Définition correcte du nom d'hôte - Fedora 20 sur Amazon EC2

Le contexte

J'ai une image cloud Fedora 20 fonctionnant sur Amazon EC2 (désormais appelée "instance"). Et j'ai une certaine incertitude quant à la définition persistante de son nom d'hôte.

Objectif

Dans ce cas, disons que je veux définir le nom d'hôte de l'instance sur penpen.homelinux.org . (Ce nom sera également enregistré sur DynDNS en utilisant ddclient, mais c'est un autre aspect qui ne nous intéresse pas ici.)

Le nom d'hôte peut bien sûr être défini manuellement une fois le démarrage terminé (en utilisant hostnamectlentre autres). Mais nous voulons que le nom d'hôte correct soit défini avant la première connexion.

Traditionnellement, pour configurer de manière persistante le nom d'hôte, on modifierait le contenu de /etc/hostname. Malheureusement, cela ne fonctionne pas ici.

Comportement système par défaut

Par défaut, l'instance définit son nom d'hôte sur un nom EC2 interne. Après le démarrage, nous pouvons regarder tous les petits endroits différents qui donnent le nom d'hôte, et nous trouvons:

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'                 : 

Essayons donc d'écrire dans / etc / hostname ...

Si l'on écrit le nom d'hôte souhaité /etc/hostname, cette modification est à nouveau perdue au prochain démarrage. Examinons le processus de démarrage, qui est effectué par systemd.

Exemple d'exécution

Écrivez rorororoor.homelinux.orgà /etc/hostname, puis redémarrez.

En utilisant journald, nous trouvons (Notez que les lignes de log ne sont pas entièrement ordonnées par le temps):

Le processus de démarrage démarre avec le nom d'hôte en tant qu'hôte local, puis passe en mode racine, auquel cas le nom d'hôte devient 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.

Nous voyons que systemddéfinit le nom d'hôte sur rorororoor.homelinux.org , évidemment avec succès lorsque la colonne hôte du journal change. Certaines erreurs sont émises, peut-être parce que hostnamectlvous ne pouvez pas contacter DBus à ce stade.

Je ne sais pas qui fait la composition du nom ici; une partie interne de systemd? Quoi qu'il en soit, en continuant à travers le journal, nous constatons que le nom d'hôte revient très bientôt au nom interne EC2:

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)

Le réglage du nom d'hôte ici se fait via l'unité "systemd-hostnamed". Le "fichier d'unité" pour "systemd-hostnamed" est /usr/lib/systemd/system/systemd-hostnamed.serviceet contient:

[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

Le programme invoqué par ce qui précède /usr/lib/systemd/systemd-hostnamedest en fait un binaire (POURQUOI!). Cependant, le code source peut être trouvé.

Le fait est que nous sommes de retour à ip-10-164-65-105.ec2.internal

QU'EST-CE QUE?

Vous devez faire deux choses (mais n'en avez fait qu'une seule):

1. Définissez le nom d'hôte dans /etc/hostname.
2. Modifiez /etc/cloud/cloud.cfget définissez preserve_hostnamesur True. (Vous pouvez également transmettre cette option avec vos données utilisateur.)

La deuxième étape est nécessaire car Fedora utilise cloud-initpour importer des données utilisateur de l'environnement EC2 pour provisionner l'instance, et cloud-initdoit être informé que le nom d'hôte doit persister.

Une autre option consiste à définir le nom d'hôte via les données utilisateur

par exemple

#cloud-config
hostname: foo
fqdn: foo.bar.net

Cela définira le nom d'hôte au démarrage, mais je ne sais pas si cela se produira toujours avant la première connexion.

Il semble que la réponse se trouve dans la page de manuel hostnamectl, il y a maintenant 3 noms d'hôtes, les noms d'hôtes statiques, transitoires et jolis.

Pour définir le nom d'hôte statique qui, je pense, est celui que vous souhaitez,

hostnamectl --static set-hostname somehost.tld

Vous pouvez les définir tous de la même manière avec

hostnamectl set-hostname somehost.tld

Résoudre à l'aide d'un fichier d'unité supplémentaire

Ce qui suit ne fonctionne pas vraiment:

Créez un fichier d'unité système /usr/lib/systemd/system/penpen-naming.serviceà démarrer après systemd-hostnamed.service(et éventuellement uniquement après dbus.service).

(J'ai dû effectuer quelques essais discrets pour trouver le «bon endroit» afin de systemdne pas désactiver simplement la nouvelle unité car «un cycle a été détecté». Notez que vous pouvez représenter graphiquement le graphique de dépendance des fichiers d'unité avec systemd-analyze dot, ce qui crée un «point "fichier à passer au dotprogramme " graphviz " , mais le résultat est juste un grand graphique déroutant, à moins que vous ne le préfiltrez)

Contenu du fichier d'unité /usr/lib/systemd/system/penpen-naming.service:

[Unit]
Description= *** Hostname becomes 'penpen.homelinux.org' ***
After=default.target 
# After=systemd-hostnamed.service -- NOPE 
# After=dbus.service  -- NOPE

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/toolbox/setting_hostnames/penpen

[Install]
WantedBy=multi-user.target

Activez-le en utilisant systemctl enable penpen-naming

Que fait /usr/local/toolbox/setting_hostnames/penpen-il? Si écrit penpen.homelinux.org à /etc/hostname. Mais cela ne suffit pas, il faut également définir le nom d'hôte à l'aide hostnamectl.

Même alors, l'unité doit être exécutée si tard (After=default.target)que le shell de connexion affiche toujours le nom d'hôte interne EC2. Et il y a toujours des problèmes de connexion à DBus.

Ce n'est donc pas une bonne solution, ou au moins il a besoin d'un correctif pour "position dans l'arborescence de dépendance des fichiers d'unité" et "ce qui se passe avec dbus"

Les noms d'hôtes suivants sont:

Kernel hostname via 'sysctl'                      : penpen.homelinux.org
Kernel domainname via 'sysctl'                    : (none)
File '/etc/hostname'                              : contains 'penpen.homelinux.org'
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'              : penpen.homelinux.org
Hostname ('hostname')                             : penpen.homelinux.org
Short hostname ('hostname --short')               : penpen
NIS domain name ('domainname')                    : (none)
YP default domain ('hostname --yp')               : [hostname --yp failed]
DNS domain name ('hostname --domain')             : homelinux.org
Fully qualified hostname ('hostname --fqdn')      : penpen.homelinux.org
Hostname alias ('hostname --alias')               : 
By IP address ('hostname --ip-address')           : 54.221.0.63
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'                 : penpen.homelinux.org
Transient hostname via 'hostnamectl'              : penpen.homelinux.org
Pretty hostname via 'hostnamectl'                 : 

Il s'agit en fait d'un bogue dans cloud-init sur les distributions de type RHEL utilisant SystemD. Un patch est disponible sur https://bugs.launchpad.net/cloud-init/+bug/1424710