- openldap-bugs - openldap.org

Re: (ITS#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it 09 Dec '09

09 Dec '09

quanah(a)zimbra.com wrote: > When configuring a replica using syncrepl, it should be possible to have an > option that sets the keepalive used for the tcp connection between the replica > and master. Support for this was added to libldap, but no corresponding support > was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for > configuring this, based in seconds. A fix is in HEAD (it's been there for a while); please test. Thanks, p.

1 0

Re: (ITS#6037) errno in signal handlers
by hyc＠symas.com 08 Dec '09

08 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Signal handlers slapd/daemon.c:slap_sig_shutdown()/slap_sig_wake() need > to save/restore errno, since they call functions that can modify errno. > > And/or possibly they need sock_errno() - sock_errset() from ac/socket.h, > since they use tcp_write()? I don't know if that's safe inside signal > handlers, or if Windows itself saves/restores this code around signal > handlers. Windows doesn't really have signals in the first place. SIGTERM/SIGINT are simulated by the C runtime library, none of the other signals are really supported... All of the "support" is synchronous only - can only be invoked by raise(). I don't think there's any issue here. (An exception - I wrote a patch for the MSYS 1.11 runtime to propagate SIGINT/SIGTERM to other processes. The patch only works on win32, not win64 because I never got a decent win64 build environment working... But if you're using MSYS, it is possible to send these signals to a running slapd and have it shutdown cleanly. Otherwise, signals don't really exist for native Windows apps...) > slapd/main.c:wait4child() can loop forever after EINTR, since it checks > for errno even when the waitpid returns 0. I don't know if there is > a good reason it does that. Some of the commits have my name on them > but I think I copied it from elsewhere. > > > Anyway, I'm doing the minimal changes now: save/restore errno, and > set errno=0 in each loop iteration instead of before the loop. > Anyone with better ideas can take it from there. Good enough. Closing this ITS. -- -- 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#6423 slapo-rwm and dynlist overlay
by hyc＠symas.com 08 Dec '09

08 Dec '09

masarati(a)aero.polimi.it wrote: > The problem is that back-relay presents slapo-rwm(3) an entry with both > REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a > consequence, the entry is released (namely, freed) before it is returned > by the frontend. As far as I understand, the two flags should be mutually > exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is > supposed to be a copy of an entry that may need to be released, or an > entry created from scratch and thus not stored anywhere. I have a quick > fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when > REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in > tracking where the issue occurs. Unless I track it, I'll commit the quick > fix. We already have ITS#5340 for issues with these flags... -- -- 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

ldapsearch with delay (on the same machine over TLS/SSL only)
by Pavel Lisy 08 Dec '09

08 Dec '09

Hello I've found one problem I have latest openldap release 2.4.3 (but it is similar on former versions too). There is small delay (1-2s) on beginning when I query ldap server from the same machine over TLS or SSL. Without SSL is no delay. Is it bug or is it normal? How can I debug it more? QUERY with delay: from ldap1 to ldap1 (the same machine) [root@ldap1 ~]# ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d QUERY without delay: from ldap1 to ldap1 (the same machine without TLS) [root@ldap1 ~]# ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d from ldap1 to ldap2 [root@ldap1 ~]# ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d from ldap2 to ldap1 [root@ldap2 ~]# ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d I think my DNS/hosts settings are correct My testing environment: servers: ldap1.ldapnet.tmapy.cz ldap2.ldapnet.tmapy.cz ldap3.ldapnet.tmapy.cz from ldap1 config: slapd.conf TLSCACertificateFile /etc/pki/tls/cacert.pem TLSCertificateFile /etc/pki/tls/certs/ldap1.ldapnet.tmapy.cz-cert.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap1.ldapnet.tmapy.cz-key.pem [root@ldap1 ~]# hostname ldap1.ldapnet.tmapy.cz [root@ldap1 ~]# grep ldap1 /etc/hosts 192.168.241.10 ldap1.ldapnet.tmapy.cz [root@ldap1 ~]# ifconfig eth0 eth0 inet adr:192.168.241.10 Všesměr:192.168.241.255 Maska:255.255.255.0 [root@ldap1 ~]# grep ldap1 /etc/pki/tls/certs/ldap1.ldapnet.tmapy.cz-cert.pem Subject: C=CS, ST=Kraj kralovehradecky, O=T-MAPY spol. s r.o.,OU=ldapnet, CN=ldap1.ldapnet.tmapy.cz Pavel Lisy -- Pavel Lisy <pali(a)tmapy.cz>

3 4

Re: (ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

h.b.furuseth(a)usit.uio.no writes: > In syncrepl.c lines 1001-1010: Also in equivalent code around line 820. -- Hallvard

1 0

(ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.20 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In syncrepl.c lines 1001-1010: LDAPControl **next; rctrlp = ldap_control_find( LDAP_CONTROL_SYNC_DONE, rctrls, &next ); if ( next && ldap_control_find( LDAP_CONTROL_SYNC_DONE, next, NULL ) ) 'next' in the last line is uninitalized if 2nd line failed. Seen in testrun/srv2/valgrind.* with './run -b null test050' and and slapd under valgrind.

1 0

ITS#6423 slapo-collect & slapo-valsort could suffer from the same issue
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

This should now be fixed in HEAD, collect.c 1.17 <- 1.16 valsort.c 1.27 <- 1.26 please review and test. p.

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 Please test and report. Thanks, p.

1 0

(ITS#6424) slapd-meta pseudoroot* directives deprecated
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando The man page erroneously reports them. A fix is coming. See also ITS#6418. p.

1 0

ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

The problem is that back-relay presents slapo-rwm(3) an entry with both REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a consequence, the entry is released (namely, freed) before it is returned by the frontend. As far as I understand, the two flags should be mutually exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is supposed to be a copy of an entry that may need to be released, or an entry created from scratch and thus not stored anywhere. I have a quick fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in tracking where the issue occurs. Unless I track it, I'll commit the quick fix. p.

1 0

(ITS#6423) slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 08 Dec '09

08 Dec '09

Full_Name: Leo Bergolth Version: 2.4.20 OS: linux URL: http://leo.kloburg.at/tmp/dynlist-rwm.log Submission from: (NULL) (137.208.89.66) When using the relay backend, entries that have attributes expanded by the dynlist overlay are not shown in the virtual naming context. (Not even those attributes that are not created dynamically, only an empty dn is shown for those entries.) Example: # real naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu-wien,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: cn=dynlisttest,ou=LDAPgroups,dc=wu-wien,dc=ac,dc=at objectClass: wuDynGroupOfNames objectClass: groupOfURLs objectClass: top cn: dynlisttest memberURL: ldap:///dc=wu-wien,dc=ac,dc=at??sub?(&(objectclass=wuPerson)(uid=be rgolth*)) member: uid=bergolth,ou=users,dc=wu-wien,dc=ac,dc=at member: uid=bergolth2,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at -------------------- 8< -------------------- # virtual naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: -------------------- 8< -------------------- According to Pierangelo Maserati it seems to be a bug in slapo-rwm. http://thread.gmane.org/gmane.network.openldap.technical/207/focus=210 # dynlist config: -------------------- 8< -------------------- dn: olcOverlay={0}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}posixGroup labeledURI memberUid:uid olcDlAttrSet: {1}wuDynGroupOfNames memberURL member -------------------- 8< -------------------- # relay rwm config: -------------------- 8< -------------------- dn: olcOverlay={0}rwm,olcDatabase={3}relay,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "dc=wu-wien,dc=ac,dc=at" -------------------- 8< -------------------- The debug output of the second ldapsearch can be found at the specified URL. Thanks, --leo

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 7:19 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi, > Thanks for your reply. After inspection in config.log, I found that ld > could not find libstdc++ although it there in /usr/lib and /usr/lib64. I > just add a symbolic link to libstdc++.so.6.0.8 then bingo! THE ISSUE HAS > RESOLVED > > Best Regards, I've closed this ITS based on the response. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 9:47 AM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: openldap-2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > > > Hi Guys, > As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel > package (there is mysql_config & ndbclient library), counfigure does not > locate ndbclient library. Also I've upgrade libtools! > > Best Regards, > -- Afshin > > > > [root@dc1 openldap-2.4.19]# mysql_config --libs > -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc > [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ > total 51780 > -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a > -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a > -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a > -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a > -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a > -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a > -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la > -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a > -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la > -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a > -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a > -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a > -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la > -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a > -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a > -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la > [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb > --disable-hdb > Configuring OpenLDAP 2.4.19-Release ... > checking for ndb_init in -lndbclient... no > configure: error: could not locate ndbclient library > [root@dc1 openldap-2.4.19]# And what does the config.log show for why this linking failed? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Dienstag 08 Dezember 2009 11:53:41 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > >>> ------------------------------------ > >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > >>> type="refreshAndPersist" starttls=critical bindmethod="simple" > >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > >>> ------------------------------------ > >>> > >>> Question is if this is a bug in the documentation or in the code. I > >>> think it's the latter. > >> > >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 > >> -> 1.509. Can you please test and let us know the result? > > > > It solves the problem only partially. It still doesn't work when using > > "ldaps://" uris AFAICS. > > The code was assuming that at least one of the other TLS config keywords > would also be used in these situations. Most of the time the slapd TLS > config would only be appropriate for server use, and would need to be > overridden when acting as a client. > > Anyway, this is now fixed in HEAD. Confirmed. -- Ralf

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by hyc＠symas.com 08 Dec '09

08 Dec '09

rhafer(a)suse.de wrote: > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: >>> ------------------------------------ >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" >>> type="refreshAndPersist" starttls=critical bindmethod="simple" >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" >>> ------------------------------------ >>> >>> Question is if this is a bug in the documentation or in the code. I think >>> it's the latter. >> >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> >> 1.509. Can you please test and let us know the result? > It solves the problem only partially. It still doesn't work when using > "ldaps://" uris AFAICS. The code was assuming that at least one of the other TLS config keywords would also be used in these situations. Most of the time the slapd TLS config would only be appropriate for server use, and would need to be overridden when acting as a client. Anyway, this is now fixed in 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#6422) configure does not locate ndbclient library
by a.afzali2003＠gmail.com 08 Dec '09

08 Dec '09

Full_Name: afshin afzali Version: openldap-2.4.19 OS: CentOS 5 - 64Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.182.20.153) Hi Guys, As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel package (there is mysql_config & ndbclient library), counfigure does not locate ndbclient library. Also I've upgrade libtools! Best Regards, -- Afshin [root@dc1 openldap-2.4.19]# mysql_config --libs -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ total 51780 -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb --disable-hdb Configuring OpenLDAP 2.4.19-Release ... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking configure arguments... done checking for cc... cc checking for ar... ar checking for style of include used by make... GNU checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... none checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs checking for ranlib... ranlib checking for strip... strip checking if cc static flag works... yes checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... cat: ld.so.conf.d/*.conf: No such file or directory GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool checking how to run the C preprocessor... cc -E checking whether we are using MS Visual C++... no checking for be_app in -lbe... no checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ISO C89... (cached) none needed checking dependency style of cc... (cached) none checking for cc depend flag... -M checking for afopen in -ls... no checking for EBCDIC... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether termios.h defines TIOCGWINSZ... no checking whether sys/ioctl.h defines TIOCGWINSZ... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking arpa/nameser.h usability... yes checking arpa/nameser.h presence... yes checking for arpa/nameser.h... yes checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking bits/types.h usability... yes checking bits/types.h presence... yes checking for bits/types.h... yes checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking crypt.h usability... yes checking crypt.h presence... yes checking for crypt.h... yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking filio.h usability... no checking filio.h presence... no checking for filio.h... no checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking io.h usability... no checking io.h presence... no checking for io.h... no checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking for memory.h... (cached) yes checking psap.h usability... no checking psap.h presence... no checking for psap.h... no checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking process.h usability... no checking process.h presence... no checking for process.h... no checking sgtty.h usability... yes checking sgtty.h presence... yes checking for sgtty.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking sys/fstyp.h usability... no checking sys/fstyp.h presence... no checking for sys/fstyp.h... no checking sys/errno.h usability... yes checking sys/errno.h presence... yes checking for sys/errno.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/privgrp.h usability... no checking sys/privgrp.h presence... no checking for sys/privgrp.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/stat.h... (cached) yes checking sys/syslog.h usability... yes checking sys/syslog.h presence... yes checking for sys/syslog.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for sys/types.h... (cached) yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/vmount.h usability... no checking sys/vmount.h presence... no checking for sys/vmount.h... no checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking for resolv.h... yes checking for netinet/tcp.h... yes checking for sys/ucred.h... no checking for sigaction... yes checking for sigset... yes checking for socket... yes checking for select... yes checking for sys/select.h... (cached) yes checking for sys/socket.h... (cached) yes checking types of arguments for select... int,fd_set *,struct timeval * checking for poll... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/epoll.h usability... yes checking sys/epoll.h presence... yes checking for sys/epoll.h... yes checking for epoll system call... yes checking sys/devpoll.h usability... no checking sys/devpoll.h presence... no checking for sys/devpoll.h... no checking declaration of sys_errlist... yes checking for strerror... yes checking for strerror_r... yes checking non-posix strerror_r... no checking for regex.h... yes checking for library containing regfree... none required checking for compatible POSIX regex... yes checking sys/uuid.h usability... no checking sys/uuid.h presence... no checking for sys/uuid.h... no checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for library containing uuid_generate... -luuid checking for library containing uuid_unparse_lower... none required checking for resolver link (default)... no checking for resolver link (-lresolv)... yes checking for hstrerror... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for gai_strerror... yes checking for inet_ntop... yes checking INET6_ADDRSTRLEN... yes checking struct sockaddr_storage... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... yes checking OpenSSL library version (CRL checking capability)... yes checking for _beginthread... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking POSIX thread version... 10 checking for LinuxThreads pthread.h... no checking for GNU Pth pthread.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for pthread_create in default libraries... no checking for pthread link with -kthread... no checking for pthread link with -pthread... yes checking for sched_yield... yes checking for pthread_yield... yes checking for thr_yield... no checking for pthread_kill... yes checking for pthread_rwlock_destroy with <pthread.h>... yes checking for pthread_detach with <pthread.h>... yes checking for pthread_setconcurrency... yes checking for pthread_getconcurrency... yes checking for thr_setconcurrency... no checking for thr_getconcurrency... no checking for pthread_kill_other_threads_np... no checking for LinuxThreads implementation... no checking for LinuxThreads consistency... no checking if pthread_create() works... yes checking if select yields when using pthreads... yes checking for thread specific errno... yes checking for thread specific h_errno... yes checking for ctime_r... yes checking for gethostbyname_r... yes checking for gethostbyaddr_r... yes checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking for openlog... yes checking for mysql_config... yes checking for NdbApi.hpp... yes checking for ndb_init in -lndbclient... no configure: error: could not locate ndbclient library [root@dc1 openldap-2.4.19]#

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > > ------------------------------------ > > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > > type="refreshAndPersist" starttls=critical bindmethod="simple" > > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > > ------------------------------------ > > > > Question is if this is a bug in the documentation or in the code. I think > > it's the latter. > > Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> > 1.509. Can you please test and let us know the result? It solves the problem only partially. It still doesn't work when using "ldaps://" uris AFAICS. regards, Ralf

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > This fix allows the overlay to use poorly formatted data > since we cannot prevent the user from using it. Which is what I suspect is a misfeature... > A better fix would be to intercept write operations that modify entries in > a manner that would trigger slapo-dynlist(5), and be picky about how URLs > are written. This would not fix existing databases, nor handle cases > where slapo-dynlist(5) is configured using slapd-config(5). Yesbut... LDAP URLs can come from many sources and be used in many contexts; I suppose this would in practice need to treat URL-valued attributes as if they had an URL syntax. I guess we could as an extension, turned on by default. > Or, we could simply become picky about how LDAP URIs are written in general. Yup. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> Well, the fact is that memberURL is stored in the data. As soon as we >> accept that value, we need to deal with it. The current behavior of >> slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be >> parsed). We should rather reject values like this when written in the >> database, but this would probably break other applications. So I >> believe the fix is better than silently ignoring these values. > > I disagree. Data validation in LDAP is generally the user's job, LDAP > syntaxes are very rough in that regard. > > If this is a fix to make dynlist compatible with the rest of OpenLDAP's > handling of URLs in data (e.g. the ref attribute), then this is a good > fix and I'm way to late to complain. But in my view, if this fix is > introducing an incompatibility with the LDAP spec, then it's not. Data validation is the user's responsibility, but here we're using user data (an LDAP URI) to perform internal operations, so if we want to be strict, we should do it when the user writes the data, not when we are going to use it. This fix allows the overlay to use poorly formatted data since we cannot prevent the user from using it. A better fix would be to intercept write operations that modify entries in a manner that would trigger slapo-dynlist(5), and be picky about how URLs are written. This would not fix existing databases, nor handle cases where slapo-dynlist(5) is configured using slapd-config(5). Or, we could simply become picky about how LDAP URIs are written in general. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > Well, the fact is that memberURL is stored in the data. As soon as we > accept that value, we need to deal with it. The current behavior of > slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be > parsed). We should rather reject values like this when written in the > database, but this would probably break other applications. So I > believe the fix is better than silently ignoring these values. I disagree. Data validation in LDAP is generally the user's job, LDAP syntaxes are very rough in that regard. If this is a fix to make dynlist compatible with the rest of OpenLDAP's handling of URLs in data (e.g. the ref attribute), then this is a good fix and I'm way to late to complain. But in my view, if this fix is introducing an incompatibility with the LDAP spec, then it's not. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> When a memberURL contains a simple filter with no brackets, like >> >> ldap:///ou=People,dc=example,dc=com???objectClass=person >> slapo-dynlist(5) is unable to build the composite filter needed >> for the related internal search. >> >> A fix is coming. > > Are you sure that's a good idea to fix? > > It's not a valid LDAP filter, even though OpenLDAP accepts it in > many places. That we accept it from users in tools is fair enough, > but I'm not sure it's a good idea to accept them on the server side. > > Makes them one step closer to interoperability problems if they > reach other servers that do not slap on the necessary parens. Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > When a memberURL contains a simple filter with no brackets, like > > ldap:///ou=People,dc=example,dc=com???objectClass=person > slapo-dynlist(5) is unable to build the composite filter needed > for the related internal search. > > A fix is coming. Are you sure that's a good idea to fix? It's not a valid LDAP filter, even though OpenLDAP accepts it in many places. That we accept it from users in tools is fair enough, but I'm not sure it's a good idea to accept them on the server side. Makes them one step closer to interoperability problems if they reach other servers that do not slap on the necessary parens. -- Hallvard

1 0

(ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando When a memberURL contains a simple filter with no brackets, like ldap:///ou=People,dc=example,dc=com???objectClass=person slapo-dynlist(5) is unable to build the composite filter needed for the related internal search. A fix is coming. p.

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by quanah＠zimbra.com 07 Dec '09

07 Dec '09

--On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > ------------------------------------ > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > type="refreshAndPersist" starttls=critical bindmethod="simple" > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > ------------------------------------ > > Question is if this is a bug in the documentation or in the code. I think > it's the latter. Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> 1.509. Can you please test and let us know the result? Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6420) test058-syncrepl-asymmetric may not clean up
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test058-syncrepl-asymmetric can leave slapd processes behind on failure. It tries to kill them with the command 'KILL' instead of 'kill'. Fixed in rev 1.4 in HEAD.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs