Basic uninstaller for the CA

[rcritten]

This in response to watching users flounder with repeated failed replica installations and ipa-ca-install attempts that require a complete uninstall. Review it with whatever priority you desire.

This is meant ONLY to be able to re-try an installation if the
CA cloning fails for some reason. It is not intended to be used
to remove the CA as a service on a given master.

This is to avoid having to stand up a whole new master just
because the CA installation failed.

https://pagure.io/freeipa/issue/6595

[martbab]

I would avoid having half-effective CA uninstaller given that other components like Samba, DNS(Sec), and now also KRA (given the amount of bugs the uninstaller caused) do not support their uninstallation.

Either we have to design some unified framework for proper optional component uninstallation, or we can go in vein of AD trust and DNS installers which are idempotent to a degree. I have an impression that this PR will cause users more problems than it aims to solve.

[rcritten]

What do you mean half-effective? Did you try it?

There already IS a unified framework for component uninstallation: each service provides it. There are edge cases when trying to uninstall one particular piece but that is relatively straightforward to handle and as outlined in the PR this is not intended or expected to clean up every last element, just enough to be able to cleanly attempt the installation again.

Forcing users to uninstall an entire master just to (try to) re-install the CA is a major pain point.

Other services not having uninstall options is not relevant to this case IMHO.

[martbab]

@rcritten If it is expected to not clean up properly after a fai;ed installation then I would rather not advertise it as an uninstaller, otherwise users will start to get ideas like "I do not want to use built-in CA anymore, let's just uninstall it and use 3rd party certs everywhere" and will run into problems with leftover certificates and such.

I would rather provide some rollback after failed install but again, I think there should be a more extensive discussion about a generic solution applicable to all service installers.

Also I would not claim that we actually do not have a service uninstaller framework since every service installer has a copy-pasted code in an ad-hoc coded uninstall method repeated ad nauseam. From what I have glimpsed from ipa-4-5 branch, Service class does not even provide uninstall abstract method to override, only SimpleServiceInstance does that.

[pvoborni]

Let's first clarify the problem to solve. If I understand @rcritten right, the problem is that if ipa-ca-install fail then one must reinstall the whole replica because the failed installation left a garbage and subsequent installer is not able to handle the garbage.

Uninstallation of successful CA installation is not the intend, right? If so then it seems to me that both of you are in agreement. And I would add that I completely agree with CA uninstall not being a goal because it would add just another use case to support with a benefit I don't see.

So if goal is repeatable ipa-ca-install then let's not talk about creating a CA uninstaller but rather about CA cleanup and let's hide/remove the --uninstall option and figure out how it should behave - i.e. let it be internal.

[martbab]

@pvoborni We can try to move the uninstaller logic to the beginning of the install, or make the affected steps idempotent. But still I would be hesitant to merge this PR without some design in place.

[stlaz]

@pvoborni @rcritten @martbab This discussion at this PR makes no sense. Clearly we can see that the impact is much higher and should be discussed on designated channels, meaning either freeipa-devel mailing list or in our issue tracking system (the former would be preferable with having the result in the latter). I believe that the guys from the Dogtag project could also have a great insight on this.

Here's questions which should answer why I want this to be discussed there:

• how to handle users so they don't use ipa-ca-install --uninstall any time?
• at which point is the installation recoverable and when it's not?
• describe what happens in each and every step, mention which files and entries are created
  • on master
  • on replica
• describe what has to be done in case a step fails for each and every step
  • on master
  • on replica
• describe how ipa-ca-install rollback should behave when installing first CA in a CA-less setup

These problems are just from the top of my head and I am a CA installation noob. I would however be very cautious not knowing an answer to either of those.

@rcritten if you do know the answers, please, share them with us (or maybe just me because I sure don't know them), it would help a lot with deciding on where to go from here.

[rcritten]

As far as I can tell it is always recoverable using this. I wasn't able to force a failure of replication, that could be a potential show-stopper. The PR doesn't touch the replication agreements at all except to allow them to already be there, so if things were in some sort of halfway state I couldn't say for sure what would happen.

The code is there for examination to determine what steps are done, but in short:

• call the existing CA uninstaller which mostly just calls pki-destroy (it also does some state cleanup, removes the CRLs and untracks the CA certs via certmonger)
• A side-effect of the uninstaller is to shutdown certmonger. I start that back up
• The service is removed from cn=masters
• The cached services list is removed so ipactl won't fail starting a non-existent tomcat instance

To be idempotent would require changes in dogtag, it is that which blows up on a re-install attempt.

I would not be in favor of automatically uninstalling dogtag on another ipa-ca-install call.

ipa-ca-install would/should never be run on the original master. It already prints a big fat warning. I'd be ok making it fatter and requiring (no joke) multiple "Are you sure" prompts.

There is no CA install for CAless so not a case I'm interested in.

If you want to rename options I'm ok with that as well, maybe --try-again or something of that nature (in which case I WOULD be in favor of doing the uninstall automatically).

[pvoborni]

We need to develop something like this, but right now it is not the best time for it. First we need to stabilize 4.5.1 (seems that's almost done). Then focus on testing - current test coverage + on pull request CI. When this is ready we can focus on python3 porting and existing PRs including this one. The reason is that I'm hesitant implementing this to not introduce other regressions because it touches more areas than it seems.

For the parts above:

• +1 for denying uninstall on successful install
• there is actually a path from CA less to CA so we need to think about it as well

[tiran]

I think the feature is useful, but I'm not fond of the option name --uninstall. It's partial uninstallation. What do you think about either a different option name (e.g. --remove-instance) or a --reinstall option that removes and reinstalls just Dogtag?

[tiran]

This change seems unrelated and should not be required. In fact it is going to break Python package tests and make fastcheck.

[tiran]

This is also unrelated and should not be required.

[rcritten]

I'll eventually open a ticket with a design and then resubmit once that is accepted.