[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