openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 02 Mar '09

02 Mar '09

I would like to end the patch of dnssrv.c by implementing the weighty notion in SRV searchs (according to the rfc2782); but the use of a file disk to store the previous answers does seem to me a very successful solution. Would anybody have better one idea?...

1 0

Re: (ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 9:28 PM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > It's working just fine here (HEAD/re24). The main differences in > configuration are modules (everything here is built statically) and few > paths, URIs and so. You should walk through it with a debugger, after > identifying (with -d -1) how far it gets before going berserk. But -d -1, as I pasted before, didn't actually show anything I saw useful at all. And I don't have access to their system. :/ Once my servers are back online, I can play with this more. I'd guess it's one of those weird load dependencies we've been seeing. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5984) chain/syncprov problems
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)zimbra.com wrote: > Same problem once it is changed to: > > overlay chain > chain-uri "ldap://xxx" > chain-idassert-bind bindmethod="simple" > binddn="cn=Manager,dc=XYZ,dc=com" > credentials="secrets" > mode="self" > chain-tls start > chain-return-error TRUE > > > slapd still fails to start as long as both chain and syncprov are enabled. > It also fails to log any reason as to why it's failing to start up. It's working just fine here (HEAD/re24). The main differences in configuration are modules (everything here is built statically) and few paths, URIs and so. You should walk through it with a debugger, after identifying (with -d -1) how far it gets before going berserk. 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#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 7:58 PM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> chain-idassert-bind >> bindmethod="simple" >> binddn="cn=Manager,dc=XYX,dc=com" >> credentials="secret" >> mode="self" >> chain-tls start >> chain-return-error TRUE > > chain-tls start > chain-return-error TRUE > > are not allowed within a "chain-idassert-bind"; probably the leading > whitespace is not intended. Same problem once it is changed to: overlay chain chain-uri "ldap://xxx" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XYZ,dc=com" credentials="secrets" mode="self" chain-tls start chain-return-error TRUE slapd still fails to start as long as both chain and syncprov are enabled. It also fails to log any reason as to why it's failing to start up. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5985) replication lockout with syncrepl
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 7:59 PM +0000 ando(a)sys-net.it wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3/2.4/HEAD >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> I noticed back in testing with OpenLDAP 2.3 that if a master gets a high >> rate of changes, and you have 3+ replicas, usually 2 replicas will end >> up getting all of the changes while the 3rd+ replicas have to wait until >> those 2 finish before getting changes. If the high rate of changes goes >> on for a long enough period of time, this can cause the other replicas >> to get so far out of sync that it is more efficient to reload them than >> to wait on them to re-sync. I discussed this with Howard, and in >> reviewing the code, he sees there's an underlying design issue with >> updates that is causing this. His comments: >> >> Once a thread for a psearch wakes up, it sends all the changes that were >> queued so it may hog an entire thread for a long time before the next >> psearch comes off the queue > > Is this supposed to hit 2.4 as well, as you indicated in the ITS' > "Version"? Yes. It affects OL2.3, OL2.4, and remains this way in current HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5985) replication lockout with syncrepl
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3/2.4/HEAD > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I noticed back in testing with OpenLDAP 2.3 that if a master gets a high rate of > changes, and you have 3+ replicas, usually 2 replicas will end up getting all of > the changes while the 3rd+ replicas have to wait until those 2 finish before > getting changes. If the high rate of changes goes on for a long enough period > of time, this can cause the other replicas to get so far out of sync that it is > more efficient to reload them than to wait on them to re-sync. I discussed this > with Howard, and in reviewing the code, he sees there's an underlying design > issue with updates that is causing this. His comments: > > Once a thread for a psearch wakes up, it sends all the changes that were queued > so it may hog an entire thread for a long time before the next psearch comes off > the queue Is this supposed to hit 2.4 as well, as you indicated in the ITS' "Version"? 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#5984) chain/syncprov problems
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)zimbra.com wrote: > chain-idassert-bind > bindmethod="simple" > binddn="cn=Manager,dc=XYX,dc=com" > credentials="secret" > mode="self" > chain-tls start > chain-return-error TRUE chain-tls start chain-return-error TRUE are not allowed within a "chain-idassert-bind"; probably the leading whitespace is not intended. 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

(ITS#5985) replication lockout with syncrepl
by quanah＠OpenLDAP.org 02 Mar '09

02 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.3/2.4/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I noticed back in testing with OpenLDAP 2.3 that if a master gets a high rate of changes, and you have 3+ replicas, usually 2 replicas will end up getting all of the changes while the 3rd+ replicas have to wait until those 2 finish before getting changes. If the high rate of changes goes on for a long enough period of time, this can cause the other replicas to get so far out of sync that it is more efficient to reload them than to wait on them to re-sync. I discussed this with Howard, and in reviewing the code, he sees there's an underlying design issue with updates that is causing this. His comments: Once a thread for a psearch wakes up, it sends all the changes that were queued so it may hog an entire thread for a long time before the next psearch comes off the queue

1 0

(ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In a discussion with a user on the #openldap channel in IRC, they noted that if they had both the chain and syncprov overlays enabled in their configuration, slapd would refuse to start. Commenting out either one allowed slapd to start. I didn't see any obvious misconfigurations on their part. Configs as follows: include /usr/local/openldap-2.4.15/etc/openldap/schema/core.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/cosine.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/misc.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/nis.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/dyngroup.schema pidfile /usr/local/openldap-2.4.15/var/run/slapd.pid argsfile /usr/local/openldap-2.4.15/var/run/slapd.args modulepath /usr/local/openldap-2.4.15/libexec/openldap moduleload accesslog.la moduleload auditlog.la moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload dyngroup.la moduleload ppolicy.la moduleload syncprov.la moduleload unique.la # TLS Section TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 TLSCACertificateFile /usr/local/openldap-2.4.15/etc/openldap/cacert.pem TLSCertificateFile /usr/local/openldap-2.4.15/etc/openldap/servercert.pem TLSCertificateKeyFile /usr/local/openldap-2.4.15/etc/openldap/serverkey.pem TLSVerifyClient never security tls=256 password-crypt-salt-format "$1$%.8s$" loglevel 256 loglevel stats sync overlay chain chain-uri "ldap://xxx" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XYX,dc=com" credentials="secret" mode="self" chain-tls start chain-return-error TRUE database bdb suffix "dc=XYZ,dc=com" rootdn "cn=Manager,dc=XYZ,dc=com" rootpw secret directory /usr/local/openldap-2.4.15/var/openldap-data/XYZ.com-slave overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=010 provider=ldap://xxx type=refreshAndPersist interval=00:00:00:05 searchbase="dc=XYZ,dc=com" bindmethod=simple binddn="cn=SyncRepl,dc=XYZ,dc=com" credentials=secret retry="5 5 300 5" starttls=yes tls_reqcert=never slapd -d -1 output wasn't too helpful, either: @(#) $OpenLDAP: slapd 2.4.15 (Mar 2 2009 11:27:50) $ bill@crash:/home/bill/openldap-2.4.15/servers/slapd ldap_pvt_gethostbyname_a: host=crash, r=0 daemon_init: listen on ldap:// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) daemon: listener initialized ldap:// daemon_init: 2 listeners opened ldap_create slapd init: initiated server. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008) bdb_db_init: Initializing BDB database >>> dnPrettyNormal: <dc=XYZ,dc=com> <<< dnPrettyNormal: <dc=XYZ,dc=com>, <dc=XYZ,dc=com> >>> dnPrettyNormal: <cn=Manager,dc=XYZ,dc=com> <<< dnPrettyNormal: <cn=Manager,dc=XYZ,dc=com>, <cn=manager,dc=XYZ,dc=com> >>> dnNormalize: <cn=Manager,dc=XYZ,dc=com> <<< dnNormalize: <cn=manager,dc=XYZ,dc=com> slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 02 Mar '09

02 Mar '09

michael(a)stroeder.com wrote: > mariusp44(a)gmail.com wrote: >> I am running openldap 2.4.11 > > Note that this release is already a bit old. If you're testing it is > more helpful to use a recent release (like 2.4.15 at the moment). The fact is that there is no point in chasing a bug in an old release. If the bug exists in the latest, fine. Otherwise one needs to upgrade anyway, either to the latest release or to the forthcoming when the bug is fixed. 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

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