Bug 1226600
| Summary: | olcDatabase in olcFrontend attribute incorrect/faulty | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Louis Abel <tucklesepk> |
| Component: | openldap | Assignee: | Matus Honek <mhonek> |
| Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | ebenes, jsynacek, mkosek, pkis |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: Broken logic in handling automatic databases' numbering.
Consequence: The frontend database olcDatabase attribute has not been prepended by an index which resulted in error while modifying the database.
Fix: Underlying patch, adopted from upstream, fixes the issue.
Result: The frontend databse is correctly indexed and modifying the databse works as it should.
|
Story Points: | --- |
| Clone Of: | 1132111 | Environment: | |
| Last Closed: | 2015-11-19 08:53:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
As you correctly stated the issue has not been resolved by solving BZ1132094. However, the issue has already been resolved in upstream by resolving issue ITS#8150 (which modifies first attempt (ITS#7016) to resolve the bug) which is already in REL_ENG_2_4 branch which means the patch is supposed to be included in upcoming OpenLDAP 2.4.41 release. A patch for this issue is planned for the next RHEL7 release. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-2131.html |
The following bug was closed as a duplicate of 1132094. The prior bug report 1132094 was closed as fixed. This is still not the case. A new install of openldap-servers-2.4.39-6 has the same issue as described below. The /usr/share/openldap-servers/slapd.ldif appears to be correct, but the generation of the dynamic configuration has proven that it is still broken and requires manual editing. /etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 7bfbe68d dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend ... The same modification issues described below still occur as a result. +++ This bug was initially created as a clone of Bug #1132111 +++ Description of problem: Modifications cannot be performed on the default olcDatabase={-1}Frontend due to the olcDatabase attribute being incorrect as opposed to the distinguished name. Default install shows: dn: olcDatabase={-1}frontend olcDatabase: frontend Should be: dn: olcDatabase={-1}frontend olcDatabase: {-1}frontend Version-Release number of selected component (if applicable): openldap-servers-2.4.39-3.el7.x86_64 How reproducible: On first installation of openldap-servers package/Always. Steps to Reproduce: 1. Install openldap-servers 2. Attempt to modify olcDatabase={-1}Frontend Actual results: [root@library ldif]# ldapmodify -xWD "cn=config" -f ~/stuff Enter LDAP Password: modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Naming violation (64) additional info: value of naming attribute 'olcDatabase' is not present in entry Expected results: modifying entry "olcDatabase={-1}frontend,cn=config" (No errors) Additional info: This is corrected by manually editing /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{-1\}frontend.ldif - Which is discouraged. This is also similar to bug: 1132094, which states that the ldif is also missing an important objectClass. --- Additional comment from Jan Synacek on 2014-11-28 06:47:54 EST ---