openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#5846) Support Solaris 10U6 GSS library
by andjo＠ida.liu.se 03 Dec '08

03 Dec '08

Full_Name: Andreas Johansson Version: 2.4.13 OS: Solaris 10 URL: http://www.ida.liu.se/~andjo/tmp/openldap-solaris-gssapi.patch Submission from: (NULL) (2001:6b0:17:f020:203:baff:fe7b:3cfa) The OpenLDAP configure script does not detect the GSSAPI library in Solaris 10 (at least the one in update 6). The library is named gss instead of gssapi or gssapi_krb5. Referenced is a small patch for configure.in to search for gss_wrap in libgss as well.

1 0

Re: (ITS#5839) overlay glue
by Marin.LEHOUELLEUR＠astrium.eads.net 03 Dec '08

03 Dec '08

This is a multi-part message in MIME format. ------_=_NextPart_001_01C95559.E58ECC4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I=20have=20no=20other=20impact=20than=20not=20having=20the=20glued=20bran= ch=20visible=20in LDAPBrowser=20: Search=20queries=20on=20the=20glued=20branch=20works=20perfectly. I'm=20wondering=20about=20the=20proper=20use=20of=20overlay=20glue=20as= =20error=20message appears=20in=20slapd=20log=20(directive=20glue-sub=20ignored). Solution=20offered=20by=20Rein=20is=20good=20looking=20but=20I'll=20have= =20to=20deal=20with=2030 ACLs=20on=20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20con= sumers=20!! I'll=20do=20that=20if=20any=20bug=20shows=20its=20face.=20Still=20better= =20than=20migrating=20the servers=20(gloups,=20oh=20no=20I=20don't=20want=20that). Thank=20you=20for=20helping. M Marin=20Le=20Houelleur Projet=20Pharos=20-=20Capgemini marin.lehouelleur(a)astrium.eads.net 05=2062=2019=2068=2059 Ce=20courriel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut= =20contenir=20des=20informations=20confidentielles=20et/ou=20protegees=20= ou=20dont=20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu= =20ce=20courriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,= =20ni=20l'utiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.= =20Merci=20d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer= =20ce=20courriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20re= sponsabilite=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration= =20ou=20de=20falsification=20de=20ce=20courriel=20lors=20de=20sa=20transm= ission=20par=20voie=20electronique. This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= tial=20and/or=20privileged=20information=20or=20information=20otherwise= =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= =20falsified.=20 --------------------------------------------------------------------- Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France ------_=_NextPart_001_01C95559.E58ECC4C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE=20HTML=20PUBLIC=20"-//W3C//DTD=20HTML=203.2//EN"> <HTML> <HEAD> <META=20HTTP-EQUIV=3D"Content-Type"=20CONTENT=3D"text/html;=20charset=3Du= s-ascii"> <META=20NAME=3D"Generator"=20CONTENT=3D"MS=20Exchange=20Server=20version= =206.5.7653.2"> <TITLE>Re:=20(ITS#5839)=20overlay=20glue</TITLE> </HEAD> <BODY>  <FONT=20SIZE=3D2=20FACE=3D"Arial">I=20have=20no=20other=20impact=20tha= n=20not=20having=20the=20glued=20branch=20visible=20in=20LDAPBrowser=20:<= /FONT> <FONT=20SIZE=3D2=20FACE=3D"Arial">Search=20queries=20on=20the=20glued= =20branch=20works=20perfectly. <FONT=20SIZE=3D2=20FACE=3D"Arial">I'm=20wondering=20about=20the=20pro= per=20use=20of=20overlay=20glue=20as=20error=20message=20appears=20in=20s= lapd=20log=20(directive=20glue-sub=20ignored). <FONT=20SIZE=3D2=20FACE=3D"Arial">Solution=20offered=20by=20Rein=20is= =20good=20looking=20but=20I'll=20have=20to=20deal=20with=2030=20ACLs=20on= =20the=20producer=20side=20as=20I've=20as=20much=20as=2030=20consumers=20= !! <FONT=20SIZE=3D2=20FACE=3D"Arial">I'll=20do=20that=20if=20any=20bug=20= shows=20its=20face.=20Still=20better=20than=20migrating=20the=20servers= =20(gloups,=20oh=20no=20I=20don't=20want=20that). <FONT=20SIZE=3D2=20FACE=3D"Arial">Thank=20you=20for=20helping. <FONT=20SIZE=3D2=20FACE=3D"Arial">M <FONT=20SIZE=3D2=20FACE=3D"Arial">Marin=20Le=20Houelleur <FONT=20SIZE=3D2=20FACE=3D"Arial">Projet=20Pharos=20-=20Capgemini</FO= NT> <FONT=20SIZE=3D2=20FACE=3D"Arial">marin.lehouelleur(a)astrium.eads.net<= /FONT> <FONT=20SIZE=3D2=20FACE=3D"Arial">05=2062=2019=2068=2059 </BODY> </HTML> <table><tr><td=20bgcolor=3D#ffffff><font=20color=3D#000000><pre>Ce=20cour= riel=20(incluant=20ses=20eventuelles=20pieces=20jointes)=20peut=20conteni= r=20des=20informations=20confidentielles=20et/ou=20protegees=20ou=20dont= =20la=20diffusion=20est=20restreinte.=20Si=20vous=20avez=20recu=20ce=20co= urriel=20par=20erreur,=20vous=20ne=20devez=20ni=20le=20copier,=20ni=20l'u= tiliser,=20ni=20en=20divulguer=20le=20contenu=20a=20quiconque.=20Merci=20= d'en=20avertir=20immediatement=20l'expediteur=20et=20d'effacer=20ce=20cou= rriel=20de=20votre=20systeme.=20Astrium=20decline=20toute=20responsabilit= e=20en=20cas=20de=20corruption=20par=20virus,=20d'alteration=20ou=20de=20= falsification=20de=20ce=20courriel=20lors=20de=20sa=20transmission=20par= =20voie=20electronique. This=20email=20(including=20any=20attachments)=20may=20contain=20confiden= tial=20and/or=20privileged=20information=20or=20information=20otherwise= =20protected=20from=20disclosure.=20If=20you=20are=20not=20the=20intended= =20recipient,=20please=20notify=20the=20sender=20immediately,=20do=20not= =20copy=20this=20message=20or=20any=20attachments=20and=20do=20not=20use= =20it=20for=20any=20purpose=20or=20disclose=20its=20content=20to=20any=20= person,=20but=20delete=20this=20message=20and=20any=20attachments=20from= =20your=20system.=20Astrium=20disclaims=20any=20and=20all=20liability=20i= f=20this=20email=20transmission=20was=20virus=20corrupted,=20altered=20or= =20falsified.=20 --------------------------------------------------------------------- Astrium=20SAS=20(393=20341=20516=20RCS=20Paris)=20-=20Siege=20social:=206= =20rue=20Laurent=20Pichat,=2075016=20Paris,=20France</pre></td></t= r></table> ------_=_NextPart_001_01C95559.E58ECC4C--

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs