As an admin, I want to deploy FreeIPA read-only containers.
The code in /usr/lib/python3.10/site-packages/ipaserver/install/server/install.py says
# installer needs to update hosts file when DNS subsystem will be # installed or custom addresses are used if options.ip_addresses or options.setup_dns: installer._update_hosts_file = True
However, the installer tries too hard to do the right thing, taking away flexibility of various setups. With read-only filesystem / /etc/hosts, installer attempting to do
/etc/hosts
Adding [172.29.0.1 ipa.example.test] to your /etc/hosts file
will fail. In containers, whatever the installer puts to /etc/hosts won't be there the next time the container is run, as /etc/hosts is populated by podman / docker from scratch anyway.
It is really up to the admin deploying FreeIPA to make sure the IP address specified with --ip-address is routable correctly to self and that the hostname resolves to self, and the same holds for --setup-dns scenarios.
--ip-address
--setup-dns
On latest Fedoras, hosts line in /etc/nsswitch.conf says
hosts
/etc/nsswitch.conf
hosts: files myhostname resolve [!UNAVAIL=return] dns
so environment's hostname resolves to the local IP addresses without record in /etc/hosts needed.
This is fairly similar / related to https://pagure.io/freeipa/issue/2648 where the fix was to put the IP addresses to /etc/hosts. I'd claim that if the installer want to check / ensure anything, it should check if the hostname is resolvable and the IP address it routable back to itself (start https server and try to reach it), not try to do various configuration tweaks that will become obsolete as the general OS defaults evolve.
ipa-server-install
chattr +i /etc/hosts
ipa-server-install --ip-address 172.29.0.1
I fails with
Adding [172.29.0.1 ipa.example.test] to your /etc/hosts file [Errno 1] Operation not permitted: '/etc/hosts' The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
It should not fail as myhostname resolves the machines hostname just fine.
myhostname
When I comment out the above-mentioned code in /usr/lib/python3.10/site-packages/ipaserver/install/server/install.py, the installer finishes without error and the FreeIPA server works, in spite of the fact that its hostname never got added to /etc/hosts. In my mind that proves that the update_hosts_file is not necessary.
update_hosts_file
$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
freeipa-client-4.9.4-2.fc35.x86_64 package ipa-server is not installed package ipa-client is not installed 389-ds-base-2.0.5-1.fc35.1.x86_64 pki-ca-10.11.0-0.4.alpha2.fc35.noarch krb5-server-1.19.1-10.fc35.x86_64
Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.
Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting
Hello, could someone chime in if my conclusions are correct? I don't need a specific fix as I can patch the code in freeipa-container but I'd like to know if not touching /etc/hosts is in general something that the project wants to do in the future.
Is nss-myhostname is used universally?
Would doing a file permission check be sufficient?
os.access("/etc/hosts", os.W_OK)
I've seen myhostname most everywhere recently. But, I cannot rule out that some OS versions in some configurations and installation methods won't have them.
My question was not as much about avoiding the Operation not permitted error but about avoiding changes to the stock configuration if the stock configuration already does what is needed. So attempting the hostname resolution might be a preferred way over that os.access check.
Operation not permitted
os.access
Login to comment on this ticket.