As briefly discussed yesterday on IRC, I'll try to add some further info first. If you prefer not to read all of this crap, just scroll down to the suggested documentation amendment.
*** WHY DOES THIS PROBLEM OCCUR AT ALL ***
The installed client uses ssh to connect to the installserver for disabling
network boot in task chboot and to copy the log files in task savelog
respectively fai-savelog.
To make this work non-interactively, an ssh identity (key) is created in
fai-setup, as well as a proper preparation of a known_hosts file is attempted.
A known_hosts file contains a comma-separated list of hostnames and the
corresponding server keys. For a known_hosts file to work as expected, i.e., to
allow fully non-interactive operation, it must contain the hostname or IP
address used in contacting the server in tasks chboot and savelog.
In task chboot, the host known as $SERVER is contacted. This variable is set by
get-boot-info, using the data provided by the DHCP response. I guess it is safe
to assume that $SERVER coincides with the host where fai-setup is run, so there
is nothing generally wrong up to here.
In task savelog, either $LOGSERVER or $SERVER is used to contact a host. The
latter is only used, if $LOGSERVER is empty. In simple setups, which is exactly
what fai-setup aims at, this will again be the host where fai-setup is run.
*** WHAT WE DO INTERNALLY ***
In fai-setup we thus operate under the assumption that $SERVER is the host where
fai-setup run, which is safe according to the above reasoning. In known_hosts,
the effective value of $SERVER, as used at the time of installation, must thus
be added. When running fai-setup, the best we can do is check all sensible
values. Therefore,
- all IP addresses of the host are added
- for each IP address, we try to obtain a name via `getent hosts`, which uses
name resolution as determined by /etc/nsswitch.conf.
*** WHAT MAY GO WRONG ***
First, the assumption that $SERVER is identical to the host running fai-setup
may be invalid. We can't really do anything in this case, apart from adding some
information to the FAI guide, as shown below.
Second, we may fail to obtain all the names (IP addresses should really be ok).
This may happen for two reasons. First, name lookups may be misconfigured on the
FAI server, or disabled for some reason. Again, there is nothing we can do. At
last, the server may have a bunch of CNAMEs, which do not show up in the output
of getent hosts.
The original submitter even had an added local configuration of setting $SERVER
in fai.conf, as opposed to the usual procedure outlined above. There is no way
to catch all such cases, people might redefine $SERVER in various ways in the
config space as well. If people do this, they should also be prepared to
adapting the known_hosts file themselves, as documented below.
*** POSSIBLE FIX IN CASE OF MISSING CNAMES ***
Starting from the result of getent hosts, we could run host -t any `getent hosts
$ip | awk '{ print $2 }'` and parse its output. This will likely catch more
cases than the current code, but requires the host utility to be installed and
may break in case the output format is ever changed. This fix does not really
fit in the category "keep it simple".
*** PREFERRED FIX: EXTEND THE DOCUMENTATION ***
"In the tasks chboot and savelog, a connection using secure shell is opened to
the FAI server (cf. <add reference to isavelog>). To ensure that this works
non-interactively, a proper entry in NFSROOT/root/.ssh/known_hosts must be
created. When using fai-setup, this is done automatically, but it may require
manual editing in case the name of your FAI server was not determined correctly.
If you stumble over ssh connections that require typing "yes" to accept the host
key during installation, please check the contents of your
NFSROOT/root/.ssh/known_hosts file."
I'd really suggest we add this small piece of documentation to the FAI Guide,
which may then even make it into lenny.
Best,
Michael
pgpoXpSvJ6lkg.pgp
Description: PGP signature
