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 hostnamectl
entre 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 systemd
dé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 hostnamectl
vous 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.service
et 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-hostnamed
est 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?
sudo hostnamectl set-hostname --static myhost.example.com
, qui écrit/etc/hostname
également.Une autre option consiste à définir le nom d'hôte via les données utilisateur
par exemple
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.
la source
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,
Vous pouvez les définir tous de la même manière avec
la source
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èssystemd-hostnamed.service
(et éventuellement uniquement aprèsdbus.service
).(J'ai dû effectuer quelques essais discrets pour trouver le «bon endroit» afin de
systemd
ne 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é avecsystemd-analyze dot
, ce qui crée un «point "fichier à passer audot
programme " 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
: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'aidehostnamectl
.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:
la source
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
la source