Bug 1265450
| Summary: | ipa-client-install --uninstall local only clean up option | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | fjayalat |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Namita Soman <nsoman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | fjayalat, haldir.junk, mkosek, rcritten, ssorce |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-01-26 10:41: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: | |||
A better way to handle this is to not uninstall, and instead just run a forced join after changing the hostname and deleteing/moving aside the existing keytab. On top of that you could use the template image keyatb to perform the join if that host key ids given enough permissions. Hello, I filed the origin support case... I tested the suggested method (re)moving the keytab and force-joining, but this fails to join: [root@client2 ~]# mv /etc/krb5.keytab ./ [root@client2 ~]# ipa-client-install --force-join IPA client is already configured on this system. If you want to reinstall the IPA client, uninstall it first using 'ipa-client-install --uninstall'. I am not sure how it is validating that the client was configured. I also tried moving /etc/ipa, but got the same result. I agree that this process would be a good solution if I can get it to work. Hello,
I looked over the code a bit and found I would need to remove /etc/krb5.keytab, /etc/ipa/default.conf (or *), and /etc/nssdb/*. This works, but is less than ideal since doing an uninstall later effectively reverts it to the source server joined state (since that's whats backed up by the join).
After more fiddling I made a patch that allows the un-enroll to be toggled which is more what I had in mind. Using this to do an "offline" uninstall, reverts to the source servers vanilla files, then install rejoins with new name.
--- /sbin/ipa-client-install 2015-12-09 07:51:12.000000000 -0500
+++ ./ipa-client-install 2015-12-17 13:35:46.453310779 -0500
@@ -213,6 +213,8 @@
uninstall_group.add_option("", "--uninstall", dest="uninstall", action="store_true",
default=False, help="uninstall an existing installation. The uninstall can " \
"be run with --unattended option")
+ uninstall_group.add_option("--offline", dest="offline_uninstall", action="store_true",
+ default=False, help="uninstall without unenrolling from the domain controller")
parser.add_option_group(uninstall_group)
options, args = parser.parse_args()
@@ -594,7 +596,7 @@
"Failed to disable automatic startup of the %s service: %s",
cmonger.service_name, str(e))
- if not options.on_master and os.path.exists(paths.IPA_DEFAULT_CONF):
+ if not options.on_master and not options.offline_uninstall and os.path.exists(paths.IPA_DEFAULT_CONF):
root_logger.info("Unenrolling client from IPA server")
join_args = [paths.SBIN_IPA_JOIN, "--unenroll", "-h", hostname]
if options.debug:
Clearing NEEDINFO since I didn't in my previous replies. Hello Eric, sorry for delay, we have been discussing this RFE on several occasions with the team before we came to conclusion. There is a controversy on this one, the fact that client uninstall contacts the server to unenroll itself is there on purpose. For security reasons, there should always be only one instance of the host keys (identity). The proposed option would only make sense if there are multiple instances of the host keys (like a VM clone or template in your case), which however means the keys could be compromised in the process and multiple VMs could pretend to be that host. As FreeIPA/IdM works on providing the option that support the best security practices, it cannot support the option that promotes otherwise. Given above, I am closing the proposal for the new option as WONTFIX. I am disappointed by this. I understand the concern, and our cloning/provisioning process generates new host keys for this reason (and therefore is not an issue). In fact, the whole point of this request is to make sure that server has the correct access restrictions applied as quickly and consistently as possible to avoid security issues. Cloning will happen, it is part of a virtual infrastructure, but this decision makes it harder to enforce good security and access controls rather than easier. |
Description of problem: Customer would just like some kind of option/flag that he can pass so that the IDM settings and configs on the local machine are cleared just as they would be normally during uninstall but not actually contact the domain controller or revoke host certificates or whatever. The idea is to Clone a new server from existing IPA client, then be able to join the domain as a new device under a new name once renaming and reconfig is complete and to not impact the source device in any way (which would still exist in this scenario). Our provisioning script begins by "sanitizing" the server of any previous identity, and then configuring the desired one as normal. Since the source may still exist and even be in use, the sanitizing should only be done locally. For our clients an example of a use case for this would be a load balanced web application. A web node is cloned (including the app and its configuration), and the clone is then added to the pool of load balanced servers for easy scalability (though reconfiguration may be needed depending on the app). While this could also be implemented by provisioning a new server and installing the application using puppet or some other management tool, this is not practical for small clients with just a couple nodes, or limited technical knowledge. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Currently cu clone existing IPA client - > manually configure the cloned server (Because if they run ipa-client-install --uninstall it will remove the original source server) -> Expected results: Additional info: Subscription-manager has this capability with the clean command (even if this wasn't the scenario in mind). From the man page: CLEAN OPTIONS The clean command removes all of the subscription and identity data from the local system without affecting the system information in the subscrip‐ tion management service. This means that any of the subscriptions applied to the system are not available for other systems to use. The clean com‐ mand is useful in cases where the local subscription information is corrupted or lost somehow, and the system will be reregistered using the regis‐ ter --consumerid=EXISTING_ID command.