Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

live image hostname leaks into some configuration #158

Closed
anarcat opened this issue Apr 29, 2021 · 2 comments
Closed

live image hostname leaks into some configuration #158

anarcat opened this issue Apr 29, 2021 · 2 comments

Comments

@anarcat
Copy link
Contributor

anarcat commented Apr 29, 2021

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. :)

@rlaager
Copy link
Member

rlaager commented Dec 12, 2021

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.

@anarcat
Copy link
Contributor Author

anarcat commented Dec 12, 2021

maybe we could split it up in two places? e.g. run first:

hostname HOSTNAME

then, later, when the dataset is mounted, just:

hostname > /mnt/etc/hostname

that way we wouldn't set the hostname twice, we would set it first, then save it later...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants