Bug 733436
| Summary: | IPA does not always properly detect its configuration status | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Rob Crittenden <rcritten> |
| Component: | ipa | Assignee: | Rob Crittenden <rcritten> |
| Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.1 | CC: | benl, dpal, grajaiya, iheim, jgalipea, mkosek, mwagner, perfbz |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ipa-2.1.1-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: The IPA server installer and ipactl use two different methods to determine whether IPA is configured.
Consequence: If the IPA uninstallation was not complete, ipactl may claim that IPA server is not configured while IPA server installer refuses to continue because IPA is configured. This is confusing for the user.
Fix: Use a common function to check if IPA server has been configured. Check for left-overs during IPA server uninstallation and report them to the user so that he can resolve the situation.
Result: ipactl and IPA server install check for existing configuration consistently. User has a better feedback when uninstalling IPA server.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 18:30:28 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: | |||
|
Description
Rob Crittenden
2011-08-25 17:22:10 UTC
Upstream ticket: https://fedorahosted.org/freeipa/ticket/1715 I think that the real issue here is that yum erase ipa-server ... should first run ipa-server-install --uninstall ....... okay ... second thought ... not sure that is correct. I'm am still in the school of thought that everything happened as expected. yum erase ipa-server , should not remove 389 or unconfigure it . and a re-install of ipa-server did exactly what it should have ... errored with message stating that a directory server instance already exists and it must be removed for ipa to be installed. Can I get a better reason why you think this is an ipa bug? If I use yum to remove a product from my system, it should not leave cruft behind that prevents a fresh install from being configured. Why does the product team view that as a feature ? What is the use case ? Because ipa consists of 389, dogtag, kdc ... it I can see this gets a bit tricky for you. The proper way to clean up is to .. ipa-server-install --uninstall (cleans up all configuration and 389 instances) and then yum erase what ever packages you want to remove. So here is what we should do for this ticket: Any leftover item from the old install of: * IPA * DS * CS * whatever we care about... that we check on the install that can prevent a successful install should be checked on the uninstall and an appropriate remediation should be provided. It can be backing up or removing depending upon the situation but the bottom line is that the uninstall should allow the system to be brought into the compliance with the install requirements regarding cleanness of the system. This ticket does NOT cover other reasons like DNS and hostname resolution that can prevent IPA from successful installation and functioning. fixed upstream in master: d7618acb73f57a63aca0a9fcfa8bf5edb1cffdda ipa-2-1: 91c9e8320932124ff77178383a0531fb2b218f2f Will now check for leftover when the uninstall finishes and warn about the things it finds.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause: The IPA server installer and ipactl use two different methods to determine whether IPA is configured.
Consequence: If the IPA uninstallation was not complete, ipactl may claim that IPA server is not configured while IPA server installer refuses to continue because IPA is configured. This is confusing for the user.
Fix: Use a common function to check if IPA server has been configured. Check for left-overs during IPA server uninstallation and report them to the user so that he can resolve the situation.
Result: ipactl and IPA server install check for existing configuration consistently. User has a better feedback when uninstalling IPA server.
[root@mudflap ~]# ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring CA directory server Unconfiguring CA Unconfiguring web server Unconfiguring krb5kdc Unconfiguring ipa_kpasswd Unconfiguring directory server ^C Cleaning up... [root@mudflap ~]# [root@mudflap ~]# ipactl status Directory Service: STOPPED Failed to get list of services to probe status: Directory Server is stopped [root@mudflap ~]# [root@mudflap ~]# ipa-server-install The log file for this installation can be found in /var/log/ipaserver-install.log IPA server is already configured on this system. If you want to reinstall the IPA server please uninstall it first. [root@mudflap ~]# [root@mudflap ~]# ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring directory server root : ERROR IPA cannot be re-installed without removing existing 389-ds instance(s) [root@mudflap ~]# [root@mudflap ~]# rpm -qi ipa-server | head Name : ipa-server Relocations: (not relocatable) Version : 2.1.3 Vendor: Red Hat, Inc. Release : 8.el6 Build Date: Wed 02 Nov 2011 03:21:27 AM IST Install Date: Thu 03 Nov 2011 10:02:33 AM IST Build Host: x86-012.build.bos.redhat.com Group : System Environment/Base Source RPM: ipa-2.1.3-8.el6.src.rpm Size : 3381421 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.freeipa.org/ Summary : The IPA authentication server [root@mudflap ~]# Is the above verification enough to be marked this as verified ? I don't think this is it as ipactl does not say that ipa server is not configured. You can check test scenarios that Rob added to the upstream ticket though: https://fedorahosted.org/freeipa/ticket/1715#comment:5 They should help in verifying this. The uninstall log should have additional details on what it found was already installed too. Positive test: [root@mudflap ~]# ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring CA directory server Unconfiguring CA Unconfiguring web server Unconfiguring krb5kdc Unconfiguring ipa_kpasswd Unconfiguring directory server [root@mudflap ~]# echo $? 0 [root@mudflap ~]# Negative test1: - install - Add some state (can be any name=value pair) to /var/lib/ipa/sysrestore/sysrestore.state - uninstall, should get warning about state, rv = 1 [root@sideswipe sysrestore]# ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring CA directory server Unconfiguring CA Unconfiguring web server Unconfiguring krb5kdc Unconfiguring ipa_kpasswd Unconfiguring directory server root : ERROR Some installation state for httpd has not been restored, see /var/lib/ipa/sysrestore/sysrestore.state root : ERROR Some installation state for ipa_kpasswd has not been restored, see /var/lib/ipa/sysrestore/sysrestore.state root : ERROR Some installation state for dirsrv has not been restored, see /var/lib/ipa/sysrestore/sysrestore.state [root@sideswipe sysrestore]# echo $? 1 [root@sideswipe sysrestore]# Negative test2: - install - set up a new 389-ds instance - uninstall [root@decepticons dirsrv]# ls -l total 24 drwxr-xr-x. 2 root root 4096 Oct 19 04:11 config -rw------- 1 dirsrv dirsrv 616 Nov 7 18:59 ds.keytab drwxr-xr-x. 2 root root 4096 Oct 19 04:11 schema drwxrwx--- 3 nobody nobody 4096 Nov 7 19:18 slapd-decepticons drwxrwx--- 3 dirsrv dirsrv 4096 Nov 7 19:11 slapd-LAB-ENG-PNQ-REDHAT-COM drwxrwx--- 3 pkisrv dirsrv 4096 Nov 7 19:00 slapd-PKI-IPA [root@decepticons dirsrv]# [root@decepticons dirsrv]# service dirsrv status dirsrv decepticons (pid 24801) is running... dirsrv LAB-ENG-PNQ-REDHAT-COM (pid 24082) is running... dirsrv PKI-IPA (pid 24150) is running... [root@decepticons dirsrv]# [root@decepticons ~]# ipa-server-install --uninstall -U Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring CA directory server Unconfiguring CA Unconfiguring web server Unconfiguring krb5kdc Unconfiguring ipa_kpasswd Unconfiguring directory server root : ERROR IPA cannot be re-installed without removing existing 389-ds instance(s) [root@decepticons ~]# echo $? 1 [root@decepticons ~]# from ipaserver-uninstall.log: 2011-11-08 07:32:52,073 DEBUG stdout= 2011-11-08 07:32:52,073 DEBUG stderr= 2011-11-08 07:32:52,085 DEBUG Found existing 389-ds instance /etc/dirsrv/slapd-ipaqavma 2011-11-08 07:32:52,086 ERROR IPA cannot be re-installed without removing existing 389-ds instance(s) There exists a bug (https://bugzilla.redhat.com/show_bug.cgi?id=751769) which tracks the issue where the 389-ds instance is successfully removed and still ipa-server-install --uninstall displays an ERROR. Verified. [root@decepticons ~]# rpm -qi ipa-server | head Name : ipa-server Relocations: (not relocatable) Version : 2.1.3 Vendor: Red Hat, Inc. Release : 9.el6 Build Date: Tue 08 Nov 2011 01:30:54 AM IST Install Date: Tue 08 Nov 2011 11:14:36 AM IST Build Host: x86-001.build.bos.redhat.com Group : System Environment/Base Source RPM: ipa-2.1.3-9.el6.src.rpm Size : 3382131 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.freeipa.org/ Summary : The IPA authentication server [root@decepticons ~]# 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. http://rhn.redhat.com/errata/RHSA-2011-1533.html |