Bug 1636765
Summary: | ipa-restore set wrong file permissions and ownership for /var/log/dirsrv/slapd-<instance> directory | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Luc de Louw <ldelouw> |
Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.5 | CC: | frenaud, ldelouw, myusuf, pvoborni, rcritten, ssidhaye, tscherf |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ipa-4.6.6-7.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-03-31 19:55: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
Luc de Louw
2018-10-07 13:50:53 UTC
What is the package version of ipa-server? (In reply to Rob Crittenden from comment #2) > What is the package version of ipa-server? Hi, It is: ipa-server-4.5.4-10.el7_5.4.4.x86_64 ipa-server-common-4.5.4-10.el7_5.4.4.noarch Thanks, Luc Upstream ticket: https://pagure.io/freeipa/issue/7725 Is this a restore on top of an existing IPA installation or an restore on a new system? (In reply to Rob Crittenden from comment #5) > Is this a restore on top of an existing IPA installation or an restore on a > new system? It was on a new vanilla RHEL7 latest and greatest system. "yum -y install ipa-server ipa-server-dns" followed by the restore attempt. I can duplicate the permission and ownership difference but not the bad behavior. In my test ns-slapd starts and logs fine. A default install has the log instance as: drwxrwx---. 2 dirsrv dirsrv 127 Oct 8 10:35 slapd-EXAMPLE-TEST A restored instance: drwxr-xr-x. 2 root root 127 Oct 8 10:26 slapd-EXAMPLE-TEST (In reply to Rob Crittenden from comment #7) > I can duplicate the permission and ownership difference but not the bad > behavior. In my test ns-slapd starts and logs fine. > > A default install has the log instance as: > > drwxrwx---. 2 dirsrv dirsrv 127 Oct 8 10:35 slapd-EXAMPLE-TEST > > A restored instance: > > drwxr-xr-x. 2 root root 127 Oct 8 10:26 slapd-EXAMPLE-TEST In my case, it was even more strange: the error log has the same permission as the access log and was writable. When I deleted the access log and ipactl restart, access was created with zero byte size and the same error occurred. Fixed upstream master: https://pagure.io/freeipa/c/8da0e2e9774ead01d5c0fa53b1498f15b1818b79 ipa-4-8: https://pagure.io/freeipa/c/966e0b8cee0ca4f9ce9ecf34ca49e58e14a632c9 ipa-4-7: https://pagure.io/freeipa/c/05b173c1a7fb0b18b371771bafe01c0083547c79 ipa-4-6: https://pagure.io/freeipa/c/8cd2052c3cb6d8a2569903593762d64669303ff6 CI test. Fixed upstream master: https://pagure.io/freeipa/c/7aec6f10374129d75cd99a4012980516ca535551 CI test Fixed upstream ipa-4-8: https://pagure.io/freeipa/c/940e2ef900d766086a793cfd6b8906e425badac0 CI test Fixed upstream ipa-4-7: https://pagure.io/freeipa/c/140111cd53803194a6c41a576cab9b3c282ed54f ipa-4-6: https://pagure.io/freeipa/c/de0afeaf5e07028af8ec7247ce37efc789add2ae ============================= test session starts ============================== platform linux2 -- Python 2.7.5, pytest-4.6.7, py-1.8.0, pluggy-0.13.1 -- /usr/bin/python2 cachedir: .pytest_cache metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-1118.el7.x86_64-x86_64-with-redhat-7.8-Maipo', 'Packages': {'py': '1.8.0', 'pytest': '4.6.7', 'pluggy': '0.13.1'}, 'Plugins': {u'html': u'1.22.1', u'multihost': u'1.1', u'sourceorder': u'0.5', u'metadata': u'1.8.0'}} rootdir: /usr/lib/python2.7/site-packages/ipatests plugins: metadata-1.8.0, html-1.22.1, multihost-1.1, sourceorder-0.5 collecting ... collected 3 items test_integration/test_backup_and_restore.py::TestBackupAndRestore::test_full_backup_and_restore PASSED [ 33%] test_integration/test_backup_and_restore.py::TestBackupAndRestore::test_full_backup_and_restore_with_removed_users PASSED [ 66%] test_integration/test_backup_and_restore.py::TestBackupAndRestore::test_full_backup_and_restore_with_selinux_booleans_off PASSED [100%] Automation ran in LTE mode and passed. Logs provided. Marking the bug as verified. 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/RHBA-2020:1083 |