Contexto
Eu tenho uma imagem de nuvem do Fedora 20 em execução no Amazon EC2 (doravante denominada "instância"). E eu tenho alguma incerteza sobre definir persistentemente seu nome de host.
Objetivo
Nesse caso, digamos que desejo definir o nome do host da instância como penpen.homelinux.org . (Esse nome também será registrado no DynDNS usando ddclient
, mas esse é outro aspecto no qual não estamos interessados aqui.)
É claro que o nome do host pode ser definido manualmente após a inicialização (usando hostnamectl
entre outros). Mas queremos que o nome do host correto seja definido antes do primeiro login.
Tradicionalmente, para configurar persistentemente o nome do host, é necessário modificar o conteúdo de /etc/hostname
. Infelizmente, isso não funciona aqui.
Comportamento padrão do sistema
Por padrão, a instância define seu nome de host como um nome interno do EC2. Após a inicialização, podemos observar todos os pequenos locais diferentes que produzem o nome do host e 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' :
Então, vamos tentar escrever para / etc / hostname ...
Se alguém escrever o nome do host desejado /etc/hostname
, essa alteração será perdida novamente na próxima inicialização. Vamos examinar o processo de inicialização, realizado por systemd
.
Exemplo de execução
Escreva rorororoor.homelinux.org
para /etc/hostname
e reinicie.
Usando o journald , encontramos (Observe que as linhas de log não são totalmente ordenadas por tempo):
O processo de inicialização começa com o nome do host como localhost e, em seguida, muda de raiz, quando o nome do host se torna 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
define o nome do host como rorororoor.homelinux.org , evidentemente com êxito à medida que a coluna host do log é alterada. Alguns erros são emitidos, possivelmente porque hostnamectl
não podem entrar em contato com o DBus neste momento.
Não tenho certeza de quem faz a digitação aqui; alguma parte interna do systemd? De qualquer forma, continuando o diário, descobrimos que o nome do host está definido novamente para o nome interno do 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)
A configuração do nome do host aqui é feita através da unidade "systemd-hostnamed". O "arquivo de unidade" para "systemd-hostnamed" é /usr/lib/systemd/system/systemd-hostnamed.service
e contém:
[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
O programa invocado pelo acima /usr/lib/systemd/systemd-hostnamed
é realmente um binário (POR QUE!). No entanto, o código fonte pode ser encontrado.
O ponto é que estamos de volta em ip-10-164-65-105.ec2.internal
FAZER O QUE?
sudo hostnamectl set-hostname --static myhost.example.com
, que também escreve/etc/hostname
.Outra opção é definir o nome do host via dados do usuário
por exemplo
Isso definirá o nome do host na inicialização, no entanto, não tenho certeza se isso sempre aconteceria antes do primeiro login.
fonte
Parece que a resposta está na página do manual hostnamectl, agora existem 3 nomes de host, os estáticos, transitórios e bonitos.
Para definir o nome do host estático que eu acho que é o que você deseja,
Você pode configurá-los todos para serem iguais
fonte
Resolva usando um arquivo de unidade adicional
O seguinte realmente não funciona:
Crie um arquivo de unidade do sistema
/usr/lib/systemd/system/penpen-naming.service
para ser iniciado depoissystemd-hostnamed.service
(e possivelmente somente depoisdbus.service
).(Eu tive que realizar algumas tentativas silenciosas para encontrar o "lugar certo", para que
systemd
não fosse simples desativar a nova unidade porque "um ciclo foi detectado". Observe que você pode representar graficamente o gráfico de dependência do arquivo de unidadesystemd-analyze dot
, o que cria um "ponto" "arquivo a ser passado para o programa" graphviz "dot
, mas o resultado é apenas um grande gráfico confuso, a menos que você o pré-filtre)Conteúdo do arquivo da unidade
/usr/lib/systemd/system/penpen-naming.service
:Ative-o usando
systemctl enable penpen-naming
O que
/usr/local/toolbox/setting_hostnames/penpen
faz? Se escreve penpen.homelinux.org em/etc/hostname
. Mas na verdade isso não é suficiente, é preciso também definir o nome do host usandohostnamectl
.Mesmo assim, a unidade precisa ser executada tão tarde
(After=default.target)
que o shell de login ainda exibe o nome do host interno do EC2. E ainda há problemas para se conectar ao DBus.Portanto, essa não é uma boa solução, ou pelo menos precisa de uma correção para "posição na árvore de dependência de arquivos unitários" e "o que diabos está acontecendo com o dbus"
Os nomes de host depois disso são:
fonte
Na verdade, isso é um bug no cloud-init em distros do tipo RHEL usando o SystemD. Existe um patch disponível em https://bugs.launchpad.net/cloud-init/+bug/1424710
fonte