Am 16/01/2023 um 17:52 schrieb Friedrich Weber:
> Previously, Setup/CentOS.pm only wrote to /etc/hostname if the file
Nit: note that we prefer avoiding code file names in favor of module names
or more general terms like "the CentOS setup module" - if one wants to
know which file got altered they can always check the git diff/show --stat
output. There are naturally some commits where it may be warranted, but
it's rather an exception.
The rest of the commit message and patch was really great, so it's really
just an very minor nit.
> already existed. Many CT templates of Redhat-derived distros do not
> contain that file, so the containers ended up without /etc/hostname.
> This caused systemd-hostnamed to report the "static hostname" to be
> empty. If networking is handled by NetworkManager, the empty static
> hostname caused DHCP requests to be sent without the "Hostname" field,
> as reported in #4460.
>
> With this fix, Setup/CentOS.pm creates /etc/hostname if it does not
> exist, so NetworkManager correctly reads the hostname and includes it in
> DHCP requests.
>
> Manually tested with the following CT templates (checking that
> /etc/hostname exists and DHCP requests include the hostname):
>
> * Distros using NetworkManager:
> - Alma Linux 9 (almalinux-9-default_20221108_amd64.tar.xz)
> - CentOS 8 (centos-8-default_20201210_amd64.tar.xz)
> - CentOS 9 Stream (centos-9-stream-default_20221109_amd64.tar.xz)
> - Rocky Linux 9 (rockylinux-9-default_20221109_amd64.tar.xz)
> * Distros using network-scripts (here, DHCP requests already contained the
> hostname without this fix, as network-scripts does not rely on
> systemd-hostnamed):
> - Alma Linux 8 (almalinux-8-default_20210928_amd64.tar.xz)
> - CentOS 7 (centos-7-default_20190926_amd64.tar.xz)
> - CentOS 8 Stream (centos-8-stream-default_20220327_amd64.tar.xz)
> - Rocky Linux 8 (rockylinux-8-default_20210929_amd64.tar.xz)
>
> Signed-off-by: Friedrich Weber <f.we...@proxmox.com>
> ---
>
> Question: This will cause Setup/CentOS.pm to create /etc/hostname also
> in already-existing containers. I don't think this should any cause
> issues for users, but I'm not sure. What do you think?
first, as long as the central ct_file_set_contents is used any admin/user
can control if a file is ignored by creating a ".pve-ignore.$file" in the
same directory.
When initially introducing this in c0eae40 ("add class for redhat based
containers") we can see that the if was accompanied by an else earlier, as
it then was deemed to either set the hostname via /etc/hostname or the
sysconfig. There's no actual reason for why that's the case, as after
all it would always be the same value, so it seems that it couldn't
have ever hurt to set both, well, at least if nothing changed behavior
significantly depending on the existence of /etc/hostname - which would
be IMO really weird and in any case quite hard to find out for all possible
CentOS et al. packages - so rather I'd just roll this out slowly and check
for regression reports in the support channels.
>
> src/PVE/LXC/Setup/CentOS.pm | 5 ++---
> src/test/test-centos6-001/etc/hostname.exp | 1 +
> src/test/test-centos6-002/etc/hostname.exp | 1 +
> src/test/test-centos8-001/etc/hostname.exp | 1 +
> 4 files changed, 5 insertions(+), 3 deletions(-)
> create mode 100644 src/test/test-centos6-001/etc/hostname.exp
> create mode 100644 src/test/test-centos6-002/etc/hostname.exp
> create mode 100644 src/test/test-centos8-001/etc/hostname.exp
>
>
applied, thanks!
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
