Bug 666885 - ds-base > 1.2.7.2 will not start
ds-base > 1.2.7.2 will not start
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: 389-ds-base (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Rich Megginson
Fedora Extras Quality Assurance
: screened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-03 11:16 EST by Michael Cronenworth
Modified: 2011-04-25 19:27 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-04 12:06:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
error log (2.12 KB, text/plain)
2011-01-03 11:16 EST, Michael Cronenworth
no flags Details

  None (edit)
Description Michael Cronenworth 2011-01-03 11:16:32 EST
Created attachment 471508 [details]
error log

Description of problem: I upgraded from 389-ds-base 1.2.7.2 to 1.2.7.5 and my LDAP service would not start. The LDAP error log is attached.


Version-Release number of selected component (if applicable):
389-ds-base-1.2.7.5-1.fc13.x86_64.rpm


How reproducible: Always


Steps to Reproduce:
1. 389 server version 1.2.7.2 with TLS enabled
2. upgrade to 1.2.7.5
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 1.2.7.2 to have a working LDAP server. This server runs in a production environment serving roughly 30 users.
Comment 1 Michael Cronenworth 2011-01-03 12:36:53 EST
It seems my attached error log may not be helpful. I was adding a new user today when I noticed the error log for 1.2.7.2 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 1.2.7.4 and then 1.2.7.3. Both versions also fail to start. So something between 1.2.7.2 and 1.2.7.3 broke my server configuration.
Comment 2 Nathan Kinder 2011-01-03 12:50:32 EST
I was unable to reproduce by installing 389-ds-base-1.2.7.2 on F13, setting up LDAPS, then upgrading to 389-ds-base-1.2.7.5.

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-1.2.7.5 or 389-ds-base-1.2.7.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 well?
Comment 3 Michael Cronenworth 2011-01-03 15:16:18 EST
(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
> well?

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-1.2.7.2-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 1.2.7.2 RPM removes the errors from the log.

Also, updating to 1.2.7.5 now works. Thanks for the help. Shouldn't the new schema files make it when upgrading though?
Comment 4 Nathan Kinder 2011-01-03 18:27:24 EST
So you are able to start your server using 1.2.7.5 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 1.2.7.2 version?
Comment 5 Michael Cronenworth 2011-01-03 19:08:05 EST
Yes, the server is running 1.2.7.5 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.
Comment 6 Rich Megginson 2011-01-04 11:32:58 EST
Did you manually edit/delete/replace any of the schema files?

Could be a problem with upgrade -> downgrade -> upgrade.
Comment 7 Michael Cronenworth 2011-01-04 12:06:30 EST
(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 1.2.7.5 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.

Note You need to log in before you can comment on or make changes to this bug.