As a FreeIPA administrator, I want the ability to specify that ipa-replica-install should add the ipaapi user as an allowed uid for ifp in /etc/sssd/sssd.conf so that I can still run the ipa certmap-match command after an upgrade.
ipa-replica-install
ipaapi
ifp
/etc/sssd/sssd.conf
ipa certmap-match
Apologies for being so long-winded, but I am trying to explain exactly what I am doing from the beginning.
I have three FreeIPA servers in AWS called ipa0, ipa1, and ipa2. The three FreeIPA servers all replicate against each other and all three are advertised via DNS SRV records. When i first set up the three servers I first install ipa0 via ipa-server-install and then install ipa1 and ipa2 as replicas of ipa0 via ipa-replica-install. All three servers are identical, except that ipa0 is configured to be the CA renewal master and has the entire DNA range for user and group IDs. If ipa0 goes down, I can move the CA renewal master and the DNS range to ipa1 or ipa2 and everything continues working as before. This is all working great.
ipa0
ipa1
ipa2
ipa-server-install
In keeping with the idea of treating servers like cattle instead of pets, when I want to upgrade the three FreeIPA servers I build a new AMI and completely replace them one at a time. To be explicit, I:
Next I perform steps 2-6 for ipa1 and ipa2, making them replicas of ipa0. At this point I have three upgraded FreeIPA servers and all my data has been preserved.
Yesterday, though, I noticed that the command ipa certmap-match started failing after an upgrade. Upon investigation, I determined that this is because I have run ipa-replica-install on all three servers and hence there is no server where the ipaapi user has been set up as an allowed UID for ifp in /etc/sssd/sssd.conf. I traced through the FreeIPA code and found that there are only two ways that particular piece of code is triggered:
ipa-client-install
--on-master
The first is not available to me when upgrading, since I need the FreeIPA server i am setting up to replicate against one of the existing servers. I don't think the second is advisable either, since even if I could run ipa-client-install separately from ipa-replica-install, the --on-master flag triggers quite a few other bits of code in addition to the ifp configuration of /etc/sssd/sssd.conf.
Of course I can add a step to edit the /etc/sssd/sssd.conf file manually at the end of the upgrade process and restart services, but I was wondering if it might make sense to create a separate command line option for ipa-replica-install that triggers this behavior automatically.
Explained in previous section.
ipa0 is no longer configured with the ipaapi user as an allowed uid after a FreeIPA cluster update.
ipa0 should be configured with the ipaapi user as an allowed uid after a FreeIPA cluster update.
$ sudo rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server freeipa-server-4.8.6-1.fc32.x86_64 freeipa-client-4.8.6-1.fc32.x86_64 package ipa-server is not installed package ipa-client is not installed 389-ds-base-1.4.3.9-1.fc32.x86_64 pki-ca-10.8.3-2.fc32.noarch krb5-server-1.18-1.fc32.x86_64
None
I am happy to create a PR for this change, but I wanted to make sure it was actually necessary and something that would be useful to others. I realize that my upgrade method is probably not the most common, but I doubt I am the only one doing it this way.
Also, thank you for creating such a great piece of software! It has really scratched a lot of itches on the project where I am currently using it.
This upgrade method is absolutely the recommended way to do it.
It should be straightforward enough to update the SSSD configuration at the end of ipa-replica-install. An excellent candidate would be promote_sssd().
@rcritten, should I create a command line flag to turn on that ssd config update, or should it just always take place? I think the former, but I wanted to make sure I'm not misunderstanding your comment.
I can start on a PR for this. Should I go ahead and claim this issue?
I think this is fine to enable on all servers.
Yes, feel free to take it. See https://www.freeipa.org/page/Contribute/Code for information on code style, commit messages, etc.
When we run ipa-server-install that in turn runs ipa-client-install with the --on-master option set. The --on-master option for ipa-client-install causes the sssd_enable_ifp() function to be run, and that is where the ipaapi user gets added.
sssd_enable_ifp()
My thought was to add a --allow-ipaapi-ifp flag to ipa-client-install that is set when ipa-client-install is run by ipa-replica-install. The presence of that flag or the --on-master flag would cause the sssd_enable_ifp() function to be run. That way ifp is configured for ipaapi via the same code, whether we run ipa-replica-install or ipa-server-install.
--allow-ipaapi-ifp
Does that make sense @rcritten? Otherwise I would need to import sssd_enable_ifp() from ipaclient/install/client.py so that I could use it in promote_sssd() in ipareplica/install/server/replicainstall.py. That seems a lot more complicated.
ipaclient/install/client.py
promote_sssd()
ipareplica/install/server/replicainstall.py
Please let me know what I am missing. You're obviously much more familiar with this codebase than I am.
I think this is only an issue when promoting a client into a full server using ipa-replica-install. Running ipa-replica-install alone and providing credentials will call ipa-client-install with --on-master and ifp will be enabled. There are already imports from ipaclient so you aren't doing something completely new.
I think the import will be fine.
Running ipa-replica-install alone and providing credentials will call ipa-client-install with --on-master and ifp will be enabled.
I don't think this is the case, although I could be misunderstanding you. ipa-replica-install calls ipa-client-install here and I don't see the --on-master flag being set. Also, in the case of my FreeIPA cluster, I know that I am not promoting an existing client. I am only running ipa-replica-install on fresh instances.
Got it that the imports are fine. I will add the import and change the code so that it runs sssd_enable_ifp() from inside promote_sssd().
Finally, I see here that I need to refer to a FreeIPA component in my PR commits. Which component does this pertain to?
You can't pass --on-master into the client installer because it assumes some things have been setup that aren't complete yet, in particular it needs to point to an existing server and not to itself.
The purpose of promote_sssd (and others like it) to change from a client-oriented configuration into a server-oriented one with services pointing at itself.
promote_sssd
In this case I think if your description line is suffiently detailed you may be able to get away without a component, otherwise I'd use replica.
replica
Pull request created.
PR looks good to me. Somebody should also add a test case for the issue.
Test case added.
master:
ipa-4-8:
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.