Alexander Bokovoy wrote:
On ti, 13 kesä 2017, Rob Crittenden wrote:
> Alexander Bokovoy via FreeIPA-users wrote:
>> On ti, 13 kesä 2017, Chris Dagdigian via FreeIPA-users wrote:
>>> Hi folks,
>>>
>>> Fixing a topology and replication issue caused my IDM infrastructure
>>> to forget about roughly 30 enrolled client hosts.
>>>
>>> Though this would be trivial to fix via an ansible playbook that runs
>>> the IPA client install command again with the "--force-join"
argument.
>> Force join is for the case when you want ipa-join utility to repeat join
>> process on the server side. This just ignores the fact that host object
>> does exist in LDAP and allows to continue to regenerate a keytab.
>>
>> It does not mean ipa-client-install would reconfigure the client side.
>>
>> If you want really to re-do install, run 'ipa-client-install --uninstall
>> --force' and then 'ipa-client-install --force-join'.
>>
>> The check for already installed client cannot be overridden right now.
>
> Right but this is exactly the opposite of what the man page and the v3
> design document states [1], hence the need for a bug.
The change I pointed to (ad717bff3c8c176f2c3c983d1a743eac00af426e) is
part of FreeIPA 3.0.0, so the behavior did not change since that time.
> [1]
http://www.freeipa.org/page/V3/Forced_client_re-enrollment
This design document does not talk about existing client-side
configuration. The check for already configured client is independent of
the --force-join logic described in the document above.
Should we decide to cease to enforce "client is already configured" part
is a different question but the behavior there is consistent at least
since 3.0.0.
Sure it does, in the force-join case it stipulates "No changes have been
done to the host entry (host has not been un-enrolled using
ipa-client-install --uninstall) and host has not been disabled using
host-disable command."
That is similar to what is documented in the man page as well.
The behavior doesn't match.
I don't have an opinion either way at this point whether it should work
this way or not, though based on the tests I think this assumes the
client was lost in some way.
Anyway, for the reporter, you can probably do something like this to get
the clients back into a usable state without re-enrolling them (though
that might be the better way):
$ kinit admin
$ ipa host-add <host> (assuming the host entry doesn't already exist)
$ ipa-getkeytab -s <ipa master> -p host/<host> -k /etc/krb5.keytab
Note that this is just off the top of my head but I think I got the
options right.
rob