cc-set-hostname behavior non-uniform, causes Kerberos issue

[aph3rson]

Bug report

I have a pair of VMs running on a Proxmox host - one using Fedora 40, the other using Ubuntu Noble.
Both have similar cloud-init configurations with an FQDN specified in Proxmox's configuration:

root@pve-1:~# for i in 102 110; do qm cloudinit dump $i user; done
#cloud-config
hostname: sso
manage_etc_hosts: true
fqdn: sso.my.fq.dn
user: bootstrap
ssh_authorized_keys:
  - ssh-rsa [snip]
chpasswd:
  expire: False
users:
  - default
package_upgrade: true

#cloud-config
hostname: gitlab
manage_etc_hosts: true
fqdn: gitlab.my.fq.dn
user: bootstrap
ssh_authorized_keys:
  - ssh-rsa [snip]
chpasswd:
  expire: False
users:
  - default
package_upgrade: true

I was trying to debug why Kerberos (ipa-getcert, specifically) wasn't working on the latter of the two VMs, and it turns out it's due to how cloud-init configures the hostname.
Here's some output from cloud-init's logs:

2025-02-26 06:29:08,784 - helpers.py[DEBUG]: Running config-set_hostname using lock (<FileLock using file '/var/lib/cloud/instances/a3fe93578937bd7fa54d03be7b9b3942758cc7e3/sem/config_set_hostname'>)
2025-02-26 06:29:08,785 - cc_set_hostname.py[DEBUG]: Setting the hostname to sso.my.fq.dn (sso)
2025-02-26 06:29:08,785 - subp.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'sso.my.fq.dn'] with allowed return codes [0] (shell=False, capture=True)
2025-02-26 06:29:08,800 - __init__.py[DEBUG]: Non-persistently setting the system hostname to sso.my.fq.dn
2025-02-26 06:29:08,800 - subp.py[DEBUG]: Running command ['hostname', 'sso.my.fq.dn'] with allowed return codes [0] (shell=False, capture=True)
2025-02-26 06:29:08,802 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmps8bh70as) - w: [644] 58 bytes/chars
2025-02-26 06:29:08,802 - handlers.py[DEBUG]: finish: init-network/config-set_hostname: SUCCESS: config-set_hostname ran successfully

2025-02-26 06:32:48,281 - helpers.py[DEBUG]: Running config-set_hostname using lock (<FileLock using file '/var/lib/cloud/instances/0a368fe66ee1420d4544775c576985eff60af28b/sem/config_set_hostname'>)
2025-02-26 06:32:48,281 - cc_set_hostname.py[DEBUG]: Setting the hostname to gitlab.my.fq.dn (gitlab)
2025-02-26 06:32:48,281 - util.py[DEBUG]: Reading from /etc/hostname (quiet=False)
2025-02-26 06:32:48,281 - util.py[DEBUG]: Reading 7 bytes from /etc/hostname
2025-02-26 06:32:48,281 - util.py[DEBUG]: Writing to /etc/hostname - wb: [644] 7 bytes
2025-02-26 06:32:48,281 - distros[DEBUG]: Non-persistently setting the system hostname to gitlab
2025-02-26 06:32:48,281 - subp.py[DEBUG]: Running command ['hostname', 'gitlab'] with allowed return codes [0] (shell=False, capture=True)
2025-02-26 06:32:48,282 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmp4ym46hj8) - w: [644] 64 bytes/chars
2025-02-26 06:32:48,282 - handlers.py[DEBUG]: finish: init-network/config-set_hostname: SUCCESS: config-set_hostname ran successfully and took 0.001 seconds

This is confirmed in RHEL's hostname set logic (inherited by Fedora):

cloud-init/cloudinit/distros/rhel.py

Line 119 in 9704ba8

subp.subp(["hostnamectl", "set-hostname", str(hostname)])

vs. Debian's hostname set logic (inherited by Ubuntu):

cloud-init/cloudinit/distros/debian.py

Line 160 in 9704ba8

util.write_file(filename, str(conf), 0o644)

The major difference here - on Fedora, /etc/hostname ends up as the FQDN. On Ubuntu, /etc/hostname ends up as just the single label (gitlab). This has a variety of follow-on issues - most notably, though, Kerberos behavior varies greatly if that file has an FQDN in it.

hostnamectl is a systemd component, and is available in Ubuntu. Is there any reason we're editing /etc/hostname directly here?
I feel like we could have some generic typing for setting hostnames via systemd's hostnamectl for multiple different distros. Or, at the very least, let the user select a strategy if desired.

Steps to reproduce the problem

Boot a Fedora (40) and Ubuntu (Noble) instance, both with the same user config (specifying both hostname and fqdn).
Observe the former ends up with an FQDN in /etc/hostname, whereas the latter only has a base name.

Environment details

• Cloud-init version: 24.1.4 and 24.4, respectively (but current source confirms this behavior continues to exist)
• Operating System Distribution: Fedora and Ubuntu
• Cloud provider, platform or installer type: Proxmox VE

cloud-init logs

See above.