- openldap-bugs - openldap.org

Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart
by h.b.furuseth＠usit.uio.no 11 Sep '08

11 Sep '08

Looking at liblutil/utils.c:lutil_gettime() led me to Beware of QueryPerformanceCounter() http://www.virtualdub.org/blog/pivot/entry.php?id=106 Is warning relevant to slapd? I don't know Windows programming at all. -- Hallvard

1 0

Re: (ITS#5668) Invalid entryCSN generated, and slapd will not restart
by hyc＠symas.com 10 Sep '08

10 Sep '08

emmanuel.duru(a)atosorigin.com wrote: > I am running windows 32 bits. > Here is what I get from my debugging session: > After QueryPerformanceCounter(&count ), count.QuadPart is worth > 4243738405535005 > So the overflow comes from count.QuadPart *= 1000000; I see. There's no reason we should be computing against the full value of the count; since we're only looking for the microsecond portion we should have stripped off everything greater. (E.g., count.QuadPart %= cFreq.QuadPart). I'll have to play with this code a bit more, there's probably a better way to isolate the microseconds. PS: I guess that means your Windows machine had an uptime of several days. Quite impressive, for Windows... ;) > > >> -----Message d'origine----- >> De : Howard Chu [mailto:hyc@symas.com] >> Envoyé : mercredi 27 août 2008 13:08 >> À : openldap-its(a)openldap.org; Emmanuel Duru >> Objet : Re: (ITS#5668) Invalid entryCSN generated, and slapd will not >> restart >> >> ando(a)sys-net.it wrote: >>> emmanuel.duru(a)atosorigin.com wrote: >>>> I see that tm->tm_usub is negative, there seems to be overflows between >>>> LARGE_INTEGER and int variables. >> It would take over 4 billion operations in a single timer tick (on the >> order >> of nanoseconds) to make tm_usub overflow. That seems pretty unlikely. >> >>> If the problem disappears by initializing the static variables in >>> lutil_gettime(), then it might be a compiler issue. >> I suppose that's always possible... >> >> The original post shows that the tm_usec field is negative. That could >> happen >> if the offset we computed between the SYSTEMTIME and the >> PerformanceCounter >> was wrong, or if the SYSTEMTIME was adjusted while the process was >> running. >> >> What version of Windows are you running? 32 or 64 bit? Can you singlestep >> through this function with a debugger and verify all of the values? I >> haven't >> run this code on Windows in a long time, would take a bit of effort to >> resurrect my build environment. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5694)
by ando＠sys-net.it 10 Sep '08

10 Sep '08

Works for me, after Howard's fix. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > Just to be clear here, I'm slapcating a provider while it is running, > then stopping the provider and the replica, wiping both their dbs, then > using slapadd -w to reload the *provider* and syncrepl to load the > consumer. Thus I don't see whether or not the CSN is in memory at the > time on the *provider* matters much. Right, it shouldn't matter, since either it is equal to what -w would generate, or -w would overwrite it with the correct value anyway. The only case I see is if the last operation was a delete, then the contextCSN on the provider would be greater than what a slapadd -w would generate. > Particularly given that if I stop > the reloaded provider and restart it (i.e., flushing the context CSN), I > still get the same behavior problems on the replica. I.e., the replica > has never been loaded via slapadd, only the provider, and the provider > has been stopped started since the slapadd. In fact, I could easily reproduce the behavior you pointed out. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati >> <ando(a)sys-net.it> wrote: >> >>> I thuink the issue is related to the fact that slapadd -w uses >>> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >>> does not implement those hooks. As a consequence, any modification to >>> the context entry is not reflected in slapo-accesslog(5). >>> >>> However, I don't see how this should affect replication, since a >>> consistent database, after slapcatt'ing, should generate a ldif with the >>> correct contextCSN. However, if you slapcat before stopping the >>> producer, the resulting ldif will not contain the contextCSN, because >>> after a fresh slapadd without -w it's kept in memory until the producer >>> is stopped. You should try Just to be clear here, I'm slapcating a provider while it is running, then stopping the provider and the replica, wiping both their dbs, then using slapadd -w to reload the *provider* and syncrepl to load the consumer. Thus I don't see whether or not the CSN is in memory at the time on the *provider* matters much. Particularly given that if I stop the reloaded provider and restart it (i.e., flushing the context CSN), I still get the same behavior problems on the replica. I.e., the replica has never been loaded via slapadd, only the provider, and the provider has been stopped started since the slapadd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 12:19 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati >> <ando(a)sys-net.it> wrote: >> >> >>>> I'll give what you suggested a try, but this is still a serious bug. >>> There's something I don't clearly get. As far as I understand, you are >>> saying that consumers lose sync when the log database is purged before >>> they have a chance to sync (because they were down). I don't see how >>> they could sync, then. Of course, there should be a means for >>> slapo-syncprov(5) to tell that, and force a refresh. >> >> Because the consumer is supposed to do a full refresh if they find their >> context CSN doesn't match the contextCSN of the master. > > Not quite. More precisely, the provider is supposed to tell the consumer > that the consumer's cookie is out of date if the cookie is older than > anything in the provider, and the consumer asked for the reload Hint. > Otherwise the provider just sees the consumer is stale and returns a full > dump implicitly. Well, the consumer's definitely not acting on a full dump in either case. :/ In my latest test, after the purge, I have: # accesslog dn: cn=accesslog contextCSN: 20080909190440.484524Z#000000#000#000000 dn: contextCSN: 20080909190440.484524Z#000000#000#000000 on the master and contextCSN: 20080909183254.258851Z#000000#000#000000 on the replica prior to starting it. SO the replica is clearly behind. The new entry on the master is: dn: uid=qtest7,cn=admins,cn=zimbra entryCSN: 20080909190440.484524Z#000000#000#000000 which matches the CSN on both the main DB and accesslog DB. now, staring the replica, we find: contextCSN: 20080909190440.484524Z#000000#000#000000 So, it believes it has sync'd now, but uid=qtest7 doesn't exist! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by hyc＠symas.com 09 Sep '08

09 Sep '08

quanah(a)zimbra.com wrote: > --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > > >>> I'll give what you suggested a try, but this is still a serious bug. >> There's something I don't clearly get. As far as I understand, you are >> saying that consumers lose sync when the log database is purged before >> they have a chance to sync (because they were down). I don't see how >> they could sync, then. Of course, there should be a means for >> slapo-syncprov(5) to tell that, and force a refresh. > > Because the consumer is supposed to do a full refresh if they find their > context CSN doesn't match the contextCSN of the master. Not quite. More precisely, the provider is supposed to tell the consumer that the consumer's cookie is out of date if the cookie is older than anything in the provider, and the consumer asked for the reload Hint. Otherwise the provider just sees the consumer is stale and returns a full dump implicitly. In plain syncrepl the consumer never asks for the reload hint. In delta-sync the consumer does ask for a reload hint, because that tells it to do a sync from the main DB instead of the log DB. It sounds like if there's a bug here, it's caused by the logdb's provider not sending a reload hint when it should. > See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: >> I'll give what you suggested a try, but this is still a serious bug. > > There's something I don't clearly get. As far as I understand, you are > saying that consumers lose sync when the log database is purged before > they have a chance to sync (because they were down). I don't see how > they could sync, then. Of course, there should be a means for > slapo-syncprov(5) to tell that, and force a refresh. Because the consumer is supposed to do a full refresh if they find their context CSN doesn't match the contextCSN of the master. See ITS#5376, ITS#5378, ITS#5465, ITS#5493, ITS#5282 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> I thuink the issue is related to the fact that slapadd -w uses >> bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) >> does not implement those hooks. As a consequence, any modification to >> the context entry is not reflected in slapo-accesslog(5). >> >> However, I don't see how this should affect replication, since a >> consistent database, after slapcatt'ing, should generate a ldif with the >> correct contextCSN. However, if you slapcat before stopping the >> producer, the resulting ldif will not contain the contextCSN, because >> after a fresh slapadd without -w it's kept in memory until the producer >> is stopped. You should try > > It should be possible to restore a working provider/slave relationship > from a hot slapcat taken at any point in time. Well, actually slapadd -w should suffice. As an alternative, slapcat could support -w as well, for symmetry, so that consistent ldifs can be generated. > I'll give what you suggested a try, but this is still a serious bug. There's something I don't clearly get. As far as I understand, you are saying that consumers lose sync when the log database is purged before they have a chance to sync (because they were down). I don't see how they could sync, then. Of course, there should be a means for slapo-syncprov(5) to tell that, and force a refresh. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 8:50 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > I thuink the issue is related to the fact that slapadd -w uses > bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) > does not implement those hooks. As a consequence, any modification to > the context entry is not reflected in slapo-accesslog(5). > > However, I don't see how this should affect replication, since a > consistent database, after slapcatt'ing, should generate a ldif with the > correct contextCSN. However, if you slapcat before stopping the > producer, the resulting ldif will not contain the contextCSN, because > after a fresh slapadd without -w it's kept in memory until the producer > is stopped. You should try It should be possible to restore a working provider/slave relationship from a hot slapcat taken at any point in time. I'll give what you suggested a try, but this is still a serious bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by ando＠sys-net.it 09 Sep '08

09 Sep '08

I thuink the issue is related to the fact that slapadd -w uses bi_tool_entry_modify() and bi_tool_sync(). However, slapo-accesslog(5) does not implement those hooks. As a consequence, any modification to the context entry is not reflected in slapo-accesslog(5). However, I don't see how this should affect replication, since a consistent database, after slapcatt'ing, should generate a ldif with the correct contextCSN. However, if you slapcat before stopping the producer, the resulting ldif will not contain the contextCSN, because after a fresh slapadd without -w it's kept in memory until the producer is stopped. You should try (i) stop the master and replica (j) do a slapcat of the master (k) delete the database on the master and replica (l) Use slapadd -w to restore your slapcat of 5 users (m) start the replica, verify the contents are the same (n) stop the replica (o) add a user on the master (p) wait for the accesslog to expire (q) start the replica In the meanwhile, you should check what contextCSN your consumers have after syncing from a producer loaded without -w. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 6:27 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 9/7/2008 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As reported by David Hawes: > > http://www.openldap.org/lists/openldap-software/200808/msg00163.html > > If you load a server that will become the delta-syncrepl master using > slapadd -w, the slave will not see changes that occur after the accesslog > expires. Additionally did the following: Stopped the replica again, purged its db, restarted it so it got a fresh sync from the master (all users present). stopped the replica, added a new user on the master, let it expire from the accesslog db. started the replica. New user is not replicated. So it essentially appears that once -w is used to slapadd a master, no replica will be consistent if changes occur that are purged before the replica gets them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 9/7/2008 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As reported by David Hawes: http://www.openldap.org/lists/openldap-software/200808/msg00163.html If you load a server that will become the delta-syncrepl master using slapadd -w, the slave will not see changes that occur after the accesslog expires. To confirm this, I did the following: (a) Created a base LDIF file that set up the suffix, a people tree, and a replica user (b) slapadded this LDIF file WITHOUT -w on the master (c) started the master (d) started the replica All data was replicated correctly (e) Stopped the replica (f) Added 6 users, and then deleted one (g) waited for the accesslog to expire (h) started the replica All data was replicated correctly (i) did a slapcat of the master (j) stopped the master and replica (k) deleted the database on the master and replica (l) Used slapadd -w to restore my slapcat of 5 users (m) started the replica, verified the contents were the same (n) stopped the replica (o) added a user on the master (p) waited for the accesslog to expire (q) started the replica The user I added was not replicated, and now the databases are inconsistent.

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 4:52 PM +0000 ando(a)sys-net.it wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: >> >>> quanah(a)zimbra.com wrote: >>> >>>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>>> it should be valid to me. >>> >>> ... >>> >>>> cn=config is *clearly* under "" >>> >>> No, cn=config is *clearly* under cn=config, which comes earlier than "". >>> But then you don't need to set rootpw. >> >> Ah, I see. So this is more just a behavior change between 2.3 and 2.4. >> Thanks! > > Well, I don't think they changed that much. If you expose cn=config > then any DN in that namespace will belong to the back-config; if you > don't expose it, then it will belong to "". I think you weren't using > the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. Hm, you're right, I mixed parts of a stock 2.4 slapd.conf with my 2.3 slapd.conf. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Quanah Gibson-Mount wrote: > --On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >> >>> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >>> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >>> it should be valid to me. >> >> ... >> >>> cn=config is *clearly* under "" >> >> No, cn=config is *clearly* under cn=config, which comes earlier than "". >> But then you don't need to set rootpw. > > Ah, I see. So this is more just a behavior change between 2.3 and 2.4. > Thanks! Well, I don't think they changed that much. If you expose cn=config then any DN in that namespace will belong to the back-config; if you don't expose it, then it will belong to "". I think you weren't using the same slapd.conf with 2.3 and 2.4, if you noticed a different behavior. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 09 Sep '08

09 Sep '08

--On Tuesday, September 09, 2008 10:10 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> In OpenLDAP 2.3, it was possible to set the rootdn of the main database >> to be cn=config. This no longer works in OpenLDAP 2.4, but seems like >> it should be valid to me. > > ... > >> cn=config is *clearly* under "" > > No, cn=config is *clearly* under cn=config, which comes earlier than "". > But then you don't need to set rootpw. Ah, I see. So this is more just a behavior change between 2.3 and 2.4. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5691) Re: malloc without check
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Actually, I see plenty of places where it occurs. I vaguely recall that malloc used to be #defined as ch_malloc within slapd, although I believe it is no longer. In any case, I'm in favor of avoiding those redefinitions, for the sake of clarity. The correct solution should be to replace them with ch_malloc() (same for other memory-related functions, like calloc(), realloc(), strdup() and free(), although the latter is not strictly needed). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5692) Re: literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by ando＠sys-net.it 09 Sep '08

09 Sep '08

In none of the files you indicated the buffer size 8192 is used for a DN, so I see no reason for hijacking SLAP_LDAPDN_MAXLEN for that purpose. It might be good practice to define one or more macros and consistently use them, although in the specific cases there is no repeated use of the value, nor specific consistency constraints for the use of that value. With respect to your second question, OpenLDAP never relies on SLAP_LDAPDN_MAXLEN stability in terms of buffer access; since that macro is local to slapd, if it changes the whole slapd will see it. The only issue could be with redefinition of the macro across module compilation, if you use dynamic modules. Also in that case things shouldn't be critical, as slapd never relies on that macro for accessing buffers, but rather on actual buffer size. The only potentia issue I see is with spurious syntax errors if a module with larger SLAP_LDAPDN_MAXLEN calls a DN-related validation/normalization function passing a DN whose length is larger than the value of SLAP_LDAPDN_MAXLEN slapd was built with. No buffer overflow risk, though; at most, DoS on uncommonly long DNs. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I see a few potential issues in current slapo-translucent(5) filtering approach: - if an attribute is marked as local, it will not be used to filter entries on the remote server; however, that attribute might exist in entries on the remote server, resulting in inconsistent search results - the same is also true in the reverse case in those cases, it might be helpful to let the same attribute be listed as local *and* remote, acting accordingly. Also, there is no way to indicate that some attributes are local and *all the others* are remote (and viceversa); it is suggested to allow "*" (and "+"?), as well as "1.1" to indicate no attributes. Wildcards would take effect unless attribute specifications are present. I don't know, right now, how easy it would be to implement those enhancements; I'm just noting them here as a reminder for a feature request. p.

1 0

Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
by toby＠inf.ed.ac.uk 09 Sep '08

09 Sep '08

Hi again, I haven't been able to reproduce the problem since patching, so I consider it fixed.... Many thanks Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#5692) literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in /servers/slapd/bconfig.c /libraries/libldap_r/tls.c /libraries/libldap_r/tls.c ./libraries/liblber/stdio.c /libraries/liblunicode/ucdata/ucgendat.c /contrib/slapd-modules/lastmod/lastmod.c the literal value 8192 is used for array sizes instead of SLAP_LDAPDN_MAXLEN 8192 defined in /servers/slapd/slap.h I think this could become a problem if SLAP_LDAPDN_MAXLEN grows in a future release. A question from a newbie: What happens in a mixed environment with a never version with bigger SLAP_LDAPDN_MAXLEN that replicates his entries to a version with SLAP_LDAPDN_MAXLEN at 8192 ? Isn't it wrong not to check for a buffer owerflow when strings are concantenated and suppose that the data we use does not exceed the limit ? Bye Andreas

1 0

(ITS#5691) malloc withou check
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in servers/slapd/add.c int the function slap_entry2mods() malloc() is called three times and the result is not checked against NULL. Bye Andreas

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by ando＠sys-net.it 09 Sep '08

09 Sep '08

quanah(a)zimbra.com wrote: > In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be > cn=config. This no longer works in OpenLDAP 2.4, but seems like it should be > valid to me. ... > cn=config is *clearly* under "" No, cn=config is *clearly* under cn=config, which comes earlier than "". As such, auth'ing as cn=config will be intercepted by back-config, hence the config error. > and changing it to "cn=config,dc=junk" works. > So it's specific to the term "cn=config". Changing it to "cn=joe" works just > fine. It also doesn't seem to care that I use "cn=config" with back-monitor... But then you don't need to set rootpw. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 09 Sep '08

09 Sep '08

mateusz.kijowski(a)gmail.com wrote: > Full_Name: Mateusz Kijowski > Version: 2.3.43 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.126.222.22) > > > In some use scenarios, it is useful if the translucent overlay does not forward > bind operation requests to the remote server when there are values for > userPassword attribute in the local database. It would be nice if this could be > enabled or disabled by a configuration option. For consistency, enabling this > behavior should also affect the PASSMOD extended operation to modify the local > value of userPassword. The local bind feature has been added to HEAD; please test. As for the passmod feature, that requires a little bit more. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 08 Sep '08

08 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be cn=config. This no longer works in OpenLDAP 2.4, but seems like it should be valid to me. Example config: include /opt/zimbra/openldap-2.4.12/etc/openldap/schema/core.schema include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/inetorgperson.schema" pidfile /opt/zimbra/openldap-2.4.12/var/run/slapd.pid argsfile /opt/zimbra/openldap-2.4.12/var/run/slapd.args modulepath /opt/zimbra/openldap-2.4.12/libexec/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la database config rootpw secret database monitor rootdn "cn=config" access to dn.children="cn=monitor" by * read database hdb suffix cn=accesslog directory /opt/zimbra/data/openldap/accesslog/db rootdn cn=accesslog index default eq index entryCSN index objectClass index reqEnd index reqResult index reqStart access to dn.subtree="cn=accesslog" by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=admins,cn=zimbra" read # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 64 5 cachesize 10000 timelimit unlimited sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database hdb suffix "" rootdn "cn=config" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /opt/zimbra/data/openldap/db # Indices to maintain index objectClass eq index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub # recommended for replication index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 20 10 syncprov-sessionlog 500 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 Slaptest fails with: line 74 (suffix "") >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> line 75 (rootdn "cn=config") >>> dnPrettyNormal: <cn=config> <<< dnPrettyNormal: <cn=config>, <cn=config> line 79 (rootpw ***) /opt/zimbra/openldap-2.4.12/etc/openldap/slapd.conf: line 79: <rootpw> can only be set when rootdn is under suffix slaptest: bad configuration file! cn=config is *clearly* under "", and changing it to "cn=config,dc=junk" works. So it's specific to the term "cn=config". Changing it to "cn=joe" works just fine. It also doesn't seem to care that I use "cn=config" with back-monitor...

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs