☰

De onde o systemd determina o nome do host transitório?

tag-icon • tag-icon boot systemd
De onde o systemd determina o nome do host transitório?

No RHEL 7.2, systemdinicia e determina o nome do host do host. Se /etc/hostnameestiver indisponível (ou seja, removido) e /etc/machine-infoinacessível, e o kernel não estiver configurado com essa informação (ou seja, sysctl's kernel.hostname), systemdatribui um nome de host "transitório" ao host. A questão é: de onde isso determina isso?

O host foi originalmente nomeado desta forma. Em seguida, clonei o host (é uma VM) e limpei todas as referências a esse nome. Mas então, durante o processo de inicialização, bem cedo, ele é configurado dessa forma.

Se eu inicializar, rescuemodeposso ver que ele define o nome do host muito cedo:

[    0.456076] systemd[1]: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +AC
L +XZ)
[    0.456664] systemd[1]: Detected virtualization 'kvm'.
[    0.456955] systemd[1]: Running in initial RAM disk.
[    0.458496] systemd[1]: Set hostname to <badhostname.example.com>.
[    0.475394] systemd[1]: Expecting device dev-mapper-vgroot\x2dlvroot.device...

No prompt de comando, ele é definido como um nome de host “transitório”:

# hostnamectl status
Transient hostname: badhostname.mydomain.com
...

Pode ser que não systemd: eu até tenho esse problema ao usar init=/bin/bash, mas o systemd está rodando dentro da imagem initrd.

  • Não está definido no grub nem nada.
  • Não é definido pelo DHCP, pois a rede está desativada na inicialização.

  • Não está em nenhum lugar do sistema de arquivos:

    # find / \( -path /sys -prune -o -path /proc -prune -o -path /run -prune \) -o -type f -exec grep -ilrF "${HOSTNAME}" {} +
<some .git files>
<history files of non-root user>

De alguma forma, o kernel ou systemd está determinando o nome do host antigo e usando-o como um transitório, e não sei como! . Eu fiz um find ... -exec grepsem resultados, exceto /var/log/dmesg. Estou lhe dizendo, o systemd assombrou meu host!

EDIT 2: A única vez que não entendo é se eu inicializar no initramfs de resgate fornecido. Aparentemente, o initramfs gerado guarda segredos sujos!

Responder1

Graças aos insights de Don Crissti e por meio do processo de eliminação, conclui-se que o culpado é a imagem do initramfs. De alguma forma, dracutquando ela é construída, a imagem decide incluir uma versão em cache do nome do host (!?!).

A reconstrução do initrd/initram fs é abordadaaquimas resumindo (já que você, caro leitor, pode não ter acesso), faça

dracut -f -v

informação relacionada