[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problems administering OL2.3.4 via cn=config
Michael.Heep@o2.com wrote:
Hi list,
I'm having some problems administering the OL2.3.4 server in our
testenvironment.
Untill adding the olcRootPW attribute manually to cn=config.ldif I
wasn't able to access cn=config at all with any kind of LDAP Browser
(like JXPlorer or LDAP Administrator). After doing so I could finally
authenticate to the LDAP Server and list the contens of cn=config.
Maybe this should be added to the docs or maybe what I did here is
totally wrong in the first place. In that case please direct me to
some doc/faq that describes the proper procedure.
Yes, that's fine, and yes, the docs need further updates. The cn=config
backend only allows access to its rootdn. Setting the rootpw is probably
the easiest way to get access. (Using SASL and some regexp's to map some
other ID to the cn=config rootdn is the other way.)
Now to my real problem: When i try to delete an entry from cn=config,
lets say cn=include{3}, which is the one with the highest index I get
the following slapd debug output:
> send_ldap_result: conn=0 op=32 p=3
send_ldap_result: err=53 matched="" text="operation not supported
within namingContext" send_ldap_response: msgid=133 tag=107 err=53
ber_flush: 59 bytes to sd 10 conn=0 op=32 RESULT tag=107 err=53
text=operation not supported within namingContext
Correct. The LDAPDelete operation is not supported in this release. For
most cn=config entries it will probably never be supported.
Similar things happen when i try to delete attributes under
cn=confige, for example my olcTLS* attributes.
Deleting the TLS attributes (using LDAPModify) is supported.
Another strange behaviour accured when trying to modify attributes in
cn=config: When I tried to modify the value of
olcTLSCACertificateFile the operation is supposedly successfull, but
after that the cn=config.ldif file is garbled: dn: cn=config
objectClass: olcGlobal cn: config olcConfigDir: /etc/openldap/slapd.d
olcArgsFile: /var/lib/ldap/slapd.args olcAuthzPolicy: none
olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2 olcLocalSSF: 71 olcLogLevel: Stats
olcPidFile: /var/lib/ldap/slapd.pid olcReadOnly: FALSE
olcReplicationInterval: 0 olcRootPW::
e1NTSEF9NzJxZWFVcEYvOGxMZ2hvakJWRGlsQzNVd2JRQ280Z0U= olcSaslSecProps:
noplain,noanonymous olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16
structuralObjectClass: olcGlobal olcTLSCertificateFile:
/etc/openldap/ssl/sgmldap01.cert olcTLSCertificateKeyFile:
/etc/openldap/ssl/sgmldap01.key olcTLSVerifyClient: never
olcTLSCipherSuite: HIGH:SSLv3 olcTLSCACertificateFile:
/etc/openldap/ssl/ca.cert entryCSN: 20050624091640Z#000001#00#000000
modifiersName: cn=config modifyTimestamp: 20050624091640Z 071404Z
As you can see that last line containing "071404Z" makes the file
syntactically incorrect. Sometimes also just a "Z" is appended to the
file.
Looks like a bug in back-ldif's Modify code. Please file an ITS for this
specific problem so we can track it.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support