openldap-bugs December 2008

openldap-bugs@openldap.org

36 participants
131 discussions

Re: (ITS#5841) slapd hanging upon shutdown
by rhafer＠suse.de 03 Dec '08

03 Dec '08

The thread running ldap_pvt_thread_pool_destroy and the one that ran the index task (which was immediately finished after receiving the shutdown signal) are both waiting for the pool->ltp_cond to be signalled. Under normal conditions (slapd is not shutting down) the signal would have been sent by ldap_pvt_thread_pool_resume(), called by the thread that handled the second modify request. But there is an explicit check for pool->ltp_finishing in ldap_pvt_thread_pool_resume(). When pool->ltp_finishing is set this signal is not send. The check for pool->ltp_finishing has been introduced with r1.81 of tpool.c. I am unsure what this was supposed to fix the log message is just: "In pool_resume don't touch the condvar if the pool is tearing down." This patch solves the problem for me, so I am unsure if it'll break other things: --- libraries/libldap_r/tpool.c 10 Mar 2008 12:21:24 -0000 1.97 +++ libraries/libldap_r/tpool.c 3 Dec 2008 14:43:28 -0000 @@ -785,8 +785,7 @@ SET_VARY_OPEN_COUNT(pool); pool->ltp_work_list = &pool->ltp_pending_list; - if (!pool->ltp_finishing) - ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); + ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex); return(0);

1 0

Re: (ITS#5845) Distribution List support for OpenLDAP schema
by andrew.findlay＠skills-1st.co.uk 03 Dec '08

03 Dec '08

On Wed, Dec 03, 2008 at 05:02:52AM +0000, bejnet(a)yahoo.com wrote: > I want to create distribution list in OpenLDAP. Meaning - If I have a group > called admins(a)ldap.com and there are two members - bejoy(a)ldap.com and > bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com = both these members must > get the email. Exchange has this feature. This mail id should have a display > name feature as well - that would show up on search of address books. > > At present the work around is using qmail's schema for this distribution list. I > believe inetOrgPerson schema could have a group version too - which would need a > compulsory attribute called members which must have atleast one member mentioned > under it. I think you have just described groupOfNames. I do not like groupOfNames *because* it makes the member attribute mandatory, which makes management complicated. Anyway, I cannot see this as a defect in OpenLDAP. LDAP schema is extensible: if you want something that is not in the standard set you can add it locally. You say that you have used qmail's schema: is there anything wrong with that? Most LDAP-capable mail systems can be persuaded to use groups as mailing lists, but that is a mail system issue not an OpenLDAP one. It could be argued that simple groups are not rich enough to use for list expansion (no way to keep track of per-member list preferences etc) but if we are going to talk about defining an improved group this is the wrong place to do it: maybe IETF's ldapext list would be better. 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 | -----------------------------------------------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by ando＠sys-net.it 03 Dec '08

03 Dec '08

rhafer(a)suse.de wrote: > Am Mittwoch 03 Dezember 2008 04:10:36 schrieb hyc(a)symas.com: >> On Tue, Dec 02, 2008 at 03:14:28PM +0000, rhafer(a)suse.de wrote: >>> Full_Name: Ralf Haferkamp >>> Version: HEAD, RE24 >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (89.166.134.124) >>> >>> >>> When slapd is shutdown while the online indexing task is active it will >>> stop the indexing task immediately leaving a half created index files >>> behind. Searches that use the index afterwards will return imcomplete >>> results. >>> >>> I wonder if we should wait for the indexing task to complete when >>> shutting down the daemon or if there are any other ways to put the >>> databases and the configuration back into a consistant state. (Apart from >>> manually running slapindex) >> That's documented behavior. (See the Admin Guide: >> If slapd is stopped before the index task completes, indexing >> will have to be manually completed using the slapindex tool. >> >> Generally when people issue a shutdown command to slapd they want it to >> Stop Right Now. I think it would be a bad idea to wait, and I see nothing >> to change here. This ITS should be closed. > Ok, waiting for the index task to complete is a bad idea as it can take very > long to complete. But could we indicate the condition somehow that warn the > user about an incomplete run upon next startup? - the index should be invalidated - slapd, at the next manual startup, should complain about the need to run slapindex first. - in order to allow consistent batch restart with no human intervention, slapd could allow to be restarted without running slapindex first, but without making use of the inconsistent index. my 2c, not volunteering right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by rhafer＠suse.de 03 Dec '08

03 Dec '08

Am Mittwoch 03 Dezember 2008 04:10:36 schrieb hyc(a)symas.com: > On Tue, Dec 02, 2008 at 03:14:28PM +0000, rhafer(a)suse.de wrote: > > Full_Name: Ralf Haferkamp > > Version: HEAD, RE24 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.134.124) > > > > > > When slapd is shutdown while the online indexing task is active it will > > stop the indexing task immediately leaving a half created index files > > behind. Searches that use the index afterwards will return imcomplete > > results. > > > > I wonder if we should wait for the indexing task to complete when > > shutting down the daemon or if there are any other ways to put the > > databases and the configuration back into a consistant state. (Apart from > > manually running slapindex) > > That's documented behavior. (See the Admin Guide: > If slapd is stopped before the index task completes, indexing > will have to be manually completed using the slapindex tool. > > Generally when people issue a shutdown command to slapd they want it to > Stop Right Now. I think it would be a bad idea to wait, and I see nothing > to change here. This ITS should be closed. Ok, waiting for the index task to complete is a bad idea as it can take very long to complete. But could we indicate the condition somehow that warn the user about an incomplete run upon next startup? -- Ralf

1 0

(ITS#5845) Distribution List support for OpenLDAP schema
by bejnet＠yahoo.com 02 Dec '08

02 Dec '08

Full_Name: Bejoy Abraham Mathews Version: 2.4.11 OS: gNewSense Gnu/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.101.252.217) I want to create distribution list in OpenLDAP. Meaning - If I have a group called admins(a)ldap.com and there are two members - bejoy(a)ldap.com and bejnet(a)ldap.com; and mail is sent to admins(a)ldap.com = both these members must get the email. Exchange has this feature. This mail id should have a display name feature as well - that would show up on search of address books. At present the work around is using qmail's schema for this distribution list. I believe inetOrgPerson schema could have a group version too - which would need a compulsory attribute called members which must have atleast one member mentioned under it.

1 0

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 02 Dec '08

02 Dec '08

On Tue, Dec 02, 2008 at 03:14:28PM +0000, rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD, RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.134.124) > > > When slapd is shutdown while the online indexing task is active it will stop the > indexing task immediately leaving a half created index files behind. Searches > that use the index afterwards will return imcomplete results. > > I wonder if we should wait for the indexing task to complete when shutting down > the daemon or if there are any other ways to put the databases and the > configuration back into a consistant state. (Apart from manually running > slapindex) That's documented behavior. (See the Admin Guide: If slapd is stopped before the index task completes, indexing will have to be manually completed using the slapindex tool. Generally when people issue a shutdown command to slapd they want it to Stop Right Now. I think it would be a bad idea to wait, and I see nothing to change here. This ITS should be closed.

1 0

Re: (ITS#5844) bdb backend hangs
by quanah＠zimbra.com 02 Dec '08

02 Dec '08

--On Wednesday, December 03, 2008 1:02 AM +0000 thomas(a)koeller.dyndns.org wrote: > Full_Name: Thomas Koeller > Version: 2.4.13 > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.39.153.46) > > > I just built openldap-2.4.13. Issuing the 'make test' command after > building results in slapadd hanging: What version of BDB? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5844) bdb backend hangs
by thomas＠koeller.dyndns.org 02 Dec '08

02 Dec '08

Full_Name: Thomas Koeller Version: 2.4.13 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.39.153.46) I just built openldap-2.4.13. Issuing the 'make test' command after building results in slapadd hanging: >---------------------------------------------------------------------- bash-3.2$ make test cd tests; make test make[1]: Entering directory `/home/thomas/build/openldap-2.4.13/tests' make[2]: Entering directory `/home/thomas/build/openldap-2.4.13/tests' Initiating LDAP tests for BDB... Running /home/thomas/src/openldap-2.4.13/tests/scripts/all... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch to retrieve the cn=Monitor... dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: cn=Monitor 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.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 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: 3 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: OTP vendorName: The OpenLDAP Project <http://www.openldap.org/> entryDN: subschemaSubentry: cn=Subschema dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor objectClass: monitorServer cn: Monitor description: This subtree contains monitoring/managing objects. description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. monitoredInfo: OpenLDAP: slapd 2.4.13 (Dec 3 2008 01:43:49) >>>>> Test succeeded >>>>> /home/thomas/src/openldap-2.4.13/tests/scripts/test000-rootdse completed OK. >>>>> Starting test001-slapadd ... running defines.sh Running slapadd to build slapd database... *** hangs here *** >---------------------------------------------------------------------- If I ignore this problem and install anyway, I cannot use the bdb backend. If I do, slapd will hang upon any access. However, if I use the ldif backend, slapd works as expected, so I suspect the problem is in the bdb backend. These are my build options: bash-3.2$ ./config.status --version config.status configured by /home/thomas/src/openldap-2.4.13/configure, generated by GNU Autoconf 2.59, with options "'--prefix=/usr' '--enable-crypt' '--enable-bdb=mod' '--enable-hdb=mod' '--enable-ldap=mod' '--enable-monitor=mod' '--enable-null=mod' '--enable-passwd=mod' '--enable-local' '--enable-overlays=mod' '--with-cyrus-sasl' '--with-threads' '--enable-dynamic' '--enable-modules' 'CC=/usr/gcc/bin/gcc' 'CFLAGS=-pipe -O3 -fomit-frame-pointer -march=native -m64' 'CPP=/usr/gcc/bin/cpp' 'LDFLAGS=-O3 -Wl,--enable-new-dtags,--hash-style=gnu'"

1 0

(ITS#5843) Multi-master doesn't replicate deletes under certain circumstances.
by ildefonso_camargo＠yahoo.com 02 Dec '08

02 Dec '08

Full_Name: Jose Ildefonso Camargo Tolosa Version: 2.4.13 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (190.73.138.178) Hi! I just configured multi-master replication (with N=3) for testing purposes, and I just found an annoying problem, under these conditions: 1. Configure a N number of "masters", and have them replicate happily (this is important). 2. Stop slapd service on all of the servers. 3. Start slapd service on any number of servers < N (ie, leave at least one stopped). 4. Delete any entry (yes, it only fails with deletes, you can combine changes: modify, add, and delete, and only deletes will fail to replicate). 5. Stop slapd service on *all of the servers again* (this is the most important part). 6. Start slapd service on all the servers. 7. Look for the deleted entry on the server(s) that you left stopped in steps 3 and 4, the entry is there!, but it isn't on the server(s) that were running in step 3 and 4. You will see that, on the servers that you left down on step 3, the deleted entries are still present. If you leave at least one server up, it replicates just fine, the problem is when you stop all of the masters, and then start them again. If you need further info, just ask! I hope this helps, Ildefonso Camargo

1 0

Re: (ITS#5839) overlay glue
by rein＠OpenLDAP.org 02 Dec '08

02 Dec '08

marin.lehouelleur(a)astrium.eads.net wrote: > Full_Name: Marin Le Houelleur > Version: 2.3.32 > OS: Linux RH5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (140.94.82.30) > > Working for one year now with this version of Openldap. I come to the point I > need to glue different branch of my master to the slaves to manage complexe > filtering that I'm unable to manage with overlay syncrepl filters First of all you should upgrade, preferrable to the latest 2.4 release. There have been a lot of syncrepl fixes since this version. But your config design is likely to not function, as only one syncrepl consumer can reliably be configured within a glued set of databases to replicate from the same consumer. You should instead configure syncrepl on the glue suffix with a simple filter that matches all you replicate (or just leave it out and use the default). Configure ACLs on the master that gives each consumer access to only those entries it should receive. Rein

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2008