William Faulk via FreeIPA-users wrote:
Sorry; I should have been more explicit in my initial post. I'm
basically only concerned with authentication on the client server and minimizing any
outage related to that. The system is running services, but they are independent of IPA
other than that they're running as users that are defined in IPA. I don't think
that the lack of a username/uid mapping will cause a problem for a running process, since
the process will already be associated with that uid even if no username exists for it,
and the same is true of files, but I am a little concerned about group membership. If a
process is accessing files that it has access to via group membership, and it's not
the process's current gid, I would have thought that it would lose access to those
files. But a little poking around suggests that's not true. (Supplementary groups are
in the process descriptor? I didn't realize that.)
Maybe this isn't as big a concern as I thought.
Regardless, I guess what I was looking for was basically a way for the IPA membership to
be atomically replaced without a gap in name-to-id lookup. I feel like from the client
point of view, this would be like joining a new IPA environment, which feels like a thing
that could exist. If not, maybe sssd could cache the auth through the gap?
Or is it safer to assume that there will be a gap in auth and take the hit of bringing
those systems out of active service?
Ok, let's try to game this out. I might miss something so let's come to
an agreement before you do anything. Call me paranoid.
From a server perspective a "client" is a host entry and perhaps a DNS
entry or two (A and PTR). I'll assume no DNS since it's simpler.
That host record contains the krbPrincipalName and krbPrincipalKey
attributes: the keytab (simplified).
So theoretically for your four orphaned clients if you create a host
entry on the working side of the cluster and run ipa-getkeytab then the
client should work. The rest of the IPA/SSSD configuration is more less
valid other than the default server(s) to talk to (/etc/ipa/default.conf
and /etc/sssd/sssd.conf).
I don't think there is a way to do it without breaking the connection
since you'd also want to switch away from the split cluster. My idea is
to assume the rest of the configuration is just fine so a full
ipa-client-install --uninstall and ipa-client-install isn't necessary.
I suppose it would be relatively "quick" but that can be an eternity in
milliseconds.
You could try an experiment and enroll a new 5th orphaned client against
the split cluster and then try to re-point it.
I think the scenario would be something like:
On a client/server pointing to the "good" side:
- ipa host-add split-client.example.test
- ipa-getkeytab -k /path/to/temp/keytab -p host/split-client.example.test
On 5th orphan:
- mv /etc/krb5.keytab /etc/krb5.keytab.split
- copy in the keytab you generated on the "good" side to
/etc/krb5.keytab (ensure perms, ownership, SELinux labels).
- edit /etc/sssd/sssd.conf and /etc/ipa/default.conf and replace the
"split" server name with a "good" one
- systemctl restart sssd
Maybe run an id <foo> name during the restart to gauge how badly things
go. The SSSD cache should still be valid since it's the same
realm/domain environment.
And then verify that things are a-ok. Look-ups work, particularly those
not cached, etc.
rob