March 2010 - openldap-bugs

(ITS#6494) replication doesn't works if directory contains more than one tree

by Ikonta＠yandex.ru

Full_Name: Sergey A. Starikov Version: 2.4.21 OS: FreeBSD 7.2-RELEASE-p4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.229.208.12) Also (currently the main OS) is FreeBSD 6.4-RELEASE-p9. Configuration stored in slapd.conf. Two servers in mirror mode. The slapd.conf is: <includes> serverID pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb <ACLs set (replicator user can read everything in replicated tree)> sizelimit 1024 # ####################################################################### # BDB database definitions ####################################################################### # db #1 (caotus userbase, main database) database bdb suffix "dc=mydomain,dc=ru" rootdn "uid=admin,dc=mydomain,dc=ru" rootpw {SSHA}<some hash> overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/db/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub <and some other indexes> # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=002 provider=ldap://ldapN.mydomain.ru:389 type=refreshOnly interval=00:00:12:00 retry="64 16 256 4" searchbase="dc=mydomain,dc=ru" scope=sub sizelimit=unlimited timelimit=512 schemachecking=on bindmethod=simple binddn="uid=Replicator,ou=People,dc=mydomain,dc=ru" credentials=secret mirrormode on # db #2 (ESPP certs database accesslog) database bdb suffix "cn=accesslog" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/log/openldap-accesslog # Indices to maintain index reqStart eq In described case accesslog overlay works normally. But overlay syncprov is _particularly_ inoperate (transferred only one of about 28 changes in source database). Both in refreshAndPersist and refreshOnly replication modes. If I remove the accesslog overlay from slapd.conf --- replication works as it should. Also, if I try to add instead the accesslog another tree, for example: slapd.conf: ... # db #2 database bdb suffix "dc=public,dc=org" directory /var/db/openldap-db2 # Indices to maintain index objectClass eq <other indexes> ... replication also doesn't works.

13 years

1
0
0 / 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.

by korvus＠comcast.net

On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote: > --On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > >> tjoen wrote: >>> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>>> After some chatter on the mailing list, the problem is now >>>> understood: >>>> - TLS error messages are indeed reported by OpenLDAP: >>>> TLS: could not use key file >>>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >>> ... >>>> - The only way to see these error messages is to start the daemon >>>> with >>>> '-d stats' >>> ... >>>> My suggestions: print the TLS error messages out to syslog, or if >>>> that's not possible, print them to stdout regardless of whether the >>>> daemon is running in the foreground or not. >>> >>> Isn't it in local4.* ? >>> >> >> No, they do not get sent to local4.* - the only TLS message which makes >> it there in this scenario is: slapd[72041]: main: TLS init def ctx >> failed: -1 >> >> Like I said, the ONLY way to get the actual TLS error messages is to run >> the daemon by hand in the foreground with loglevel stats by way of >> 'slapd >> -d stats'. Per the manpage this also prevents slapd from forking: >> -d debug-level >> Turn on debugging as defined by debug-level. If this >> option is specified, even with a zero argument, slapd >> will not fork or disassociate from the invoking >> terminal. >> >> >> Let me know if I'm still not being clear. > > If you are trying to debug an issue, you most certainly should be > running slapd -d <level>... that's why it exists. > > --Quanah > That's a valid point. However, it does not explain why the TLS errors aren't (or "shouldn't be") logged via syslog.

13 years

1
0
0 / 0

Re: (ITS#6493) Broken link in online openldap administrator's guide

by ghenry＠OpenLDAP.org

----- "felix wolfsteller" <felix.wolfsteller(a)intevation.de> wrote: > Full_Name: Felix Wolfsteller > Version: n/a > OS: na/a > URL: http://www.openldap.org/doc/admin24/schema.html > Submission from: (NULL) (212.95.107.190) > > > In the online openldap administrator's guide, section 13.2.1 > ( http://www.openldap.org/doc/admin24/schema.html ) > , > > " http://www.alvestrand.no/harald/objectid/ " > > is referenced, where it should be > > " http://www.alvestrand.no/objectid/ " , i guess. Thanks, will fix. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

13 years

1
0
0 / 0

(ITS#6493) Broken link in online openldap administrator's guide

by felix.wolfsteller＠intevation.de

Full_Name: Felix Wolfsteller Version: n/a OS: na/a URL: http://www.openldap.org/doc/admin24/schema.html Submission from: (NULL) (212.95.107.190) In the online openldap administrator's guide, section 13.2.1 ( http://www.openldap.org/doc/admin24/schema.html ) , " http://www.alvestrand.no/harald/objectid/ " is referenced, where it should be " http://www.alvestrand.no/objectid/ " , i guess.

13 years

1
0
0 / 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.

by quanah＠zimbra.com

--On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > tjoen wrote: >> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>> After some chatter on the mailing list, the problem is now understood: >>> - TLS error messages are indeed reported by OpenLDAP: >>> TLS: could not use key file >>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >> ... >>> - The only way to see these error messages is to start the daemon with >>> '-d stats' >> ... >>> My suggestions: print the TLS error messages out to syslog, or if >>> that's not possible, print them to stdout regardless of whether the >>> daemon is running in the foreground or not. >> >> Isn't it in local4.* ? >> > > No, they do not get sent to local4.* - the only TLS message which makes > it there in this scenario is: slapd[72041]: main: TLS init def ctx > failed: -1 > > Like I said, the ONLY way to get the actual TLS error messages is to run > the daemon by hand in the foreground with loglevel stats by way of 'slapd > -d stats'. Per the manpage this also prevents slapd from forking: > -d debug-level > Turn on debugging as defined by debug-level. If this > option is specified, even with a zero argument, slapd > will not fork or disassociate from the invoking > terminal. > > > Let me know if I'm still not being clear. If you are trying to debug an issue, you most certainly should be running slapd -d <level>... that's why it exists. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

13 years

1
0
0 / 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed

by quanah＠zimbra.com

--On Tuesday, March 16, 2010 8:31 PM +0000 robert.hanson(a)calabrio.com wrote: > Full_Name: Robert Hanson > Version: 2.4.21 > OS: RedHat 4.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.203.208.250) > > > 1) start with an empty database; use slapadd to add a large (3 MB) > database. 2) Use ldapbrowser to delete nearly all the nodes. After this > process, I get to a point where a subnode can't be deleted; I see the > message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center > 1, ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed] > 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, > ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser > window. > > Steps to reproduce: (on redhat linux; I think any linux will do) > 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the > distro. 2) copy built slapd to an appropriate place. link it to slapadd. > 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is > scheduled to close 3/23/2010; let me know if you need the file uploaded > again). unzip the file, it contains the slapcat.out; a blank database > (in a subfolder), and a slapd.conf file. > 4) Edit the slapd.conf file as needed to point to the directory where you > put the database. > > That was the setup, now here are the steps to reproduce the problem: > > 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. > 6) start slapd (using slapd -d 1 -f slapd.conf) > 7) use ldapbrowser to delete the "lcc=call center 1" node. > > It takes a long time, but eventually you'll see it fail while trying to > delete the "agents" node. > Do you see this problem using BDB 4.7.25+patches instead of BDB 4.8? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

13 years

1
0
0 / 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.

by korvus＠comcast.net

tjoen wrote: >On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >> After some chatter on the mailing list, the problem is now understood: >> - TLS error messages are indeed reported by OpenLDAP: >> TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. >... >> - The only way to see these error messages is to start the daemon with >> '-d stats' >... >> My suggestions: print the TLS error messages out to syslog, or if that's >> not possible, print them to stdout regardless of whether the daemon is >> running in the foreground or not. > >Isn't it in local4.* ? > No, they do not get sent to local4.* - the only TLS message which makes it there in this scenario is: slapd[72041]: main: TLS init def ctx failed: -1 Like I said, the ONLY way to get the actual TLS error messages is to run the daemon by hand in the foreground with loglevel stats by way of 'slapd -d stats'. Per the manpage this also prevents slapd from forking: -d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Let me know if I'm still not being clear.

13 years

1
0
0 / 0

(ITS#6492) sendmail+openldap

by exclusivedesign＠yandex.ru

Full_Name: Leo Version: openldap-sasl-client-2.4.21 OS: freebsd 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.247.195.163) Hello. I use ldap_routing feature in the sendmail (8.14.4). When I upgrade openldap from 2.4.19 to 2.4.21, ldap routing stopped working. SYSERR(root): Error getting LDAP results in map ldapmra: Partial results and referral received downgrade to old version - not helped. Help me please.

13 years

1
0
0 / 0

(ITS#6491) LDAP Error code 80 - Dn index delete failed

by robert.hanson＠calabrio.com

Full_Name: Robert Hanson Version: 2.4.21 OS: RedHat 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.203.208.250) 1) start with an empty database; use slapadd to add a large (3 MB) database. 2) Use ldapbrowser to delete nearly all the nodes. After this process, I get to a point where a subnode can't be deleted; I see the message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed] 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser window. Steps to reproduce: (on redhat linux; I think any linux will do) 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the distro. 2) copy built slapd to an appropriate place. link it to slapadd. 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is scheduled to close 3/23/2010; let me know if you need the file uploaded again). unzip the file, it contains the slapcat.out; a blank database (in a subfolder), and a slapd.conf file. 4) Edit the slapd.conf file as needed to point to the directory where you put the database. That was the setup, now here are the steps to reproduce the problem: 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. 6) start slapd (using slapd -d 1 -f slapd.conf) 7) use ldapbrowser to delete the "lcc=call center 1" node. It takes a long time, but eventually you'll see it fail while trying to delete the "agents" node.

13 years

1
0
0 / 0

Re: ITS#6475

by masarati＠aero.polimi.it

> <masarati(a)aero.polimi.it> wrote: > >> > access to * attrs=cmusaslsecretOTP >> > by dn.regex="cn=replica,o=test" write stop >> > by * break >> >> This is orthogonal to the sasl auxprops discussion. It's a matter of >> well-configuring the authorizing identity in slapo-chain(5). > > I pointed it here for future reference because this is an unusual case. > I suspect everyone configure replicas with universal read-only access. > For this to work, replica must also have write access to > cmusaslsecretOTP. Well, if a shadow uses slapo-chain(5), the producer must be configured in order to allow writes coming from the shadow. >> > Another point: bind on the replica is impossible when the master is >> > down. I understand this is to prevent replaying the same OTP on >> multiple >> > replicas, but that defeats the purpose of setting up replicas for fail >> > over. >> >> This was clearly pointed out at the beginning of the discussion. You >> can't have both, it should be clear. > > Yes, I understand that. > >> Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is >> used, OTP breaks. If it is acceptable to have it broken, we can remove >> the hardcoding, and let admins decide whether they prefer fail-over over >> consistency. I'd have no doubt, and favor consistency. > > When you tell about using the shadow copy, the modification will still > be sent to the master, right? Not in the original code. In that case, the modification was bypassing replication, thus it was being applied to the shadow without generating a referral. The alternative, inconsistent solution you seem to indicate would require to replay the modification as internal in case the modification to the producer failed because the service was not available. > Such a behavior allows replays attacks > within the modification propagation time frame, but it ensures that bind > are still possible when then master is down. I think it could be > interesting to have a configuration setting for that. We should bring this to -devel, to see whether it makes sense and whether it would be acceptable. p.

13 years

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2010