Contexto
Tengo una imagen en la nube de Fedora 20 ejecutándose en Amazon EC2 (en adelante denominada "instancia"). Y tengo cierta incertidumbre sobre la configuración persistente de su nombre de host.
Objetivo
En este caso, digamos que quiero establecer el nombre de host de la instancia en penpen.homelinux.org . (Este nombre también se registrará en DynDNS usando ddclient
, pero ese es otro aspecto que no nos interesa aquí).
El nombre de host, por supuesto, se puede configurar manualmente después de que se complete el arranque (utilizando hostnamectl
entre otros). Pero queremos tener el nombre de host correcto establecido antes del primer inicio de sesión.
Tradicionalmente, para configurar persistentemente el nombre de host, uno modificaría el contenido de /etc/hostname
. Lamentablemente esto no funciona aquí.
Comportamiento predeterminado del sistema
De manera predeterminada, la instancia establece su nombre de host en un nombre EC2 interno. Después del arranque, podemos ver todos los pequeños lugares diferentes que producen el nombre de host, y encontramos:
Kernel hostname via 'sysctl' : ip-10-164-65-105.ec2.internal
Kernel domainname via 'sysctl' : (none)
File '/etc/hostname' : contains 'ip-10-164-65-105.ec2.internal'
File '/etc/sysconfig/network' : exists but has no 'HOSTNAME' line
According to the shell : HOSTNAME = ip-10-164-65-105.ec2.internal
Nodename given by 'uname --nodename' : ip-10-164-65-105.ec2.internal
Hostname ('hostname') : ip-10-164-65-105.ec2.internal
Short hostname ('hostname --short') : ip-10-164-65-105
NIS domain name ('domainname') : (none)
YP default domain ('hostname --yp') : [hostname --yp failed]
DNS domain name ('hostname --domain') : ec2.internal
Fully qualified hostname ('hostname --fqdn') : ip-10-164-65-105.ec2.internal
Hostname alias ('hostname --alias') :
By IP address ('hostname --ip-address') : 10.164.65.105
All IPs ('hostname --all-ip-addresses') : 10.164.65.105
All FQHNs via IPs ('hostname --all-ip-addresses') : ip-10-164-65-105.ec2.internal
Static hostname via 'hostnamectl' : ip-10-164-65-105.ec2.internal
Transient hostname via 'hostnamectl' : ip-10-164-65-105.ec2.internal
Pretty hostname via 'hostnamectl' :
Así que tratemos de escribir en / etc / hostname ...
Si se escribe el nombre de host deseado /etc/hostname
, este cambio se pierde nuevamente en el próximo arranque. Examinemos el proceso de arranque, que es realizado por systemd
.
Ejecución de ejemplo
Escriba rorororoor.homelinux.org
en /etc/hostname
, luego reinicie.
Usando journald encontramos (Tenga en cuenta que las líneas de registro no están completamente ordenadas por tiempo):
El proceso de arranque comienza con el nombre de host como localhost luego cambia de raíz, en cuyo punto el nombre de host se convierte en rorororoor.homelinux.org .
Dec 26 15:12:08 localhost systemd[1]: Starting Cleanup udevd DB...
Dec 26 15:12:08 localhost systemd[1]: Started Cleanup udevd DB.
Dec 26 15:12:08 localhost systemd[1]: Starting Switch Root.
Dec 26 15:12:08 localhost systemd[1]: Reached target Switch Root.
Dec 26 15:12:08 localhost systemd[1]: Starting Switch Root...
Dec 26 15:12:08 localhost systemd[1]: Switching root.
Dec 26 15:12:08 localhost systemd-journal[67]: Journal stopped
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journal[155]: Runtime journal is using 8.0M
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journal[155]: Runtime journal is using 8.0M
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journald[67]: Received SIGTERM
...........
Dec 26 15:12:12 rorororoor.homelinux.org kernel: SELinux: initialized
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journal[155]: Journal started
Dec 26 15:12:08 rorororoor.homelinux.org systemd-cgroups-agent[128]: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: No such file or directory
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: systemd 208 running in system mode.
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: Detected virtualization 'xen'.
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: Set hostname to <rorororoor.homelinux.org>.
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: Failed to open private bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
Dec 26 15:12:11 rorororoor.homelinux.org systemd[1]: Mounted Debug File System.
Vemos que systemd
establece el nombre de host en rorororoor.homelinux.org , evidentemente con éxito a medida que cambia la columna de host del registro. Se emiten algunos errores, posiblemente porque hostnamectl
no puede contactar a DBus en este momento.
No estoy seguro de quién hace el nombre aquí; alguna parte interna de systemd? De todos modos, continuando a través del diario, encontramos que el nombre de host se restablece al nombre interno de EC2 muy pronto:
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] util.py[DEBUG]: Running command ('resize2fs', '/dev/xvda1') with allowed return codes [0] (shell=False, capture=True)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing took 0.067 seconds
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] cc_resizefs.py[DEBUG]: Resized root filesystem (type=ext4, val=True)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] helpers.py[DEBUG]: config-set_hostname already ran (freq=once-per-instance)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] helpers.py[DEBUG]: Running config-update_hostname using lock (<cloudinit.helpers.DummyLock object at 0x2559210>)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] cc_update_hostname.py[DEBUG]: Updating hostname to ip-10-164-65-105.ec2.internal (ip-10-164-65-105)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] util.py[DEBUG]: Running command ['hostname'] with allowed return codes [0] (shell=False, capture=True)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] __init__.py[DEBUG]: Attempting to update hostname to ip-10-164-65-105.ec2.internal in 1 files
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] util.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'ip-10-164-65-105.ec2.internal'] with allowed return codes [0] (shell=False, capture=True)
Dec 26 15:12:33 rorororoor.homelinux.org dbus-daemon[226]: dbus[226]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Dec 26 15:12:33 rorororoor.homelinux.org dbus[226]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Dec 26 15:12:34 rorororoor.homelinux.org systemd[1]: Starting Hostname Service...
Dec 26 15:12:34 rorororoor.homelinux.org dbus-daemon[226]: dbus[226]: [system] Successfully activated service 'org.freedesktop.hostname1'
Dec 26 15:12:34 rorororoor.homelinux.org dbus[226]: [system] Successfully activated service 'org.freedesktop.hostname1'
Dec 26 15:12:34 rorororoor.homelinux.org systemd[1]: Started Hostname Service.
Dec 26 15:12:34 rorororoor.homelinux.org systemd-hostnamed[598]: Changed static host name to 'ip-10-164-65-105.ec2.internal'
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd-hostnamed[598]: Changed host name to 'ip-10-164-65-105.ec2.internal'
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Started Initial cloud-init job (metadata service crawler).
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Starting Cloud-config availability.
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Reached target Cloud-config availability.
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Starting Apply the settings specified in cloud-config...
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] helpers.py[DEBUG]: Running config-update_etc_hosts using lock (<cloudinit.helpers.DummyLock object at 0x2559350>)
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] cc_update_etc_hosts.py[DEBUG]: Configuration option 'manage_etc_hosts' is not set, not managing /etc/hosts in module update_etc_hosts
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] helpers.py[DEBUG]: config-rsyslog already ran (freq=once-per-instance)
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] helpers.py[DEBUG]: config-users-groups already ran (freq=once-per-instance)
La configuración del nombre de host aquí se realiza a través de la unidad "systemd-hostnamed". El "archivo de unidad" para "systemd-hostnamed" es /usr/lib/systemd/system/systemd-hostnamed.service
y contiene:
[Unit]
Description=Hostname Service
Documentation=man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/hostnamed
[Service]
ExecStart=/usr/lib/systemd/systemd-hostnamed
BusName=org.freedesktop.hostname1
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE
El programa invocado por lo anterior /usr/lib/systemd/systemd-hostnamed
es en realidad un binario (¡POR QUÉ!). Sin embargo , se puede encontrar el código fuente .
El punto es que estamos de vuelta en ip-10-164-65-105.ec2.internal
¿QUÉ HACER?
sudo hostnamectl set-hostname --static myhost.example.com
, que también escribe/etc/hostname
.Otra opción es establecer el nombre de host a través de los datos del usuario
p.ej
Esto establecerá el nombre de host en el arranque, sin embargo, no estoy seguro de si eso siempre sucedería antes del primer inicio de sesión.
fuente
Parece que la respuesta está en la página de manual hostnamectl ahora hay 3 nombres de host, los nombres de host estáticos, transitorios y bonitos.
Para establecer el nombre de host estático que creo que es el que desea,
Puede configurarlos para que sean iguales con
fuente
Resolver usando un archivo de unidad adicional
Lo siguiente no funciona realmente:
Cree un archivo de unidad del sistema
/usr/lib/systemd/system/penpen-naming.service
para que se inicie despuéssystemd-hostnamed.service
(y posiblemente solo despuésdbus.service
).(Tuve que realizar algunas pruebas silenciosas para encontrar el "lugar correcto" para que
systemd
no se desactivara simplemente la nueva unidad porque "se detectó un ciclo". Tenga en cuenta que puede graficar el gráfico de dependencia del archivo de la unidad consystemd-analyze dot
, lo que crea un "punto "archivo que se pasará aldot
programa " graphviz " , pero el resultado es solo un gran gráfico confuso, a menos que lo filtre previamente )Contenido del archivo de la unidad
/usr/lib/systemd/system/penpen-naming.service
:Activalo usando
systemctl enable penpen-naming
¿Qué
/usr/local/toolbox/setting_hostnames/penpen
hacer? Si escribe penpen.homelinux.org a/etc/hostname
. Pero eso en realidad no es suficiente, uno también tiene que configurar el nombre de host usandohostnamectl
.Incluso entonces, la unidad debe ejecutarse tan tarde
(After=default.target)
que el shell de inicio de sesión todavía muestra el nombre de host interno EC2. Y todavía hay problemas para conectarse a DBus.Así que esta no es una buena solución, o al menos necesita una solución para "posición en el árbol de dependencia del archivo de la unidad" y "qué demonios pasa con dbus"
Los nombres de host después de esto son:
fuente
Esto es realmente un error en cloud-init en distribuciones similares a RHEL usando SystemD. Hay un parche disponible en https://bugs.launchpad.net/cloud-init/+bug/1424710
fuente