Bug 1487857
| Summary: | Upgrading to CentOS 7 CR (RHEL 7?) breaks openldap server due to ppolicy changes | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Rolf Fokkens <rolf> |
| Component: | openldap | Assignee: | Matus Honek <mhonek> |
| Status: | CLOSED ERRATA | QA Contact: | Dalibor Pospíšil <dapospis> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | dapospis, fumiyas, kfujii, mmalone2, msugaya, nkinder, pkis, trevor.hemsley |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openldap-2.4.44-12.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 18:16:19 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: | |||
|
Description
Rolf Fokkens
2017-09-02 16:50:27 UTC
Specifically, the link in the CentOS bug to https://lists.ltb-project.org/pipermail/ltb-users/2015-December/000653.html This presumably affects RHEL 7.4 too and I do not see any mention of this as a potential problem in the RHEL 7.4 Release Notes (maybe I am blind, wouldn't be the first time!). Both linked bugs are invisible to ordinary mortals :-( Sorry for that. Bug 1386365 is a rebase bug that caused this regression. Bug 1479309 points to a different bug that is not directly related but is tied to the slapd's startup, too. I cannot say now if it is possible to make them public. Anyway, thanks for reporting this also for RHEL. I'll update this bug publicly ASAP. Is there a workaround until the fix is released? Not that I'm aware of, my impression so far:
In the current CentOS (CR) situation there's an option to do a distro-sync to revert to the working openldap version if this issue hits you. This allows you to revert to a working openldap.
The alternative is to manually edit /etc/openldap/slapd.d/cn=config/cn=schema/cn={3}ppolicy.ldif after you discover the LDAP server no longer starts.
Best may be is to run the script https://bugs.centos.org/file_download.php?file_id=21740&type=bug prior to upgrading. But that won't save you once you executed the update.
That script tells me "ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)", though I think it's running (as part of freeipa). The workaround is to add the missing attribute to a dynamic configuration. Once openldap-servers-2.4.44 or newer is installed the correct example of ppolicy schema is in /etc/openldap/schema/ppolicy.{schema,ldif}. The attribute that is missing in older configurations has this prototype:
( 1.3.6.1.4.1.42.2.27.8.1.30 NAME 'pwdMaxRecordedFailur
e' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.
1466.115.121.1.27 SINGLE-VALUE )
Once you add this to your dynamic configuration then this error should not occur any more. Please note, that you cannot edit a dynamic configuration directly as a file due to the CRC checksum that is accompanied with the LDIF file.
The easiest way to do so is to downgrade openldap-servers, ldapadd the missing attribute, and then upgrade the openldap-servers back to the newest version.
Automating this for any possible configuration is technically impossible and having slapd not running at the time of an upgrade would add additional complexity - even when considering the most common configurations and slapd is running, still at least ACL rules might be set so that the script may not be able to access the configuration at all. Thus, automatic script at package's upgrade can be best effort only, unfortunately.
(In reply to Avi Kivity from comment #9)
> That script tells me "ldap_sasl_interactive_bind_s: Can't contact LDAP
> server (-1)", though I think it's running (as part of freeipa).
FreeIPA uses 389DS by default, which is not OpenLDAP. And if you are actually using OpenLDAP then as I've noted above the actual configuration really matters.
(In reply to Matus Honek from comment #10) > (In reply to Avi Kivity from comment #9) > > That script tells me "ldap_sasl_interactive_bind_s: Can't contact LDAP > > server (-1)", though I think it's running (as part of freeipa). > FreeIPA uses 389DS by default, which is not OpenLDAP. And if you are > actually using OpenLDAP then as I've noted above the actual configuration > really matters. Thanks for clearing my confusion. I verified that indeed a binary from the 389-ds-base package is running. For some reason openldap-servers is also installed on my system. *** Bug 1490724 has been marked as a duplicate of this bug. *** 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://access.redhat.com/errata/RHEA-2018:0974 |