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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to