- openldap-bugs - openldap.org

Re: (ITS#5505) Attribute value for 'modifiersName' in case of overlays
by ando＠sys-net.it 10 May '08

10 May '08

> Just a feature request for convenience: > > Would it be possible to set the value of attribute 'modifiersName' to the > DN of > the overlays' configuration entry under cn=config if an entry was modified > by an > overlay? In this case one would have a direct link to the configuration if > needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity > Overlay) is > added which does not refer to an existing entry at all. Technically, I don't see any problem, except that overlays (and software modules, in general) do not hold a direct reference to their config entry's DN, if any (e.g. when back-config is not in use, the data structure is in place, but not in LDIF form; please correct me if I'm wrong). I wonder whether exposing such detail makes sense, or risks breaking any security. Probably I'm getting paranoid... 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(a)sys-net.it ---------------------------------------

1 0

(ITS#5505) Attribute value for 'modifiersName' in case of overlays
by michael＠stroeder.com 10 May '08

10 May '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.119.62) HI! Just a feature request for convenience: Would it be possible to set the value of attribute 'modifiersName' to the DN of the overlays' configuration entry under cn=config if an entry was modified by an overlay? In this case one would have a direct link to the configuration if needed. Currently 'cn=<overlay name>' (e.g cn=Referential Integrity Overlay) is added which does not refer to an existing entry at all. Ciao, Michael.

1 0

Re: (ITS#5503) Openldap segmentation fault when running syncrepl.
by hyc＠symas.com 10 May '08

10 May '08

chuck.short(a)canonical.com wrote: > Howard Chu wrote: >> zulcss(a)ubuntu.com wrote: >>> Full_Name: Chuck Short >>> Version: 2.4.9 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (99.224.150.216) >>> >>> >>> When running the following scripts openldap crashes when trying to run a >>> syncrepl from a slave server. The original bug report can be found at: >>> http://bugs.launchpad.net/bugs/227178. >>> >>> Steps to reproduce it: >>> >>> 1. Download the attachment in the bug report. >>> 2. mkdir /home/amg1127/ >>> 3. Unpack the attachment in the just created directory. >>> 4. Run the ./create-master-base.sh script. >>> 5. In one terminal run the run-master-slapd.sh script. >>> 6. In another terminal create the run-slave-slapd.sh script. >>> 7. The result will be a segmentation fault in the slave server. >>> >>> Thanks >>> chuck >> Thanks for the report, too bad you didn't forward it to us sooner. >> This is now fixed in CVS HEAD. >> > I backported the patch and was still able to reproduce the crash. Backported to 2.4.7? I see no crash with the patch applied to 2.4.9. If you're using 2.4.9, please post your backtrace. -- -- 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#5503) Openldap segmentation fault when running syncrepl.
by chuck.short＠canonical.com 10 May '08

10 May '08

Howard Chu wrote: > zulcss(a)ubuntu.com wrote: >> Full_Name: Chuck Short >> Version: 2.4.9 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (99.224.150.216) >> >> >> When running the following scripts openldap crashes when trying to run a >> syncrepl from a slave server. The original bug report can be found at: >> http://bugs.launchpad.net/bugs/227178. >> >> Steps to reproduce it: >> >> 1. Download the attachment in the bug report. >> 2. mkdir /home/amg1127/ >> 3. Unpack the attachment in the just created directory. >> 4. Run the ./create-master-base.sh script. >> 5. In one terminal run the run-master-slapd.sh script. >> 6. In another terminal create the run-slave-slapd.sh script. >> 7. The result will be a segmentation fault in the slave server. >> >> Thanks >> chuck > > Thanks for the report, too bad you didn't forward it to us sooner. > This is now fixed in CVS HEAD. > I backported the patch and was still able to reproduce the crash. Thanks chuck

1 0

Re: (ITS#5504) ldapsearch hangs retrieving info
by hyc＠symas.com 10 May '08

10 May '08

Javier.Fernandez(a)cern.ch wrote: > Full_Name: Javier Fernandez > Version: 2.2.13 > OS: SL4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (156.35.192.4) OpenLDAP 2.2 was moved to Historical status a few years ago. Upgrade to a current supported release if you want anyone to look into this. > > Hi, > ldapsearch gets stuck retrieving info and after some minutes the following error > message is thrown: > ldap_result: Can't contact LDAP server (-1) > > I'm using: > ldapsearch -V > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.2.13 (May 3 2007 03:01:11) $ > root@lxcert-amd64:/scratch/rpmbuild.7430.xx7460/openldap-2.2.13/openldap-2.2.13/build-clients/clients/tools > (LDAP library: OpenLDAP 20213) > > under > Linux 2.6.9-55.EL.cernsmp #1 SMP Thu May 10 18:09:56 CEST 2007 x86_64 x86_64 > x86_64 GNU/Linux > > Things used to work until one day when it began to give problems, so it could be > a site network port filtering problem, but our network administrator does not > know how to debug, so we would need any hint on how to trace back the problem. > > The command, which starts working but after some time gets stuck, is: > > ldapsearch -p 2170 -h exp-bdii.cern.ch -x -LLL -b "o=grid" -d -1 > > Of course, we CAN do a telnet on that port and that host. Any help is really > welcome and apreciated. Here is a snippet from the output of the command: -- -- 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#5503) Openldap segmentation fault when running syncrepl.
by hyc＠symas.com 10 May '08

10 May '08

zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 2.4.9 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.224.150.216) > > > When running the following scripts openldap crashes when trying to run a > syncrepl from a slave server. The original bug report can be found at: > http://bugs.launchpad.net/bugs/227178. > > Steps to reproduce it: > > 1. Download the attachment in the bug report. > 2. mkdir /home/amg1127/ > 3. Unpack the attachment in the just created directory. > 4. Run the ./create-master-base.sh script. > 5. In one terminal run the run-master-slapd.sh script. > 6. In another terminal create the run-slave-slapd.sh script. > 7. The result will be a segmentation fault in the slave server. > > Thanks > chuck Thanks for the report, too bad you didn't forward it to us sooner. This is now fixed in CVS HEAD. -- -- 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

(ITS#5504) ldapsearch hangs retrieving info
by Javier.Fernandez＠cern.ch 09 May '08

09 May '08

Full_Name: Javier Fernandez Version: 2.2.13 OS: SL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (156.35.192.4) Hi, ldapsearch gets stuck retrieving info and after some minutes the following error message is thrown: ldap_result: Can't contact LDAP server (-1) I'm using: ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.2.13 (May 3 2007 03:01:11) $ root@lxcert-amd64:/scratch/rpmbuild.7430.xx7460/openldap-2.2.13/openldap-2.2.13/build-clients/clients/tools (LDAP library: OpenLDAP 20213) under Linux 2.6.9-55.EL.cernsmp #1 SMP Thu May 10 18:09:56 CEST 2007 x86_64 x86_64 x86_64 GNU/Linux Things used to work until one day when it began to give problems, so it could be a site network port filtering problem, but our network administrator does not know how to debug, so we would need any hint on how to trace back the problem. The command, which starts working but after some time gets stuck, is: ldapsearch -p 2170 -h exp-bdii.cern.ch -x -LLL -b "o=grid" -d -1 Of course, we CAN do a telnet on that port and that host. Any help is really welcome and apreciated. Here is a snippet from the output of the command: ldap_create ldap_url_parse_ext(ldap://exp-bdii.cern.ch:2170) ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP exp-bdii.cern.ch:2170 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 128.142.173.206:2170 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 ldap_open_defconn: successful ldap_send_server_request ber_flush: 14 bytes to sd 3 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_result msgid 1 ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL wait4msg (infinite timeout), msgid 1 wait4msg continue, msgid 1, all 1 ** Connections: * host: exp-bdii.cern.ch port: 2170 (default) refcnt: 2 status: Connected last used: Fri May 9 18:19:40 2008 ** Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL ldap_int_select read1msg: msgid 1, all 1 ber_get_next ---snip------ ldap_int_select read1msg: msgid -1, all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 82 03 57 02 01 02 64 0..W...d ldap_read: want=851, got=571 0000: 82 03 50 04 51 47 6c 75 65 43 6c 75 73 74 65 72 ..P.QGlueCluster 0010: 55 6e 69 71 75 65 49 44 3d 67 62 2d 63 65 2d 61 UniqueID=gb-ce-a 0020: 6d 63 2e 61 6d 63 2e 6e 6c 2c 4d 64 73 2d 56 6f mc.amc.nl,Mds-Vo 0030: 2d 6e 61 6d 65 3d 4c 53 47 2d 41 4d 43 2c 4d 64 -name=LSG-AMC,Md 0040: 73 2d 56 6f 2d 6e 61 6d 65 3d 6c 6f 63 61 6c 2c s-Vo-name=local, 0050: 6f 3d 67 72 69 64 30 82 02 f9 30 60 04 0b 6f 62 o=grid0...0`..ob 0060: 6a 65 63 74 43 6c 61 73 73 31 51 04 0e 47 6c 75 jectClass1Q..Glu 0070: 65 43 6c 75 73 74 65 72 54 6f 70 04 0b 47 6c 75 eClusterTop..Glu 0080: 65 43 6c 75 73 74 65 72 04 11 47 6c 75 65 53 63 eCluster..GlueSc 0090: 68 65 6d 61 56 65 72 73 69 6f 6e 04 16 47 6c 75 hemaVersion..Glu 00a0: 65 49 6e 66 6f 72 6d 61 74 69 6f 6e 53 65 72 76 eInformationServ 00b0: 69 63 65 04 07 47 6c 75 65 4b 65 79 30 25 04 0f ice..GlueKey0%.. 00c0: 47 6c 75 65 43 6c 75 73 74 65 72 4e 61 6d 65 31 GlueClusterName1 00d0: 12 04 10 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 ...gb-ce-amc.amc 00e0: 2e 6e 6c 30 71 04 12 47 6c 75 65 43 6c 75 73 74 .nl0q..GlueClust 00f0: 65 72 53 65 72 76 69 63 65 31 5b 04 2b 67 62 2d erService1[.+gb- 0100: 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e 6c 3a 32 31 ce-amc.amc.nl:21 0110: 31 39 2f 6a 6f 62 6d 61 6e 61 67 65 72 2d 70 62 19/jobmanager-pb 0120: 73 2d 6d 65 64 69 75 6d 04 2c 67 62 2d 63 65 2d s-medium.,gb-ce- 0130: 61 6d 63 2e 61 6d 63 2e 6e 6c 3a 32 31 31 39 2f amc.amc.nl:2119/ 0140: 6a 6f 62 6d 61 6e 61 67 65 72 2d 70 62 73 2d 65 jobmanager-pbs-e 0150: 78 70 72 65 73 73 30 29 04 13 47 6c 75 65 43 6c xpress0)..GlueCl 0160: 75 73 74 65 72 55 6e 69 71 75 65 49 44 31 12 04 usterUniqueID1.. 0170: 10 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e .gb-ce-amc.amc.n 0180: 6c 30 82 01 3a 04 0e 47 6c 75 65 46 6f 72 65 69 l0..:..GlueForei 0190: 67 6e 4b 65 79 31 82 01 26 04 18 47 6c 75 65 53 gnKey1..&..GlueS 01a0: 69 74 65 55 6e 69 71 75 65 49 44 3d 4c 53 47 2d iteUniqueID=LSG- 01b0: 41 4d 43 04 3a 47 6c 75 65 43 45 55 6e 69 71 75 AMC.:GlueCEUniqu 01c0: 65 49 44 3d 67 62 2d 63 65 2d 61 6d 63 2e 61 6d eID=gb-ce-amc.am 01d0: 63 2e 6e 6c 3a 32 31 31 39 2f 6a 6f 62 6d 61 6e c.nl:2119/jobman 01e0: 61 67 65 72 2d 70 62 73 2d 6d 65 64 69 75 6d 04 ager-pbs-medium. 01f0: 3b 47 6c 75 65 43 45 55 6e 69 71 75 65 49 44 3d ;GlueCEUniqueID= 0200: 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e 6c gb-ce-amc.amc.nl 0210: 3a 32 31 31 39 2f 6a 6f 62 6d 61 6e 61 67 65 72 :2119/jobmanager 0220: 2d 70 62 73 2d 65 78 70 72 65 73 73 04 18 47 6c -pbs-express..Gl 0230: 75 65 53 69 74 65 55 6e 69 71 75 ueSiteUniqu ber_get_next failed. wait4msg continue, msgid -1, all 0 ** Connections: * host: exp-bdii.cern.ch port: 2170 (default) refcnt: 2 status: Connected last used: Fri May 9 18:57:52 2008 ** Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty ldap_chkResponseList for msgid=-1, all=0 ldap_chkResponseList returns NULL ldap_int_select ldap_result: Can't contact LDAP server (-1) Thank you very much in advance

1 0

(ITS#5503) Openldap segmentation fault when running syncrepl.
by zulcss＠ubuntu.com 09 May '08

09 May '08

Full_Name: Chuck Short Version: 2.4.9 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.224.150.216) When running the following scripts openldap crashes when trying to run a syncrepl from a slave server. The original bug report can be found at: http://bugs.launchpad.net/bugs/227178. Steps to reproduce it: 1. Download the attachment in the bug report. 2. mkdir /home/amg1127/ 3. Unpack the attachment in the just created directory. 4. Run the ./create-master-base.sh script. 5. In one terminal run the run-master-slapd.sh script. 6. In another terminal create the run-slave-slapd.sh script. 7. The result will be a segmentation fault in the slave server. Thanks chuck

1 0

Re: (ITS#5500) comments in cn=config entries
by h.b.furuseth＠usit.uio.no 09 May '08

09 May '08

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> However the attribute for general notes ('info') should probably be >> treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient >> to do that with a preexisting attribute without that feature. The >> valsort overlay does, but I don' suggest to require valsort. > > The X-ORDERED flag obviously cannot be added to existing schema > elements; That's why I said "treated as" X-ORDERED (when occurring in cn=config). If that's too cumbersome though: > you need to define a new attribute. An attribute private to OpenLDAP should have a prefix like "olc", but an RFCed attribute must wait till (X-)ORDERED is standardized. I suggest "olc-note", then. Still stands out from the rest since the others do not use hyphens, and also sorts it before the other "olc"s. -- Hallvard

1 0

(ITS#5502) LDAP problem
by javed_ansari＠infosys.com 09 May '08

09 May '08

Full_Name: Javed Ansari Version: 2.3.30 OS: Sun URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.64.6) Since yesterday, we are facing LDAP problems while insertion of data. When we try to insert data in the ldap we get the following error: [LDAP: error code 80 - entry store failed] There however seems to be no problem with the login though, this occurs only during registration

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 08 May '08

08 May '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> As I recall, the only reason we needed the waking counter here was to >> make sure we never filled the pipe buffer, which would cause a >> single-threaded server to deadlock. We can simply set the pipe to >> nonblocking instead, and eliminate the counter. > > Sounds good... > >> The other point was that if there was already a pending wake event, >> there was no reason to write another one. > > Aha! Now the code makes more sense to me:-) And if 'waking' is > just a boolean flag, we can keep it as long as it is treated that way. > > #define WAKE_LISTENER(w) do { \ > if ((w)&& !waking) { \ > waking = 1; \ > tcp_write( SLAP_FD2SOCK(wake_sds[1]), "0", 1 ); \ > } \ > } while (0) > > I need to stare at it a bit to look for race conditions with readers. > I don't suggest to hold next RE24 for this though. It's hardly urgent, > and should be tested a bit --without-threads first. > Actually this can all be simplified even further if you're building --without-threads - in that case, the only WAKE_LISTENER call that matters is the one made from the signal handler. In every other case, the calling function will eventually return and fall back into the main event loop anyway. -- -- 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

(ITS#5501) syncprov/glue crash with RE24 CVS
by mark.cave-ayland＠siriusit.co.uk 08 May '08

08 May '08

Full_Name: Mark Cave-Ayland Version: 2.4.8cvs-RE24-2008-05-06 OS: RHEL4, x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.197.142) Hi there, We've located a segfault in openldap 2.4.8cvs RE24 branch from 2 days ago (which we believe is almost exactly the same as the 2.4.9 release) when using a combination of glue/syncprov. Details from the slapd log and the gdb core file can be found here: http://pastebin.siriusit.co.uk/openldap-bug-20080508.txt More information from the gdb core file can be obtained upon request. Many thanks, Mark.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 08 May '08

08 May '08

Le Jeu 8 mai 2008 00:03, Howard Chu a écrit : > raphael.ouazana(a)linagora.com wrote: >> It is not really hung, it is more in an infinite loop. > > Nothing in this trace indicates a loop; all of the threads are in wait > states. > Is there anything in the logs that indicates a loop? Yes, at least two things: - one CPU is about at 100% - logs from slapd.1.log and slapd.2.log are slowly increasing It seems to be an infinite loop between the first slapd and the second slapd, where the second is always active. I'm sorry I won't be able to access the logs until Tuesday, and all the processes are now killed. Regards, Raphaël Ouazana.

1 0

Re: (ITS#5500) comments in cn=config entries
by hyc＠symas.com 08 May '08

08 May '08

h.b.furuseth(a)usit.uio.no wrote: > One problem with back-config is that comments in slapd.conf > are lost when converting to cn=config, and cn=config does > not offer attributes in which to put comments. So I suggest: > > Add something like 'MAY ( description $ info )' to object class > olcConfig, and slapd.conf keywords with the same name. description > to describe the slapd entry, info for other notes about it. > > The slapd.conf keywords would allow admins to "upgrade" most comments in > slapd.conf before converting to cn=config. They'll need to insert any > context into the comments though, and preferably move frontend directives > with comments in slapd.conf to an explicit frontend database. > > I think it'd be best if these attribute names do not have a prefix > like "olc", so they'll stand out a bit from the rest. Thus the > suggestion to stick to preexisting RFCed attributes. However the > attribute for general notes ('info') should probably be treated as > X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do > that with a preexisting attribute without that feature. The valsort > overlay does, but I don' suggest to require valsort. The X-ORDERED flag obviously cannot be added to existing schema elements; you need to define a new attribute. -- -- 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#5470) Sporadic failures with RE24
by hyc＠symas.com 08 May '08

08 May '08

raphael.ouazana(a)linagora.com wrote: > It is not really hung, it is more in an infinite loop. Nothing in this trace indicates a loop; all of the threads are in wait states. Is there anything in the logs that indicates a loop? -- -- 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

(ITS#5500) comments in cn=config entries
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard One problem with back-config is that comments in slapd.conf are lost when converting to cn=config, and cn=config does not offer attributes in which to put comments. So I suggest: Add something like 'MAY ( description $ info )' to object class olcConfig, and slapd.conf keywords with the same name. description to describe the slapd entry, info for other notes about it. The slapd.conf keywords would allow admins to "upgrade" most comments in slapd.conf before converting to cn=config. They'll need to insert any context into the comments though, and preferably move frontend directives with comments in slapd.conf to an explicit frontend database. I think it'd be best if these attribute names do not have a prefix like "olc", so they'll stand out a bit from the rest. Thus the suggestion to stick to preexisting RFCed attributes. However the attribute for general notes ('info') should probably be treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do that with a preexisting attribute without that feature. The valsort overlay does, but I don' suggest to require valsort.

1 0

Re: (ITS#5499) slapd-perl man page
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

I wrote: > + * bind DN, or "" for anonymous bind Duh, sorry. Anonymous bind is handled by the frontend, of course. -- Hallvard

1 0

Re: (ITS#5499) slapd-perl man page
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Alexander.lelyakin(a)googlemail.com writes: > Man page slapd-perl does not contain ANY information on 'bind' method. Wow. That doc is 9 years old and you are the first to notice. Thanks for the report. > Also it is not clear: Is there any possibility for perl backend to get > connection information, for example IP addres of client (for > implementation own access control schemes). No. Except for Bind, what you see in the manpage is what you get. Also the manpage should mention LDIF format for Search entries. Like this, I think - but I (or someone) needs to test before committing. Index: doc/man/man5/slapd-perl.5 =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/doc/man/man5/slapd-perl.5,v retrieving revision 1.7 diff -u -2 -r1.7 doc/man/man5/slapd-perl.5 --- doc/man/man5/slapd-perl.5 4 Jul 2005 04:57:11 -0000 1.7 +++ doc/man/man5/slapd-perl.5 7 May 2008 17:01:30 -0000 @@ -24,4 +24,5 @@ .nf * new # creates a new object, + * bind # does a simple bind, * search # performs the ldap search, * compare # does a compare, @@ -52,4 +53,15 @@ method receives the class name as argument. .TP +.B bind +This method is called when the client requests a Simple Bind, +except Simple Bind as the rootdn when rootpw is set in slapd.conf. +Its arguments are as follows. +.nf + * object reference + * bind DN, or "" for anonymous bind + * password, or "" for no password +.fi +.LP +.TP .B search This method is called when a search request comes from a client. @@ -68,4 +80,8 @@ .LP Return value: (resultcode, ldif-entry, ldif-entry, ...) + +Each ldif-entry is a string starting with "dn:" in +.BR ldif (5) +format. .TP .B compare @@ -96,5 +112,5 @@ .nf * object reference - * entry in string format + * entry record in \fBldif\fP(5) string format .fi .LP @@ -187,3 +203,4 @@ .BR slapd.conf (5), .BR slapd (8), -.BR perl (1). +.BR perl (1), +.BR ldif (5). -- Hallvard

1 0

Re: (ITS#5497) back-sql with base64 encoded attributes
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Pavel Kislinger writes: > This is an imperfection of back-sql. It doesn't exist any way > how to say to slapd, which attributes are base64 encoded. No. base64 has nothing to do with attribute definitions, nor with anything else in LDAP except the LDIF file format. (Some backends make use of the LDIF format internally instead of a more efficient format. What you just said is that back-sql is not one of them.) So: > (...) It doesn't matter, no LDIF file is imported to back-sql. Exactly. Looks to me like you need to read up on LDAP and LDIF. E.g. the LDAP wikipedia article. Then, if you still have trouble, please take this to the openldap-software list. -- Hallvard

1 0

(ITS#5499) slapd-perl man page
by Alexander.lelyakin＠googlemail.com 07 May '08

07 May '08

Full_Name: Alexander Lelyakin Version: Any OS: linux URL: Submission from: (NULL) (141.52.232.84) Man page slapd-perl does not contain ANY information on 'bind' method. Also it is not clear: Is there any possibility for perl backend to get connection information, for example IP addres of client (for implementation own access control schemes).

1 0

Re: (ITS#5497) back-sql with base64 encoded attributes
by kislinger＠kn.vutbr.cz 07 May '08

07 May '08

This is an imperfection of back-sql. It doesn't exist any way how to say to slapd, which attributes are base64 encoded. Here are configuration files, that I am using. Look at "cn", "sn" attributes in "usi.sql" especialy. advanced schemas: http://printer.kn.vutbr.cz/~orim/dbmail.schema http://printer.kn.vutbr.cz/~orim/usi.schema SQL scripts http://printer.kn.vutbr.cz/~orim/ldap.sql backsql_create.sql http://printer.kn.vutbr.cz/~orim/usi.sql slapd.conf http://printer.kn.vutbr.cz/~orim/slapd.conf Hallvard B Furuseth napsal(a): > Please use the mailinglist (openldap-source and -technical) for > questions about using the software. This does not look like a bug, > which is what the ITS system is for. This ITS will be closed. > > Since I'm writing anyway though: > Textual attributes in LDAP are as UTF-8. I'm not sure what chacter > encoding you are using, but I assume it't something else. > utf-8 > As for base64, that's merely part of the LDIF file format, not how the > value is represented in LDAP (nor SQL I presume). The '::' after the > attribute names tells the client which reads the LDIF to base64-decode > the provided value. > > It doesn't matter, no LDIF file is imported to back-sql. Record are inserted into MySQL (4 metadata tables).

1 0

Re: (ITS#5498) "Issue Tracking" -> "Bugs" @ webpage
by Kurt＠OpenLDAP.org 07 May '08

07 May '08

On May 7, 2008, at 7:12 AM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > I suggest the "Issue Tracking" link on on http://www.openldap.org is > renamed to "Bugs" or "Bugs/patches". A user problem is after all an > "issue" too, and obviously they don't all read the text in later text > about what kind of issues ITS is for. > > "Bugs" is also wrong (incomplete), but I expect most people are used > to > looking under Bugs about enhancements/contributions. > > I'm sure this has been mentioned before, but I couldn't find where > or if > anything came of it. No matter it is called, some users will file user problems using the system. I seriously doubt renaming the issue tracker to something else will significant reduce these instances. -- Kurt

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 07 May '08

07 May '08

Hi, Le Mer 7 mai 2008 16:11, Quanah Gibson-Mount a écrit : > --On Wednesday, May 07, 2008 12:44 PM +0000 raphael.ouazana(a)linagora.com > wrote: > >> Currently testing new RE24. I have now a slapd process stuck at 100% : >> \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb >> \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h >> ldap://localhost:9011/ -d 261 >> \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h >> ldap://localhost:9012/ -d 261 >> \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h >> ldap://localhost:9013/ -d 261 >> \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb >> \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H >> ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni >> Association,ou=People,dc=example,dc=com (objectClass=*) >> \_ awk /^dn:/ {print "OK"} >> >> Do you need some debugging info (strace, gdb, log, or other) ? > > Please provide a gdb backtrace of the hung process. It is not really hung, it is more in an infinite loop. Here is the backtrace: (gdb) thread apply all bt Thread 5 (Thread 0xb7ad5b90 (LWP 6028)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7d14676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x080600bb in slapd_daemon_task (ptr=0x0) at daemon.c:2281 #3 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread 0xb76d4b90 (LWP 6030)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da9aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0807302b in send_ldap_ber (conn=0xb7ad6b28, ber=0xb76d2e98) at result.c:188 #3 0x08075256 in slap_send_search_entry (op=0x8252af0, rs=0xb76d4178) at result.c:1200 #4 0x08056418 in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x828bf48, depth=0) at bconfig.c:3507 #5 0x080563e4 in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x828bf48, depth=1) at bconfig.c:3516 #6 0x080563be in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x82527c0, depth=0) at bconfig.c:3511 #7 0x080563e4 in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x82527c0, depth=1) at bconfig.c:3516 #8 0x080563be in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x824fc80, depth=0) at bconfig.c:3511 #9 0x080564e4 in config_back_search (op=0x8252af0, rs=0xb76d4178) at bconfig.c:5261 #10 0x08065283 in fe_op_search (op=0x8252af0, rs=0xb76d4178) at search.c:366 #11 0x08065af7 in do_search (op=0x8252af0, rs=0xb76d4178) at search.c:217 #12 0x0806312f in connection_operation (ctx=0xb76d4248, arg_v=0x8252af0) at connection.c:1084 #13 0x080639bf in connection_read_thread (ctx=0xb76d4248, argv=0x8) at connection.c:1211 #14 0x0812fb48 in ldap_int_thread_pool_wrapper (xpool=0x822cae8) at tpool.c:663 #15 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #16 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb71d2b90 (LWP 6034)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da9aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0812fbb5 in ldap_int_thread_pool_wrapper (xpool=0x822cae8) at tpool.c:654 #3 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb6dd1b90 (LWP 6035)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da9aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0812f4c2 in handle_pause (tpool=<value optimized out>, do_pause=1) at tpool.c:738 #3 0x08054abf in config_back_add (op=0xb6dd0dd4, rs=0xb6dd0728) at bconfig.c:4548 ---Type <return> to continue, or q <return> to quit--- #4 0x080bb70f in syncrepl_entry (si=0x8255888, op=0xb6dd0dd4, entry=0x823ffec, modlist=0xb6dd0b44, syncstate=1, syncUUID=0xb6dd0b0c, syncCSN=0x0) at syncrepl.c:2108 #5 0x080be0d9 in do_syncrep2 (op=0xb6dd0dd4, si=0x8255888) at syncrepl.c:862 #6 0x080bfec4 in do_syncrepl (ctx=0xb6dd1248, arg=0x8255ac8) at syncrepl.c:1276 #7 0x08063a06 in connection_read_thread (ctx=0xb6dd1248, argv=0x9) at connection.c:1213 #8 0x0812fb48 in ldap_int_thread_pool_wrapper (xpool=0x822cae8) at tpool.c:663 #9 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb7c3c6b0 (LWP 6024)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da6775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0805d633 in slapd_daemon () at daemon.c:2644 #3 0x0804c597 in main (argc=8, argv=0xbfaefcc4) at main.c:946 #0 0xb7eef410 in __kernel_vsyscall () (gdb) Regards, Raphaël Ouazana.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by quanah＠zimbra.com 07 May '08

07 May '08

--On Wednesday, May 07, 2008 12:44 PM +0000 raphael.ouazana(a)linagora.com wrote: > Currently testing new RE24. I have now a slapd process stuck at 100% : > \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb > \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h > ldap://localhost:9011/ -d 261 > \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h > ldap://localhost:9012/ -d 261 > \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h > ldap://localhost:9013/ -d 261 > \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb > \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H > ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni > Association,ou=People,dc=example,dc=com (objectClass=*) > \_ awk /^dn:/ {print "OK"} > > Do you need some debugging info (strace, gdb, log, or other) ? Please provide a gdb backtrace of the hung process. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5498) "Issue Tracking" -> "Bugs" @ webpage
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard I suggest the "Issue Tracking" link on on http://www.openldap.org is renamed to "Bugs" or "Bugs/patches". A user problem is after all an "issue" too, and obviously they don't all read the text in later text about what kind of issues ITS is for. "Bugs" is also wrong (incomplete), but I expect most people are used to looking under Bugs about enhancements/contributions. I'm sure this has been mentioned before, but I couldn't find where or if anything came of it.

1 0

Re: (ITS#5497) back-sql with base64 encoded attributes
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Please use the mailinglist (openldap-source and -technical) for questions about using the software. This does not look like a bug, which is what the ITS system is for. This ITS will be closed. Since I'm writing anyway though: Textual attributes in LDAP are as UTF-8. I'm not sure what chacter encoding you are using, but I assume it't something else. As for base64, that's merely part of the LDIF file format, not how the value is represented in LDAP (nor SQL I presume). The '::' after the attribute names tells the client which reads the LDIF to base64-decode the provided value. -- Hallvard

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 07 May '08

07 May '08

Hi, Le Lun 5 mai 2008 23:08, Howard Chu a écrit : > The logs show that the syncrepl consumers all timed out periodically, when > trying to bind to a provider. It seems that using a 1 second timeout in > the > syncrepl configs is too short, or your test machine was too slow during > that run. > > Probably we should remove that timeout now, since the cn=config/thread > pause > issue has already been resolved. Currently testing new RE24. I have now a slapd process stuck at 100% : \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h ldap://localhost:9011/ -d 261 \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9012/ -d 261 \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9013/ -d 261 \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com (objectClass=*) \_ awk /^dn:/ {print "OK"} Do you need some debugging info (strace, gdb, log, or other) ? Regards, Raphael Ouazana.

1 0

(ITS#5497) back-sql with base64 encoded attributes
by kislinger＠kn.vutbr.cz 07 May '08

07 May '08

Full_Name: Pavel Kislinger Version: 2.4.8 OS: Freebsd 6.3 Stable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.229.202.76) I am using this packages: openldap-server-2.4.8_1 openldap-client-2.4.8 mysql-client-5.0.51a unixODBC-2.2.12_4 mysql-connector-odbc-unixodbc-mysql50-3.51.12_1 I have records with diacritics (czech language) like name or surname in SQL. +-------+---------------+-----------+ | vutid | name | surname | +-------+---------------+-----------+ | 1 | Pavel | Kislinger | | 2 | Michhěčřýíé | abáček | +-------+---------------+-----------+ First record in SQL correspond to record in LDAP. Second record with diacritics doesn't works. # 1, users, test.vutbr.cz dn: uid=1,ou=users,dc=test,dc=vutbr,dc=cz objectClass: usi cn: Pavel Kislinger sn: Kislinger givenName: Pavel uid: 1 Solution of this problem is base64 encoding of attributes. "cn" for second record "Michhěčřýíé abáček" could be: cn:: eHhNaWNoaOy56Pi+/e3pYWx4eCBLaXNsaW5nZXI= I wrote MySQL function base64_encoding and adjusted table ldap_attr_mapping for "cn": insert into ldap_attr_mappings (<list of columns>) values (114,3,'cn',"base64_encode(concat(users.name,' ',users.surname))",'users',NULL,NULL,NULL,3,0); the result in ldap is: cn: eHhNaWNoaOy56Pi+/e3pYWx4eCBLaXNsaW5nZXI= This value is false recognized by ldap clients (outlook, thunderbird) as string "eHhN..." instead of "Michhěčřýíé abáček" How can I mark "cn" attribute in SQL, that this attribute is encoded by base64?

1 0

Re: (ITS#5495) cpu consuption
by quanah＠zimbra.com 07 May '08

07 May '08

--On Monday, May 05, 2008 6:07 AM +0000 naga.gangadhar(a)gmail.com wrote: > Full_Name: Naga Gangadhar Reddy > Version: 2.4.19 > OS: cent-os > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.212.208.159) There's no evidence of a bug here. Please submit questions about how to configure and use OpenLDAP to the Openldap software list. I will also note that there is no such OpenLDAP release as "2.4.19". Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5494) slapd crashed when accessed by multiple threads
by adejong＠debian.org 06 May '08

06 May '08

--=-6tNxv4Jql6LXRCulK2og Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-05-05 at 18:30 -0700, Howard Chu wrote: > This is most likely the same as ITS#5439, fixed in HEAD/RE24/2.4.9. > Please test against a more recent release. I have used a cvs version: cvs -d :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP -z3 \ checkout -P -rOPENLDAP_REL_ENG_2_4_9 openldap and configured it with: ./configure --prefix=3D/opt/openldap-cvs-2.4.9 --enable-local \ --enable-slapd --enable-aci --enable-cleartext --enable-crypt \ --disable-lmpasswd --enable-spasswd --enable-slapi --enable-slp \ --enable-wrappers --enable-backends=3Dmod --enable-ldbm=3Dno \ --enable-overlays=3Dmod --with-subdir=3Dldap --with-cyrus-sasl \ --with-threads --with-tls=3Dgnutls --with-odbc=3Dunixodbc \ --enable-perl=3Dno and have not been able to trigger a crash with it so I would think that it is fixed in that version. Thanks. --=20 -- arthur - adejong(a)debian.org - http://people.debian.org/~adejong -- --=-6tNxv4Jql6LXRCulK2og Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIIMnRVYan35+NCKcRArkpAKCYd7ndeUHUsgQtj0loLAOJZYKDTgCgk37K C4gfQFwljJKeGhYkY7gWnq0= =YSTk -----END PGP SIGNATURE----- --=-6tNxv4Jql6LXRCulK2og--

1 0

Re: (ITS#5494) slapd crashed when accessed by multiple threads
by hyc＠symas.com 06 May '08

06 May '08

This is most likely the same as ITS#5439, fixed in HEAD/RE24/2.4.9. Please test against a more recent release. adejong(a)debian.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.7 > OS: Debian unstable > URL: http://arthurenhella.demon.nl/nss-ldapd/adejong-slapd-crash.log > Submission from: (NULL) (83.160.165.27) > > > This has also been submitted as a Debian bug: > http://bugs.debian.org/479237 > > My test slapd consistently crashes when doing multiple simultaneous > requests in different threads. Each thread has it's own LDAP *ld > connection to the LDAP server which is supposed to be supported [1]. In > any case this shouldn't crash the LDAP server. > > [1] http://www.openldap.org/lists/openldap-software/200606/msg00252.html > > This problem arises in my test suite for nss-ldapd. Source can be > checked out at http://arthurenhella.demon.nl/svn/nss-ldapd/ (svn) and > the test file is (test/test_myldap.c). It uses a wrapper module (myldap) > around calls to OpenLDAP to simplify memory management. The function > that triggers the crash is test_threads(). > > I have captured the crash in gdb: > > # gdb /usr/sbin/slapd > GNU gdb 6.8-debian > [...] > This GDB was configured as "i486-linux-gnu"... > (gdb) r -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f > /etc/ldap/slapd.conf > Starting program: /usr/sbin/slapd -d 1 -h ldap:/// ldaps:/// ldapi:/// -g > openldap -u openldap -f /etc/ldap/slapd.conf > [Thread debugging using libthread_db enabled] > [New Thread 0xb7b3a930 (LWP 1542)] > @(#) $OpenLDAP: slapd 2.4.7 (Apr 16 2008 08:13:31) $ > @minerva.hungry.com:/home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/debian/build/servers/slapd > ldap_pvt_gethostbyname_a: host=sorbet, r=0 > daemon_init: listen on ldap:/// > daemon_init: 1 listeners to open... > [...] > <= send_search_entry: conn 2 exit. > entry_decode: "cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld" > <= entry_decode(cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld) > => send_search_entry: conn 2 dn="cn=Zaka > Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld" > ber_flush2: 107 bytes to sd 18 > <= send_search_entry: conn 2 exit. > entry_decode: "uid=wvakil,ou=lotsofpeople,dc=test,dc=tld" > <= entry_decode(uid=wvakil,ou=lotsofpeople,dc=test,dc=tld) > => send_search_entry: conn 2 dn="uid=wvakil,ou=lotsofpeople,dc=test,dc=tld" > ber_flush2: 90 bytes to sd 18 > <= send_search_entry: conn 2 exit. > entry_decode: "uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld" > <= entry_decode(uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld) > => send_search_entry: conn 2 dn="uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld" > ber_flush2: 92 bytes to sd 18 > <= send_search_entry: conn 2 exit. > bdb_search: 1104 scope not okay > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb5f18b90 (LWP 5017)] > 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 > (gdb) bt > #0 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 > #1 0xb7f4351d in ldap_pvt_thread_mutex_lock () from > /usr/lib/libldap_r-2.4.so.2 > #2 0xb783883d in bdb_cache_return_entry_rw (bdb=0x81ea358, e=0x820922c, rw=0, > lock=0xb5f16fd4) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/cache.c:256 > #3 0xb782ce12 in bdb_search (op=0x8299b10, rs=0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/search.c:909 > #4 0x08077d13 in fe_op_search (op=0x8299b10, rs=0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:368 > #5 0x0807853c in do_search (op=0x8299b10, rs=0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:217 > #6 0x080757c6 in connection_operation (ctx=0xb5f18248, arg_v=0x8299b10) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1083 > #7 0x08075ed6 in connection_read_thread (ctx=0xb5f18248, argv=0x13) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1210 > #8 0xb7f42a44 in ?? () from /usr/lib/libldap_r-2.4.so.2 > #9 0xb5f18248 in ?? () > #10 0x00000013 in ?? () > #11 0x00000000 in ?? () > > A more detailed backtrace is available at the url specified below. > > > -- -- 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#5470) Sporadic failures with RE24
by hyc＠symas.com 05 May '08

05 May '08

Raphaël Ouazana-Sustowski wrote: > Hi, > > Le Ven 2 mai 2008 11:01, hyc(a)symas.com a écrit : >> luca(a)OpenLDAP.org wrote: >>> luca(a)OpenLDAP.org wrote: >>>> This is a multi-part message in MIME format. >>>> --------------080809000906010300090306 >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Howard Chu wrote: >>>> >>>>> Thanks. Please try HEAD again. >>>>> >>>> No way. >>>> new testrun directory in >>>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >>>> >>>> backtrace attached >>>> >>> recent commits seem to have fixed it (at least, right now I'm not able >>> to reproduce it anymore...) >> Right. Confirmed here too; I (temporarily) added an assert(0) to the >> offending >> branch of code to make sure the patch was actually getting hit. It takes a >> very particular timing to trigger that code path. >> >> I'm not sure how we can reliably test for this down the road. Perhaps we >> should add a "disabled" config keyword for backends and syncrepl >> consumers, so >> that we can start up the individual servers, (which takes an unpredictable >> amount of time for each) and then enable various parts in a fixed sequence >> (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit >> or >> miss, because our test database is so small it's unlikely that we can hit >> the >> window of time on demand. > > I'm testing the last RE24 tag. After 201 successful runs of test050, I got > a failure :/ > Cleaning up test run directory leftover from previous run. > Running ./scripts/test050-syncrepl-multimaster... > running defines.sh > Initializing server configurations... > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > Starting consumer2 slapd on TCP/IP port 9013... > Using ldapsearch to check that consumer2 slapd is running... > Configuring syncrepl on consumer2... > Adding schema and databases on producer... > Using ldapadd to populate producer... > Waiting 20 seconds for syncrepl to receive changes... > Using ldapadd to populate consumer... > Waiting 20 seconds for syncrepl to receive changes... > Using ldapsearch to check that syncrepl received database changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > ldapsearch failed (32)! > > testrun uploaded in > ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-080505.tgz The logs show that the syncrepl consumers all timed out periodically, when trying to bind to a provider. It seems that using a 1 second timeout in the syncrepl configs is too short, or your test machine was too slow during that run. Probably we should remove that timeout now, since the cn=config/thread pause issue has already been resolved. -- -- 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#5488) syncrepl received contextCSN not passed on to syncprov consumers
by rein＠OpenLDAP.org 05 May '08

05 May '08

On Sun, 4 May 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: >> On Wed, 30 Apr 2008, Howard Chu wrote: >>> rein(a)OpenLDAP.org wrote: >>>> My first attempt at fixing this was to change syncprov to fetch the >>>> queued csn values from the glue backend where it was used. But that >>>> failed as other modules queues the csn values in their own backend when >>>> they changes things. >>> What other modules? Generally there cannot be any other sources of changes. >> >> Sorry, I should have written other configurations. The CSNs gets queued >> in the subordinate database when syncrepl is used there, or not at all >> (i.e in regular updates that comes in through the frontend). > > OK, but that's again quite a special case. I.e., that's multi-master; in the > default (single-master) case there cannot be regular updates arriving through > the frontend. When a single-master syncrepl consumer is configured, that is > the only possible source of updates. Let's be sure we've solved this question > for the single-master case first, before addressing the multi-master case. No, I'm thinking about single-master glued configurations where either: 1) The server is the single master for the subordinate backend or 2) The server is a syncrepl consumer for the subordinate backend, and syncrepl is configured on the subordinate db. In both cases is the CSN values queued in the subordinate database where syncprov looks for the values. The case that don't work is when syncrepl and syncprov are both used on the glue database, but still in single-master mode (although I don't think that matter). I.e, this server acts like a kind of forwarding server, it replicates the changes it receives from its producer to its own consumers. In this case syncrepl queues the CSN values in the glue database, while syncprov still looks for them in the subordinate database where the actual changes are made. > While it's expected that the software will be able to handle multiple glued > DBs and multi-master across them, I seriously doubt that anyone out there > actually knows how to configure and maintain such a setup yet. I haven't looked at multi-master yet, although I have multiple master servers that replicate between each other. But each backend database has a clearly defined single master, so this is not what I think about as multi-master configurations. >>>> Instead I changed ctxcsn.c so that it always >>>> queues them in the glue backend where syncprov is used. But I don't >>>> feel that my understanding of this stuff is good enough to be sure that >>>> this is the optimal solution.. >>> I definitely don't like references to the syncprov overlay appearing in main >>> slapd code like that. We need a different solution. > >> To me it makes sense to have a single queue of CSN values in a glued >> configuration, no matter if or where syncprov is used. > > Yes, I can probably go along with that. The downside is that it may reduce > write concurrency a bit, compared to a glued configuration where each glued DB > is otherwise independent. Which again should imply that the best fix probably is to change syncrepl so that it queues the csn values in the backends where the changes are made? >> Another approach could be to have syncprov look in the glue database if >> it fails to find any queued CSN in a subordinate db. I haven't tested >> it, but that should work in both configurations. It should also remove >> the need to always look for the glue db which my patch requires. Would >>> that be better? > > That sounds like a decent alternative. A new patch that implements this is at the end. Is this OK or should we go for the syncrepl alternative instead? >>>> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >>>> test, should that have included an overlay_is_inst() clause as well? >>> Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on >>> that call. > >> The current test (introduced to fix ITS#5433) causes the contextCSN to >> be written to the glue database when syncprov is used on a subordinate >> db, which appears wrong to me. > > Understood. > > Again, the question is whether the admin intended to configure a single > syncprov over an entire glued DB, or individual syncprovs over each component > of the glued tree. The distinction is vital, and it's detected based on > whether the syncprov overlay is above the glue overlay in the overlay stack, > or below it, on the topmost DB. Yes, the first case is what I'm using, it works with the current code. The second is what I'm afraid got broken by this patch. Although I haven't tried the second type, so I'm not sure.. >> Could you elaborate on when op->o_bd->bd_self must be used instead of >> op->o_bd? I understand that op->o_bd may be a copy of the original >> structure that op->o_bd->bd_self refers to, but I'm not sure when it >> must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch >> the BackendInfo that can be used to call the top-most bd_search (and >> similar) also in overlays? > > If you read the code for overlay_is_inst() it should be obvious - that > function only works when used with a real BackendDB structure. The local copy > structure has had its bd_info replaced with whatever on_inst structure > corresponds to the current overlay. OK, I understand that one. I had hoped for a general rule, but am afraid that can't be given. And if we should continue this discussion I guess it's time to move it to openldap-devel. > Yes, the bd_self points to the topmost structure, so you can use it for > be_search. Much of what's happening in these overlays was intended to avoid > starting over at the top though, because the code is already running in the > desired overlay context. Ah, good. Using that is much clearer than to cast op->o_bd->bd_info into an overinst pointer and fetching it there :-) Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.20 diff -u -u -r1.20 syncprov.c --- OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 17:45:38 -0000 1.20 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 20:58:35 -0000 @@ -1589,6 +1589,17 @@ cbuf[0] = '\0'; ldap_pvt_thread_rdwr_wlock( &si->si_csn_rwlock ); slap_get_commit_csn( op, &maxcsn ); + if ( BER_BVISNULL( &maxcsn ) && SLAP_GLUE_SUBORDINATE( op->o_bd )) { + /* syncrepl queues the CSN values in the db where + * it is configured , not where the changes are made. + * So look for a value in the glue db if we didn't + * find any in this db. + */ + BackendDB *be = op->o_bd; + op->o_bd = select_backend( &be->be_nsuffix[0], 1); + slap_get_commit_csn( op, &maxcsn ); + op->o_bd = be; + } if ( !BER_BVISNULL( &maxcsn ) ) { int i, sid; strcpy( cbuf, maxcsn.bv_val );

1 0

Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by rein＠OpenLDAP.org 05 May '08

05 May '08

On Sun, 4 May 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: >> A new patch that I hope should fix this is at the end. It always use >> be_search, after putting back the original bd_info if needed. I feel >> that using the generic be_search is better than interfering directly >> with the overlay code as overlay_op_walk does. I also tested for >> SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more >> generic to me. But again, I may be totally wrong here. Does this >> patch look better? > > SLAP_IS_OVERLAY will never be true here. That flag is only set when the > BackendDB being tested is a local copy of a real BackendDB structure. The > structure referenced in s_op is always a real BackendDB. No, it is true when syncprov_findbase is called from syncprov_op_search, as s_op is the op passed to that function. The new patch at the end uses o_bd->bd_self, which should eliminate this test since copying the db is not necessary. > In fact, if you're always going to use s_op and be_search, there's no > further work needed, because the regular overlay infrastructure will > always make a new local BackendDB copy itself. (And of course, some of > that would be wasted effort, which is why the original code uses > overlay_op_walk. Since op->o_bd is already an overlay DB, there's no > need to make yet another copy for the first-search case.) I understand, but I still prefer the clarity of always using be_search. After all, this function is only called the first time a consumer is initialized or after an update of the search base entry. I.e the few extra cycles shouldn't be measurable, even when the search base is the glue suffix where updates of the contextCSN causes the entry to be written more often than most other entries. Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.1.1.18 retrieving revision 1.20 diff -u -u -r1.1.1.18 -r1.20 --- OpenLDAP/servers/slapd/overlays/syncprov.c 30 Apr 2008 11:17:58 -0000 1.1.1.18 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 17:45:38 -0000 1.20 @@ -404,7 +404,6 @@ slap_callback cb = {0}; Operation fop; SlapReply frs = { REP_RESULT }; - BackendInfo *bi; int rc; fc->fss->s_flags ^= PS_FIND_BASE; @@ -412,11 +411,10 @@ fop = *fc->fss->s_op; + fop.o_bd = fop.o_bd->bd_self; fop.o_hdr = op->o_hdr; - fop.o_bd = op->o_bd; fop.o_time = op->o_time; fop.o_tincr = op->o_tincr; - bi = op->o_bd->bd_info; cb.sc_response = findbase_cb; cb.sc_private = fc; @@ -434,8 +432,7 @@ fop.ors_filter = &generic_filter; fop.ors_filterstr = generic_filterstr; - rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info = bi; + rc = fop.o_bd->be_search( &fop, &frs ); } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase = 1;

1 0

(ITS#5496) delta-syncrepl consumers don't update backend contextCSN after processing each entry
by jwm＠horde.net 05 May '08

05 May '08

Full_Name: John Morrissey Version: 2.3.41 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) delta-syncrepl does not update the backend's contextCSN after processing each replication event. This exposes slapd to problems in the event of a power loss, crash, etc. as it will attempt to re-process the replication entries once re-started. Relevant thread on openldap-software starts here: http://marc.info/?l=openldap-software&m=120965853100883&w=2 and Howard's summary of the behavior is here: http://marc.info/?l=openldap-software&m=120967526528453&w=2

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 05 May '08

05 May '08

Hi, Le Ven 2 mai 2008 11:01, hyc(a)symas.com a écrit : > luca(a)OpenLDAP.org wrote: >> luca(a)OpenLDAP.org wrote: >>> This is a multi-part message in MIME format. >>> --------------080809000906010300090306 >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Howard Chu wrote: >>> >>>> Thanks. Please try HEAD again. >>>> >>> No way. >>> new testrun directory in >>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >>> >>> backtrace attached >>> >> recent commits seem to have fixed it (at least, right now I'm not able >> to reproduce it anymore...) > > Right. Confirmed here too; I (temporarily) added an assert(0) to the > offending > branch of code to make sure the patch was actually getting hit. It takes a > very particular timing to trigger that code path. > > I'm not sure how we can reliably test for this down the road. Perhaps we > should add a "disabled" config keyword for backends and syncrepl > consumers, so > that we can start up the individual servers, (which takes an unpredictable > amount of time for each) and then enable various parts in a fixed sequence > (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit > or > miss, because our test database is so small it's unlikely that we can hit > the > window of time on demand. I'm testing the last RE24 tag. After 201 successful runs of test050, I got a failure :/ Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! testrun uploaded in ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-080505.tgz Regards, Raphaël Ouazana.

1 0

(ITS#5495) cpu consuption
by naga.gangadhar＠gmail.com 05 May '08

05 May '08

Full_Name: Naga Gangadhar Reddy Version: 2.4.19 OS: cent-os URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.212.208.159) slapd is taking 100% cpu though the memory consumption is just 0.9%.

1 0

Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by hyc＠symas.com 04 May '08

04 May '08

Rein Tollevik wrote: > On Wed, 30 Apr 2008, Howard Chu wrote: >> rein(a)OpenLDAP.org wrote: >>> My first attempt at fixing this was to change syncprov to fetch the >>> queued csn values from the glue backend where it was used. But that >>> failed as other modules queues the csn values in their own backend when >>> they changes things. >> What other modules? Generally there cannot be any other sources of changes. > > Sorry, I should have written other configurations. The CSNs gets queued > in the subordinate database when syncrepl is used there, or not at all > (i.e in regular updates that comes in through the frontend). OK, but that's again quite a special case. I.e., that's multi-master; in the default (single-master) case there cannot be regular updates arriving through the frontend. When a single-master syncrepl consumer is configured, that is the only possible source of updates. Let's be sure we've solved this question for the single-master case first, before addressing the multi-master case. While it's expected that the software will be able to handle multiple glued DBs and multi-master across them, I seriously doubt that anyone out there actually knows how to configure and maintain such a setup yet. >>> Instead I changed ctxcsn.c so that it always >>> queues them in the glue backend where syncprov is used. But I don't >>> feel that my understanding of this stuff is good enough to be sure that >>> this is the optimal solution.. >> I definitely don't like references to the syncprov overlay appearing in main >> slapd code like that. We need a different solution. > To me it makes sense to have a single queue of CSN values in a glued > configuration, no matter if or where syncprov is used. Yes, I can probably go along with that. The downside is that it may reduce write concurrency a bit, compared to a glued configuration where each glued DB is otherwise independent. > Another approach could be to have syncprov look in the glue database if > it fails to find any queued CSN in a subordinate db. I haven't tested > it, but that should work in both configurations. It should also remove > the need to always look for the glue db which my patch requires. Would > that be better? That sounds like a decent alternative. >>> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >>> test, should that have included an overlay_is_inst() clause as well? >> Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on >> that call. > The current test (introduced to fix ITS#5433) causes the contextCSN to > be written to the glue database when syncprov is used on a subordinate > db, which appears wrong to me. Understood. Again, the question is whether the admin intended to configure a single syncprov over an entire glued DB, or individual syncprovs over each component of the glued tree. The distinction is vital, and it's detected based on whether the syncprov overlay is above the glue overlay in the overlay stack, or below it, on the topmost DB. > Could you elaborate on when op->o_bd->bd_self must be used instead of > op->o_bd? I understand that op->o_bd may be a copy of the original > structure that op->o_bd->bd_self refers to, but I'm not sure when it > must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch > the BackendInfo that can be used to call the top-most bd_search (and > similar) also in overlays? If you read the code for overlay_is_inst() it should be obvious - that function only works when used with a real BackendDB structure. The local copy structure has had its bd_info replaced with whatever on_inst structure corresponds to the current overlay. Yes, the bd_self points to the topmost structure, so you can use it for be_search. Much of what's happening in these overlays was intended to avoid starting over at the top though, because the code is already running in the desired overlay context. -- -- 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#5487) syncprov_findbase must search the backend from the syncrepl search
by hyc＠symas.com 04 May '08

04 May '08

Rein Tollevik wrote: > On Wed, 30 Apr 2008, Howard Chu wrote: > >> rein(a)OpenLDAP.org wrote: > >>> syncprov_findbase() must search the backend saved with the syncrepl >>> operation, >>> not the one from the operation passed as argument. The backend in the op >>> argument can be a subordinate database, in which case the search for the >>> base in >>> the superior database will fail, and syncrepl consumers will be force to do >>> a an >>> unneccessary full refresh of the database. >> OK. >> >>> The patch at the end should fix >>> this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the >>> overlay_op_walk() call, which is the reason for the long pointer traversal >>> to >>> find the correct bd_info to save and restore. > >> But the overlay_op_walk call is only appropriate when the DB to be searched >> is the current database, and the current DB is an overlay DB structure. > > Ah, the changing of the BackendDB->bd_info that takes place when > overlays are called feels like an open pit I manage to fall into every > time I get close to it... I wish it could be replaced in a future > version. Agreed, it would have been safer as an Op-specific field, but that would have caused quite a lot of disruption to all existing backend code. > A new patch that I hope should fix this is at the end. It always use > be_search, after putting back the original bd_info if needed. I feel > that using the generic be_search is better than interfering directly > with the overlay code as overlay_op_walk does. I also tested for > SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more > generic to me. But again, I may be totally wrong here. Does this patch > look better? SLAP_IS_OVERLAY will never be true here. That flag is only set when the BackendDB being tested is a local copy of a real BackendDB structure. The structure referenced in s_op is always a real BackendDB. In fact, if you're always going to use s_op and be_search, there's no further work needed, because the regular overlay infrastructure will always make a new local BackendDB copy itself. (And of course, some of that would be wasted effort, which is why the original code uses overlay_op_walk. Since op->o_bd is already an overlay DB, there's no need to make yet another copy for the first-search case.) -- -- 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#5488) syncrepl received contextCSN not passed on to syncprov consumers
by rein＠OpenLDAP.org 04 May '08

04 May '08

On Wed, 30 Apr 2008, Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> When syncrepl and syncprov are both used on a glue database, the >> contextCSN received from the syncrepl producers are not passed on to the >> syncprov consumers when changes in subordinate databases are received. >> The reason is that syncrepl queues the CSNs in the glue backend, while >> syncprov fetches them from the backend where the changes are made. As a >> consequence, the consumers will be passed a cookie without any csn >> value. >> >> My first attempt at fixing this was to change syncprov to fetch the >> queued csn values from the glue backend where it was used. But that >> failed as other modules queues the csn values in their own backend when >> they changes things. > > What other modules? Generally there cannot be any other sources of changes. Sorry, I should have written other configurations. The CSNs gets queued in the subordinate database when syncrepl is used there, or not at all (i.e in regular updates that comes in through the frontend). >> Instead I changed ctxcsn.c so that it always >> queues them in the glue backend where syncprov is used. But I don't >> feel that my understanding of this stuff is good enough to be sure that >> this is the optimal solution.. > > I definitely don't like references to the syncprov overlay appearing in main > slapd code like that. We need a different solution. That's reasonable, but the test for syncrepl is probably not needed if this solution should be kept. The test was more or less a copy and paste from syncrepl where it finds out which backend to write through. To me it makes sense to have a single queue of CSN values in a glued configuration, no matter if or where syncprov is used. > At one point in the past, I had changed syncrepl.c to queue the CSNs in > both places, but that seemed rather sloppy. Still, it may work best here. I don't like duplicating information, sooner or later it tends to end up with wrong info in one of the places.. Another approach could be to have syncprov look in the glue database if it fails to find any queued CSN in a subordinate db. I haven't tested it, but that should work in both configurations. It should also remove the need to always look for the glue db which my patch requires. Would that be better? >> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >> test, should that have included an overlay_is_inst() clause as well? > > Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on > that call. The current test (introduced to fix ITS#5433) causes the contextCSN to be written to the glue database when syncprov is used on a subordinate db, which appears wrong to me. Could you elaborate on when op->o_bd->bd_self must be used instead of op->o_bd? I understand that op->o_bd may be a copy of the original structure that op->o_bd->bd_self refers to, but I'm not sure when it must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch the BackendInfo that can be used to call the top-most bd_search (and similar) also in overlays? Rein

1 0

(ITS#5494) slapd crashed when accessed by multiple threads
by adejong＠debian.org 04 May '08

04 May '08

Full_Name: Arthur de Jong Version: 2.4.7 OS: Debian unstable URL: http://arthurenhella.demon.nl/nss-ldapd/adejong-slapd-crash.log Submission from: (NULL) (83.160.165.27) This has also been submitted as a Debian bug: http://bugs.debian.org/479237 My test slapd consistently crashes when doing multiple simultaneous requests in different threads. Each thread has it's own LDAP *ld connection to the LDAP server which is supposed to be supported [1]. In any case this shouldn't crash the LDAP server. [1] http://www.openldap.org/lists/openldap-software/200606/msg00252.html This problem arises in my test suite for nss-ldapd. Source can be checked out at http://arthurenhella.demon.nl/svn/nss-ldapd/ (svn) and the test file is (test/test_myldap.c). It uses a wrapper module (myldap) around calls to OpenLDAP to simplify memory management. The function that triggers the crash is test_threads(). I have captured the crash in gdb: # gdb /usr/sbin/slapd GNU gdb 6.8-debian [...] This GDB was configured as "i486-linux-gnu"... (gdb) r -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f /etc/ldap/slapd.conf Starting program: /usr/sbin/slapd -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f /etc/ldap/slapd.conf [Thread debugging using libthread_db enabled] [New Thread 0xb7b3a930 (LWP 1542)] @(#) $OpenLDAP: slapd 2.4.7 (Apr 16 2008 08:13:31) $ @minerva.hungry.com:/home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/debian/build/servers/slapd ldap_pvt_gethostbyname_a: host=sorbet, r=0 daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... [...] <= send_search_entry: conn 2 exit. entry_decode: "cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld" <= entry_decode(cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld) => send_search_entry: conn 2 dn="cn=Zaka Eddins+uid=zeddins,ou=lotsofpeople,dc=test,dc=tld" ber_flush2: 107 bytes to sd 18 <= send_search_entry: conn 2 exit. entry_decode: "uid=wvakil,ou=lotsofpeople,dc=test,dc=tld" <= entry_decode(uid=wvakil,ou=lotsofpeople,dc=test,dc=tld) => send_search_entry: conn 2 dn="uid=wvakil,ou=lotsofpeople,dc=test,dc=tld" ber_flush2: 90 bytes to sd 18 <= send_search_entry: conn 2 exit. entry_decode: "uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld" <= entry_decode(uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld) => send_search_entry: conn 2 dn="uid=zmeeker,ou=lotsofpeople,dc=test,dc=tld" ber_flush2: 92 bytes to sd 18 <= send_search_entry: conn 2 exit. bdb_search: 1104 scope not okay Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5f18b90 (LWP 5017)] 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0xb7f4351d in ldap_pvt_thread_mutex_lock () from /usr/lib/libldap_r-2.4.so.2 #2 0xb783883d in bdb_cache_return_entry_rw (bdb=0x81ea358, e=0x820922c, rw=0, lock=0xb5f16fd4) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/cache.c:256 #3 0xb782ce12 in bdb_search (op=0x8299b10, rs=0xb5f18168) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/back-bdb/search.c:909 #4 0x08077d13 in fe_op_search (op=0x8299b10, rs=0xb5f18168) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:368 #5 0x0807853c in do_search (op=0x8299b10, rs=0xb5f18168) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/search.c:217 #6 0x080757c6 in connection_operation (ctx=0xb5f18248, arg_v=0x8299b10) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1083 #7 0x08075ed6 in connection_read_thread (ctx=0xb5f18248, argv=0x13) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap2.3-2.4.7/servers/slapd/connection.c:1210 #8 0xb7f42a44 in ?? () from /usr/lib/libldap_r-2.4.so.2 #9 0xb5f18248 in ?? () #10 0x00000013 in ?? () #11 0x00000000 in ?? () A more detailed backtrace is available at the url specified below.

1 0

Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by rein＠OpenLDAP.org 04 May '08

04 May '08

On Wed, 30 Apr 2008, Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> syncprov_findbase() must search the backend saved with the syncrepl >> operation, >> not the one from the operation passed as argument. The backend in the op >> argument can be a subordinate database, in which case the search for the >> base in >> the superior database will fail, and syncrepl consumers will be force to do >> a an >> unneccessary full refresh of the database. > > OK. > >> The patch at the end should fix >> this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the >> overlay_op_walk() call, which is the reason for the long pointer traversal >> to >> find the correct bd_info to save and restore. > But the overlay_op_walk call is only appropriate when the DB to be searched > is the current database, and the current DB is an overlay DB structure. Ah, the changing of the BackendDB->bd_info that takes place when overlays are called feels like an open pit I manage to fall into every time I get close to it... I wish it could be replaced in a future version. > Your patch causes fc->fss->s_op->o_bd's bd_info pointer to change, which is > not allowed. That's in the original backendDB, which must be treated as > read-only since multiple threads may be accessing it. The correct approach > here is to use a new local backendDB variable, copy the s_op->o_bd into it, > and then just do a regular be_search invocation instead of using > overlay_op_walk. > > But, this patch must not take effect on the first call to syncprov_findbase > (which occurred in syncprov_op_search) - in that case, the current code is > correct. So, you need to tweak things based on whether (s_flags & > PS_IS_REFRESHING) is true or not - if true, this is the first search, and it > should use the original code. Else, it must use be_search. A new patch that I hope should fix this is at the end. It always use be_search, after putting back the original bd_info if needed. I feel that using the generic be_search is better than interfering directly with the overlay code as overlay_op_walk does. I also tested for SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more generic to me. But again, I may be totally wrong here. Does this patch look better? Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.1.1.18 diff -u -u -r1.1.1.18 syncprov.c --- OpenLDAP/servers/slapd/overlays/syncprov.c 30 Apr 2008 11:17:58 -0000 1.1.1.18 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 2 May 2008 11:19:46 -0000 @@ -404,7 +404,7 @@ slap_callback cb = {0}; Operation fop; SlapReply frs = { REP_RESULT }; - BackendInfo *bi; + BackendDB be; int rc; fc->fss->s_flags ^= PS_FIND_BASE; @@ -413,10 +413,15 @@ fop = *fc->fss->s_op; fop.o_hdr = op->o_hdr; - fop.o_bd = op->o_bd; fop.o_time = op->o_time; fop.o_tincr = op->o_tincr; - bi = op->o_bd->bd_info; + + if ( SLAP_ISOVERLAY( fop.o_bd )) { + slap_overinst *on = (slap_overinst *)fop.o_bd->bd_info; + be = *fop.o_bd; + be.bd_info = (BackendInfo *)on->on_info; + fop.o_bd = &be; + } cb.sc_response = findbase_cb; cb.sc_private = fc; @@ -434,8 +439,7 @@ fop.ors_filter = &generic_filter; fop.ors_filterstr = generic_filterstr; - rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info = bi; + rc = fop.o_bd->be_search( &fop, &frs ); } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase = 1;

1 0

(ITS#5493) CSN updates with delta-syncrepl refresh
by quanah＠OpenLDAP.org 04 May '08

04 May '08

Full_Name: Quanah Gibson-Mount Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) When delta-syncrepl is refreshing from the accesslog DB, it should update its local CSN after every modification, rather than waiting until all updates have propagated and then updating its CSN, in case slapd is shut down or dies, etc, while in the update process. This comes from the thread: <http://www.openldap.org/lists/openldap-software/200805/msg00004.html> --Quanah

1 0

back-bdb cache wrong lock ordering
by Yin Wang 03 May '08

03 May '08

Our study shows another potential deadlock in back-bdb/cache.c OpenLDAP 2.4.8 In bdb_cache_release_all(), thread wants to lock the c_lru_mutex at cache.c:1366, while it has the c_rwlock from cache.c:1364 In bdb_cache_delete_internal(), thread wants to lock the c_rwlock at cache.c:1317, while it has the c_lru_mutex from callers, bdb_cache_delete() at cache.c:1259, or bdb_cache_lru_purge() at cache.c:652. Note that two deadlock bugs of the same two mutexes have been reported and verified in the issue tracking system http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4254 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=3494 Yin Wang

2 1

Re: (ITS#5489) Assert failed in slapd_clr_write()
by rein＠OpenLDAP.org 02 May '08

02 May '08

On Wed, 30 Apr 2008, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in >> slapd_clr_write() failed, see the stack trace at the end. The >> last log message (at loglevel stat) related to the socket was >> "fd=657 closed (connection lost on write)". The comment where >> slapd_daemon_task() calls connection_write() makes me believe >> that slapd_clr_write() should not have use assert here. Remove >> it or include it as a condition in the following if statement? > > How frequently can you reproduce this? I'm tempted to say move the > assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still > triggers. This is the only occurrence I have found of this abort, so it is not very reproduce able :-( But the core shows that SLAP_SOCK_IS_WRITE would be false (as would SLAP_SOCK_IS_READ), so moving the assert into the if block should fix this case. And asserting a writeable socket is also active makes sence to me. Rein

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 02 May '08

02 May '08

luca(a)OpenLDAP.org wrote: > luca(a)OpenLDAP.org wrote: >> This is a multi-part message in MIME format. >> --------------080809000906010300090306 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> >> Howard Chu wrote: >> >>> Thanks. Please try HEAD again. >>> >> No way. >> new testrun directory in >> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >> >> backtrace attached >> > recent commits seem to have fixed it (at least, right now I'm not able > to reproduce it anymore...) Right. Confirmed here too; I (temporarily) added an assert(0) to the offending branch of code to make sure the patch was actually getting hit. It takes a very particular timing to trigger that code path. I'm not sure how we can reliably test for this down the road. Perhaps we should add a "disabled" config keyword for backends and syncrepl consumers, so that we can start up the individual servers, (which takes an unpredictable amount of time for each) and then enable various parts in a fixed sequence (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit or miss, because our test database is so small it's unlikely that we can hit the window of time on demand. -- -- 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#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 02 May '08

02 May '08

luca(a)OpenLDAP.org wrote: > This is a multi-part message in MIME format. > --------------080809000906010300090306 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Howard Chu wrote: > >> Thanks. Please try HEAD again. >> > No way. > new testrun directory in > ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz > > backtrace attached > recent commits seem to have fixed it (at least, right now I'm not able to reproduce it anymore...)

1 0

Potential deadlock in back-monitor cache
by Yin Wang 01 May '08

01 May '08

We are working on a project that could relieve from programmer the burden of reasoning about deadlocks, races etc. Our study of the latest OpenLDAP source code shows the following susceptible to deadlock. - monitor_cache_get at servers/slapd/back-monitor/cache.c:163 waiting for mp_mutex while holding mi_cache_mutex - monitor_cache_release at servers/slapd/back-monitor/cache.c:366 waiting for mi_cache_mutex while holding mp_mutex We have not verified this in production run, which could be difficult. Any comment would be greatly appreciated. Yin Wang

1 0

Re: (ITS#5491) slapd crashes with ldappasswd
by quanah＠zimbra.com 01 May '08

01 May '08

--On Wednesday, April 30, 2008 10:34 PM +0000 Deepak.Cheema(a)emerson.com wrote: > Full_Name: Deepak Cheema > Version: 2.4.8 > OS: Red Hat Linux 3.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.189.5.201) > > > Just built, installed openldap 2.4.8 and slapd starts up fine using the > following > > slapd -f slapd.conf -u root > > as root user on default port 389 > > [root@dl2k245 libexec]# ps -ef|grep slapd > root 15065 1 0 15:31 ? 00:00:00 ./slapd -f > /dbapps/informatica/l > dap/etc/openldap/slapd.conf -u root > > The process stays up as long as I don't type the ldappasswd command to > get the encrypted password a new user... > > once I type in ldappasswd... this is what happens.. > > [root@dl2k245 bin]# ldappasswd > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > additional info: SASL(0): successful result: security flags do not > match > required > [root@dl2k245 bin]# ps -ef|grep lapd > root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd > > and the slapd process is no longer there... > > Any ideas why it might be happening or how to debug this? > I tried dbg but it did not tell me much.. maybe I did not use it > correctly... > > Any help is appreciated ! gdb the slapd process, let it run, and then run your ldappasswd command and see where it is segfaulting. Provide a backtrace, etc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5492)
by hyc＠symas.com 01 May '08

01 May '08

huynh.tuan(a)comcast.net wrote: > --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 > Content-Type: text/plain > Content-Transfer-Encoding: 8bit > > I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. > > Used crypt to hash password. DES-based Unix crypt only checks the first 8 characters. As I said, if you want longer passwords, then your current choice of password hash is no good. Use some other hash instead. This ITS will be closed. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs