Red Hat Bugzilla – Bug 666885
ds-base > 188.8.131.52 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 184.108.40.206 to 220.127.116.11 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 18.104.22.168 with TLS enabled
2. upgrade to 22.214.171.124
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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 and then 220.127.116.11. Both versions also fail to start. So something between 18.104.22.168 and 22.214.171.124 broke my server configuration.
I was unable to reproduce by installing 389-ds-base-126.96.36.199 on F13, setting up LDAPS, then upgrading to 389-ds-base-188.8.131.52.
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-184.108.40.206 or 389-ds-base-220.127.116.11.
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-18.104.22.168-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 22.214.171.124 RPM removes the errors from the log.
Also, updating to 126.96.36.199 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 188.8.131.52 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 184.108.40.206 version?
Yes, the server is running 220.127.116.11 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 18.104.22.168 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.