Full_Name: Ettore Simone Version: CVS HEAD OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/server-slapd-overlays-accesslog-0.4.patch Submission from: (NULL) (82.91.99.165) I know about the better way using the new accesslog structure, but the old changelog method is still used by commercial product like Oracle Internet Directory, Novell eDirectory and others, usually to perform Identity Management operations. The old style changelog simplify the integration and perform better in sincronizations compared to optimized full searches. I'll provide a patch (server-slapd-overlays-accesslog-0.4.patch) that let choose the style of logging (logstyle accesslog|changelog, with accesslog as default) and that follow the directives pubished as draft by IETF and named draft-good-ldap-changelog-04. In the hope it could be useful. My best regards, Ettore Simone
changed notes moved from Incoming to Contrib
> I know about the better way using the new accesslog structure, but the old > changelog method is still used by commercial product like Oracle Internet > Directory, Novell eDirectory and others, usually to perform Identity Management > operations. > > The old style changelog simplify the integration and perform better in > sincronizations compared to optimized full searches. > > I'll provide a patch (server-slapd-overlays-accesslog-0.4.patch) that let choose > the style of logging (logstyle accesslog|changelog, with accesslog as default) > and that follow the directives pubished as draft by IETF and named > draft-good-ldap-changelog-04. Thanks for the contribution. As soon as the IPR and related stuff are checked and approved, I'd take care of integrating your patch into HEAD code. I have a few questions: - what client software did you check your patch with? - as far as I remember, some implementations also take care of noting firstChangeNumber and lastChangeNumber in the rootDSE, along with the changeLog attribute indicating what naming context is holding the logs. I wonder if their absence, although not described in draft-good-ldap-changelog-04, would impact interoperability with clients making use of che changelog approach. - could you provide a patch for the man page? We could either use the code as is, adding the related parts to slapo-accesslog(5), or register the overlay twice, one as "accesslog" and one as "changelog", and let slapd determine the style and the configuration syntax based on the overlay's name. In this case, a slapo-changelog(5) man page would be more appropriate. p.
Thanks to you for your great job. On 8/30/06, Pierangelo Masarati <openldap-its@openldap.org> wrote: > > Thanks for the contribution. As soon as the IPR and related stuff are > checked > and approved, I'd take care of integrating your patch into HEAD code. > > I have a few questions: > > - what client software did you check your patch with? I played with Novell IDM2, Novell IM3 and with Sun One Directory 5 (based on Netscape). - as far as I remember, some implementations also take care of noting > firstChangeNumber and lastChangeNumber in the rootDSE, along with the > changeLog > attribute indicating what naming context is holding the logs. I wonder if > their > absence, although not described in draft-good-ldap-changelog-04, would > impact > interoperability with clients making use of che changelog approach. I know that firstChangeNumber and lastChangeNumber are used by IBM Tivoli Directory Server, I'm not sure if it's used in OID or other. I'm sure it's not used in eDirectory. In eDirectory with IDM the last changeNumer is stored in its ldap object (with represent the connection to the ldap). In case of its absence they start from 0. If their absence compromise the integration with IBM Tivoli, or other clients, it could be added in a second stage I suppose. - could you provide a patch for the man page? We could either use the code > as > is, adding the related parts to slapo-accesslog(5), or register the > overlay > twice, one as "accesslog" and one as "changelog", and let slapd determine > the > style and the configuration syntax based on the overlay's name. In this > case, a > slapo-changelog(5) man page would be more appropriate. > As you prefere. I can provide both the man. I don't know many about how to register the same overlay twice with different names. Can you point me to some example of this? Regards, Ettore Simone
I forgot to mention that the rootDSE changeLog entry is just provided in the patch supplied.
> I forgot to mention that the rootDSE changeLog entry is just provided > in the patch supplied. Yes, I've noticed it, thanks. I've already reworked the code to take care of registering with two names. I'm doing some cleanup of the back-config stuff to prevent reconfiguring a running database from accesslog to changelog mode and the like; I'll take care of those details. Right now, to select the changelog mode, you can simply use overlay changelog log* ... the rest is much like accesslog. In any case, I think we can plainly add a comment to slapo-accesslog(5) which states that by invoking the overlay as "changelog" the changelog mode is used. At a first glance, all the functionalities seem to be there as expected; now I'm looking for something to test it with, I'll likely be back by the end of the week. -- o --- o -- Kurt, please check the IPR and see if I can go along with committing the changes. Also, I guess it'd be nice to add draft-good-ldap-changelog to the package, right? p.
To Ando as well - be very careful with this. As noted in my accesslog draft, the changelog spec has some major security weaknesses, along with the rest of its shortcomings. ettore.simone@gmail.com wrote: > I forgot to mention that the rootDSE changeLog entry is just provided > in the patch supplied. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
hyc@symas.com wrote: > To Ando as well - be very careful with this. As noted in my accesslog > draft, the changelog spec has some major security weaknesses, along with > the rest of its shortcomings. > I think I'm aware of all those issues. One major point for spending some time on this issue is that I happen to need supporting few clients that want to use this feature. I'll do my best to persuade the implementors of those clients that supporting content synchronization and/or accesslog as currently implemented in OpenLDAP is way much better, but unfortunately I have no control on that, and it's very unlikely that they will, based on the usual refrain "changelog is the de facto standard" or things like that. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------
ando@sys-net.it wrote: > hyc@symas.com wrote: > >> To Ando as well - be very careful with this. As noted in my accesslog >> draft, the changelog spec has some major security weaknesses, along with >> the rest of its shortcomings. >> >> > I think I'm aware of all those issues. One major point for spending > some time on this issue is that I happen to need supporting few clients > that want to use this feature. I'll do my best to persuade the > implementors of those clients that supporting content synchronization > and/or accesslog as currently implemented in OpenLDAP is way much > better, but unfortunately I have no control on that, and it's very > unlikely that they will, based on the usual refrain "changelog is the de > facto standard" or things like that. > I agree that implementing that spec means contributing to keeping it into life, but the point is that I have to face with closed source products which claim to support it and explicitly state in their documentation that they "can interoperate with: Netscape/iPlanet/Sun ONE; Active Directory; Lotus Domino; Exchange, while interoperability with OpenLDAP is not possible because it cannot store changes into the changelog", which we know it's not only incorrect, but also false: OpenLDAP provides better native (although coded into an open specification: RFC4533) means to synchronize than simply storing changes into a changelog. Moreover, it provides native (although coded into an open specification: draft-chu-ldap-logschema) means to inform clients about modifications. But many client implementors seem to willingly ignore this, so I need to keep supporting obsoleted de facto standard stuff, which, by the way, doesn't even agree with the contents of preliminary attempts to specify them in an open manner (see Netscape/iPlanet/Sun ONE, now Fedora DS "retroplugin" as opposed to draft-good-ldap-changelog)! p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------
resent 4656.reply.2
I've placed a reworked patch into the ITS at <ftp://ftp.openldap.org/incoming/changelog-pm-2006-09-04.patch> Basically, there were a few concurrency issues when increasing the changeNumber plus minor cleanup. I also renamed functions specific to the changelog feature prepending "changelog_" instead of "accesslog_", to make clear what's specific and what's not. Finally, I started integrating some of the stuff that Neil Dunbar submitted as ITS#3953 (right now, the schema and the presentation of {first,last}ChangeNumber. Right now, this is optional and mimics what done by FDS, i.e. the numbers are published in the root DSE (which makes very little sense; even publishing the changeLog attribute in the root DSE is nonsense to me!) rather than in the suffix entry of the changelog itself. Consider this a work in progress, though. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------
Great work! I submitted a patch to update the old overlay of Neil Dunbar to OpenLDAP 2.3. It works for our identity management (using Novell IDM 3.01) - see ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I would like to ask, wether this patch (ITS#4656) is likely to be accepted in the near future. In this case I won't maintain a separate overlay. But it doesn't seem to be in HEAD, for now? -- MfG Sebastian Rieger Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg - 37077 Göttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des DFN überprüft werden: https://ca.gwdg.de/certs/root-classic/root-ca-cert.der
Hi, I have not been paying attention to these changes since Ando was working on them. You'll have to ask him for their update status. Since you've already posted a query to the ITS, I think that would be the appropriate place to continue the conversation. Looking over the ITS just now, I would say the tweak to register the changelog overlay type is unnecessary. Nor can you fairly deprecate the LogStyle parameter, since that appears to be the only way to invoke the SunOne workaround. All in all I understand your motivations for pursuing this feature. Despite my dislike for broken specs and broken code, I will not prevent this patch from going in. But you should realize that wrong is wrong, and just because Novell, Sun, and Oracle software is broken doesn't mean we should be broken too. There are other IdM packages out there. Rieger, Sebastian wrote: > Hi, > > I submitted a patch to update the old overlay of Neil Dunbar to OpenLDAP > 2.3. It works for our identity management (using Novell IDM 3.01) - see > ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I would like > to ask, wether the patch to your accesslog that offers changelog > functionality (ITS#4656) is likely to be committed to CVS HEAD in the near > future. In this case I won't maintain a separate overlay. Thanks in advance > for a quick reply, we really need changelog functionality as Novell, Sun and > Oracle seem to depend on it. > > -- > MfG > > Sebastian Rieger > > Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen > Am Fassberg - 37077 Göttingen > Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 > > Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des DFN > überprüft werden: https://ca.gwdg.de/certs/root-classic/root-ca-cert.der > -- -- 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/
Thanks for the quick reply, I'd continue the conversation with Ando and via IST, thanks for putting them on CC:. Can you name the IdM packages you refer to, that implement a replication mechanism that is compatible with OpenLDAP? We tested: - Microsoft Identity Integration Server: only flat-file LDAP support (using LDIF) (until Gemini version ~2008) - no replication, just full synchronization - Siemens DirX: using a full search over all objects (Novell Identity Manager can do so either, but you're unable to detect moved objects then, as it looks like a delete and add of the object, and performance is low, as for every sync cycle a full search over the tree is necessary) Oracle and Sun using changelog were already mentioned... Maybe IBM? or do you refer to the meta backend module for OpenLDAP? Thanks in advance for the advice... -- MfG Sebastian Rieger Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg - 37077 Göttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des DFN überprüft werden: https://ca.gwdg.de/certs/root-classic/root-ca-cert.der -----Ursprüngliche Nachricht----- Von: Howard Chu [mailto:hyc@symas.com] Gesendet: Dienstag, 13. Februar 2007 12:20 An: Rieger, Sebastian Cc: Heuer, Konrad; ando@OpenLDAP.org; openldap-its@OpenLDAP.org Betreff: Re: ITS#4656 OpenLDAP accesslog overlay using "changelog dialect" Hi, I have not been paying attention to these changes since Ando was working on them. You'll have to ask him for their update status. Since you've already posted a query to the ITS, I think that would be the appropriate place to continue the conversation. Looking over the ITS just now, I would say the tweak to register the changelog overlay type is unnecessary. Nor can you fairly deprecate the LogStyle parameter, since that appears to be the only way to invoke the SunOne workaround. All in all I understand your motivations for pursuing this feature. Despite my dislike for broken specs and broken code, I will not prevent this patch from going in. But you should realize that wrong is wrong, and just because Novell, Sun, and Oracle software is broken doesn't mean we should be broken too. There are other IdM packages out there. Rieger, Sebastian wrote: > Hi, > > I submitted a patch to update the old overlay of Neil Dunbar to > OpenLDAP 2.3. It works for our identity management (using Novell IDM > 3.01) - see ITS#4685. As my patch needs cleanup to get into OpenLDAP > HEAD I would like to ask, wether the patch to your accesslog that > offers changelog functionality (ITS#4656) is likely to be committed to > CVS HEAD in the near future. In this case I won't maintain a separate > overlay. Thanks in advance for a quick reply, we really need changelog > functionality as Novell, Sun and Oracle seem to depend on it. > > -- > MfG > > Sebastian Rieger > > Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am > Fassberg - 37077 Göttingen > Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 > > Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des > DFN überprüft werden: > https://ca.gwdg.de/certs/root-classic/root-ca-cert.der > -- -- 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/
hyc@symas.com wrote: > All in all I understand your motivations for pursuing this feature. Despite > my dislike for broken specs and broken code, I will not prevent this patch > from going in. But you should realize that wrong is wrong, and just because > Novell, Sun, and Oracle software is broken doesn't mean we should be broken > too. There are other IdM packages out there. While this is hardly the place for commercial endorsements, I should note that while Neil Dunbar wrote that changelog overlay for HP's purposes, we (Symas) convinced HP to adopt the accesslog format instead and HP does not rely on the changelog any more. If you're looking for software that actually conforms to open specs with some degree of technical merit, you might consider looking there, if you can't convince your current vendors to fix their products. > > Rieger, Sebastian wrote: >> Hi, >> >> I submitted a patch to update the old overlay of Neil Dunbar to OpenLDAP >> 2.3. It works for our identity management (using Novell IDM 3.01) - see >> ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I would like >> to ask, wether the patch to your accesslog that offers changelog >> functionality (ITS#4656) is likely to be committed to CVS HEAD in the near >> future. In this case I won't maintain a separate overlay. Thanks in advance >> for a quick reply, we really need changelog functionality as Novell, Sun and >> Oracle seem to depend on it. -- -- 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/
hyc@symas.com wrote: > Hi, > I have not been paying attention to these changes since Ando was working > on them. You'll have to ask him for their update status. Sorry for overlooking yur previous message. Yes, I'm keeping that patch sort of updated, but keeping it in sync with HEAD was a pain due to the many changes that occurred in that code. I'm not sure it's ready for commit right now, and I'm not sure it works as intended, given the lack of specs (every implementor seem to have their own idea of haw that's supposed to work, and willing to interoperate, despite claims, seems to be their last concern). Preserving compatibility with re23 might not be an option, and I don't think we want that stuff to go in re23 right now. > Since you've already posted a query to the ITS, I think that would be the > appropriate place to continue the conversation. > > Looking over the ITS just now, I would say the tweak to register the > changelog overlay type is unnecessary. Nor can you fairly deprecate the > LogStyle parameter, since that appears to be the only way to invoke the > SunOne workaround. > > All in all I understand your motivations for pursuing this feature. Despite > my dislike for broken specs and broken code, I will not prevent this patch > from going in. But you should realize that wrong is wrong, and just because > Novell, Sun, and Oracle software is broken doesn't mean we should be broken > too. There are other IdM packages out there. I'll be committing something workable soon. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------
See ITS#3953
The auditlog overlay generates something quite similar, and there's little value in supporting this at this point.