openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

(ITS#5990) Segmentation Fault with slapd with two olcSyncrepl directives in the config database
by crispy＠cluenet.org 04 Mar '09

04 Mar '09

Full_Name: Chris Breneman Version: 2.4.15 OS: Debian Lenny URL: Submission from: (NULL) (207.38.203.80) Using this configuration on a replication consumer, it segfaults almost immediately, and on startup. Config (standard schema files left out): === ./slapd.d/cn=config.ldif === dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /home/slapd/slapd.conf.skel olcConfigDir: /home/slapd/usr/etc/openldap/slapd.d olcArgsFile: /home/slapd/usr/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /home/slapd/usr/var/run/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 410a9404-9d47-102d-884d-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z entryCSN: 20090304203158.642980Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203158Z === ./slapd.d/cn=config/olcDatabase={-1}frontend.ldif === dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 410b05ba-9d47-102d-8853-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z entryCSN: 20090304203158.642980Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203158Z === ./slapd.d/cn=config/olcDatabase={0}config.ldif === dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW:: XXXXXXXXXXX olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 410b0970-9d47-102d-8854-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z olcSyncrepl: {0}rid=3 provider=ldap://ldap.cluenet.org type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="cn=schema,cn=config" bin dmethod=simple binddn="cn=replicator,dc=cluenet,dc=org" credentials="xxxxxxxx xxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/certs/Cluenet.pem tls_reqcer t=demand olcSyncrepl: {1}rid=4 provider=ldap://ldap.cluenet.org type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="olcDatabase={0}config,cn =config" attrs=olcAccess bindmethod=simple binddn="cn=replicator,dc=cluenet,d c=org" credentials="xxxxxxxxxxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/ certs/Cluenet.pem tls_reqcert=demand entryCSN: 20090304203402.651594Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203402Z Backtrace: #0 0x0805a0e7 in config_add_internal (cfb=0x8207ba0, e=0x8fe5554, ca=0xb68fc568, rs=0xb68fd974, renum=0xb68fd6e0, op=0xb68fdd24) at bconfig.c:4521 #1 0x0805a9c8 in config_back_add (op=0xb68fdd24, rs=0xb68fd974) at bconfig.c:4730 #2 0x080dda6c in syncrepl_entry (si=0x900bd08, op=0xb68fdd24, entry=0x8fe5554, modlist=0xb68fdb38, syncstate=1, syncUUID=0xb68fdb90, syncCSN=0x0) at syncrepl.c:2153 #3 0x080d9622 in do_syncrep2 (op=0xb68fdd24, si=0x900bd08) at syncrepl.c:890 #4 0x080daf2c in do_syncrepl (ctx=0xb68fe210, arg=0x900c008) at syncrepl.c:1333 #5 0x0806cf10 in connection_read_thread (ctx=0xb68fe210, argv=0xd) at connection.c:1225 #6 0x0816ba54 in ldap_int_thread_pool_wrapper (xpool=0x8fccf08) at tpool.c:663 #7 0xb7e4bf3b in start_thread () from /lib/libpthread.so.0 #8 0xb7be0bee in clone () from /lib/libc.so.6 Last lines with -d -1: syncrepl_entry: rid=003 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=003 inserted UUID 3d9f90aa-9ba6-102d-9a95-995804f089ee => access_allowed: search access to "cn=schema,cn=config" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => test_filter EQUALITY => access_allowed: search access to "cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={0}core,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={2}nis,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={3}inetorgperson,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncrepl_entry: rid=003 be_search (0) syncrepl_entry: rid=003 cn=schema,cn=config => access_allowed: add access to "cn=schema,cn=config" "entry" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) <= acl_access_allowed: granted to database root => access_allowed: add access to "olcDatabase={0}config,cn=config" "children" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) Segmentation fault (core dumped)

1 0

Re: (ITS#5989) slapd-ldap(5) idassert-bind missing starttls
by ando＠sys-net.it 04 Mar '09

04 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24/HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > In the slapd-ldap man page, the section on idassert-bind is missing the fact > that you can configure: > > starttls=no|yes|critical > > while listing all the other tls related keywords you can configure. tls_protocol_min is missing as well. Also, I note the values of starttls should be changed from "no,yes,critical" to "no,try,yes" (with "critical" synonym of "yes"), to remove the false security perception given by the current semantics of "yes". The change would create minor backward compatibility issues, but no security concern, since the meaning of "yes" would be promoted from optional to required. Incautious users that still use "yes" would just need to change it to "try" to restore the previous unsafe behavior. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5989) slapd-ldap(5) idassert-bind missing starttls
by quanah＠OpenLDAP.org 03 Mar '09

03 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In the slapd-ldap man page, the section on idassert-bind is missing the fact that you can configure: starttls=no|yes|critical while listing all the other tls related keywords you can configure.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 03 Mar '09

03 Mar '09

Thanks for your help. Would you be able to email your Makefile that you generated for gcc 4.0.3 on Solaris/SPARC? I am seriously missing something. I installed lated Sun Studio 12 and compiled with it and it's the same problem. /M. On Tue, Mar 3, 2009 at 2:49 PM, <hyc(a)symas.com> wrote: > mariusp44(a)gmail.com wrote: >> as I have pointed out in earlier post not only it doesn't work when I >> compile it myself but also the one that was downloaded form >> sunfreeware.com. It is not possible to tell what version of gcc was >> used to compile openldap that is distributed but explanation that it >> doesn't work because of compiler bug seems to me highly unlikely. >> Unless you can specifically point to which bug in gcc on SPARC >> contributes to this erratic behaviour of openldap. > > It's not our responsibility to do your legwork for you. You can easily email > the maintainers at sunfreeware.com and ask them. Since they currently host gcc > 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. > > Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris > and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy > on my system, nor do I see any reason to install a known-bad compiler just to > further demonstrate what has already been plainly documented by other folks. >> >> Either way, thanks for comments. >> >> /M. >> >> On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >>> ando(a)sys-net.it wrote: >>>> mariusp44(a)gmail.com wrote: >>>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>>> >>>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>>> I have no chance to test on that arch. You should figure our why those >>>> hashes are not supported. Did you enable crypt (--enable-crypt)? >>> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >>> >>> and is known to have many bugs. It's also already known that old gcc releases >>> have other problems on Sparc. (E.g. ITS#5875.) >>> >>> Please use a working compiler. >>> >>> As a workaround, recompile the offending functions with optimization disabled. >>> That usually helps in cases like this. >>> >>> There is no bug in OpenLDAP Software here, 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/ >>> >>> >>> >> >> >> > > > -- > -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by hyc＠symas.com 03 Mar '09

03 Mar '09

mariusp44(a)gmail.com wrote: > as I have pointed out in earlier post not only it doesn't work when I > compile it myself but also the one that was downloaded form > sunfreeware.com. It is not possible to tell what version of gcc was > used to compile openldap that is distributed but explanation that it > doesn't work because of compiler bug seems to me highly unlikely. > Unless you can specifically point to which bug in gcc on SPARC > contributes to this erratic behaviour of openldap. It's not our responsibility to do your legwork for you. You can easily email the maintainers at sunfreeware.com and ask them. Since they currently host gcc 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy on my system, nor do I see any reason to install a known-bad compiler just to further demonstrate what has already been plainly documented by other folks. > > Either way, thanks for comments. > > /M. > > On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >> ando(a)sys-net.it wrote: >>> mariusp44(a)gmail.com wrote: >>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>> >>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>> I have no chance to test on that arch. You should figure our why those >>> hashes are not supported. Did you enable crypt (--enable-crypt)? >> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >> >> and is known to have many bugs. It's also already known that old gcc releases >> have other problems on Sparc. (E.g. ITS#5875.) >> >> Please use a working compiler. >> >> As a workaround, recompile the offending functions with optimization disabled. >> That usually helps in cases like this. >> >> There is no bug in OpenLDAP Software here, 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/ >> >> >> > > > -- -- 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#5926) slapd proxying AD with back-meta locks up
by ando＠sys-net.it 03 Mar '09

03 Mar '09

mhardin(a)symas.com wrote: > Thank you for looking into this. The new configuration does not rely > on loopbacks and instead uses back-glue. We are also running 2.4.14 > with additional patches. Though it might quickly lead to unnecessary and excessive code duplication, I wonder whether a proxy backend couldn't just detect it would call self, and use an internal operation instead? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5926) slapd proxying AD with back-meta locks up
by mhardin＠symas.com 03 Mar '09

03 Mar '09

Thank you for looking into this. The new configuration does not rely on loopbacks and instead uses back-glue. We are also running 2.4.14 with additional patches. Cheers, -Matt On Mar 3, 2009, at 10:46 AM, Howard Chu wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.12 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We are using a pair of OpenLDAP 2.4.12 servers with back-meta to >> proxy an active >> directory domain. The clients are all current versions of PADL's >> nss_ldap >> libraries. >> >> Every once in a while (sometimes twice a day, sometimes once every >> two weeks) >> one of the slapd servers will peg CPU use at 100% and stop >> answering requests. >> The only way to stop slapd is with a kill -9. >> >> There doesn't seem to be anything to explain the lockup or allow us >> to reproduce >> it. We are using redundant AD servers and they are not going >> offline. A third >> slapd server running as a test server using the same AD servers and >> configured >> identically but serving a much lighter nss_ldap load does not fail >> at all. We >> have ruled out hardware, OS, and connectivity as possible causes. >> >> We are unfortunately unable to attach gdb to the running processes, >> as these are >> production servers and need to be restarted immediately. Our >> smaller test system >> does not exhibit the same behavior, either. There is nothing >> unusual in the >> server logs, either. We do have core files generated from kill -6 >> commands, and >> they are all eerily similar to the back-trace below in that they >> have one or >> more threads waiting for a search or a bind response from AD. >> >> I am also enclosing relevant portions of slapd.conf for these >> systems. Please >> let me know if any additional information would be useful. >> >> Thanks, >> >> -Matt >> >> ----- >> >> >> (gdb) thr apply all bt > >> Thread 1 (process 29769): >> #0 0x005fa410 in __kernel_vsyscall () >> #1 0x004ddd10 in raise () from /lib/libc.so.6 >> #2 0x004df621 in abort () from /lib/libc.so.6 >> #3 0x004d715b in __assert_fail () from /lib/libc.so.6 >> #4 0x0806eec8 in slap_listener (sl=0x9583108) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/ >> daemon.c:1803 >> #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/ >> daemon.c:1997 >> #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/ >> libldap_r/tpool.c:663 >> #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 >> #8 0x00585c4e in clone () from /lib/libc.so.6 >> (gdb) > > It seems you sent the wrong backtrace; this one doesn't show any > signs of looping or anything that would indicate heavy CPU usage. It > shows an assert which would kill the process, leading to 0% CPU > usage. This assert was most likely fixed in 2.4.14. > >> slapd.conf > >> ####################################################################### >> # bdb database definitions >> ####################################################################### >> database bdb >> suffix "ou=nisdata" > >> ####################################################################### >> # Definitions for proxy and cache to AD >> ####################################################################### >> database meta >> suffix "dc=my-customer,dc=com" > >> # The link to AD: >> uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my- >> customer,dc=com >> ldaps://ldap-prd-dc02.my-customer.com/ > >> # The link to the NIS data directory (yes, we could chain/glue, >> that's >> # for later) >> uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my- >> customer,dc=com > > Pointing back-meta at its own slapd will inevitably exhaust the > thread pool since incoming operations will always use 2x the number > of available threads. > > 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

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 03 Mar '09

03 Mar '09

as I have pointed out in earlier post not only it doesn't work when I compile it myself but also the one that was downloaded form sunfreeware.com. It is not possible to tell what version of gcc was used to compile openldap that is distributed but explanation that it doesn't work because of compiler bug seems to me highly unlikely. Unless you can specifically point to which bug in gcc on SPARC contributes to this erratic behaviour of openldap. Either way, thanks for comments. /M. On Mon, Mar 2, 2009 at 5:56 PM, <hyc(a)symas.com> wrote: > ando(a)sys-net.it wrote: >> mariusp44(a)gmail.com wrote: >>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>> md5 and sha works, smd5, ssha and crypt doesn't. >>> >>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >> >> I have no chance to test on that arch. You should figure our why those >> hashes are not supported. Did you enable crypt (--enable-crypt)? > > gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ > > and is known to have many bugs. It's also already known that old gcc releases > have other problems on Sparc. (E.g. ITS#5875.) > > Please use a working compiler. > > As a workaround, recompile the offending functions with optimization disabled. > That usually helps in cases like this. > > There is no bug in OpenLDAP Software here, 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

Re: (ITS#5926) slapd proxying AD with back-meta locks up
by hyc＠symas.com 03 Mar '09

03 Mar '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.12 > OS: Red Hat Enterprise Linux 4 i686 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.185) > > > Hi All, > > We are using a pair of OpenLDAP 2.4.12 servers with back-meta to proxy an active > directory domain. The clients are all current versions of PADL's nss_ldap > libraries. > > Every once in a while (sometimes twice a day, sometimes once every two weeks) > one of the slapd servers will peg CPU use at 100% and stop answering requests. > The only way to stop slapd is with a kill -9. > > There doesn't seem to be anything to explain the lockup or allow us to reproduce > it. We are using redundant AD servers and they are not going offline. A third > slapd server running as a test server using the same AD servers and configured > identically but serving a much lighter nss_ldap load does not fail at all. We > have ruled out hardware, OS, and connectivity as possible causes. > > We are unfortunately unable to attach gdb to the running processes, as these are > production servers and need to be restarted immediately. Our smaller test system > does not exhibit the same behavior, either. There is nothing unusual in the > server logs, either. We do have core files generated from kill -6 commands, and > they are all eerily similar to the back-trace below in that they have one or > more threads waiting for a search or a bind response from AD. > > I am also enclosing relevant portions of slapd.conf for these systems. Please > let me know if any additional information would be useful. > > Thanks, > > -Matt > > ----- > > > (gdb) thr apply all bt > Thread 1 (process 29769): > #0 0x005fa410 in __kernel_vsyscall () > #1 0x004ddd10 in raise () from /lib/libc.so.6 > #2 0x004df621 in abort () from /lib/libc.so.6 > #3 0x004d715b in __assert_fail () from /lib/libc.so.6 > #4 0x0806eec8 in slap_listener (sl=0x9583108) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1803 > #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1997 > #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 > #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 > #8 0x00585c4e in clone () from /lib/libc.so.6 > (gdb) It seems you sent the wrong backtrace; this one doesn't show any signs of looping or anything that would indicate heavy CPU usage. It shows an assert which would kill the process, leading to 0% CPU usage. This assert was most likely fixed in 2.4.14. > slapd.conf > ####################################################################### > # bdb database definitions > ####################################################################### > database bdb > suffix "ou=nisdata" > ####################################################################### > # Definitions for proxy and cache to AD > ####################################################################### > database meta > suffix "dc=my-customer,dc=com" > # The link to AD: > uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my-customer,dc=com > ldaps://ldap-prd-dc02.my-customer.com/ > # The link to the NIS data directory (yes, we could chain/glue, that's > # for later) > uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my-customer,dc=com Pointing back-meta at its own slapd will inevitably exhaust the thread pool since incoming operations will always use 2x the number of available threads. 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

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 03 Mar '09

03 Mar '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Probably a side-effect of fixing ITS#5853: >> This seems to be unrelated from ITS#5853, actually. > > Fixed now in HEAD Thanks. I did not realize I was trying an exceptional configuration. >> Another note: if a search reference is received, it is returned by >> libldap and additionally it is chased, so one gets both the search >> reference and the chased search reference results. > > 2.3 does this as well, seems to be intentional. I tested the scenario I described in a previous mail, and nothing weird showed up. I might have screwed up something? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

← Newer
1
...
18
19
20
21
22
23
24
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009