- openldap-bugs - openldap.org

Re: (ITS#5005) test017 fails
by hyc＠symas.com 19 Jun '07

19 Jun '07

ando(a)sys-net.it wrote: > dieter(a)dkluenter.de wrote: > >> the patch fails, this is the patch reject file: > > That's probably because you cut'n'pasted from the email, where the tabs > were probably replaced by whitespaces. I'll apply that fix if anyone > confirms that cookie is legal at all. Yes. There's no hard definition of the cookie requirements. "rid=xxx" without a CSN is the same as no cookie at all. The patch seems to work here, go ahead and commit it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it 19 Jun '07

19 Jun '07

Simon Gao wrote: > Pierangelo Masarati wrote: >> gao(a)schrodinger.com wrote: >> >> >>> URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext >>> >> ^^^ This link is unreachable >> >> > Sorry about the broken link. Here is the correct one: > > ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext > >>> When following command against a consumer slapd, it will crash slapd of the >>> consumer when loglevel is set to any other value other than 1 or -1 on the >>> consumer: >>> >>> ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S >>> -x -A >>> >>> The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 >>> or "-1", then no crash is experienced. In addition, when run consumer slapd >>> manually as front process, >>> >> ^^^ what does this mean? >> > If I start slapd manually as following commands: > > /usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps' > /usr/lib/openldap/slapd -d 256 -u ldap -g ldap -h 'ldap:// ldaps' > /usr/lib/openldap/slapd -d 512 -u ldap -g ldap -h 'ldap:// ldaps' > > Then I did not see the problem as I would when setting loglevel to 0, > 256, 512 in slapd.conf and start slapd from /etc/init.d/slapd, which > launch the daemon with the same options. When starting slapd from > /etc/init.d/slapd as background daemon process, slapd will write to > /var/log/ldap.log and /var/log/message. It seems that the difference > exists between writing ldap logs to a file (slapd runs in background) or > writing to console (slapd runs in foreground as started manually). > >> >>> then all debug level works without problem. >>> >> OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything >> like that. I note that differences related to the debug level usually >> mean that a NULL or an invalid pointer is passed to a *printf(3) routine >> on those systems that do not tolerate it (e.g. Solaris). But usually >> the bug disappears when __decreasing__ the log level, while -1 means all. >> >> p. >> > > I would expect writing less log should help avoiding problem. In this > case, somehow logging must be set at certain or above a level. Below > that it will trigger problem. While I was trying to get pieces working, > I always set loglevel to 1 or -1. So I did not realize this problem > until very late. The error I got as a result of attempting change > password is "can't contact LDAP server" which is very confusing (might > be because slapd already crashed before serving last request). > > I am happy to run more tests and provide further information as needed. If slapd crashes, the only really useful info is a core dump, as indicated in the FAQ I already pointed you to (that's basically why I pointed you there: there's no point in always repeating instructions for bug tracing, that's what the FAQ is intended for; apparently, it's totally ignored). 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

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 19 Jun '07

19 Jun '07

Pierangelo Masarati wrote: > gao(a)schrodinger.com wrote: > > >> URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext >> > > ^^^ This link is unreachable > > Sorry about the broken link. Here is the correct one: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext >> When following command against a consumer slapd, it will crash slapd of the >> consumer when loglevel is set to any other value other than 1 or -1 on the >> consumer: >> >> ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S >> -x -A >> >> The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 >> or "-1", then no crash is experienced. In addition, when run consumer slapd >> manually as front process, >> > > ^^^ what does this mean? > If I start slapd manually as following commands: /usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps' /usr/lib/openldap/slapd -d 256 -u ldap -g ldap -h 'ldap:// ldaps' /usr/lib/openldap/slapd -d 512 -u ldap -g ldap -h 'ldap:// ldaps' Then I did not see the problem as I would when setting loglevel to 0, 256, 512 in slapd.conf and start slapd from /etc/init.d/slapd, which launch the daemon with the same options. When starting slapd from /etc/init.d/slapd as background daemon process, slapd will write to /var/log/ldap.log and /var/log/message. It seems that the difference exists between writing ldap logs to a file (slapd runs in background) or writing to console (slapd runs in foreground as started manually). > >> then all debug level works without problem. >> > > OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything > like that. I note that differences related to the debug level usually > mean that a NULL or an invalid pointer is passed to a *printf(3) routine > on those systems that do not tolerate it (e.g. Solaris). But usually > the bug disappears when __decreasing__ the log level, while -1 means all. > > p. > I would expect writing less log should help avoiding problem. In this case, somehow logging must be set at certain or above a level. Below that it will trigger problem. While I was trying to get pieces working, I always set loglevel to 1 or -1. So I did not realize this problem until very late. The error I got as a result of attempting change password is "can't contact LDAP server" which is very confusing (might be because slapd already crashed before serving last request). I am happy to run more tests and provide further information as needed. Thanks, Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by quanah＠zimbra.com 18 Jun '07

18 Jun '07

--On Tuesday, June 19, 2007 5:37 AM +0000 ando(a)sys-net.it wrote: > gao(a)schrodinger.com wrote: > >> URL: >> ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its >> .ext <ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext> is the actual file. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it 18 Jun '07

18 Jun '07

gao(a)schrodinger.com wrote: > URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext ^^^ This link is unreachable > When following command against a consumer slapd, it will crash slapd of the > consumer when loglevel is set to any other value other than 1 or -1 on the > consumer: > > ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S > -x -A > > The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 > or "-1", then no crash is experienced. In addition, when run consumer slapd > manually as front process, ^^^ what does this mean? > then all debug level works without problem. OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything like that. I note that differences related to the debug level usually mean that a NULL or an invalid pointer is passed to a *printf(3) routine on those systems that do not tolerate it (e.g. Solaris). But usually the bug disappears when __decreasing__ the log level, while -1 means all. p. 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

Re: (ITS#4986) manageDSAit might control cause problems in database selection
by hyc＠symas.com 18 Jun '07

18 Jun '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). >> >> Please test. > > Not entirely sure about that test myself. The original is rev 1.94 > > revision 1.94 > date: 2000/10/21 01:29:02; author: kurt; state: Exp; lines: +20 -7 > First-cut at manageDSAit-aware backend selection. > > Seems a bit unnecessary really. > Thinking back, I think the idea here is that you might have a set of nested databases connected by referral entries. E.g., database ldbm suffix dc=sub,dc=example,dc=com database ldbm suffix dc=example,dc=com If you had an referral entry in the superior DB that pointed to the sub database, you would need the manageDSAit control to be able to operate on the referral entry. None of this really makes sense post 2.1 since subordinate/glue makes it superfluous. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4986) manageDSAit might control cause problems in database selection
by hyc＠symas.com 18 Jun '07

18 Jun '07

ando(a)sys-net.it wrote: > A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). > > Please test. Not entirely sure about that test myself. The original is rev 1.94 revision 1.94 date: 2000/10/21 01:29:02; author: kurt; state: Exp; lines: +20 -7 First-cut at manageDSAit-aware backend selection. Seems a bit unnecessary really. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5024) Disabling pagedResults advertisements
by hyc＠symas.com 18 Jun '07

18 Jun '07

v_orgos(a)yahoo.com.au wrote: > Full_Name: Vic Orgos > Version: 2.2.13 > OS: RHEL4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.9.136.163) > I really do not want to have to maintain a custom RPM or have to patch RedHat's > everytime there is an update/security patch. 2.2.13 was obsoleted years ago. If you can't get adequate support from RedHat then you should upgrade to a current release. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5024) Disabling pagedResults advertisements
by v_orgos＠yahoo.com.au 18 Jun '07

18 Jun '07

Full_Name: Vic Orgos Version: 2.2.13 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.9.136.163) Hi, I am upgrading from 2.0.xx (RHEL3) to 2.2.13 on RHEL4. Outlook 2003 clients have been using the old ldap server with no issues at all but during testing on the new RHEL4 test server I've come across the problem discussed at http://www.openldap.org/lists/openldap-software/200408/msg00298.html As suggested I've tried to stop it advertising pagedResults but it does not work. I've tried access to dn.exact="" filter="(supportedControl=1.2.840.113556.1.4.319)" by * none but this does not work and I've tried ccess to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319 by * none which seg faults. I would appreciate if you would provide me with the correct syntax or some means to allow Outlook to work correctly. I really do not want to have to maintain a custom RPM or have to patch RedHat's everytime there is an update/security patch. Thank you for your time. Vic.

1 0

(ITS#5023) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 18 Jun '07

18 Jun '07

Full_Name: Simon Gao Version: 2.3.35 OS: Gentoo Linux 2007.0 kernel 2.6.16 URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext Submission from: (NULL) (192.156.98.12) When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer: ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process, then all debug level works without problem. Please check attached ftp link for detailed logs and information.

1 0

(ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 18 Jun '07

18 Jun '07

Full_Name: Simon Gao Version: 2.3.35 OS: Gentoo Linux 2007.0 kernel 2.6.16 URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext Submission from: (NULL) (192.156.98.12) When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer: ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process, then all debug level works without problem. Please check attached ftp link for detailed logs and information.

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by h.b.furuseth＠usit.uio.no 18 Jun '07

18 Jun '07

We've clarified the usage text in SampleLDAP.py. -- Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 17 Jun '07

17 Jun '07

Howard Chu writes: > Are you using the same version of OpenSSL on your other test machines? > Have you tried a newer version? Yes, and not yet. > (...) But at the moment this seems to be an OpenSSL problem, in which > case we can close this ITS. Yes, or put it on Feedback. I'll have a closer look at this eventually, but just compiling OpenSSL on that HP box takes ages. Don't hold RE23 for this. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by hyc＠symas.com 16 Jun '07

16 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't > know. Are you using the same version of OpenSSL on your other test machines? Have you tried a newer version? Makes sense that this wouldn't be a problem in HEAD since we're now using liblber for certificate handling. I suppose we could patch RE23 to use ber_get_int for the serial number. But at the moment this seems to be an OpenSSL problem, in which case we can close this ITS. > The offending operation (on Jennifer Smith) adds one certificate and > deletes the old one. However the added and the old certificate compare > equal because certificateExactNormalize() produces the same string for > both: > 0$email=ca(a)example.com,cn=example ca, > o=openldap example\2C ltd.,st=california,c=us > > That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() > returns serial number "0". The inputs to that function are > (gdb) p *sn > $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} > and > (gdb) p *sn > $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} > Those *sn values are the same as on a successful run on Linux, except > the 2nd data[1...] (the xample... string) which I presume does not > matter when length=1. > > The input certificates ('val' arg to certificateExactNormalize()) are > correct. > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 16 Jun '07

16 Jun '07

Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't know. The offending operation (on Jennifer Smith) adds one certificate and deletes the old one. However the added and the old certificate compare equal because certificateExactNormalize() produces the same string for both: 0$email=ca(a)example.com,cn=example ca, o=openldap example\2C ltd.,st=california,c=us That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() returns serial number "0". The inputs to that function are (gdb) p *sn $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} and (gdb) p *sn $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} Those *sn values are the same as on a successful run on Linux, except the 2nd data[1...] (the xample... string) which I presume does not matter when length=1. The input certificates ('val' arg to certificateExactNormalize()) are correct. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 16 Jun '07

16 Jun '07

quanah(a)zimbra.com writes: > conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary > Why is it modifying the same attribute twice? It adds one cert and deletes another in the same op. The log from a successful run on Linux shows the same. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by quanah＠zimbra.com 15 Jun '07

15 Jun '07

--On June 15, 2007 9:59:56 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, 2.3.35 > OS: HP-UX > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in > HEAD. > > OpenSSL version: 0.9.7d. > > I enclose the testrun directory from: > > $ ./run -b ldif test021-certificate > Cleaning up test run directory leftover from previous run. > Running ./scripts/test021-certificate... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Testing certificate handling... > Add certificates... > ldapmodify failed (20)! > The last modify is erroring with already exists. The last logged modify looks really weird to me: conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary Why is it modifying the same attribute twice? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Full_Name: Hallvard B Furuseth Version: RE23, 2.3.35 OS: HP-UX URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in HEAD. OpenSSL version: 0.9.7d. I enclose the testrun directory from: $ ./run -b ldif test021-certificate Cleaning up test run directory leftover from previous run. Running ./scripts/test021-certificate... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing certificate handling... Add certificates... ldapmodify failed (20)!

1 0

Re: (ITS#5020) configure needs -pthread to find pthread.h
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

I wrote: > ./configure CC="cc -pthread" works. Well, it configures. Then it fails to build shared libraries because libtool invokes ld ... -pthread, and ld does not accept -pthread. But I guess that should be reported to the libtool folks. ./configure --disable-shared CC="cc -pthread" does work. -- Regards, Hallvard

1 0

Re: (ITS#5014) syncrepl failure syslog
by donn＠u.washington.edu 15 Jun '07

15 Jun '07

On Jun 14, 2007, at 2:08 PM, Pierangelo Masarati wrote: > So what's really relevant in your patch, and > missing from the code, is a test for "err" after the "done" label. I > have applied something along those lines to the code. Please test. Yes, this works in my case - if indeed the test is after "done:". You accidentally put it before, and it doesn't work there. Thanks! Donn Cave, donn(a)u.washington.edu

1 0

(ITS#5020) configure needs -pthread to find pthread.h
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: OSF1 V5.1 alpha URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard /configure on OSF1 alpha finds no suitable threading library. config.log says: configure:19993: checking pthread.h usability configure:20005: cc -c -g -I/local/include -I/local/gnu/include conftest.c >&5 cc: Error: /usr/include/pthread.h, line 1251: #error "Please compile the module including pthread.h with -pthread" (errormessage) due to this snippet of pthread.h: # ifndef _REENTRANT # error "Please compile the module including pthread.h with -pthread" # endif ./configure CC="cc -pthread" works. Not sure how to deal with that one. Seems a bit excessive to run all the OL_PTHREAD_TRY()s _before_ detecting that the system has pthread. Maybe write a special case, like try for pthread.h with -D_REENTRANT if not found without that?

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 15 Jun '07

15 Jun '07

pierangelo.masarati(a)sys-net.it wrote : > Would it be possible to get, from the consumer's log, what was the > actually requested time limit in those cases? This means: track down > what connection/operation was concluded by a "Time Limit Exceeded" > response; then find out the corresponding request, and see what was the > requested time limit. You need "args" debug level for this purpose, and > you need to look at the second of the three numbers that end the SRCH > line in the logs; for example: Hi Pierangelo; The problem came from my LDAP client which specified timelimit=1. I repaired the client and everything works fine since several hours :-) Thanks for your help and sorry for wasting your time. For me the ITS is to be closed (the error "Time Limit Exceeded" produced for syncrepl connection every 3600 seconds does not bother me). Best regards Ali

1 0

Re: memory leak (ITS#5018)
by niloulili＠hotmail.com 14 Jun '07

14 Jun '07

OK,I've download release 2.3.32,after removing and test ,i'll report whether problem still exits. Thank you so much. best regards nina >From: Pierangelo Masarati <openldap-its(a)OpenLDAP.org> >To: niloulili(a)hotmail.com >Subject: Re: memory leak (ITS#5018) >Date: Thu, 14 Jun 2007 08:13:11 GMT > >OpenLDAP 2.2.19 (and OpenLDAP 2.2) has been abandoned long ago, so it is no >longer maintained. Please upgrade to a recent version and check if the problem >persists. Otherwise this ITS will be closed. > >p. _________________________________________________________________ ÓëÁª»úµÄÅóÓÑœøÐÐœ»Á÷£¬ÇëÊ¹ÓÃ MSN Messenger: http://messenger.msn.com/cn

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by rra＠stanford.edu 14 Jun '07

14 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote: >> While investigating another issue with back_perl, I tried to use the >> SampleLDAP.pm module that comes with the OpenLDAP source. I added the >> following to my slapd.conf: >> database perl >> suffix "o=AnyOrg,c=US" >> perlModulePath /home/eagle/SampleLDAP.pm >> perlModule SampleLDAP [...] > database perl > suffix "o=AnyOrg,c=US" > perlModulePath /usr/local/etc/openldap > perlModule SampleLDAP I detect an intriguing difference in our configurations. I was misled by this comment in SampleLDAP.pm: # Usage: Add something like this to slapd.conf: # # database perl # suffix "o=AnyOrg,c=US" # perlModulePath /path/to/this/file # perlModule SampleLDAP The man page is more accurate. This was apparently actually a minor bug in the comments. :) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.3.35 > OS: Debian > URL: > Submission from: (NULL) (171.66.157.14) > > > While investigating another issue with back_perl, I tried to use the > SampleLDAP.pm module that comes with the OpenLDAP source. I added the > following to my slapd.conf: > > moduleload back_perl > ># ... > > database perl > suffix "o=AnyOrg,c=US" > perlModulePath /home/eagle/SampleLDAP.pm > perlModule SampleLDAP > > The result of slapd -d 1 is: > ... > WARNING: No dynamic config support for database perl. > config_build_entry: "olcDatabase={2}perl" > backend_startup_one: starting "dc=Stanford,dc=EDU" > bdb_db_open: unclean shutdown detected; attempting recovery. > bdb_db_open: dbenv_open(/var/lib/ldap) > backend_startup_one: starting "o=AnyOrg,c=US" > Can't call method "init" on an undefined value. Using the SampleLDAP perl module supplied with the OpenLDAP source works just fine for me on Stanford's LDAP servers. ldap-uat00:/usr/local/etc/openldap# more slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema loglevel 0 threads 8 password-hash {CLEARTEXT} # Define global ACLs to disable default read access. pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # # Load dynamic backend modules: # Note: back-null is statically-linked. modulepath /usr/local/lib/openldap moduleload back_perl.la access to dn="" by * read access to * by anonymous read by users read by self write # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! tool-threads 2 ####################################################################### # perl database definitions ####################################################################### database perl suffix "o=AnyOrg,c=US" perlModulePath /usr/local/etc/openldap perlModule SampleLDAP Output from slapd -d -1 slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" WARNING: No dynamic config support for database perl. config_build_entry: "olcDatabase={1}perl" backend_startup_one: starting "o=AnyOrg,c=US" slapd starting daemon: added 4r listener=(nil) daemon: added 7r listener=0x6010e0 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL So I am unable to reproduce this issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs