On ti, 13 kesä 2017, Rob Crittenden via FreeIPA-users wrote:
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:
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 , 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.
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
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
That is similar to what is documented in the man page as well.
The behavior doesn't match.
I think we are talking about different things here.
Enrollment override with --force-join is about server side: do not freak
out if there is already existing LDAP object for this host, proceed to
retrieve a keytab.
While "IPA client is already configured" is about a client configuration
itself. The check is done well before we start any installation, let
What I'm saying is that --force-join works; "IPA client is already
configured" error message works too, they are two separate things
applied at different stages.
If client was lost but a backup files stored by ipa-client-install are
still there, then running 'ipa-client-install --force --uninstall' is
what can clean up the state. Then 'ipa-client-install --force-join'
would allow you to proceed with re-enrollment.
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
I think it can be reduced to
$ kinit admin
$ ipa-join -f -h <host> -s <ipa master> -k /etc/krb5.keytab
ipa-join utility will force IPA server side to add the host.
/ Alexander Bokovoy
FreeIPA-users mailing list -- email@example.com
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org