I think we need a better error reporting in this case so that we can insicate what needs to be done to overcome the issue.

This will probably affect #3374.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=918263

There are some changes introduced to ipa-join in patch for #3374.

Option -f has been added to join the host even if the host entry exists.

There introduced --keytab option functionality depends on host-join command's ability to rewrite the host entry even if it exists. I agree that at the very least we should log a info message about the existence of the host entry, so there is relevant information on server side.

I propose either adding a new option for host-join that will force adding even if the entry exists and change the current behaviour to not support that by default OR keeping the current behaviour while providing relevant information to the log. (we should do the logging in both cases though)

I prefer the latter, to be honest.

It is unclear what we do with a forced re-enrollment with any existing certificates or other service keytabs. Are those still valid? I prefer to leave this up to the end-user. It just means it requires admin intervention to run host-disable.

No new switches please, just do the logging.

Once you managed to re-provision the system you can re-provision certs and keytabs using its identity if needed in an automatic fashion.

You as a customer know what is the condition i.e. whether you have other certs and keytabs and whether they have been preserved and recovered or they need to be re-provisioned.
If they need to be re-provisioned you can authenticate as host and do all you need from within the kisckstart.

master: 2f0c7d6[[BR]]
ipa-3-1: e6fedfb