Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments?
--On Thursday, April 05, 2007 12:30 PM -0700 Howard Chu hyc@symas.com wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments?
Please. :P
Although there was one concern expressed recently that the syncrepl w/ back-ldap as a push method wasn't a great solution as a replacement, since it requires opening holes in the firewall in the reverse direction. If it is something we simply are never going to address, then I guess that is just the way things go. ;)
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah Gibson-Mount wrote:
--On Thursday, April 05, 2007 12:30 PM -0700 Howard Chu hyc@symas.com wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments?
Please. :P
Although there was one concern expressed recently that the syncrepl w/ back-ldap as a push method wasn't a great solution as a replacement, since it requires opening holes in the firewall in the reverse direction.
Huh? It requires no such thing. syncrepl w/back-ldap will work with the exact same firewall setup as slurpd.
If it is something we simply are never going to address, then I guess that is just the way things go. ;)
Not an issue.
--On Thursday, April 05, 2007 1:07 PM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Thursday, April 05, 2007 12:30 PM -0700 Howard Chu hyc@symas.com wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments?
Please. :P
Although there was one concern expressed recently that the syncrepl w/ back-ldap as a push method wasn't a great solution as a replacement, since it requires opening holes in the firewall in the reverse direction.
Huh? It requires no such thing. syncrepl w/back-ldap will work with the exact same firewall setup as slurpd.
Well, it wasn't my concern. I'm just saying what they expressed. ;)
The relevant thread is:
http://www.openldap.org/lists/openldap-software/200703/msg00251.html
If they are wrong, then so much the better. :)
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah Gibson-Mount wrote:
--On Thursday, April 05, 2007 1:07 PM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Thursday, April 05, 2007 12:30 PM -0700 Howard Chu hyc@symas.com wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments?
Please. :P
Although there was one concern expressed recently that the syncrepl w/ back-ldap as a push method wasn't a great solution as a replacement, since it requires opening holes in the firewall in the reverse direction.
Huh? It requires no such thing. syncrepl w/back-ldap will work with the exact same firewall setup as slurpd.
Well, it wasn't my concern. I'm just saying what they expressed. ;)
The relevant thread is:
http://www.openldap.org/lists/openldap-software/200703/msg00251.html
If they are wrong, then so much the better. :)
That person was talking about plain syncrepl, not assisted via back-ldap.
--On Thursday, April 05, 2007 1:17 PM -0700 Howard Chu hyc@symas.com wrote:
The relevant thread is:
http://www.openldap.org/lists/openldap-software/200703/msg00251.html
If they are wrong, then so much the better. :)
That person was talking about plain syncrepl, not assisted via back-ldap.
Oh. When they said they'd read the threads about "push" based syncrepl, I made the assumption they were talking about using it with back-ldap, since I don't know how else you'd get push based syncrepl. In any case, I vote to purge slurpd.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Howard Chu said the following on 05/04/07 21:17:
Quanah Gibson-Mount wrote:
--On Thursday, April 05, 2007 1:07 PM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Thursday, April 05, 2007 12:30 PM -0700 Howard Chu hyc@symas.com wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments?
Please. :P
Although there was one concern expressed recently that the syncrepl w/ back-ldap as a push method wasn't a great solution as a replacement, since it requires opening holes in the firewall in the reverse direction.
Huh? It requires no such thing. syncrepl w/back-ldap will work with the exact same firewall setup as slurpd.
Well, it wasn't my concern. I'm just saying what they expressed. ;)
The relevant thread is:
http://www.openldap.org/lists/openldap-software/200703/msg00251.html
If they are wrong, then so much the better. :)
That person was talking about plain syncrepl, not assisted via back-ldap.
We can just add a Firewall section to the Replication section in the new Admin guide for this setup.
I'll make a note.
We can just add a Firewall section to the Replication section in the new Admin guide for this setup.
And that's probably the biggest blocker to keeping slurpd around -- which is to say, lose it.
BTW, RE23 tested good for me on Solaris; there are a couple relevant ITS to us resolved in it and I expect it to go production quickly around here.
Aaron Richton wrote:
We can just add a Firewall section to the Replication section in the new Admin guide for this setup.
And that's probably the biggest blocker to keeping slurpd around -- which is to say, lose it.
Since nobody has leaped to slurpd's defense ;) it's now gone in HEAD. We can drop it from RE24 the next time we sync it with HEAD.
BTW, RE23 tested good for me on Solaris; there are a couple relevant ITS to us resolved in it and I expect it to go production quickly around here.
Thanks for the feedback. I think all that remains is to push a couple of the recent doc fixes in HEAD into RE23 and we should be good to go.
Howard Chu wrote:
Aaron Richton wrote:
We can just add a Firewall section to the Replication section in the new Admin guide for this setup.
And that's probably the biggest blocker to keeping slurpd around -- which is to say, lose it.
Since nobody has leaped to slurpd's defense ;) it's now gone in HEAD. We can drop it from RE24 the next time we sync it with HEAD.
You exploited my first and only 4 vacation days in 2007! Just kidding, please go.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Gavin Henry wrote:
Howard Chu said the following on 05/04/07 21:17:
Quanah Gibson-Mount wrote:
Huh? It requires no such thing. syncrepl w/back-ldap will work with the exact same firewall setup as slurpd.
Well, it wasn't my concern. I'm just saying what they expressed. ;)
The relevant thread is:
http://www.openldap.org/lists/openldap-software/200703/msg00251.html
If they are wrong, then so much the better. :)
That person was talking about plain syncrepl, not assisted via back-ldap.
We can just add a Firewall section to the Replication section in the new Admin guide for this setup.
I'll make a note.
Sounds good, thanks. Yes, we have a lot of reworking to do in the Admin guide.
We've been using slurpd to replicate to a Novell edirectory, and a modified slurpd to talk to a ActiveDirectory. If we ever want to move to 2.4, we would need slurpd and replog creation.
On Apr 5, 2007, at 3:30 PM, Howard Chu wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
<quote who="Paul Turgyan">
We've been using slurpd to replicate to a Novell edirectory, and a modified slurpd to talk to a ActiveDirectory. If we ever want to move to 2.4, we would need slurpd and replog creation.
But you've modified slurpd, so it would never be the same anyway.
On Apr 5, 2007, at 3:30 PM, Howard Chu wrote:
Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Paul Turgyan wrote:
We've been using slurpd to replicate to a Novell edirectory, and a modified slurpd to talk to a ActiveDirectory. If we ever want to move to 2.4, we would need slurpd and replog creation.
If you had submitted modifications back to the Project that might have told us there was interest in maintaining slurpd. As it is, nobody on the Project has any interest, so you would still have been maintaining it yourself. The way forward here is to write an overlay that handles any necessary adaptations for ActiveDirectory. You just have to map entryUUID to objectGUID and map the entryCSNs.
-
Aaron Richton -
Gavin Henry -
Howard Chu -
Paul Turgyan -
Pierangelo Masarati -
Quanah Gibson-Mount