You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
during the Buster install procedure, we set the hostname in the chroot basically like this:
echo $HOSTNAME > /mnt/etc/hostname
(Well, not exactly, but that's the short version.)
That's fine and good for when the system boots and is installed, but what happens when you do things like this?
apt install openssh-server
If you haven't guessed yet, the OpenSSH server keys get generated, and they get their metadata (ie. the hostname) from the hostname command (or, more accurately, probably the gethostname(2) syscall). And that will talk to the live image kernel, which will not return the hostname from /mnt/etc/hostname. In my case, the hostname stored in the SSH keys was grml because that's the hostname of the live image I used (grml.org).
A quick grep on a fresh Debian bullseye install (see #126) finds a copy of the live hostname in /etc/ssh/ssh*.pub files and /etc/zfs/zpool.cache. The SSH public keys error is somewhat harmless: it's only the key comment, but it can be confusing and should be fixed. I don't know how bad it is that the zpool.cache has the wrong hostname.
We should do this instead:
hostname $HOSTNAME
hostname > /mnt/etc/hostname
That's the canonical way to set the hostname in an installer. It ensures coherence between the running and configured hostnames. It overwrites the hostname of the live image, of course, but that's not a problem because, well, it's a live image. :)
The text was updated successfully, but these errors were encountered:
I made the suggested change. Note that this change does not change what appears in zpool.cache, as that gets populated earlier when the pools are created. We could run hostname HOSTNAME much earlier in the process if we care about that. But given it's not creating any practical problem that I'm seeing, I didn't do that, as it would complicate the instructions: we'd have two sections where the hostname is set.
during the Buster install procedure, we set the hostname in the chroot basically like this:
(Well, not exactly, but that's the short version.)
That's fine and good for when the system boots and is installed, but what happens when you do things like this?
If you haven't guessed yet, the OpenSSH server keys get generated, and they get their metadata (ie. the hostname) from the
hostname
command (or, more accurately, probably thegethostname(2)
syscall). And that will talk to the live image kernel, which will not return the hostname from/mnt/etc/hostname
. In my case, the hostname stored in the SSH keys wasgrml
because that's the hostname of the live image I used (grml.org).A quick grep on a fresh Debian bullseye install (see #126) finds a copy of the live hostname in
/etc/ssh/ssh*.pub
files and/etc/zfs/zpool.cache
. The SSH public keys error is somewhat harmless: it's only the key comment, but it can be confusing and should be fixed. I don't know how bad it is that thezpool.cache
has the wrong hostname.We should do this instead:
That's the canonical way to set the hostname in an installer. It ensures coherence between the running and configured hostnames. It overwrites the hostname of the live image, of course, but that's not a problem because, well, it's a live image. :)
The text was updated successfully, but these errors were encountered: