Red Hat Bugzilla – Bug 666885
ds-base > 184.108.40.206 will not start
Last modified: 2011-04-25 19:27:47 EDT
Created attachment 471508 [details]
Description of problem: I upgraded from 389-ds-base 220.127.116.11 to 18.104.22.168 and my LDAP service would not start. The LDAP error log is attached.
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. 389 server version 22.214.171.124 with TLS enabled
2. upgrade to 126.96.36.199
3. try to start LDAP service
Actual results: Fails to start
Expected results: Started service
Additional info: This 389 server is freshly made as of a few months ago (Oct 2010). The only custom configuration I've done is enabling TLS.
In the mean time, I downgraded to 188.8.131.52 to have a working LDAP server. This server runs in a production environment serving roughly 30 users.
It seems my attached error log may not be helpful. I was adding a new user today when I noticed the error log for 184.108.40.206 contains the exact same error messages. I was able to add the user successfully and no other error messages are present.
Also note: I tried 220.127.116.11 and then 18.104.22.168. Both versions also fail to start. So something between 22.214.171.124 and 126.96.36.199 broke my server configuration.
I was unable to reproduce by installing 389-ds-base-188.8.131.52 on F13, setting up LDAPS, then upgrading to 389-ds-base-184.108.40.206.
The errors you are seeing seem to indicate a problem with the schema files. The attributes that the errors refer to do not use the matching rules indicated by the errors in 389-ds-base-220.127.116.11 or 389-ds-base-18.104.22.168.
In your /etc/dirsrv/slapd-<instance>/schema directory, what does your definition of the "userCertificate" attribute type look like? Is this attribute only defined in 05rfc4523.ldif, or is it defined in another file as well?
(In reply to comment #2)
> In your /etc/dirsrv/slapd-<instance>/schema directory, what does your
> definition of the "userCertificate" attribute type look like? Is this
> attribute only defined in 05rfc4523.ldif, or is it defined in another file as
It is only defined in 05rfc4523.ldif. The schema file doesn't match what the RPM thinks it should be:
# rpm -qV 389-ds-base-22.214.171.124-1.fc13.x86_64
S.5....T. c /etc/dirsrv/schema/05rfc4523.ldif
S.5....T. c /etc/dirsrv/schema/05rfc4524.ldif
S.5....T. c /etc/dirsrv/schema/06inetorgperson.ldif
..5....T. c /etc/dirsrv/schema/30ns-common.ldif
I do not have any *.rpmsave or *.rpmnew files in my /etc/dirsrv/schema directory. I haven't replaced the schema files with old ones on purpose. Replacing those files with the ones from the 126.96.36.199 RPM removes the errors from the log.
Also, updating to 188.8.131.52 now works. Thanks for the help. Shouldn't the new schema files make it when upgrading though?
So you are able to start your server using 184.108.40.206 after cleaning up the schema file issue?
I'm not sure why those files would not be upgraded. Those should be solely handled by installing the new RPM, so something went wrong somewhere. I take it you've been running 389-ds-base on this system since before the 220.127.116.11 version?
Yes, the server is running 18.104.22.168 now after the schema clean-up.
As mentioned, this server was freshly installed in October 2010. The version of 389 that was around then in Fedora 13 was 1.2.6.
Did you manually edit/delete/replace any of the schema files?
Could be a problem with upgrade -> downgrade -> upgrade.
(In reply to comment #6)
> Did you manually edit/delete/replace any of the schema files?
No, I have no need to.
> Could be a problem with upgrade -> downgrade -> upgrade.
I tried to reproduce the issue by installing 1.2.6-0.1.a1.fc13 in a Fedora 13 VM. Upgrading to 22.214.171.124 resulted in the correct schema being placed in /etc/dirsrv/schema, so I could not reproduce it.
It must have been some strange fluke. If it happens again I'll open a separate bug.
Thanks for the help. Sorry for the noise.