Bug 666885
| Summary: | ds-base > 1.2.7.2 will not start | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Cronenworth <mike> | ||||
| Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 13 | CC: | edewata, nhosoi, nkinder, rmeggins | ||||
| Target Milestone: | --- | Keywords: | screened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-01-04 17:06:30 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. 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? (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? 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? 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. 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 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. |
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.