- openldap-bugs - openldap.org

(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 09 May '08

09 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 09 May '08

09 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 08 May '08

08 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 07 May '08

07 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 07 May '08

07 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 07 May '08

07 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs