Bug 1445776
| Summary: | Deployment of FreeIPA of F26 fails with tomcat errors | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stephen Gallagher <sgallagh> |
| Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 26 | CC: | abokovoy, awilliam, edewata, gmarr, ipa-maint, jcholast, jhrozek, mreynolds, nhosoi, nkinder, pvoborni, rcritten, rmeggins, robatino, ssorce, tbordaz, tkrizek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.6.5-1.fc26 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-05-01 16:27:44 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1349186 | ||
|
Description
Stephen Gallagher
2017-04-26 13:42:33 UTC
Proposing as a Beta blocker via the Beta criterion: "The core functional requirements for all Featured Server Roles must be met, without any workarounds being necessary." Since the FreeIPA server cannot be installed successfully, it cannot serve any of its functions. (Note to blocker review crew: currently this is only broken in updates-testing, but it's serious enough that I want to make sure it's kept on the radar). Reproduced. I think it is a directory server issue: 389-ds-base-1.3.6.4-1.fc26.x86_64 PKI cannot communicate with DS. systemctl status dirsrv.COM.service ● dirsrv.COM.service - 389 Directory Server TEST.EXAMPLE.COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; disabled; vendor preset: disabled) Active: failed (Result: signal) since Wed 2017-04-26 16:13:28 CEST; 11min ago Main PID: 14647 (code=killed, signal=SEGV) Status: "slapd started: Ready to process requests" ns-slapd[14647]: [26/Apr/2017:16:13:04.563485142 +0200] - INFO - ldbm_back_ldbm2index - ipaca: Indexing VLV: caRejectedRenewal-pki-tomcatIndex ns-slapd[14647]: [26/Apr/2017:16:13:04.565677302 +0200] - INFO - ldbm_back_ldbm2index - ipaca: Indexing VLV: caRejectedRevocation-pki-tomcatIndex ns-slapd[14647]: [26/Apr/2017:16:13:04.567787915 +0200] - INFO - ldbm_back_ldbm2index - ipaca: Indexing VLV: caRenewal-pki-tomcatIndex ns-slapd[14647]: [26/Apr/2017:16:13:04.569939377 +0200] - INFO - ldbm_back_ldbm2index - ipaca: Indexing VLV: caRevocation-pki-tomcatIndex ns-slapd[14647]: [26/Apr/2017:16:13:04.580337710 +0200] - INFO - ldbm_back_ldbm2index - ipaca: Finished indexing. systemd[1]: dirsrv.COM.service: Main process exited, code=killed, status=11/SEGV systemd[1]: dirsrv.COM.service: Unit entered failed state. systemd[1]: dirsrv.COM.service: Failed with result 'signal' Correction, I had PKI 10.3.5-12.fc26, not 10.4 Thierry could you confirm my theory? Petr, 389-ds is SIGSEV but no core was dumped. I will try to reproduce it, would you give me more details how to reproduce ? Also I noticed that SELinux is enforced and that 389-ds hit (autotuning) 1436689. I do not know if it is leading to the crash. But if it is, running in permissive would be a temporary workaround. I just - installed freeipa-server-dns with updates testing enabled on minimal install - ipa-server-install --setup-dns + mandatory options From my script: sudo ipa-server-install -U -n $IPA_DOMAIN -r $IPA_REALM -p $IPA_PASSWORD -a $IPA_PASSWORD --setup-dns --forwarder=$DNS_FORWARDER --no-reverse More info can be found on vm in comment 5 - including SELinux denieals (there is quite a lot of them related to various services). I hit that bug 2 days ago and opened https://pagure.io/389-ds-base/issue/49233 William identified the RC and proposed a fix that is still under review. The crash is related to the use of persistent search where the connection handling with the new nunc-stans components had a invalid heap access (access after freed block). A temporary workaround could be to prevent dogtag to open a persistent search. Upstream ticket https://pagure.io/389-ds-base/issue/49233 pushed Just to clarify where this fix applies. It fixes a regression introduced in #49097 (in connection.c:connectio_threadmain OP_FLAG_PS calls slapi_pblock_init rather that memset the pblock) So this bug does not exist in RHEL7.4 So the original 389-ds-base was withdrawn and a subsequent one, which AFAIK passed all manual and automated testing, has now been pushed stable: https://bodhi.fedoraproject.org/updates/FEDORA-2017-15e2a038b2 are we tracking anything else here or should we close this now? Looks good to me. Discussed during the 2017-05-01 blocker review meeting: [1] The decision to delay the classification of this bug was made as we believe a fix has been released. We will revisit it next week. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-05-01/f26-blocker-review.2017-05-01-16.02.txt |