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
andrew.findlay@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/
On Wed, May 20, 2015 at 06:40:36PM +0000, hyc@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.)
On Wed, May 20, 2015 at 11:57:13AM -0700, Ryan Tandy wrote: > 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 Good point: that suggests an incomplete fix for ITS#7106 rather than a problem in slapcat. 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 | -----------------------------------------------------------------------
Does the following patch make sense? ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_index-handle-frontend.patch
Ryan Tandy wrote: > Does the following patch make sense? > > ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_index-handle-frontend.patch Looks fine to me. Pushing to master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
fixed in master fixed in RE25 fixed in RE24
changed notes changed state Release to Closed