openldap-bugs May 2015

openldap-bugs@openldap.org

26 participants
101 discussions

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 20 May '15

20 May '15

On Wed, May 20, 2015 at 06:40:36PM +0000, hyc(a)symas.com wrote: >Unable to reproduce. It does if you use an initial LDIF like the one from ITS#7016: $ mkdir cf.d $ slapadd -Fcf.d -n0 dn: cn=config objectClass: olcGlobal dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig ^D $ slapcat -Fcf.d -n0 -l cf.ldif $ rm -r cf.d/* $ slapadd -Fcf.d -n0 -l cf.ldif slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=591): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry _#################### 100.00% eta none elapsed none fast! Closing DB... (I ran into this myself a while back but forgot to report it.)

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 20 May '15

20 May '15

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.40 > OS: CentOS 7 > URL: > Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) > > > When using cn=config it is sometimes necessary to extract the whole config to an > LDIF file, edit it and re-load into an empty directory. Therefore I would expect > the null-edit case to work for any system: > > slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif > rm -rf .../config > mkdir .../config > slapadd -F .../config -n 0 -l extracted.ldif > > What I actually get is an error message: > slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of > single-valued naming attribute 'olcDatabase' conflicts with value present in > entry Unable to reproduce. violino:~/OD/o24/tests> mkdir testrun/slapd.d violino:~/OD/o24/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf -F testrun/slapd.d -n0 > cf1.ldif violino:~/OD/o24/tests> ls testrun/slapd.d cn=config cn=config.ldif violino:~/OD/o24/tests> rm -rf testrun/slapd.d/* violino:~/OD/o24/tests> ../servers/slapd/slapd -Ta -F testrun/slapd.d -n0 -l cf1.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

Full_Name: Andrew Findlay Version: 2.4.40 OS: CentOS 7 URL: Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) When using cn=config it is sometimes necessary to extract the whole config to an LDIF file, edit it and re-load into an empty directory. Therefore I would expect the null-edit case to work for any system: slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif rm -rf .../config mkdir .../config slapadd -F .../config -n 0 -l extracted.ldif What I actually get is an error message: slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry The problem is the frontend database entry: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcAccess: {0}to * by * read structuralObjectClass: olcDatabaseConfig entryUUID: 35adc8f6-9363-1034-85ee-896d5ca46112 creatorsName: cn=config createTimestamp: 20150520174137Z entryCSN: 20150520174137.558106Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20150520174137Z %SpSpecifically, the '{-1}' in the dn should either be omitted or should also be present on the olcDatabase attribute in the entry itself. The problem is in the behaviour of slapcat, but may be related to the fix for ITS#7016 Andrew

1 0

(ITS#8149) nssov loginStatus doesn't play well with replication
by ryan＠openldap.org 20 May '15

20 May '15

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (142.31.146.2) Submitted by: ryan jindraj in #openldap reported that in a master/slave setup, nssov on the slave updates loginStatus in the local db, not on the master. nssov should update loginStatus in a way that can be forwarded properly (possibly controlled by a conf option, similar to ppolicy_forward_updates). The loginStatus updates also don't behave intuitively under MMR. The mod is done without opattrs, so is not immediately replicated, but it does get replicated if the entry's CSN gets updated for any other reason. loginStatus is not an operational attribute, nor is user-modification of it prohibited. (Maybe it should be?)

1 0

Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by alexoz66＠gmail.com 20 May '15

20 May '15

On 05/19/2015 11:55 PM, Howard Chu wrote: > alexoz66(a)gmail.com wrote: >> Full_Name: John Alex. >> Version: 2.4.40 >> OS: FreeBSD 9.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (176.58.252.240) >> >> >> I have a consumer configured with slapo-memberof and exattrs=memberof in order >> to keep track of group memberships locally as suggested in the manpages. This >> works ok when adding/deleting users to groups, but when a user entry containing >> "memberOf" values is modified, those values are deleted in the consumer. >> According to ITS#7400, exattrs=memberOf is necessary to avoid getting this >> attribute from the provider. > > I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive > in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list > and needs new design work. By reading ITS#7400, I got the impression that the provider (wrongly) sends "memberOf" when the consumer requests "+", so I figured I had to either block this attribute by acl at the provider or by using exattrs on the consumer. Has this been fixed? >> However, it was suggested to me to remove >> "memberOf" from exattrs, which I did and now everything seems to work fine. >> >> In any case, even if exattrs=memberof is not needed anymore, it should not have >> any effect to the local slapo-memberof operations. > > Sorry, that doesn't follow. Adding settings will invariably change some server behavior. > Adding a setting that you didn't need generally turns a working config into a broken config. Redundant yes, but broken? Although I don't have the slightest clue about the inner workings of syncrepl and slapo-memberof, I don't see why one should affect the other. >> See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html > >

1 0

Re: (ITS#8133) segfault at startup with memberof+dds
by ryan＠nardis.ca 19 May '15

19 May '15

The patch below fixes the crash, however I'd appreciate a review before committing in case I misunderstood why that code might be needed. The first periodic expiry runs immediately after startup completes, and AFAICT does everything this one would have; so the window for returning stale data should be short. Thanks. ftp://ftp.openldap.org/incoming/20150519_rtandy_ITS-8133-avoid-mods-during-…

1 0

Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by hyc＠symas.com 19 May '15

19 May '15

alexoz66(a)gmail.com wrote: > Full_Name: John Alex. > Version: 2.4.40 > OS: FreeBSD 9.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (176.58.252.240) > > > I have a consumer configured with slapo-memberof and exattrs=memberof in order > to keep track of group memberships locally as suggested in the manpages. This > works ok when adding/deleting users to groups, but when a user entry containing > "memberOf" values is modified, those values are deleted in the consumer. > According to ITS#7400, exattrs=memberOf is necessary to avoid getting this > attribute from the provider. I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list and needs new design work. > However, it was suggested to me to remove > "memberOf" from exattrs, which I did and now everything seems to work fine. > > In any case, even if exattrs=memberof is not needed anymore, it should not have > any effect to the local slapo-memberof operations. Sorry, that doesn't follow. Adding settings will invariably change some server behavior. Adding a setting that you didn't need generally turns a working config into a broken config. > See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by alexoz66＠gmail.com 19 May '15

19 May '15

Full_Name: John Alex. Version: 2.4.40 OS: FreeBSD 9.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.58.252.240) I have a consumer configured with slapo-memberof and exattrs=memberof in order to keep track of group memberships locally as suggested in the manpages. This works ok when adding/deleting users to groups, but when a user entry containing "memberOf" values is modified, those values are deleted in the consumer. According to ITS#7400, exattrs=memberOf is necessary to avoid getting this attribute from the provider. However, it was suggested to me to remove "memberOf" from exattrs, which I did and now everything seems to work fine. In any case, even if exattrs=memberof is not needed anymore, it should not have any effect to the local slapo-memberof operations. See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html

1 0

Re: (ITS#8142) back-ldap transparent reconnecting is not so transparent
by hyc＠symas.com 19 May '15

19 May '15

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4 > OS: > URL: > Submission from: (NULL) (50.113.67.84) > > > Currently, back-ldap stores credentials in the outbound connection > structure. When that disappears, e.g. from idle-timeout, conn-ttl, > network lossage, AD trouble, etc., the connection becomes unbound and > AD returns err=1 (Operations error), which isn't enougfofor back-ldap > to treat it as LDAP_UNAVAILABLE. > > Howard reports this is working-as-designed, even if the design is bad. > Several ITS filings are still open about this problem; 5110, 6571, and > 7464 are all related. > > At a minimum, we should drop the client connection if we can't keep > the session stable. This is not as simple as it sounds. In particular, back-ldap may be part of a larger glued tree of backends. A failure to search in the back-ldap context should not prevent the rest of the glued tree from being searched, and it should not drop the client connection. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#8147) syncrepl fails when encountering bad data, master leaks memory
by Mark.Bannister＠morganstanley.com 19 May '15

19 May '15

> > I did see that a number of memory leaks have been fixed since 2.4.30, b= ut I > > didn't see anything that looked like this profile. Sorry I don't have = a newer > > version of OpenLDAP to hand to re-test. > > Closing this ITS. You can followup again if you see the same problem in t= he=20 > current 2.4.41 release candidate. 2.4.30 is over 3 years old, no one is g= oing=20 > to investigate this. I wasn't asking anyone to look into 2.4.30. Given how easy this is to test= , Howard, and in the interests of code hygiene, wouldn't it be better for you to spen= d 10 minutes attempting to reproduce the problem on the latest RC? It'll take me much l= onger to download and compile the new RC than it would do for you to import a bad en= try and set-up basic syncrepl. If, by doing so, you can identify and fix another m= emory leak then that's a really good thing. If you can't reproduce it in 2.4.41 after= 10 minutes, then I understand if you close the issue. Best regards, Mark. ---------------------------------------------------------------------------= ----- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers. If you canno= t access these links, please notify us by reply message and we will send th= e contents to you. By messaging with Morgan Stanley you consent to the fore= going.=

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2015