#8888 With myhostname early in hosts: in nsswitch.conf, update_hosts_file is not needed
Opened 2 years ago by adelton. Modified 10 months ago

Request for enhancement

As an admin, I want to deploy FreeIPA read-only containers.

Issue

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

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.

On latest Fedoras, hosts line in /etc/nsswitch.conf says

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.

Steps to Reproduce

  1. Make sure host's hostname or address is not in /etc/hosts.
  2. Make /etc/hosts immutable to prevent ipa-server-install from writing to it: chattr +i /etc/hosts
  3. Run ipa-server-install --ip-address 172.29.0.1 where the address is of one of the machine's interfaces.

Actual behavior

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

Expected behavior

It should not fail as myhostname resolves the machines hostname just fine.

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.

Version/Release/Distribution

$ 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

Additional info:

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.

Login to comment on this ticket.

Metadata