From hyc@symas.com Thu May 1 00:11:50 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5492) Ignore password longer than pwdMinLength specified in PPOLICY Date: Thu, 01 May 2008 00:11:50 +0000 Message-ID: <200805010011.m410BoeW030378@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1617736505242815943==" --===============1617736505242815943== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable huynh.tuan(a)comcast.net wrote: > Full_Name: Tuan Huynh > Version: 2.3.39 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.39.129.66) > > > My password is 10 characters long, however system allowed me to login as lo= ng as > I enter first 8 characters and it ignored the rest even if I enter garbage.= For > example: > > my password is !thisIsATest! > when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdk= dkdk > > I used ppolicy and pwdMinLength is set at 8 Sounds like a configuration error in your Solaris system, or possibly a poor = choice of password hash mechanism. I don't see any evidence of an OpenLDAP bu= g=20 here. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============1617736505242815943==-- From huynh.tuan@comcast.net Thu May 1 00:52:10 2008 From: huynh.tuan@comcast.net To: openldap-bugs@openldap.org Subject: (ITS#5492) Date: Thu, 01 May 2008 00:52:09 +0000 Message-ID: <200805010052.m410q9pF032438@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4207636168414795872==" --===============4207636168414795872== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom ap= peared to be the same. =20 Used crypt to hash password. --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/html Content-Transfer-Encoding: 8bit

I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symt= om appeared to be the same.

Used crypt to hash password.

--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0-- --===============4207636168414795872==-- From hyc@symas.com Thu May 1 01:19:40 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5492) Date: Thu, 01 May 2008 01:19:39 +0000 Message-ID: <200805010119.m411JdRR033665@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3140126120277758987==" --===============3140126120277758987== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable huynh.tuan(a)comcast.net wrote: > --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 > Content-Type: text/plain > Content-Transfer-Encoding: 8bit > > I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom = appeared to be the same. > > Used crypt to hash password. DES-based Unix crypt only checks the first 8 characters. As I said, if you=20 want longer passwords, then your current choice of password hash is no good. = Use some other hash instead. This ITS will be closed. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============3140126120277758987==-- From quanah@zimbra.com Thu May 1 01:23:33 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5491) slapd crashes with ldappasswd Date: Thu, 01 May 2008 01:23:33 +0000 Message-ID: <200805010123.m411NXbU034466@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7521693157648146712==" --===============7521693157648146712== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Wednesday, April 30, 2008 10:34 PM +0000 Deepak.Cheema(a)emerson.com wrote: > Full_Name: Deepak Cheema > Version: 2.4.8 > OS: Red Hat Linux 3.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.189.5.201) > > > Just built, installed openldap 2.4.8 and slapd starts up fine using the > following > > slapd -f slapd.conf -u root > > as root user on default port 389 > > [root(a)dl2k245 libexec]# ps -ef|grep slapd > root 15065 1 0 15:31 ? 00:00:00 ./slapd -f > /dbapps/informatica/l > dap/etc/openldap/slapd.conf -u root > > The process stays up as long as I don't type the ldappasswd command to > get the encrypted password a new user... > > once I type in ldappasswd... this is what happens.. > > [root(a)dl2k245 bin]# ldappasswd > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > additional info: SASL(0): successful result: security flags do not > match > required > [root(a)dl2k245 bin]# ps -ef|grep lapd > root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd > > and the slapd process is no longer there... > > Any ideas why it might be happening or how to debug this? > I tried dbg but it did not tell me much.. maybe I did not use it > correctly... > > Any help is appreciated ! gdb the slapd process, let it run, and then run your ldappasswd command and see where it is segfaulting. Provide a backtrace, etc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============7521693157648146712==-- From yinw@umich.edu Thu May 1 07:31:37 2008 From: Yin Wang To: openldap-bugs@openldap.org Subject: Potential deadlock in back-monitor cache Date: Thu, 01 May 2008 03:34:59 -0400 Message-ID: <200805010731.m417VX5I056272@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8598880930449644421==" --===============8598880930449644421== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit We are working on a project that could relieve from programmer the burden of reasoning about deadlocks, races etc. Our study of the latest OpenLDAP source code shows the following susceptible to deadlock. - monitor_cache_get at servers/slapd/back-monitor/cache.c:163 waiting for mp_mutex while holding mi_cache_mutex - monitor_cache_release at servers/slapd/back-monitor/cache.c:366 waiting for mi_cache_mutex while holding mp_mutex We have not verified this in production run, which could be difficult. Any comment would be greatly appreciated. Yin Wang --===============8598880930449644421==-- From luca@OpenLDAP.org Fri May 2 08:37:15 2008 From: luca@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Fri, 02 May 2008 08:37:14 +0000 Message-ID: <200805020837.m428bENu098819@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8079432450848144127==" --===============8079432450848144127== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit luca(a)OpenLDAP.org wrote: > This is a multi-part message in MIME format. > --------------080809000906010300090306 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Howard Chu wrote: > >> Thanks. Please try HEAD again. >> > No way. > new testrun directory in > ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz > > backtrace attached > recent commits seem to have fixed it (at least, right now I'm not able to reproduce it anymore...) --===============8079432450848144127==-- From hyc@symas.com Fri May 2 09:01:48 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Fri, 02 May 2008 09:01:47 +0000 Message-ID: <200805020901.m4291lfb001035@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3602034741593724458==" --===============3602034741593724458== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable luca(a)OpenLDAP.org wrote: > luca(a)OpenLDAP.org wrote: >> This is a multi-part message in MIME format. >> --------------080809000906010300090306 >> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> Content-Transfer-Encoding: 7bit >> >> Howard Chu wrote: >> >>> Thanks. Please try HEAD again. >>> >> No way. >> new testrun directory in >> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >> >> backtrace attached >> > recent commits seem to have fixed it (at least, right now I'm not able > to reproduce it anymore...) Right. Confirmed here too; I (temporarily) added an assert(0) to the offendin= g=20 branch of code to make sure the patch was actually getting hit. It takes a=20 very particular timing to trigger that code path. I'm not sure how we can reliably test for this down the road. Perhaps we=20 should add a "disabled" config keyword for backends and syncrepl consumers, s= o=20 that we can start up the individual servers, (which takes an unpredictable=20 amount of time for each) and then enable various parts in a fixed sequence=20 (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit or= =20 miss, because our test database is so small it's unlikely that we can hit the= =20 window of time on demand. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============3602034741593724458==-- From rein@OpenLDAP.org Fri May 2 09:42:16 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5489) Assert failed in slapd_clr_write() Date: Fri, 02 May 2008 09:42:15 +0000 Message-ID: <200805020942.m429gFxJ006140@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5979277164557053549==" --===============5979277164557053549== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 30 Apr 2008, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in >> slapd_clr_write() failed, see the stack trace at the end. The >> last log message (at loglevel stat) related to the socket was >> "fd=657 closed (connection lost on write)". The comment where >> slapd_daemon_task() calls connection_write() makes me believe >> that slapd_clr_write() should not have use assert here. Remove >> it or include it as a condition in the following if statement? > > How frequently can you reproduce this? I'm tempted to say move the > assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still > triggers. This is the only occurrence I have found of this abort, so it is not very reproduce able :-( But the core shows that SLAP_SOCK_IS_WRITE would be false (as would SLAP_SOCK_IS_READ), so moving the assert into the if block should fix this case. And asserting a writeable socket is also active makes sence to me. Rein --===============5979277164557053549==-- From yinw@umich.edu Sat May 3 03:56:25 2008 From: Yin Wang To: openldap-bugs@openldap.org Subject: back-bdb cache wrong lock ordering Date: Fri, 02 May 2008 23:59:49 -0500 Message-ID: <200805030356.m433uLZG067629@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3911434495692171585==" --===============3911434495692171585== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Our study shows another potential deadlock in back-bdb/cache.c OpenLDAP 2.4.8 In bdb_cache_release_all(), thread wants to lock the c_lru_mutex at cache.c:1366, while it has the c_rwlock from cache.c:1364 In bdb_cache_delete_internal(), thread wants to lock the c_rwlock at cache.c:1317, while it has the c_lru_mutex from callers, bdb_cache_delete() at cache.c:1259, or bdb_cache_lru_purge() at cache.c:652. Note that two deadlock bugs of the same two mutexes have been reported and verified in the issue tracking system http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4254 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=3494 Yin Wang --===============3911434495692171585==-- From hyc@symas.com Sat May 3 21:30:04 2008 From: Howard Chu To: openldap-bugs@openldap.org Subject: Re: back-bdb cache wrong lock ordering Date: Sat, 03 May 2008 14:27:21 -0700 Message-ID: <481CD8B9.8080400@symas.com> In-Reply-To: <200805030356.m433uLZG067629@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7835123859409752020==" --===============7835123859409752020== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Yin Wang wrote: > Our study shows another potential deadlock in back-bdb/cache.c > OpenLDAP 2.4.8 2.4.8 is a few months old already; 2.4.9 is just about to be released. Your study should be working with CVS HEAD, to avoid reporting on bugs that have already been fixed. Working with old code isn't useful. > In bdb_cache_release_all(), thread wants to lock the c_lru_mutex > at cache.c:1366, while it has the c_rwlock from cache.c:1364 The locks in that function are superfluous, since it can only be called while the database is shutting down. There are no other active threads when this function runs. > In bdb_cache_delete_internal(), thread wants to lock the c_rwlock > at cache.c:1317, while it has the c_lru_mutex from callers, > bdb_cache_delete() at cache.c:1259, or bdb_cache_lru_purge() at > cache.c:652. > > Note that two deadlock bugs of the same two mutexes have been > reported and verified in the issue tracking system > > http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4254 > > http://www.openldap.org/its/index.cgi/Software%20Bugs?id=3494 Those bug reports were closed 2-3 years ago. You need to focus on something recent in order to have any relevance. > Yin Wang -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7835123859409752020==-- From quanah@OpenLDAP.org Sat May 3 23:07:27 2008 From: quanah@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5493) CSN updates with delta-syncrepl refresh Date: Sat, 03 May 2008 23:07:26 +0000 Message-ID: <200805032307.m43N7QDm015775@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5539328064026435945==" --===============5539328064026435945== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Quanah Gibson-Mount Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) When delta-syncrepl is refreshing from the accesslog DB, it should update its local CSN after every modification, rather than waiting until all updates have propagated and then updating its CSN, in case slapd is shut down or dies, etc, while in the update process. This comes from the thread: --Quanah --===============5539328064026435945==-- From rein@OpenLDAP.org Sun May 4 10:46:54 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search Date: Sun, 04 May 2008 10:46:54 +0000 Message-ID: <200805041046.m44Aksb8039090@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1226101875044268981==" --===============1226101875044268981== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 30 Apr 2008, Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> syncprov_findbase() must search the backend saved with the syncrepl >> operation, >> not the one from the operation passed as argument. The backend in the op >> argument can be a subordinate database, in which case the search for the >> base in >> the superior database will fail, and syncrepl consumers will be force to do >> a an >> unneccessary full refresh of the database. > > OK. > >> The patch at the end should fix >> this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the >> overlay_op_walk() call, which is the reason for the long pointer traversal >> to >> find the correct bd_info to save and restore. > But the overlay_op_walk call is only appropriate when the DB to be searched > is the current database, and the current DB is an overlay DB structure. Ah, the changing of the BackendDB->bd_info that takes place when overlays are called feels like an open pit I manage to fall into every time I get close to it... I wish it could be replaced in a future version. > Your patch causes fc->fss->s_op->o_bd's bd_info pointer to change, which is > not allowed. That's in the original backendDB, which must be treated as > read-only since multiple threads may be accessing it. The correct approach > here is to use a new local backendDB variable, copy the s_op->o_bd into it, > and then just do a regular be_search invocation instead of using > overlay_op_walk. > > But, this patch must not take effect on the first call to syncprov_findbase > (which occurred in syncprov_op_search) - in that case, the current code is > correct. So, you need to tweak things based on whether (s_flags & > PS_IS_REFRESHING) is true or not - if true, this is the first search, and it > should use the original code. Else, it must use be_search. A new patch that I hope should fix this is at the end. It always use be_search, after putting back the original bd_info if needed. I feel that using the generic be_search is better than interfering directly with the overlay code as overlay_op_walk does. I also tested for SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more generic to me. But again, I may be totally wrong here. Does this patch look better? Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.1.1.18 diff -u -u -r1.1.1.18 syncprov.c --- OpenLDAP/servers/slapd/overlays/syncprov.c 30 Apr 2008 11:17:58 -0000 1.1= .1.18 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 2 May 2008 11:19:46 -0000 @@ -404,7 +404,7 @@ slap_callback cb =3D {0}; Operation fop; SlapReply frs =3D { REP_RESULT }; - BackendInfo *bi; + BackendDB be; int rc; fc->fss->s_flags ^=3D PS_FIND_BASE; @@ -413,10 +413,15 @@ fop =3D *fc->fss->s_op; fop.o_hdr =3D op->o_hdr; - fop.o_bd =3D op->o_bd; fop.o_time =3D op->o_time; fop.o_tincr =3D op->o_tincr; - bi =3D op->o_bd->bd_info; + + if ( SLAP_ISOVERLAY( fop.o_bd )) { + slap_overinst *on =3D (slap_overinst *)fop.o_bd->bd_info; + be =3D *fop.o_bd; + be.bd_info =3D (BackendInfo *)on->on_info; + fop.o_bd =3D &be; + } cb.sc_response =3D findbase_cb; cb.sc_private =3D fc; @@ -434,8 +439,7 @@ fop.ors_filter =3D &generic_filter; fop.ors_filterstr =3D generic_filterstr; - rc =3D overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info =3D bi; + rc =3D fop.o_bd->be_search( &fop, &frs ); } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase =3D 1; --===============1226101875044268981==-- From adejong@debian.org Sun May 4 10:53:46 2008 From: adejong@debian.org To: openldap-bugs@openldap.org Subject: (ITS#5494) slapd crashed when accessed by multiple threads Date: Sun, 04 May 2008 10:53:46 +0000 Message-ID: <200805041053.m44ArkKL040013@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2573963192620256791==" --===============2573963192620256791== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Arthur de Jong Version: 2.4.7 OS: Debian unstable URL: http://arthurenhella.demon.nl/nss-ldapd/adejong-slapd-crash.log Submission from: (NULL) (83.160.165.27) This has also been submitted as a Debian bug: http://bugs.debian.org/479237 My test slapd consistently crashes when doing multiple simultaneous requests in different threads. Each thread has it's own LDAP *ld connection to the LDAP server which is supposed to be supported [1]. In any case this shouldn't crash the LDAP server. [1] http://www.openldap.org/lists/openldap-software/200606/msg00252.html This problem arises in my test suite for nss-ldapd. Source can be checked out at http://arthurenhella.demon.nl/svn/nss-ldapd/ (svn) and the test file is (test/test_myldap.c). It uses a wrapper module (myldap) around calls to OpenLDAP to simplify memory management. The function that triggers the crash is test_threads(). I have captured the crash in gdb: # gdb /usr/sbin/slapd GNU gdb 6.8-debian [...] This GDB was configured as "i486-linux-gnu"... (gdb) r -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f /etc/ldap/slapd.conf Starting program: /usr/sbin/slapd -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f /etc/ldap/slapd.conf [Thread debugging using libthread_db enabled] [New Thread 0xb7b3a930 (LWP 1542)] @(#) $OpenLDAP: slapd 2.4.7 (Apr 16 2008 08:13:31) $ @minerva.hungry.com:/home/pere/src/debiancvs/initscripts-ng-svn/trunk= /src/insserv/openldap2.3-2.4.7/debian/build/servers/slapd ldap_pvt_gethostbyname_a: host=3Dsorbet, r=3D0 daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... [...] <=3D send_search_entry: conn 2 exit. entry_decode: "cn=3DZaka Eddins+uid=3Dzeddins,ou=3Dlotsofpeople,dc=3Dtest,dc= =3Dtld" <=3D entry_decode(cn=3DZaka Eddins+uid=3Dzeddins,ou=3Dlotsofpeople,dc=3Dtest,= dc=3Dtld) =3D> send_search_entry: conn 2 dn=3D"cn=3DZaka Eddins+uid=3Dzeddins,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld" ber_flush2: 107 bytes to sd 18 <=3D send_search_entry: conn 2 exit. entry_decode: "uid=3Dwvakil,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld" <=3D entry_decode(uid=3Dwvakil,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld) =3D> send_search_entry: conn 2 dn=3D"uid=3Dwvakil,ou=3Dlotsofpeople,dc=3Dtest= ,dc=3Dtld" ber_flush2: 90 bytes to sd 18 <=3D send_search_entry: conn 2 exit. entry_decode: "uid=3Dzmeeker,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld" <=3D entry_decode(uid=3Dzmeeker,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld) =3D> send_search_entry: conn 2 dn=3D"uid=3Dzmeeker,ou=3Dlotsofpeople,dc=3Dtes= t,dc=3Dtld" ber_flush2: 92 bytes to sd 18 <=3D send_search_entry: conn 2 exit. bdb_search: 1104 scope not okay Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5f18b90 (LWP 5017)] 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0xb7f4351d in ldap_pvt_thread_mutex_lock () from /usr/lib/libldap_r-2.4.so.2 #2 0xb783883d in bdb_cache_return_entry_rw (bdb=3D0x81ea358, e=3D0x820922c, = rw=3D0, lock=3D0xb5f16fd4) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap= 2.3-2.4.7/servers/slapd/back-bdb/cache.c:256 #3 0xb782ce12 in bdb_search (op=3D0x8299b10, rs=3D0xb5f18168) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap= 2.3-2.4.7/servers/slapd/back-bdb/search.c:909 #4 0x08077d13 in fe_op_search (op=3D0x8299b10, rs=3D0xb5f18168) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap= 2.3-2.4.7/servers/slapd/search.c:368 #5 0x0807853c in do_search (op=3D0x8299b10, rs=3D0xb5f18168) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap= 2.3-2.4.7/servers/slapd/search.c:217 #6 0x080757c6 in connection_operation (ctx=3D0xb5f18248, arg_v=3D0x8299b10) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap= 2.3-2.4.7/servers/slapd/connection.c:1083 #7 0x08075ed6 in connection_read_thread (ctx=3D0xb5f18248, argv=3D0x13) at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openldap= 2.3-2.4.7/servers/slapd/connection.c:1210 #8 0xb7f42a44 in ?? () from /usr/lib/libldap_r-2.4.so.2 #9 0xb5f18248 in ?? () #10 0x00000013 in ?? () #11 0x00000000 in ?? () A more detailed backtrace is available at the url specified below. --===============2573963192620256791==-- From rein@OpenLDAP.org Sun May 4 11:28:12 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers Date: Sun, 04 May 2008 11:28:12 +0000 Message-ID: <200805041128.m44BSCoS041549@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8488773179485478265==" --===============8488773179485478265== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 30 Apr 2008, Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> When syncrepl and syncprov are both used on a glue database, the >> contextCSN received from the syncrepl producers are not passed on to the >> syncprov consumers when changes in subordinate databases are received. >> The reason is that syncrepl queues the CSNs in the glue backend, while >> syncprov fetches them from the backend where the changes are made. As a >> consequence, the consumers will be passed a cookie without any csn >> value. >> >> My first attempt at fixing this was to change syncprov to fetch the >> queued csn values from the glue backend where it was used. But that >> failed as other modules queues the csn values in their own backend when >> they changes things. > > What other modules? Generally there cannot be any other sources of changes. Sorry, I should have written other configurations. The CSNs gets queued in the subordinate database when syncrepl is used there, or not at all (i.e in regular updates that comes in through the frontend). >> Instead I changed ctxcsn.c so that it always >> queues them in the glue backend where syncprov is used. But I don't >> feel that my understanding of this stuff is good enough to be sure that >> this is the optimal solution.. > > I definitely don't like references to the syncprov overlay appearing in main > slapd code like that. We need a different solution. That's reasonable, but the test for syncrepl is probably not needed if this solution should be kept. The test was more or less a copy and paste from syncrepl where it finds out which backend to write through. To me it makes sense to have a single queue of CSN values in a glued configuration, no matter if or where syncprov is used. > At one point in the past, I had changed syncrepl.c to queue the CSNs in > both places, but that seemed rather sloppy. Still, it may work best here. I don't like duplicating information, sooner or later it tends to end up with wrong info in one of the places.. Another approach could be to have syncprov look in the glue database if it fails to find any queued CSN in a subordinate db. I haven't tested it, but that should work in both configurations. It should also remove the need to always look for the glue db which my patch requires. Would that be better? >> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >> test, should that have included an overlay_is_inst() clause as well? > > Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on > that call. The current test (introduced to fix ITS#5433) causes the contextCSN to be written to the glue database when syncprov is used on a subordinate db, which appears wrong to me. Could you elaborate on when op->o_bd->bd_self must be used instead of op->o_bd? I understand that op->o_bd may be a copy of the original structure that op->o_bd->bd_self refers to, but I'm not sure when it must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch the BackendInfo that can be used to call the top-most bd_search (and similar) also in overlays? Rein --===============8488773179485478265==-- From hyc@symas.com Sun May 4 11:35:54 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search Date: Sun, 04 May 2008 11:35:54 +0000 Message-ID: <200805041135.m44BZsaY042376@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3030841631373998482==" --===============3030841631373998482== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rein Tollevik wrote: > On Wed, 30 Apr 2008, Howard Chu wrote: > >> rein(a)OpenLDAP.org wrote: > >>> syncprov_findbase() must search the backend saved with the syncrepl >>> operation, >>> not the one from the operation passed as argument. The backend in the op >>> argument can be a subordinate database, in which case the search for the >>> base in >>> the superior database will fail, and syncrepl consumers will be force to = do >>> a an >>> unneccessary full refresh of the database. >> OK. >> >>> The patch at the end should fix >>> this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the >>> overlay_op_walk() call, which is the reason for the long pointer traversal >>> to >>> find the correct bd_info to save and restore. > >> But the overlay_op_walk call is only appropriate when the DB to be searched >> is the current database, and the current DB is an overlay DB structure. > > Ah, the changing of the BackendDB->bd_info that takes place when > overlays are called feels like an open pit I manage to fall into every > time I get close to it... I wish it could be replaced in a future > version. Agreed, it would have been safer as an Op-specific field, but that would have= =20 caused quite a lot of disruption to all existing backend code. > A new patch that I hope should fix this is at the end. It always use > be_search, after putting back the original bd_info if needed. I feel > that using the generic be_search is better than interfering directly > with the overlay code as overlay_op_walk does. I also tested for > SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more > generic to me. But again, I may be totally wrong here. Does this patch > look better? SLAP_IS_OVERLAY will never be true here. That flag is only set when the=20 BackendDB being tested is a local copy of a real BackendDB structure. The=20 structure referenced in s_op is always a real BackendDB. In fact, if you're always going to use s_op and be_search, there's no further= =20 work needed, because the regular overlay infrastructure will always make a ne= w=20 local BackendDB copy itself. (And of course, some of that would be wasted=20 effort, which is why the original code uses overlay_op_walk. Since op->o_bd i= s=20 already an overlay DB, there's no need to make yet another copy for the=20 first-search case.) --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============3030841631373998482==-- From hyc@symas.com Sun May 4 11:51:08 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers Date: Sun, 04 May 2008 11:51:07 +0000 Message-ID: <200805041151.m44Bp7x4043351@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5008285733841047169==" --===============5008285733841047169== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rein Tollevik wrote: > On Wed, 30 Apr 2008, Howard Chu wrote: >> rein(a)OpenLDAP.org wrote: >>> My first attempt at fixing this was to change syncprov to fetch the >>> queued csn values from the glue backend where it was used. But that >>> failed as other modules queues the csn values in their own backend when >>> they changes things. >> What other modules? Generally there cannot be any other sources of changes. > > Sorry, I should have written other configurations. The CSNs gets queued > in the subordinate database when syncrepl is used there, or not at all > (i.e in regular updates that comes in through the frontend). OK, but that's again quite a special case. I.e., that's multi-master; in the = default (single-master) case there cannot be regular updates arriving through= =20 the frontend. When a single-master syncrepl consumer is configured, that is=20 the only possible source of updates. Let's be sure we've solved this question= =20 for the single-master case first, before addressing the multi-master case. While it's expected that the software will be able to handle multiple glued=20 DBs and multi-master across them, I seriously doubt that anyone out there=20 actually knows how to configure and maintain such a setup yet. >>> Instead I changed ctxcsn.c so that it always >>> queues them in the glue backend where syncprov is used. But I don't >>> feel that my understanding of this stuff is good enough to be sure that >>> this is the optimal solution.. >> I definitely don't like references to the syncprov overlay appearing in ma= in >> slapd code like that. We need a different solution. > To me it makes sense to have a single queue of CSN values in a glued > configuration, no matter if or where syncprov is used. Yes, I can probably go along with that. The downside is that it may reduce=20 write concurrency a bit, compared to a glued configuration where each glued D= B=20 is otherwise independent. > Another approach could be to have syncprov look in the glue database if > it fails to find any queued CSN in a subordinate db. I haven't tested > it, but that should work in both configurations. It should also remove > the need to always look for the glue db which my patch requires. Would > that be better? That sounds like a decent alternative. >>> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >>> test, should that have included an overlay_is_inst() clause as well? >> Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on >> that call. > The current test (introduced to fix ITS#5433) causes the contextCSN to > be written to the glue database when syncprov is used on a subordinate > db, which appears wrong to me. Understood. Again, the question is whether the admin intended to configure a single=20 syncprov over an entire glued DB, or individual syncprovs over each component= =20 of the glued tree. The distinction is vital, and it's detected based on=20 whether the syncprov overlay is above the glue overlay in the overlay stack, = or below it, on the topmost DB. > Could you elaborate on when op->o_bd->bd_self must be used instead of > op->o_bd? I understand that op->o_bd may be a copy of the original > structure that op->o_bd->bd_self refers to, but I'm not sure when it > must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch > the BackendInfo that can be used to call the top-most bd_search (and > similar) also in overlays? If you read the code for overlay_is_inst() it should be obvious - that=20 function only works when used with a real BackendDB structure. The local copy= =20 structure has had its bd_info replaced with whatever on_inst structure=20 corresponds to the current overlay. Yes, the bd_self points to the topmost structure, so you can use it for=20 be_search. Much of what's happening in these overlays was intended to avoid=20 starting over at the top though, because the code is already running in the=20 desired overlay context. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5008285733841047169==-- From naga.gangadhar@gmail.com Mon May 5 06:07:36 2008 From: naga.gangadhar@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5495) cpu consuption Date: Mon, 05 May 2008 06:07:36 +0000 Message-ID: <200805050607.m4567a4v083705@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1856385754582072796==" --===============1856385754582072796== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Naga Gangadhar Reddy Version: 2.4.19 OS: cent-os URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.212.208.159) slapd is taking 100% cpu though the memory consumption is just 0.9%. --===============1856385754582072796==-- From raphael.ouazana@linagora.com Mon May 5 14:06:20 2008 From: raphael.ouazana@linagora.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Mon, 05 May 2008 14:06:20 +0000 Message-ID: <200805051406.m45E6KeE010647@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9125757025376975283==" --===============9125757025376975283== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, Le Ven 2 mai 2008 11:01, hyc(a)symas.com a écrit : > luca(a)OpenLDAP.org wrote: >> luca(a)OpenLDAP.org wrote: >>> This is a multi-part message in MIME format. >>> --------------080809000906010300090306 >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Howard Chu wrote: >>> >>>> Thanks. Please try HEAD again. >>>> >>> No way. >>> new testrun directory in >>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >>> >>> backtrace attached >>> >> recent commits seem to have fixed it (at least, right now I'm not able >> to reproduce it anymore...) > > Right. Confirmed here too; I (temporarily) added an assert(0) to the > offending > branch of code to make sure the patch was actually getting hit. It takes a > very particular timing to trigger that code path. > > I'm not sure how we can reliably test for this down the road. Perhaps we > should add a "disabled" config keyword for backends and syncrepl > consumers, so > that we can start up the individual servers, (which takes an unpredictable > amount of time for each) and then enable various parts in a fixed sequence > (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit > or > miss, because our test database is so small it's unlikely that we can hit > the > window of time on demand. I'm testing the last RE24 tag. After 201 successful runs of test050, I got a failure :/ Cleaning up test run directory leftover from previous run. Running ./scripts/test050-syncrepl-multimaster... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! testrun uploaded in ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-080505.tgz Regards, Raphaël Ouazana. --===============9125757025376975283==-- From jwm@horde.net Mon May 5 17:31:15 2008 From: jwm@horde.net To: openldap-bugs@openldap.org Subject: (ITS#5496) delta-syncrepl consumers don't update backend contextCSN after processing each entry Date: Mon, 05 May 2008 17:31:15 +0000 Message-ID: <200805051731.m45HVFvL031061@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1778021591984016469==" --===============1778021591984016469== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: John Morrissey Version: 2.3.41 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) delta-syncrepl does not update the backend's contextCSN after processing each replication event. This exposes slapd to problems in the event of a power los= s, crash, etc. as it will attempt to re-process the replication entries once re-started. Relevant thread on openldap-software starts here: http://marc.info/?l=3Dopenldap-software&m=3D120965853100883&w=3D2 and Howard's summary of the behavior is here: http://marc.info/?l=3Dopenldap-software&m=3D120967526528453&w=3D2 --===============1778021591984016469==-- From rein@OpenLDAP.org Mon May 5 20:49:12 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search Date: Mon, 05 May 2008 20:49:11 +0000 Message-ID: <200805052049.m45KnB4G040897@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0678774029342439694==" --===============0678774029342439694== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 4 May 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: >> A new patch that I hope should fix this is at the end. It always use >> be_search, after putting back the original bd_info if needed. I feel >> that using the generic be_search is better than interfering directly >> with the overlay code as overlay_op_walk does. I also tested for >> SLAP_ISOVERLAY rather than PS_IS_REFRESHING, as that appeared more >> generic to me. But again, I may be totally wrong here. Does this >> patch look better? > > SLAP_IS_OVERLAY will never be true here. That flag is only set when the > BackendDB being tested is a local copy of a real BackendDB structure. The > structure referenced in s_op is always a real BackendDB. No, it is true when syncprov_findbase is called from syncprov_op_search, as s_op is the op passed to that function. The new patch at the end uses o_bd->bd_self, which should eliminate this test since copying the db is not necessary. > In fact, if you're always going to use s_op and be_search, there's no > further work needed, because the regular overlay infrastructure will > always make a new local BackendDB copy itself. (And of course, some of > that would be wasted effort, which is why the original code uses > overlay_op_walk. Since op->o_bd is already an overlay DB, there's no > need to make yet another copy for the first-search case.) I understand, but I still prefer the clarity of always using be_search. After all, this function is only called the first time a consumer is initialized or after an update of the search base entry. I.e the few extra cycles shouldn't be measurable, even when the search base is the glue suffix where updates of the contextCSN causes the entry to be written more often than most other entries. Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.1.1.18 retrieving revision 1.20 diff -u -u -r1.1.1.18 -r1.20 --- OpenLDAP/servers/slapd/overlays/syncprov.c 30 Apr 2008 11:17:58 -0000 1.1= .1.18 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 17:45:38 -0000 1.20 @@ -404,7 +404,6 @@ slap_callback cb =3D {0}; Operation fop; SlapReply frs =3D { REP_RESULT }; - BackendInfo *bi; int rc; fc->fss->s_flags ^=3D PS_FIND_BASE; @@ -412,11 +411,10 @@ fop =3D *fc->fss->s_op; + fop.o_bd =3D fop.o_bd->bd_self; fop.o_hdr =3D op->o_hdr; - fop.o_bd =3D op->o_bd; fop.o_time =3D op->o_time; fop.o_tincr =3D op->o_tincr; - bi =3D op->o_bd->bd_info; cb.sc_response =3D findbase_cb; cb.sc_private =3D fc; @@ -434,8 +432,7 @@ fop.ors_filter =3D &generic_filter; fop.ors_filterstr =3D generic_filterstr; - rc =3D overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info =3D bi; + rc =3D fop.o_bd->be_search( &fop, &frs ); } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase =3D 1; --===============0678774029342439694==-- From rein@OpenLDAP.org Mon May 5 21:09:45 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers Date: Mon, 05 May 2008 21:09:45 +0000 Message-ID: <200805052109.m45L9jti043295@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4366958286023174658==" --===============4366958286023174658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 4 May 2008, hyc(a)symas.com wrote: > Rein Tollevik wrote: >> On Wed, 30 Apr 2008, Howard Chu wrote: >>> rein(a)OpenLDAP.org wrote: >>>> My first attempt at fixing this was to change syncprov to fetch the >>>> queued csn values from the glue backend where it was used. But that >>>> failed as other modules queues the csn values in their own backend when >>>> they changes things. >>> What other modules? Generally there cannot be any other sources of change= s. >> >> Sorry, I should have written other configurations. The CSNs gets queued >> in the subordinate database when syncrepl is used there, or not at all >> (i.e in regular updates that comes in through the frontend). > > OK, but that's again quite a special case. I.e., that's multi-master; in the > default (single-master) case there cannot be regular updates arriving throu= gh > the frontend. When a single-master syncrepl consumer is configured, that is > the only possible source of updates. Let's be sure we've solved this questi= on > for the single-master case first, before addressing the multi-master case. No, I'm thinking about single-master glued configurations where either: 1) The server is the single master for the subordinate backend or 2) The server is a syncrepl consumer for the subordinate backend, and syncrepl is configured on the subordinate db. In both cases is the CSN values queued in the subordinate database where syncprov looks for the values. The case that don't work is when syncrepl and syncprov are both used on the glue database, but still in single-master mode (although I don't think that matter). I.e, this server acts like a kind of forwarding server, it replicates the changes it receives from its producer to its own consumers. In this case syncrepl queues the CSN values in the glue database, while syncprov still looks for them in the subordinate database where the actual changes are made. > While it's expected that the software will be able to handle multiple glued > DBs and multi-master across them, I seriously doubt that anyone out there > actually knows how to configure and maintain such a setup yet. I haven't looked at multi-master yet, although I have multiple master servers that replicate between each other. But each backend database has a clearly defined single master, so this is not what I think about as multi-master configurations. >>>> Instead I changed ctxcsn.c so that it always >>>> queues them in the glue backend where syncprov is used. But I don't >>>> feel that my understanding of this stuff is good enough to be sure that >>>> this is the optimal solution.. >>> I definitely don't like references to the syncprov overlay appearing in m= ain >>> slapd code like that. We need a different solution. > >> To me it makes sense to have a single queue of CSN values in a glued >> configuration, no matter if or where syncprov is used. > > Yes, I can probably go along with that. The downside is that it may reduce > write concurrency a bit, compared to a glued configuration where each glued= DB > is otherwise independent. Which again should imply that the best fix probably is to change syncrepl so that it queues the csn values in the backends where the changes are made? >> Another approach could be to have syncprov look in the glue database if >> it fails to find any queued CSN in a subordinate db. I haven't tested >> it, but that should work in both configurations. It should also remove >> the need to always look for the glue db which my patch requires. Would >>> that be better? > > That sounds like a decent alternative. A new patch that implements this is at the end. Is this OK or should we go for the syncrepl alternative instead? >>>> Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE >>>> test, should that have included an overlay_is_inst() clause as well? >>> Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on >>> that call. > >> The current test (introduced to fix ITS#5433) causes the contextCSN to >> be written to the glue database when syncprov is used on a subordinate >> db, which appears wrong to me. > > Understood. > > Again, the question is whether the admin intended to configure a single > syncprov over an entire glued DB, or individual syncprovs over each compone= nt > of the glued tree. The distinction is vital, and it's detected based on > whether the syncprov overlay is above the glue overlay in the overlay stack, > or below it, on the topmost DB. Yes, the first case is what I'm using, it works with the current code. The second is what I'm afraid got broken by this patch. Although I haven't tried the second type, so I'm not sure.. >> Could you elaborate on when op->o_bd->bd_self must be used instead of >> op->o_bd? I understand that op->o_bd may be a copy of the original >> structure that op->o_bd->bd_self refers to, but I'm not sure when it >> must be used. Btw, could op->o_bd->bd_self->bd_info be used to fetch >> the BackendInfo that can be used to call the top-most bd_search (and >> similar) also in overlays? > > If you read the code for overlay_is_inst() it should be obvious - that > function only works when used with a real BackendDB structure. The local co= py > structure has had its bd_info replaced with whatever on_inst structure > corresponds to the current overlay. OK, I understand that one. I had hoped for a general rule, but am afraid that can't be given. And if we should continue this discussion I guess it's time to move it to openldap-devel. > Yes, the bd_self points to the topmost structure, so you can use it for > be_search. Much of what's happening in these overlays was intended to avoid > starting over at the top though, because the code is already running in the > desired overlay context. Ah, good. Using that is much clearer than to cast op->o_bd->bd_info into an overinst pointer and fetching it there :-) Rein Index: OpenLDAP/servers/slapd/overlays/syncprov.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/overlays/syncprov.c,v retrieving revision 1.20 diff -u -u -r1.20 syncprov.c --- OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 17:45:38 -0000 1.20 +++ OpenLDAP/servers/slapd/overlays/syncprov.c 5 May 2008 20:58:35 -0000 @@ -1589,6 +1589,17 @@ cbuf[0] =3D '\0'; ldap_pvt_thread_rdwr_wlock( &si->si_csn_rwlock ); slap_get_commit_csn( op, &maxcsn ); + if ( BER_BVISNULL( &maxcsn ) && SLAP_GLUE_SUBORDINATE( op->o_bd )) { + /* syncrepl queues the CSN values in the db where + * it is configured , not where the changes are made. + * So look for a value in the glue db if we didn't + * find any in this db. + */ + BackendDB *be =3D op->o_bd; + op->o_bd =3D select_backend( &be->be_nsuffix[0], 1); + slap_get_commit_csn( op, &maxcsn ); + op->o_bd =3D be; + } if ( !BER_BVISNULL( &maxcsn ) ) { int i, sid; strcpy( cbuf, maxcsn.bv_val ); --===============4366958286023174658==-- From hyc@symas.com Mon May 5 21:11:41 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Mon, 05 May 2008 21:11:41 +0000 Message-ID: <200805052111.m45LBf3K044048@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5559334457759021156==" --===============5559334457759021156== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rapha=C3=ABl Ouazana-Sustowski wrote: > Hi, > > Le Ven 2 mai 2008 11:01, hyc(a)symas.com a =C3=A9crit : >> luca(a)OpenLDAP.org wrote: >>> luca(a)OpenLDAP.org wrote: >>>> This is a multi-part message in MIME format. >>>> --------------080809000906010300090306 >>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Howard Chu wrote: >>>> >>>>> Thanks. Please try HEAD again. >>>>> >>>> No way. >>>> new testrun directory in >>>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz >>>> >>>> backtrace attached >>>> >>> recent commits seem to have fixed it (at least, right now I'm not able >>> to reproduce it anymore...) >> Right. Confirmed here too; I (temporarily) added an assert(0) to the >> offending >> branch of code to make sure the patch was actually getting hit. It takes a >> very particular timing to trigger that code path. >> >> I'm not sure how we can reliably test for this down the road. Perhaps we >> should add a "disabled" config keyword for backends and syncrepl >> consumers, so >> that we can start up the individual servers, (which takes an unpredictable >> amount of time for each) and then enable various parts in a fixed sequence >> (e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit >> or >> miss, because our test database is so small it's unlikely that we can hit >> the >> window of time on demand. > > I'm testing the last RE24 tag. After 201 successful runs of test050, I got > a failure :/ > Cleaning up test run directory leftover from previous run. > Running ./scripts/test050-syncrepl-multimaster... > running defines.sh > Initializing server configurations... > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > Starting consumer2 slapd on TCP/IP port 9013... > Using ldapsearch to check that consumer2 slapd is running... > Configuring syncrepl on consumer2... > Adding schema and databases on producer... > Using ldapadd to populate producer... > Waiting 20 seconds for syncrepl to receive changes... > Using ldapadd to populate consumer... > Waiting 20 seconds for syncrepl to receive changes... > Using ldapsearch to check that syncrepl received database changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > Waiting 5 seconds for syncrepl to receive changes... > ldapsearch failed (32)! > > testrun uploaded in > ftp://ftp.openldap.org/incoming/raphael-ouazana-testrun-080505.tgz The logs show that the syncrepl consumers all timed out periodically, when=20 trying to bind to a provider. It seems that using a 1 second timeout in the=20 syncrepl configs is too short, or your test machine was too slow during that = run. Probably we should remove that timeout now, since the cn=3Dconfig/thread paus= e=20 issue has already been resolved. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5559334457759021156==-- From hyc@symas.com Tue May 6 01:30:59 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5494) slapd crashed when accessed by multiple threads Date: Tue, 06 May 2008 01:30:58 +0000 Message-ID: <200805060130.m461UwX7061195@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4755194735599619372==" --===============4755194735599619372== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is most likely the same as ITS#5439, fixed in HEAD/RE24/2.4.9. Please test against a more recent release. adejong(a)debian.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.7 > OS: Debian unstable > URL: http://arthurenhella.demon.nl/nss-ldapd/adejong-slapd-crash.log > Submission from: (NULL) (83.160.165.27) > > > This has also been submitted as a Debian bug: > http://bugs.debian.org/479237 > > My test slapd consistently crashes when doing multiple simultaneous > requests in different threads. Each thread has it's own LDAP *ld > connection to the LDAP server which is supposed to be supported [1]. In > any case this shouldn't crash the LDAP server. > > [1] http://www.openldap.org/lists/openldap-software/200606/msg00252.html > > This problem arises in my test suite for nss-ldapd. Source can be > checked out at http://arthurenhella.demon.nl/svn/nss-ldapd/ (svn) and > the test file is (test/test_myldap.c). It uses a wrapper module (myldap) > around calls to OpenLDAP to simplify memory management. The function > that triggers the crash is test_threads(). > > I have captured the crash in gdb: > > # gdb /usr/sbin/slapd > GNU gdb 6.8-debian > [...] > This GDB was configured as "i486-linux-gnu"... > (gdb) r -d 1 -h ldap:/// ldaps:/// ldapi:/// -g openldap -u openldap -f > /etc/ldap/slapd.conf > Starting program: /usr/sbin/slapd -d 1 -h ldap:/// ldaps:/// ldapi:/// -g > openldap -u openldap -f /etc/ldap/slapd.conf > [Thread debugging using libthread_db enabled] > [New Thread 0xb7b3a930 (LWP 1542)] > @(#) $OpenLDAP: slapd 2.4.7 (Apr 16 2008 08:13:31) $ > @minerva.hungry.com:/home/pere/src/debiancvs/initscripts-ng-svn/tr= unk/src/insserv/openldap2.3-2.4.7/debian/build/servers/slapd > ldap_pvt_gethostbyname_a: host=3Dsorbet, r=3D0 > daemon_init: listen on ldap:/// > daemon_init: 1 listeners to open... > [...] > <=3D send_search_entry: conn 2 exit. > entry_decode: "cn=3DZaka Eddins+uid=3Dzeddins,ou=3Dlotsofpeople,dc=3Dtest,d= c=3Dtld" > <=3D entry_decode(cn=3DZaka Eddins+uid=3Dzeddins,ou=3Dlotsofpeople,dc=3Dtes= t,dc=3Dtld) > =3D> send_search_entry: conn 2 dn=3D"cn=3DZaka > Eddins+uid=3Dzeddins,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld" > ber_flush2: 107 bytes to sd 18 > <=3D send_search_entry: conn 2 exit. > entry_decode: "uid=3Dwvakil,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld" > <=3D entry_decode(uid=3Dwvakil,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld) > =3D> send_search_entry: conn 2 dn=3D"uid=3Dwvakil,ou=3Dlotsofpeople,dc=3Dt= est,dc=3Dtld" > ber_flush2: 90 bytes to sd 18 > <=3D send_search_entry: conn 2 exit. > entry_decode: "uid=3Dzmeeker,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld" > <=3D entry_decode(uid=3Dzmeeker,ou=3Dlotsofpeople,dc=3Dtest,dc=3Dtld) > =3D> send_search_entry: conn 2 dn=3D"uid=3Dzmeeker,ou=3Dlotsofpeople,dc=3D= test,dc=3Dtld" > ber_flush2: 92 bytes to sd 18 > <=3D send_search_entry: conn 2 exit. > bdb_search: 1104 scope not okay > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb5f18b90 (LWP 5017)] > 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 > (gdb) bt > #0 0xb7cef160 in pthread_mutex_lock () from /lib/libpthread.so.0 > #1 0xb7f4351d in ldap_pvt_thread_mutex_lock () from > /usr/lib/libldap_r-2.4.so.2 > #2 0xb783883d in bdb_cache_return_entry_rw (bdb=3D0x81ea358, e=3D0x820922c= , rw=3D0, > lock=3D0xb5f16fd4) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openl= dap2.3-2.4.7/servers/slapd/back-bdb/cache.c:256 > #3 0xb782ce12 in bdb_search (op=3D0x8299b10, rs=3D0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openl= dap2.3-2.4.7/servers/slapd/back-bdb/search.c:909 > #4 0x08077d13 in fe_op_search (op=3D0x8299b10, rs=3D0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openl= dap2.3-2.4.7/servers/slapd/search.c:368 > #5 0x0807853c in do_search (op=3D0x8299b10, rs=3D0xb5f18168) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openl= dap2.3-2.4.7/servers/slapd/search.c:217 > #6 0x080757c6 in connection_operation (ctx=3D0xb5f18248, arg_v=3D0x8299b10) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openl= dap2.3-2.4.7/servers/slapd/connection.c:1083 > #7 0x08075ed6 in connection_read_thread (ctx=3D0xb5f18248, argv=3D0x13) > at /home/pere/src/debiancvs/initscripts-ng-svn/trunk/src/insserv/openl= dap2.3-2.4.7/servers/slapd/connection.c:1210 > #8 0xb7f42a44 in ?? () from /usr/lib/libldap_r-2.4.so.2 > #9 0xb5f18248 in ?? () > #10 0x00000013 in ?? () > #11 0x00000000 in ?? () > > A more detailed backtrace is available at the url specified below. > > > --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============4755194735599619372==-- From adejong@debian.org Tue May 6 21:13:08 2008 From: adejong@debian.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5494) slapd crashed when accessed by multiple threads Date: Tue, 06 May 2008 21:13:08 +0000 Message-ID: <200805062113.m46LD89d065538@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1031641280916739653==" --===============1031641280916739653== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --=-6tNxv4Jql6LXRCulK2og Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-05-05 at 18:30 -0700, Howard Chu wrote: > This is most likely the same as ITS#5439, fixed in HEAD/RE24/2.4.9. > Please test against a more recent release. I have used a cvs version: cvs -d :pserver:anonymous(a)cvs.OpenLDAP.org:/repo/OpenLDAP -z3 \ checkout -P -rOPENLDAP_REL_ENG_2_4_9 openldap and configured it with: ./configure --prefix=3D/opt/openldap-cvs-2.4.9 --enable-local \ --enable-slapd --enable-aci --enable-cleartext --enable-crypt \ --disable-lmpasswd --enable-spasswd --enable-slapi --enable-slp \ --enable-wrappers --enable-backends=3Dmod --enable-ldbm=3Dno \ --enable-overlays=3Dmod --with-subdir=3Dldap --with-cyrus-sasl \ --with-threads --with-tls=3Dgnutls --with-odbc=3Dunixodbc \ --enable-perl=3Dno and have not been able to trigger a crash with it so I would think that it is fixed in that version. Thanks. --=20 -- arthur - adejong(a)debian.org - http://people.debian.org/~adejong -- --=-6tNxv4Jql6LXRCulK2og Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIIMnRVYan35+NCKcRArkpAKCYd7ndeUHUsgQtj0loLAOJZYKDTgCgk37K C4gfQFwljJKeGhYkY7gWnq0= =YSTk -----END PGP SIGNATURE----- --=-6tNxv4Jql6LXRCulK2og-- --===============1031641280916739653==-- From quanah@zimbra.com Wed May 7 00:01:02 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5495) cpu consuption Date: Wed, 07 May 2008 00:01:01 +0000 Message-ID: <200805070001.m47011b0093360@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3496608143080386073==" --===============3496608143080386073== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Monday, May 05, 2008 6:07 AM +0000 naga.gangadhar(a)gmail.com wrote: > Full_Name: Naga Gangadhar Reddy > Version: 2.4.19 > OS: cent-os > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.212.208.159) There's no evidence of a bug here. Please submit questions about how to configure and use OpenLDAP to the Openldap software list. I will also note that there is no such OpenLDAP release as "2.4.19". Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3496608143080386073==-- From kislinger@kn.vutbr.cz Wed May 7 12:22:52 2008 From: kislinger@kn.vutbr.cz To: openldap-bugs@openldap.org Subject: (ITS#5497) back-sql with base64 encoded attributes Date: Wed, 07 May 2008 12:22:51 +0000 Message-ID: <200805071222.m47CMpkl092427@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6180177252333575230==" --===============6180177252333575230== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pavel Kislinger Version: 2.4.8 OS: Freebsd 6.3 Stable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.229.202.76) I am using this packages: openldap-server-2.4.8_1 openldap-client-2.4.8 mysql-client-5.0.51a unixODBC-2.2.12_4 mysql-connector-odbc-unixodbc-mysql50-3.51.12_1 I have records with diacritics (czech language) like name or surname in SQL. +-------+---------------+-----------+ | vutid | name | surname | +-------+---------------+-----------+ | 1 | Pavel | Kislinger | | 2 | Michhě=C2=9Ačř=C2=9E=C3=BD=C3=AD=C3=A9 | =C2=8Eab=C3= =A1ček | +-------+---------------+-----------+ First record in SQL correspond to record in LDAP. Second record with diacriti= cs doesn't works. # 1, users, test.vutbr.cz dn: uid=3D1,ou=3Dusers,dc=3Dtest,dc=3Dvutbr,dc=3Dcz objectClass: usi cn: Pavel Kislinger sn: Kislinger givenName: Pavel uid: 1 Solution of this problem is base64 encoding of attributes. "cn" for second record "Michhě=C2=9Ačř=C2=9E=C3=BD=C3=AD=C3=A9= =C2=8Eab=C3=A1ček" could be: cn:: eHhNaWNoaOy56Pi+/e3pYWx4eCBLaXNsaW5nZXI=3D I wrote MySQL function base64_encoding and adjusted table ldap_attr_mapping f= or "cn": insert into ldap_attr_mappings () values (114,3,'cn',"base64_encode(concat(users.name,' ',users.surname))",'users',NULL,NULL,NULL,3,0); the result in ldap is: cn: eHhNaWNoaOy56Pi+/e3pYWx4eCBLaXNsaW5nZXI=3D This value is false recognized by ldap clients (outlook, thunderbird) as stri= ng "eHhN..." instead of "Michhě=C2=9Ačř=C2=9E=C3=BD=C3=AD=C3=A9 = =C2=8Eab=C3=A1ček" How can I mark "cn" attribute in SQL, that this attribute is encoded by base6= 4? --===============6180177252333575230==-- From raphael.ouazana@linagora.com Wed May 7 12:44:45 2008 From: raphael.ouazana@linagora.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Wed, 07 May 2008 12:44:44 +0000 Message-ID: <200805071244.m47Ciisj000578@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1071584754327714572==" --===============1071584754327714572== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, Le Lun 5 mai 2008 23:08, Howard Chu a écrit : > The logs show that the syncrepl consumers all timed out periodically, when > trying to bind to a provider. It seems that using a 1 second timeout in > the > syncrepl configs is too short, or your test machine was too slow during > that run. > > Probably we should remove that timeout now, since the cn=config/thread > pause > issue has already been resolved. Currently testing new RE24. I have now a slapd process stuck at 100% : \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h ldap://localhost:9011/ -d 261 \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9012/ -d 261 \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h ldap://localhost:9013/ -d 261 \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com (objectClass=*) \_ awk /^dn:/ {print "OK"} Do you need some debugging info (strace, gdb, log, or other) ? Regards, Raphael Ouazana. --===============1071584754327714572==-- From h.b.furuseth@usit.uio.no Wed May 7 13:57:03 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5497) back-sql with base64 encoded attributes Date: Wed, 07 May 2008 13:57:03 +0000 Message-ID: <200805071357.m47Dv3vF036973@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1993452456482037528==" --===============1993452456482037528== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============1993452456482037528==-- From h.b.furuseth@usit.uio.no Wed May 7 14:12:01 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: (ITS#5498) "Issue Tracking" -> "Bugs" @ webpage Date: Wed, 07 May 2008 14:12:00 +0000 Message-ID: <200805071412.m47EC0TT045633@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2582765225607168775==" --===============2582765225607168775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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. --===============2582765225607168775==-- From quanah@zimbra.com Wed May 7 14:12:04 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Wed, 07 May 2008 14:12:03 +0000 Message-ID: <200805071412.m47EC33w045689@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5916083528855279864==" --===============5916083528855279864== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --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 --===============5916083528855279864==-- From raphael.ouazana@linagora.com Wed May 7 14:25:27 2008 From: raphael.ouazana@linagora.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Wed, 07 May 2008 14:25:26 +0000 Message-ID: <200805071425.m47EPQU3047400@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5877815024695335820==" --===============5877815024695335820== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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=, do_pause=1) at tpool.c:738 #3 0x08054abf in config_back_add (op=0xb6dd0dd4, rs=0xb6dd0728) at bconfig.c:4548 ---Type to continue, or q 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. --===============5877815024695335820==-- From Kurt@OpenLDAP.org Wed May 7 14:47:00 2008 From: Kurt@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5498) "Issue Tracking" -> "Bugs" @ webpage Date: Wed, 07 May 2008 14:46:59 +0000 Message-ID: <200805071447.m47Ekxou048989@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1339442456279401177==" --===============1339442456279401177== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============1339442456279401177==-- From kislinger@kn.vutbr.cz Wed May 7 15:31:30 2008 From: kislinger@kn.vutbr.cz To: openldap-bugs@openldap.org Subject: Re: (ITS#5497) back-sql with base64 encoded attributes Date: Wed, 07 May 2008 15:31:29 +0000 Message-ID: <200805071531.m47FVTo3052186@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5039953446136537919==" --===============5039953446136537919== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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). --===============5039953446136537919==-- From Alexander.lelyakin@googlemail.com Wed May 7 15:45:08 2008 From: Alexander.lelyakin@googlemail.com To: openldap-bugs@openldap.org Subject: (ITS#5499) slapd-perl man page Date: Wed, 07 May 2008 15:45:07 +0000 Message-ID: <200805071545.m47Fj7ss052731@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5831510763812106841==" --===============5831510763812106841== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Alexander Lelyakin Version: Any OS: linux URL:=20 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 o= wn access control schemes). --===============5831510763812106841==-- From h.b.furuseth@usit.uio.no Wed May 7 16:27:37 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5497) back-sql with base64 encoded attributes Date: Wed, 07 May 2008 16:27:36 +0000 Message-ID: <200805071627.m47GRawC056482@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0632565387424231368==" --===============0632565387424231368== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============0632565387424231368==-- From h.b.furuseth@usit.uio.no Wed May 7 17:04:32 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5499) slapd-perl man page Date: Wed, 07 May 2008 17:04:32 +0000 Message-ID: <200805071704.m47H4W7B061440@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8745938437674883397==" --===============8745938437674883397== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============8745938437674883397==-- From h.b.furuseth@usit.uio.no Wed May 7 17:11:52 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5499) slapd-perl man page Date: Wed, 07 May 2008 17:11:51 +0000 Message-ID: <200805071711.m47HBp28062296@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5089035642852154028==" --===============5089035642852154028== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I wrote: > + * bind DN, or "" for anonymous bind Duh, sorry. Anonymous bind is handled by the frontend, of course. -- Hallvard --===============5089035642852154028==-- From h.b.furuseth@usit.uio.no Wed May 7 18:52:27 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: (ITS#5500) comments in cn=config entries Date: Wed, 07 May 2008 18:52:27 +0000 Message-ID: <200805071852.m47IqQxn072809@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5061043107495036598==" --===============5061043107495036598== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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. --===============5061043107495036598==-- From hyc@symas.com Wed May 7 22:06:53 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Wed, 07 May 2008 22:06:53 +0000 Message-ID: <200805072206.m47M6rHe020315@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8185128493410877664==" --===============8185128493410877664== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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= .=20 Is there anything in the logs that indicates a loop? --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8185128493410877664==-- From hyc@symas.com Wed May 7 22:08:47 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5500) comments in cn=config entries Date: Wed, 07 May 2008 22:08:47 +0000 Message-ID: <200805072208.m47M8lBq021000@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7294874417504294499==" --===============7294874417504294499== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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/ --===============7294874417504294499==-- From raphael.ouazana@linagora.com Thu May 8 01:26:57 2008 From: raphael.ouazana@linagora.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5470) Sporadic failures with RE24 Date: Thu, 08 May 2008 01:26:57 +0000 Message-ID: <200805080126.m481QvQL045661@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8054554139168114218==" --===============8054554139168114218== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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. --===============8054554139168114218==-- From mark.cave-ayland@siriusit.co.uk Thu May 8 16:00:27 2008 From: mark.cave-ayland@siriusit.co.uk To: openldap-bugs@openldap.org Subject: (ITS#5501) syncprov/glue crash with RE24 CVS Date: Thu, 08 May 2008 16:00:26 +0000 Message-ID: <200805081600.m48G0QA5055956@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5421994079481622178==" --===============5421994079481622178== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 (wh= ich 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. --===============5421994079481622178==-- From hyc@symas.com Thu May 8 16:44:36 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5248) non-atomic signal variables Date: Thu, 08 May 2008 16:44:36 +0000 Message-ID: <200805081644.m48Gia2v061220@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8628749084762359035==" --===============8628749084762359035== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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/ --===============8628749084762359035==-- From javed_ansari@infosys.com Fri May 9 06:09:31 2008 From: javed_ansari@infosys.com To: openldap-bugs@openldap.org Subject: (ITS#5502) LDAP problem Date: Fri, 09 May 2008 06:09:30 +0000 Message-ID: <200805090609.m4969Uf3021882@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6257375895465986162==" --===============6257375895465986162== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============6257375895465986162==-- From h.b.furuseth@usit.uio.no Fri May 9 08:31:38 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5500) comments in cn=config entries Date: Fri, 09 May 2008 08:31:38 +0000 Message-ID: <200805090831.m498Vcbc031527@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4378760454389007001==" --===============4378760454389007001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============4378760454389007001==-- From zulcss@ubuntu.com Fri May 9 13:37:32 2008 From: zulcss@ubuntu.com To: openldap-bugs@openldap.org Subject: (ITS#5503) Openldap segmentation fault when running syncrepl. Date: Fri, 09 May 2008 13:37:31 +0000 Message-ID: <200805091337.m49DbVUA056564@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4848220464583154896==" --===============4848220464583154896== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============4848220464583154896==-- From Javier.Fernandez@cern.ch Fri May 9 17:38:23 2008 From: Javier.Fernandez@cern.ch To: openldap-bugs@openldap.org Subject: (ITS#5504) ldapsearch hangs retrieving info Date: Fri, 09 May 2008 17:38:23 +0000 Message-ID: <200805091738.m49HcN9a066508@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2679946311939257619==" --===============2679946311939257619== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 er= ror 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(a)lxcert-amd64:/scratch/rpmbuild.7430.xx7460/openldap-2.2.13/ope= nldap-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=3Dgrid" -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....`........ = =20 ldap_write: want=3D14, written=3D14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ = =20 ldap_result msgid 1 ldap_chkResponseList for msgid=3D1, all=3D1 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=3D1, all=3D1 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=3D8, got=3D8 0000: 30 82 03 57 02 01 02 64 0..W...d = =20 ldap_read: want=3D851, got=3D571 0000: 82 03 50 04 51 47 6c 75 65 43 6c 75 73 74 65 72 ..P.QGlueCluster = =20 0010: 55 6e 69 71 75 65 49 44 3d 67 62 2d 63 65 2d 61 UniqueID=3Dgb-ce-= a =20 0020: 6d 63 2e 61 6d 63 2e 6e 6c 2c 4d 64 73 2d 56 6f mc.amc.nl,Mds-Vo = =20 0030: 2d 6e 61 6d 65 3d 4c 53 47 2d 41 4d 43 2c 4d 64 -name=3DLSG-AMC,M= d =20 0040: 73 2d 56 6f 2d 6e 61 6d 65 3d 6c 6f 63 61 6c 2c s-Vo-name=3Dlocal= , =20 0050: 6f 3d 67 72 69 64 30 82 02 f9 30 60 04 0b 6f 62 o=3Dgrid0...0`..o= b =20 0060: 6a 65 63 74 43 6c 61 73 73 31 51 04 0e 47 6c 75 jectClass1Q..Glu = =20 0070: 65 43 6c 75 73 74 65 72 54 6f 70 04 0b 47 6c 75 eClusterTop..Glu = =20 0080: 65 43 6c 75 73 74 65 72 04 11 47 6c 75 65 53 63 eCluster..GlueSc = =20 0090: 68 65 6d 61 56 65 72 73 69 6f 6e 04 16 47 6c 75 hemaVersion..Glu = =20 00a0: 65 49 6e 66 6f 72 6d 61 74 69 6f 6e 53 65 72 76 eInformationServ = =20 00b0: 69 63 65 04 07 47 6c 75 65 4b 65 79 30 25 04 0f ice..GlueKey0%.. = =20 00c0: 47 6c 75 65 43 6c 75 73 74 65 72 4e 61 6d 65 31 GlueClusterName1 = =20 00d0: 12 04 10 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 ...gb-ce-amc.amc = =20 00e0: 2e 6e 6c 30 71 04 12 47 6c 75 65 43 6c 75 73 74 .nl0q..GlueClust = =20 00f0: 65 72 53 65 72 76 69 63 65 31 5b 04 2b 67 62 2d erService1[.+gb- = =20 0100: 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e 6c 3a 32 31 ce-amc.amc.nl:21 = =20 0110: 31 39 2f 6a 6f 62 6d 61 6e 61 67 65 72 2d 70 62 19/jobmanager-pb = =20 0120: 73 2d 6d 65 64 69 75 6d 04 2c 67 62 2d 63 65 2d s-medium.,gb-ce- = =20 0130: 61 6d 63 2e 61 6d 63 2e 6e 6c 3a 32 31 31 39 2f amc.amc.nl:2119/ = =20 0140: 6a 6f 62 6d 61 6e 61 67 65 72 2d 70 62 73 2d 65 jobmanager-pbs-e = =20 0150: 78 70 72 65 73 73 30 29 04 13 47 6c 75 65 43 6c xpress0)..GlueCl = =20 0160: 75 73 74 65 72 55 6e 69 71 75 65 49 44 31 12 04 usterUniqueID1.. = =20 0170: 10 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e .gb-ce-amc.amc.n = =20 0180: 6c 30 82 01 3a 04 0e 47 6c 75 65 46 6f 72 65 69 l0..:..GlueForei = =20 0190: 67 6e 4b 65 79 31 82 01 26 04 18 47 6c 75 65 53 gnKey1..&..GlueS = =20 01a0: 69 74 65 55 6e 69 71 75 65 49 44 3d 4c 53 47 2d iteUniqueID=3DLSG= - =20 01b0: 41 4d 43 04 3a 47 6c 75 65 43 45 55 6e 69 71 75 AMC.:GlueCEUniqu = =20 01c0: 65 49 44 3d 67 62 2d 63 65 2d 61 6d 63 2e 61 6d eID=3Dgb-ce-amc.a= m =20 01d0: 63 2e 6e 6c 3a 32 31 31 39 2f 6a 6f 62 6d 61 6e c.nl:2119/jobman = =20 01e0: 61 67 65 72 2d 70 62 73 2d 6d 65 64 69 75 6d 04 ager-pbs-medium. = =20 01f0: 3b 47 6c 75 65 43 45 55 6e 69 71 75 65 49 44 3d ;GlueCEUniqueID= =3D =20 0200: 67 62 2d 63 65 2d 61 6d 63 2e 61 6d 63 2e 6e 6c gb-ce-amc.amc.nl = =20 0210: 3a 32 31 31 39 2f 6a 6f 62 6d 61 6e 61 67 65 72 :2119/jobmanager = =20 0220: 2d 70 62 73 2d 65 78 70 72 65 73 73 04 18 47 6c -pbs-express..Gl = =20 0230: 75 65 53 69 74 65 55 6e 69 71 75 ueSiteUniqu = =20 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=3D-1, all=3D0 ldap_chkResponseList returns NULL ldap_int_select ldap_result: Can't contact LDAP server (-1) Thank you very much in advance --===============2679946311939257619==-- From hyc@symas.com Fri May 9 22:32:59 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5503) Openldap segmentation fault when running syncrepl. Date: Fri, 09 May 2008 22:32:58 +0000 Message-ID: <200805092232.m49MWwaS080049@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7252243961668248430==" --===============7252243961668248430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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/ --===============7252243961668248430==-- From hyc@symas.com Fri May 9 22:37:56 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5504) ldapsearch hangs retrieving info Date: Fri, 09 May 2008 22:37:55 +0000 Message-ID: <200805092237.m49MbtGr080773@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3073926282295317729==" --===============3073926282295317729== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=20 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(a)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 cou= ld be > a site network port filtering problem, but our network administrator does n= ot > know how to debug, so we would need any hint on how to trace back the probl= em. > > The command, which starts working but after some time gets stuck, is: > > ldapsearch -p 2170 -h exp-bdii.cern.ch -x -LLL -b "o=3Dgrid" -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: --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============3073926282295317729==-- From chuck.short@canonical.com Sat May 10 14:24:36 2008 From: chuck.short@canonical.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5503) Openldap segmentation fault when running syncrepl. Date: Sat, 10 May 2008 14:24:35 +0000 Message-ID: <200805101424.m4AEOZjL016031@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4616331009840995758==" --===============4616331009840995758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 --===============4616331009840995758==-- From hyc@symas.com Sat May 10 16:28:18 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5503) Openldap segmentation fault when running syncrepl. Date: Sat, 10 May 2008 16:28:17 +0000 Message-ID: <200805101628.m4AGSHlJ020732@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7157446231016755154==" --===============7157446231016755154== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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'r= e=20 using 2.4.9, please post your backtrace. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7157446231016755154==-- From michael@stroeder.com Sat May 10 17:10:57 2008 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: (ITS#5505) Attribute value for 'modifiersName' in case of overlays Date: Sat, 10 May 2008 17:10:57 +0000 Message-ID: <200805101710.m4AHAvQu022931@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6079642501543806734==" --===============6079642501543806734== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Michael Str=C3=B6der 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=3Dconfig if an entry was modified = by an overlay? In this case one would have a direct link to the configuration if needed. Currently 'cn=3D' (e.g cn=3DReferential Integrity Overl= ay) is added which does not refer to an existing entry at all. Ciao, Michael. --===============6079642501543806734==-- From ando@sys-net.it Sat May 10 20:36:48 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5505) Attribute value for 'modifiersName' in case of overlays Date: Sat, 10 May 2008 20:36:48 +0000 Message-ID: <200805102036.m4AKam2Y029507@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0645798604563714789==" --===============0645798604563714789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > 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=' (e.g cn=Referential Integrity > Overlay) is > added which does not refer to an existing entry at all. Technically, I don't see any problem, except that overlays (and software modules, in general) do not hold a direct reference to their config entry's DN, if any (e.g. when back-config is not in use, the data structure is in place, but not in LDIF form; please correct me if I'm wrong). I wonder whether exposing such detail makes sense, or risks breaking any security. Probably I'm getting paranoid... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it --------------------------------------- --===============0645798604563714789==-- From mark.cave-ayland@siriusit.co.uk Mon May 12 09:02:17 2008 From: mark.cave-ayland@siriusit.co.uk To: openldap-bugs@openldap.org Subject: (ITS#5506) syncprov crash with RE24 CVS Date: Mon, 12 May 2008 09:02:17 +0000 Message-ID: <200805120902.m4C92HZ8049741@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7542929150544371629==" --===============7542929150544371629== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 another segfault in openldap 2.4.8cvs RE24 branch when using syncprov, possibly similar in nature to ITS#5486. Details from the slapd log and the gdb core file can be found here: http://pastebin.siriusit.co.uk/openldap-bug-20080512.txt More information from the gdb core file can be obtained upon request. Many thanks, Mark. --===============7542929150544371629==-- From jsafrane@redhat.com Mon May 12 12:24:00 2008 From: jsafrane@redhat.com To: openldap-bugs@openldap.org Subject: (ITS#5507) Ldap clients leak file descriptors Date: Mon, 12 May 2008 12:23:59 +0000 Message-ID: <200805121224.m4CCNxen060815@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4298001450207531969==" --===============4298001450207531969== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Jan Safranek Version: 2.4.9 OS: Linux (Fedora 8) URL:=20 Submission from: (NULL) (62.40.79.66) On system protected by SELinux, when an application with active LDAP connecti= on tries to exec() binary with different security context, SELinux inspects all opened filedescriptors, including the ldap one, and denies access to the ones, which do not conform active policy (the executed binary is not authorized to contact LDAP servers). Users are then annoyed by security warnings in the log= s. There is simple fix - set CLOEXEC flag on the socket, which will force the filedescriptor to close on exec(), see patch below. --- a/libraries/libldap/os-ip.c +++ b/libraries/libldap/os-ip.c @@ -36,6 +36,9 @@ #ifdef HAVE_IO_H #include #endif /* HAVE_IO_H */ +#ifdef HAVE_FCNTL_H +#include +#endif #include "ldap-int.h" @@ -110,6 +113,9 @@ ldap_int_socket(LDAP *ld, int family, int type ) { ber_socket_t s =3D socket(family, type, 0); osip_debug(ld, "ldap_new_socket: %d\n",s,0,0); +#ifdef _GNU_SOURCE + fcntl(s, F_SETFD, FD_CLOEXEC); +#endif return ( s ); } --===============4298001450207531969==-- From hyc@symas.com Mon May 12 16:38:35 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5506) syncprov crash with RE24 CVS Date: Mon, 12 May 2008 16:38:35 +0000 Message-ID: <200805121638.m4CGcZEB075190@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5968628801072497092==" --===============5968628801072497092== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit mark.cave-ayland(a)siriusit.co.uk wrote: > 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 another segfault in openldap 2.4.8cvs RE24 branch when using > syncprov, possibly similar in nature to ITS#5486. 2.4.9 was released on May 6; that's the base version you should be using at this point. > Details from the slapd log and the gdb core file can be found here: > http://pastebin.siriusit.co.uk/openldap-bug-20080512.txt A patch is now in HEAD for this. Please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5968628801072497092==-- From whm@stanford.edu Tue May 13 01:35:09 2008 From: whm@stanford.edu To: openldap-bugs@openldap.org Subject: (ITS#5508) slapd process consumes all of CPU Date: Tue, 13 May 2008 01:35:09 +0000 Message-ID: <200805130135.m4D1Z9oB006629@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4194095416556727457==" --===============4194095416556727457== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Bill MacAllister Version: 2.3.41-1su2 OS: debian etch kernel 2.6.18-4-amd64 URL: http://www.stanford.edu/~whm/ldap-test1-bt.txt Submission from: (NULL) (171.64.19.165) The slapd process will sometimes consume all of available CPU. We observed t= his when we upgraded our production servers from 2.3.35-2su2 to 2.3.41-1su2. The problem was bad enough that we downgraded the production servers to 2.3.35-2s= u2. We have been trying to provoke the problem in our test environment and have = not been successful in making it happen on demand. Today, we noticed that one of our test servers went completely CPU bound. I took a backtrace. It is available at the URL below. The interesting thing about the problem is that although top shows a pinned CPU and a high load the server is still responsive and continues to answer LDAP searches. The test server that exhibits the problem is still CPU bound and has been for 2-3 hours now. We will leave this server in this state in case there is other information that we should harvest in resolving the problem. --===============4194095416556727457==-- From hyc@symas.com Tue May 13 08:21:01 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5508) slapd process consumes all of CPU Date: Tue, 13 May 2008 08:21:01 +0000 Message-ID: <200805130821.m4D8L18R031087@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6829322506427244792==" --===============6829322506427244792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.3.41-1su2 > OS: debian etch kernel 2.6.18-4-amd64 > URL: http://www.stanford.edu/~whm/ldap-test1-bt.txt > Submission from: (NULL) (171.64.19.165) > > > The slapd process will sometimes consume all of available CPU. We observed= this > when we upgraded our production servers from 2.3.35-2su2 to 2.3.41-1su2. T= he > problem was bad enough that we downgraded the production servers to 2.3.35-= 2su2. > We have been trying to provoke the problem in our test environment and ha= ve not > been successful in making it happen on demand. Today, we noticed that one = of > our test servers went completely CPU bound. I took a backtrace. It is > available at the URL below. The interesting thing about the problem is that > although top shows a pinned CPU and a high load the server is still respons= ive > and continues to answer LDAP searches. The test server that exhibits the > problem is still CPU bound and has been for 2-3 hours now. We will leave t= his > server in this state in case there is other information that we should harv= est > in resolving the problem. Please also provide the output from db_stat -CA on the database in question, = thanks. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6829322506427244792==-- From whm@stanford.edu Tue May 13 09:23:21 2008 From: whm@stanford.edu To: openldap-bugs@openldap.org Subject: Re: (ITS#5508) slapd process consumes all of CPU Date: Tue, 13 May 2008 09:23:20 +0000 Message-ID: <200805130923.m4D9NKZW039270@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2511170157240905432==" --===============2511170157240905432== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --==========F223CD0B078644212341========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Attached is the output of db4.2_stat -CA of the database. Thanks for looking at this. Bill --On Tuesday, May 13, 2008 01:20:49 AM -0700 Howard Chu wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: 2.3.41-1su2 >> OS: debian etch kernel 2.6.18-4-amd64 >> URL: http://www.stanford.edu/~whm/ldap-test1-bt.txt >> Submission from: (NULL) (171.64.19.165) >> >> >> The slapd process will sometimes consume all of available CPU. We >> observed this when we upgraded our production servers from 2.3.35-2su2 >> to 2.3.41-1su2. The problem was bad enough that we downgraded the >> production servers to 2.3.35-2su2. We have been trying to provoke the >> problem in our test environment and have not been successful in making >> it happen on demand. Today, we noticed that one of our test servers >> went completely CPU bound. I took a backtrace. It is available at the >> URL below. The interesting thing about the problem is that although top >> shows a pinned CPU and a high load the server is still responsive and >> continues to answer LDAP searches. The test server that exhibits the >> problem is still CPU bound and has been for 2-3 hours now. We will >> leave this server in this state in case there is other information that >> we should harvest in resolving the problem. > > Please also provide the output from db_stat -CA on the database in > question, thanks. -- Bill MacAllister Systems Programmer, ITS Unix Systems, Stanford University --==========F223CD0B078644212341========== Content-Type: text/plain; charset=utf-8; name="db_stat-CA.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="db_stat-CA.log"; size=186733 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D Lock region parameters locker table size: 4099, object table size: 4099, obj_off: 2170496, osynch_off: 0, locker_off: 2104904, lsynch_off: 0, need_dd: 0 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D Conflict matrix 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 1 1 0 0 1 0 1 0 1 0 0 0 1 1 0 1 1 1 0 1 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D Locks grouped by lockers Locker Mode Count Status ----------------- Object --------------- bf dd=3D324 locks held 1 write locks 0 =20 bf READ 1 HELD id2entry.bdb handle 0 c0 dd=3D323 locks held 0 write locks 0 =20 c1 dd=3D322 locks held 1 write locks 0 =20 c1 READ 1 HELD dn2id.bdb handle 0 c2 dd=3D321 locks held 0 write locks 0 =20 c3 dd=3D320 locks held 0 write locks 0 =20 c4 dd=3D319 locks held 0 write locks 0 =20 c5 dd=3D318 locks held 1 write locks 0 =20 c5 READ 16 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 c6 dd=3D317 locks held 0 write locks 0 =20 c7 dd=3D316 locks held 1 write locks 0 =20 c7 READ 8 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 c8 dd=3D315 locks held 0 write locks 0 =20 c9 dd=3D314 locks held 0 write locks 0 =20 ca dd=3D313 locks held 1 write locks 0 =20 ca READ 1 HELD objectClass.bdb handle 0 cb dd=3D312 locks held 0 write locks 0 =20 cc dd=3D311 locks held 0 write locks 0 =20 cd dd=3D310 locks held 1 write locks 0 =20 cd READ 1 HELD krb5PrincipalName.bdb handle 0 ce dd=3D309 locks held 0 write locks 0 =20 cf dd=3D308 locks held 0 write locks 0 =20 d0 dd=3D307 locks held 1 write locks 0 =20 d0 READ 1 HELD uid.bdb handle 0 d1 dd=3D306 locks held 0 write locks 0 =20 d2 dd=3D305 locks held 0 write locks 0 =20 d3 dd=3D304 locks held 1 write locks 0 =20 d3 READ 1 HELD suGeneralID.bdb handle 0 d4 dd=3D303 locks held 0 write locks 0 =20 d5 dd=3D302 locks held 0 write locks 0 =20 d6 dd=3D301 locks held 1 write locks 0 =20 d6 READ 1 HELD suRegID.bdb handle 0 d7 dd=3D300 locks held 0 write locks 0 =20 d8 dd=3D299 locks held 0 write locks 0 =20 d9 dd=3D298 locks held 1 write locks 0 =20 d9 READ 1 HELD suPrivilegeGroup.bdb handle 0 da dd=3D297 locks held 1 write locks 0 =20 da READ 1 WAIT suPrivilegeGroup.bdb page 22090 da READ 1 HELD suPrivilegeGroup.bdb page 2990 db dd=3D296 locks held 0 write locks 0 =20 dc dd=3D295 locks held 1 write locks 0 =20 dc READ 1 WAIT suPrivilegeGroup.bdb page 22090 dc READ 1 HELD suPrivilegeGroup.bdb page 2990 dd dd=3D294 locks held 1 write locks 0 =20 dd READ 1 HELD suSunetID.bdb handle 0 de dd=3D293 locks held 0 write locks 0 =20 df dd=3D292 locks held 0 write locks 0 =20 e0 dd=3D291 locks held 1 write locks 0 =20 e0 READ 11 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 e1 dd=3D290 locks held 1 write locks 0 =20 e1 READ 1 HELD suSN.bdb handle 0 e2 dd=3D289 locks held 0 write locks 0 =20 e3 dd=3D288 locks held 0 write locks 0 =20 e4 dd=3D287 locks held 1 write locks 0 =20 e4 READ 1 HELD suVisibSunetID.bdb handle 0 e5 dd=3D286 locks held 0 write locks 0 =20 e6 dd=3D285 locks held 0 write locks 0 =20 e7 dd=3D284 locks held 0 write locks 0 =20 e8 dd=3D283 locks held 0 write locks 0 =20 e9 dd=3D282 locks held 1 write locks 0 =20 e9 READ 1 HELD suVisibIdentity.bdb handle 0 ea dd=3D281 locks held 0 write locks 0 =20 eb dd=3D280 locks held 0 write locks 0 =20 ec dd=3D279 locks held 0 write locks 0 =20 ed dd=3D278 locks held 0 write locks 0 =20 ee dd=3D277 locks held 1 write locks 0 =20 ee READ 1 HELD suVisibHomeAddress.bdb handle 0 ef dd=3D276 locks held 0 write locks 0 =20 f0 dd=3D275 locks held 0 write locks 0 =20 f1 dd=3D274 locks held 0 write locks 0 =20 f2 dd=3D273 locks held 0 write locks 0 =20 f3 dd=3D272 locks held 1 write locks 0 =20 f3 READ 1 HELD suDisplayAffiliation.bdb handle 0 f4 dd=3D271 locks held 0 write locks 0 =20 f5 dd=3D270 locks held 0 write locks 0 =20 f6 dd=3D269 locks held 0 write locks 0 =20 f7 dd=3D268 locks held 0 write locks 0 =20 f8 dd=3D267 locks held 1 write locks 0 =20 f8 READ 1 HELD suVisibPermanentAddress.bdbhandle 0 f9 dd=3D266 locks held 0 write locks 0 =20 fa dd=3D265 locks held 0 write locks 0 =20 fb dd=3D264 locks held 0 write locks 0 =20 fc dd=3D263 locks held 0 write locks 0 =20 fd dd=3D262 locks held 1 write locks 0 =20 fd READ 1 HELD suVisibAffiliation1.bdb handle 0 fe dd=3D261 locks held 0 write locks 0 =20 ff dd=3D260 locks held 0 write locks 0 =20 100 dd=3D259 locks held 0 write locks 0 =20 101 dd=3D258 locks held 0 write locks 0 =20 102 dd=3D257 locks held 1 write locks 0 =20 102 READ 1 HELD suVisibTelephoneNumber.bdbhandle 0 103 dd=3D256 locks held 0 write locks 0 =20 104 dd=3D255 locks held 0 write locks 0 =20 105 dd=3D254 locks held 0 write locks 0 =20 106 dd=3D253 locks held 0 write locks 0 =20 107 dd=3D252 locks held 1 write locks 0 =20 107 READ 1 HELD suVisibHomePhone.bdb handle 0 108 dd=3D251 locks held 0 write locks 0 =20 109 dd=3D250 locks held 0 write locks 0 =20 10a dd=3D249 locks held 0 write locks 0 =20 10b dd=3D248 locks held 0 write locks 0 =20 10c dd=3D247 locks held 1 write locks 0 =20 10c READ 1 HELD suVisibMailCode.bdb handle 0 10d dd=3D246 locks held 0 write locks 0 =20 10e dd=3D245 locks held 0 write locks 0 =20 10f dd=3D244 locks held 0 write locks 0 =20 110 dd=3D243 locks held 0 write locks 0 =20 111 dd=3D242 locks held 1 write locks 0 =20 111 READ 1 HELD suGwAffilCode1.bdb handle 0 112 dd=3D241 locks held 0 write locks 0 =20 113 dd=3D240 locks held 0 write locks 0 =20 114 dd=3D239 locks held 0 write locks 0 =20 115 dd=3D238 locks held 0 write locks 0 =20 116 dd=3D237 locks held 1 write locks 0 =20 116 READ 1 HELD suAffiliation.bdb handle 0 117 dd=3D236 locks held 0 write locks 0 =20 118 dd=3D235 locks held 0 write locks 0 =20 119 dd=3D234 locks held 0 write locks 0 =20 11a dd=3D233 locks held 0 write locks 0 =20 11b dd=3D232 locks held 1 write locks 0 =20 11b READ 1 HELD suVisibMailAddress.bdb handle 0 11c dd=3D231 locks held 0 write locks 0 =20 11d dd=3D230 locks held 0 write locks 0 =20 11e dd=3D229 locks held 0 write locks 0 =20 11f dd=3D228 locks held 0 write locks 0 =20 120 dd=3D227 locks held 1 write locks 0 =20 120 READ 1 HELD suVisibAffilPhone1.bdb handle 0 121 dd=3D226 locks held 0 write locks 0 =20 122 dd=3D225 locks held 0 write locks 0 =20 123 dd=3D224 locks held 0 write locks 0 =20 124 dd=3D223 locks held 0 write locks 0 =20 125 dd=3D222 locks held 0 write locks 0 =20 126 dd=3D221 locks held 1 write locks 0 =20 126 READ 1 HELD modifyTimestamp.bdb handle 0 127 dd=3D220 locks held 0 write locks 0 =20 128 dd=3D219 locks held 0 write locks 0 =20 129 dd=3D218 locks held 1 write locks 0 =20 129 READ 1 HELD suKerberosStatus.bdb handle 0 12a dd=3D217 locks held 0 write locks 0 =20 12b dd=3D216 locks held 0 write locks 0 =20 12c dd=3D215 locks held 0 write locks 0 =20 12d dd=3D214 locks held 0 write locks 0 =20 12e dd=3D213 locks held 1 write locks 0 =20 12e READ 1 HELD suGwAffilCode2.bdb handle 0 12f dd=3D212 locks held 0 write locks 0 =20 130 dd=3D211 locks held 0 write locks 0 =20 131 dd=3D210 locks held 0 write locks 0 =20 132 dd=3D209 locks held 0 write locks 0 =20 133 dd=3D208 locks held 1 write locks 0 =20 133 READ 1 HELD suVisibAffiliation2.bdb handle 0 134 dd=3D207 locks held 0 write locks 0 =20 135 dd=3D206 locks held 0 write locks 0 =20 136 dd=3D205 locks held 0 write locks 0 =20 137 dd=3D204 locks held 0 write locks 0 =20 138 dd=3D203 locks held 0 write locks 0 =20 139 dd=3D202 locks held 0 write locks 0 =20 13a dd=3D201 locks held 1 write locks 0 =20 13a READ 1 HELD suVisibEmail.bdb handle 0 13b dd=3D200 locks held 0 write locks 0 =20 13c dd=3D199 locks held 0 write locks 0 =20 13d dd=3D198 locks held 0 write locks 0 =20 13e dd=3D197 locks held 0 write locks 0 =20 13f dd=3D196 locks held 0 write locks 0 =20 140 dd=3D195 locks held 1 write locks 0 =20 140 READ 1 HELD suPrimaryOrganizationID.bdbhandle 0 141 dd=3D194 locks held 0 write locks 0 =20 142 dd=3D193 locks held 0 write locks 0 =20 143 dd=3D192 locks held 0 write locks 0 =20 144 dd=3D191 locks held 0 write locks 0 =20 145 dd=3D190 locks held 1 write locks 0 =20 145 READ 1 HELD suVisibAffilAddress1.bdb handle 0 146 dd=3D189 locks held 0 write locks 0 =20 147 dd=3D188 locks held 0 write locks 0 =20 148 dd=3D187 locks held 0 write locks 0 =20 149 dd=3D186 locks held 0 write locks 0 =20 14a dd=3D185 locks held 1 write locks 0 =20 14a READ 1 HELD suVisibStreet.bdb handle 0 14b dd=3D184 locks held 0 write locks 0 =20 14c dd=3D183 locks held 0 write locks 0 =20 14d dd=3D182 locks held 0 write locks 0 =20 14e dd=3D181 locks held 0 write locks 0 =20 14f dd=3D180 locks held 1 write locks 0 =20 14f READ 1 HELD suCN.bdb handle 0 150 dd=3D179 locks held 0 write locks 0 =20 151 dd=3D178 locks held 0 write locks 0 =20 152 dd=3D177 locks held 0 write locks 0 =20 153 dd=3D176 locks held 0 write locks 0 =20 154 dd=3D175 locks held 1 write locks 0 =20 154 READ 1 HELD suRegisteredName.bdb handle 0 155 dd=3D174 locks held 0 write locks 0 =20 156 dd=3D173 locks held 0 write locks 0 =20 157 dd=3D172 locks held 0 write locks 0 =20 158 dd=3D171 locks held 0 write locks 0 =20 159 dd=3D170 locks held 1 write locks 0 =20 159 READ 1 HELD suVisibAffilFax1.bdb handle 0 15a dd=3D169 locks held 0 write locks 0 =20 15b dd=3D168 locks held 0 write locks 0 =20 15c dd=3D167 locks held 0 write locks 0 =20 15d dd=3D166 locks held 0 write locks 0 =20 15e dd=3D165 locks held 1 write locks 0 =20 15e READ 1 HELD suVisibFacsimileTelephoneNumber.bdbhandle = 0 15f dd=3D164 locks held 0 write locks 0 =20 160 dd=3D163 locks held 0 write locks 0 =20 161 dd=3D162 locks held 0 write locks 0 =20 162 dd=3D161 locks held 0 write locks 0 =20 163 dd=3D160 locks held 1 write locks 0 =20 163 READ 1 HELD cn.bdb handle 0 164 dd=3D159 locks held 0 write locks 0 =20 165 dd=3D158 locks held 0 write locks 0 =20 166 dd=3D157 locks held 0 write locks 0 =20 167 dd=3D156 locks held 0 write locks 0 =20 168 dd=3D155 locks held 1 write locks 0 =20 168 READ 1 HELD displayName.bdb handle 0 169 dd=3D154 locks held 0 write locks 0 =20 16a dd=3D153 locks held 0 write locks 0 =20 16b dd=3D152 locks held 0 write locks 0 =20 16c dd=3D151 locks held 0 write locks 0 =20 16d dd=3D150 locks held 1 write locks 0 =20 16d READ 1 HELD suGwAffilCode3.bdb handle 0 16e dd=3D149 locks held 0 write locks 0 =20 16f dd=3D148 locks held 0 write locks 0 =20 170 dd=3D147 locks held 0 write locks 0 =20 171 dd=3D146 locks held 0 write locks 0 =20 172 dd=3D145 locks held 1 write locks 0 =20 172 READ 1 HELD suVisibHomePage.bdb handle 0 173 dd=3D144 locks held 0 write locks 0 =20 174 dd=3D143 locks held 0 write locks 0 =20 175 dd=3D142 locks held 0 write locks 0 =20 176 dd=3D141 locks held 0 write locks 0 =20 177 dd=3D140 locks held 1 write locks 0 =20 177 READ 1 HELD suGwAffilPhone2.bdb handle 0 178 dd=3D139 locks held 0 write locks 0 =20 179 dd=3D138 locks held 0 write locks 0 =20 17a dd=3D137 locks held 0 write locks 0 =20 17b dd=3D136 locks held 0 write locks 0 =20 17c dd=3D135 locks held 1 write locks 0 =20 17c READ 1 HELD suVisibAffilPhone2.bdb handle 0 17d dd=3D134 locks held 0 write locks 0 =20 17e dd=3D133 locks held 0 write locks 0 =20 17f dd=3D132 locks held 0 write locks 0 =20 180 dd=3D131 locks held 0 write locks 0 =20 181 dd=3D130 locks held 0 write locks 0 =20 182 dd=3D129 locks held 0 write locks 0 =20 183 dd=3D128 locks held 1 write locks 0 =20 183 READ 1 HELD sn.bdb handle 0 184 dd=3D127 locks held 0 write locks 0 =20 185 dd=3D126 locks held 0 write locks 0 =20 186 dd=3D125 locks held 0 write locks 0 =20 187 dd=3D124 locks held 0 write locks 0 =20 188 dd=3D123 locks held 1 write locks 0 =20 188 READ 1 HELD suGwAffilPhone1.bdb handle 0 189 dd=3D122 locks held 0 write locks 0 =20 18a dd=3D121 locks held 0 write locks 0 =20 18b dd=3D120 locks held 0 write locks 0 =20 18c dd=3D119 locks held 0 write locks 0 =20 18d dd=3D118 locks held 1 write locks 0 =20 18d READ 1 HELD suVisibLocalAddress.bdb handle 0 18e dd=3D117 locks held 0 write locks 0 =20 18f dd=3D116 locks held 0 write locks 0 =20 190 dd=3D115 locks held 0 write locks 0 =20 191 dd=3D114 locks held 0 write locks 0 =20 192 dd=3D113 locks held 1 write locks 0 =20 192 READ 1 HELD suVisibAffiliation3.bdb handle 0 193 dd=3D112 locks held 0 write locks 0 =20 194 dd=3D111 locks held 0 write locks 0 =20 195 dd=3D110 locks held 0 write locks 0 =20 196 dd=3D109 locks held 0 write locks 0 =20 197 dd=3D108 locks held 1 write locks 0 =20 197 READ 1 HELD suGwAffilPhone3.bdb handle 0 198 dd=3D107 locks held 0 write locks 0 =20 199 dd=3D106 locks held 0 write locks 0 =20 19a dd=3D105 locks held 0 write locks 0 =20 19b dd=3D104 locks held 0 write locks 0 =20 19c dd=3D103 locks held 1 write locks 0 =20 19c READ 1 HELD suVisibAffilPhone3.bdb handle 0 19d dd=3D102 locks held 0 write locks 0 =20 19e dd=3D101 locks held 0 write locks 0 =20 19f dd=3D100 locks held 0 write locks 0 =20 1a0 dd=3D99 locks held 0 write locks 0 =20 1a1 dd=3D98 locks held 1 write locks 0 =20 1a1 READ 1 HELD suGwAffilCode5.bdb handle 0 1a2 dd=3D97 locks held 0 write locks 0 =20 1a3 dd=3D96 locks held 0 write locks 0 =20 1a4 dd=3D95 locks held 0 write locks 0 =20 1a5 dd=3D94 locks held 0 write locks 0 =20 1a6 dd=3D93 locks held 1 write locks 0 =20 1a6 READ 1 HELD suVisibAffilPhone5.bdb handle 0 1a7 dd=3D92 locks held 0 write locks 0 =20 1a8 dd=3D91 locks held 0 write locks 0 =20 1a9 dd=3D90 locks held 0 write locks 0 =20 1aa dd=3D89 locks held 0 write locks 0 =20 1ab dd=3D88 locks held 1 write locks 0 =20 1ab READ 1 HELD suGwAffilPhone5.bdb handle 0 1ac dd=3D87 locks held 0 write locks 0 =20 1ad dd=3D86 locks held 0 write locks 0 =20 1ae dd=3D85 locks held 0 write locks 0 =20 1af dd=3D84 locks held 0 write locks 0 =20 1b0 dd=3D83 locks held 1 write locks 0 =20 1b0 READ 1 HELD homePhone.bdb handle 0 1b1 dd=3D82 locks held 0 write locks 0 =20 1b2 dd=3D81 locks held 0 write locks 0 =20 1b3 dd=3D80 locks held 0 write locks 0 =20 1b4 dd=3D79 locks held 0 write locks 0 =20 1b5 dd=3D78 locks held 1 write locks 0 =20 1b5 READ 1 HELD suLocalPhone.bdb handle 0 1b6 dd=3D77 locks held 0 write locks 0 =20 1b7 dd=3D76 locks held 0 write locks 0 =20 1b8 dd=3D75 locks held 0 write locks 0 =20 1b9 dd=3D74 locks held 0 write locks 0 =20 1ba dd=3D73 locks held 1 write locks 0 =20 1ba READ 1 HELD suGwAffilFax1.bdb handle 0 1bb dd=3D72 locks held 0 write locks 0 =20 1bc dd=3D71 locks held 0 write locks 0 =20 1bd dd=3D70 locks held 0 write locks 0 =20 1be dd=3D69 locks held 0 write locks 0 =20 1bf dd=3D68 locks held 1 write locks 0 =20 1bf READ 1 HELD suGwAffilFax2.bdb handle 0 1c0 dd=3D67 locks held 0 write locks 0 =20 1c1 dd=3D66 locks held 0 write locks 0 =20 1c2 dd=3D65 locks held 0 write locks 0 =20 1c3 dd=3D64 locks held 0 write locks 0 =20 1c4 dd=3D63 locks held 1 write locks 0 =20 1c4 READ 1 HELD suVisibAffilAddress2.bdb handle 0 1c5 dd=3D62 locks held 0 write locks 0 =20 1c6 dd=3D61 locks held 0 write locks 0 =20 1c7 dd=3D60 locks held 0 write locks 0 =20 1c8 dd=3D59 locks held 0 write locks 0 =20 1c9 dd=3D58 locks held 1 write locks 0 =20 1c9 READ 1 HELD suVisibAffilFax2.bdb handle 0 1ca dd=3D57 locks held 0 write locks 0 =20 1cb dd=3D56 locks held 0 write locks 0 =20 1cc dd=3D55 locks held 0 write locks 0 =20 1cd dd=3D54 locks held 0 write locks 0 =20 1ce dd=3D53 locks held 1 write locks 0 =20 1ce READ 1 HELD suDialinStatus.bdb handle 0 1cf dd=3D52 locks held 0 write locks 0 =20 1d0 dd=3D51 locks held 0 write locks 0 =20 1d1 dd=3D50 locks held 0 write locks 0 =20 1d2 dd=3D49 locks held 0 write locks 0 =20 1d3 dd=3D48 locks held 1 write locks 0 =20 1d3 READ 1 HELD suLelandStatus.bdb handle 0 1d4 dd=3D47 locks held 0 write locks 0 =20 1d5 dd=3D46 locks held 0 write locks 0 =20 1d6 dd=3D45 locks held 0 write locks 0 =20 1d7 dd=3D44 locks held 0 write locks 0 =20 1d8 dd=3D43 locks held 1 write locks 0 =20 1d8 READ 1 HELD suMailDrop.bdb handle 0 1d9 dd=3D42 locks held 0 write locks 0 =20 1da dd=3D41 locks held 0 write locks 0 =20 1db dd=3D40 locks held 1 write locks 0 =20 1db READ 1 HELD suSeasStatus.bdb handle 0 1dc dd=3D39 locks held 0 write locks 0 =20 1dd dd=3D38 locks held 0 write locks 0 =20 1de dd=3D37 locks held 0 write locks 0 =20 1df dd=3D36 locks held 0 write locks 0 =20 1e0 dd=3D35 locks held 1 write locks 0 =20 1e0 READ 1 HELD uidNumber.bdb handle 0 1e1 dd=3D34 locks held 0 write locks 0 =20 1e2 dd=3D33 locks held 0 write locks 0 =20 1e3 dd=3D32 locks held 0 write locks 0 =20 1e4 dd=3D31 locks held 0 write locks 0 =20 1e5 dd=3D30 locks held 1 write locks 0 =20 1e5 READ 1 HELD suVisibProfile.bdb handle 0 1e6 dd=3D29 locks held 0 write locks 0 =20 1e7 dd=3D28 locks held 0 write locks 0 =20 1e8 dd=3D27 locks held 0 write locks 0 =20 1e9 dd=3D26 locks held 0 write locks 0 =20 1ea dd=3D25 locks held 1 write locks 0 =20 1ea READ 1 HELD suGwAffilCode4.bdb handle 0 1eb dd=3D24 locks held 0 write locks 0 =20 1ec dd=3D23 locks held 0 write locks 0 =20 1ed dd=3D22 locks held 0 write locks 0 =20 1ee dd=3D21 locks held 0 write locks 0 =20 1ef dd=3D20 locks held 1 write locks 0 =20 1ef READ 1 HELD suVisibMobilePhone.bdb handle 0 1f0 dd=3D19 locks held 0 write locks 0 =20 1f1 dd=3D18 locks held 0 write locks 0 =20 1f2 dd=3D17 locks held 0 write locks 0 =20 1f3 dd=3D16 locks held 0 write locks 0 =20 1f4 dd=3D15 locks held 1 write locks 0 =20 1f4 READ 14 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f5 dd=3D14 locks held 1 write locks 0 =20 1f5 READ 23 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f6 dd=3D13 locks held 1 write locks 0 =20 1f6 READ 29 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f7 dd=3D12 locks held 1 write locks 0 =20 1f7 READ 22 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f8 dd=3D11 locks held 1 write locks 0 =20 1f8 READ 23 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f9 dd=3D 9 locks held 1 write locks 0 =20 1f9 READ 1 WAIT suPrivilegeGroup.bdb page 17856 1f9 READ 1 HELD suPrivilegeGroup.bdb page 2990 1fa dd=3D 8 locks held 0 write locks 0 =20 1fb dd=3D 7 locks held 1 write locks 0 =20 1fb READ 1 WAIT suPrivilegeGroup.bdb page 131 1fb READ 1 HELD suPrivilegeGroup.bdb page 14507 1fc dd=3D 6 locks held 0 write locks 0 =20 1fd dd=3D 5 locks held 1 write locks 0 =20 1fd READ 1 WAIT suPrivilegeGroup.bdb page 17856 1fd READ 1 HELD suPrivilegeGroup.bdb page 2990 1fe dd=3D 4 locks held 0 write locks 0 =20 1ff dd=3D 3 locks held 1 write locks 0 =20 1ff READ 1 WAIT suPrivilegeGroup.bdb page 131 1ff READ 1 HELD suPrivilegeGroup.bdb page 14507 200 dd=3D 2 locks held 0 write locks 0 =20 201 dd=3D 1 locks held 1 write locks 0 =20 201 READ 1 WAIT suPrivilegeGroup.bdb page 22090 201 READ 1 HELD suPrivilegeGroup.bdb page 2990 202 dd=3D 0 locks held 0 write locks 0 =20 8000184f dd=3D10 locks held 1049 write locks 522 =20 8000184f WRITE 1 WAIT 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9369 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9369 8000184f READ 2 HELD suPrivilegeGroup.bdb page 966 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5238 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 5238 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10411 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 10411 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13717 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13717 8000184f READ 6 HELD suPrivilegeGroup.bdb page 15596 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 15596 8000184f READ 3 HELD suPrivilegeGroup.bdb page 12785 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 12785 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16662 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16662 8000184f READ 4 HELD suPrivilegeGroup.bdb page 793 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 793 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15482 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15482 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2482 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2482 8000184f READ 6 HELD suPrivilegeGroup.bdb page 6498 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6498 8000184f READ 3 HELD suPrivilegeGroup.bdb page 11366 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 11366 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9467 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9467 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15828 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15828 8000184f READ 9 HELD suPrivilegeGroup.bdb page 14584 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 14584 8000184f READ 6 HELD suPrivilegeGroup.bdb page 18704 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 18704 8000184f READ 11 HELD suPrivilegeGroup.bdb page 3465 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 3465 8000184f READ 3 HELD suPrivilegeGroup.bdb page 213 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 213 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1646 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1646 8000184f READ 12 HELD suPrivilegeGroup.bdb page 7180 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 7180 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6489 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6489 8000184f READ 6 HELD suPrivilegeGroup.bdb page 971 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 971 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4927 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4927 8000184f READ 3 HELD suPrivilegeGroup.bdb page 96 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 96 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3296 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 3296 8000184f READ 12 HELD suPrivilegeGroup.bdb page 127 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 127 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2007 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2007 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10460 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10460 8000184f READ 3 HELD suPrivilegeGroup.bdb page 689 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 689 8000184f READ 3 HELD suPrivilegeGroup.bdb page 271 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 271 8000184f READ 9 HELD suPrivilegeGroup.bdb page 16648 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 16648 8000184f READ 6 HELD suPrivilegeGroup.bdb page 35 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 35 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1299 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1299 8000184f READ 18 HELD suPrivilegeGroup.bdb page 20692 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 20692 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6846 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 6846 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20649 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20649 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1931 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1931 8000184f READ 51 HELD suPrivilegeGroup.bdb page 432 8000184f WRITE 21 HELD suPrivilegeGroup.bdb page 432 8000184f READ 38 HELD suPrivilegeGroup.bdb page 8881 8000184f WRITE 20 HELD suPrivilegeGroup.bdb page 8881 8000184f READ 15 HELD suPrivilegeGroup.bdb page 22001 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 22001 8000184f READ 29 HELD suPrivilegeGroup.bdb page 33 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 33 8000184f READ 9 HELD suPrivilegeGroup.bdb page 9630 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 9630 8000184f READ 9 HELD suPrivilegeGroup.bdb page 17122 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 17122 8000184f READ 5 HELD suPrivilegeGroup.bdb page 2859 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2859 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7446 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 7446 8000184f READ 3 HELD suPrivilegeGroup.bdb page 131 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 131 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2887 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2887 8000184f READ 7 HELD suPrivilegeGroup.bdb page 9663 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 9663 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18308 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18308 8000184f READ 24 HELD suPrivilegeGroup.bdb page 19970 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 19970 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1726 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1726 8000184f READ 15 HELD suPrivilegeGroup.bdb page 6932 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 6932 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1630 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 1630 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8250 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8250 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1424 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1424 8000184f READ 5 HELD suPrivilegeGroup.bdb page 13864 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13864 8000184f READ 3 HELD suPrivilegeGroup.bdb page 22090 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 22090 8000184f READ 3 HELD suPrivilegeGroup.bdb page 696 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 696 8000184f READ 42 HELD suPrivilegeGroup.bdb page 18208 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 18208 8000184f READ 7 HELD suPrivilegeGroup.bdb page 14426 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 14426 8000184f READ 3 HELD suPrivilegeGroup.bdb page 14306 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 14306 8000184f READ 33 HELD suPrivilegeGroup.bdb page 1268 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 1268 8000184f READ 33 HELD suPrivilegeGroup.bdb page 6935 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 6935 8000184f READ 39 HELD suPrivilegeGroup.bdb page 235 8000184f WRITE 17 HELD suPrivilegeGroup.bdb page 235 8000184f READ 36 HELD suPrivilegeGroup.bdb page 21195 8000184f WRITE 16 HELD suPrivilegeGroup.bdb page 21195 8000184f READ 41 HELD suPrivilegeGroup.bdb page 3175 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 3175 8000184f READ 33 HELD suPrivilegeGroup.bdb page 18520 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 18520 8000184f READ 51 HELD suPrivilegeGroup.bdb page 20476 8000184f WRITE 21 HELD suPrivilegeGroup.bdb page 20476 8000184f READ 48 HELD suPrivilegeGroup.bdb page 151 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 151 8000184f READ 24 HELD suPrivilegeGroup.bdb page 2647 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 2647 8000184f READ 24 HELD suPrivilegeGroup.bdb page 115 8000184f WRITE 12 HELD suPrivilegeGroup.bdb page 115 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3271 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3271 8000184f READ 9 HELD suPrivilegeGroup.bdb page 21663 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 21663 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6104 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6104 8000184f READ 66 HELD suPrivilegeGroup.bdb page 142 8000184f WRITE 30 HELD suPrivilegeGroup.bdb page 142 8000184f READ 21 HELD suPrivilegeGroup.bdb page 18801 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 18801 8000184f READ 15 HELD suPrivilegeGroup.bdb page 566 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 566 8000184f READ 9 HELD suPrivilegeGroup.bdb page 21851 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 21851 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13771 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13771 8000184f READ 3 HELD suPrivilegeGroup.bdb page 194 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 194 8000184f READ 12 HELD suPrivilegeGroup.bdb page 9300 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 9300 8000184f READ 42 HELD suPrivilegeGroup.bdb page 69 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 69 8000184f READ 9 HELD suPrivilegeGroup.bdb page 11280 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 11280 8000184f READ 9 HELD suPrivilegeGroup.bdb page 8804 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 8804 8000184f READ 15 HELD suPrivilegeGroup.bdb page 498 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 498 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3357 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3357 8000184f READ 9 HELD suPrivilegeGroup.bdb page 20639 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 20639 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6397 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 6397 8000184f READ 19 HELD suPrivilegeGroup.bdb page 434 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 434 8000184f READ 24 HELD suPrivilegeGroup.bdb page 8248 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 8248 8000184f READ 15 HELD suPrivilegeGroup.bdb page 12 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 12 8000184f READ 27 HELD suPrivilegeGroup.bdb page 9092 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 9092 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4512 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 4512 8000184f READ 27 HELD suPrivilegeGroup.bdb page 1127 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 1127 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4170 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4170 8000184f READ 5 HELD suPrivilegeGroup.bdb page 3 8000184f READ 2 HELD suPrivilegeGroup.bdb page 30 8000184f READ 31 HELD suPrivilegeGroup.bdb page 4745 8000184f READ 2 HELD suPrivilegeGroup.bdb page 4 8000184f READ 2 HELD suPrivilegeGroup.bdb page 2988 8000184f READ 2 HELD suPrivilegeGroup.bdb page 12964 8000184f READ 8 HELD suPrivilegeGroup.bdb page 6812 8000184f READ 31 HELD suPrivilegeGroup.bdb page 14 8000184f READ 16 HELD suPrivilegeGroup.bdb page 43 8000184f READ 4 HELD suPrivilegeGroup.bdb page 7 8000184f READ 7 HELD suPrivilegeGroup.bdb page 20665 8000184f READ 8 HELD suPrivilegeGroup.bdb page 447 8000184f READ 4 HELD suPrivilegeGroup.bdb page 10 8000184f READ 45 HELD suPrivilegeGroup.bdb page 11782 8000184f WRITE 21 HELD suPrivilegeGroup.bdb page 11782 8000184f READ 27 HELD suPrivilegeGroup.bdb page 8545 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 8545 8000184f READ 33 HELD suPrivilegeGroup.bdb page 5328 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 5328 8000184f READ 31 HELD suPrivilegeGroup.bdb page 806 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 806 8000184f READ 31 HELD suPrivilegeGroup.bdb page 112 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 112 8000184f READ 33 HELD suPrivilegeGroup.bdb page 16578 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 16578 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2479 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2479 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3843 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3843 8000184f READ 9 HELD suPrivilegeGroup.bdb page 27 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 27 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2484 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2484 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1642 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1642 8000184f READ 12 HELD suPrivilegeGroup.bdb page 5876 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 5876 8000184f READ 32 HELD suPrivilegeGroup.bdb page 16454 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 16454 8000184f READ 32 HELD suPrivilegeGroup.bdb page 575 8000184f WRITE 16 HELD suPrivilegeGroup.bdb page 575 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1519 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1519 8000184f READ 3 HELD suPrivilegeGroup.bdb page 569 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 569 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20904 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20904 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1562 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1562 8000184f READ 9 HELD suPrivilegeGroup.bdb page 15811 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 15811 8000184f READ 28 HELD suPrivilegeGroup.bdb page 68 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 68 8000184f READ 45 HELD suPrivilegeGroup.bdb page 8435 8000184f WRITE 17 HELD suPrivilegeGroup.bdb page 8435 8000184f READ 15 HELD suPrivilegeGroup.bdb page 19078 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 19078 8000184f READ 15 HELD suPrivilegeGroup.bdb page 2463 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2463 8000184f READ 15 HELD suPrivilegeGroup.bdb page 458 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 458 8000184f READ 27 HELD suPrivilegeGroup.bdb page 14005 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 14005 8000184f READ 9 HELD suPrivilegeGroup.bdb page 730 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 730 8000184f READ 27 HELD suPrivilegeGroup.bdb page 1214 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 1214 8000184f READ 9 HELD suPrivilegeGroup.bdb page 29 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 29 8000184f READ 36 HELD suPrivilegeGroup.bdb page 9452 8000184f WRITE 16 HELD suPrivilegeGroup.bdb page 9452 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1123 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1123 8000184f READ 42 HELD suPrivilegeGroup.bdb page 12173 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 12173 8000184f READ 69 HELD suPrivilegeGroup.bdb page 11298 8000184f WRITE 27 HELD suPrivilegeGroup.bdb page 11298 8000184f READ 39 HELD suPrivilegeGroup.bdb page 15787 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 15787 8000184f READ 39 HELD suPrivilegeGroup.bdb page 6557 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 6557 8000184f READ 39 HELD suPrivilegeGroup.bdb page 81 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 81 8000184f READ 39 HELD suPrivilegeGroup.bdb page 17445 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 17445 8000184f READ 54 HELD suPrivilegeGroup.bdb page 431 8000184f WRITE 20 HELD suPrivilegeGroup.bdb page 431 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1323 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1323 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21202 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 21202 8000184f READ 6 HELD suPrivilegeGroup.bdb page 2878 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 2878 8000184f READ 15 HELD suPrivilegeGroup.bdb page 21581 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 21581 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1612 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1612 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5758 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5758 8000184f READ 12 HELD suPrivilegeGroup.bdb page 20436 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 20436 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5999 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5999 8000184f READ 18 HELD suPrivilegeGroup.bdb page 2485 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 2485 8000184f READ 12 HELD suPrivilegeGroup.bdb page 64 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 64 8000184f READ 15 HELD suPrivilegeGroup.bdb page 6492 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6492 8000184f READ 15 HELD suPrivilegeGroup.bdb page 2907 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 2907 8000184f READ 18 HELD suPrivilegeGroup.bdb page 1649 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1649 8000184f READ 6 HELD suPrivilegeGroup.bdb page 4603 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4603 8000184f READ 9 HELD suPrivilegeGroup.bdb page 15069 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 15069 8000184f READ 6 HELD suPrivilegeGroup.bdb page 6518 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 6518 8000184f READ 9 HELD suPrivilegeGroup.bdb page 18362 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 18362 8000184f READ 15 HELD suPrivilegeGroup.bdb page 2796 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2796 8000184f READ 27 HELD suPrivilegeGroup.bdb page 8 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 8 8000184f READ 51 HELD suPrivilegeGroup.bdb page 248 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 248 8000184f READ 51 HELD suPrivilegeGroup.bdb page 1471 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 1471 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2710 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2710 8000184f READ 39 HELD suPrivilegeGroup.bdb page 18760 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 18760 8000184f READ 21 HELD suPrivilegeGroup.bdb page 4219 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 4219 8000184f READ 21 HELD suPrivilegeGroup.bdb page 2816 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 2816 8000184f READ 48 HELD suPrivilegeGroup.bdb page 21406 8000184f WRITE 20 HELD suPrivilegeGroup.bdb page 21406 8000184f READ 9 HELD suPrivilegeGroup.bdb page 13245 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 13245 8000184f READ 27 HELD suPrivilegeGroup.bdb page 513 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 513 8000184f READ 24 HELD suPrivilegeGroup.bdb page 3514 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 3514 8000184f READ 33 HELD suPrivilegeGroup.bdb page 765 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 765 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 14 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10332 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10332 8000184f READ 10 HELD suPrivilegeGroup.bdb page 2 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 2 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3311 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3311 8000184f READ 15 HELD suPrivilegeGroup.bdb page 1797 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 1797 8000184f READ 6 HELD suPrivilegeGroup.bdb page 17675 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 17675 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10403 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10403 8000184f READ 24 HELD suPrivilegeGroup.bdb page 5000 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 5000 8000184f READ 6 HELD suPrivilegeGroup.bdb page 16608 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 16608 8000184f READ 24 HELD suPrivilegeGroup.bdb page 1041 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 1041 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10022 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10022 8000184f READ 27 HELD suPrivilegeGroup.bdb page 2711 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 2711 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13539 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13539 8000184f READ 15 HELD suPrivilegeGroup.bdb page 4101 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 4101 8000184f READ 15 HELD suPrivilegeGroup.bdb page 20373 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 20373 8000184f READ 12 HELD suPrivilegeGroup.bdb page 694 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 694 8000184f READ 12 HELD suPrivilegeGroup.bdb page 682 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 682 8000184f READ 21 HELD suPrivilegeGroup.bdb page 16 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 16 8000184f READ 12 HELD suPrivilegeGroup.bdb page 86 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 86 8000184f READ 12 HELD suPrivilegeGroup.bdb page 123 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 123 8000184f READ 19 HELD suPrivilegeGroup.bdb page 15054 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 15054 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7996 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 7996 8000184f READ 28 HELD suPrivilegeGroup.bdb page 2418 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 2418 8000184f READ 9 HELD suPrivilegeGroup.bdb page 8564 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 8564 8000184f READ 30 HELD suPrivilegeGroup.bdb page 10715 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 10715 8000184f READ 9 HELD suPrivilegeGroup.bdb page 20900 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 20900 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9298 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9298 8000184f READ 18 HELD suPrivilegeGroup.bdb page 400 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 400 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10420 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10420 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6800 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6800 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20 8000184f READ 21 HELD suPrivilegeGroup.bdb page 18913 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 18913 8000184f READ 3 HELD suPrivilegeGroup.bdb page 275 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 275 8000184f READ 12 HELD suPrivilegeGroup.bdb page 9795 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 9795 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7552 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7552 8000184f READ 6 HELD suPrivilegeGroup.bdb page 77 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 77 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7062 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7062 8000184f READ 12 HELD suPrivilegeGroup.bdb page 305 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 305 8000184f READ 6 HELD suPrivilegeGroup.bdb page 433 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 433 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6787 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6787 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2522 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2522 8000184f READ 12 HELD suPrivilegeGroup.bdb page 13753 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 13753 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1762 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1762 8000184f READ 9 HELD suPrivilegeGroup.bdb page 890 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 890 8000184f READ 9 HELD suPrivilegeGroup.bdb page 83 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 83 8000184f READ 6 HELD suPrivilegeGroup.bdb page 11083 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 11083 8000184f READ 9 HELD suPrivilegeGroup.bdb page 402 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 402 8000184f READ 3 HELD suPrivilegeGroup.bdb page 968 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 968 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17639 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17639 8000184f READ 9 HELD suPrivilegeGroup.bdb page 9880 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 9880 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5648 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5648 8000184f READ 6 HELD suPrivilegeGroup.bdb page 12006 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 12006 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7257 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 7257 8000184f READ 15 HELD suPrivilegeGroup.bdb page 9624 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 9624 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1783 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1783 8000184f READ 9 HELD suPrivilegeGroup.bdb page 310 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 310 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13760 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13760 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15193 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15193 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2701 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2701 8000184f READ 24 HELD suPrivilegeGroup.bdb page 892 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 892 8000184f READ 25 HELD suPrivilegeGroup.bdb page 19475 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 19475 8000184f READ 16 HELD suPrivilegeGroup.bdb page 11596 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 11596 8000184f READ 20 HELD suPrivilegeGroup.bdb page 79 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 79 8000184f READ 22 HELD suPrivilegeGroup.bdb page 2525 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 2525 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1230 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 1230 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 447 8000184f READ 30 HELD suPrivilegeGroup.bdb page 61 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 61 8000184f READ 3 HELD suPrivilegeGroup.bdb page 19101 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 19101 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1364 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1364 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21017 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21017 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2212 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2212 8000184f READ 3 HELD suPrivilegeGroup.bdb page 70 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 70 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6958 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 6958 8000184f READ 13 HELD suPrivilegeGroup.bdb page 15259 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 15259 8000184f READ 13 HELD suPrivilegeGroup.bdb page 15285 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 15285 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5118 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5118 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5688 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5688 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20706 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20706 8000184f READ 3 HELD suPrivilegeGroup.bdb page 197 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 197 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17646 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17646 8000184f READ 3 HELD suPrivilegeGroup.bdb page 107 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 107 8000184f READ 6 HELD suPrivilegeGroup.bdb page 22151 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 22151 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9563 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9563 8000184f READ 9 HELD suPrivilegeGroup.bdb page 76 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 76 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1326 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1326 8000184f READ 3 HELD suPrivilegeGroup.bdb page 67 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 67 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10419 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10419 8000184f READ 4 HELD suPrivilegeGroup.bdb page 1121 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1121 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21911 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21911 8000184f READ 3 HELD suPrivilegeGroup.bdb page 130 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 130 8000184f READ 3 HELD suPrivilegeGroup.bdb page 11516 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 11516 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21839 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21839 8000184f READ 3 HELD suPrivilegeGroup.bdb page 204 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 204 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2902 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2902 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1946 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1946 8000184f READ 9 HELD suPrivilegeGroup.bdb page 745 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 745 8000184f READ 9 HELD suPrivilegeGroup.bdb page 332 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 332 8000184f READ 9 HELD suPrivilegeGroup.bdb page 16396 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 16396 8000184f READ 3 HELD suPrivilegeGroup.bdb page 413 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 413 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5698 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5698 8000184f READ 42 HELD suPrivilegeGroup.bdb page 737 8000184f WRITE 22 HELD suPrivilegeGroup.bdb page 737 8000184f READ 6 HELD suPrivilegeGroup.bdb page 656 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 656 8000184f READ 9 HELD suPrivilegeGroup.bdb page 144 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 144 8000184f READ 6 HELD suPrivilegeGroup.bdb page 31 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 31 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2599 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2599 8000184f READ 6 HELD suPrivilegeGroup.bdb page 12031 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 12031 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7258 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7258 8000184f READ 6 HELD suPrivilegeGroup.bdb page 18778 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 18778 8000184f READ 9 HELD suPrivilegeGroup.bdb page 9296 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 9296 8000184f READ 4 HELD suPrivilegeGroup.bdb page 3667 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3667 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6802 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6802 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1335 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1335 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3686 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3686 8000184f READ 3 HELD suPrivilegeGroup.bdb page 664 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 664 8000184f READ 3 HELD suPrivilegeGroup.bdb page 680 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 680 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20385 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20385 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15427 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15427 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10416 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10416 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4999 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4999 8000184f READ 3 HELD suPrivilegeGroup.bdb page 14185 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 14185 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1446 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1446 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20633 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20633 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7712 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7712 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16606 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16606 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17058 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17058 8000184f READ 9 HELD suPrivilegeGroup.bdb page 217 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 217 8000184f READ 6 HELD suPrivilegeGroup.bdb page 9301 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 9301 8000184f READ 6 HELD suPrivilegeGroup.bdb page 9090 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 9090 8000184f READ 9 HELD suPrivilegeGroup.bdb page 6830 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6830 8000184f READ 6 HELD suPrivilegeGroup.bdb page 40 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 40 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7407 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7407 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5841 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5841 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3298 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3298 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2618 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2618 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13774 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13774 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1060 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1060 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20097 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20097 8000184f READ 12 HELD suPrivilegeGroup.bdb page 8301 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 8301 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3807 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3807 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6301 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6301 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5537 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5537 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21353 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 21353 8000184f READ 6 HELD suPrivilegeGroup.bdb page 14604 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 14604 8000184f READ 9 HELD suPrivilegeGroup.bdb page 205 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 205 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4278 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4278 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21848 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21848 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1182 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1182 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13754 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13754 8000184f READ 9 HELD suPrivilegeGroup.bdb page 6835 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6835 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20665 8000184f READ 6 HELD suPrivilegeGroup.bdb page 226 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 226 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21773 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21773 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6803 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6803 8000184f READ 13 HELD suPrivilegeGroup.bdb page 7262 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 7262 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3756 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3756 8000184f READ 3 HELD suPrivilegeGroup.bdb page 138 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 138 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18705 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18705 8000184f READ 3 HELD suPrivilegeGroup.bdb page 209 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 209 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21738 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 21738 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4583 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4583 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3345 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 3345 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13999 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13999 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15901 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15901 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2495 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2495 8000184f READ 27 HELD suPrivilegeGroup.bdb page 13633 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 13633 8000184f READ 30 HELD suPrivilegeGroup.bdb page 113 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 113 8000184f READ 27 HELD suPrivilegeGroup.bdb page 16373 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 16373 8000184f READ 7 HELD suPrivilegeGroup.bdb page 2610 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2610 8000184f READ 6 HELD suPrivilegeGroup.bdb page 4759 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4759 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1410 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1410 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7549 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7549 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3694 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3694 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1675 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 1675 8000184f READ 24 HELD suPrivilegeGroup.bdb page 452 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 452 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1655 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 1655 8000184f READ 24 HELD suPrivilegeGroup.bdb page 15481 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 15481 8000184f READ 6 HELD suPrivilegeGroup.bdb page 9823 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 9823 8000184f READ 9 HELD suPrivilegeGroup.bdb page 19758 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 19758 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3633 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3633 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3363 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3363 8000184f READ 9 HELD suPrivilegeGroup.bdb page 683 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 683 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1265 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1265 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6531 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6531 8000184f READ 9 HELD suPrivilegeGroup.bdb page 17650 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 17650 8000184f READ 9 HELD suPrivilegeGroup.bdb page 14281 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 14281 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2646 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2646 8000184f READ 13 HELD suPrivilegeGroup.bdb page 403 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 403 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3632 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3632 8000184f READ 12 HELD suPrivilegeGroup.bdb page 20099 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20099 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20806 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20806 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8895 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8895 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2603 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2603 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1875 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1875 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3400 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3400 8000184f READ 6 HELD suPrivilegeGroup.bdb page 18910 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 18910 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1039 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1039 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1412 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1412 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13762 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13762 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4332 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 4332 8000184f READ 6 HELD suPrivilegeGroup.bdb page 16542 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 16542 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10793 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10793 8000184f READ 15 HELD suPrivilegeGroup.bdb page 8528 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 8528 8000184f READ 6 HELD suPrivilegeGroup.bdb page 2296 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 2296 8000184f READ 6 HELD suPrivilegeGroup.bdb page 16080 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 16080 8000184f READ 9 HELD suPrivilegeGroup.bdb page 6091 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6091 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1536 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 1536 8000184f READ 6 HELD suPrivilegeGroup.bdb page 807 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 807 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15357 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15357 8000184f READ 3 HELD suPrivilegeGroup.bdb page 28 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 28 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13580 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13580 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1189 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1189 8000184f READ 3 HELD suPrivilegeGroup.bdb page 841 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 841 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2085 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2085 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5496 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5496 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7261 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7261 8000184f READ 3 HELD suPrivilegeGroup.bdb page 22076 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 22076 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20634 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20634 8000184f READ 6 HELD suPrivilegeGroup.bdb page 12120 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 12120 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9769 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9769 8000184f READ 6 HELD suPrivilegeGroup.bdb page 2433 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 2433 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 43 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7377 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 7377 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4273 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 4273 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7200 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7200 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2577 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2577 8000184f READ 7 HELD suPrivilegeGroup.bdb page 21841 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 21841 8000184f READ 3 HELD suPrivilegeGroup.bdb page 196 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 196 8000184f READ 3 HELD suPrivilegeGroup.bdb page 985 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 985 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8911 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8911 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2493 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2493 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1208 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1208 8000184f READ 3 HELD suPrivilegeGroup.bdb page 353 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 353 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5 8000184f READ 3 HELD suPrivilegeGroup.bdb page 22149 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 22149 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2136 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2136 8000184f READ 3 HELD suPrivilegeGroup.bdb page 39 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 39 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13 8000184f READ 3 HELD suPrivilegeGroup.bdb page 11440 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 11440 8000184f READ 9 HELD suPrivilegeGroup.bdb page 154 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 154 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18777 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18777 8000184f READ 3 HELD suPrivilegeGroup.bdb page 518 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 518 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20650 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20650 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20984 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20984 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1258 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1258 8000184f READ 3 HELD suPrivilegeGroup.bdb page 19104 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 19104 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1833 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1833 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10093 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10093 8000184f READ 6 HELD suPrivilegeGroup.bdb page 456 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 456 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2464 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2464 8000184f READ 3 HELD suPrivilegeGroup.bdb page 406 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 406 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5804 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5804 8000184f READ 6 HELD suPrivilegeGroup.bdb page 805 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 805 8000184f READ 6 HELD suPrivilegeGroup.bdb page 72 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 72 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18309 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18309 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15651 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15651 8000184f READ 3 HELD suPrivilegeGroup.bdb page 32 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 32 8000184f READ 6 HELD suPrivilegeGroup.bdb page 8020 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 8020 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16521 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16521 8000184f READ 3 HELD suPrivilegeGroup.bdb page 436 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 436 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3028 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3028 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3034 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3034 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5292 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5292 8000184f READ 3 HELD suPrivilegeGroup.bdb page 85 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 85 8000184f READ 3 HELD suPrivilegeGroup.bdb page 475 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 475 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6930 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6930 8000184f READ 6 HELD suPrivilegeGroup.bdb page 4426 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4426 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3714 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3714 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20096 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20096 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5919 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5919 8000184f READ 3 HELD suPrivilegeGroup.bdb page 84 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 84 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15522 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15522 8000184f READ 6 HELD suPrivilegeGroup.bdb page 203 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 203 8000184f READ 3 HELD suPrivilegeGroup.bdb page 967 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 967 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8550 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8550 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20014 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20014 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17858 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17858 8000184f READ 12 HELD suPrivilegeGroup.bdb page 22 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 22 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6225 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6225 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2487 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2487 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3299 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3299 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2055 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2055 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4832 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4832 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21970 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 21970 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13772 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13772 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1926 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1926 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2677 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2677 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16477 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16477 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4745 8000184f READ 3 HELD suPrivilegeGroup.bdb page 612 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 612 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5181 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5181 8000184f READ 9 HELD suPrivilegeGroup.bdb page 74 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 74 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3169 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3169 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7030 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 7030 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4851 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 4851 8000184f READ 12 HELD suPrivilegeGroup.bdb page 11218 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 11218 8000184f READ 12 HELD suPrivilegeGroup.bdb page 13764 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13764 8000184f READ 9 HELD suPrivilegeGroup.bdb page 19105 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 19105 8000184f READ 9 HELD suPrivilegeGroup.bdb page 286 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 286 8000184f READ 9 HELD suPrivilegeGroup.bdb page 16709 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 16709 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20916 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20916 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 6812 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1629 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1629 8000184f READ 6 HELD suPrivilegeGroup.bdb page 6174 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 6174 8000184f READ 3 HELD suPrivilegeGroup.bdb page 699 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 699 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4829 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4829 8000184f READ 9 HELD suPrivilegeGroup.bdb page 36 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 36 8000184f READ 9 HELD suPrivilegeGroup.bdb page 10079 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 10079 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5256 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5256 8000184f READ 4 HELD suPrivilegeGroup.bdb page 7927 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7927 8000184f READ 4 HELD suPrivilegeGroup.bdb page 140 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 140 8000184f READ 4 HELD suPrivilegeGroup.bdb page 137 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 137 8000184f READ 4 HELD suPrivilegeGroup.bdb page 4679 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4679 8000184f READ 7 HELD suPrivilegeGroup.bdb page 215 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 215 8000184f READ 4 HELD suPrivilegeGroup.bdb page 17856 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 17856 8000184f READ 4 HELD suPrivilegeGroup.bdb page 21928 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 21928 8000184f READ 4 HELD suPrivilegeGroup.bdb page 13363 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13363 8000184f READ 7 HELD suPrivilegeGroup.bdb page 2680 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2680 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3341 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3341 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7275 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7275 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3219 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3219 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5842 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5842 8000184f READ 3 HELD suPrivilegeGroup.bdb page 212 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 212 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5470 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5470 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4833 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4833 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3401 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 3401 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13615 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13615 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1877 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1877 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16516 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16516 8000184f READ 3 HELD suPrivilegeGroup.bdb page 216 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 216 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5777 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5777 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3027 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3027 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2361 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2361 8000184f READ 3 HELD suPrivilegeGroup.bdb page 114 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 114 8000184f READ 3 HELD suPrivilegeGroup.bdb page 329 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 329 8000184f READ 3 HELD suPrivilegeGroup.bdb page 428 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 428 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6432 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6432 8000184f READ 3 HELD suPrivilegeGroup.bdb page 695 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 695 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9838 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9838 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2981 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2981 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3274 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3274 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13757 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13757 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16503 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16503 8000184f READ 3 HELD suPrivilegeGroup.bdb page 62 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 62 8000184f READ 4 HELD suPrivilegeGroup.bdb page 1811 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1811 8000184f READ 3 HELD suPrivilegeGroup.bdb page 554 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 554 8000184f READ 3 HELD suPrivilegeGroup.bdb page 681 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 681 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20470 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20470 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5575 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5575 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4006 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4006 8000184f READ 1 HELD modifyTimestamp.bdb page 1669 8000184f WRITE 2 HELD modifyTimestamp.bdb page 1669 8000184f READ 1 HELD suPrivilegeGroup.bdb page 15898 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 15898 8000184f READ 1 HELD suPrivilegeGroup.bdb page 986 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 986 8000184f READ 1 HELD suPrivilegeGroup.bdb page 3279 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 3279 8000184f READ 1 HELD suPrivilegeGroup.bdb page 2895 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 2895 8000184f READ 1 HELD suPrivilegeGroup.bdb page 3451 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 3451 8000184f READ 1 HELD modifyTimestamp.bdb page 1718 8000184f WRITE 1 HELD modifyTimestamp.bdb page 1718 8000184f WRITE 1 HELD id2entry.bdb page 25669 8000184f WRITE 2 HELD id2entry.bdb page 0 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D Locks grouped by object Locker Mode Count Status ----------------- Object --------------- 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4278 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4278 8000184f READ 7 HELD suPrivilegeGroup.bdb page 20665 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20665 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4273 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 4273 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16516 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16516 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16521 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16521 8000184f READ 3 HELD suPrivilegeGroup.bdb page 131 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 131 1fb READ 1 WAIT suPrivilegeGroup.bdb page 131 1ff READ 1 WAIT suPrivilegeGroup.bdb page 131 8000184f READ 3 HELD suPrivilegeGroup.bdb page 130 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 130 8000184f READ 9 HELD suPrivilegeGroup.bdb page 20639 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 20639 8000184f READ 66 HELD suPrivilegeGroup.bdb page 142 8000184f WRITE 30 HELD suPrivilegeGroup.bdb page 142 8000184f READ 4 HELD suPrivilegeGroup.bdb page 140 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 140 8000184f READ 6 HELD suPrivilegeGroup.bdb page 16542 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 16542 8000184f READ 3 HELD suPrivilegeGroup.bdb page 138 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 138 8000184f READ 4 HELD suPrivilegeGroup.bdb page 137 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 137 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20634 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20634 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20633 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20633 8000184f READ 48 HELD suPrivilegeGroup.bdb page 151 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 151 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20706 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20706 8000184f READ 9 HELD suPrivilegeGroup.bdb page 144 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 144 8000184f READ 6 HELD suPrivilegeGroup.bdb page 16608 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 16608 8000184f READ 9 HELD suPrivilegeGroup.bdb page 154 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 154 8000184f READ 6 HELD suPrivilegeGroup.bdb page 226 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 226 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4332 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 4332 8000184f READ 39 HELD suPrivilegeGroup.bdb page 235 8000184f WRITE 17 HELD suPrivilegeGroup.bdb page 235 8000184f READ 45 HELD suPrivilegeGroup.bdb page 8435 8000184f WRITE 17 HELD suPrivilegeGroup.bdb page 8435 8000184f READ 33 HELD suPrivilegeGroup.bdb page 16578 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 16578 8000184f READ 51 HELD suPrivilegeGroup.bdb page 248 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 248 8000184f READ 3 HELD suPrivilegeGroup.bdb page 197 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 197 8000184f READ 3 HELD suPrivilegeGroup.bdb page 196 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 196 8000184f READ 18 HELD suPrivilegeGroup.bdb page 20692 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 20692 8000184f READ 3 HELD suPrivilegeGroup.bdb page 194 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 194 8000184f READ 9 HELD suPrivilegeGroup.bdb page 205 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 205 8000184f READ 3 HELD suPrivilegeGroup.bdb page 204 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 204 8000184f READ 6 HELD suPrivilegeGroup.bdb page 203 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 203 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16606 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16606 8000184f READ 7 HELD suPrivilegeGroup.bdb page 215 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 215 8000184f READ 3 HELD suPrivilegeGroup.bdb page 213 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 213 8000184f READ 3 HELD suPrivilegeGroup.bdb page 212 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 212 8000184f READ 3 HELD suPrivilegeGroup.bdb page 209 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 209 8000184f READ 9 HELD suPrivilegeGroup.bdb page 217 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 217 8000184f READ 3 HELD suPrivilegeGroup.bdb page 216 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 216 8000184f READ 3 HELD suPrivilegeGroup.bdb page 39 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 39 8000184f READ 9 HELD suPrivilegeGroup.bdb page 36 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 36 8000184f READ 6 HELD suPrivilegeGroup.bdb page 35 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 35 8000184f READ 29 HELD suPrivilegeGroup.bdb page 33 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 33 8000184f WRITE 2 HELD id2entry.bdb page 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 32 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 32 bf READ 1 HELD id2entry.bdb handle 0 c1 READ 1 HELD dn2id.bdb handle 0 ca READ 1 HELD objectClass.bdb handle 0 8000184f READ 16 HELD suPrivilegeGroup.bdb page 43 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 43 126 READ 1 HELD modifyTimestamp.bdb handle 0 163 READ 1 HELD cn.bdb handle 0 8000184f READ 6 HELD suPrivilegeGroup.bdb page 40 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 40 cd READ 1 HELD krb5PrincipalName.bdb handle 0 168 READ 1 HELD displayName.bdb handle 0 f3 READ 1 HELD suDisplayAffiliation.bdb handle 0 e9 READ 1 HELD suVisibIdentity.bdb handle 0 154 READ 1 HELD suRegisteredName.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8250 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8250 111 READ 1 HELD suGwAffilCode1.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 62 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 62 8000184f READ 24 HELD suPrivilegeGroup.bdb page 8248 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 8248 14f READ 1 HELD suCN.bdb handle 0 8000184f READ 30 HELD suPrivilegeGroup.bdb page 61 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 61 183 READ 1 HELD sn.bdb handle 0 116 READ 1 HELD suAffiliation.bdb handle 0 d6 READ 1 HELD suRegID.bdb handle 0 fd READ 1 HELD suVisibAffiliation1.bdb handle 0 8000184f READ 9 HELD suPrivilegeGroup.bdb page 16396 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 16396 8000184f READ 15 HELD suPrivilegeGroup.bdb page 4101 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 4101 d3 READ 1 HELD suGeneralID.bdb handle 0 8000184f READ 4 HELD suPrivilegeGroup.bdb page 7 e1 READ 1 HELD suSN.bdb handle 0 d0 READ 1 HELD uid.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5 dd READ 1 HELD suSunetID.bdb handle 0 8000184f READ 2 HELD suPrivilegeGroup.bdb page 4 8000184f READ 5 HELD suPrivilegeGroup.bdb page 3 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3 8000184f READ 10 HELD suPrivilegeGroup.bdb page 2 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 2 13a READ 1 HELD suVisibEmail.bdb handle 0 d9 READ 1 HELD suPrivilegeGroup.bdb handle 0 8000184f READ 31 HELD suPrivilegeGroup.bdb page 14 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 14 140 READ 1 HELD suPrimaryOrganizationID.bdbhandle 0 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13 1b0 READ 1 HELD homePhone.bdb handle 0 8000184f READ 15 HELD suPrivilegeGroup.bdb page 12 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 12 ee READ 1 HELD suVisibHomeAddress.bdb handle 0 8000184f READ 4 HELD suPrivilegeGroup.bdb page 10 107 READ 1 HELD suVisibHomePhone.bdb handle 0 f8 READ 1 HELD suVisibPermanentAddress.bdbhandle 0 8000184f READ 27 HELD suPrivilegeGroup.bdb page 8 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 8 e4 READ 1 HELD suVisibSunetID.bdb handle 0 10c READ 1 HELD suVisibMailCode.bdb handle 0 8000184f READ 12 HELD suPrivilegeGroup.bdb page 22 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 22 11b READ 1 HELD suVisibMailAddress.bdb handle 0 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20 14a READ 1 HELD suVisibStreet.bdb handle 0 145 READ 1 HELD suVisibAffilAddress1.bdb handle 0 188 READ 1 HELD suGwAffilPhone1.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17 102 READ 1 HELD suVisibTelephoneNumber.bdbhandle 0 8000184f READ 21 HELD suPrivilegeGroup.bdb page 16 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 16 120 READ 1 HELD suVisibAffilPhone1.bdb handle 0 8000184f READ 6 HELD suPrivilegeGroup.bdb page 31 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 31 133 READ 1 HELD suVisibAffiliation2.bdb handle 0 8000184f READ 2 HELD suPrivilegeGroup.bdb page 30 12e READ 1 HELD suGwAffilCode2.bdb handle 0 8000184f READ 9 HELD suPrivilegeGroup.bdb page 29 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 29 18d READ 1 HELD suVisibLocalAddress.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 28 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 28 1b5 READ 1 HELD suLocalPhone.bdb handle 0 8000184f READ 9 HELD suPrivilegeGroup.bdb page 27 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 27 172 READ 1 HELD suVisibHomePage.bdb handle 0 192 READ 1 HELD suVisibAffiliation3.bdb handle 0 16d READ 1 HELD suGwAffilCode3.bdb handle 0 1ba READ 1 HELD suGwAffilFax1.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16503 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16503 8000184f READ 12 HELD suPrivilegeGroup.bdb page 8301 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 8301 8000184f READ 3 HELD suPrivilegeGroup.bdb page 96 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 96 8000184f READ 3 HELD suPrivilegeGroup.bdb page 107 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 107 8000184f READ 24 HELD suPrivilegeGroup.bdb page 115 8000184f WRITE 12 HELD suPrivilegeGroup.bdb page 115 8000184f READ 3 HELD suPrivilegeGroup.bdb page 114 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 114 8000184f READ 32 HELD suPrivilegeGroup.bdb page 16454 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 16454 8000184f READ 30 HELD suPrivilegeGroup.bdb page 113 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 113 8000184f READ 31 HELD suPrivilegeGroup.bdb page 112 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 112 8000184f READ 12 HELD suPrivilegeGroup.bdb page 127 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 127 8000184f READ 21 HELD suPrivilegeGroup.bdb page 4219 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 4219 8000184f READ 12 HELD suPrivilegeGroup.bdb page 123 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 123 8000184f READ 3 HELD suPrivilegeGroup.bdb page 70 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 70 8000184f READ 42 HELD suPrivilegeGroup.bdb page 69 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 69 8000184f READ 28 HELD suPrivilegeGroup.bdb page 68 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 68 8000184f READ 3 HELD suPrivilegeGroup.bdb page 67 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 67 8000184f READ 12 HELD suPrivilegeGroup.bdb page 64 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 64 8000184f READ 20 HELD suPrivilegeGroup.bdb page 79 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 79 8000184f READ 6 HELD suPrivilegeGroup.bdb page 77 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 77 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4170 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4170 8000184f READ 9 HELD suPrivilegeGroup.bdb page 76 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 76 8000184f READ 9 HELD suPrivilegeGroup.bdb page 74 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 74 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16477 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16477 8000184f READ 6 HELD suPrivilegeGroup.bdb page 72 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 72 8000184f READ 12 HELD suPrivilegeGroup.bdb page 86 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 86 8000184f READ 3 HELD suPrivilegeGroup.bdb page 85 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 85 8000184f READ 3 HELD suPrivilegeGroup.bdb page 84 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 84 8000184f READ 9 HELD suPrivilegeGroup.bdb page 83 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 83 8000184f READ 9 HELD suPrivilegeGroup.bdb page 20900 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 20900 8000184f READ 39 HELD suPrivilegeGroup.bdb page 81 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 81 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20904 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20904 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20916 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20916 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4512 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 4512 8000184f READ 54 HELD suPrivilegeGroup.bdb page 431 8000184f WRITE 20 HELD suPrivilegeGroup.bdb page 431 8000184f READ 3 HELD suPrivilegeGroup.bdb page 428 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 428 8000184f READ 3 HELD suPrivilegeGroup.bdb page 436 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 436 8000184f READ 19 HELD suPrivilegeGroup.bdb page 434 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 434 8000184f READ 6 HELD suPrivilegeGroup.bdb page 433 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 433 8000184f READ 51 HELD suPrivilegeGroup.bdb page 432 8000184f WRITE 21 HELD suPrivilegeGroup.bdb page 432 8000184f READ 8 HELD suPrivilegeGroup.bdb page 447 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 447 8000184f READ 3 HELD suPrivilegeGroup.bdb page 406 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 406 8000184f READ 13 HELD suPrivilegeGroup.bdb page 403 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 403 8000184f READ 9 HELD suPrivilegeGroup.bdb page 402 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 402 8000184f READ 18 HELD suPrivilegeGroup.bdb page 400 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 400 8000184f READ 3 HELD suPrivilegeGroup.bdb page 413 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 413 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4583 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4583 8000184f READ 3 HELD suPrivilegeGroup.bdb page 12785 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 12785 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20984 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20984 8000184f READ 15 HELD suPrivilegeGroup.bdb page 498 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 498 8000184f READ 6 HELD suPrivilegeGroup.bdb page 4603 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4603 8000184f READ 24 HELD suPrivilegeGroup.bdb page 452 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 452 8000184f READ 15 HELD suPrivilegeGroup.bdb page 458 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 458 8000184f READ 6 HELD suPrivilegeGroup.bdb page 456 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 456 8000184f READ 3 HELD suPrivilegeGroup.bdb page 475 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 475 8000184f READ 9 HELD suPrivilegeGroup.bdb page 310 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 310 8000184f READ 12 HELD suPrivilegeGroup.bdb page 305 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 305 8000184f READ 9 HELD suPrivilegeGroup.bdb page 16648 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 16648 8000184f READ 3 HELD suPrivilegeGroup.bdb page 16662 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 16662 8000184f READ 3 HELD suPrivilegeGroup.bdb page 271 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 271 8000184f READ 3 HELD suPrivilegeGroup.bdb page 275 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 275 8000184f READ 9 HELD suPrivilegeGroup.bdb page 286 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 286 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8550 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8550 8000184f READ 27 HELD suPrivilegeGroup.bdb page 8545 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 8545 8000184f READ 3 HELD suPrivilegeGroup.bdb page 353 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 353 8000184f READ 9 HELD suPrivilegeGroup.bdb page 8564 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 8564 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20806 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20806 8000184f READ 9 HELD suPrivilegeGroup.bdb page 16709 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 16709 8000184f READ 6 HELD suPrivilegeGroup.bdb page 4426 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4426 8000184f READ 9 HELD suPrivilegeGroup.bdb page 332 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 332 8000184f READ 3 HELD suPrivilegeGroup.bdb page 329 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 329 8000184f READ 15 HELD suPrivilegeGroup.bdb page 8528 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 8528 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17058 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17058 8000184f READ 2 HELD suPrivilegeGroup.bdb page 12964 8000184f READ 9 HELD suPrivilegeGroup.bdb page 683 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 683 8000184f READ 12 HELD suPrivilegeGroup.bdb page 682 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 682 8000184f READ 3 HELD suPrivilegeGroup.bdb page 681 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 681 8000184f READ 3 HELD suPrivilegeGroup.bdb page 680 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 680 8000184f READ 3 HELD suPrivilegeGroup.bdb page 695 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 695 8000184f READ 38 HELD suPrivilegeGroup.bdb page 8881 8000184f WRITE 20 HELD suPrivilegeGroup.bdb page 8881 8000184f READ 12 HELD suPrivilegeGroup.bdb page 694 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 694 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8895 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8895 8000184f READ 3 HELD suPrivilegeGroup.bdb page 689 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 689 8000184f READ 3 HELD suPrivilegeGroup.bdb page 699 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 699 8000184f READ 3 HELD suPrivilegeGroup.bdb page 696 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 696 8000184f READ 31 HELD suPrivilegeGroup.bdb page 4745 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4745 8000184f READ 6 HELD suPrivilegeGroup.bdb page 4759 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4759 8000184f READ 6 HELD suPrivilegeGroup.bdb page 656 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 656 8000184f READ 9 HELD suPrivilegeGroup.bdb page 17122 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 17122 8000184f READ 3 HELD suPrivilegeGroup.bdb page 664 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 664 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4833 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4833 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4832 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4832 8000184f READ 42 HELD suPrivilegeGroup.bdb page 737 8000184f WRITE 22 HELD suPrivilegeGroup.bdb page 737 8000184f READ 9 HELD suPrivilegeGroup.bdb page 745 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 745 8000184f READ 9 HELD suPrivilegeGroup.bdb page 4851 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 4851 8000184f READ 33 HELD suPrivilegeGroup.bdb page 765 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 765 8000184f READ 36 HELD suPrivilegeGroup.bdb page 21195 8000184f WRITE 16 HELD suPrivilegeGroup.bdb page 21195 8000184f READ 3 HELD suPrivilegeGroup.bdb page 8911 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 8911 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21202 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 21202 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4829 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4829 8000184f READ 9 HELD suPrivilegeGroup.bdb page 730 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 730 8000184f READ 3 HELD suPrivilegeGroup.bdb page 554 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 554 8000184f READ 15 HELD suPrivilegeGroup.bdb page 566 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 566 8000184f READ 32 HELD suPrivilegeGroup.bdb page 575 8000184f WRITE 16 HELD suPrivilegeGroup.bdb page 575 8000184f READ 3 HELD suPrivilegeGroup.bdb page 569 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 569 8000184f READ 3 HELD suPrivilegeGroup.bdb page 518 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 518 8000184f READ 27 HELD suPrivilegeGroup.bdb page 513 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 513 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21017 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21017 8000184f READ 9 HELD suPrivilegeGroup.bdb page 8804 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 8804 8000184f READ 3 HELD suPrivilegeGroup.bdb page 612 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 612 8000184f READ 4 HELD suPrivilegeGroup.bdb page 4679 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 4679 8000184f READ 9 HELD suPrivilegeGroup.bdb page 13245 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 13245 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4999 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4999 8000184f READ 27 HELD suPrivilegeGroup.bdb page 9092 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 9092 8000184f READ 6 HELD suPrivilegeGroup.bdb page 9090 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 9090 8000184f READ 48 HELD suPrivilegeGroup.bdb page 21406 8000184f WRITE 20 HELD suPrivilegeGroup.bdb page 21406 8000184f READ 24 HELD suPrivilegeGroup.bdb page 5000 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 5000 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5118 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5118 8000184f READ 3 HELD suPrivilegeGroup.bdb page 967 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 967 8000184f READ 2 HELD suPrivilegeGroup.bdb page 966 8000184f READ 6 HELD suPrivilegeGroup.bdb page 971 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 971 8000184f READ 3 HELD suPrivilegeGroup.bdb page 968 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 968 8000184f READ 1 HELD suPrivilegeGroup.bdb page 986 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 986 8000184f READ 3 HELD suPrivilegeGroup.bdb page 985 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 985 8000184f READ 6 HELD suPrivilegeGroup.bdb page 807 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 807 8000184f READ 31 HELD suPrivilegeGroup.bdb page 806 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 806 8000184f READ 6 HELD suPrivilegeGroup.bdb page 805 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 805 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4927 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4927 8000184f READ 4 HELD suPrivilegeGroup.bdb page 793 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 793 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21353 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 21353 8000184f READ 24 HELD suPrivilegeGroup.bdb page 892 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 892 8000184f READ 9 HELD suPrivilegeGroup.bdb page 890 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 890 8000184f READ 3 HELD suPrivilegeGroup.bdb page 841 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 841 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1189 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1189 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5292 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5292 8000184f READ 27 HELD suPrivilegeGroup.bdb page 1214 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 1214 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1208 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1208 8000184f READ 9 HELD suPrivilegeGroup.bdb page 21663 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 21663 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5256 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5256 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17639 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17639 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9369 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9369 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1182 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1182 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13539 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13539 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17646 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17646 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21738 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 21738 8000184f READ 36 HELD suPrivilegeGroup.bdb page 9452 8000184f WRITE 16 HELD suPrivilegeGroup.bdb page 9452 8000184f READ 9 HELD suPrivilegeGroup.bdb page 17650 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 17650 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1258 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1258 8000184f READ 33 HELD suPrivilegeGroup.bdb page 1268 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 1268 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1265 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1265 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9467 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9467 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1230 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 1230 8000184f READ 33 HELD suPrivilegeGroup.bdb page 5328 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 5328 8000184f READ 39 HELD suPrivilegeGroup.bdb page 17445 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 17445 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1060 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1060 8000184f READ 4 HELD suPrivilegeGroup.bdb page 13363 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13363 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5181 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5181 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1039 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1039 8000184f WRITE 1 HELD id2entry.bdb page 25669 8000184f READ 24 HELD suPrivilegeGroup.bdb page 1041 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 1041 8000184f READ 27 HELD suPrivilegeGroup.bdb page 1127 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 1127 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1123 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1123 8000184f READ 4 HELD suPrivilegeGroup.bdb page 1121 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1121 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5238 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 5238 8000184f READ 15 HELD suPrivilegeGroup.bdb page 21581 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 21581 8000184f READ 6 HELD suPrivilegeGroup.bdb page 9301 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 9301 8000184f READ 12 HELD suPrivilegeGroup.bdb page 9300 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 9300 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9298 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9298 8000184f READ 9 HELD suPrivilegeGroup.bdb page 9296 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 9296 8000184f READ 4 HELD suPrivilegeGroup.bdb page 21928 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 21928 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1446 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1446 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5537 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5537 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13757 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13757 8000184f READ 7 HELD suPrivilegeGroup.bdb page 9663 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 9663 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13754 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13754 8000184f READ 12 HELD suPrivilegeGroup.bdb page 13753 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 13753 8000184f READ 51 HELD suPrivilegeGroup.bdb page 1471 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 1471 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21911 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21911 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1412 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1412 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1410 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1410 1f5 READ 23 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f7 READ 22 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f8 READ 23 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f6 READ 29 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 c7 READ 8 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 1f4 READ 14 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 c5 READ 16 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 e0 READ 11 HELD 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 8000184f WRITE 1 WAIT 0x117488 len: 9 data: = 7i0x010x000x000x000x000x000x00 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13717 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13717 8000184f READ 9 HELD suPrivilegeGroup.bdb page 9630 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 9630 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1424 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1424 8000184f READ 15 HELD suPrivilegeGroup.bdb page 9624 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 9624 8000184f READ 15 HELD suPrivilegeGroup.bdb page 22001 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 22001 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1519 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1519 8000184f READ 3 HELD suPrivilegeGroup.bdb page 17858 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 17858 8000184f READ 12 HELD suPrivilegeGroup.bdb page 13764 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13764 8000184f READ 4 HELD suPrivilegeGroup.bdb page 17856 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 17856 1f9 READ 1 WAIT suPrivilegeGroup.bdb page 17856 1fd READ 1 WAIT suPrivilegeGroup.bdb page 17856 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13762 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13762 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5575 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5575 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13760 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13760 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13774 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13774 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13772 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13772 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13771 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 13771 8000184f READ 6 HELD suPrivilegeGroup.bdb page 21970 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 21970 8000184f READ 6 HELD suPrivilegeGroup.bdb page 13615 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 13615 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1326 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1326 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1323 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1323 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1335 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1335 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21773 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21773 8000184f READ 6 HELD suPrivilegeGroup.bdb page 17675 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 17675 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13580 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13580 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1299 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1299 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21839 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21839 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5496 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5496 8000184f READ 27 HELD suPrivilegeGroup.bdb page 13633 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 13633 8000184f READ 7 HELD suPrivilegeGroup.bdb page 21841 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 21841 8000184f READ 9 HELD suPrivilegeGroup.bdb page 21851 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 21851 8000184f READ 3 HELD suPrivilegeGroup.bdb page 21848 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 21848 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1364 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1364 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5470 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5470 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9563 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9563 8000184f READ 3 HELD suPrivilegeGroup.bdb page 13999 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13999 8000184f READ 1 HELD modifyTimestamp.bdb page 1669 8000184f WRITE 2 HELD modifyTimestamp.bdb page 1669 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5804 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5804 8000184f READ 27 HELD suPrivilegeGroup.bdb page 14005 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 14005 8000184f READ 6 HELD suPrivilegeGroup.bdb page 22151 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 22151 8000184f READ 3 HELD suPrivilegeGroup.bdb page 22149 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 22149 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1726 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1726 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1675 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 1675 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5777 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5777 8000184f READ 9 HELD suPrivilegeGroup.bdb page 9880 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 9880 8000184f READ 1 HELD modifyTimestamp.bdb page 1718 8000184f WRITE 1 HELD modifyTimestamp.bdb page 1718 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1762 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1762 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1783 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1783 8000184f READ 12 HELD suPrivilegeGroup.bdb page 5876 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 5876 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5842 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5842 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5841 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5841 8000184f READ 5 HELD suPrivilegeGroup.bdb page 13864 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 13864 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9769 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9769 8000184f READ 3 HELD suPrivilegeGroup.bdb page 22076 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 22076 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5688 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5688 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1536 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 1536 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5648 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5648 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1562 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1562 8000184f READ 3 HELD suPrivilegeGroup.bdb page 9838 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 9838 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1646 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1646 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1642 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1642 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1655 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 1655 8000184f READ 18 HELD suPrivilegeGroup.bdb page 1649 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 1649 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5758 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5758 8000184f READ 12 HELD suPrivilegeGroup.bdb page 9795 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 9795 8000184f READ 3 HELD suPrivilegeGroup.bdb page 22090 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 22090 da READ 1 WAIT suPrivilegeGroup.bdb page 22090 dc READ 1 WAIT suPrivilegeGroup.bdb page 22090 201 READ 1 WAIT suPrivilegeGroup.bdb page 22090 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5698 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5698 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1612 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1612 8000184f READ 6 HELD suPrivilegeGroup.bdb page 9823 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 9823 8000184f READ 12 HELD suPrivilegeGroup.bdb page 1630 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 1630 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1629 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1629 8000184f READ 9 HELD suPrivilegeGroup.bdb page 18362 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 18362 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18309 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18309 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18308 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18308 8000184f READ 6 HELD suPrivilegeGroup.bdb page 1926 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1926 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1931 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1931 8000184f READ 3 HELD suPrivilegeGroup.bdb page 14306 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 14306 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1946 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1946 8000184f READ 9 HELD suPrivilegeGroup.bdb page 14281 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 14281 8000184f READ 9 HELD suPrivilegeGroup.bdb page 6091 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6091 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2007 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2007 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10022 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10022 8000184f READ 42 HELD suPrivilegeGroup.bdb page 18208 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 18208 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6104 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6104 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1833 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1833 8000184f READ 15 HELD suPrivilegeGroup.bdb page 1797 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 1797 8000184f READ 4 HELD suPrivilegeGroup.bdb page 1811 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 1811 8000184f READ 3 HELD suPrivilegeGroup.bdb page 5919 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 5919 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10093 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10093 8000184f READ 3 HELD suPrivilegeGroup.bdb page 14185 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 14185 8000184f READ 6 HELD suPrivilegeGroup.bdb page 5999 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 5999 8000184f READ 3 HELD suPrivilegeGroup.bdb page 1877 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 1877 8000184f READ 9 HELD suPrivilegeGroup.bdb page 10079 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 10079 8000184f READ 9 HELD suPrivilegeGroup.bdb page 1875 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 1875 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10403 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10403 1fb READ 1 HELD suPrivilegeGroup.bdb page 14507 1ff READ 1 HELD suPrivilegeGroup.bdb page 14507 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2212 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2212 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10411 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 10411 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10420 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10420 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10419 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10419 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10416 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10416 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6301 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6301 8000184f READ 9 HELD suPrivilegeGroup.bdb page 14584 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 14584 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6397 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 6397 8000184f READ 6 HELD suPrivilegeGroup.bdb page 2296 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 2296 8000184f READ 3 HELD suPrivilegeGroup.bdb page 10460 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 10460 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2085 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2085 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2055 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2055 8000184f READ 6 HELD suPrivilegeGroup.bdb page 6174 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 6174 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6225 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6225 8000184f READ 33 HELD suPrivilegeGroup.bdb page 18520 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 18520 8000184f READ 7 HELD suPrivilegeGroup.bdb page 14426 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 14426 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10332 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10332 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2136 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2136 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2464 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2464 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2479 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2479 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2487 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2487 8000184f READ 18 HELD suPrivilegeGroup.bdb page 2485 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 2485 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2484 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2484 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2482 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2482 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2495 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2495 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2493 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2493 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6531 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6531 8000184f READ 6 HELD suPrivilegeGroup.bdb page 2433 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 2433 8000184f READ 39 HELD suPrivilegeGroup.bdb page 6557 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 6557 8000184f READ 15 HELD suPrivilegeGroup.bdb page 2463 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2463 8000184f READ 21 HELD suPrivilegeGroup.bdb page 18913 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 18913 8000184f READ 6 HELD suPrivilegeGroup.bdb page 18910 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 18910 8000184f READ 30 HELD suPrivilegeGroup.bdb page 10715 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 10715 8000184f READ 22 HELD suPrivilegeGroup.bdb page 2525 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 2525 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2522 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2522 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6432 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6432 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2361 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2361 8000184f READ 6 HELD suPrivilegeGroup.bdb page 14604 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 14604 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18705 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18705 8000184f READ 6 HELD suPrivilegeGroup.bdb page 18704 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 18704 8000184f READ 6 HELD suPrivilegeGroup.bdb page 6498 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 6498 8000184f READ 21 HELD suPrivilegeGroup.bdb page 18801 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 18801 8000184f READ 6 HELD suPrivilegeGroup.bdb page 6518 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 6518 8000184f READ 28 HELD suPrivilegeGroup.bdb page 2418 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 2418 8000184f READ 39 HELD suPrivilegeGroup.bdb page 18760 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 18760 8000184f READ 6 HELD suPrivilegeGroup.bdb page 18778 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 18778 8000184f READ 3 HELD suPrivilegeGroup.bdb page 18777 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 18777 8000184f READ 15 HELD suPrivilegeGroup.bdb page 6492 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6492 8000184f READ 9 HELD suPrivilegeGroup.bdb page 19105 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 19105 8000184f READ 3 HELD suPrivilegeGroup.bdb page 19104 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 19104 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6489 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6489 8000184f READ 9 HELD suPrivilegeGroup.bdb page 6830 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6830 8000184f READ 9 HELD suPrivilegeGroup.bdb page 6835 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 6835 8000184f READ 15 HELD suPrivilegeGroup.bdb page 19078 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 19078 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6846 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 6846 15e READ 1 HELD suVisibFacsimileTelephoneNumber.bdbhandle = 0 1e5 READ 1 HELD suVisibProfile.bdb handle 0 159 READ 1 HELD suVisibAffilFax1.bdb handle 0 1ef READ 1 HELD suVisibMobilePhone.bdb handle 0 19c READ 1 HELD suVisibAffilPhone3.bdb handle 0 197 READ 1 HELD suGwAffilPhone3.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6787 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6787 1ea READ 1 HELD suGwAffilCode4.bdb handle 0 1a1 READ 1 HELD suGwAffilCode5.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2701 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2701 1c4 READ 1 HELD suVisibAffilAddress2.bdb handle 0 17c READ 1 HELD suVisibAffilPhone2.bdb handle 0 177 READ 1 HELD suGwAffilPhone2.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 19101 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 19101 1c9 READ 1 HELD suVisibAffilFax2.bdb handle 0 8000184f READ 27 HELD suPrivilegeGroup.bdb page 2711 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 2711 1bf READ 1 HELD suGwAffilFax2.bdb handle 0 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6803 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6803 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2710 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2710 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6802 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6802 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6800 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6800 1ab READ 1 HELD suGwAffilPhone5.bdb handle 0 1a6 READ 1 HELD suVisibAffilPhone5.bdb handle 0 8000184f READ 8 HELD suPrivilegeGroup.bdb page 6812 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 6812 1d8 READ 1 HELD suMailDrop.bdb handle 0 1db READ 1 HELD suSeasStatus.bdb handle 0 129 READ 1 HELD suKerberosStatus.bdb handle 0 1e0 READ 1 HELD uidNumber.bdb handle 0 1ce READ 1 HELD suDialinStatus.bdb handle 0 1d3 READ 1 HELD suLelandStatus.bdb handle 0 8000184f READ 15 HELD suPrivilegeGroup.bdb page 2796 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2796 8000184f READ 19 HELD suPrivilegeGroup.bdb page 15054 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 15054 8000184f READ 9 HELD suPrivilegeGroup.bdb page 15069 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 15069 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2599 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2599 8000184f READ 6 HELD suPrivilegeGroup.bdb page 10793 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 10793 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2603 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2603 8000184f READ 7 HELD suPrivilegeGroup.bdb page 2610 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2610 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2618 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2618 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2577 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2577 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2677 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2677 8000184f READ 7 HELD suPrivilegeGroup.bdb page 2680 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 2680 8000184f READ 24 HELD suPrivilegeGroup.bdb page 2647 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 2647 8000184f READ 9 HELD suPrivilegeGroup.bdb page 2646 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 2646 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2981 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2981 da READ 1 HELD suPrivilegeGroup.bdb page 2990 dc READ 1 HELD suPrivilegeGroup.bdb page 2990 1f9 READ 1 HELD suPrivilegeGroup.bdb page 2990 1fd READ 1 HELD suPrivilegeGroup.bdb page 2990 201 READ 1 HELD suPrivilegeGroup.bdb page 2990 8000184f READ 13 HELD suPrivilegeGroup.bdb page 15285 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 15285 8000184f READ 2 HELD suPrivilegeGroup.bdb page 2988 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7062 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7062 8000184f READ 13 HELD suPrivilegeGroup.bdb page 15259 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 15259 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15357 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15357 8000184f READ 12 HELD suPrivilegeGroup.bdb page 11218 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 11218 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3028 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3028 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3027 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3027 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3034 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3034 8000184f READ 12 HELD suPrivilegeGroup.bdb page 6958 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 6958 8000184f READ 5 HELD suPrivilegeGroup.bdb page 2859 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2859 8000184f READ 6 HELD suPrivilegeGroup.bdb page 2878 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 2878 8000184f READ 21 HELD suPrivilegeGroup.bdb page 2816 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 2816 8000184f READ 33 HELD suPrivilegeGroup.bdb page 6935 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 6935 8000184f READ 15 HELD suPrivilegeGroup.bdb page 6932 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 6932 8000184f READ 3 HELD suPrivilegeGroup.bdb page 6930 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 6930 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7030 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 7030 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2887 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2887 8000184f READ 6 HELD suPrivilegeGroup.bdb page 11083 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 11083 8000184f READ 1 HELD suPrivilegeGroup.bdb page 2895 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 2895 8000184f READ 3 HELD suPrivilegeGroup.bdb page 2902 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 2902 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15193 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15193 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15522 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15522 8000184f READ 15 HELD suPrivilegeGroup.bdb page 2907 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 2907 8000184f READ 3 HELD suPrivilegeGroup.bdb page 11440 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 11440 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3219 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3219 8000184f READ 6 HELD suPrivilegeGroup.bdb page 15596 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 15596 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3299 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3299 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3298 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3298 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7407 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7407 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3296 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 3296 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3311 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3311 8000184f READ 3 HELD suPrivilegeGroup.bdb page 11516 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 11516 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3271 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3271 8000184f READ 1 HELD suPrivilegeGroup.bdb page 3279 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 3279 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3274 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3274 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7377 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 7377 8000184f READ 69 HELD suPrivilegeGroup.bdb page 11298 8000184f WRITE 27 HELD suPrivilegeGroup.bdb page 11298 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7200 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7200 8000184f READ 25 HELD suPrivilegeGroup.bdb page 19475 8000184f WRITE 13 HELD suPrivilegeGroup.bdb page 19475 8000184f READ 12 HELD suPrivilegeGroup.bdb page 7180 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 7180 8000184f READ 9 HELD suPrivilegeGroup.bdb page 11280 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 11280 8000184f READ 3 HELD suPrivilegeGroup.bdb page 11366 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 11366 8000184f READ 41 HELD suPrivilegeGroup.bdb page 3175 8000184f WRITE 19 HELD suPrivilegeGroup.bdb page 3175 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3169 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3169 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7275 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7275 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15482 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15482 8000184f READ 24 HELD suPrivilegeGroup.bdb page 15481 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 15481 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15427 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15427 8000184f READ 13 HELD suPrivilegeGroup.bdb page 7262 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 7262 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7261 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7261 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7258 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7258 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7257 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 7257 8000184f READ 39 HELD suPrivilegeGroup.bdb page 15787 8000184f WRITE 15 HELD suPrivilegeGroup.bdb page 15787 8000184f READ 24 HELD suPrivilegeGroup.bdb page 3514 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 3514 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7552 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7552 8000184f READ 11 HELD suPrivilegeGroup.bdb page 3465 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 3465 8000184f READ 9 HELD suPrivilegeGroup.bdb page 15811 8000184f WRITE 7 HELD suPrivilegeGroup.bdb page 15811 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15828 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15828 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15651 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15651 8000184f READ 9 HELD suPrivilegeGroup.bdb page 19758 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 19758 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3363 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3363 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3341 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3341 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7446 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 7446 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3345 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 3345 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3357 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3357 8000184f READ 6 HELD suPrivilegeGroup.bdb page 7549 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7549 8000184f READ 1 HELD suPrivilegeGroup.bdb page 3451 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 3451 8000184f READ 16 HELD suPrivilegeGroup.bdb page 11596 8000184f WRITE 8 HELD suPrivilegeGroup.bdb page 11596 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3401 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 3401 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3400 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3400 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3756 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3756 8000184f READ 12 HELD suPrivilegeGroup.bdb page 20099 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20099 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20097 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20097 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20096 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 20096 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3714 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3714 8000184f READ 6 HELD suPrivilegeGroup.bdb page 12006 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 12006 8000184f READ 4 HELD suPrivilegeGroup.bdb page 7927 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 7927 8000184f READ 6 HELD suPrivilegeGroup.bdb page 12031 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 12031 8000184f READ 6 HELD suPrivilegeGroup.bdb page 16080 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 16080 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3807 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3807 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20014 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20014 8000184f READ 3 HELD suPrivilegeGroup.bdb page 7712 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 7712 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3633 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3633 8000184f READ 9 HELD suPrivilegeGroup.bdb page 3632 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 3632 8000184f READ 24 HELD suPrivilegeGroup.bdb page 19970 8000184f WRITE 14 HELD suPrivilegeGroup.bdb page 19970 8000184f READ 45 HELD suPrivilegeGroup.bdb page 11782 8000184f WRITE 21 HELD suPrivilegeGroup.bdb page 11782 8000184f READ 3 HELD suPrivilegeGroup.bdb page 15901 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 15901 8000184f READ 1 HELD suPrivilegeGroup.bdb page 15898 8000184f WRITE 1 HELD suPrivilegeGroup.bdb page 15898 8000184f READ 3 HELD suPrivilegeGroup.bdb page 3686 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 3686 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3694 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3694 8000184f READ 4 HELD suPrivilegeGroup.bdb page 3667 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3667 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20385 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20385 8000184f READ 3 HELD suPrivilegeGroup.bdb page 4006 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 4006 8000184f READ 42 HELD suPrivilegeGroup.bdb page 12173 8000184f WRITE 18 HELD suPrivilegeGroup.bdb page 12173 8000184f READ 15 HELD suPrivilegeGroup.bdb page 20373 8000184f WRITE 9 HELD suPrivilegeGroup.bdb page 20373 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20470 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20470 8000184f READ 27 HELD suPrivilegeGroup.bdb page 16373 8000184f WRITE 11 HELD suPrivilegeGroup.bdb page 16373 8000184f READ 51 HELD suPrivilegeGroup.bdb page 20476 8000184f WRITE 21 HELD suPrivilegeGroup.bdb page 20476 8000184f READ 12 HELD suPrivilegeGroup.bdb page 20436 8000184f WRITE 10 HELD suPrivilegeGroup.bdb page 20436 8000184f READ 9 HELD suPrivilegeGroup.bdb page 7996 8000184f WRITE 5 HELD suPrivilegeGroup.bdb page 7996 8000184f READ 6 HELD suPrivilegeGroup.bdb page 3843 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 3843 8000184f READ 6 HELD suPrivilegeGroup.bdb page 8020 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 8020 8000184f READ 6 HELD suPrivilegeGroup.bdb page 12120 8000184f WRITE 4 HELD suPrivilegeGroup.bdb page 12120 8000184f READ 6 HELD suPrivilegeGroup.bdb page 20650 8000184f WRITE 6 HELD suPrivilegeGroup.bdb page 20650 8000184f READ 3 HELD suPrivilegeGroup.bdb page 20649 8000184f WRITE 3 HELD suPrivilegeGroup.bdb page 20649 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D Memory free list 0x2b864a3cc008: 736880 --==========F223CD0B078644212341==========-- --===============2511170157240905432==-- From hyc@symas.com Tue May 13 09:48:24 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5508) slapd process consumes all of CPU Date: Tue, 13 May 2008 09:48:23 +0000 Message-ID: <200805130948.m4D9mNfg040716@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6887520848667254306==" --===============6887520848667254306== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill MacAllister wrote: > Attached is the output of db4.2_stat -CA of the database. > > Thanks for looking at this. > So far it just looks like a very busy server. Can you turn off the network=20 access to it and see if it settles down when the query traffic stops? It's a bit odd that a single transaction has so many pages of the=20 suPrivilegeGroup index locked. The backtrace is somewhat suspicious, there are several = =20 items in the trace. In thread 8, frames 5 and 6 the locker value is odd;=20 usually in BDB the locker ID associated with a transaction has bit 31 set,=20 yielding a very large 32 bit number. Also there is no locker with that ID in = the db_stat output you provided. It looks like you'll have to try this again with a non-optimized binary to ge= t=20 a reliable backtrace. > Bill > > --On Tuesday, May 13, 2008 01:20:49 AM -0700 Howard Chu > wrote: > >> whm(a)stanford.edu wrote: >>> Full_Name: Bill MacAllister >>> Version: 2.3.41-1su2 >>> OS: debian etch kernel 2.6.18-4-amd64 >>> URL: http://www.stanford.edu/~whm/ldap-test1-bt.txt >>> Submission from: (NULL) (171.64.19.165) >>> >>> >>> The slapd process will sometimes consume all of available CPU. We >>> observed this when we upgraded our production servers from 2.3.35-2su2 >>> to 2.3.41-1su2. The problem was bad enough that we downgraded the >>> production servers to 2.3.35-2su2. We have been trying to provoke the >>> problem in our test environment and have not been successful in making >>> it happen on demand. Today, we noticed that one of our test servers >>> went completely CPU bound. I took a backtrace. It is available at the >>> URL below. The interesting thing about the problem is that although top >>> shows a pinned CPU and a high load the server is still responsive and >>> continues to answer LDAP searches. The test server that exhibits the >>> problem is still CPU bound and has been for 2-3 hours now. We will >>> leave this server in this state in case there is other information that >>> we should harvest in resolving the problem. >> Please also provide the output from db_stat -CA on the database in >> question, thanks. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6887520848667254306==-- From whm@stanford.edu Tue May 13 14:25:53 2008 From: whm@stanford.edu To: openldap-bugs@openldap.org Subject: Re: (ITS#5508) slapd process consumes all of CPU Date: Tue, 13 May 2008 14:25:52 +0000 Message-ID: <200805131425.m4DEPqxd070569@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3718235174933570342==" --===============3718235174933570342== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, May 13, 2008 02:45:06 AM -0700 Howard Chu wrote: > Bill MacAllister wrote: >> Attached is the output of db4.2_stat -CA of the database. >> >> Thanks for looking at this. >> > So far it just looks like a very busy server. Can you turn off the > network access to it and see if it settles down when the query traffic > stops? Last night the server tried to do a log rotation. When I look at the log now it is zero length and nothing is getting written to it. An ldapsearch on the server just hangs. I logged into the console, shutdown the network interface down and the CPU is still pinned. > It's a bit odd that a single transaction has so many pages of the > suPrivilegeGroup index locked. > > The backtrace is somewhat suspicious, there are several out> items in the trace. In thread 8, frames 5 and 6 the locker value is > odd; usually in BDB the locker ID associated with a transaction has bit > 31 set, yielding a very large 32 bit number. Also there is no locker with > that ID in the db_stat output you provided. > > It looks like you'll have to try this again with a non-optimized binary > to get a reliable backtrace. Yes, we were afraid of that. I will build a debug version of bdb. The real rub is that we don't seem to be able to make this happen on demand. I tried taking the log from the pinned server, turned the log into a shell script of ldapsearch commands, and pointed it at another server. I could not make the second server go CPU bound. So, we will just have to deploy the debug bdb support on our test servers and wait. Bill >> Bill >> >> --On Tuesday, May 13, 2008 01:20:49 AM -0700 Howard Chu >> wrote: >> >>> whm(a)stanford.edu wrote: >>>> Full_Name: Bill MacAllister >>>> Version: 2.3.41-1su2 >>>> OS: debian etch kernel 2.6.18-4-amd64 >>>> URL: http://www.stanford.edu/~whm/ldap-test1-bt.txt >>>> Submission from: (NULL) (171.64.19.165) >>>> >>>> >>>> The slapd process will sometimes consume all of available CPU. We >>>> observed this when we upgraded our production servers from 2.3.35-2su2 >>>> to 2.3.41-1su2. The problem was bad enough that we downgraded the >>>> production servers to 2.3.35-2su2. We have been trying to provoke the >>>> problem in our test environment and have not been successful in >>>> making it happen on demand. Today, we noticed that one of our test >>>> servers went completely CPU bound. I took a backtrace. It is >>>> available at the URL below. The interesting thing about the problem >>>> is that although top shows a pinned CPU and a high load the server is >>>> still responsive and continues to answer LDAP searches. The test >>>> server that exhibits the problem is still CPU bound and has been for >>>> 2-3 hours now. We will leave this server in this state in case there >>>> is other information that we should harvest in resolving the problem. >>> Please also provide the output from db_stat -CA on the database in >>> question, thanks. -- Bill MacAllister Systems Programmer, ITS Unix Systems, Stanford University --===============3718235174933570342==-- From mark.cave-ayland@siriusit.co.uk Tue May 13 15:36:57 2008 From: mark.cave-ayland@siriusit.co.uk To: openldap-bugs@openldap.org Subject: Re: (ITS#5506) syncprov crash with RE24 CVS Date: Tue, 13 May 2008 15:36:57 +0000 Message-ID: <200805131536.m4DFavHY075774@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6954608907885020399==" --===============6954608907885020399== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howard Chu wrote: >> Details from the slapd log and the gdb core file can be found here: >> http://pastebin.siriusit.co.uk/openldap-bug-20080512.txt > > A patch is now in HEAD for this. Please test. Okay. I've arranged for a set of new packages (based upon HEAD) to be built and installed tomorrow, so will feedback on progress in a few days after the new packages have had time to settle in. Thanks once again, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 --===============6954608907885020399==-- From quanah@zimbra.com Tue May 13 19:22:44 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5465) Delta-Syncrepl cookie problems Date: Tue, 13 May 2008 19:22:44 +0000 Message-ID: <200805131922.m4DJMiKX006265@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4458111587191870792==" --===============4458111587191870792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable More data on another occurrence of this problem, this time with some packet l= evel logging. 15:56:55 is when the replica's disconnect: May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 op=3D1 MOD dn=3D"uid= =3Dxxxxx,ou=3Dpeople,dc=3Dxxx,dc=3Dxxxx,dc=3Dxxx" May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 op=3D1 MOD attr=3Dzimb= raPasswordLockoutFailureTime zimbraPasswordLockoutFailureTime May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463286 op=3D1 RESULT tag=3D10= 3 err=3D0 text=3D May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463286 op=3D2 SRCH base=3D"ui= d=3Dyyyyyy,ou=3Dpeople,dc=3Dxxx,dc=3Dxxxx,dc=3Dxxxx" scope=3D0 deref=3D3 filt= er=3D"(objectClass=3D*)" May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463286 op=3D2 SEARCH RESULT t= ag=3D101 err=3D0 nentries=3D1 text=3D May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463286 op=3D3 UNBIND May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463286 fd=3D27 closed May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 op=3D1 RESULT tag=3D10= 3 err=3D0 text=3D May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 op=3D2 SRCH base=3D"ui= d=3Dxxxxx,ou=3Dpeople,dc=3Dxxx,dc=3Dxxxx,dc=3Dxxx" scope=3D0 deref=3D3 filter= =3D"(objectClass=3D*)" May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 op=3D2 SEARCH RESULT t= ag=3D101 err=3D0 nentries=3D1 text=3D May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 op=3D3 UNBIND May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1463287 fd=3D28 closed May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1443587 op=3D3 UNBIND May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1443587 fd=3D25 closed May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1443455 op=3D3 UNBIND May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1443455 fd=3D40 closed May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1367867 op=3D3 UNBIND May 7 15:56:55 neo-ldap-1 slapd[7732]: conn=3D1367867 fd=3D24 closed 1443587, 1443455 are the connections from the two replicas. In the packet log for the replica, I see: l 0000: 30 0d 02 02 3c da 65 07 0a 01 00 04 00 04 00 0...<.e........ ldap_write: want=3D15, written=3D15 0000: 30 0d 02 02 3c da 65 07 0a 01 00 04 00 04 00 0...<.e........ ldap_read: want=3D8, got=3D0 ldap_read: want=3D8, got=3D0 ldap_read: want=3D8, got=3D8 0000: 30 7a 02 01 03 64 30 04 0z...d0. ldap_read: want=3D116, got=3D116 0000: 2c 72 65 71 53 74 61 72 74 3d 32 30 30 38 30 34 ,reqStart=3D200804 0010: 32 39 32 30 35 36 32 30 2e 30 30 30 30 30 31 5a 29205620.000001Z 0020: 2c 63 6e 3d 61 63 63 65 73 73 6c 6f 67 30 00 a0 ,cn=3Daccesslog0.. 0030: 43 30 41 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 C0A..1.3.6.1.4.1 0040: 2e 34 32 30 33 2e 31 2e 39 2e 31 2e 32 04 25 30 .4203.1.9.1.2.%0 0050: 23 0a 01 03 04 10 76 89 f9 82 aa 7a 10 2c 8e 1b #.....v....z.,.. 0060: 05 5f 81 eb fa ec 04 0c 63 73 6e 3d 2c 72 69 64 ._......csn=3D,rid 0070: 3d 31 30 30 =3D100 0000: 30 05 02 01 04 42 00 0....B. ldap_write: want=3D7, written=3D7 0000: 30 05 02 01 04 42 00 0....B. do_syncrepl: rid 100 retrying This looks to be due to expiry, as that timestamp is approximately 7 days bef= ore the current time. --Quanah --=20 Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============4458111587191870792==-- From ando@sys-net.it Wed May 14 08:33:12 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5509) slapd-meta(5) does not mention idassert Date: Wed, 14 May 2008 08:33:12 +0000 Message-ID: <200805140833.m4E8XCA7078523@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6889925179551337873==" --===============6889925179551337873== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) That feature was backported from HEAD long ago (around 2.3.33). --===============6889925179551337873==-- From Javier.Fernandez@cern.ch Wed May 14 09:56:41 2008 From: Javier.Fernandez@cern.ch To: openldap-bugs@openldap.org Subject: Re: (ITS#5504) ldapsearch hangs retrieving info Date: Wed, 14 May 2008 09:56:40 +0000 Message-ID: <200805140956.m4E9ueP5092220@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5301098111606180038==" --===============5301098111606180038== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Howard, unfortunately thereŽs no update for openladp under SL4, thatŽs why we are using such version. In fact I see no newer versions but for Fedora and Mandriva http://www.rpmfind.net/linux/rpm2html/search.php?query=openldap In fact, other sites are living nice with that version or older ones. In any case, I have compiled and built latest stable version from openldap project webpage (2.3.39) and I get the same problem. I'm not saying this is a bug from ldap, but something with local area network configuration. I'm asking for some support to debug this problem actually. Javi -- +--------------------------------------------------------------+ Javier Fernandez Menendez Grupo de Fisica de AAEE Universidad de Oviedo C/ Calvo Sotelo, s/n 33005 Oviedo Phone: +34 985106252 mailto:Javier.Fernandez(a)cern.ch +---------------------------------------------------------------+ --===============5301098111606180038==-- From h.b.furuseth@usit.uio.no Wed May 14 12:18:09 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5507) Ldap clients leak file descriptors Date: Wed, 14 May 2008 12:18:09 +0000 Message-ID: <200805141218.m4ECI9n9098765@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2419392417043439405==" --===============2419392417043439405== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I've no idea how SELinux works, so I'm not up to testing any of what I'm saying here myself, but some notes follow anyway. Please clarify: > On system protected by SELinux, when an application with active LDAP > connection tries to exec() binary with different security context, > SELinux inspects all opened filedescriptors, including the ldap one, > and denies access to the ones, which do not conform active policy (the > executed binary is not authorized to contact LDAP servers). Users are > then annoyed by security warnings in the logs. More to the point, some of those security warnings may indicate real security problems. Bind with password, exec some application, and then that application has the bound user's access to LDAP. The message could be indicating a bug in the app - that it should release its resources (such as descriptors) before exec(). Except, I presume this happens in system() as well? I'd be unfortunate if LDAP apps could not use system() safely. > +#ifdef _GNU_SOURCE > + fcntl(s, F_SETFD, FD_CLOEXEC); > +#endif _GNU_SOURCE depends on the compiler flags. Please try #ifdef FD_CLOEXEC instead. Also I expect the same should be done in os-local.c:ldap_pvt_socket(), which opens ldapi:// sockets. Can you check if the same problem occurs if you run slapd ... -h ldapi:// and a client which listens to that URL instead of ldap:// ? ldapi:// creates a unix-domain socket file somehwere, typically /usr/local/var/run/ldapi If you want to use some other filename you can use ldapi:/// e.g. ldapi://%2Fhome%2Fjsafrane%2Fldapi/ -- Hallvard --===============2419392417043439405==-- From Javier.Fernandez@cern.ch Wed May 14 15:13:54 2008 From: Javier.Fernandez@cern.ch To: openldap-bugs@openldap.org Subject: (ITS#5504) ldapsearch hangs retrieving info Date: Wed, 14 May 2008 15:13:53 +0000 Message-ID: <200805141513.m4EFDruP018227@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3200595404231914178==" --===============3200595404231914178== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Howard, unfortunately thereŽs no update for openladp under SL4, thatŽs why we are using such version. In fact I see no newer versions but for Fedora and Mandriva http://www.rpmfind.net/linux/rpm2html/search.php?query=openldap In fact, other sites are living nice with that version or older ones. In any case, I have compiled and built latest stable version from openldap project webpage (2.3.39) and I get the same problem. I'm not saying this is a bug from ldap, but something with local area network configuration. I'm asking for some support to debug this problem actually. Javi -- +--------------------------------------------------------------+ Javier Fernandez Menendez Grupo de Fisica de AAEE Universidad de Oviedo C/ Calvo Sotelo, s/n 33005 Oviedo Phone: +34 985106252 mailto:Javier.Fernandez(a)cern.ch +---------------------------------------------------------------+ --===============3200595404231914178==-- From quanah@zimbra.com Wed May 14 16:40:42 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5504) ldapsearch hangs retrieving info Date: Wed, 14 May 2008 16:40:41 +0000 Message-ID: <200805141640.m4EGefgD026210@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0445934833936874403==" --===============0445934833936874403== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Wednesday, May 14, 2008 9:56 AM +0000 Javier.Fernandez(a)cern.ch wrote: > unfortunately there?s no update for openladp under SL4, that?s why we > are using such version. In fact I see no newer versions but for Fedora > and Mandriva or > In fact, other sites are living nice with that version or older ones. > In any case, I have compiled and built latest stable version from > openldap project webpage (2.3.39) and I get the same problem. I'm not > saying this is a bug from ldap, but something with local area network > configuration. > > I'm asking for some support to debug this problem actually. If the bug is not specifically in the OpenLDAP software, I suggest you peruse: I would note I don't see anything particular in what you provide indicating the problem is with ldapsearch. What version of OpenLDAP is the server in question running (I see it is OpenLDAP by querying its rootDSE)? I'll note that a *limited* ldapsearch works just fine: [quanah(a)freelancer ~]$ ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "" -s base + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + # # dn: structuralObjectClass: OpenLDAProotDSE namingContexts: o=grid supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [quanah(a)freelancer ~]$ I would also note that for me, doing a dump of the entire server works just fine: ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "o=grid" results in: # search result search: 2 result: 0 Success # numResponses: 43962 # numEntries: 43961 Adding -d -1 to the query, I eventually see the same thing you do: ber_get_next failed. wait4msg continue ld 0x233f0e0 msgid -1 all 0 ** ld 0x233f0e0 Connections: * host: exp-bdii.cern.ch port: 2170 (default) refcnt: 2 status: Connected last used: Wed May 14 09:34:06 2008 ** ld 0x233f0e0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x233f0e0 Response Queue: Empty ldap_chkResponseList ld 0x233f0e0 msgid -1 all 0 ldap_chkResponseList returns ld 0x233f0e0 NULL ldap_int_select read1msg: ld 0x233f0e0 msgid -1 all 0 ber_get_next ldap_read: want=1142, got=0 ber_get_next failed. ldap_perror ldap_result: Can't contact LDAP server (-1) ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind ber_flush: 7 bytes to sd 3 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============0445934833936874403==-- From aej@wpi.edu Wed May 14 17:41:17 2008 From: aej@wpi.edu To: openldap-bugs@openldap.org Subject: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 17:41:16 +0000 Message-ID: <200805141741.m4EHfGc8030004@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7333255322837886934==" --===============7333255322837886934== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Allan E. Johannesen Version: 2.4.9 OS: RHEL4 i686 URL:=20 Submission from: (NULL) (130.215.24.208) slapd appeared to exit after this: May 14 13:05:42 ALUM slapd[28252]: SASL [conn=3D1] Failure: GSSAPI Error: The context has expired (No error) May 14 13:05:42 ALUM slapd[28252]: send_search_entry: conn 1 ber write faile= d. Is termination expected or should I look for something else? Thanks. If you want me to post anything about the environment, please let me know. --===============7333255322837886934==-- From quanah@zimbra.com Wed May 14 18:25:49 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 18:25:48 +0000 Message-ID: <200805141825.m4EIPmf9032253@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1098377496314089179==" --===============1098377496314089179== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Wednesday, May 14, 2008 5:41 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.4.9 > OS: RHEL4 i686 > URL: > Submission from: (NULL) (130.215.24.208) > > > slapd appeared to exit after this: > > May 14 13:05:42 ALUM slapd[28252]: SASL [conn=1] Failure: GSSAPI Error: > The context has expired (No error) > May 14 13:05:42 ALUM slapd[28252]: send_search_entry: conn 1 ber write > failed. > > Is termination expected or should I look for something else? > > Thanks. > > If you want me to post anything about the environment, please let me know. Make sure you have debugging symbols enabled, gdb slapd, repeat, send in the backtrace. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============1098377496314089179==-- From quanah@zimbra.com Wed May 14 19:17:00 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 19:16:59 +0000 Message-ID: <200805141917.m4EJGxuH034982@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3350703181824576812==" --===============3350703181824576812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Send all response to the ITS, rather than me. If you want them investigated, anyhow. --Quanah --On Wednesday, May 14, 2008 3:14 PM -0400 "Allan E. Johannesen" wrote: >>>>>> "quanah" == Quanah Gibson-Mount writes: > > quanah> --On Wednesday, May 14, 2008 5:41 PM +0000 aej(a)wpi.edu wrote: >>> Full_Name: Allan E. Johannesen Version: 2.4.9 OS: RHEL4 i686 URL: >>> Submission from: (NULL) (130.215.24.208) >>> >>> >>> slapd appeared to exit after this: >>> >>> May 14 13:05:42 ALUM slapd[28252]: SASL [conn=1] Failure: GSSAPI Error: >>> The context has expired (No error) May 14 13:05:42 ALUM slapd[28252]: >>> send_search_entry: conn 1 ber write failed. >>> >>> Is termination expected or should I look for something else? >>> >>> Thanks. >>> >>> If you want me to post anything about the environment, please let me >>> know. > > quanah> Make sure you have debugging symbols enabled, gdb slapd, repeat, > send quanah> in the backtrace. > > (gdb) r -d32768 -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf > Starting program: > /tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd/slapd -d32768 > -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf [Thread debugging using > libthread_db enabled] > [New Thread -1209116992 (LWP 19050)] > @(#) $OpenLDAP: slapd 2.4.9 (May 9 2008 08:02:12) $ > aej(a)CCC1.WPI.EDU:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/s > lapd [New Thread -1728967776 (LWP 19053)] > [Thread -1728967776 (LWP 19053) exited] > [New Thread -1728967776 (LWP 19054)] > [Thread -1728967776 (LWP 19054) exited] > slapd starting > [New Thread -1728967776 (LWP 19055)] > [New Thread 2035399584 (LWP 19056)] > [New Thread 2031201184 (LWP 19057)] > [New Thread 2027002784 (LWP 19058)] > SASL [conn=1] Error: unable to open Berkeley db /etc/sasldb2: No such > file or directory SASL [conn=1] Error: unable to open Berkeley db > /etc/sasldb2: No such file or directory SASL [conn=33] Error: unable to > open Berkeley db /etc/sasldb2: No such file or directory SASL [conn=33] > Error: unable to open Berkeley db /etc/sasldb2: No such file or directory > [New Thread 1994468256 (LWP 19109)] > [New Thread 1980824480 (LWP 19168)] > [New Thread 1967180704 (LWP 19169)] > [New Thread 1962982304 (LWP 19170)] > connection_read(20): no connection! > > connection_read(20): no connection! > SASL [conn=33] Failure: GSSAPI Error: The context has expired (No error) > sb_sasl_write: failed to encode packet: generic failure > send_search_entry: conn 33 ber write failed. > slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 2027002784 (LWP 19058)] > 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > (gdb) (gdb) where ># 0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 ># 1 0x00ad8815 in raise () from /lib/tls/libc.so.6 ># 2 0x00ada279 in abort () from /lib/tls/libc.so.6 ># 3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 ># 4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x4a72) ># at rq.c:92 5 0x080ffd9f in syncprov_free_syncop (so=0x83fe198) at ># syncprov.c:744 6 0x0810011d in syncprov_qtask (ctx=0x78d19210, ># arg=0x84aa898) at syncprov.c:949 7 0x08113cfd in ># ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:663 8 ># 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 ># 9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 > (gdb) quit > The program is running. Exit anyway? (y or n) y > ALUM:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd$ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3350703181824576812==-- From quanah@zimbra.com Wed May 14 19:18:44 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5503) Openldap segmentation fault when running syncrepl. Date: Wed, 14 May 2008 19:18:44 +0000 Message-ID: <200805141918.m4EJIiMN035658@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4068005515419407940==" --===============4068005515419407940== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Saturday, May 10, 2008 4:28 PM +0000 hyc(a)symas.com wrote: > 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. Chuck, Please provide feedback. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============4068005515419407940==-- From quanah@zimbra.com Wed May 14 19:33:59 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 19:33:59 +0000 Message-ID: <200805141933.m4EJXxYY036795@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2834206925526153806==" --===============2834206925526153806== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Wednesday, May 14, 2008 7:16 PM +0000 quanah(a)zimbra.com wrote: >> Program received signal SIGABRT, Aborted. >> [Switching to Thread 2027002784 (LWP 19058)] >> 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 >> (gdb) (gdb) where >># 0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 >># 1 0x00ad8815 in raise () from /lib/tls/libc.so.6 >># 2 0x00ada279 in abort () from /lib/tls/libc.so.6 >># 3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 >># 4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x4a72) >># at rq.c:92 5 0x080ffd9f in syncprov_free_syncop (so=0x83fe198) at >># syncprov.c:744 6 0x0810011d in syncprov_qtask (ctx=0x78d19210, >># arg=0x84aa898) at syncprov.c:949 7 0x08113cfd in >># ldap_int_thread_pool_wrapper (xpool=0x82e6ab0) at tpool.c:663 8 >># 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 >># 9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 >> (gdb) quit >> The program is running. Exit anyway? (y or n) y >> ALUM:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd$ frame 4 print e Also, please provide the full backtrace (thread apply all bt) What type of search is being done here? A search from an ldapclient or a replica? What Kerberos implementation are you using (I'm guessing MIT)? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2834206925526153806==-- From aej@WPI.EDU Wed May 14 19:51:10 2008 From: aej@WPI.EDU To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 19:51:10 +0000 Message-ID: <200805141951.m4EJpA8u038027@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7356245976872177878==" --===============7356245976872177878== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>>>> "quanah" =3D=3D Quanah Gibson-Mount writes: quanah> What type of search is being done here? A search from an ldapclient = or quanah> a replica? What Kerberos implementation are you using (I'm guessing quanah> MIT)? Replica. Yes, MIT. --===============7356245976872177878==-- From aej@WPI.EDU Wed May 14 20:03:04 2008 From: aej@WPI.EDU To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 20:03:04 +0000 Message-ID: <200805142003.m4EK3458039095@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2006035798636960050==" --===============2006035798636960050== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>>>> "quanah" =3D=3D Quanah Gibson-Mount writes: ALUM:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd$ gdb slapd GNU gdb Red Hat Linux (6.3.0.0-1.153.el4_6.2rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db = library "/lib/tls/libthread_db.so.1". (gdb) r -d32768 -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf Starting program: /tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/slapd= /slapd -d32768 -h ldap:/// ldaps:/// -f /var/openldap/slapd.conf [Thread debugging using libthread_db enabled] [New Thread -1209116992 (LWP 21561)] @(#) $OpenLDAP: slapd 2.4.9 (May 9 2008 08:02:12) $ aej(a)CCC1.WPI.EDU:/tools/src/openldap/RHEL4-i686/openldap-2.4.9/servers/sla= pd [New Thread -1728967776 (LWP 21564)] [Thread -1728967776 (LWP 21564) exited] [New Thread -1728967776 (LWP 21565)] [Thread -1728967776 (LWP 21565) exited] slapd starting [New Thread -1728967776 (LWP 21566)] [New Thread 2035399584 (LWP 21567)] [New Thread 2031201184 (LWP 21568)] [New Thread 2027002784 (LWP 21569)] SASL [conn=3D11] Error: unable to open Berkeley db /etc/sasldb2: No such file= or directory SASL [conn=3D11] Error: unable to open Berkeley db /etc/sasldb2: No such file= or directory [New Thread 1994468256 (LWP 21585)] [New Thread 1989217184 (LWP 21586)] [New Thread 1983966112 (LWP 21587)] [New Thread 1953536928 (LWP 21588)] [New Thread 1938815904 (LWP 21859)] SASL [conn=3D11] Failure: GSSAPI Error: The context has expired (No error) sb_sasl_write: failed to encode packet: generic failure send_search_entry: conn 11 ber write failed. slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e =3D=3D entry' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 2035399584 (LWP 21567)] 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 #2 0x00ada279 in abort () from /lib/tls/libc.so.6 #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x543f) a= t rq.c:92 #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403248) at syncprov.c:744 #6 0x0810011d in syncprov_qtask (ctx=3D0x7951b210, arg=3D0x847e618) at syncp= rov.c:949 #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :663 #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 quanah> frame 4 print e (gdb) frame 4 #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x543f) a= t rq.c:92 92 assert( e =3D=3D entry ); (gdb) print e $2 =3D (struct re_s *) 0x0 (gdb) print entry $3 =3D (struct re_s *) 0x543f quanah> Also, please provide the full backtrace (thread apply all bt) (gdb) thread apply all bt Thread 12 (Thread 1938815904 (LWP 21859)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.= so.0 #2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :654 #3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 11 (Thread 1953536928 (LWP 21588)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00b7b0a8 in send () from /lib/tls/libc.so.6 #2 0x00b76446 in vsyslog () from /lib/tls/libc.so.6 #3 0x00b7668f in syslog () from /lib/tls/libc.so.6 #4 0x0806365e in do_search (op=3D0x843e5b8, rs=3D0x74709120) at search.c:186 #5 0x08061a5c in connection_operation (ctx=3D0x74709210, arg_v=3D0x843e5b8) = at connection.c:1084 #6 0x080620fd in connection_read_thread (ctx=3D0x74709210, argv=3D0x1c) at c= onnection.c:1211 #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :663 #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 10 (Thread 1983966112 (LWP 21587)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.= so.0 #2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :654 #3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 9 (Thread 1989217184 (LWP 21586)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.= so.0 #2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :654 #3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 8 (Thread 1994468256 (LWP 21585)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.= so.0 #2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :654 #3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 7 (Thread 2027002784 (LWP 21569)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00b72f12 in fdatasync () from /lib/tls/libc.so.6 #2 0xb7fc65e2 in __os_fsync () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5.= so #3 0xb7fc3adc in __memp_sync_file () from /usr/local/BerkeleyDB.4.5/lib/libd= b-4.5.so #4 0xb7fc27cf in __memp_walk_files () from /usr/local/BerkeleyDB.4.5/lib/lib= db-4.5.so #5 0xb7fc3108 in __memp_sync_int () from /usr/local/BerkeleyDB.4.5/lib/libdb= -4.5.so #6 0xb7fc3609 in __memp_sync () from /usr/local/BerkeleyDB.4.5/lib/libdb-4.5= .so #7 0xb7fd176f in __txn_checkpoint () from /usr/local/BerkeleyDB.4.5/lib/libd= b-4.5.so #8 0xb7fd1943 in __txn_checkpoint_pp () from /usr/local/BerkeleyDB.4.5/lib/l= ibdb-4.5.so #9 0x080dbf0b in bdb_add (op=3D0x78d176c0, rs=3D0x78d17680) at add.c:484 #10 0x080b6061 in overlay_op_walk (op=3D0x78d176c0, rs=3D0x78d17680, which=3D= op_add, oi=3D0x83298a8, on=3D0x83299a8) at backover.c:646 #11 0x080b6152 in over_op_func (op=3D0x78d176c0, rs=3D0x78d17680, which=3Dop_= add) at backover.c:698 #12 0x080fcdb6 in accesslog_response (op=3D0x83fc0a8, rs=3D0x78d19120) at acc= esslog.c:1650 #13 0x080b5863 in over_back_response (op=3D0x83fc0a8, rs=3D0x78d19120) at bac= kover.c:235 #14 0x0806e95b in slap_response_play (op=3D0x83fc0a8, rs=3D0x78d19120) at res= ult.c:307 #15 0x0806ea9b in send_ldap_response (op=3D0x83fc0a8, rs=3D0x78d19120) at res= ult.c:381 #16 0x0806f11e in slap_send_ldap_result (op=3D0x83fc0a8, rs=3D0x78d19120) at = result.c:642 #17 0x080bef75 in bdb_modify (op=3D0x83fc0a8, rs=3D0x78d19120) at modify.c:697 #18 0x080b6061 in overlay_op_walk (op=3D0x83fc0a8, rs=3D0x78d19120, which=3Do= p_modify, oi=3D0x832a240, on=3D0x8331910) at backover.c:646 #19 0x080b6152 in over_op_func (op=3D0x83fc0a8, rs=3D0x78d19120, which=3Dop_m= odify) at backover.c:698 #20 0x08074b4a in fe_op_modify (op=3D0x83fc0a8, rs=3D0x78d19120) at modify.c:= 300 #21 0x080764de in do_modify (op=3D0x83fc0a8, rs=3D0x78d19120) at modify.c:175 #22 0x08061a5c in connection_operation (ctx=3D0x78d19210, arg_v=3D0x83fc0a8) = at connection.c:1084 #23 0x080620fd in connection_read_thread (ctx=3D0x78d19210, argv=3D0x22) at c= onnection.c:1211 #24 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :663 #25 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #26 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 6 (Thread 2031201184 (LWP 21568)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00d14cf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.= so.0 #2 0x08113d54 in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :654 #3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 5 (Thread 2035399584 (LWP 21567)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 #2 0x00ada279 in abort () from /lib/tls/libc.so.6 #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x543f) a= t rq.c:92 #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403248) at syncprov.c:744 #6 0x0810011d in syncprov_qtask (ctx=3D0x7951b210, arg=3D0x847e618) at syncp= rov.c:949 #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool.c= :663 #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 4 (Thread -1728967776 (LWP 21566)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00b7a82e in epoll_wait () from /lib/tls/libc.so.6 #2 0x0805e753 in slapd_daemon_task (ptr=3D0x0) at daemon.c:2281 #3 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Thread 1 (Thread -1209116992 (LWP 21561)): #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00d13297 in pthread_join () from /lib/tls/libpthread.so.0 #2 0x0805f5b9 in slapd_daemon () at daemon.c:2644 #3 0x0804cd40 in main (argc=3D7, argv=3D0xbffff884) at main.c:946 --===============2006035798636960050==-- From rein@OpenLDAP.org Wed May 14 20:27:25 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 20:27:25 +0000 Message-ID: <200805142027.m4EKRP9s042145@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8198494498543986147==" --===============8198494498543986147== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 14 May 2008, aej(a)WPI.EDU wrote: > (gdb) frame 4 > #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x543f)= at rq.c:92 > 92 assert( e =3D=3D entry ); > (gdb) print e > $2 =3D (struct re_s *) 0x0 > (gdb) print entry > $3 =3D (struct re_s *) 0x543f > Thread 5 (Thread 2035399584 (LWP 21567)): > #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 > #2 0x00ada279 in abort () from /lib/tls/libc.so.6 > #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x543f)= at rq.c:92 > #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403248) at syncprov.c:744 > #6 0x0810011d in syncprov_qtask (ctx=3D0x7951b210, arg=3D0x847e618) at syn= cprov.c:949 > #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6ab0) at tpool= .c:663 > #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 > #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 Could you also "print *so" from frame 5, the entry from frame 4 looks=20 corrupt. Rein --===============8198494498543986147==-- From aej@WPI.EDU Wed May 14 22:09:23 2008 From: aej@WPI.EDU To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Wed, 14 May 2008 22:09:22 +0000 Message-ID: <200805142209.m4EM9Mi7047943@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5093073329327521184==" --===============5093073329327521184== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>>>> "rein" =3D=3D Rein Tollevik writes: rein> Could you also "print *so" from frame 5, the entry from frame 4 looks rein> corrupt. connection_read(33): no connection! SASL [conn=3D27] Failure: GSSAPI Error: The context has expired (No error) sb_sasl_write: failed to encode packet: generic failure send_search_entry: conn 27 ber write failed. slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e =3D=3D entry' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1986071456 (LWP 27434)] 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 #2 0x00ada279 in abort () from /lib/tls/libc.so.6 #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x6b2a) a= t rq.c:92 #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403c88) at syncprov.c:744 #6 0x0810011d in syncprov_qtask (ctx=3D0x76610210, arg=3D0x845e880) at syncp= rov.c:949 #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6c78) at tpool.c= :663 #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 (gdb) frame 5 #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403c88) at syncprov.c:744 744 ldap_pvt_runqueue_remove( &slapd_rq, so->s_qtask ); (gdb) print so $1 =3D (syncops *) 0x8403c88 (gdb) print *so $2 =3D {s_next =3D 0x0, s_base =3D {bv_len =3D 6, bv_val =3D 0x83f9b50 "cn=3D= log"}, s_eid =3D 1, s_op =3D 0x83fe748, s_rid =3D 1, s_sid =3D -1,=20 s_filterstr =3D {bv_len =3D 46, bv_val =3D 0x7881811c "0\001.\b\022"}, s_fl= ags =3D 2, s_inuse =3D 0, s_res =3D 0x0, s_restail =3D 0x0,=20 s_qtask =3D 0x845e880, s_mutex =3D {__m_reserved =3D 1, __m_count =3D 0, __= m_owner =3D 0x6b2a, __m_kind =3D 0, __m_lock =3D {__status =3D 1,=20 __spinlock =3D 0}}} --===============5093073329327521184==-- From dwhite@olp.net Wed May 14 22:19:17 2008 From: dwhite@olp.net To: openldap-bugs@openldap.org Subject: (ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0 Date: Wed, 14 May 2008 22:19:16 +0000 Message-ID: <200805142219.m4EMJGCh049131@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3865630432961211520==" --===============3865630432961211520== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Dan White Version: 2.4.9 OS: Debian Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2610:b8:1:0:21a:70ff:fe8f:e0b3) I'm experiencing SIGABRT crashes when the slapo-unique overlay is enabled, an= d I attempt to set one of the unique attributes to '0'. A configuration snippet: ... modulepath /usr/lib/ldap moduleload back_bdb moduleload smbk5pwd moduleload unique ... overlay unique #unique_base ou=3DPeople,dc=3Dolp,dc=3Dnet unique_attributes uidNumber btcAltUID I'm triggering the crash while modifying the uidNumber attribute with the ldapmodify command: hiro:/var/lib/ldap# ldapsearch -LLL uid=3Ddwhite(a)olp.net uidNumber dn: uid=3Ddwhite(a)olp.net,ou=3Dpeople,dc=3Dolp,dc=3Dnet uidNumber: 497913425 hiro:/var/lib/ldap# ldapmodify=20 dn: uid=3Ddwhite(a)olp.net,ou=3Dpeople,dc=3Dolp,dc=3Dnet changeType: modify replace: uidNumber uidNumber: 0 modifying entry "uid=3Ddwhite(a)olp.net,ou=3Dpeople,dc=3Dolp,dc=3Dnet" ldap_result: Can't contact LDAP server (-1) If I comment out all the unique overlay related configuration items and resta= rt slapd, and rerun my ldapmodify command, the process completes normally. Details from the coredump: ... Core was generated by `/usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -g root -u root -f /etc/ldap/sl'. Program terminated with signal 6, Aborted. #0 0xb7eee410 in ?? () (gdb) thread apply all bt Thread 3 (process 9354): #0 0xb7eee410 in ?? () #1 0xbfdb51a8 in ?? () #2 0x0000248b in ?? () #3 0x00000000 in ?? () Thread 2 (process 9355): #0 0xb7eee410 in ?? () #1 0xb717a458 in ?? () #2 0x00000400 in ?? () #3 0x081c4148 in ?? () #4 0xb7bf2b0e in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #5 0x08075ca9 in slapd_daemon_task (ptr=3D0x0) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/daemon.c:2281 #6 0xb7c5d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7bf249e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 9359): #0 0xb7eee410 in ?? () #1 0xb6d77a38 in ?? () #2 0x00000006 in ?? () #3 0x0000248f in ?? () #4 0xb7b4f811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7b50fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0xb7b48fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7579032 in build_filter (domain=3D0x822f130, uri=3D0x822b748, ad=3D0x8= 1e20b0, b=3D0x82bd980, kp=3D0xb6878266 "(uidNumber=3D0", ks=3D13, ctx=3D0x82bdab8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/overlays/uniqu= e.c:931 #8 0xb7579d89 in unique_modify (op=3D0x82bd6f8, rs=3D0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/overlays/unique.c:1185 #9 0x080f1c69 in overlay_op_walk (op=3D0x82bd6f8, rs=3D0xb6d791c8, which=3Do= p_modify, oi=3D0x822cbc8, on=3D0x822f148) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:636 #10 0x080f1ea0 in over_op_func (op=3D0x82bd6f8, rs=3D0xb6d791c8, which=3Dop_m= odify) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:698 #11 0x080f1f68 in over_op_modify (op=3D0x82bd6f8, rs=3D0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:732 #12 0x08096290 in fe_op_modify (op=3D0x82bd6f8, rs=3D0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/modify.c:300 #13 0x08095cd4 in do_modify (op=3D0x82bd6f8, rs=3D0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/modify.c:175 #14 0x080795c2 in connection_operation (ctx=3D0xb6d792ac, arg_v=3D0x82bd6f8) = at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/connection.c:1084 #15 0x08079aaf in connection_read_thread (ctx=3D0xb6d792ac, argv=3D0x12) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/connection.c:1211 #16 0xb7ea812e in ldap_int_thread_pool_wrapper (xpool=3D0x81e38d0) at /usr/src/build/slapd.noopt/openldap-2.4.9/libraries/libldap_r/tpool.c:663 #17 0xb7c5d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb7bf249e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) quit --===============3865630432961211520==-- From jclarke@linagora.com Wed May 14 23:38:43 2008 From: jclarke@linagora.com To: openldap-bugs@openldap.org Subject: (ITS#5512) Doc contribution for search privileges in 2.4 Date: Wed, 14 May 2008 23:38:43 +0000 Message-ID: <200805142338.m4ENchS2052659@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3984304794879616532==" --===============3984304794879616532== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Jonathan Clarke Version: 2.4 OS:=20 URL:=20 Submission from: (NULL) (88.167.76.100) Hello, ITS #5400 outlines a change in the privileges required by search operations in 2.4. I would like to suggest documentation for this in the admin guide (the slapd.access man page is already accurate). Please find propositions here: 1) http://www.phillipoux.net/jonathan-clarke-20080515-upgrading.patch Explanation and example in the "Upgrading from 2.3" appendix. 2) http://www.phillipoux.net/jonathan-clarke-20080515-access-control.patch Detail of the required privileges on the "entry" pseudo-attribute in the acce= ss control section (static and dynamic config - same text is repeated twice). As a side note, I encountered a "452 Error writing file: No space left on device." error on ftp.openldap.org/incoming while trying to upload these patches. Regards, Jonathan --===============3984304794879616532==-- From mbackes@symas.com Thu May 15 03:20:59 2008 From: mbackes@symas.com To: openldap-bugs@openldap.org Subject: (ITS#5513) back-ldap+ppolicy bind assertion failure Date: Thu, 15 May 2008 03:20:58 +0000 Message-ID: <200805150320.m4F3KwM8060086@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1255685559572416567==" --===============1255685559572416567== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Matthew Backes Version: 2.3, 2.4 OS: linux URL:=20 Submission from: (NULL) (76.88.99.93) A basic back-ldap configuration with the password policy overlay stacked on t= op results in an assertfail for the second bind. e.g. given a working (possibly empty db) on ldap://localhost:1389/... include ...../core.schema include ...../ppolicy.schema modulepath ..... moduleload back_ldap.la moduleload ppolicy.la database ldap suffix "" uri ldap://localhost:1389/ After performing a successful remote bind, the next bind attempt halts the back-ldap directory with: slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags & (0x02U) )' failed. where 0x02U here is LDAP_BACK_AUTH_OVERRIDE. This happens under both OpenLDAP 2.3 and 2.4. --===============1255685559572416567==-- From sushmita_mishra@infosys.com Thu May 15 05:29:14 2008 From: sushmita_mishra@infosys.com To: openldap-bugs@openldap.org Subject: (ITS#5514) Query about openLDAP on windows Date: Thu, 15 May 2008 05:29:13 +0000 Message-ID: <200805150529.m4F5TD8l067301@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6182609425751660427==" --===============6182609425751660427== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Sushmita Mishra Version: 2.3.41 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.64.6) Hi, I want to use openLDAP for authentication, for this purpose I have gone through the documents available at . In all th= ese documents, I found the installation for openLDAP directory server is given for LINUX or UNIX only and not for Windows. My query is Can we install openLDAP directory server on windows machine? If y= es can you please send me the steps for installing/configuring openLDAP directory server on windows machine? Thanks, Sushmita Mishra --===============6182609425751660427==-- From ghenry@suretecsystems.com Thu May 15 07:54:47 2008 From: ghenry@suretecsystems.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5512) Doc contribution for search privileges in 2.4 Date: Thu, 15 May 2008 07:54:47 +0000 Message-ID: <200805150754.m4F7slhw071892@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0227860379237331057==" --===============0227860379237331057== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Hello, > > ITS #5400 outlines a change in the privileges required by search > operations in > 2.4. I would like to suggest documentation for this in the admin guide > (the > slapd.access man page is already accurate). > > Please find propositions here: > 1) http://www.phillipoux.net/jonathan-clarke-20080515-upgrading.patch > Explanation and example in the "Upgrading from 2.3" appendix. > > 2) http://www.phillipoux.net/jonathan-clarke-20080515-access-control.patch > Detail of the required privileges on the "entry" pseudo-attribute in the > access > control section (static and dynamic config - same text is repeated twice). > > > As a side note, I encountered a "452 Error writing file: No space left on > device." error on ftp.openldap.org/incoming while trying to upload these > patches. > Thanks for this. I was hoping to do this tomorrow as I've been so busy this week, but now I don't need to! Will patch, review and provide feedback as soon as I can. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. --===============0227860379237331057==-- From Javier.Fernandez@cern.ch Thu May 15 09:13:46 2008 From: Javier.Fernandez@cern.ch To: openldap-bugs@openldap.org Subject: Re: (ITS#5504) ldapsearch hangs retrieving info Date: Thu, 15 May 2008 09:13:45 +0000 Message-ID: <200805150913.m4F9Djb7077141@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8420616161992475620==" --===============8420616161992475620== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thanks Quanah for your time. I have some answers/comments inline: Quanah Gibson-Mount escribió: > --On Wednesday, May 14, 2008 9:56 AM +0000 Javier.Fernandez(a)cern.ch > wrote: > >> unfortunately there?s no update for openladp under SL4, that?s why we >> are using such version. In fact I see no newer versions but for Fedora >> and Mandriva > > or > I have tried installing last 2.4 version for RH but I get the same result, since problem is not related to ldap version I'm afraid >> In fact, other sites are living nice with that version or older ones. >> In any case, I have compiled and built latest stable version from >> openldap project webpage (2.3.39) and I get the same problem. I'm not >> saying this is a bug from ldap, but something with local area network >> configuration. >> >> I'm asking for some support to debug this problem actually. > If the bug is not specifically in the OpenLDAP software, I suggest you > peruse: > > Well, this is the first thing I tried, but I got no solutions browsing through the pages and therefore I tried this mailing list referenced from that link. > I would note I don't see anything particular in what you provide > indicating the problem is with ldapsearch. What version of OpenLDAP > is the server in question running (I see it is OpenLDAP by querying > its rootDSE)? > > I'll note that a *limited* ldapsearch works just fine: > > [quanah(a)freelancer ~]$ ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 > -b "" -s base + > # extended LDIF > # > # LDAPv3 snip > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 That works fine for me. > I would also note that for me, doing a dump of the entire server works > just fine: > > ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "o=grid" > > results in: > > # search result > search: 2 > result: 0 Success > > # numResponses: 43962 > # numEntries: 43961 I do not reach that point, in fact that is the problem: command gets stuck retrieving one of the entries, in particular today it hangs at: GlueCEAccessControlBaseRule: VO:ops GlueForeignKey: GlueClusterUniqueID=ce104.cern.ch GlueInformationServiceURL: ldap://ce104.cern.ch:2170/mds-vo-name=resource,o=gr id GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3 and after a long long time, the output gives/jumps to another entry... and it continues dripping entries from time to time for an indefinite period until the command gives timeout. A ping to exp-bdii.cern.ch gives an average delay of 40ms which I consider normal. From any other sites (e.g. any machine from CERN) the command works fine in any openldap version, although I do not see any summary at the end with such big number of entries and results as you do. > > Adding -d -1 to the query, I eventually see the same thing you do: > I just added it to perform some debugging but I do not know how to interpret the results. Once more: any hint on how to trace back this problem would be really apreciated. Thank you very much. -- +--------------------------------------------------------------+ Javier Fernandez Menendez Grupo de Fisica de AAEE Universidad de Oviedo C/ Calvo Sotelo, s/n 33005 Oviedo Phone: +34 985106252 mailto:Javier.Fernandez(a)cern.ch +---------------------------------------------------------------+ --===============8420616161992475620==-- From jsafrane@redhat.com Thu May 15 13:38:46 2008 From: jsafrane@redhat.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5507) Ldap clients leak file descriptors Date: Thu, 15 May 2008 13:38:46 +0000 Message-ID: <200805151338.m4FDckYl088970@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6387167098256537356==" --===============6387167098256537356== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > I've no idea how SELinux works, so I'm not up to testing any of what > I'm saying here myself, but some notes follow anyway. Please clarify: > >> On system protected by SELinux, when an application with active LDAP >> connection tries to exec() binary with different security context, >> SELinux inspects all opened filedescriptors, including the ldap one, >> and denies access to the ones, which do not conform active policy (the >> executed binary is not authorized to contact LDAP servers). Users are >> then annoyed by security warnings in the logs. > > More to the point, some of those security warnings may indicate real > security problems. Bind with password, exec some application, and then > that application has the bound user's access to LDAP. That's exactly the case SELinux is trying to prevent. > The message could be indicating a bug in the app - that it should > release its resources (such as descriptors) before exec(). > Except, I presume this happens in system() as well? > I'd be unfortunate if LDAP apps could not use system() safely. I assume system() calls fork() and exec() internally, so yes, it's protected as well. SELinux can be extensively configured and if an admin thinks that executed application can safely use inherited ldap connection, he/she can allow it. But this is nearly impossible, because LDAP can be integrated into pam (via nss_ldap). If pam uses nss_ldap, then really lot of applications use ldap client indirectly. And nss_ldap can be configured to keep the connection open for certain time so it's reused, and the applications don't know, if the pam with nss_ldap has opened ldap connection and they can't close it. >> +#ifdef _GNU_SOURCE >> + fcntl(s, F_SETFD, FD_CLOEXEC); >> +#endif > > _GNU_SOURCE depends on the compiler flags. Please try > #ifdef FD_CLOEXEC > instead. Agreed.. > Also I expect the same should be done in os-local.c:ldap_pvt_socket(), Yes, it should. Again, please use fcntl(s, F_SETFD, FD_CLOEXEC); Jan --===============6387167098256537356==-- From stelios.xx.grigoriadis@ericsson.com Thu May 15 14:03:13 2008 From: stelios.xx.grigoriadis@ericsson.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection Date: Thu, 15 May 2008 14:03:12 +0000 Message-ID: <200805151403.m4FE3C55092901@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8512238855841082307==" --===============8512238855841082307== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit We have created a patch that works for us. An updated version is available for 2.4.9 The patch is using the parameter "mastercheckint" in slapd.conf, if present. A separate thread then continously askes the master for the root DSE. An excerpt from the slapd.conf file: # from master ldapt1.roadrunner syncrepl rid=102 provider=ldap://ldapt1.roadrunner type=refreshAndPersist retry="10 10 60 +" searchbase="dc=example,dc=com" filter="(objectClass=*)" scope=sub schemachecking=off sizelimit=500000 timelimit=360000 bindmethod=simple mastercheckint=5 ### THIS is the new parameter. binddn="cn=admin,dc=example,dc=com" credentials=secret updateref ldap://ldapt1.roadrunner overlay syncprov If the master unexpectedly terminates (eg. due to a power failure) the replicas will get a new connection once it's up again. The patch is available at: http://www.freewebs.com/stigri/Stelios-Grigoriadis-its5133-080514.patch It must be run while in openlda-2.4.9 directory. /Stelios Grigoriadis --===============8512238855841082307==-- From h.b.furuseth@usit.uio.no Thu May 15 14:20:30 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0 Date: Thu, 15 May 2008 14:20:29 +0000 Message-ID: <200805151420.m4FEKTIw096697@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4803371233083796825==" --===============4803371233083796825== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Confirmed in HEAD. Unique makes too small buffer for filter "(uidNumber=0)", so build_filter() line 931: assert( len >= 0 && len < ks ); fails because len == ks == 13 == strlen(filter). slapd.conf: include ...core.schema include ...cosine.schema include ...nis.schema database bdb directory /tmp/db suffix uid=dwhite rootdn uid=dwhite rootpw secret overlay unique unique_attributes uidNumber 'ldapadd'ed ldif: dn: uid=dwhite objectClass: account objectClass: posixAccount uid: dwhite uidNumber: 0 cn: Dan White gidNumber: 1 homeDirectory: /home/dwhite -- Hallvard --===============4803371233083796825==-- From ando@sys-net.it Thu May 15 14:53:45 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5514) Query about openLDAP on windows Date: Thu, 15 May 2008 14:53:44 +0000 Message-ID: <200805151453.m4FErikq003948@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6746279616772291137==" --===============6746279616772291137== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sushmita_mishra(a)infosys.com wrote: > I want to use openLDAP for authentication, for this purpose I have gone > through the documents available at . In all = these > documents, I found the installation for openLDAP directory server is given = for > LINUX or UNIX only and not for Windows. >=20 > My query is Can we install openLDAP directory server on windows machine? If= yes > can you please send me the steps for installing/configuring openLDAP direct= ory > server on windows machine? Please direct OpenLDAP software usage questions to the openldap-software=20 mailing lists; the ITS is to track bugs and issues. This ITS will be=20 closed. 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 --------------------------------------- --===============6746279616772291137==-- From hyc@symas.com Fri May 16 04:35:47 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Fri, 16 May 2008 04:35:46 +0000 Message-ID: <200805160435.m4G4ZkXx040480@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1763727054201727114==" --===============1763727054201727114== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable aej(a)WPI.EDU wrote: >>>>>> "rein" =3D=3D Rein Tollevik writes: > > rein> Could you also "print *so" from frame 5, the entry from frame 4 looks > rein> corrupt. > > connection_read(33): no connection! > SASL [conn=3D27] Failure: GSSAPI Error: The context has expired (No error) > sb_sasl_write: failed to encode packet: generic failure > send_search_entry: conn 27 ber write failed. > slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e =3D=3D entry' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1986071456 (LWP 27434)] > 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > (gdb) where > #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 > #2 0x00ada279 in abort () from /lib/tls/libc.so.6 > #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x08114473 in ldap_pvt_runqueue_remove (rq=3D0x82c1820, entry=3D0x6b2a)= at rq.c:92 > #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403c88) at syncprov.c:744 > #6 0x0810011d in syncprov_qtask (ctx=3D0x76610210, arg=3D0x845e880) at syn= cprov.c:949 > #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=3D0x82e6c78) at tpool= .c:663 > #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 > #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 > (gdb) frame 5 > #5 0x080ffd9f in syncprov_free_syncop (so=3D0x8403c88) at syncprov.c:744 > 744 ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask ); > (gdb) print so > $1 =3D (syncops *) 0x8403c88 > (gdb) print *so > $2 =3D {s_next =3D 0x0, s_base =3D {bv_len =3D 6, bv_val =3D 0x83f9b50 "cn= =3Dlog"}, s_eid =3D 1, s_op =3D 0x83fe748, s_rid =3D 1, s_sid =3D -1, > s_filterstr =3D {bv_len =3D 46, bv_val =3D 0x7881811c "0\001.\b\022"}, s= _flags =3D 2, s_inuse =3D 0, s_res =3D 0x0, s_restail =3D 0x0, > s_qtask =3D 0x845e880, s_mutex =3D {__m_reserved =3D 1, __m_count =3D 0,= __m_owner =3D 0x6b2a, __m_kind =3D 0, __m_lock =3D {__status =3D 1, > __spinlock =3D 0}}} This is extremely odd - the structure definition clearly shows the value of=20 s_qtask that should have been passed to ldap_pvt_runqueue_remove, and yet you= r=20 trace shows that the value that actually got passed is s_mutex.__m_owner. Thi= s=20 looks like a pretty major compiler bug, assuming the trace is correct. What=20 version of compiler did you use, were you using optimization? Can you try wit= h=20 a different version and/or without optimization? --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============1763727054201727114==-- From stelios.xx.grigoriadis@ericsson.com Fri May 16 08:12:38 2008 From: stelios.xx.grigoriadis@ericsson.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection Date: Fri, 16 May 2008 08:12:38 +0000 Message-ID: <200805160812.m4G8CcAn047793@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1700016958066636915==" --===============1700016958066636915== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit We also have a patch for the stable version should anybody be interested in it. ----- # This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software # represented in the following patch(es) were developed by Stelios Grigoriadis stelios.xx.grigoriadis(a)ericsson.com. # These modifications are not subject to any license of Ericsson AB. # I, Stelios Grigoriadis, hereby place the following modifications to OpenLDAP Software (and only these modifications) # into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or # without attribution and/or other notice. # Bug Fix - This patch fixes the bug ITS#5133. # The fix works as follows. A periodic check in the runqueue (called do_mastercheck). The intervall is determined by # a slapd.conf parameter (mastercheckint) in the syncrepl section and is optional. If it's not specified, it's not # inserted in the runqueue. --- servers/slapd/syncrepl.c 2007-10-05 10:36:13.000000000 +0200 +++ syncrepl.c 2008-05-13 14:27:09.000000000 +0200 @@ -78,6 +78,7 @@ int si_manageDSAit; int si_slimit; int si_tlimit; + int si_mastercheck_int; int si_refreshDelete; int si_refreshPresent; int si_syncdata; @@ -89,6 +90,9 @@ ldap_pvt_thread_mutex_t si_mutex; } syncinfo_t; +/* Necessary in order to use asynchronous searches in mastercheck */ +static ber_int_t ps_msgid; + static int syncuuid_cmp( const void *, const void * ); static void avl_ber_bvfree( void * ); static void syncrepl_del_nonpresent( Operation *, syncinfo_t *, BerVarray, struct berval * ); @@ -314,7 +318,6 @@ BerElement *ber = (BerElement *)&berbuf; LDAPControl c[2], *ctrls[3]; struct timeval timeout; - ber_int_t msgid; int rc; int rhint; char *base; @@ -402,7 +405,7 @@ rc = ldap_search_ext( si->si_ld, base, scope, filter, attrs, attrsonly, ctrls, NULL, si->si_tlimit > 0 ? &timeout : NULL, - si->si_slimit, &msgid ); + si->si_slimit, &ps_msgid ); ber_free_buf( ber ); return rc; } @@ -667,7 +670,7 @@ tout_p = NULL; } - while (( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE, + while (( rc = ldap_result( si->si_ld, ps_msgid, LDAP_MSG_ONE, tout_p, &res )) > 0 ) { if ( slapd_shutdown ) { @@ -2769,6 +2772,7 @@ #define OLDAUTHCSTR "bindprincipal" #define EXATTRSSTR "exattrs" #define MANAGEDSAITSTR "manageDSAit" +#define MASTERCHECKINTSTR "mastercheckint" /* FIXME: unused */ #define LASTMODSTR "lastmod" @@ -3198,6 +3202,17 @@ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); return 1; } + } else if ( !strncasecmp( c->argv[ i ], MASTERCHECKINTSTR "=", + STRLENOF( MASTERCHECKINTSTR "=" ) ) ) + { + val = c->argv[ i ] + STRLENOF( MASTERCHECKINTSTR "=" ); + if ( lutil_atoi( &si->si_mastercheck_int, val ) != 0 || si->si_mastercheck_int < 0 ) { + snprintf( c->msg, sizeof( c->msg ), + "invalid master check interval value \"%s\".\n", + val ); + Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); + return 1; + } } else if ( !strncasecmp( c->argv[ i ], SYNCDATASTR "=", STRLENOF( SYNCDATASTR "=" ) ) ) { @@ -3273,6 +3288,7 @@ si->si_tlimit = 0; si->si_slimit = 0; si->si_conn_setup = 0; + si->si_mastercheck_int = 0; si->si_presentlist = NULL; LDAP_LIST_INIT( &si->si_nonpresentlist ); @@ -3435,6 +3451,68 @@ ber_dupbv( bv, &bc ); } +static void * +do_mastercheck( + void *ctx, + void *arg ) +{ + struct re_s* rtask = arg; + syncinfo_t *si = ( syncinfo_t * ) rtask->arg; + int rc; + char *search_attrs[] = { NULL }; + LDAPMessage *res = 0; + struct timeval timeout; + timeout.tv_sec = 0; + timeout.tv_usec = 0; + static int mc_msg=-1; + + ldap_pvt_thread_mutex_lock( &si->si_mutex ); + if (si->si_ld) { + if (mc_msg != -1) { + res=0; + ldap_result(si->si_ld, mc_msg, 1, &timeout, &res); + if (res) { ldap_msgfree(res);} + if (rc != LDAP_SUCCESS) { + ldap_abandon_ext(si->si_ld, mc_msg, NULL, NULL); + } + } + mc_msg=-1; + rc=ldap_search_ext(si->si_ld, "", LDAP_SCOPE_BASE, "(objectClass=*)", search_attrs, + 0, NULL, NULL, NULL, 0, &mc_msg); + if (rc != LDAP_SUCCESS) { + Debug(LDAP_DEBUG_ANY,"Failed to send\n",0,0,0); + } + } + + ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex ); + + if ( ldap_pvt_runqueue_isrunning( &slapd_rq, rtask )) { + ldap_pvt_runqueue_stoptask( &slapd_rq, rtask ); + } + + rtask->interval.tv_sec = si->si_mastercheck_int; + ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); + + ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); + + ldap_pvt_thread_mutex_unlock( &si->si_mutex ); +} + +static int add_mastercheck( ConfigArgs *c ) { + int rc; + syncinfo_t *si = c->be->be_syncinfo; + + if ( si->si_mastercheck_int == 0 ) + return 0; + + rc = ldap_pvt_runqueue_insert( &slapd_rq, si->si_mastercheck_int * 60, + do_mastercheck, si, "do_mastercheck", c->be->be_suffix[0].bv_val ); + if (rc < 0) + Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 ); + + return rc; +} + int syncrepl_config( ConfigArgs *c ) { @@ -3470,5 +3548,6 @@ } else if ( add_syncrepl( c ) ) { return(1); } + add_mastercheck( c ); return config_sync_shadow( c ); } --===============1700016958066636915==-- From h.b.furuseth@usit.uio.no Fri May 16 14:01:00 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5510) Does GSSAPI failure kill slapd? Date: Fri, 16 May 2008 14:01:00 +0000 Message-ID: <200805161401.m4GE10CH064634@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1529404290548155889==" --===============1529404290548155889== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit hyc(a)symas.com writes: > This looks like a pretty major compiler bug, assuming the trace is > correct. Not necessarily, valid optimizations can rearrange memory beyond a debugger's ability to figure out what's going on. Still, this does look like a strange optimization if it's a valid one. > What version of compiler did you use, were you using optimization? Can > you try with a different version and/or without optimization? -- Hallvard --===============1529404290548155889==-- From bgoldsbury@gleim.com Fri May 16 21:54:12 2008 From: bgoldsbury@gleim.com To: openldap-bugs@openldap.org Subject: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly Date: Fri, 16 May 2008 21:54:11 +0000 Message-ID: <200805162154.m4GLsBHO092079@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3003091859460476502==" --===============3003091859460476502== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Ben Goldsbury Version: 2.4.9 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.208.68.2) When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) = and using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: TLS certificate verification: Error, unable to get local issuer certificate When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) and using the same certificate, connections work properly. Please contact me if you need any additional information. --===============3003091859460476502==-- From ando@sys-net.it Sat May 17 09:03:17 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5502) LDAP problem Date: Sat, 17 May 2008 09:03:16 +0000 Message-ID: <200805170903.m4H93Gdg015489@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6233187569417558190==" --===============6233187569417558190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable javed_ansari(a)infosys.com wrote: > Full_Name: Javed Ansari > Version: 2.3.30 > OS: Sun > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.225.64.6) >=20 >=20 > 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: >=20 > [LDAP: error code 80 - entry store failed] >=20 > There however seems to be no problem with the login though, this occurs only > during registration You seem to be a little bit too confident on our capability to predict=20 the server's behavior based on a very limited amount of information.=20 Based on the accuracy of your issue report, all I can tell is that you=20 seem to have a problem. Please follow guidelines at=20 and provide a decent=20 issue report. 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 --------------------------------------- --===============6233187569417558190==-- From ando@sys-net.it Sat May 17 09:37:41 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5513) back-ldap+ppolicy bind assertion failure Date: Sat, 17 May 2008 09:37:41 +0000 Message-ID: <200805170937.m4H9bfYX020541@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8069441873101112404==" --===============8069441873101112404== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable mbackes(a)symas.com wrote: > A basic back-ldap configuration with the password policy overlay stacked on= top > results in an assertfail for the second bind. e.g. given a working (possi= bly > empty db) on ldap://localhost:1389/... >=20 > include ...../core.schema > include ...../ppolicy.schema >=20 > modulepath ..... > moduleload back_ldap.la > moduleload ppolicy.la >=20 > database ldap > suffix "" > uri ldap://localhost:1389/ >=20 > After performing a successful remote bind, the next bind attempt halts the > back-ldap directory with: >=20 > slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags= & > (0x02U) )' failed. >=20 > where 0x02U here is LDAP_BACK_AUTH_OVERRIDE. >=20 > This happens under both OpenLDAP 2.3 and 2.4. I've been able to reproduce the issue, and I think it's solved=20 (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't=20 understand all the details of your configuration, so I might have tested=20 something different. The bug was in ldap_back_entry_get() setting up a connection based on=20 the o_tag field, which is that of the current operation (a bind, in your=20 case). I fixed it by always re-setting the tag to LDAP_REQ_SEARCH,=20 under the assumption that ldap_back_entry_get() doesn't need to know=20 what operation required the entry to be looked up. Please test and report; in case of further issues, I might need the full=20 slapd.conf of the proxy (unless the above is all, of course...) 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 --------------------------------------- --===============8069441873101112404==-- From ando@sys-net.it Sat May 17 09:54:30 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: (ITS#5516) acl_set_cb_gather() incorrectly handles multiple attrs Date: Sat, 17 May 2008 09:54:30 +0000 Message-ID: <200805170954.m4H9sUNc021897@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1012240365435747262==" --===============1012240365435747262== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Only the last attribute is considered. Reported in . A fix is coming. --===============1012240365435747262==-- From mbackes@symas.com Sun May 18 01:03:01 2008 From: mbackes@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5513) back-ldap+ppolicy bind assertion failure Date: Sun, 18 May 2008 01:03:00 +0000 Message-ID: <200805180103.m4I130T4051225@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6355395238910042184==" --===============6355395238910042184== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I've been able to reproduce the issue, and I think it's solved > (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't > understand all the details of your configuration, so I might have > tested something different. > > The bug was in ldap_back_entry_get() setting up a connection based > on the o_tag field, which is that of the current operation (a bind, > in your case). I fixed it by always re-setting the tag to > LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() > doesn't need to know what operation required the entry to be looked > up. > > Please test and report; in case of further issues, I might need the > full slapd.conf of the proxy (unless the above is all, of course...) Thanks; this seems to fix the issue, at least in my test cases. Matthew Backes Symas Corporation mbackes(a)symas.com --===============6355395238910042184==-- From hyc@symas.com Sun May 18 06:24:56 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly Date: Sun, 18 May 2008 06:24:56 +0000 Message-ID: <200805180624.m4I6Ouwd063074@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1105030827942041698==" --===============1105030827942041698== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable bgoldsbury(a)gleim.com wrote: > Full_Name: Ben Goldsbury > Version: 2.4.9 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.208.68.2) > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing= ) and > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail wi= th: > > TLS certificate verification: Error, unable to get local issuer certificate > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testi= ng) > and using the same certificate, connections work properly. > > Please contact me if you need any additional information. This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. What exactly do you mean by "Wildcard SSL certificate" ? There are a couple=20 different approaches to that. One uses the subjectAltName extension, and that= =20 is the officially sanctioned approach. One uses "*" in the certificate CN, an= d=20 that is non-standard and generally not supposed to work. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============1105030827942041698==-- From ando@sys-net.it Sun May 18 09:26:25 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5513) back-ldap+ppolicy bind assertion failure Date: Sun, 18 May 2008 09:26:25 +0000 Message-ID: <200805180926.m4I9QPOt070186@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3842941563862314780==" --===============3842941563862314780== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit mbackes(a)symas.com wrote: > Thanks; this seems to fix the issue, at least in my test cases. OK, I've applied the fix to re23/re24 as well. 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 --------------------------------------- --===============3842941563862314780==-- From bpgoldsb@gleim.com Sun May 18 17:29:20 2008 From: bpgoldsb@gleim.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly Date: Sun, 18 May 2008 17:29:19 +0000 Message-ID: <200805181729.m4IHTJTj089115@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8129596340093970924==" --===============8129596340093970924== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We're using *.domain.tld in the CN and subjectAltName:DNS:*.domain.tld This may be a GnuTLS issue, as I am able to reproduce it with the GnuTLS server/client testing tools. On Sat, 2008-05-17 at 23:23 -0700, Howard Chu wrote: > bgoldsbury(a)gleim.com wrote: > > Full_Name: Ben Goldsbury > > Version: 2.4.9 > > OS: Debian > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (209.208.68.2) > > > > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testi= ng) and > > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail = with: > > > > TLS certificate verification: Error, unable to get local issuer certifica= te > > > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my tes= ting) > > and using the same certificate, connections work properly. > > > > Please contact me if you need any additional information. >=20 > This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. >=20 > What exactly do you mean by "Wildcard SSL certificate" ? There are a couple= =20 > different approaches to that. One uses the subjectAltName extension, and th= at=20 > is the officially sanctioned approach. One uses "*" in the certificate CN, = and=20 > that is non-standard and generally not supposed to work. --===============8129596340093970924==-- From h.b.furuseth@usit.uio.no Sun May 18 18:09:18 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: (ITS#5517) add superclass of existing class fails Date: Sun, 18 May 2008 18:09:17 +0000 Message-ID: <200805181809.m4II9HBS090323@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8963306726509980159==" --===============8963306726509980159== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard If objectclass B is a subclass of A, and an entry contains objectclass B but not A, slapd returns attributeOrValueExists to a request to add A. OTOH it allows replace(objectClass: ), and after that it allows delete(objectClass: A). This is inconsistent. If the objectClass attribute contains B, does it "really" contain A as well? I couldn't find such a statement in the RFCs, so my guess is that add(objectClass: A) should be allowed. Though I haven't looked all that hard. Example: ldapadd -cx <<'EOF' # Create initial object dn: c=NO objectClass: friendlyCountry c: NO co: Norway # error dn: c=NO changetype: modify add: objectClass objectClass: top - # error dn: c=NO changetype: modify add: objectClass objectClass: country - # success dn: c=NO changetype: modify replace: objectClass objectClass: top objectClass: country objectClass: friendlyCountry - # success dn: c=NO changetype: modify delete: objectClass objectClass: top - # success dn: c=NO changetype: modify delete: objectClass objectClass: country - EOF --===============8963306726509980159==-- From zulcss@ubuntu.com Mon May 19 08:47:54 2008 From: zulcss@ubuntu.com To: openldap-bugs@openldap.org Subject: (ITS#5518) Assertion error in io.c:234: ber_flush2 Date: Mon, 19 May 2008 08:47:53 +0000 Message-ID: <200805190847.m4J8lrxK024269@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4192434211086876516==" --===============4192434211086876516== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Chuck Short Version: 2.4.7 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.142.121.161) We are getting assertion errors in libraries/liblber/io.c. The original bug report is located at the following: http://bugs.launchpad.net/bugs/215904 Thanks chuck --===============4192434211086876516==-- From quanah@zimbra.com Mon May 19 18:14:22 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly Date: Mon, 19 May 2008 18:14:21 +0000 Message-ID: <200805191814.m4JIELon066758@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6272465257746484250==" --===============6272465257746484250== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Sunday, May 18, 2008 6:24 AM +0000 hyc(a)symas.com wrote: > bgoldsbury(a)gleim.com wrote: >> Full_Name: Ben Goldsbury >> Version: 2.4.9 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.208.68.2) >> >> >> When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my >> testing) and using a valid Wildcard SSL certificate, TLS connections to >> OpenLDAP fail with: >> >> TLS certificate verification: Error, unable to get local issuer >> certificate User verifies that this is a GnuTLS bug, this ITS will be closed. See last follow up in: --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============6272465257746484250==-- From fredme@gmail.com Mon May 19 18:46:27 2008 From: fredme@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5519) Compilation fails when linking with ldap threading symbols Date: Mon, 19 May 2008 18:46:26 +0000 Message-ID: <200805191846.m4JIkQWo068684@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8101796195518243978==" --===============8101796195518243978== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Eugenio Grytsenko Version: 2.4.9 OS: Suse Linux Enterprise Server 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.5.92.164) Ldap compilation fails when I am trying to compile with-threads and back_shell enabled. Here is the trace: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CUT HERE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D creating .libs/slapdS.c (cd .libs && cc -c -fno-builtin "slapdS.c") rm -f .libs/slapdS.c .libs/slapd.nm .libs/slapd.nmS .libs/slapd.nmT cc -g -O2 .libs/slapdS.o -o .libs/slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad= .o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral= .o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcs= n.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o alock.o txn.o version.o -rdynamic -Wl,-rpath -Wl,/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE -Wl,--export-dynamic = libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.so /root/fred/ldap24/openldap-2.4.9/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so /usr/lib64/libdb-4.2.so -L/usr/local/lib64 /usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/auto/DynaLo= ader/DynaLoader.a -L/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE -lperl /usr/lib64/libodbc.so -lpthread /usr/lib64/libslp.so -lm -lnsl /usr/lib64/libsasl2.so -lssl -lcrypto -lcrypt -lresolv libslapi.a /usr/lib64/libltdl.so -ldl -lwrap daemon.o(.text+0xe3f): In function `slap_listener_thread': /root/fred/ldap24/openldap-2.4.9/servers/slapd/daemon.c:1824: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead daemon.o(.text+0xe2e):/root/fred/ldap24/openldap-2.4.9/servers/slapd/daemon.c= :1824: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead result.o(.text+0x12cd): In function `slap_send_search_entry': /root/fred/ldap24/openldap-2.4.9/servers/slapd/result.c:1042: undefined reference to `ldap_pvt_thread_pool_pausing' syncrepl.o(.text+0x6bd5): In function `do_syncrep2': /root/fred/ldap24/openldap-2.4.9/servers/slapd/syncrepl.c:1140: undefined reference to `ldap_pvt_thread_pool_pausing' syncrepl.o(.text+0x6d2c):/root/fred/ldap24/openldap-2.4.9/servers/slapd/syncr= epl.c:1140: undefined reference to `ldap_pvt_thread_pool_pausing' liboverlays.a(syncprov.o)(.text+0x4e2d): In function `syncprov_op_mod': /root/fred/ldap24/openldap-2.4.9/servers/slapd/overlays/syncprov.c:1809: undefined reference to `ldap_pvt_thread_pool_pausecheck' collect2: ld returned 1 exit status make[2]: *** [slapd] Error 1 make[2]: Leaving directory `/root/fred/ldap24/openldap-2.4.9/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/fred/ldap24/openldap-2.4.9/servers' make: *** [all-common] Error 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CUT HERE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D OS I am using: Suse Linux Enterprise Server 9 GCC version string: Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=3Dposix --prefix=3D/usr --with-local-prefix=3D/usr/local --infodir=3D/usr/share/info --mandir=3D/usr/= share/man --enable-languages=3Dc,c++,f77,objc,java,ada --disable-checking --libdir=3D/usr/lib64 --enable-libgcj --with-gxx-include-dir=3D/usr/include/g= ++ --with-slibdir=3D/lib64 --with-system-zlib --enable-shared --enable-__cxa_ate= xit x86_64-suse-linux Thread model: posix gcc version 3.3.3 (SuSE Linux) My machine architecture: x86_64 My Kernel: Linux cs9 2.6.16.27-0.9-xen #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux My OpenLDAP configure command: ./configure \ --prefix=3D/usr \ --exec-prefix=3D/usr \ --bindir=3D/usr/bin \ --sbindir=3D/usr/sbin \ --libexecdir=3D/usr/lib64 \ --datadir=3D/usr/share \ --sysconfdir=3D/etc \ --sharedstatedir=3D/usr/share/com \ --localstatedir=3D/var/run/slapd \ --libdir=3D/usr/lib64 \ --includedir=3D/usr/include \ --oldincludedir=3D/usr/include \ --infodir=3D/usr/share/info \ --mandir=3D/usr/share/man \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-proctitle \ --enable-ipv6 \ --enable-local \ --enable-slapd \ --enable-dynacl \ --enable-aci \ --enable-cleartext \ --enable-crypt \ --enable-lmpasswd \ --enable-spasswd \ --enable-modules \ --enable-rewrite \ --enable-rlookups \ --enable-slapi \ --enable-slp \ --enable-wrappers \ --enable-backends \ --enable-bdb \ --enable-dnssrv \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-null \ --enable-passwd \ --enable-perl \ --enable-relay \ --enable-shell \ --enable-sock \ --enable-sql \ --enable-overlays \ --enable-accesslog \ --enable-auditlog \ --enable-constraint \ --enable-dds \ --enable-dyngroup \ --enable-dynlist \ --enable-memberof \ --enable-ppolicy \ --enable-proxycache \ --enable-refint \ --enable-retcode \ --enable-rwm \ --enable-seqmod \ --enable-syncprov \ --enable-translucent \ --enable-unique \ --enable-valsort \ --enable-static \ --enable-shared \ --enable-fast-install \ --with-cyrus-sasl \ --without-threads \ --with-tls \ --with-yielding-select \ --with-mp \ --with-odbc=3Dunixodbc \ --with-gnu-ld \ --with-pic Thanks. --===============8101796195518243978==-- From fredme@gmail.com Mon May 19 18:55:48 2008 From: fredme@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5519) Date: Mon, 19 May 2008 18:55:47 +0000 Message-ID: <200805191855.m4JItlWE069093@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9190655498011353305==" --===============9190655498011353305== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit All works fine if I change the flags to --with-threads and --disable-shell. --===============9190655498011353305==-- From hyc@symas.com Tue May 20 09:28:31 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5519) Date: Tue, 20 May 2008 09:28:31 +0000 Message-ID: <200805200928.m4K9SV42023931@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0092879701381856195==" --===============0092879701381856195== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit fredme(a)gmail.com wrote: > All works fine if I change the flags to --with-threads and --disable-shell. This is now fixed in CVS HEAD. It's probably best that you build with --disable-shell anyway though. Migrate to back-sock instead... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============0092879701381856195==-- From h.b.furuseth@usit.uio.no Tue May 20 09:41:33 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5519) Compilation fails when linking with ldap threading symbols Date: Tue, 20 May 2008 09:41:33 +0000 Message-ID: <200805200941.m4K9fXpG025150@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0215142144220158189==" --===============0215142144220158189== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit fredme writes: > Ldap compilation fails when I am trying to compile with-threads and > back_shell enabled. I think you mean --without-threads broke it... BTW, note that --enable-backends and --enable-overlays enable all backends/overlays, you don't need --enable- switches in addition. And to drop the shell backend as Howard suggests, you'd then override with --disable-shell. -- Hallvard --===============0215142144220158189==-- From hyc@symas.com Tue May 20 09:55:06 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5518) Assertion error in io.c:234: ber_flush2 Date: Tue, 20 May 2008 09:55:06 +0000 Message-ID: <200805200955.m4K9t6rX026432@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2814004887911518632==" --===============2814004887911518632== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 2.4.7 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.142.121.161) > > > We are getting assertion errors in libraries/liblber/io.c. The original bug > report is located at the following: > > http://bugs.launchpad.net/bugs/215904 I've requested some more information on the above bug report. Looking back over ITS, it seems this has been a long-standing problem with nss-ldap. http://www.openldap.org/its/index.cgi/Incoming?id=3874;expression=liblber http://www.openldap.org/its/index.cgi/Incoming?id=4014;expression=liblber https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124549 http://www.openldap.org/its/index.cgi/Incoming?id=4445;expression=liblber Unfortunately the information in the other reports is a bit confusing; e.g. the redhat bug indicates that a kernel update fixed the issue. That doesn't really make any sense. Hopefully we can get some consistent info to track it down this time. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============2814004887911518632==-- From jeff@jeffrodriguez.com Tue May 20 23:37:47 2008 From: jeff@jeffrodriguez.com To: openldap-bugs@openldap.org Subject: (ITS#5520) infinite recursion in syncrepl overlay Date: Tue, 20 May 2008 23:37:46 +0000 Message-ID: <200805202337.m4KNbkYN085192@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6578708368939421847==" --===============6578708368939421847== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Jeff Rodriguez Version: 2.3.30 OS: Debian etch URL: ftp://ftp.openldap.org/incoming/jeff-rodriguez-080520.tgz Submission from: (NULL) (208.48.140.97) syncprov seems to be causing a segfault when importing kerberos entries. slapd.conf, LDIFs, heimdal kerberos schema, and logs included. These are live files I was used to generate the segfault. It's also reproducible with the co= nf and ldif files customized to the environment. Commenting out syncprov and related lines in the conf eliminates the segfault. 1. stop slapd 2. wipe out current database 3. slapadd schema.ldif and chown the database to openldap user and group 4. start slapd with: /usr/sbin/slapd -g openldap -u openldap -d 1 -h "ldap:/// ldapi:///" 5. add ldif entries live: ldapadd -H ldapi:///var/run/ldapi -D cn=3Dadmin,o=3Dexample -w CHANGE_THIS_PASSWORD -f bugged.ldif 6. segfault uname -a: Linux ds1.phx2 2.6.18-6-xen-amd64 #1 SMP Sun Feb 10 18:02:52 UTC 2008 x86_64 GNU/Linux --===============6578708368939421847==-- From quanah@zimbra.com Wed May 21 00:13:04 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5520) infinite recursion in syncrepl overlay Date: Wed, 21 May 2008 00:13:03 +0000 Message-ID: <200805210013.m4L0D3At087933@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2150206915503222129==" --===============2150206915503222129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, May 20, 2008 11:37 PM +0000 jeff(a)jeffrodriguez.com wrote: > Full_Name: Jeff Rodriguez > Version: 2.3.30 > OS: Debian etch > URL: ftp://ftp.openldap.org/incoming/jeff-rodriguez-080520.tgz > Submission from: (NULL) (208.48.140.97) 2.3.30 is an extremely old release. Please re-test with 2.3.41. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2150206915503222129==-- From rhafer@suse.de Wed May 21 14:27:23 2008 From: rhafer@suse.de To: openldap-bugs@openldap.org Subject: (ITS#5521) Can't change indexing of an attribute within a single modification Date: Wed, 21 May 2008 14:27:23 +0000 Message-ID: <200805211427.m4LERNfF031184@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3753572381260655259==" --===============3753572381260655259== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS:=20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.89.54) The following modification to add an additional index an attribute fails with the error messages pasted below: -------------------------- dn: olcDatabase=3D{1}bdb,cn=3Dconfig changetype: modify delete: olcdbindex olcDbIndex: cn pres,eq - add: olcdbindex olcDbIndex: cn pres,eq,sub -------------------------- modifying entry "olcDatabase=3D{1}bdb,cn=3Dconfig" ldap_modify: Other (e.g., implementation specific) error (80) additional info: handler exited with 1 As far as I can see it fails because the old indexmask hat not yet been delet= ed from the bdb-struct. The ainfo_insert()-call in back-bdb/attr.c(bdb_attr_index_config()) returns with -1. Splitting the above modification in two separate operations works around that problem. --===============3753572381260655259==-- From andrew.graham@agustawestland.com Thu May 22 09:44:38 2008 From: Andrew Graham To: openldap-bugs@openldap.org Subject: Segmentation fault with quarantine Date: Thu, 22 May 2008 10:43:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6110079132517562795==" --===============6110079132517562795== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable *** Before acting on this email or opening any attachment you are advised to= read the disclaimer at the end of this email *** I've set up a meta directory with openldap, which has worked flawlessly until now. If I set the 'quarantine' directive slapd fails to start, giving a segmentation fault. This occurs every time I use quarantine, on two different distros, on any version of openldap that I've tested (2.3.39, 2.3.41, 2.4.9), with both my usual config file and a very simple config file. As an example, I built openldap 2.4.9 on suse 10 with the following configure line... # ./configure --prefix=3D/usr/local/ldap3 --enable-meta --enable-ldap Slapd.conf looks like... ******************* include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include =20 /usr/local/ldap/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/ldap/var/run/slapd.pid argsfile /usr/local/ldap/var/run/slapd.args database meta suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3Dmanager,dc=3Dexample,dc=3Dcom" rootpw "secret" quarantine 1800,3 uri "ldap://ldap.example.com/dc=3Dexample,dc=3Dcom" ******************* Obviously my normal config looks nothing like this, but running this config gets the same result. the last few lines that slapd will output with full debug gives... ****************** line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 10 (argsfile /usr/local/ldap/var/run/slapd.args) line 13 (database meta) line 14 (suffix "dc=3Dexample,dc=3Dcom") >>> dnPrettyNormal: =3D> ldap_bv2dn(dc=3Dexample,dc=3Dcom,0) <=3D ldap_bv2dn(dc=3Dexample,dc=3Dcom)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(dc=3Dexample,dc=3Dcom)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(dc=3Dexample,dc=3Dcom)=3D0 <<< dnPrettyNormal: , line 16 (rootdn "cn=3Dmanager,dc=3Dexample,dc=3Dcom") >>> dnPrettyNormal: =3D> ldap_bv2dn(cn=3Dmanager,dc=3Dexample,dc=3Dcom,0) <=3D ldap_bv2dn(cn=3Dmanager,dc=3Dexample,dc=3Dcom)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Dmanager,dc=3Dexample,dc=3Dcom)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Dmanager,dc=3Dexample,dc=3Dcom)=3D0 <<< dnPrettyNormal: , line 17 (rootpw ***) line 19 (quarantine 1800,3) ******************* Before exiting with Segmentation Fault. Gdb shows... ****************** Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211279696 (LWP 19080)] 0x081296d0 in ?? () ****************** Is this a bug or some mistake I'm making? Thanks is advance! Drew Graham *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence ma= y be subject to the Export Control Act (ECA) 2002. The content is private and= is intended solely for the recipient(s).=20 For those other than the recipient any disclosure, copying, distribution, or = action taken, or omitted to be taken, in reliance on such information is proh= ibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 20= 02, is a criminal offence. Westland Helicopters Ltd=20 Lysander Road=20 Yeovil BA20 2YB=20 England=20 Registered in England under No 604352=20 --===============6110079132517562795==-- From ando@sys-net.it Thu May 22 14:06:14 2008 From: Pierangelo Masarati To: openldap-bugs@openldap.org Subject: Re: Segmentation fault with quarantine Date: Thu, 22 May 2008 16:05:51 +0200 Message-ID: <48357DBF.8090407@sys-net.it> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2552644312005795104==" --===============2552644312005795104== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Andrew Graham wrote: > Is this a bug or some mistake I'm making? It is definitely a bug. Please file an ITS. 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 --------------------------------------- --===============2552644312005795104==-- From andrew.graham@agustawestland.com Thu May 22 15:11:33 2008 From: andrew.graham@agustawestland.com To: openldap-bugs@openldap.org Subject: (ITS#5522) Quarantine causes segmentation fault Date: Thu, 22 May 2008 15:11:33 +0000 Message-ID: <200805221511.m4MFBXx7030658@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0656982647847276884==" --===============0656982647847276884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Drew Graham Version: 2.4.9 OS: SUSE 10 URL: Submission from: (NULL) (194.169.32.250) I've set up a meta directory with openldap, which has worked flawlessly until now. If I set the 'quarantine' directive slapd fails to start, giving a segmentation fault. This occurs every time I use quarantine, on two different distros, on any version of openldap that I've tested (2.3.39, 2.3.41, 2.4.9), with both my usual config file and a very simple config file. As an example, I built openldap 2.4.9 on suse 10 with the following configure line... # ./configure --prefix=/usr/local/ldap3 --enable-meta --enable-ldap Slapd.conf looks like... ******************* include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/ldap/var/run/slapd.pid argsfile /usr/local/ldap/var/run/slapd.args database meta suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" rootpw "secret" quarantine 1800,3 uri "ldap://ldap.example.com/dc=example,dc=com" ******************* Obviously my normal config looks nothing like this, but running this config gets the same result. the last few lines that slapd will output with full debug gives... ****************** line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 9 (pidfile /usr/local/ldap/var/run/slapd.pid) line 10 (argsfile /usr/local/ldap/var/run/slapd.args) line 13 (database meta) line 14 (suffix "dc=example,dc=com") >>> dnPrettyNormal: => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: , line 16 (rootdn "cn=manager,dc=example,dc=com") >>> dnPrettyNormal: => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: , line 17 (rootpw ***) line 19 (quarantine 1800,3) ******************* Slapd then exits with Segmentation Fault. Gdb shows... ****************** Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211279696 (LWP 19080)] 0x081296d0 in ?? () ****************** Thanks is advance! Drew Graham --===============0656982647847276884==-- From quanah@OpenLDAP.org Thu May 22 19:28:02 2008 From: quanah@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5523) BDB 4.7 support Date: Thu, 22 May 2008 19:28:01 +0000 Message-ID: <200805221928.m4MJS1FW055200@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7424327665957643394==" --===============7424327665957643394== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Quanah Gibson-Mount Version: HEAD/RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) BDB 4.7 is officially released. We should add support for it. --===============7424327665957643394==-- From andrew.findlay@skills-1st.co.uk Thu May 22 19:30:25 2008 From: andrew.findlay@skills-1st.co.uk To: openldap-bugs@openldap.org Subject: (ITS#5524) Additions to the Security section of the Admin Guide Date: Thu, 22 May 2008 19:30:24 +0000 Message-ID: <200805221930.m4MJUOoM055987@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7451420151565251807==" --===============7451420151565251807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Andrew Findlay Version: 2.4.9 OS: Linux URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522 Submission from: (NULL) (88.97.25.132) This patch adds text to the Security chapter in the Admin Guide. It describes the password storage schemes, including the {SASL} scheme that triggers pass-through authentication. The latter facility has existed since version 2.0 but has never been mentioned in the docs, so I have included a section with an example of its use. --===============7451420151565251807==-- From quanah@zimbra.com Thu May 22 19:32:33 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5523) BDB 4.7 support Date: Thu, 22 May 2008 19:32:33 +0000 Message-ID: <200805221932.m4MJWXuD056767@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8317576417214009634==" --===============8317576417214009634== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --On Thursday, May 22, 2008 7:28 PM +0000 quanah(a)OpenLDAP.org wrote: Change log at: --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============8317576417214009634==-- From hyc@symas.com Thu May 22 20:22:40 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5523) BDB 4.7 support Date: Thu, 22 May 2008 20:22:39 +0000 Message-ID: <200805222022.m4MKMd6M072491@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1567902943126947031==" --===============1567902943126947031== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > --On Thursday, May 22, 2008 7:28 PM +0000 quanah(a)OpenLDAP.org wrote: > > Change log at: > > Hooray, they've finally got a partitioned lock manager. The lock subsystem ha= s=20 always been a huge bottleneck in previous releases... The last time I looked at 4.7, the main problem was that they stopped=20 exporting the __lock_getlocker() function. As a quick hack to allow testing=20 the rest of OpenLDAP, I just patched it back in to my copy. The clean approach would be to once again resurrect the long-lived=20 read-transaction code that we dropped a long time back. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============1567902943126947031==-- From hyc@symas.com Thu May 22 20:30:58 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5523) BDB 4.7 support Date: Thu, 22 May 2008 20:30:58 +0000 Message-ID: <200805222030.m4MKUwhb074904@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0581190777293859622==" --===============0581190777293859622== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > Hooray, they've finally got a partitioned lock manager. The lock subsystem = has > always been a huge bottleneck in previous releases... (Relatively speaking. Back in OpenLDAP 2.0 we had plenty of other problems,=20 but today most of those are gone, and BerkeleyDB's lock manager is quite=20 conspicuous in current profile results...) --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============0581190777293859622==-- From paul@mad-scientist.us Fri May 23 03:58:18 2008 From: paul@mad-scientist.us To: openldap-bugs@openldap.org Subject: (ITS#5525) libldap causes a core dump due to accessing freed memory Date: Fri, 23 May 2008 03:58:18 +0000 Message-ID: <200805230358.m4N3wIY5000976@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5497192984608859845==" --===============5497192984608859845== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Paul Smith Version: 2.4.7 OS: Ubuntu 8.04 URL:=20 Submission from: (NULL) (65.78.30.67) I've been trying to track down a crasher in Evolution's Exchange server backe= nd, and I believe it's a bug in OpenLDAP's libldap. The core manifests as an assert() in io.c:ber_flush2(), but by using valgrind I can see that the real problem is using already-freed memory. You can see various backtraces and valgrind outputs in the Gnome bug tracking system here: http://bugzilla.gnome.org/show_bug.cgi?id=3D512605 Note that the later stack traces are better as I've installed debugging versions of OpenLDAP so there are better symbols shown. In Evolution we have a loop we use to look up global contacts, which looks li= ke this: for (try =3D 0; try < 2; try++) { ldap_error =3D get_gc_connection (gc, op); if (ldap_error !=3D LDAP_SUCCESS) return ldap_error; ldap_error =3D ldap_search_ext (gc->priv->ldap, base, scope, filter, (char **)attrs, FALSE, NULL, NULL, NULL, 0, &msgid); if (ldap_error =3D=3D LDAP_SERVER_DOWN) continue; else if (ldap_error !=3D LDAP_SUCCESS) return ldap_error; =20 ldap_error =3D gc_ldap_result (gc->priv->ldap, op, msgid, msg); if (ldap_error =3D=3D LDAP_SERVER_DOWN) continue; else if (ldap_error !=3D LDAP_SUCCESS) return ldap_error; =20 return LDAP_SUCCESS; } where get_gc_connection() eventually calls ldap_ntlm_bind() and where gc_ldap_result() calls ldap_result(). When the core happens, the first trip through the for loop here gives an error LDAP_SERVER_DOWN as the return code from ldap_result(). We go back to the top of the loop, and ldap_ntlm_bind() = is called. That eventually ends up in ldap_send_initial_request() which invokes ldap_send_server_request() like this: rc =3D ldap_send_server_request( ld, ber, msgid, NULL, NULL, NULL, NULL ); Inside ldap_send_server_request() we need to find an LDAPConn* structure, but the one passed in is NULL as is the srvlist, so, we use the default connectio= n: if ( lc =3D=3D NULL ) { if ( srvlist =3D=3D NULL ) { lc =3D ld->ld_defconn; Valgrind reports that the very next line, attempting to access lc->lconn_stat= us, is referencing freed memory: if ( lc !=3D NULL && lc->lconn_status =3D=3D LDAP_CONNST_CONNECTING )= { So, basically, we know that ld->ld_defconn is a non-NULL pointer pointing to already freed memory. This seems like it is a buggy state. How did we get here? In ldap_result() we get into this loop invoking try_read1msg() (I'm removing the mutex locking for readability, even though it IS enabled in my version of libldap): for ( lc =3D ld->ld_conns; rc =3D=3D LDAP_MSG_X_KEEP_LOOKING && lc !=3D NULL; ) { if ( lc->lconn_status =3D=3D LDAP_CONNST_CONNECTED && ldap_is_read_ready( ld, lc->lconn_sb ) ) { rc =3D try_read1msg( ld, msgid, all, &lc, result ); if ( lc =3D=3D NULL ) { /* if lc gets free()'d, * there's no guarantee * lc->lconn_next is still * sane; better restart * (ITS#4405) */ lc =3D ld->ld_conns; /* don't get to next conn! */ break; } } /* next conn */ lc =3D lc->lconn_next; } Inside try_read1msg() we call "tag =3D ber_get_next( lc->lconn_sb, &len, ber = );" and if the tag we get back is LBER_DEFAULT, then we declare an error and we f= ree the connection and set the pointer to NULL: case LBER_DEFAULT: ld->ld_errno =3D LDAP_SERVER_DOWN; ldap_free_connection( ld, lc, 1, 0 ); lc =3D *lcp =3D NULL; return -1; If you check ldap_free_connection() you'll see that it removes the LDAPConn pointer "lc" from the list of connections before it is freed. BUT! The ldap_free_connection() function never does anything with the ld->ld_defconn pointer, so if the connection we just freed is the one pointed= to by ld->ld_defconn, it is now pointing to freed memory. And that causes the problem detected above by valgrind, or causing an assert later on: accessing freed memory. I'm not really sure what the right thing to do here is, or I'd provide a patc= h.=20 Should we set ld_defconn to NULL? Is that ever a valid state? Or should we just pick another connection from the list (and what if there isn't one?) --===============5497192984608859845==-- From paul@mad-scientist.us Fri May 23 04:04:34 2008 From: paul@mad-scientist.us To: openldap-bugs@openldap.org Subject: Re: (ITS#5518) Assertion error in io.c:234: ber_flush2 Date: Fri, 23 May 2008 04:04:33 +0000 Message-ID: <200805230404.m4N44Xt2001337@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4890389540849789534==" --===============4890389540849789534== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all; I just posted a new bug 5525 that describes exactly how this happens and where the bug is. I came to this conclusion while trying to find a crasher in Evolution Exchange: I ran it under valgrind to find the use of freed memory. Hopefully this will provide us with a quick fix! --===============4890389540849789534==-- From quanah@zimbra.com Fri May 23 04:44:01 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5522) Quarantine causes segmentation fault Date: Fri, 23 May 2008 04:44:00 +0000 Message-ID: <200805230444.m4N4i0tg005683@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6206011038932764577==" --===============6206011038932764577== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Thursday, May 22, 2008 3:11 PM +0000 andrew.graham(a)agustawestland.com wrote: > Full_Name: Drew Graham > Version: 2.4.9 > OS: SUSE 10 > URL: > Submission from: (NULL) (194.169.32.250) > ******************* > > Slapd then exits with Segmentation Fault. Gdb shows... This bug has been patched by Pierangelo in HEAD, and it will be in the 2.3.42 and 2.4.10 releases. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============6206011038932764577==-- From hyc@symas.com Fri May 23 07:10:45 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5518) Assertion error in io.c:234: ber_flush2 Date: Fri, 23 May 2008 07:10:44 +0000 Message-ID: <200805230710.m4N7Aigj013716@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1513201133170747888==" --===============1513201133170747888== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable paul(a)mad-scientist.us wrote: > Hi all; I just posted a new bug 5525 that describes exactly how this > happens and where the bug is. I came to this conclusion while trying to > find a crasher in Evolution Exchange: I ran it under valgrind to find > the use of freed memory. > > Hopefully this will provide us with a quick fix! Thanks for tracking this down Paul. I think you've nailed it for us, we shoul= d=20 be able to patch this pretty soon. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============1513201133170747888==-- From abackman@gmail.com Fri May 23 07:50:24 2008 From: Andreas Backman To: openldap-bugs@openldap.org Subject: Permission denied while opening odbcinst.ini Date: Fri, 23 May 2008 09:50:11 +0200 Message-ID: <27b503030805230050l2bb68cebwd22a2230c7c665a7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2091785104967173608==" --===============2091785104967173608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all! I'm trying to configure an OpenLDAP server with a mySQL server as back-end. This is what happens when i try to start the server. root(a)ldap:~# slapd -d1 --------- backsql_open_db_handle(): SQLConnect() to database "MySQL" failed. Return code: -1 nativeErrCode=0 SQLengineState=IM002 msg="[unixODBC][Driver Manager]Data source name not found, and no default driver specified" --------- I couldn't find anything wrong with my configuration (see odbc.ini and odbcinst.ini below) so i tried strace: root(a)ldap:~# strace -o /tmp/out.txt slapd root(a)ldap:~# grep odbc /tmp/out.txt open("/usr/lib/libodbc.so.1", O_RDONLY) = 3 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) access("/etc/odbc.ini", F_OK) = 0 stat64("/etc/odbc.ini", {st_mode=S_IFREG|0644, st_size=598, ...}) = 0 open("/etc/odbcinst.ini", O_RDONLY) = -1 EACCES (Permission denied) Permissions of odbc.ini and odbcinst.ini root(a)ldap:/etc# ls odbc*.ini -l -rw-r--r-- 1 root root 598 2008-05-23 08:50 odbc.ini -rw-r--r-- 1 root root 549 2008-05-23 08:49 odbcinst.ini Contents of my odbc.ini and odbcinst.ini: odbc.ini: --------- [MySQL] Description = MySQL test database Driver = MySQL SERVER = 192.168.100.38 USER = root PASSWORD = *** PORT = 3306 DATABASE = kplatsen ---------- odbsinst.ini ---------- [MySQL] Description = MySQL driver for Linux & Win32 Driver = /usr/lib/odbc/libmyodbc3.so Setup = /usr/lib/odbc/libmyodbc3S.so FileUsage = 1 [Default] Driver = /usr/lib/odbc/libmyodbc.so UsageCount = 1 ---------- I've tested the ODBC-connection with: root(a)ldap:~# isql MySQL and it works... Please help! --===============2091785104967173608== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.htm" MIME-Version: 1.0 SGkgYWxsITxicj5JJiMzOTttIHRyeWluZyB0byBjb25maWd1cmUgYW4gT3BlbkxEQVAgc2VydmVy IHdpdGggYSBteVNRTCBzZXJ2ZXIgYXMgYmFjay1lbmQuPGJyPlRoaXMgaXMgd2hhdCBoYXBwZW5z IHdoZW4gaSB0cnkgdG8gc3RhcnQgdGhlIHNlcnZlci48YnI+PGJyPnJvb3RAbGRhcDp+IyBzbGFw ZCAtZDE8YnI+LS0tLS0tLS0tPGJyPmJhY2tzcWxfb3Blbl9kYl9oYW5kbGUoKTogU1FMQ29ubmVj dCgpIHRvIGRhdGFiYXNlICZxdW90O015U1FMJnF1b3Q7IGZhaWxlZC48YnI+ClJldHVybiBjb2Rl OiAtMTxicj4mbmJzcDsmbmJzcDsgbmF0aXZlRXJyQ29kZT0wIFNRTGVuZ2luZVN0YXRlPUlNMDAy IG1zZz0mcXVvdDtbdW5peE9EQkNdW0RyaXZlciBNYW5hZ2VyXURhdGEgc291cmNlIG5hbWUgbm90 IGZvdW5kLCBhbmQgbm8gZGVmYXVsdCBkcml2ZXIgc3BlY2lmaWVkJnF1b3Q7PGJyPi0tLS0tLS0t LTxicj48YnI+SSBjb3VsZG4mIzM5O3QgZmluZCBhbnl0aGluZyB3cm9uZyB3aXRoIG15IGNvbmZp Z3VyYXRpb24gKHNlZSBvZGJjLmluaSBhbmQgb2RiY2luc3QuaW5pIGJlbG93KSBzbyBpIHRyaWVk IHN0cmFjZTo8YnI+Cjxicj5yb290QGxkYXA6fiMgc3RyYWNlIC1vIC90bXAvb3V0LnR4dCBzbGFw ZDxicj48YnI+cm9vdEBsZGFwOn4jIGdyZXAgb2RiYyAvdG1wL291dC50eHQgPGJyPm9wZW4oJnF1 b3Q7L3Vzci9saWIvbGlib2RiYy5zby4xJnF1b3Q7LCBPX1JET05MWSkgPSAzPGJyPm9wZW4oJnF1 b3Q7L2V0Yy9vZGJjaW5zdC5pbmkmcXVvdDssIE9fUkRPTkxZKSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA9IC0xIEVBQ0NFUyAoUGVybWlzc2lvbiBkZW5pZWQpPGJyPgphY2Nlc3MoJnF1b3Q7L2V0 Yy9vZGJjLmluaSZxdW90OywgRl9PSykmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSAwPGJyPnN0YXQ2NCgmcXVvdDsvZXRjL29kYmMu aW5pJnF1b3Q7LCB7c3RfbW9kZT1TX0lGUkVHfDA2NDQsIHN0X3NpemU9NTk4LCAuLi59KSA9IDA8 YnI+b3BlbigmcXVvdDsvZXRjL29kYmNpbnN0LmluaSZxdW90OywgT19SRE9OTFkpJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ID0gLTEgRUFDQ0VTIChQZXJtaXNzaW9uIGRlbmllZCk8YnI+Cjxicj5Q ZXJtaXNzaW9ucyBvZiBvZGJjLmluaSBhbmQgb2RiY2luc3QuaW5pPGJyPjxicj5yb290QGxkYXA6 L2V0YyMgbHMgb2RiYyouaW5pIC1sPGJyPgotcnctci0tci0tIDEgcm9vdCByb290IDU5OCAyMDA4 LTA1LTIzIDA4OjUwIG9kYmMuaW5pPGJyPgotcnctci0tci0tIDEgcm9vdCByb290IDU0OSAyMDA4 LTA1LTIzIDA4OjQ5IG9kYmNpbnN0LmluaTxicj48YnI+Q29udGVudHMgb2YgbXkgb2RiYy5pbmkg YW5kIG9kYmNpbnN0LmluaTo8YnI+PGJyPm9kYmMuaW5pOjxicj4tLS0tLS0tLS08YnI+W015U1FM XTxicj5EZXNjcmlwdGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9IE15U1FMIHRlc3QgZGF0 YWJhc2U8YnI+RHJpdmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gTXlTUUw8YnI+ U0VSVkVSJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gPGEgaHJlZj0iaHR0cDovLzE5 Mi4xNjguMTAwLjM4Ij4xOTIuMTY4LjEwMC4zODwvYT48YnI+ClVTRVImbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSByb290PGJyPlBBU1NXT1JEJm5ic3A7Jm5ic3A7 Jm5ic3A7ID0gKioqPGJyPlBPUlQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPSAzMzA2PGJyPkRBVEFCQVNFJm5ic3A7Jm5ic3A7Jm5ic3A7ID0ga3BsYXRzZW48YnI+ LS0tLS0tLS0tLTxicj48YnI+b2Ric2luc3QuaW5pPGJyPi0tLS0tLS0tLS08YnI+W015U1FMXTxi cj5EZXNjcmlwdGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9IE15U1FMIGRyaXZlciBmb3Ig TGludXggJmFtcDsgV2luMzI8YnI+RHJpdmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gL3Vzci9saWIvb2RiYy9saWJteW9kYmMzLnNvPGJy PgpTZXR1cCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA9IC91c3IvbGliL29kYmMvbGlibXlvZGJjM1Muc288YnI+RmlsZVVzYWdlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gMTxicj48YnI+W0RlZmF1bHRdPGJy PkRyaXZlciA9IC91c3IvbGliL29kYmMvbGlibXlvZGJjLnNvPGJyPlVzYWdlQ291bnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPSAxPGJyPi0tLS0tLS0tLS08YnI+PGJyPkkmIzM5O3ZlIHRlc3RlZCB0 aGUgT0RCQy1jb25uZWN0aW9uIHdpdGg6PGJyPgpyb290QGxkYXA6fiMgaXNxbCBNeVNRTDxicj5h bmQgaXQgd29ya3MuLi48YnI+PGJyPlBsZWFzZSBoZWxwITxicj4K --===============2091785104967173608==-- From hyc@symas.com Fri May 23 08:12:11 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5525) libldap causes a core dump due to accessing freed memory Date: Fri, 23 May 2008 08:12:10 +0000 Message-ID: <200805230812.m4N8CALQ017619@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4907803651000904080==" --===============4907803651000904080== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable paul(a)mad-scientist.us wrote: > Full_Name: Paul Smith > Version: 2.4.7 > OS: Ubuntu 8.04 > URL: > Submission from: (NULL) (65.78.30.67) > If you check ldap_free_connection() you'll see that it removes the LDAPConn > pointer "lc" from the list of connections before it is freed. > > BUT! The ldap_free_connection() function never does anything with the > ld->ld_defconn pointer, so if the connection we just freed is the one point= ed to > by ld->ld_defconn, it is now pointing to freed memory. And that causes the > problem detected above by valgrind, or causing an assert later on: accessing > freed memory. > > I'm not really sure what the right thing to do here is, or I'd provide a pa= tch. > Should we set ld_defconn to NULL? Is that ever a valid state? Or should we > just pick another connection from the list (and what if there isn't one?) A fix is now in HEAD, please test. The solution sets ld_defconn to NULL, and = also closes ld->ld_sb if necessary. In that case, ldap_send_initial_request=20 will create a new defconn before calling ldap_send_server_request. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============4907803651000904080==-- From hyc@symas.com Fri May 23 08:30:55 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5429) component Matching Date: Fri, 23 May 2008 08:30:54 +0000 Message-ID: <200805230830.m4N8UsQT018976@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0851510147504490773==" --===============0851510147504490773== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ron(a)zytrax.com wrote: > Full_Name: Ron Aitchison > Version: 2.4.8 > OS: FreeBSD (5.4/6.2) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.148.181.131) > > > Component matching (RFC 3687) is defined to be released with 2.4.8. However= it > is conditionally compiled from the variable LDAP_COMP_MATCH which is only s= et > (in servers/slapd/slap.h) if LDAP_DEVEL is set. LDAP_DEVEL is not set by de= fault > in a normal build. The net result is that component matching is not include= d in > an OpenLDAP build. It's not clear that this feature is safe for use. It's certain that indexing = for component matching in back-bdb is broken. Unindexed matching may or may=20 not work. The lead developer on this feature is gone, so until someone else=20 comes along to adopt the code it's going to remain DEVEL-only. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============0851510147504490773==-- From hyc@symas.com Fri May 23 08:57:45 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5518) Assertion error in io.c:234: ber_flush2 Date: Fri, 23 May 2008 08:57:44 +0000 Message-ID: <200805230857.m4N8viQ8020836@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8070513887385533092==" --===============8070513887385533092== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > paul(a)mad-scientist.us wrote: >> Hi all; I just posted a new bug 5525 that describes exactly how this >> happens and where the bug is. I came to this conclusion while trying to >> find a crasher in Evolution Exchange: I ran it under valgrind to find >> the use of freed memory. >> >> Hopefully this will provide us with a quick fix! > > Thanks for tracking this down Paul. I think you've nailed it for us, we sho= uld > be able to patch this pretty soon. > I replied to #5525 that a patch for this is now in HEAD. Please test. I've now closed #5525 as a dup of this bug. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8070513887385533092==-- From zulcss@ubuntu.com Fri May 23 09:02:28 2008 From: zulcss@ubuntu.com To: openldap-bugs@openldap.org Subject: (ITS#5526) Another segmentation fault Date: Fri, 23 May 2008 09:02:28 +0000 Message-ID: <200805230902.m4N92SKQ021813@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2396419184976212735==" --===============2396419184976212735== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Chuck Short Version: 3.2.7 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.142.121.161) Hello, We recieved another report of a segmentation fault in openldap 3.2.7. The bug report with the test case can be found at: http://bugs.launchpad.net/bugs/234196 If you have any questions please let me know. Thanks chuck --===============2396419184976212735==-- From zulcss@ubuntu.com Fri May 23 09:05:53 2008 From: zulcss@ubuntu.com To: openldap-bugs@openldap.org Subject: (ITS#5527) Segmentation fault in dynlist.c Date: Fri, 23 May 2008 09:05:53 +0000 Message-ID: <200805230905.m4N95r3h021950@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7885642371657733576==" --===============7885642371657733576== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Chuck Short Version: 3.2.7 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.142.121.161) Hello, We have recieved a bug report about a segmentation fault using dynlist. You c= an find the bug report at:=20 http://bugs.launchpad.net/bugs/218734 If you have any questions please feel free to ask. Thanks chuck --===============7885642371657733576==-- From mark.cave-ayland@siriusit.co.uk Fri May 23 09:16:41 2008 From: mark.cave-ayland@siriusit.co.uk To: openldap-bugs@openldap.org Subject: Re: (ITS#5506) syncprov crash with RE24 CVS Date: Fri, 23 May 2008 09:16:40 +0000 Message-ID: <200805230916.m4N9Geua022601@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1817707676286615122==" --===============1817707676286615122== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Mark Cave-Ayland wrote: > Okay. I've arranged for a set of new packages (based upon HEAD) to be > built and installed tomorrow, so will feedback on progress in a few days > after the new packages have had time to settle in. Just to feedback on this bug: we have been running packages from CVS HEAD dated 2008-05-14 on our client setup (which is basically openldap 2.4.9 plus fixes for ITS#5503 and ITS#5506), and I am pleased to report that we have had no more core files produced since the packages were installed in the middle of last week. I'm happy for this ticket to be closed, plus I would suggest closing ITS#5501, which since it hasn't occurred since, is likely to be another symptom of this bug. Thanks once again for your help, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 --===============1817707676286615122==-- From hyc@symas.com Fri May 23 13:27:21 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5506) syncprov crash with RE24 CVS Date: Fri, 23 May 2008 13:27:21 +0000 Message-ID: <200805231327.m4NDRLAP038076@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5463217715783416058==" --===============5463217715783416058== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Mark Cave-Ayland wrote: > Mark Cave-Ayland wrote: > >> Okay. I've arranged for a set of new packages (based upon HEAD) to be >> built and installed tomorrow, so will feedback on progress in a few days >> after the new packages have had time to settle in. > > Just to feedback on this bug: we have been running packages from CVS > HEAD dated 2008-05-14 on our client setup (which is basically openldap > 2.4.9 plus fixes for ITS#5503 and ITS#5506), and I am pleased to report > that we have had no more core files produced since the packages were > installed in the middle of last week. > > I'm happy for this ticket to be closed, plus I would suggest closing > ITS#5501, which since it hasn't occurred since, is likely to be another > symptom of this bug. Thanks for the followup. We'll close this and #5501 with 2.4.10. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5463217715783416058==-- From quanah@zimbra.com Fri May 23 15:09:16 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5526) Another segmentation fault Date: Fri, 23 May 2008 15:09:16 +0000 Message-ID: <200805231509.m4NF9GLg056749@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0090181980798161921==" --===============0090181980798161921== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 3.2.7 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.142.121.161) > > > Hello, > > We received another report of a segmentation fault in openldap 3.2.7. The > bug report with the test case can be found at: > > http://bugs.launchpad.net/bugs/234196 > > If you have any questions please let me know. Sure. What is OpenLDAP 3.2.7? And the bug reported here was already fixed in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before filing an ITS. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============0090181980798161921==-- From quanah@zimbra.com Fri May 23 15:11:33 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5526) Another segmentation fault Date: Fri, 23 May 2008 15:11:32 +0000 Message-ID: <200805231511.m4NFBW7C058536@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3927089928364434265==" --===============3927089928364434265== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, May 23, 2008 8:09 AM -0700 Quanah Gibson-Mount wrote: > --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote: > >> Full_Name: Chuck Short >> Version: 3.2.7 >> OS: Ubuntu >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.142.121.161) >> >> >> Hello, >> >> We received another report of a segmentation fault in openldap 3.2.7. The >> bug report with the test case can be found at: >> >> http://bugs.launchpad.net/bugs/234196 >> >> If you have any questions please let me know. > > Sure. What is OpenLDAP 3.2.7? And the bug reported here was already > fixed in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before > filing an ITS. Okay, ignore me. I was thinking of a different assertion failure fixed by 2.4.9. :P But 3.2.7 still is not a valid OpenLDAP release. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3927089928364434265==-- From hyc@symas.com Fri May 23 15:13:28 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5526) Another segmentation fault Date: Fri, 23 May 2008 15:13:28 +0000 Message-ID: <200805231513.m4NFDS0w059265@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5523705771297921307==" --===============5523705771297921307== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com wrote: > --On Friday, May 23, 2008 9:02 AM +0000 zulcss(a)ubuntu.com wrote: > >> Full_Name: Chuck Short >> Version: 3.2.7 >> OS: Ubuntu >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.142.121.161) >> >> >> Hello, >> >> We received another report of a segmentation fault in openldap 3.2.7. The >> bug report with the test case can be found at: >> >> http://bugs.launchpad.net/bugs/234196 >> >> If you have any questions please let me know. > > Sure. What is OpenLDAP 3.2.7? And the bug reported here was already fixed > in OpenLDAP 2.4.9 IIRC. Please validate bugs against 2.4.9 before filing > an ITS. Actually no, this particular bug was still present in 2.4.9. A patch is in HEAD and still needs testing. Some of the other recently filed ones were already fixed though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5523705771297921307==-- From hyc@symas.com Fri May 23 15:16:21 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5527) Segmentation fault in dynlist.c Date: Fri, 23 May 2008 15:16:21 +0000 Message-ID: <200805231516.m4NFGLcL060053@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7210591945324698704==" --===============7210591945324698704== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable zulcss(a)ubuntu.com wrote: > Full_Name: Chuck Short > Version: 3.2.7 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.142.121.161) > > > Hello, > > We have recieved a bug report about a segmentation fault using dynlist. You= can > find the bug report at: > > http://bugs.launchpad.net/bugs/218734 > > If you have any questions please feel free to ask. I was able to reproduce your crash in 2.4.7 but not in 2.4.9. This ITS will b= e=20 closed. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7210591945324698704==-- From ando@sys-net.it Sat May 24 09:18:37 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sat, 24 May 2008 09:18:36 +0000 Message-ID: <200805240918.m4O9IaD1014928@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1466515038923605094==" --===============1466515038923605094== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If objectclass B is a subclass of A, and an entry contains objectclass B > but not A, slapd returns attributeOrValueExists to a request to add A. > OTOH it allows replace(objectClass: ), and after that it allows > delete(objectClass: A). This is inconsistent. > > If the objectClass attribute contains B, does it "really" contain A as > well? I couldn't find such a statement in the RFCs, so my guess is > that add(objectClass: A) should be allowed. Though I haven't looked > all that hard. I believe the actual implementation should be... implementation dependent :), provided it is consistent. Right now, the issue you noticed is caused by the fact that the presence of the value being added is checked by using the objectClass attribute equality rule implemented in objectSubClassMatch(), which (correctly) returns a match both for exact and inherited match. However, this does not allow to discriminate the actual presence of an objectClass from its inherited presence. We should either: a) use a separate matching rule when checking for value presence, or b) always remove superior objectClasses, and transparently ignore any attempt to add them to an entry (the operation succeeds, but nothing is actually written). In any case, the code as is now seems to be inconsistent, as it does not allow a modification that should be perfectly legitimate, regardless of how it is actually dealt with by the implementation. I vote in favor of option (b). 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 --------------------------------------- --===============1466515038923605094==-- From ando@sys-net.it Sat May 24 10:19:41 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5505) Attribute value for 'modifiersName' in case of overlays Date: Sat, 24 May 2008 10:19:41 +0000 Message-ID: <200805241019.m4OAJfIm019127@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6719598062705866574==" --===============6719598062705866574== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: >> 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=' (e.g cn=Referential Integrity >> Overlay) is >> added which does not refer to an existing entry at all. > > Technically, I don't see any problem, except that overlays (and software > modules, in general) do not hold a direct reference to their config > entry's DN, if any (e.g. when back-config is not in use, the data > structure is in place, but not in LDIF form; please correct me if I'm > wrong). I wonder whether exposing such detail makes sense, or risks > breaking any security. Probably I'm getting paranoid... As a quick fix to your legitimate issue, I've added to HEAD the refint_modifiersname parameter that allows to customize the name used for internal modifications. Please test. 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 --------------------------------------- --===============6719598062705866574==-- From ando@sys-net.it Sat May 24 13:07:05 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sat, 24 May 2008 13:07:05 +0000 Message-ID: <200805241307.m4OD753A051179@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2588306713619050340==" --===============2588306713619050340== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> If objectclass B is a subclass of A, and an entry contains objectclass B >> but not A, slapd returns attributeOrValueExists to a request to add A. >> OTOH it allows replace(objectClass: ), and after that it allows >> delete(objectClass: A). This is inconsistent. >> >> If the objectClass attribute contains B, does it "really" contain A as >> well? I couldn't find such a statement in the RFCs, so my guess is >> that add(objectClass: A) should be allowed. Though I haven't looked >> all that hard. > > I believe the actual implementation should be... implementation > dependent :), provided it is consistent. Right now, the issue you > noticed is caused by the fact that the presence of the value being added > is checked by using the objectClass attribute equality rule implemented > in objectSubClassMatch(), which (correctly) returns a match both for > exact and inherited match. However, this does not allow to discriminate > the actual presence of an objectClass from its inherited presence. We > should either: > > a) use a separate matching rule when checking for value presence, or > > b) always remove superior objectClasses, and transparently ignore any > attempt to add them to an entry (the operation succeeds, but nothing is > actually written). > > In any case, the code as is now seems to be inconsistent, as it does not > allow a modification that should be perfectly legitimate, regardless of > how it is actually dealt with by the implementation. > > I vote in favor of option (b). Probably, the "right" fix requires to extend the concept of equality match, to distinguish between "match" in the sense of filtering and "match" in the sense of literal match. Something like that already occurs: see SLAP_MR_VALUE_OF_ASSERTION_SYNTAX vs. SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX. The issue right now is caused by the fact that comparing present values with the asserted one causes objectSubClassMatch() to check for match including superiors. Match functions should be able to return an indication about whether the match was literal or not, sort of a return flag indicating if the match was SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX or SLAP_MR_VALUE_OF_ASSERTION_SYNTAX. This will probably require some significant API change in the match routines, unless the related information can be safely ORed to the return value. 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 --------------------------------------- --===============2588306713619050340==-- From ando@sys-net.it Sat May 24 13:12:41 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sat, 24 May 2008 13:12:40 +0000 Message-ID: <200805241312.m4ODCerr051989@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2749731537335298921==" --===============2749731537335298921== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Full_Name: Hallvard B Furuseth >>> Version: HEAD >>> OS: Linux >>> URL:=20 >>> Submission from: (NULL) (129.240.6.233) >>> Submitted by: hallvard >>> >>> >>> If objectclass B is a subclass of A, and an entry contains objectclass B >>> but not A, slapd returns attributeOrValueExists to a request to add A. >>> OTOH it allows replace(objectClass: ), and after that it allows >>> delete(objectClass: A). This is inconsistent. >>> >>> If the objectClass attribute contains B, does it "really" contain A as >>> well? I couldn't find such a statement in the RFCs, so my guess is >>> that add(objectClass: A) should be allowed. Though I haven't looked >>> all that hard. >> I believe the actual implementation should be... implementation=20 >> dependent :), provided it is consistent. Right now, the issue you=20 >> noticed is caused by the fact that the presence of the value being added=20 >> is checked by using the objectClass attribute equality rule implemented=20 >> in objectSubClassMatch(), which (correctly) returns a match both for=20 >> exact and inherited match. However, this does not allow to discriminate=20 >> the actual presence of an objectClass from its inherited presence. We=20 >> should either: >> >> a) use a separate matching rule when checking for value presence, or >> >> b) always remove superior objectClasses, and transparently ignore any=20 >> attempt to add them to an entry (the operation succeeds, but nothing is=20 >> actually written). >> >> In any case, the code as is now seems to be inconsistent, as it does not=20 >> allow a modification that should be perfectly legitimate, regardless of=20 >> how it is actually dealt with by the implementation. >> >> I vote in favor of option (b). >=20 > Probably, the "right" fix requires to extend the concept of equality=20 > match, to distinguish between "match" in the sense of filtering and=20 > "match" in the sense of literal match. Something like that already=20 > occurs: see SLAP_MR_VALUE_OF_ASSERTION_SYNTAX vs.=20 > SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX. The issue right now is caused by the=20 > fact that comparing present values with the asserted one causes=20 > objectSubClassMatch() to check for match including superiors. Match=20 > functions should be able to return an indication about whether the match=20 > was literal or not, sort of a return flag indicating if the match was=20 > SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX or SLAP_MR_VALUE_OF_ASSERTION_SYNTAX.=20 > This will probably require some significant API change in the match=20 > routines, unless the related information can be safely ORed to the=20 > return value. Quick hack along the lines of option (a): diff -u -r1.65 mods.c --- servers/slapd/mods.c 7 Jan 2008 23:20:08 -0000 1.65 +++ servers/slapd/mods.c 24 May 2008 13:09:44 -0000 @@ -99,7 +99,13 @@ * server (whether from LDAP or from the underlying * database). */ - flags =3D SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTION_SYNTA= X; + if ( a->a_desc =3D=3D slap_schema.si_ad_objectClass ) { + /* Needed by ITS#5517 */ + flags =3D SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ATTRIBU= TE_SYNTAX; + + } else { + flags =3D SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTI= ON_SYNTAX; + } if ( mod->sm_nvalues ) { flags |=3D SLAP_MR_ASSERTED_VALUE_NORMALIZED_MATCH | SLAP_MR_ATTRIBUTE_VALUE_NORMALIZED_MATCH; 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 --------------------------------------- --===============2749731537335298921==-- From h.b.furuseth@usit.uio.no Sat May 24 21:37:57 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sat, 24 May 2008 21:37:57 +0000 Message-ID: <200805242137.m4OLbvit071435@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0074685974574811694==" --===============0074685974574811694== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ando(a)sys-net.it writes: > The issue right now is caused by the fact that comparing present > values with the asserted one causes objectSubClassMatch() to check for > match including superiors. This looks like a bug to me. objectClass has EQUALITY matching rule objectIdentifierMatch, which does not follow the object class inheritance chain. See RFC 4517 section 4.2.26. RFC 4512 section 3.3 (the 'objectClass' attribute) does not special-case this. What makes slapd work is that it also disobeys RFC 4512 section 3.3: "When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present." This doesn't say the classes shall be considered to be implicitly present, like slapd does. Instead slapd should add the missing classes to the actual object, just like it adds some other attribute/values implicitly (createTimestamp, subschemaSubentry, etc). I don't know what to do about it now though. Will replication work between current servers and servers which obeys the RFCs? Is this a RE25 fix, so we should stay with fixed like previously suggested in RE24? Or yet another thing to do with the last RE23, for the sake of replication? -- Hallvard --===============0074685974574811694==-- From h.b.furuseth@usit.uio.no Sat May 24 22:14:54 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sat, 24 May 2008 22:14:54 +0000 Message-ID: <200805242214.m4OMEsQv073018@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3426368967030079823==" --===============3426368967030079823== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no writes: > This looks like a bug to me. objectClass has EQUALITY matching rule > objectIdentifierMatch, which does not follow the object class > inheritance chain. (...) > > What makes slapd work is that it also disobeys RFC 4512 section 3.3: Oops, I meant the opposite: It's 1st bug which slapd with 2nd bug work. -- Hallvard --===============3426368967030079823==-- From Kurt@OpenLDAP.org Sun May 25 00:40:02 2008 From: Kurt@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sun, 25 May 2008 00:40:01 +0000 Message-ID: <200805250040.m4P0e19s079562@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6773726307508967386==" --===============6773726307508967386== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On May 18, 2008, at 11:09 AM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If objectclass B is a subclass of A, and an entry contains > objectclass B > but not A, slapd returns attributeOrValueExists to a request to add A. Yes, A is implicitly present (by implicit add). > OTOH it allows replace(objectClass: ), and after that it allows > delete(objectClass: A). This is inconsistent. This can be argued to be incorrect. It is improper to attempt to delete a superclass of any listed class. > If the objectClass attribute contains B, does it "really" contain A as > well? If provided by the client, yes. Otherwise A is implicitly present due to B. When a client adds B then deletes B, its a net zero result. If A were actually added by the server, the delete of B would either leave A behind or be invalid (such as when A is abstract). > I couldn't find such a statement in the RFCs, The RFCs are someone vague here. > so my guess is that add(objectClass: A) should be allowed. Adding A when a subclass is present is just as invalid as deleting A when a subclass is present. Both should result in errors. > Though I haven't looked > all that hard. > > Example: > > ldapadd -cx <<'EOF' > # Create initial object > dn: c=NO > objectClass: friendlyCountry > c: NO > co: Norway > > # error > dn: c=NO > changetype: modify > add: objectClass > objectClass: top > - > > # error > dn: c=NO > changetype: modify > add: objectClass > objectClass: country > - > > # success > dn: c=NO > changetype: modify > replace: objectClass > objectClass: top > objectClass: country > objectClass: friendlyCountry > - > > # success > dn: c=NO > changetype: modify > delete: objectClass > objectClass: top > - > > # success > dn: c=NO > changetype: modify > delete: objectClass > objectClass: country > - > EOF > > --===============6773726307508967386==-- From Kurt@OpenLDAP.org Sun May 25 00:52:33 2008 From: Kurt@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sun, 25 May 2008 00:52:33 +0000 Message-ID: <200805250052.m4P0qXP6080562@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4281386310175700141==" --===============4281386310175700141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On May 24, 2008, at 2:37 PM, h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The issue right now is caused by the fact that comparing present >> values with the asserted one causes objectSubClassMatch() to check >> for >> match including superiors. > > This looks like a bug to me. Maybe in the RFCs. > objectClass has EQUALITY matching rule > objectIdentifierMatch, which does not follow the object class > inheritance chain. Yes, but objectClass is quite special (despite being a userApplications attribute). For instance, (objectClass=*) is to match DSEs which don't have an objectClass attribute. Likewise, objectClass=foo can match objectClass attributes which don't explicitly contain foo. > See RFC 4517 section 4.2.26. RFC 4512 section 3.3 > (the 'objectClass' attribute) does not special-case this. > > What makes slapd work is that it also disobeys RFC 4512 section 3.3: > "When creating an entry or adding an 'objectClass' value to an > entry, > all superclasses of the named classes SHALL be implicitly added as > well if not already present." > This doesn't say the classes shall be considered to be implicitly > present, like slapd does. You are reading 3.3 as if it said "SHALL be added (by the server)". It doesn't say "SHALL be added (by the server). It says "SHALL be implicitly added" (presumedly by the server). This was discussed during LDAPbis discussions. As the Editor of RFC 4512, I can say that it was my intent to allow servers to merely treat superclasses as being present. > Instead slapd should add the missing classes to the actual object, Doing so is problematic. A client which adds B then deletes B would be surprised by non-net-zero result of the operation(s). > just like it adds some other attribute/values > implicitly (createTimestamp, subschemaSubentry, etc). These are operational attributes. ObjectClass is an userApplications attribute. Servers should not muck with the values of userApplication attributes. > I don't know what to do about it now though. Will replication work > between current servers and servers which obeys the RFCs? Is this a > RE25 > fix, so we should stay with fixed like previously suggested in > RE24? Or > yet another thing to do with the last RE23, for the sake of > replication? > > -- > Hallvard > > --===============4281386310175700141==-- From Kurt@OpenLDAP.org Sun May 25 00:58:54 2008 From: Kurt@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sun, 25 May 2008 00:58:54 +0000 Message-ID: <200805250058.m4P0wsDm081361@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7047497996186645743==" --===============7047497996186645743== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > I believe the actual implementation should be... implementation > dependent :), provided it is consistent. I agree there is a slight inconsistency. A client can delete a listed superclass but not add an superclass of a listed attribute. One could argue that both be considered invalid operations. However, it would be reasonable to consider an add of an unlisted superclass and a delete of a listed superclass to be valid. However, a add of an already listed class should be invalid and a delete of a unlisted class should always be invalid. -- Kurt --===============7047497996186645743==-- From ando@sys-net.it Sun May 25 15:11:34 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5517) add superclass of existing class fails Date: Sun, 25 May 2008 15:11:33 +0000 Message-ID: <200805251511.m4PFBXB5009868@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1015469257934395015==" --===============1015469257934395015== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Kurt Zeilenga wrote: > > On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > >> I believe the actual implementation should be... implementation >> dependent :), provided it is consistent. > > I agree there is a slight inconsistency. > > A client can delete a listed superclass but not add an superclass of a > listed attribute. > > One could argue that both be considered invalid operations. However, it > would be reasonable to consider an add of an unlisted superclass and a > delete of a listed superclass to be valid. However, a add of an already > listed class should be invalid and a delete of a unlisted class should > always be invalid. Agreed. With respect to the current implementation, we're back to square one, since the issue is related to using objectSubClassMatch() to check for the presence of a value. Any superclass is returned as present no matter if it is actually present or just implied. From your answers, it seems that treating objectClass specially should be the solution, and the fix I'm proposing goes in this direction. Should I commit it, or does anyone see any side effect? 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 --------------------------------------- --===============1015469257934395015==-- From ando@sys-net.it Sun May 25 16:29:00 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5521) Can't change indexing of an attribute within a single modification Date: Sun, 25 May 2008 16:29:00 +0000 Message-ID: <200805251629.m4PGT0N7013954@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5960954772658923421==" --===============5960954772658923421== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable rhafer(a)suse.de wrote: > The following modification to add an additional index an attribute fails wi= th > the error messages pasted below: >=20 > -------------------------- > dn: olcDatabase=3D{1}bdb,cn=3Dconfig > changetype: modify > delete: olcdbindex > olcDbIndex: cn pres,eq > - > add: olcdbindex > olcDbIndex: cn pres,eq,sub > -------------------------- >=20 > modifying entry "olcDatabase=3D{1}bdb,cn=3Dconfig" > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: handler exited with 1 >=20 > As far as I can see it fails because the old indexmask hat not yet been del= eted > from the bdb-struct. The ainfo_insert()-call in > back-bdb/attr.c(bdb_attr_index_config()) returns with -1. >=20 > Splitting the above modification in two separate operations works around th= at > problem. What about using replace 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 Email: pierangelo.masarati(a)sys-net.it --------------------------------------- --===============5960954772658923421==-- From pierre42d@9online.fr Sun May 25 20:14:21 2008 From: pierre42d@9online.fr To: openldap-bugs@openldap.org Subject: Re: (ITS#5244) Problem configuring openldap 2.4.6 Date: Sun, 25 May 2008 20:14:20 +0000 Message-ID: <200805252014.m4PKEKeA028681@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6863438845007262853==" --===============6863438845007262853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Ok i agree it's an enhancement request rather than a bug. I know this environment variables, but my point of view is that /usr/local should be considered part of default/standard system locations. Regards, --===============6863438845007262853==-- From pierre42d@9online.fr Sun May 25 22:59:49 2008 From: pierre42d@9online.fr To: openldap-bugs@openldap.org Subject: (ITS#5528) Problem compiling openldap 2.4.9 Date: Sun, 25 May 2008 22:59:49 +0000 Message-ID: <200805252259.m4PMxnbO033600@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8743072377395786195==" --===============8743072377395786195== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Pierre Version: 2.4.9 OS: GNU/Linux URL:=20 Submission from: (NULL) (79.82.49.83) # make Making all in /tmp/openldap-2.4.9 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.9/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.9/include' =20 Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.9/libraries' Making all in /tmp/openldap-2.4.9/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblutil' =20 Entering subdirectory liblber make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblber' =20 Entering subdirectory liblunicode make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblunicode' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblunicode' =20 Entering subdirectory libldap make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/libldap' /bin/sh ../..//libtool --mode=3Dlink gcc -s -O3 -march=3Di686=20 -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl= 2=20 -lgnutls -lcrypt -lresolv =20 gcc -s -O3 -march=3Di686 -o .libs/apitest apitest.o=20 -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so /tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.9/libraries' make: *** [all-common] Error 1 --===============8743072377395786195==-- From h.b.furuseth@usit.uio.no Sun May 25 23:02:46 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5244) Problem configuring openldap 2.4.6 Date: Sun, 25 May 2008 23:02:45 +0000 Message-ID: <200805252302.m4PN2jkA033702@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4273271068625067819==" --===============4273271068625067819== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit pierre42d(a)9online.fr writes: > Ok i agree it's an enhancement request rather than a bug. I know this > environment variables, but my point of view is that /usr/local should > be considered part of default/standard system locations. I don't think we should suddenly mess with these defaults now, but there could be an option to add them to CPPFLAGS and LDFLAGS. Or rather, add $includedir (default /usr/local/include) and $libdir (default /usr/local/lib). -- Hallvard --===============4273271068625067819==-- From ghenry@OpenLDAP.org Mon May 26 12:07:55 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5524) Additions to the Security section of the Admin Guide Date: Mon, 26 May 2008 12:07:54 +0000 Message-ID: <200805261207.m4QC7sxC075398@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2425131675045169378==" --===============2425131675045169378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.9 > OS: Linux > URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522 > Submission from: (NULL) (88.97.25.132) >=20 >=20 > This patch adds text to the Security chapter in the Admin Guide. It describ= es > the password storage schemes, including the {SASL} scheme that triggers > pass-through authentication. The latter facility has existed since version = 2.0 > but has never been mentioned in the docs, so I have included a section with= an > example of its use. >=20 >=20 I've patched security.sdf and I'm abotu to clean up some typos and=20 formating. Should we also mention that CRYPT is platform specific? Lastly, should I also put: Portions Copyright 2008 Andrew Findlay into doc/guide/COPYRIGHT ? --=20 Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============2425131675045169378==-- From rhafer@suse.de Mon May 26 12:17:04 2008 From: rhafer@suse.de To: openldap-bugs@openldap.org Subject: Re: (ITS#5521) Can't change indexing of an attribute within a single modification Date: Mon, 26 May 2008 12:17:04 +0000 Message-ID: <200805261217.m4QCH4bv076664@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0927837624683411089==" --===============0927837624683411089== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sonntag, 25. Mai 2008, Pierangelo Masarati wrote: > rhafer(a)suse.de wrote: > > The following modification to add an additional index an attribute > > fails with the error messages pasted below: > > > > -------------------------- > > dn: olcDatabase={1}bdb,cn=config > > changetype: modify > > delete: olcdbindex > > olcDbIndex: cn pres,eq > > - > > add: olcdbindex > > olcDbIndex: cn pres,eq,sub > > -------------------------- > > > > modifying entry "olcDatabase={1}bdb,cn=config" > > ldap_modify: Other (e.g., implementation specific) error (80) > > additional info: handler exited with 1 > > > > As far as I can see it fails because the old indexmask hat not yet > > been deleted from the bdb-struct. The ainfo_insert()-call in > > back-bdb/attr.c(bdb_attr_index_config()) returns with -1. > > > > Splitting the above modification in two separate operations works > > around that problem. > > What about using replace instead? That causes the same behavior as the modification pasted above. So it doesn't work as well. -- Ralf --===============0927837624683411089==-- From ghenry@OpenLDAP.org Mon May 26 12:30:46 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5524) Additions to the Security section of the Admin Guide Date: Mon, 26 May 2008 12:30:46 +0000 Message-ID: <200805261230.m4QCUk3n078156@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8264025988905249853==" --===============8264025988905249853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I've patched security.sdf and I'm abotu to clean up some typos and > formating. Hmm, maybe I should do the same to the e-mails I write ;-) --===============8264025988905249853==-- From ando@sys-net.it Mon May 26 14:18:59 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5521) Can't change indexing of an attribute within a single modification Date: Mon, 26 May 2008 14:18:58 +0000 Message-ID: <200805261418.m4QEIwd7084358@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7534054546835170077==" --===============7534054546835170077== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit rhafer(a)suse.de wrote: >>> Splitting the above modification in two separate operations works >>> around that problem. >> What about using replace instead? > That causes the same behavior as the modification pasted above. So it > doesn't work as well. Also, it might not be very practical if very complex indexing is in place... 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 --------------------------------------- --===============7534054546835170077==-- From rhafer@suse.de Mon May 26 15:40:16 2008 From: rhafer@suse.de To: openldap-bugs@openldap.org Subject: Re: (ITS#5521) Can't change indexing of an attribute within a single modification Date: Mon, 26 May 2008 15:40:15 +0000 Message-ID: <200805261540.m4QFeF6c092274@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6505269030966023925==" --===============6505269030966023925== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Montag, 26. Mai 2008, ando(a)sys-net.it wrote: > rhafer(a)suse.de wrote: > >>> Splitting the above modification in two separate operations works > >>> around that problem. > >> > >> What about using replace instead? > > > > That causes the same behavior as the modification pasted above. So > > it doesn't work as well. > > Also, it might not be very practical if very complex indexing is in > place... Yes. But I think I fixed the original issue now. (r1.39 of servers/slapd/back-bdb/attr.c) -- Ralf --===============6505269030966023925==-- From h.b.furuseth@usit.uio.no Mon May 26 17:27:46 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: (ITS#5529) test048-syncrepl-multiproxy --without-threads hangs Date: Mon, 26 May 2008 17:27:46 +0000 Message-ID: <200805261727.m4QHRkgY096006@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8263794222393991991==" --===============8263794222393991991== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080526.tgz.1 Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g' $ ./run test048 Cleaning up test run directory leftover from previous run. Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... gdb shows both slapd and ldapsearch waiting in poll(). testrun with backtraces enclosed. Ignore the Hallvard-Furuseth-080526.tgz (without .1) file; ftp created it but did not let me upload it. Needed passive mode to upload. --===============8263794222393991991==-- From mike@tedder.cc Mon May 26 17:50:24 2008 From: mike@tedder.cc To: openldap-bugs@openldap.org Subject: (ITS#5530) OpenLDAP fails to compile Date: Mon, 26 May 2008 17:50:23 +0000 Message-ID: <200805261750.m4QHoNGC097431@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5384820346225596296==" --===============5384820346225596296== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Mike Tedder Version: 2.4.9 OS: powerpc-linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.170.158.22) The back-bdb backend for the OpenLDAP slapd server fails to compile when being built using Berkeley DB 4.7: cd back-bdb; make -w all make[3]: Entering directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd/back-bdb' rm -f version.c ../../../build/mkversion -v "2.4.9" back_bdb > version.c /bin/sh ../../..//libtool --tag=3Ddisable-shared --mode=3Dcompile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c init.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c init.c -o init.o init.c: In function `bdb_db_open': init.c:509: error: structure has no member named `lk_handle' init.c: In function `bdb_back_initialize': init.c:752: warning: passing arg 1 of `db_env_set_func_yield' from incompatib= le pointer type make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/mnt/home/bpoint/src/openldap-2.4.9/servers' make: *** [all-common] Error 1 The reason for this error is because there is no longer a "lk_handle" member inside the DB_ENV structure in /usr/include/db.h. I checked the mailing list archives, and there's not a sign of anyone having this compile error anywhere. I also checked the HEAD revision in CVS, and init.c still uses the lk_handle member variable. I guess no one's upgraded to Berkeley 4.7 yet...? :) To work around the compile error, I have changed: #if DB_VERSION_FULL >=3D 0x04060012 ...to... #if 0 && DB_VERSION_FULL >=3D 0x04060012 in all places in init.c and cache.c (the only two files affected), and slapd compiles successfully. I'm not sure if this is the proper way to fix it or n= ot, however... --===============5384820346225596296==-- From ando@sys-net.it Mon May 26 18:15:06 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5530) OpenLDAP fails to compile Date: Mon, 26 May 2008 18:15:05 +0000 Message-ID: <200805261815.m4QIF5hK098677@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2106798027932095362==" --===============2106798027932095362== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable mike(a)tedder.cc wrote: > The back-bdb backend for the OpenLDAP slapd server fails to compile when be= ing > built using Berkeley DB 4.7: Berkeley DB 4.7 is not supported (yet). 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 --------------------------------------- --===============2106798027932095362==-- From rra@stanford.edu Mon May 26 18:20:46 2008 From: rra@stanford.edu To: openldap-bugs@openldap.org Subject: Re: (ITS#5528) Problem compiling openldap 2.4.9 Date: Mon, 26 May 2008 18:20:45 +0000 Message-ID: <200805261820.m4QIKjn0099546@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0861175945424330772==" --===============0861175945424330772== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable pierre42d(a)9online.fr writes: > /bin/sh ../..//libtool --mode=3Dlink gcc -s -O3 -march=3Di686=20 > -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la > ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsa= sl2=20 > -lgnutls -lcrypt -lresolv =20 > gcc -s -O3 -march=3Di686 -o .libs/apitest apitest.o=20 > -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so > /tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib > ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a > /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so > /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap > /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv > ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' What version of GnuTLS do you have installed? I wonder if the one you have is too old. --=20 Russ Allbery (rra(a)stanford.edu) --===============0861175945424330772==-- From ando@sys-net.it Mon May 26 18:20:54 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5529) test048-syncrepl-multiproxy --without-threads hangs Date: Mon, 26 May 2008 18:20:53 +0000 Message-ID: <200805261820.m4QIKr7A099764@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6029730952299761581==" --===============6029730952299761581== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080526.tgz.1 > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=-O0 -g' > > $ ./run test048 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test048-syncrepl-multiproxy... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > > gdb shows both slapd and ldapsearch waiting in poll(). > testrun with backtraces enclosed. Probably, sync replication should not be allowed when building --without-threads. 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 --------------------------------------- --===============6029730952299761581==-- From mike@tedder.cc Mon May 26 18:23:20 2008 From: mike@tedder.cc To: openldap-bugs@openldap.org Subject: Re: (ITS#5530) OpenLDAP fails to compile Date: Mon, 26 May 2008 18:23:20 +0000 Message-ID: <200805261823.m4QINKNK001034@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8553863453775634336==" --===============8553863453775634336== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 27 May 2008 03:15:09 +0900, Pierangelo Masarati wrote: > mike(a)tedder.cc wrote: > >> The back-bdb backend for the OpenLDAP slapd server fails to compile >> when being >> built using Berkeley DB 4.7: > > Berkeley DB 4.7 is not supported (yet). That would explain why. :) I will downgrade to 4.6.21. Thanks for the quick response! --===============8553863453775634336==-- From rra@debian.org Mon May 26 18:41:20 2008 From: rra@debian.org To: openldap-bugs@openldap.org Subject: (ITS#5531) Use MAXPATHLEN, not PATH_MAX Date: Mon, 26 May 2008 18:41:19 +0000 Message-ID: <200805261841.m4QIfJ3B001634@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7146048364643526825==" --===============7146048364643526825== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Russ Allbery Version: 2.4.9 OS: Debian GNU/Linux URL:=20 Submission from: (NULL) (171.66.157.16) servers/slapd/back-bdb/monitor.c uses PATH_MAX rather than MAXPATHLEN. GNU H= urd doesn't have PATH_MAX. OpenLDAP defines MAXPATHLEN portably, so that should = be used instead. Here is the trivial patch: --- openldap.orig/servers/slapd/back-bdb/monitor.c +++ openldap/servers/slapd/back-bdb/monitor.c @@ -395,7 +395,7 @@ { struct berval bv, nbv; ber_len_t pathlen =3D 0, len =3D 0; - char path[ PATH_MAX ] =3D { '\0' }; + char path[ MAXPATHLEN ] =3D { '\0' }; char *fname =3D bdb->bi_dbenv_home, *ptr; This is http://bugs.debian.org/475744 --===============7146048364643526825==-- From ando@sys-net.it Mon May 26 18:57:27 2008 From: ando@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5531) Use MAXPATHLEN, not PATH_MAX Date: Mon, 26 May 2008 18:57:27 +0000 Message-ID: <200805261857.m4QIvRmR005509@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0285131513595913326==" --===============0285131513595913326== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable rra(a)debian.org wrote: > servers/slapd/back-bdb/monitor.c uses PATH_MAX rather than MAXPATHLEN. GNU= Hurd > doesn't have PATH_MAX. OpenLDAP defines MAXPATHLEN portably, so that shoul= d be > used instead. Here is the trivial patch: That portion of code was moved to back-bdb from back-monitor/database.c,=20 where PATH_MAX was (naively) redefined. Thanks for spotting it. It is=20 now fixed in HEAD, re24 and re23. 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 --------------------------------------- --===============0285131513595913326==-- From andrew.findlay@skills-1st.co.uk Mon May 26 19:48:19 2008 From: andrew.findlay@skills-1st.co.uk To: openldap-bugs@openldap.org Subject: Re: (ITS#5524) Additions to the Security section of the Admin Guide Date: Mon, 26 May 2008 19:48:18 +0000 Message-ID: <200805261948.m4QJmIr2008854@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3191389975790547473==" --===============3191389975790547473== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: > I've patched security.sdf and I'm abotu to clean up some typos and > formating. Thanks. > Should we also mention that CRYPT is platform specific? I put in a note about the glibc2 version, but I was not aware of any platform oddities on the traditional 13-character version. Are there other MD5 variants? We could also mention the LANMAN scheme which I forgot to include as it is a compile-time option. > Lastly, should I also put: > > Portions Copyright 2008 Andrew Findlay > > into doc/guide/COPYRIGHT ? Yes please. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- --===============3191389975790547473==-- From ghenry@OpenLDAP.org Mon May 26 20:37:55 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5524) Additions to the Security section of the Admin Guide Date: Mon, 26 May 2008 20:37:55 +0000 Message-ID: <200805262037.m4QKbtCD011774@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5991895188521238080==" --===============5991895188521238080== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: > >> I've patched security.sdf and I'm abotu to clean up some typos and >> formating. > > Thanks. > >> Should we also mention that CRYPT is platform specific? > > I put in a note about the glibc2 version, but I was not aware of any > platform oddities on the traditional 13-character version. Are there > other MD5 variants? See http://www.openldap.org/faq/index.cgi?_highlightWords=crypt&file=344 > > We could also mention the LANMAN scheme which I forgot to include as > it is a compile-time option. Sure, could do. > >> Lastly, should I also put: >> >> Portions Copyright 2008 Andrew Findlay >> >> into doc/guide/COPYRIGHT ? > > Yes please. Done. Check in HEAD -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ --===============5991895188521238080==-- From hyc@symas.com Tue May 27 05:10:27 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5530) OpenLDAP fails to compile Date: Tue, 27 May 2008 05:10:27 +0000 Message-ID: <200805270510.m4R5ARKq042581@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5451837353934108950==" --===============5451837353934108950== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable mike(a)tedder.cc wrote: > Full_Name: Mike Tedder > Version: 2.4.9 > OS: powerpc-linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.170.158.22) > > > The back-bdb backend for the OpenLDAP slapd server fails to compile when be= ing > built using Berkeley DB 4.7: This was already reported in ITS#5523. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5451837353934108950==-- From hai.zhao@gmail.com Tue May 27 10:10:13 2008 From: hai.zhao@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5532) incorrect timestamp of slapd replica log Date: Tue, 27 May 2008 10:10:13 +0000 Message-ID: <200805271010.m4RAADtR079025@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1719907435595076995==" --===============1719907435595076995== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Zhao Hai Version: 2.3.41 OS: Linux 2.4.21 arm URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch Submission from: (NULL) (205.209.140.4) Problem: race condition makes incorrect timestamp in replogfile, cause certain modification of entries not replicate to slurp slaves. replica: 180.0.10.2:1234 replica: 180.0.10.3:1234 time: 1211855467 ^^^^^^^^^^ this timestamp How to reproduce the problem: 1) run under very slow machines (my environ: arm 266MHz) 2) slapd is configed to generate replogfile 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. Patch: Please look the attached patch. It works for me. --===============1719907435595076995==-- From Kurt@OpenLDAP.org Tue May 27 17:04:19 2008 From: Kurt@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5524) Additions to the Security section of the Admin Guide Date: Tue, 27 May 2008 17:04:19 +0000 Message-ID: <200805271704.m4RH4JqS030111@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2708604382965963392==" --===============2708604382965963392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On May 26, 2008, at 12:48 PM, andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: > >> I've patched security.sdf and I'm abotu to clean up some typos and >> formating. > > Thanks. > >> Should we also mention that CRYPT is platform specific? > > I put in a note about the glibc2 version, but I was not aware of any > platform oddities on the traditional 13-character version. Are there > other MD5 variants? > > We could also mention the LANMAN scheme which I forgot to include as > it is a compile-time option. > >> Lastly, should I also put: >> >> Portions Copyright 2008 Andrew Findlay > > >> >> into doc/guide/COPYRIGHT ? No. This file is a copy of the main OpenLDAP Software COPYRIGHT file. That file is intended to contain notices of copyright holders which hold signfiicant rights in OpenLDAP Software. Notices for copyright holders, as noted in the COPYRIGHT file, are generally to be placed in the individual source files which the holder holds significant rights in. That is, this notice belongs in security.sdf itself. I have so updated the source documents. Though the preface does clearly say that admin guide is part of OpenLDAP Software, I've also updated the preface to note that portions of the document may be copyright by others as indicated in source files. -- Kurt --===============2708604382965963392==-- From h.b.furuseth@usit.uio.no Tue May 27 18:27:22 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5529) test048-syncrepl-multiproxy --without-threads hangs Date: Tue, 27 May 2008 18:27:21 +0000 Message-ID: <200805271827.m4RIRLDb034710@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7682573379864613226==" --===============7682573379864613226== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ando(a)sys-net.it writes: >h.b.furuseth(a)usit.uio.no wrote: >> RE24 configured with --quiet --without-threads --enable-ldap 'CFLAGS=3D-O0= -g' Sorry, that's RE24 + the ITS#5519 (--without-thread miscompiles) patch: cvs diff -r1.34 -r1.35 -I'[$]OpenLDAP[$:]' libraries/libldap_r/thr_stub.c > Probably, sync replication should not be allowed when building > --without-threads. Or there could be a warning that --without-threads breaks some features. Looking closer I see the server replicates from itself in this test. I can see how that'd be a problem in single-threaded mode... Most other syncrepl tests succeed. Though test050 crashes: daemon.c:979: slapd_set_read: Assertion `((slap_daemon.sd_index[(s)]) !=3D = -1)' failed. (Argh, it refuses to dump core for some reason. I've done ulimit -c unlimited and put it in defines.sh too.) --=20 Hallvard --===============7682573379864613226==-- From ghenry@OpenLDAP.org Tue May 27 18:52:40 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5524) Additions to the Security section of the Admin Guide Date: Tue, 27 May 2008 18:52:40 +0000 Message-ID: <200805271852.m4RIqelJ036584@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4467345022653049751==" --===============4467345022653049751== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > On May 26, 2008, at 12:48 PM, andrew.findlay(a)skills-1st.co.uk wrote: > >> On Mon, May 26, 2008 at 01:07:22PM +0100, Gavin Henry wrote: >> >>> I've patched security.sdf and I'm abotu to clean up some typos and >>> formating. >> >> Thanks. >> >>> Should we also mention that CRYPT is platform specific? >> >> I put in a note about the glibc2 version, but I was not aware of any >> platform oddities on the traditional 13-character version. Are there >> other MD5 variants? >> >> We could also mention the LANMAN scheme which I forgot to include as >> it is a compile-time option. >> >>> Lastly, should I also put: >>> >>> Portions Copyright 2008 Andrew Findlay >> > >>> >>> into doc/guide/COPYRIGHT ? > > No. > > This file is a copy of the main OpenLDAP Software COPYRIGHT file. > That file is intended to contain notices of copyright holders which > hold signfiicant rights in OpenLDAP Software. Notices for copyright > holders, as noted in the COPYRIGHT file, are generally to be placed in > the individual source files which the holder holds significant rights > in. That is, this notice belongs in security.sdf itself. I have so > updated the source documents. Good, this clears things up and make it clear going forward. Thanks. > Though the preface does clearly say that admin guide is part of > OpenLDAP Software, I've also updated the preface to note that portions > of the document may be copyright by others as indicated in source files. Thanks again. --===============4467345022653049751==-- From h.b.furuseth@usit.uio.no Tue May 27 20:05:47 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: (ITS#5533) test035-meta crashes --without-threads Date: Tue, 27 May 2008 20:05:46 +0000 Message-ID: <200805272005.m4RK5kGO041268@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5625494331920549231==" --===============5625494331920549231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Hallvard B Furuseth Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080527.tgz.1 Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd crashes in test035 after 10 runs: daemon.c:979: assert( SLAP_SOCK_IS_ACTIVE( s )); RE24 + libraries/libldap_r/thr_stub.c rev 1.35 ./configure --quiet --without-threads --enable-meta --enable-ldap 'CFLAGS=-O0 -g' (declare -i n=0; while n=n+1 && echo "run #$n" && ./run test035; do sleep 5; done) Testrun directory enclosed, with files OUTPUT (from tty) and slapd.*.GDB. Removed database directories though. (Argh, I messed up with passive mode again. Oh well.) --===============5625494331920549231==-- From quanah@zimbra.com Tue May 27 20:11:08 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5533) test035-meta crashes --without-threads Date: Tue, 27 May 2008 20:11:07 +0000 Message-ID: <200805272011.m4RKB7L2043142@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2542100165866817959==" --===============2542100165866817959== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, May 27, 2008 8:05 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080527.tgz.1 > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > Isn't this just a duplicate of ITS#5489? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2542100165866817959==-- From h.b.furuseth@usit.uio.no Tue May 27 21:03:05 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5533) test035-meta crashes --without-threads Date: Tue, 27 May 2008 21:03:05 +0000 Message-ID: <200805272103.m4RL35XV049549@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1235194639183933375==" --===============1235194639183933375== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit quanah(a)zimbra.com writes: > Isn't this just a duplicate of ITS#5489? Apparently not. Got it again at 4th run with daemon.c 1.380.2.12. Also in a somewhat patched HEAD with the same configuration. Hm, the crashes happen for extended operations. So far 6 times "Passwd ExOp failed (1)!", once "WhoAmI failed (49)!". -- Hallvard --===============1235194639183933375==-- From hyc@symas.com Tue May 27 23:25:12 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5318) response msgid <= 0 mishandled in libldap Date: Tue, 27 May 2008 23:25:11 +0000 Message-ID: <200805272325.m4RNPBow064819@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8320452758475475600==" --===============8320452758475475600== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > libraries/libldap/result.c:try_read1msg() accesses 'lr' uninitialized > if 'id' (message ID) from line 577's 'ber_get_int( ber,&id )' is<= 0. > > I'm not sure if the client should terminate the connection when it > receives message id< 0, or if it should just toss the response like > it does with unknown message IDs. RFC4511 isn't really explicit here, although it does say that the connection should be dropped for unparsable messages. Anyway, I've patched HEAD to toss the messages for now. > With message ID 0, the code reaches this statement with 'lr' uninitialized: > Debug( LDAP_DEBUG_TRACE, > "read1msg: ld %p msgid %ld message type %s\n", > (void *)ld, (long)lr->lr_msgid, ldap_int_msgtype2str( tag ) ); > As far as I can tell, normally lr->lr_msgid == id. I haven't tracked what > those values are with LDAP_CONNECTIONLESS at the 'nextresp2:' label. For CONNECTIONLESS, it can only jump back there because there were multiple responses to the current request. So the lr is the same as for the first response. No problem there. (Remember this is all within a single datagram. Responses to multiple different requests cannot be interleaved at this point.) > A 700-line function with 5 labels, yuck. > Anyway, I wonder why taht statement and the statement below: > if ( id == 0 ) { > doesn't use the same value, either id or lr->lr_msgid for both. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8320452758475475600==-- From abartlet@samba.org Wed May 28 00:39:11 2008 From: abartlet@samba.org To: openldap-bugs@openldap.org Subject: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Wed, 28 May 2008 00:39:10 +0000 Message-ID: <200805280039.m4S0dABl088350@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5199947554557478680==" --===============5199947554557478680== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: http://www.openldap.org/lists/openldap-technical/200803/msg00101.html Submission from: (NULL) (59.167.251.137) For Samba4, I need a few things, detailed in the attached URL. This ITS is for internal transactions and validation - the ability to have a openldap overlay roll back all the changes so far, because a precondition is = not met. I need the memberOf and refint modules to ensure that no dangling links ever exist, even over subtree renames and invalid modifies, and that a transaction ensures this is always the case.=20 This needs to occur even between databases on the server, but I won't ask that it occur outside the known trees.=20 --===============5199947554557478680==-- From hyc@symas.com Wed May 28 01:22:30 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Wed, 28 May 2008 01:22:29 +0000 Message-ID: <200805280122.m4S1MTLW002156@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7755595244401000473==" --===============7755595244401000473== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 9 > URL: http://www.openldap.org/lists/openldap-technical/200803/msg00101.html > Submission from: (NULL) (59.167.251.137) > > > For Samba4, I need a few things, detailed in the attached URL. The above message thread had some unanswered questions. We may need to have=20 each point listed out again. > This ITS is for internal transactions and validation - the ability to have a > openldap overlay roll back all the changes so far, because a precondition i= s not > met. I think this one is understood, OK. Just a matter of getting the time to do i= t. > I need the memberOf and refint modules to ensure that no dangling links ever > exist, even over subtree renames and invalid modifies, and that a transacti= on > ensures this is always the case. I think the proper use of memberOf still needs to be addressed. E.g., it's=20 generally a bad idea to search for (memberOf=3Dfoo) when you can simply=20 enumerate the members inside the "foo" entry. If you give us precise examples= =20 of the searches and modifications that you'll be using, we may be able to=20 narrow the scope of this work. > This needs to occur even between databases on the server, but I won't ask t= hat > it occur outside the known trees. It's already possible for operations in one database to reference entries in = a=20 different database, so that aspect of validation should be fine. However, as = noted before, "validation" is generally bogus to begin with. In particular,=20 how do you create entries with circular references? If you disallow reference= s=20 to nonexistent entries, you can't set the references until after all of the=20 entries have been created. This means that you cannot backup a database that = has these references and then later reload it in a single pass. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7755595244401000473==-- From abartlet@samba.org Wed May 28 01:31:33 2008 From: abartlet@samba.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Wed, 28 May 2008 01:31:32 +0000 Message-ID: <200805280131.m4S1VWMe005464@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7256598207125039053==" --===============7256598207125039053== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --=-I6d9E5fOqbwKcJhhvz+z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 9 > > URL: http://www.openldap.org/lists/openldap-technical/200803/msg00101.h= tml > > Submission from: (NULL) (59.167.251.137) > > > > > > For Samba4, I need a few things, detailed in the attached URL. >=20 > The above message thread had some unanswered questions. We may need to ha= ve=20 > each point listed out again. >=20 > > This ITS is for internal transactions and validation - the ability to h= ave a > > openldap overlay roll back all the changes so far, because a preconditi= on is not > > met. >=20 > I think this one is understood, OK. Just a matter of getting the time to = do it. >=20 > > I need the memberOf and refint modules to ensure that no dangling links= ever > > exist, even over subtree renames and invalid modifies, and that a trans= action > > ensures this is always the case. >=20 > I think the proper use of memberOf still needs to be addressed. E.g., it'= s=20 > generally a bad idea to search for (memberOf=3Dfoo) when you can simply=20 > enumerate the members inside the "foo" entry. If you give us precise exam= ples=20 > of the searches and modifications that you'll be using, we may be able to= =20 > narrow the scope of this work. I'll be passing on any search that a windows client makes, and trying to return the same result a windows server would return. Bad ideas still have to be implemented in my world :-( > > This needs to occur even between databases on the server, but I won't a= sk that > > it occur outside the known trees. >=20 > It's already possible for operations in one database to reference entries= in a=20 > different database, so that aspect of validation should be fine. However,= as=20 > noted before, "validation" is generally bogus to begin with. In particula= r,=20 > how do you create entries with circular references? If you disallow refer= ences=20 > to nonexistent entries, you can't set the references until after all of t= he=20 > entries have been created. This means that you cannot backup a database t= hat=20 > has these references and then later reload it in a single pass. An interesting point, but I need to match the windows runtime behaviour.=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-I6d9E5fOqbwKcJhhvz+z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIPLXqz4A8Wyi0NrsRArp6AJ9OaJP8Cu4MdO69n1k1S8vlBjtPOACdHvDh t0XbDQzXaJya2LR/bhl1RlQ= =/FnH -----END PGP SIGNATURE----- --=-I6d9E5fOqbwKcJhhvz+z-- --===============7256598207125039053==-- From hyc@symas.com Wed May 28 01:43:23 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Wed, 28 May 2008 01:43:22 +0000 Message-ID: <200805280143.m4S1hME0009350@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6226016004471658449==" --===============6226016004471658449== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andrew Bartlett wrote: > On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: >>> This needs to occur even between databases on the server, but I won't ask= that >>> it occur outside the known trees. >> It's already possible for operations in one database to reference entries = in a >> different database, so that aspect of validation should be fine. However, = as >> noted before, "validation" is generally bogus to begin with. In particular, >> how do you create entries with circular references? If you disallow refere= nces >> to nonexistent entries, you can't set the references until after all of the >> entries have been created. This means that you cannot backup a database th= at >> has these references and then later reload it in a single pass. > > An interesting point, but I need to match the windows runtime > behaviour. Only when it has a visible impact on other clients. What software will break = if the directory allows you to add new entries that contain dangling=20 references? What will break if the directory allows you to modify a reference= =20 attribute to point to a nonexistent entry? There's a lot of Windows behavior that is clearly wrong, by any number of=20 metrics. You need to be a bit more selective in prioritizing the list of=20 things to chase down. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6226016004471658449==-- From abartlet@samba.org Wed May 28 02:28:09 2008 From: abartlet@samba.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Wed, 28 May 2008 02:28:09 +0000 Message-ID: <200805280228.m4S2S9nN018281@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5745321044289298171==" --===============5745321044289298171== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --=-s2sha8beM9nUssvA07HS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-05-27 at 18:43 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: >=20 > >>> This needs to occur even between databases on the server, but I won't= ask that > >>> it occur outside the known trees. > >> It's already possible for operations in one database to reference entr= ies in a > >> different database, so that aspect of validation should be fine. Howev= er, as > >> noted before, "validation" is generally bogus to begin with. In partic= ular, > >> how do you create entries with circular references? If you disallow re= ferences > >> to nonexistent entries, you can't set the references until after all o= f the > >> entries have been created. This means that you cannot backup a databas= e that > >> has these references and then later reload it in a single pass. > > > > An interesting point, but I need to match the windows runtime > > behaviour. >=20 > Only when it has a visible impact on other clients. What software will br= eak=20 > if the directory allows you to add new entries that contain dangling=20 > references? What will break if the directory allows you to modify a refer= ence=20 > attribute to point to a nonexistent entry? Sure, I'm not asking for a change to default behaviours. I'm listing the things that our testsuite finds are differences, and looking for solutions.=20 > There's a lot of Windows behavior that is clearly wrong, by any number of= =20 > metrics. You need to be a bit more selective in prioritizing the list of=20 > things to chase down. This is the currently the top priority for an LDAP Backend for Samba4. =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-s2sha8beM9nUssvA07HS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIPMMwz4A8Wyi0NrsRAljCAJsEsn1tsq4BdkdenNOEOF3PIGcDDACfVoUR APoU1kbv2ljwVBgjyhPbyGQ= =mXBr -----END PGP SIGNATURE----- --=-s2sha8beM9nUssvA07HS-- --===============5745321044289298171==-- From Guillaume.Rousse@inria.fr Wed May 28 14:07:39 2008 From: Guillaume.Rousse@inria.fr To: openldap-bugs@openldap.org Subject: (ITS#5535) smbk5pwd uses private heimdal functions Date: Wed, 28 May 2008 14:07:38 +0000 Message-ID: <200805281407.m4SE7cZC050548@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5547214827076633565==" --===============5547214827076633565== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Guillaume Rousse Version: 2.4.8 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) smbk5pwd uses two private heimdal functions: _kadm5_set_keys _kadm5_free_keys As of heimdal 1.1, those functions are not exported anymore. As a consequence, opendalp crashes as soon as I try to change password when the overlay is activated. According to heimdal maintainers, smb5pwd should rather use hdb_generate_key_set_password and hdb_free_keys to generate the key data. I tried to produce a patch myself (available at http://www.zarb.org/~guillomovitch/openldap-smbk5pwd-2.4.8-dont-use-internal-= functions.patch) by inlining _kadm5_set_keys function directly in smbk5pwd, but I don't know h= ow to deal with members of private kadm_context structure. --===============5547214827076633565==-- From hyc@symas.com Wed May 28 15:14:27 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Wed, 28 May 2008 15:14:27 +0000 Message-ID: <200805281514.m4SFERIk069175@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8266017340636638432==" --===============8266017340636638432== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andrew Bartlett wrote: > On Tue, 2008-05-27 at 18:43 -0700, Howard Chu wrote: >> Andrew Bartlett wrote: >>> On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: >>>>> This needs to occur even between databases on the server, but I won't a= sk that >>>>> it occur outside the known trees. >>>> It's already possible for operations in one database to reference entrie= s in a >>>> different database, so that aspect of validation should be fine. However= , as >>>> noted before, "validation" is generally bogus to begin with. In particul= ar, >>>> how do you create entries with circular references? If you disallow refe= rences >>>> to nonexistent entries, you can't set the references until after all of = the >>>> entries have been created. This means that you cannot backup a database = that >>>> has these references and then later reload it in a single pass. >>> An interesting point, but I need to match the windows runtime >>> behaviour. >> Only when it has a visible impact on other clients. What software will bre= ak >> if the directory allows you to add new entries that contain dangling >> references? What will break if the directory allows you to modify a refere= nce >> attribute to point to a nonexistent entry? > > Sure, I'm not asking for a change to default behaviours. I'm listing > the things that our testsuite finds are differences, and looking for > solutions. I don't believe your proposed solution will ever be satisfactory. Entries wit= h=20 circular references will also break syncrepl Refresh if the constraint you're= =20 asking for is enforced. That will clearly have visible impact in many=20 deployments. If the only thing that complains with the current behavior is=20 your testsuite and not any real world clients, I suggest you just note the=20 difference and move on. >> There's a lot of Windows behavior that is clearly wrong, by any number of >> metrics. You need to be a bit more selective in prioritizing the list of >> things to chase down. > > This is the currently the top priority for an LDAP Backend for Samba4. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8266017340636638432==-- From quanah@zimbra.com Wed May 28 17:31:56 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5532) incorrect timestamp of slapd replica log Date: Wed, 28 May 2008 17:31:55 +0000 Message-ID: <200805281731.m4SHVtnc087855@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2137601645221394675==" --===============2137601645221394675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, May 27, 2008 10:10 AM +0000 hai.zhao(a)gmail.com wrote: > Full_Name: Zhao Hai > Version: 2.3.41 > OS: Linux 2.4.21 arm > URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch > Submission from: (NULL) (205.209.140.4) > > > Problem: > race condition makes incorrect timestamp in replogfile, cause certain > modification of entries not replicate to slurp slaves. > > replica: 180.0.10.2:1234 > replica: 180.0.10.3:1234 > time: 1211855467 > ^^^^^^^^^^ this timestamp > > How to reproduce the problem: > 1) run under very slow machines (my environ: arm 266MHz) > 2) slapd is configed to generate replogfile > 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. This is fixed in RE23. If there is ever a 2.3.43 release, it will be in that. In the meantime, I'd advise using 2.3.42 + your patch. Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============2137601645221394675==-- From rein@OpenLDAP.org Wed May 28 18:51:28 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Wed, 28 May 2008 18:51:28 +0000 Message-ID: <200805281851.m4SIpST2097609@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1555198727875880247==" --===============1555198727875880247== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/rein-serverID.patch Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl includes the serverID in the syncCookie in multi-master mode only, b= ut there are other configuration that would benefit from it as well. A case I have is where a consumer replicates a glue'ed database, with the exception of one subordinate backend where the consumer is the master. The subordinate backend is replicated back to the master of the glue'ed database.= =20 With the current code the master would send the content of the subordinate db back to its master. I currently solve this problem with acl rules on the glue'ed master that prevents the slave from reading the subordinate db it is master for. Differe= nt rootdn's on the glue and subordinate db on the slave prevents syncrepl from succeeding in its attempts to remove the content of the subordinate db during the present phase. But it felt like I got a minor heartache the first time a saw the log of delete messages scroll by before I realized they were all error messages... A patch that fixes this is at the referenced URL. As I am not sure of the consequences if a defaulted serverID=3D0 value was included in the syncCookie= the patch changes the internal default slap_serverID value to -1 to make it possi= ble to differentiate between a configured and defaulted serverID=3D0. Btw, there are potential problems with using serverID=3D0, so it would be bes= t if that value was reserved for the default unconfigured case. I.e, a default serverID=3D0 value could be chosen be slapadd when the two-argument form of serverID is used in the config, as resolving the URL needs the listener argum= ent to slapd to succeed. Enforcing serverID>0 could require changes in existing configurations, but indicating it in the doc. could be a first step? Rein Tollevik Basefarm AS --===============1555198727875880247==-- From hyc@symas.com Wed May 28 19:12:19 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Wed, 28 May 2008 19:12:19 +0000 Message-ID: <200805281912.m4SJCJ7F002455@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6895075019821714960==" --===============6895075019821714960== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: ftp://ftp.openldap.org/incoming/rein-serverID.patch > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl includes the serverID in the syncCookie in multi-master mode only,= but > there are other configuration that would benefit from it as well. > > A case I have is where a consumer replicates a glue'ed database, with the > exception of one subordinate backend where the consumer is the master. The > subordinate backend is replicated back to the master of the glue'ed databas= e. > With the current code the master would send the content of the subordinate = db > back to its master. Understood. In fact, having multiple sources of data in a glued tree is reall= y=20 a form of multi-master. (The separate glued branches cannot cause=20 inconsistencies with each other, but still their contextCSNs must be managed = individually.) > A patch that fixes this is at the referenced URL. As I am not sure of the > consequences if a defaulted serverID=3D0 value was included in the syncCook= ie the > patch changes the internal default slap_serverID value to -1 to make it pos= sible > to differentiate between a configured and defaulted serverID=3D0. > Btw, there are potential problems with using serverID=3D0, so it would be b= est if > that value was reserved for the default unconfigured case. I.e, a default > serverID=3D0 value could be chosen be slapadd when the two-argument form of > serverID is used in the config, as resolving the URL needs the listener arg= ument > to slapd to succeed. You mean the three-argument form? The two-argument form only allows a single = serverID to be configured anyway, so there is no ambiguity there. But you're = right, in tool mode when multiple serverIDs are configured, there's no way fo= r=20 it to choose the right serverID. That's a problem regardless of whether the=20 default is 0 or -1 though. For now I think this is a doc issue; we could simply recommend that slapadd=20 always be performed on the node with ID 0, and you manually change the=20 serverID config if you need to slapadd on some other node. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6895075019821714960==-- From rein@OpenLDAP.org Wed May 28 19:28:21 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5537) syncprov updates incorrect contextCSN at startup Date: Wed, 28 May 2008 19:28:20 +0000 Message-ID: <200805281928.m4SJSKA1004007@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0390610662007787669==" --===============0390610662007787669== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Rein Tollevik Version: CVS head + rein-serverID.patch OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/rein-syncprov.patch Submission from: (NULL) (81.93.160.250) Submitted by: rein At startup syncprov searches for any entries with an entryCSN value newer than the newest contextCSN it read from the db and replaces the newest contextCSN value with the newest it finds. But the newest entryCSN could have a differe= nt sid field, which would result in the server loosing one valid contextCSN and instead introduce two contexCSNs with the same sid field. It could also introduce a defaulted contextCSN with sid=3D0, which would never be updated u= nless there exist a server with that sid, ref my previous ITS. A patch that fixes this is at the referenced URL. It only updates the contextCSN from entryCSN values matching the serverID of this server. My initial thought was that all the contextCSNs that has newer entryCSN values with the same sid field should be updated. But I'm afraid that could cause syncrepl to miss some entries if it picks up the updated contextCSN values, as there may be entries from remote servers with entryCSN values newer than the contextCSN received from that server. The exception is delta-syncrepl where a similar update of all the contextCSN values should probably be done at startu= p.=20 But that belongs in syncrepl.c if needed, as it is requiered whether syncprov= is used or not. Rein Tollevik Basefarm AS --===============0390610662007787669==-- From rein@OpenLDAP.org Wed May 28 20:28:24 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Wed, 28 May 2008 20:28:24 +0000 Message-ID: <200805282028.m4SKSOHX013869@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0539360325933920784==" --===============0539360325933920784== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 28 May 2008, Howard Chu wrote: >> A case I have is where a consumer replicates a glue'ed database, with the >> exception of one subordinate backend where the consumer is the master. The >> subordinate backend is replicated back to the master of the glue'ed=20 >> database. >> With the current code the master would send the content of the subordinate= =20 >> db back to its master. > > Understood. In fact, having multiple sources of data in a glued tree is=20 > really a form of multi-master. (The separate glued branches cannot cause=20 > inconsistencies with each other, but still their contextCSNs must be manage= d=20 > individually.) Yes, this is a sort of multi-master configuration, but not what I think=20 of when I hear it (and read the doc). The doc. could be clearer that=20 different serverID values are always required when there are multiple=20 master servers, even if the configuration ensures that there will never be=20 more than one master for any backend. Btw, if I have understood things correctly there cannot safely be more then one subordinate db (in a glued environment) that replicates from any=20 single master, but it is OK as long as all the subordinates replicates=20 from different masters. That's why the syncrepl consumer in this case is=20 used on the glue db itself, not the subordinates. And it definitely tries=20 to interfere with what goes on in the subordinates (as it should). >> A patch that fixes this is at the referenced URL. As I am not sure of the >> consequences if a defaulted serverID=3D0 value was included in the syncCoo= kie=20 >> the >> patch changes the internal default slap_serverID value to -1 to make it=20 >> possible >> to differentiate between a configured and defaulted serverID=3D0. > >> Btw, there are potential problems with using serverID=3D0, so it would be = >> best if >> that value was reserved for the default unconfigured case. I.e, a default >> serverID=3D0 value could be chosen be slapadd when the two-argument form of >> serverID is used in the config, as resolving the URL needs the listener=20 >> argument >> to slapd to succeed. > > You mean the three-argument form? The two-argument form only allows a singl= e=20 > serverID to be configured anyway, so there is no ambiguity there. But you'r= e=20 > right, in tool mode when multiple serverIDs are configured, there's no way = > for it to choose the right serverID. That's a problem regardless of whether= =20 > the default is 0 or -1 though. Yes, I didn't count the serverID itself as an argument. If it was clear that different serverID values are always required if=20 there are more than one master server in a replication setup then it=20 should be safe to always include the sid in the syncrepl cookie. And the=20 internal distinction between a configured and defaulted serverID=3D0 value=20 this patch introduces would probably not be needed. > For now I think this is a doc issue; we could simply recommend that slapadd= =20 > always be performed on the node with ID 0, and you manually change the=20 > serverID config if you need to slapadd on some other node. My thought was that with serverID=3D0 reserved for the true single-master=20 configuration and tool mode we could safely ignore a contextCSN with 0 in=20 the sid field when serverID>0 is in use (to get rid of values already=20 in the databases). At startup syncprov could update its own contextCSN=20 value with newer entryCSN values that has 0 in the sid field. Ref=20 ITS#5537. Slapadd'ing on more than one master without synchronizing them between each run could still be a potential problem though.. Rein --===============0539360325933920784==-- From ghenry@OpenLDAP.org Wed May 28 20:39:54 2008 From: ghenry@OpenLDAP.org To: openldap-bugs@openldap.org Subject: (ITS#5538) Spelling of Respository at http://www.openldap.org/software/ Date: Wed, 28 May 2008 20:39:54 +0000 Message-ID: <200805282039.m4SKdsF2016288@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5196818019274165863==" --===============5196818019274165863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Gavin Henry Version: N/A OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Spelling: Respository at: http://www.openldap.org/software/ --===============5196818019274165863==-- From hyc@symas.com Wed May 28 22:01:04 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5538) Spelling of Respository at http://www.openldap.org/software/ Date: Wed, 28 May 2008 22:01:03 +0000 Message-ID: <200805282201.m4SM13nt027341@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7933071922105898515==" --===============7933071922105898515== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: N/A > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Spelling: > > Respository > > at: > > http://www.openldap.org/software/ I've fixed this in CVS. Kurt will have to handle pushing the update to the we= b=20 server. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7933071922105898515==-- From hoshahrokhi@gmail.com Wed May 28 22:39:00 2008 From: hoshahrokhi@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5539) openLDAP Date: Wed, 28 May 2008 22:39:00 +0000 Message-ID: <200805282239.m4SMd0It032219@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2351661830250464320==" --===============2351661830250464320== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Homa Shahrokhi Version: 2.2.13-8.e14-6.4 OS: Red hat 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.18.65.57) It is the first time that I am configuring an openLDAP. I download these four rpms : 1)openldap-2.3.30-3.fc6.i386.rpm 2)openldap-clients-2.3.30-3.fc6.i386.rpm 3)openldap-devel-2.3.30-3.fc6.i386.rpm 4)openldap-servers-2.3.30-3.fc6.i386.rpm and used "yum" to install all of them individual. And change the conf file. The ldap status is running. here is my sldap.conf: =20 database bdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DManager,dc=3Dexample,dc=3Dcom" rootpw password directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub and here is my ldif file: dn: dc=3Dexample,dc=3Dcom objectClass:dcobject objectClass:organization objectClass:top dc: example and ran this command: ldappadd -x -D "cn=3DManager,dc=3Dexample,dc=3Dcom" -w password -f test.ldif and here is the result: ldap_add:Server is unwilling to perform (53) additional info: no global superior knowledge I add this part to the ldif file: dn: cn=3DManager,dc=3Dexample,dc=3Dcom objectClass: organizatiolRole cn: Manager and ran the same command and git the same error. I tried to use LDAP browser and I am able to connect but can not add any entr= y. Could you please let me know what to do and why it happens? I would really appreciate if someone can help. Thanks....Homa --===============2351661830250464320==-- From quanah@zimbra.com Wed May 28 23:14:35 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5539) openLDAP Date: Wed, 28 May 2008 23:14:34 +0000 Message-ID: <200805282314.m4SNEYfc036821@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7570731360519743339==" --===============7570731360519743339== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Wednesday, May 28, 2008 10:39 PM +0000 hoshahrokhi(a)gmail.com wrote: > Full_Name: Homa Shahrokhi > Version: 2.2.13-8.e14-6.4 > OS: Red hat 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.18.65.57) > > > It is the first time that I am configuring an openLDAP. > I download these four rpms : > 1)openldap-2.3.30-3.fc6.i386.rpm > 2)openldap-clients-2.3.30-3.fc6.i386.rpm > 3)openldap-devel-2.3.30-3.fc6.i386.rpm > 4)openldap-servers-2.3.30-3.fc6.i386.rpm This is not provided by the OpenLDAP foundation. If you have support issues with things provided by Redhat, you need to contact them. Also, your issue seems to be basic knowledge questions. I suggest you read the online documentation, and if you have further questions, send them to openldap-software(a)openldap.org. The issue tracking system is for reporting bugs only. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============7570731360519743339==-- From hai.zhao@gmail.com Thu May 29 03:16:52 2008 From: hai.zhao@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5532) incorrect timestamp of slapd replica log Date: Thu, 29 May 2008 03:16:51 +0000 Message-ID: <200805290316.m4T3GpE5067126@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8871982405828839779==" --===============8871982405828839779== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ------=3D_Part_7580_3624331.1212031000971 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Quanah: I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. Does this bug exist in 2.4.x too? Regards, Hai On Thu, May 29, 2008 at 1:31 AM, Quanah Gibson-Mount wrote: > --On Tuesday, May 27, 2008 10:10 AM +0000 hai.zhao(a)gmail.com wrote: > > Full_Name: Zhao Hai >> Version: 2.3.41 >> OS: Linux 2.4.21 arm >> URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch >> Submission from: (NULL) (205.209.140.4) >> >> >> Problem: >> race condition makes incorrect timestamp in replogfile, cause certain >> modification of entries not replicate to slurp slaves. >> >> replica: 180.0.10.2:1234 >> replica: 180.0.10.3:1234 >> time: 1211855467 >> ^^^^^^^^^^ this timestamp >> >> How to reproduce the problem: >> 1) run under very slow machines (my environ: arm 266MHz) >> 2) slapd is configed to generate replogfile >> 3) ldapadd about 5 entries, then ldapmodify 2 entries without delay. >> > > This is fixed in RE23. If there is ever a 2.3.43 release, it will be in > that. In the meantime, I'd advise using 2.3.42 + your patch. > > Regards, > Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > ------=3D_Part_7580_3624331.1212031000971 Content-Type: text/html; charset=3DUTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Quanah:

I'm considering upgrading from 2.3 to 2.4.x. I haven&#= 39;t test 2.4.x yet. Does this bug exist in 2.4.x too?

Regards,
Hai=

On Thu, May 29, 2008 at 1:31 AM, Quanah Gi= bson-Mount <quanah(a)zimbra.com= > wrote:

--On Tuesday, May 27, 2008 10:10 AM +0000 hai.zhao(a)gmail.com wrote:

Full_Name: Zhao Hai
Version: 2.3.41
OS: Linux 2.4.21 arm
URL: ftp://ftp.openldap.org/incoming/zhaohai-080527.patch
Submission from: (NULL) (2= 05.209.140.4)

Problem:
race condition makes incorrect timestamp in replogfile, cause certain
modification of entries not replicate to slurp slaves.

replica: 180.0.10.2:1234=
replica: 180.0.10.3:1234=
time: 1211855467
^^^^^^^^^^ this timestamp

How to reproduce the problem:
1) run under very slow machines (my environ: arm 266MHz)
2) slapd is configed to generate replogfile
3) ldapadd about 5 entries, then ldapmodify 2 entries without delay.

This is fixed in RE23. If there is ever a 2.3.43 release, it will be in= that. In the meantime, I'd advise using 2.3.42 + your patch.

Regards,
Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration

------=3D_Part_7580_3624331.1212031000971-- --===============8871982405828839779==-- From quanah@zimbra.com Thu May 29 04:02:53 2008 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5532) incorrect timestamp of slapd replica log Date: Thu, 29 May 2008 04:02:52 +0000 Message-ID: <200805290402.m4T42qFR068053@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3240205975939719948==" --===============3240205975939719948== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Thursday, May 29, 2008 11:16 AM +0800 Hai wrote: > Hi, Quanah: > > I'm considering upgrading from 2.3 to 2.4.x. I haven't test 2.4.x yet. > Does this bug exist in 2.4.x too? Since slurpd was removed because it is completely unreliable and buggy, no, it does not exist. Sane people use syncrepl replication. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration --===============3240205975939719948==-- From abartlet@samba.org Thu May 29 11:25:13 2008 From: abartlet@samba.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5534) Samba4 needs internal transactions/consistancy Date: Thu, 29 May 2008 11:25:12 +0000 Message-ID: <200805291125.m4TBPClT014080@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1658699867368807714==" --===============1658699867368807714== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --=-8f0GY55a/Qq8n0F+gHZS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-05-28 at 08:14 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > On Tue, 2008-05-27 at 18:43 -0700, Howard Chu wrote: > >> Andrew Bartlett wrote: > >>> On Tue, 2008-05-27 at 18:22 -0700, Howard Chu wrote: > >>>>> This needs to occur even between databases on the server, but I won= 't ask that > >>>>> it occur outside the known trees. > >>>> It's already possible for operations in one database to reference en= tries in a > >>>> different database, so that aspect of validation should be fine. How= ever, as > >>>> noted before, "validation" is generally bogus to begin with. In part= icular, > >>>> how do you create entries with circular references? If you disallow = references > >>>> to nonexistent entries, you can't set the references until after all= of the > >>>> entries have been created. This means that you cannot backup a datab= ase that > >>>> has these references and then later reload it in a single pass. > >>> An interesting point, but I need to match the windows runtime > >>> behaviour. > >> Only when it has a visible impact on other clients. What software will= break > >> if the directory allows you to add new entries that contain dangling > >> references? What will break if the directory allows you to modify a re= ference > >> attribute to point to a nonexistent entry? > > > > Sure, I'm not asking for a change to default behaviours. I'm listing > > the things that our testsuite finds are differences, and looking for > > solutions. >=20 > I don't believe your proposed solution will ever be satisfactory. Entries= with=20 > circular references will also break syncrepl Refresh if the constraint yo= u're=20 > asking for is enforced.=20 Only if you don't consider them in replication. If the backlinks are added on each node, and not replicated, then surely you just need to import a set of replicated data, and then in the same transaction update the links.=20 Is there perhaps another way to implement this - say using a search-based virtual attribute for one half of the problem? I'm in no position to set your priorities, and my wishlist remains only that I hope to someday be able to make this work with OpenLDAP, but these issues remain. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-8f0GY55a/Qq8n0F+gHZS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIPpKIz4A8Wyi0NrsRAhu+AJ9fRq1o5INcGiX1ZYJTAmjmBUMBogCfQ8gC zrbftn69NpgTvb546qKvGKA= =kiKt -----END PGP SIGNATURE----- --=-8f0GY55a/Qq8n0F+gHZS-- --===============1658699867368807714==-- From rein@OpenLDAP.org Thu May 29 12:47:27 2008 From: rein@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Thu, 29 May 2008 12:47:26 +0000 Message-ID: <200805291247.m4TClQbW025196@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5089660210574103518==" --===============5089660210574103518== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 28 May 2008, Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> Syncrepl includes the serverID in the syncCookie in multi-master mode only= ,=20 >> but >> there are other configuration that would benefit from it as well. The commited fix for this bug causes test033-glue-syncrepl to fail. The=20 serverID is not set by the config, which makes syncprov_qresp() skip the delete when it fins that the consumer presented a cookie with its own sid=20 value. Rein --===============5089660210574103518==-- From hyc@symas.com Thu May 29 14:49:32 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Thu, 29 May 2008 14:49:31 +0000 Message-ID: <200805291449.m4TEnVgA035948@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7027495900025592806==" --===============7027495900025592806== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable rein(a)OpenLDAP.org wrote: > On Wed, 28 May 2008, Howard Chu wrote: > >> rein(a)OpenLDAP.org wrote: > >>> Syncrepl includes the serverID in the syncCookie in multi-master mode onl= y, >>> but >>> there are other configuration that would benefit from it as well. > > The commited fix for this bug causes test033-glue-syncrepl to fail. The > serverID is not set by the config, which makes syncprov_qresp() skip the > delete when it fins that the consumer presented a cookie with its own sid > value. OK then I guess you're right and we need the default to be -1. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7027495900025592806==-- From hyc@symas.com Thu May 29 19:22:08 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Thu, 29 May 2008 19:22:07 +0000 Message-ID: <200805291922.m4TJM7Yk061350@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5539602957918802231==" --===============5539602957918802231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rein Tollevik wrote: > Yes, this is a sort of multi-master configuration, but not what I think > of when I hear it (and read the doc). The doc. could be clearer that > different serverID values are always required when there are multiple > master servers, even if the configuration ensures that there will never be > more than one master for any backend. We should update the manpages with this ITS as well then. > Btw, if I have understood things correctly there cannot safely be more > then one subordinate db (in a glued environment) that replicates from any > single master, If the master has multiple DBs, and they're being separately replicated into = a=20 single DB, that would be a problem (regardless of glue on the consumer). If=20 the DBs are glued on the master, then there's no problem. > My thought was that with serverID=3D0 reserved for the true single-master > configuration and tool mode we could safely ignore a contextCSN with 0 in > the sid field when serverID>0 is in use (to get rid of values already > in the databases). At startup syncprov could update its own contextCSN > value with newer entryCSN values that has 0 in the sid field. Ref > ITS#5537. Slapadd'ing on more than one master without synchronizing > them between each run could still be a potential problem though.. That's not a viable solution. The syncprov startup check is primarily to recover from unclean shutdowns.=20 I.e., it's looking for newer CSNs that may have been saved before syncprov go= t=20 a chance to write its final checkpoint. Ignoring values, or giving special=20 treatment to sid 0 isn't going to work for that purpose. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5539602957918802231==-- From hyc@symas.com Thu May 29 21:01:20 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie Date: Thu, 29 May 2008 21:01:19 +0000 Message-ID: <200805292101.m4TL1J8n065637@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8594202805519397985==" --===============8594202805519397985== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > Rein Tollevik wrote: >> My thought was that with serverID=3D0 reserved for the true single-master >> configuration and tool mode we could safely ignore a contextCSN with 0 in >> the sid field when serverID>0 is in use (to get rid of values already >> in the databases). At startup syncprov could update its own contextCSN >> value with newer entryCSN values that has 0 in the sid field. Ref >> ITS#5537. Slapadd'ing on more than one master without synchronizing >> them between each run could still be a potential problem though.. > > That's not a viable solution. > > The syncprov startup check is primarily to recover from unclean shutdowns. > I.e., it's looking for newer CSNs that may have been saved before syncprov = got > a chance to write its final checkpoint. Ignoring values, or giving special > treatment to sid 0 isn't going to work for that purpose. Hm, have to think about this some more. Generally, slapadd/slapindex require the directory to be offline. As such, if= =20 you have any running servers, you should be adding entries using ldapadd, not= =20 slapadd. So I'm going to ignore this case for now. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============8594202805519397985==-- From unix.gurus@gmail.com Fri May 30 00:01:05 2008 From: unix.gurus@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 00:01:05 +0000 Message-ID: <200805300001.m4U015rk075771@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8296824736058897926==" --===============8296824736058897926== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Sean Burford Version: 2.4.9 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/sean-burford-080529.tar.gz.1 Submission from: (NULL) (76.104.224.20) Adding equality and substring matching to an existing in use attribute causes the schema and database contents to mismatch. I added equality and substring matching to an attribute in my schema. A modification of an attribute value = was propogated a few days later, triggering the assertion and taking my replicas offline. Each restart replicated the change and triggered the assertion agai= n. When no matching is specified, new database entries do not have their normali= zed value populated in the database. When the matching is added, new database entries with have their normalized value populated in the database. There is= an assertion in attr.c that checks that attributes from the database have the expected normalization. I have attached a script and config to demonstrate the issue (ftp://ftp.openldap.org/incoming/sean-burford-080529.tar.gz.1) These files are in the tarball: slapd.d/ contains a server configuration that is suitable for reproducing the problem. script/trigger-assertion.sh performs the ldap operations necessary to trigger the assertion. The important ones are: - An attribute is added to the schema without equality matching. - An entry is added to the directory that uses the new attribute. - The schema is modified so that the attribute has equality matching. - Another attribute value is added to the entry, triggering the assertion. patch/attr-assertion.patch causes the operation to be rejected and logged, rather than triggering the assertion. It might not be the optimal patch for this problem, but it prevents the assertion and rejects the operation. --===============8296824736058897926==-- From unix.gurus@gmail.com Fri May 30 00:20:41 2008 From: unix.gurus@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 00:20:41 +0000 Message-ID: <200805300020.m4U0KfJe076743@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7403097769792543574==" --===============7403097769792543574== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ------=_Part_4694_18767492.1212106829556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw MDAwMDAwMDA0MjZlNDEgaW4gYXR0cl9tZXJnZSAoZT08dmFsdWUgb3B0aW1pemVkIG91dD4sCiAg ICBkZXNjPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgdmFscz0weDk4Y2ViMCwgbnZhbHM9MHg5NTNi ZjApIGF0IGF0dHIuYzo0NzcKIzQgIDB4MDAwMDAwMDAwMDQ2ODFiYyBpbiBtb2RpZnlfYWRkX3Zh bHVlcyAoZT0weDQwODVmN2IwLCBtb2Q9MHg5OGNlNzAsCiAgICBwZXJtaXNzaXZlPTAsIHRleHQ9 MHg0MDg2MGNkMCwgdGV4dGJ1Zj0weDQwODVmOGIwICIw77+9XDIzMCIsIHRleHRsZW49MjU2KQog ICAgYXQgbW9kcy5jOjE1NQojNSAgMHgwMDAwMDAwMDAwNDhlNGJmIGluIGhkYl9tb2RpZnlfaW50 ZXJuYWwgKG9wPTB4OTUyNDAwLCB0aWQ9MHg5NTM2NDAsCiAgICBtb2RsaXN0PTB4OThjZTcwLCBl PTB4NDA4NWY3YjAsIHRleHQ9MHg0MDg2MGNkMCwKICAgIHRleHRidWY9MHg0MDg1ZjhiMCAiMO+/ vVwyMzAiLCB0ZXh0bGVuPTI1NikgYXQgbW9kaWZ5LmM6MTAxCiM2ICAweDAwMDAwMDAwMDA0OGVl YWQgaW4gaGRiX21vZGlmeSAob3A9MHg5NTI0MDAsIHJzPTB4NDA4NjBjYjApCiAgICBhdCBtb2Rp ZnkuYzo1NzgKIzcgIDB4MDAwMDAwMDAwMDQzNDZlZCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4OTUy NDAwLCBycz0weDQwODYwY2IwKQogICAgYXQgbW9kaWZ5LmM6MzAwCiM4ICAweDAwMDAwMDAwMDA0 MzRmZGEgaW4gZG9fbW9kaWZ5IChvcD0weDk1MjQwMCwgcnM9MHg0MDg2MGNiMCkKICAgIGF0IG1v ZGlmeS5jOjE3NQojOSAgMHgwMDAwMDAwMDAwNDFlMTkzIGluIGNvbm5lY3Rpb25fb3BlcmF0aW9u IChjdHg9MHg0MDg2MGUwMCwKICAgIGFyZ192PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikgYXQgY29u bmVjdGlvbi5jOjEwODQKIzEwIDB4MDAwMDAwMDAwMDQxZTk5NSBpbiBjb25uZWN0aW9uX3JlYWRf dGhyZWFkIChjdHg9MHg0MDg2MGUwMCwKICAgIGFyZ3Y9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBh dCBjb25uZWN0aW9uLmM6MTIxMQojMTEgMHgwMDAwMDAwMDAwNTQzMGRhIGluIGxkYXBfaW50X3Ro cmVhZF9wb29sX3dyYXBwZXIgKHhwb29sPTB4OGQ3YzYwKQogICAgYXQgdHBvb2wuYzo2NjMKIzEy IDB4MDAwMDdmNzI1NmU2ZDNmNyBpbiBzdGFydF90aHJlYWQgKCkgZnJvbSAvbGliL2xpYnB0aHJl YWQuc28uMAojMTMgMHgwMDAwN2Y3MjU1OTRmYjJkIGluIGNsb25lICgpIGZyb20gL2xpYi9saWJj LnNvLjYKIzE0IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQo= ------=_Part_4694_18767492.1212106829556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86PGJyPjxicj4jMCZu YnNwOyAweDAwMDA3ZjcyNTU4YWEwOTUgaW4gcmFpc2UgKCkgZnJvbSAvbGliL2xpYmMuc28uNjxi cj4jMSZuYnNwOyAweDAwMDA3ZjcyNTU4YWJhZjAgaW4gYWJvcnQgKCkgZnJvbSAvbGliL2xpYmMu c28uNjxicj4jMiZuYnNwOyAweDAwMDA3ZjcyNTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBm cm9tIC9saWIvbGliYy5zby42PGJyPgojMyZuYnNwOyAweDAwMDAwMDAwMDA0MjZlNDEgaW4gYXR0 cl9tZXJnZSAoZT0mbHQ7dmFsdWUgb3B0aW1pemVkIG91dCZndDssPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyBkZXNjPSZsdDt2YWx1ZSBvcHRpbWl6ZWQgb3V0Jmd0OywgdmFscz0weDk4Y2ViMCwgbnZh bHM9MHg5NTNiZjApIGF0IGF0dHIuYzo0Nzc8YnI+IzQmbmJzcDsgMHgwMDAwMDAwMDAwNDY4MWJj IGluIG1vZGlmeV9hZGRfdmFsdWVzIChlPTB4NDA4NWY3YjAsIG1vZD0weDk4Y2U3MCw8YnI+CiZu YnNwOyZuYnNwOyZuYnNwOyBwZXJtaXNzaXZlPTAsIHRleHQ9MHg0MDg2MGNkMCwgdGV4dGJ1Zj0w eDQwODVmOGIwICZxdW90OzDvv71cMjMwJnF1b3Q7LCB0ZXh0bGVuPTI1Nik8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGF0IG1vZHMuYzoxNTU8YnI+IzUmbmJzcDsgMHgwMDAwMDAwMDAwNDhlNGJmIGlu IGhkYl9tb2RpZnlfaW50ZXJuYWwgKG9wPTB4OTUyNDAwLCB0aWQ9MHg5NTM2NDAsPGJyPiZuYnNw OyZuYnNwOyZuYnNwOyBtb2RsaXN0PTB4OThjZTcwLCBlPTB4NDA4NWY3YjAsIHRleHQ9MHg0MDg2 MGNkMCw8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyB0ZXh0YnVmPTB4NDA4NWY4YjAgJnF1b3Q7MO+/ vVwyMzAmcXVvdDssIHRleHRsZW49MjU2KSBhdCBtb2RpZnkuYzoxMDE8YnI+IzYmbmJzcDsgMHgw MDAwMDAwMDAwNDhlZWFkIGluIGhkYl9tb2RpZnkgKG9wPTB4OTUyNDAwLCBycz0weDQwODYwY2Iw KTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYXQgbW9kaWZ5LmM6NTc4PGJyPiM3Jm5ic3A7IDB4MDAw MDAwMDAwMDQzNDZlZCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4OTUyNDAwLCBycz0weDQwODYwY2Iw KTxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG1vZGlmeS5jOjMwMDxicj4jOCZuYnNwOyAweDAw MDAwMDAwMDA0MzRmZGEgaW4gZG9fbW9kaWZ5IChvcD0weDk1MjQwMCwgcnM9MHg0MDg2MGNiMCk8 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG1vZGlmeS5jOjE3NTxicj4jOSZuYnNwOyAweDAwMDAw MDAwMDA0MWUxOTMgaW4gY29ubmVjdGlvbl9vcGVyYXRpb24gKGN0eD0weDQwODYwZTAwLDxicj4m bmJzcDsmbmJzcDsmbmJzcDsgYXJnX3Y9Jmx0O3ZhbHVlIG9wdGltaXplZCBvdXQmZ3Q7KSBhdCBj b25uZWN0aW9uLmM6MTA4NDxicj4KIzEwIDB4MDAwMDAwMDAwMDQxZTk5NSBpbiBjb25uZWN0aW9u X3JlYWRfdGhyZWFkIChjdHg9MHg0MDg2MGUwMCw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZ3Y9 Jmx0O3ZhbHVlIG9wdGltaXplZCBvdXQmZ3Q7KSBhdCBjb25uZWN0aW9uLmM6MTIxMTxicj4jMTEg MHgwMDAwMDAwMDAwNTQzMGRhIGluIGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBwZXIgKHhwb29s PTB4OGQ3YzYwKTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYXQgdHBvb2wuYzo2NjM8YnI+CiMxMiAw eDAwMDA3ZjcyNTZlNmQzZjcgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20gL2xpYi9saWJwdGhyZWFk LnNvLjA8YnI+IzEzIDB4MDAwMDdmNzI1NTk0ZmIyZCBpbiBjbG9uZSAoKSBmcm9tIC9saWIvbGli Yy5zby42PGJyPiMxNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCk8YnI+PGJyPgo= ------=_Part_4694_18767492.1212106829556-- --===============7403097769792543574==-- From hyc@symas.com Fri May 30 00:41:24 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 00:41:23 +0000 Message-ID: <200805300041.m4U0fN47077805@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3907181159977752298==" --===============3907181159977752298== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable unix.gurus(a)gmail.com wrote: > ------=3D_Part_4694_18767492.1212106829556 > Content-Type: text/plain; charset=3DUTF-8 > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw > N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm > NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy > NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw Thanks, the original report was sufficient. It surfaces a larger problem,=20 which we've been ignoring up till now. The correct action would be to iterate= =20 through all the databases and generate the normalized values for all the=20 affected attributes. There is currently no code to make that happen though.=20 (Likewise, if deleting matching rules, the normalized values must also be=20 deleted.) As such, the only way to progress after such a change would be to=20 dump and reload the DBs (slapcat/slapadd). We'll probably need to discuss on the -devel list what steps to take from her= e. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============3907181159977752298==-- From hyc@symas.com Fri May 30 09:40:56 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 09:40:56 +0000 Message-ID: <200805300940.m4U9euZn040707@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4745193279106658114==" --===============4745193279106658114== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------050600010007030200030106 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: > We'll probably need to discuss on the -devel list what steps to take from h= ere. > I wrote the attached patch for the original issue. Unfortunately it asserted = right away: [Switching to Thread 1090525504 (LWP 23577)] 0x00002b55e738d535 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00002b55e738d535 in raise () from /lib64/libc.so.6 #1 0x00002b55e738e990 in abort () from /lib64/libc.so.6 #2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000004410e5 in attr_valadd (a=3D0xb866c8, vals=3D0x41000670, nvals= =3D0x0,=20 nn=3D1) at ../../../r24/servers/slapd/attr.c:394 #4 0x0000000000441a06 in attr_merge_one (e=3D0xb72c08, desc=3D0x8b3780,=20 val=3D0x41000670, nval=3D0x0) at ../../../r24/servers/slapd/attr.c:599 #5 0x000000000043ea0f in slap_add_opattrs (op=3D0x965ec0, text=3D, textbuf=3D, textlen=3D, manage_ctxcsn=3D) = at=20 ../../../r24/servers/slapd/add.c:664 #6 0x00000000004d9c42 in hdb_add (op=3D0x965ec0, rs=3D0x41000ca0) at add.c:1= 08 #7 0x000000000043f1a6 in fe_op_add (op=3D0x965ec0, rs=3D0x41000ca0) at=20 ../../../r24/servers/slapd/add.c:334 #8 0x000000000043fa12 in do_add (op=3D0x965ec0, rs=3D0x41000ca0) at=20 ../../../r24/servers/slapd/add.c:194 #9 0x00000000004383a7 in connection_operation (ctx=3D0x41000de0,=20 arg_v=3D0x965ec0) at ../../../r24/servers/slapd/connection.c:1084 #10 0x00000000004388cf in connection_read_thread (ctx=3D0x41000de0, argv=3D0x= c) at=20 ../../../r24/servers/slapd/connection.c:1211 #11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=3D0x8bf070) at = ../../../r24/libraries/libldap_r/tpool.c:663 #12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0 #13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () It was adding the createTimestamp attribute, without providing normalized=20 values. slap_add_opattrs was written before the generalizedTimeNormalize=20 function was written... I suspect there will be a fair number of cases that=20 need to be cleaned up. I don't have time at the moment to chase them all down= .=20 Anyone else want to jump in here? If not, we may have to push this back a bit= .=20 Note that this patch will probably require a fair number of databases to be=20 reloaded. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------050600010007030200030106 Content-Type: text/plain; name=3D"dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=3D"dif.txt" Index: attr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v retrieving revision 1.112.2.7 diff -u -r1.112.2.7 attr.c --- attr.c 11 Feb 2008 23:26:43 -0000 1.112.2.7 +++ attr.c 30 May 2008 09:33:43 -0000 @@ -366,8 +366,39 @@ BerVarray nvals, int nn ) { - int i; BerVarray v2; + int i; + + { + /* FIXME: if the schema has been edited, and an equality matching rule + * has been added or removed from the attribute definition, the database + * values may no longer be in sync with our expectations. Currently this + * means the DB must be reloaded. + */ + int have_norm, have_nval, new_nval; + have_norm =3D a->a_desc->ad_type->sat_equality->smr_normalize !=3D NULL; + have_nval =3D a->a_nvals !=3D a->a_vals; + new_nval =3D nvals !=3D NULL; + + /* this check is only relevant if any values already exist */ + if ( a->a_vals !=3D NULL && have_norm !=3D have_nval ) { + Debug(LDAP_DEBUG_ANY, + "attr_valadd: database inconsistent with schema definition of %s, reload= the DB\n", + a->a_desc->ad_cname.bv_val, 0, 0 ); + return LDAP_OTHER; + /* no need to compare have_nval with new_nval; by transitivity they will = match if + * the above check and the following check succeed. + */ + } + + assert( have_norm =3D=3D new_nval ); + if ( have_norm !=3D new_nval ) { + Debug(LDAP_DEBUG_ANY, + "attr_valadd: new values of %s not properly normalized (should never hap= pen!)\n", + a->a_desc->ad_cname.bv_val, 0, 0 ); + return LDAP_OTHER; + } + } =20 v2 =3D (BerVarray) SLAP_REALLOC( (char *) a->a_vals, (a->a_numvals + nn + 1) * sizeof(struct berval) ); @@ -469,15 +500,6 @@ =20 if ( *a =3D=3D NULL ) { *a =3D attr_alloc( desc ); - } else { - /* - * FIXME: if the attribute already exists, the presence - * of nvals and the value of (*a)->a_nvals must be consistent - */ - assert( ( nvals =3D=3D NULL && (*a)->a_nvals =3D=3D (*a)->a_vals ) - || ( nvals !=3D NULL && ( - ( (*a)->a_vals =3D=3D NULL && (*a)->a_nvals =3D=3D NULL ) - || ( (*a)->a_nvals !=3D (*a)->a_vals ) ) ) ); } =20 if ( vals !=3D NULL ) { --------------050600010007030200030106-- --===============4745193279106658114==-- From pwadas@jewish.org.pl Fri May 30 10:24:22 2008 From: pwadas@jewish.org.pl To: openldap-bugs@openldap.org Subject: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend Date: Fri, 30 May 2008 10:24:22 +0000 Message-ID: <200805301024.m4UAOMG5045690@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3857303622780603765==" --===============3857303622780603765== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Piotr Wadas Version: 2.4.7 upto 2.4.9 OS: debian 2.6.18+ kernel URL:=20 Submission from: (NULL) (195.95.182.4) The issue is discussed at http://www.openldap.org/lists/openldap-software/200805/msg00136.html List message contains debug information, steps to reproduce, backtrace logs etc. Issue appears since 2.4.7 in 2.4 series. gdb bt quick ref: #0 0xb7b4842c in free () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6 #1 0xb7e901aa in ber_memfree_x (p=3D0x0, ctx=3D0x0) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:152 #2 0xb7e9019c in ber_memfree_x (p=3D0x0, ctx=3D0x0) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:159 #3 0xb7e90235 in ber_bvarray_free_x (a=3D0xa96e3354, ctx=3D0x8279658) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:731 #4 0xb73028e5 in bdb_filter_candidates (op=3D0x82792e0, locker=3D34, f=3D0xa= 96e325c, ids=3D0xa9062008, tmp=3D0xa8ee2008, stack=3D0xa90e2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:803 #5 0xb7303064 in list_candidates (op=3D0x82792e0, locker=3D34, flist=3D0xa96= e31ec, ftype=3D160, ids=3D0xa8fe2008, tmp=3D0xa8ee2008, save=3D0xa9062008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:581 #6 0xb73017c7 in bdb_filter_candidates (op=3D0x82792e0, locker=3D34, f=3D0xa= 96e32bc, ids=3D0xa8fe2008, tmp=3D0xa8ee2008, stack=3D0xa9062008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:198 #7 0xb7303064 in list_candidates (op=3D0x82792e0, locker=3D34, flist=3D0xa9b= e2ec8, ftype=3D161, ids=3D0xa8f62008, tmp=3D0xa8ee2008, save=3D0xa8fe2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:581 #8 0xb73015ca in bdb_filter_candidates (op=3D0x82792e0, locker=3D34, f=3D0xa= 9be2ebc, ids=3D0xa8f62008, tmp=3D0xa8ee2008, stack=3D0xa8fe2008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:204 #9 0xb7303064 in list_candidates (op=3D0x82792e0, locker=3D34, flist=3D0xa9b= e2eb0, ftype=3D160, ids=3D0xa9b22e1c, tmp=3D0xa8ee2008, save=3D0xa8f62008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:581 #10 0xb73017c7 in bdb_filter_candidates (op=3D0x82792e0, locker=3D34, f=3D0xa= 9be2ed4, ids=3D0xa9b22e1c, tmp=3D0xa8ee2008, stack=3D0xa8f62008) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb= /filterindex.c:198 #11 0xb72fc858 in bdb_search (op=3D0x82792e0, rs=3D0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/search= .c:1109 #12 0x080d76f1 in overlay_op_walk (op=3D0x82792e0, rs=3D0xa9be4168, which=3Do= p_search, oi=3D0x81f63d8, on=3D0x81f64d8) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:646 #13 0x080d7c5d in over_op_func (op=3D0x82792e0, rs=3D0xa9be4168, which=3Dop_s= earch) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:698 #14 0x08077fd3 in fe_op_search (op=3D0x82792e0, rs=3D0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:366 #15 0x080787fc in do_search (op=3D0x82792e0, rs=3D0xa9be4168) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:217 #16 0x08075a9f in connection_operation (ctx=3D0xa9be4248, arg_v=3D0x82792e0) = at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:10= 84 #17 0x08076196 in connection_read_thread (ctx=3D0xa9be4248, argv=3D0x10) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:12= 11 #18 0xb7ea1d64 in ldap_int_thread_pool_wrapper (xpool=3D0x81b09b8) at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/libldap_r/tpool.c:6= 63 #19 0xb7c2c4fb in start_thread () from /usr/lib/i486-linux-gnu/i686/cmov/libpthread.so.0 #20 0xb7bafe8e in clone () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6 --===============3857303622780603765==-- From emmanuel.duru@atosorigin.com Fri May 30 11:26:46 2008 From: emmanuel.duru@atosorigin.com To: openldap-bugs@openldap.org Subject: (ITS#5542) Bug in libldap/t61.c (for your information) Date: Fri, 30 May 2008 11:26:45 +0000 Message-ID: <200805301126.m4UBQj8L048723@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2292729465002135752==" --===============2292729465002135752== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, there mis= ses a "i +=3D j; c +=3D j" at the end of the loop. --===============2292729465002135752==-- From hyc@symas.com Fri May 30 15:34:28 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5542) Bug in libldap/t61.c (for your information) Date: Fri, 30 May 2008 15:34:28 +0000 Message-ID: <200805301534.m4UFYSTD076818@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2167578760131256018==" --===============2167578760131256018== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.39 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > In t61.c/ldap_utf8s_to_t61s(), the second loop is an infinite loop, there m= isses > a "i +=3D j; c +=3D j" at the end of the loop. Congratulations, you're the first person to use this code in over 6 years. Ou= t=20 of curiosity, why do you need it? Thanks for the report, fixed in CVS. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============2167578760131256018==-- From hyc@symas.com Fri May 30 16:10:45 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5541) slapd segfaults with specific search on string bdb and hdb backend Date: Fri, 30 May 2008 16:10:44 +0000 Message-ID: <200805301610.m4UGAiYX081449@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7868789302420530660==" --===============7868789302420530660== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable pwadas(a)jewish.org.pl wrote: > Full_Name: Piotr Wadas > Version: 2.4.7 upto 2.4.9 > OS: debian 2.6.18+ kernel > URL: > Submission from: (NULL) (195.95.182.4) > > > The issue is discussed at > http://www.openldap.org/lists/openldap-software/200805/msg00136.html > > List message contains debug information, steps to reproduce, > backtrace logs etc. > Issue appears since 2.4.7 in 2.4 series. The config info you posted is missing your index configuration, which is most= =20 relevant here. From your traces, we could use a little more info as well: frame 4 print *ava->aa_desc print *mr > > gdb bt quick ref: > > #0 0xb7b4842c in free () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6 > #1 0xb7e901aa in ber_memfree_x (p=3D0x0, ctx=3D0x0) at > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:= 152 > #2 0xb7e9019c in ber_memfree_x (p=3D0x0, ctx=3D0x0) at > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:= 159 > #3 0xb7e90235 in ber_bvarray_free_x (a=3D0xa96e3354, ctx=3D0x8279658) at > /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:= 731 > #4 0xb73028e5 in bdb_filter_candidates (op=3D0x82792e0, locker=3D34, f=3D0= xa96e325c, > ids=3D0xa9062008, tmp=3D0xa8ee2008, stack=3D0xa90e2008) > at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-= bdb/filterindex.c:803 --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============7868789302420530660==-- From unix.gurus@gmail.com Fri May 30 17:15:11 2008 From: unix.gurus@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 17:15:10 +0000 Message-ID: <200805301715.m4UHFAGE095457@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5820745493737057365==" --===============5820745493737057365== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ------=3D_Part_7327_2415938.1212167698754 Content-Type: text/plain; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On Fri, May 30, 2008 at 2:40 AM, wrote: > This is a multi-part message in MIME format. > --------------050600010007030200030106 > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > Content-Transfer-Encoding: 7bit > > hyc(a)symas.com wrote: > > We'll probably need to discuss on the -devel list what steps to take from > here. > > > I wrote the attached patch for the original issue. Unfortunately it > asserted > right away: > > [Switching to Thread 1090525504 (LWP 23577)] > 0x00002b55e738d535 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00002b55e738d535 in raise () from /lib64/libc.so.6 > #1 0x00002b55e738e990 in abort () from /lib64/libc.so.6 > #2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6 > #3 0x00000000004410e5 in attr_valadd (a=3D0xb866c8, vals=3D0x41000670, > nvals=3D0x0, > nn=3D1) at ../../../r24/servers/slapd/attr.c:394 > #4 0x0000000000441a06 in attr_merge_one (e=3D0xb72c08, desc=3D0x8b3780, > val=3D0x41000670, nval=3D0x0) > at ../../../r24/servers/slapd/attr.c:599 > #5 0x000000000043ea0f in slap_add_opattrs (op=3D0x965ec0, text=3D optimized > out>, textbuf=3D, > textlen=3D, manage_ctxcsn=3D)= at > ../../../r24/servers/slapd/add.c:664 > #6 0x00000000004d9c42 in hdb_add (op=3D0x965ec0, rs=3D0x41000ca0) at add.c= :108 > #7 0x000000000043f1a6 in fe_op_add (op=3D0x965ec0, rs=3D0x41000ca0) at > ../../../r24/servers/slapd/add.c:334 > #8 0x000000000043fa12 in do_add (op=3D0x965ec0, rs=3D0x41000ca0) at > ../../../r24/servers/slapd/add.c:194 > #9 0x00000000004383a7 in connection_operation (ctx=3D0x41000de0, > arg_v=3D0x965ec0) at ../../../r24/servers/slapd/connection.c:1084 > #10 0x00000000004388cf in connection_read_thread (ctx=3D0x41000de0, argv=3D= 0xc) > at > ../../../r24/servers/slapd/connection.c:1211 > #11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=3D0x8bf070) at > ../../../r24/libraries/libldap_r/tpool.c:663 > #12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0 > #13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6 > #14 0x0000000000000000 in ?? () > > It was adding the createTimestamp attribute, without providing normalized > values. slap_add_opattrs was written before the generalizedTimeNormalize > function was written... I suspect there will be a fair number of cases that > need to be cleaned up. I don't have time at the moment to chase them all > down. > Anyone else want to jump in here? If not, we may have to push this back a > bit. > Note that this patch will probably require a fair number of databases to be > reloaded. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > --------------050600010007030200030106 > Content-Type: text/plain; > name=3D"dif.txt" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename=3D"dif.txt" > > Index: attr.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v > retrieving revision 1.112.2.7 > diff -u -r1.112.2.7 attr.c > --- attr.c 11 Feb 2008 23:26:43 -0000 1.112.2.7 > +++ attr.c 30 May 2008 09:33:43 -0000 > @@ -366,8 +366,39 @@ > BerVarray nvals, > int nn ) > { > - int i; > BerVarray v2; > + int i; > + > + { > + /* FIXME: if the schema has been edited, and an equality > matching rule > + * has been added or removed from the attribute definition, > the database > + * values may no longer be in sync with our expectations. > Currently this > + * means the DB must be reloaded. > + */ > + int have_norm, have_nval, new_nval; > + have_norm =3D a->a_desc->ad_type->sat_equality->smr_normali= ze > !=3D NULL; Not all attributes have an equality matching rule. This causes your patch to segfault since sat_equality is NULL: > have_norm =3D a->a_desc->ad_type->sat_equality->smr_normalize !=3D NULL; > This seems to be a better way to generate have_norm: > have_norm =3D a->a_desc->ad_type->sat_equality !=3D NULL && > a->a_desc->ad_type->sat_equality->smr_normalize !=3D NULL; > Once that is fixed the config backend causes an assert for me when it attempts to add createTimestamp, which is exactly the problem you describe. I'll create a patch that addresses any of these normalization issues that I can identify and send it to one of the openldap lists. Would openldap-its or openldap-devel be preferable? + have_nval =3D a->a_nvals !=3D a->a_vals; > + new_nval =3D nvals !=3D NULL; > + > + /* this check is only relevant if any values already exist > */ > + if ( a->a_vals !=3D NULL && have_norm !=3D have_nval ) { > + Debug(LDAP_DEBUG_ANY, > + "attr_valadd: database inconsistent with > schema definition of %s, reload the DB\n", > + a->a_desc->ad_cname.bv_val, 0, 0 ); > + return LDAP_OTHER; > + /* no need to compare have_nval with new_nval; by > transitivity they will match if > + * the above check and the following check succeed. > + */ > + } > + > + assert( have_norm =3D=3D new_nval ); > + if ( have_norm !=3D new_nval ) { > + Debug(LDAP_DEBUG_ANY, > + "attr_valadd: new values of %s not properly > normalized (should never happen!)\n", > + a->a_desc->ad_cname.bv_val, 0, 0 ); > + return LDAP_OTHER; > + } > + } > > v2 =3D (BerVarray) SLAP_REALLOC( (char *) a->a_vals, > (a->a_numvals + nn + 1) * sizeof(struct berval) ); > @@ -469,15 +500,6 @@ > > if ( *a =3D=3D NULL ) { > *a =3D attr_alloc( desc ); > - } else { > - /* > - * FIXME: if the attribute already exists, the presence > - * of nvals and the value of (*a)->a_nvals must be > consistent > - */ > - assert( ( nvals =3D=3D NULL && (*a)->a_nvals =3D=3D (*a)->a= _vals ) > - || ( nvals !=3D NULL && ( > - ( (*a)->a_vals =3D=3D NULL && > (*a)->a_nvals =3D=3D NULL ) > - || ( (*a)->a_nvals !=3D (*a)->a_vals > ) ) ) ); > } > > if ( vals !=3D NULL ) { > > --------------050600010007030200030106-- > > > --=20 Thanks, Sean Burford ------=3D_Part_7327_2415938.1212167698754 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

On Fri, May 30, 2008 at 2:40 AM, <<= a href=3D"mailto:hyc(a)symas.com">hyc(a)symas.com> wrote:
This is a multi-part message in MIME format.
--------------050600010007030200030106
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
Content-Transfer-Encoding: 7bit

hyc(a)symas.com wrote:
> We'll probably need to discuss on the -devel list what steps to take= from here.
>

I wrote the attached patch for the original issue. Unfortunately it ass= erted
right away:

[Switching to Thread 1090525504 (LWP 23577)]
0x00002b55e738d535 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00002b55e738d535 in raise () from /lib64/libc.so.6
#1 0x00002b55e738e990 in abort () from /lib64/libc.so.6
#2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6
#3 0x00000000004410e5 in attr_valadd (a=3D0xb866c8, vals=3D0x41000670, = nvals=3D0x0,
nn=3D1) at ../../../r24/servers/slapd/attr.c:394
#4 0x0000000000441a06 in attr_merge_one (e=3D0xb72c08, desc=3D0x8b3780,=
val=3D0x41000670, nval=3D0x0)
at ../../../r24/servers/slapd/attr.c:599
#5 0x000000000043ea0f in slap_add_opattrs (op=3D0x965ec0, text=3D<va= lue optimized
out>, textbuf=3D<value optimized out>,
textlen=3D<value optimized out>, manage_ctxcsn=3D<val= ue optimized out>) at
../../../r24/servers/slapd/add.c:664
#6 0x00000000004d9c42 in hdb_add (op=3D0x965ec0, rs=3D0x41000ca0) at ad= d.c:108
#7 0x000000000043f1a6 in fe_op_add (op=3D0x965ec0, rs=3D0x41000ca0) at<= br> ../../../r24/servers/slapd/add.c:334
#8 0x000000000043fa12 in do_add (op=3D0x965ec0, rs=3D0x41000ca0) at
../../../r24/servers/slapd/add.c:194
#9 0x00000000004383a7 in connection_operation (ctx=3D0x41000de0,
arg_v=3D0x965ec0) at ../../../r24/servers/slapd/connection.c:1084
#10 0x00000000004388cf in connection_read_thread (ctx=3D0x41000de0, argv=3D0x= c) at
../../../r24/servers/slapd/connection.c:1211
#11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=3D0x8bf070) at<= br> ../../../r24/libraries/libldap_r/tpool.c:663
#12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0
#13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6
#14 0x0000000000000000 in ?? ()

It was adding the createTimestamp attribute, without providing normalized
values. slap_add_opattrs was written before the generalizedTimeNormalize
function was written... I suspect there will be a fair number of cases that need to be cleaned up. I don't have time at the moment to chase them all = down.
Anyone else want to jump in here? If not, we may have to push this back a bit= .
Note that this patch will probably require a fair number of databases to be reloaded.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

--------------050600010007030200030106
Content-Type: text/plain;
name=3D"dif.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename=3D"dif.txt"

Index: attr.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v
retrieving revision 1.112.2.7<= /a>
diff -u -r1.112.2.7 attr.c
--- attr.c 11 Feb 2008 23:26:43 -0000 = ;1.112.2.7
+++ attr.c 30 May 2008 09:33:43 -0000
@@ -366,8 +366,39 @@
BerVarray nvals,
int nn )
{
- int i;
BerVarray v2;
+ int i;
+
+ {
+ /* FIXME: if the schema ha= s been edited, and an equality matching rule
+ * has been added or = removed from the attribute definition, the database
+ * values may no long= er be in sync with our expectations. Currently this
+ * means the DB must = be reloaded.
+ */
+ int have_norm, have_nval, = new_nval;
+ have_norm =3D a->a_desc= ->ad_type->sat_equality->smr_normalize !=3D NULL;

<= br>Not all attributes have an equality matching rule. This causes your = patch to segfault since sat_equality is NULL:

have_norm =3D a->a_desc->ad_type->sat_equality->= smr_normalize !=3D NULL;

This seems to be a better way to generate have_norm:

have_norm =3D a->a_desc->a= d_type->sat_equality !=3D NULL &&
&= nbsp; a->a_desc->ad_type->sat_equality->s= mr_normalize !=3D NULL;

Once that is fixed the con= fig backend causes an assert for me when it attempts to add createTimestamp, = which is exactly the problem you describe.

I'll create a patch that addresses any of these normalization issues = that I can identify and send it to one of the openldap lists. Would ope= nldap-its or openldap-devel be preferable?

+ have_nval =3D a->a_nval= s !=3D a->a_vals;
+ new_nval =3D nvals !=3D NU= LL;
+
+ /* this check is only rele= vant if any values already exist */
+ if ( a->a_vals !=3D NUL= L && have_norm !=3D have_nval ) {
+ = ; Debug(LDAP_DEBUG_ANY,
+ = ; "attr_valadd: database inconsistent with s= chema definition of %s, reload the DB\n",
+ = ; a->a_desc->ad= _cname.bv_val, 0, 0 );
+ = ; return LDAP_OTHER;
+ = ; /* no need to compare have_nval with new_nval; by transitivity they will ma= tch if
+ = ; * the above check and the following check succeed.
+ = ; */
+ }
+
+ assert( have_norm =3D=3D n= ew_nval );
+ if ( have_norm !=3D new_nv= al ) {
+ = ; Debug(LDAP_DEBUG_ANY,
+ = ; "attr_valadd: new values of %s not properl= y normalized (should never happen!)\n",
+ = ; a->a_desc->ad= _cname.bv_val, 0, 0 );
+ = ; return LDAP_OTHER;
+ }
+ }

v2 =3D (BerVarray) SLAP_REALLOC( (char *) a->a= _vals,
(a->= a_numvals + nn + 1) * sizeof(struct berval) );
@@ -469,15 +500,6 @@

if ( *a =3D=3D NULL ) {
*a =3D attr_alloc( de= sc );
- } else {
- /*
- * FIXME: if the attr= ibute already exists, the presence
- * of nvals and the v= alue of (*a)->a_nvals must be consistent
- */
- assert( ( nvals =3D=3D NUL= L && (*a)->a_nvals =3D=3D (*a)->a_vals )
- = ; || ( nvals !=3D NULL && (
- = ; ( (*a)->a_vals = =3D=3D NULL && (*a)->a_nvals =3D=3D NULL )
- = ; || ( (*a)->a_nva= ls !=3D (*a)->a_vals ) ) ) );
}

if ( vals !=3D NULL ) {

--------------050600010007030200030106--

--
Thanks,
Sean Burford ------=3D_Part_7327_2415938.1212167698754-- --===============5820745493737057365==-- From hyc@symas.com Fri May 30 17:51:39 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 17:51:39 +0000 Message-ID: <200805301751.m4UHpdsa097787@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6228782186583100687==" --===============6228782186583100687== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sean Burford wrote: > Not all attributes have an equality matching rule. This causes your > patch to segfault since sat_equality is NULL: > > have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL; > > > This seems to be a better way to generate have_norm: > > have_norm = a->a_desc->ad_type->sat_equality != NULL && > a->a_desc->ad_type->sat_equality->smr_normalize != NULL; Thanks, looks fine. > Once that is fixed the config backend causes an assert for me when it > attempts to add createTimestamp, which is exactly the problem you describe. > > I'll create a patch that addresses any of these normalization issues > that I can identify and send it to one of the openldap lists. Would > openldap-its or openldap-devel be preferable? Just continue to reply to this ITS for now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6228782186583100687==-- From unix.gurus@gmail.com Fri May 30 23:49:27 2008 From: unix.gurus@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Fri, 30 May 2008 23:49:27 +0000 Message-ID: <200805302349.m4UNnREn036353@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7214912691769261649==" --===============7214912691769261649== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Fri, May 30, 2008 at 2:40 AM, wrote: > > I wrote the attached patch for the original issue. Unfortunately it asserted > right away: ... > It was adding the createTimestamp attribute, without providing normalized > values. slap_add_opattrs was written before the generalizedTimeNormalize > function was written... I suspect there will be a fair number of cases that > need to be cleaned up. I don't have time at the moment to chase them all do= wn. > Anyone else want to jump in here? If not, we may have to push this back a b= it. I've modified my copy of the source to normalize data where needed. slapd starts up and my test can run. With the old assertion in place it fails exactly as it did before, because the old attr_merge() assertion runs before your new attr_valadd() normalization check. Removing the old attr_merge() assertion results in your new attr_valadd() check being triggered. Removing the old assertion looks safe, since attr_merge() calls attr_valadd() almost immediately after the assertion anyway. With these changes, running my test script from the original tarball results = in: bdb_modify_internal: add testAttribute attr_valadd: database inconsistent with schema definition of testAttribute, reload the DB bdb_modify_internal: 80 modify/add: testAttribute: merge error (80) hdb_modify: modify failed (80) I'm working through 'make test' now to find more instances that need fixing. After that I'll send some patches. > Note that this patch will probably require a fair number of databases to be > reloaded. I'm not even sure that attributes can be automatically renormalized when a problem is detected, since bugs (eg. with the generation of timestamps, CSNs or referalls) can also trigger the normalization checks. -- Thanks, Sean Burford --===============7214912691769261649==-- From unix.gurus@gmail.com Sat May 31 01:32:15 2008 From: unix.gurus@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Sat, 31 May 2008 01:32:14 +0000 Message-ID: <200805310132.m4V1WECT040521@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5480967268621943701==" --===============5480967268621943701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm having some trouble working out where to set the normalized value for ContextCSN in the modlist for the syncrepl refresh consumer (test017-syncreplication-refresh fails). The assertion backtrace looks like this: #0 0x00007f472879d095 in raise () from /lib/libc.so.6 #1 0x00007f472879eaf0 in abort () from /lib/libc.so.6 #2 0x00007f47287962df in __assert_fail () from /lib/libc.so.6 #3 0x0000000000425903 in attr_valadd (a=3D0x8fb380, vals=3D0xc72130, nvals=3D0x0, nn=3D1) at attr.c:398 #4 0x000000000046714c in modify_add_values (e=3D0x41ff5bb0, mod=3D0x41ff60e0, permissive=3D0, text=3D0x41ff6090, textbuf=3D0x41ff5cb0 "", textlen=3D256) at mods.c:155 #5 0x000000000048147d in bdb_modify_internal (op=3D0x41ff6780, tid=3D0xc71f50, modlist=3D0x41ff60e0, e=3D0x41ff5bb0, text=3D0x41ff6090, textbuf=3D0x41ff5cb0 "", textlen=3D256) at modify.c:133 #6 0x0000000000481f6d in bdb_modify (op=3D0x41ff6780, rs=3D0x41ff6070) at modify.c:578 #7 0x0000000000477d32 in overlay_op_walk (op=3D0x41ff6780, rs=3D0x41ff6070, which=3Dop_modify, oi=3D0x858990, on=3D0x0) at backover.c:646 #8 0x00000000004782b3 in over_op_func (op=3D0x41ff6780, rs=3D0x41ff6070, which=3Dop_modify) at backover.c:698 #9 0x000000000046dc59 in syncrepl_updateCookie (si=3D0x858560, op=3D0x249e, pdn=3D, syncCookie=3D0x41ff6310) at syncrepl.c:2785 #10 0x0000000000472bea in do_syncrep2 (op=3D0x41ff6780, si=3D0x858560) at syncrepl.c:961 #11 0x0000000000475072 in do_syncrepl (ctx=3D0x0, arg=3D0x8588f0) at syncrepl= .c:1276 #12 0x00000000004daa4a in ldap_int_thread_pool_wrapper (xpool=3D0x82e440) at tpool.c:663 #13 0x00007f47296d03f7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f4728842b2d in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () In frame 3 a->a_desc->ad_type->sat_equality has a value but nvals has not been set, which is why the assertion triggers: (gdb) print a->a_desc->ad_type->sat_equality $39 =3D (MatchingRule *) 0x821be0 Way back in frame 10 do_syncrepl passes a modlist containing an unnormalized contextCSN to do_syncrep2, leading me to believe that I've missed something in syncrepl.c: (gdb) print *op->o_request->oq_modify->rs_mods->rs_modlist $44 =3D {sml_mod =3D {sm_desc =3D 0x824b70, sm_values =3D 0xc72130, sm_nvalues =3D 0x0, sm_numvals =3D 1, sm_op =3D 2, sm_flags =3D 0, sm_type =3D {bv_len = =3D 10, bv_val =3D 0x824be0 "contextCSN"}}, sml_next =3D 0x0} The debug output up to the assertion is: slap_queue_csn: queing 0xc72ae0 20080531010928.580166Z#000000#000#000000 daemon: epoll: listen=3D10 active_threads=3D0 tvp=3Dzero =3D> bdb_entry_get: ndn: "dc=3Dexample,dc=3Dcom" =3D> bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("dc=3Dexample,dc=3Dcom") =3D> bdb_entry_get: found entry: "dc=3Dexample,dc=3Dcom" bdb_entry_get: rc=3D0 bdb_modify: dc=3Dexample,dc=3Dcom bdb_dn2entry("dc=3Dexample,dc=3Dcom") bdb_modify_internal: 0x00000001: dc=3Dexample,dc=3Dcom <=3D acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN slapd: attr.c:398: attr_valadd: Assertion `have_norm =3D=3D new_nval' failed. --=20 Thanks, Sean Burford --===============5480967268621943701==-- From hyc@symas.com Sat May 31 13:57:48 2008 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#5540) Normalization assertion in attr.c Date: Sat, 31 May 2008 13:57:48 +0000 Message-ID: <200805311357.m4VDvmrK068701@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5528918455079687122==" --===============5528918455079687122== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sean Burford wrote: > Hi, > > On Fri, May 30, 2008 at 2:40 AM, wrote: >> I wrote the attached patch for the original issue. Unfortunately it assert= ed >> right away: > ... >> It was adding the createTimestamp attribute, without providing normalized >> values. slap_add_opattrs was written before the generalizedTimeNormalize >> function was written... I suspect there will be a fair number of cases that >> need to be cleaned up. I don't have time at the moment to chase them all d= own. >> Anyone else want to jump in here? If not, we may have to push this back a = bit. > > I've modified my copy of the source to normalize data where needed. > slapd starts up and my test can run. With the old assertion in place > it fails exactly as it did before, because the old attr_merge() > assertion runs before your new attr_valadd() normalization check. That aspect of the patch is not optional. The old check is in the wrong place= =20 and must be removed. It misses the other places where attrs are being added, = while attr_valadd catches all of them. > Removing the old attr_merge() assertion results in your new > attr_valadd() check being triggered. Removing the old assertion looks > safe, since attr_merge() calls attr_valadd() almost immediately after > the assertion anyway. > > With these changes, running my test script from the original tarball result= s in: > bdb_modify_internal: add testAttribute > attr_valadd: database inconsistent with schema definition of > testAttribute, reload the DB > bdb_modify_internal: 80 modify/add: testAttribute: merge error (80) > hdb_modify: modify failed (80) > > I'm working through 'make test' now to find more instances that need > fixing. After that I'll send some patches. > >> Note that this patch will probably require a fair number of databases to be >> reloaded. > > I'm not even sure that attributes can be automatically renormalized > when a problem is detected, since bugs (eg. with the generation of > timestamps, CSNs or referalls) can also trigger the normalization > checks. I think it's important to continue to assert as in my patch, at least at this= =20 stage, so we can catch all of those bugs. I also don't think we can silently = renormalize just the cases that the "reload the DB" message detects, because = that's obviously only going to happen on entries that are explicitly modified= ,=20 and the rest of the DB will still have problems. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============5528918455079687122==-- From pierangelo.masarati@sys-net.it Sat May 31 18:59:11 2008 From: pierangelo.masarati@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5533) test035-meta crashes --without-threads Date: Sat, 31 May 2008 18:59:11 +0000 Message-ID: <200805311859.m4VIxBkb084630@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7860304694396592278==" --===============7860304694396592278== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: > >> Isn't this just a duplicate of ITS#5489? >> > > Apparently not. Got it again at 4th run with daemon.c 1.380.2.12. > Also in a somewhat patched HEAD with the same configuration. > > Hm, the crashes happen for extended operations. So far > 6 times "Passwd ExOp failed (1)!", once "WhoAmI failed (49)!". > I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only? 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 --------------------------------------- --===============7860304694396592278==-- From h.b.furuseth@usit.uio.no Sat May 31 20:38:19 2008 From: h.b.furuseth@usit.uio.no To: openldap-bugs@openldap.org Subject: Re: (ITS#5533) test035-meta crashes --without-threads Date: Sat, 31 May 2008 20:38:18 +0000 Message-ID: <200805312038.m4VKcIUH088288@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0888270059954985274==" --===============0888270059954985274== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit pierangelo.masarati(a)sys-net.it writes: > I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only? Still happens in HEAD as well as RE24. Not RE23 though. -- Hallvard --===============0888270059954985274==-- From pierangelo.masarati@sys-net.it Sat May 31 20:39:51 2008 From: pierangelo.masarati@sys-net.it To: openldap-bugs@openldap.org Subject: Re: (ITS#5533) test035-meta crashes --without-threads Date: Sat, 31 May 2008 20:39:51 +0000 Message-ID: <200805312039.m4VKdp9W088950@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5619167176819425977==" --===============5619167176819425977== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > pierangelo.masarati(a)sys-net.it writes: > >> I couldn't reproduce this issue with HEAD; do you confirm it's a re24 only? >> > > Still happens in HEAD as well as RE24. Not RE23 though. > Odd. I've been running test035 in HEAD for >100 times after rebuilding --without-threads with no failure. Anything I might be missing? 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 --------------------------------------- --===============5619167176819425977==--