From rmeggins at redhat.com Mon Mar 2 18:16:33 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 02 Mar 2009 11:16:33 -0700 Subject: [Fedora-directory-devel] Please review: Bug 483660 - Replication and Sync agreement edit should not allow change to/from LDAPS Message-ID: <49AC2281.7090000@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=483660 Resolves: bug 483660 Bug Description: Replication and Sync agreement edit should not allow change to/from LDAPS Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The problem is that there is no way to change the port number in this panel, so if you change to/from LDAPS, there is no way to supply the correct port number. If the agreement was created with LDAPS, disable the LDAP and StartTLS fields, and vice versa. Platforms tested: RHEL5 Flag Day: no Doc impact: Yes https://bugzilla.redhat.com/attachment.cgi?id=333769&action=diff From rmeggins at redhat.com Mon Mar 2 18:17:56 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 02 Mar 2009 11:17:56 -0700 Subject: [Fedora-directory-devel] Please review: Bug 481213 - Update replication, winsync, chaining online help about connections and authentication Message-ID: <49AC22D4.8030302@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=481213 Resolves: bug 481213 Bug Description: Update replication, winsync, chaining online help about connections and authentication Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Updated the online help to reflect the new UI. Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=333770&action=diff From rmeggins at redhat.com Wed Mar 4 17:45:49 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 04 Mar 2009 10:45:49 -0700 Subject: [Fedora-directory-devel] Please review: Bug 487425 - slapd crashes after changelog is moved Message-ID: <49AEBE4D.80503@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=487425 Resolves: bug 487425 Bug Description: slapd crashes after changelog is moved Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: There are a number of real fixes, mixed in with many changes for debugging and instrumentation. 1) When the update thread gets the changelog iterator, it will use _cl5AddThread to increment the count of threads holding an open handle to the changelog. When it releases the iterator, or if there were some error acquiring the database handle, it will decrement the thread count. The way it used to work was that it would increment the thread count when retrieving the DB object, but then would immediately decrement it, meaning it had an open handle to the database, but there was no way for the changelog code to know that (except via the reference count on the DB object itself). https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec4 https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec5 https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec6 2) Changed the AddThread code to increment the thread count outside of the state lock - this better fits the semantics of the other uses of threadcount which are outside of the lock. https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec12 3) The changelog code that closes the databases was not closing things down in the correct order. The first thing it must do is wait for all threads with open database handles or otherwise accessing the database to terminate. Once that is done, it can call _cl5DBClose() to actually close all of the databases. Otherwise, a race condition could cause a database to be accessed after it has been closed. https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec16 4) Added clcache cleanup code, and made it possible to re-init the clcache. The clcache was not designed to be dynamically closed and opened. clcache is init-ed in _cl5Open - https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec8 clcache_init is re-entrant - https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_clcache.c_sec1 Added more code to clean up the clcache - https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_clcache.c_sec4 https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_clcache.c_sec5 Delete the clcache in _cl5Delete - https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_api.c_sec18 5) The clcache stores the current buffer in a thread private storage area. If the clcache has been re-initialized, this buffer is also invalid and the clcache code must get a new buffer. https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff#ldapserver/ldap/servers/plugins/replication/cl5_clcache.c_sec2 Platforms tested: RHEL5 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=334019&action=diff From rmeggins at redhat.com Mon Mar 16 23:57:57 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Mar 2009 17:57:57 -0600 Subject: [Fedora-directory-devel] Please review: Bug 482892 - Passsync service start and stop messages in Windows event viewer are not logged correctly Message-ID: <49BEE785.1010200@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=482892 Resolves: bug 482892 Bug Description: Passsync service start and stop messages in Windows event viewer are not logged correctly Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: For some reason, the code was not detecting that the service had already been installed and was installing it again. We do not need to install the service in this code, that is done in the .msi file now. I just got rid of that old code. Platforms tested: Windows 2003 Server Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=335457&action=diff From nhosoi at redhat.com Thu Mar 19 21:19:29 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 19 Mar 2009 14:19:29 -0700 Subject: [Fedora-directory-devel] Please review: [Bug 491215] mmldif crashes in PK11_CreateDigestContext In-Reply-To: References: Message-ID: <49C2B6E1.1080401@redhat.com> Summary: mmldif crashes in PK11_CreateDigestContext https://bugzilla.redhat.com/show_bug.cgi?id=491215 Description of problem: Reported by Neuron Ring. 1. I need to merge to input files using mmldif tool 2. I m exporting it to a ldif file using db2ldif tool /opt/dirsrv/slapd- /db2ldif -n /opt/dirsrv/slapd- /db2ldif -n 3. I got two ldif files by exporting two directory server instance databases. One.ldif dn: sn=Jensen,dc=siroe,dc=com objectclass: top objectclass: person cn: Babs Jensen sn: Jensen telephoneNumber: 555-5550 createTimestamp: 100 dn: sn=Minsky,dc=siroe,dc=com objectclass: top objectclass: person cn: Pete Minsky sn: Minsky telephoneNumber: 555-5551 createTimestamp: 100 dn: sn=Rose,dc=siroe,dc=com objectclass: top objectclass: person cn: Paula Rose sn: Rose telephoneNumber: 555-5552 createTimestamp: 100 Two.ldif dn: sn=Jensen,dc=siroe,dc=com objectclass: top objectclass: person cn: Babs Jensen sn: Jensen telephoneNumber: 555-5550 createTimestamp: 100 dn: sn=Minsky,dc=siroe,dc=com objectclass: top objectclass: person cn: Pete Minsky sn: Minsky telephoneNumber: 555-5559 modifyTimestamp: 200 dn: sn=Morris,dc=siroe,dc=com objectclass: top objectclass: person cn: Ted Morris sn: Morris telephoneNumber: 555-5558 createTimestamp: 200 dn: sn=Rose,dc=siroe,dc=com objectclass: nsTombstone deleteTimestamp: 200 4. Now I m trying to use mmldif tool. 5. /opt/dirsrv/bin/mmldif -c -D -o /home/neuronring/output.ldif /home/ neuronring/one.ldif /home/ neuronring/two.ldif 6. Finally everything IN VAIN, I got the following error: [18/Mar/2009:11:35:04 +051800] - finger printing directory 0 [18/Mar/2009:11:35:04 +051800] - db0: dn: sn=Jensen,dc=siroe,dc=com /opt/dirsrv/bin/mmldif[50]: 18247 Memory fault(coredump) The following files are created in my path. 1. one.ldif.delta 2. two.ldif.delta These two files has no data 0 bytes size. 3. core ? size 1882552 bytes Even I tried exporting the database with ?r option (for replica) after stopping the instance. I m getting this error continuously with different error numbers like, /opt/dirsrv/bin/mmldif[50]: 10854 Memory fault(coredump). Somebody please suggest me to resolve this issue. Thanks in advance, Neuron Ring. [Stacktrace from the crash] Core was generated by `/usr/bin/mmldif-bin -o exampleM.ldif ./example0.ldif ./example1.ldif'. Program terminated with signal 11, Segmentation fault. [New process 31424] #0 0x00007f57fac11acb in NSSRWLock_LockRead_Util (rwlock=0x0) at nssrwlk.c:177 177 PZ_Lock(rwlock->rw_lock); Missing separate debuginfos, use: debuginfo-install cyrus-sasl.x86_64 e2fsprogs.x86_64 keyutils.x86_64 krb5.x86_64 libselinux.x86_64 svrcore.x86_64 (gdb) bt #0 0x00007f57fac11acb in NSSRWLock_LockRead_Util (rwlock=0x0) at nssrwlk.c:177 #1 0x00007f57fb0791bb in SECMOD_GetReadLock (modLock=0x0) at pk11list.c:71 #2 0x00007f57fb09d43e in PK11_GetAllTokens (type=544, needRW=0, loadCerts=1, wincx=0x0) at pk11slot.c:1786 #3 0x00007f57fb09d67a in PK11_GetBestSlotMultiple (type=0x7fff03620438, mech_count=1, wincx=0x0) at pk11slot.c:1876 #4 0x00007f57fb09d8e0 in PK11_GetBestSlot (type=544, wincx=0x0) at pk11slot.c:1937 #5 0x00007f57fb07741a in PK11_CreateDigestContext (hashAlg=SEC_OID_SHA1) at pk11cxt.c:411 #6 0x0000000000402d99 in hashname (seed=-76 '?', attrib=0x7f57fa686cb0, hashkey=0x7fff03620660 "?\212?\034<") at ldap/servers/slapd/tools/mmldif.c:936 #7 0x00000000004014b0 in mm_diff (statsp=0x7fff036206c0) at ldap/servers/slapd/tools/mmldif.c:375 #8 0x00000000004045f5 in main (argc=5, argv=0x7fff03620828) at ldap/servers/slapd/tools/mmldif.c:1479 Cause: secmod module list / module list lock is NULL. [Proposed fix] Created an attachment (id=335932) --> (https://bugzilla.redhat.com/attachment.cgi?id=335932) cvs diff ldapserver/ldap/servers/slapd/tools/mmldif.c Description: NSS was not initialized. Since cert db, key db, or secmod db are not needed, changed to call NSS_NoDB_Init to initialize NSS. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From audun.roe at kantega.no Tue Mar 31 14:56:10 2009 From: audun.roe at kantega.no (=?iso-8859-1?Q?Audun_R=F8e?=) Date: Tue, 31 Mar 2009 16:56:10 +0200 Subject: [Fedora-directory-devel] aci cache overflown problem - suggested patch for acl.h Message-ID: <72326A70FE1B0842A98E27C0CA3F291C731BC1@exchange.mogul.no.> Hey, We're in the process of replacing an old Sun Directory Server 5.2 deployment. In our preliminary tests using FDS 1.1.0 (this was back in Q2 2008 or so), we saw lots of "aci cache overflown" messages in the log for some users, and performance would basically drop to unacceptable levels. I previously posted about the issue to the user-list in early May 2008, though in retrospect the mail probably should've gone here. It's archived at http://www.mailinglistarchive.com/fedora-directory-users at redhat.com/msg02612.html if anyone's interested) Anyway, searching the cvs tree for the log message and bumping ACLPB_MAX_SELECTED_ACLS from 200 to 2000 just happened to solve our problem. The change was made as a long-shot in the dark without any insight into the code-base, i.e. we don't really have any broad understanding of how and where it's used. It just seemingly works. During our testing, we have not seen side-effects though we don't really have any experience with the unmodified server. It just wasn't usable for us with the legacy ldap-structure we have. I've attached a patch for the one-line change we made, based on the source RPM for fds-base-1.1.3. What are your thoughts on including this in future revisions? If the patch is unacceptable, would you be more prepared to accept a contribution making this configurable from dse.ldif? Assuming neither option is acceptable and the current value of 200 is locked, I would very much like to hear the reasoning, as obviously, even if things seem to work, the apparent shortage of other people bumping into this problem is slightly worrying (our directory has upwards of 1500 aci attrs - count made with a quick grep -c "aci:" on an ldif exported from the old Sun ldap). -- Audun R?e mail: audun.roe at kantega.no -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aclpb_max_selected_acls.patch Type: application/octet-stream Size: 639 bytes Desc: aclpb_max_selected_acls.patch URL: From rmeggins at redhat.com Tue Mar 31 15:03:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 31 Mar 2009 09:03:45 -0600 Subject: [Fedora-directory-devel] aci cache overflown problem - suggested patch for acl.h In-Reply-To: <72326A70FE1B0842A98E27C0CA3F291C731BC1@exchange.mogul.no.> References: <72326A70FE1B0842A98E27C0CA3F291C731BC1@exchange.mogul.no.> Message-ID: <49D230D1.4040804@redhat.com> Audun R?e wrote: > > Hey, > > > > We're in the process of replacing an old Sun Directory Server 5.2 > deployment. In our preliminary tests using FDS 1.1.0 (this was back in > Q2 2008 or so), we saw lots of "aci cache overflown" messages in the > log for some users, and performance would basically drop to > unacceptable levels. I previously posted about the issue to the > user-list in early May 2008, though in retrospect the mail probably > should've gone here. It's archived at > http://www.mailinglistarchive.com/fedora-directory-users at redhat.com/msg02612.html > if anyone's interested) > > > > Anyway, searching the cvs tree for the log message and bumping > ACLPB_MAX_SELECTED_ACLS from 200 to 2000 just happened to solve our > problem. The change was made as a long-shot in the dark without any > insight into the code-base, i.e. we don't really have any broad > understanding of how and where it's used. It just seemingly works. > During our testing, we have not seen side-effects though we don't > really have any experience with the unmodified server. It just wasn't > usable for us with the legacy ldap-structure we have. > > > > I've attached a patch for the one-line change we made, based on the > source RPM for fds-base-1.1.3. What are your thoughts on including > this in future revisions? If the patch is unacceptable, would you be > more prepared to accept a contribution making this configurable from > dse.ldif? > Yes. This seems like something that should be configurable. We would welcome your contribution. Step 1) Please review http://directory.fedoraproject.org/wiki/Contributing Step 2) Please open a bug in bugzilla.redhat.com for Fedora Directory Server - you can attach patches, tests, etc. to the bug (after we receive confirmation that you have signed and submitted the CLA) > > Assuming neither option is acceptable and the current value of 200 is > locked, I would very much like to hear the reasoning, as obviously, > even if things seem to work, the apparent shortage of other people > bumping into this problem is slightly worrying (our directory has > upwards of 1500 aci attrs - count made with a quick grep -c "aci:" on > an ldif exported from the old Sun ldap). > > > > > > -- > > Audun R?e > > mail: audun.roe at kantega.no > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: