openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 17 Mar '10

17 Mar '10

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.

1 0

(ITS#6492) sendmail+openldap
by exclusivedesign＠yandex.ru 17 Mar '10

17 Mar '10

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.

1 0

(ITS#6491) LDAP Error code 80 - Dn index delete failed
by robert.hanson＠calabrio.com 16 Mar '10

16 Mar '10

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.

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 15 Mar '10

15 Mar '10

> <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.

1 0

Re: ITS#6475
by manu＠netbsd.org 15 Mar '10

15 Mar '10

<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. > > 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? 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. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 15 Mar '10

15 Mar '10

> <masarati(a)aero.polimi.it> wrote: > >> Please test. p. > > It works, but needs to adjustement to the master ACL. My basic > configuration yield me this at OTP bind on replica: > ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) > > replica slapd logs: > > conn=1001 op=0 RESULT tag=103 err=50 text= > SASL [conn=1001] Failure: Error putting OTP secret > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: > Error putting OTP secret" > > This has been fixed on the master, by adding this at the beginning of > the ACL: > > 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). > 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. > What about making the behavior configurable? 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. p.

1 0

Re: ITS#6475
by manu＠netbsd.org 14 Mar '10

14 Mar '10

<masarati(a)aero.polimi.it> wrote: > Please test. p. It works, but needs to adjustement to the master ACL. My basic configuration yield me this at OTP bind on replica: ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) replica slapd logs: conn=1001 op=0 RESULT tag=103 err=50 text= SASL [conn=1001] Failure: Error putting OTP secret send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: Error putting OTP secret" This has been fixed on the master, by adding this at the beginning of the ACL: access to * attrs=cmusaslsecretOTP by dn.regex="cn=replica,o=test" write stop by * break 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. What about making the behavior configurable? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#6490) dds and pcache overlays not checking NULL value
by etienne.bagnoud＠irovision.ch 10 Mar '10

10 Mar '10

Full_Name: Etienne Bagnoud Version: 2.4.11 and HEAD OS: Debian GNU/Linux 5.0.4 URL: http://www.tchetch.net/code/openldap/ Submission from: (NULL) (153.109.35.2) When sending a refresh request (RFC 2589) with an empty DN, the server segfault. This did work on default Debian installed version (slapd 2.4.11) as well as on the actual (today) version in HEAD. The actual return value returned by 'select_backend' is not checked for NULL value and passed directly to 'SLAP_DYNAMIC' macro. While digging through the code to find how others overlays where doing, if found that pcache has the same behavior. I can't test for that overlay (if the bug is corrected or not), but I suppose it's the same. So here are two patches to correct dds overlay and pcache overlay : - http://www.tchetch.net/code/openldap/servers-slapd-overlays-dds.patch - http://www.tchetch.net/code/openldap/servers-slapd-overlays-pcache.patch I'm not used to dig into openldap code (in fact, this is the first time), so I hope it's ok. Etienne.

1 0

(ITS#6489) Incomplete Master/Slave Replication
by Frank.Offermanns＠caseris.de 09 Mar '10

09 Mar '10

Full_Name: Frank Offermanns Version: 2.4.21 OS: Windwos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am testing master/slave replication while adding 10000 users with 10 filled attributes. I am not using a specific time synchronization. Standard windows time synchronization in domains is active. But as far as I understood, a microsecond time synchronisation is only needed for master-master, which I am not testing. My problem is, that not every user and/or every attribute is replicated from my master to my slave. If the replicationmode is refreshAndPersist more entries are incorrect on the slave. When doing refreshOnly (every 5 mins) fewer entries have this problem. Switching to delta-syncrepl changes this behaviour. With delta-syncrepl once the intial content load has run, the replication seems to work 100%. But when I add entries while the inital content load (empty slave database) is running, a few complete users are missing (seems to be always a few in a row). But every written user has all attributes, so no missing attributes in this case. I will post my configuration (for refreshAndPersist replication). If you need any other info please let me known. Here my configurations: Master: ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 pidfile ./run/slapd.pid argsfile ./run/slapd.args access to * by dn.one="ou=Admins,o=caesar" write by * read ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" rootpw {SHA}secret... directory "c:/all2421/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 10000 ________________________________________________ Slave: ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 pidfile ./run/slapd.pid argsfile ./run/slapd.args access to * by dn.one="ou=Admins,o=caesar" write by * read ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" rootpw {SHA}secret.... directory "c:/all2421_48/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq syncrepl rid=001 provider="ldap://CAS-WS091201.domain.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited limits dn.exact="cn=Administrator,o=caesar" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 08 Mar '10

08 Mar '10

The original patch compiled but didn't run correctly due to a function that was removed. A new patch that fixes this issue is at: http://hawking.cluenet.org/~crispy/nssov-nsspamldapd-update.patch

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