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 -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
