
Percebi que o método "preferido" de definir o nome do host do sistema é fundamentalmente diferente entre os sistemas Red Hat/CentOS e Debian/Ubuntu.
Documentação do CentOSe aGuia de implantação RHELdiga o nome do hostdeve ser o FQDN:
HOSTNAME=<value>
, onde<value>
deve ser o nome de domínio totalmente qualificado (FQDN), comohostname.example.com
, mas pode ser qualquer nome de host necessário.
OGuia de instalação RHELé um pouco mais ambíguo:
A instalação solicita que você forneça um nome de host para este computador, como nome de domínio totalmente qualificado(FQDN) no formatonome de host.nome de domínio ou como um nome de host curto no formatonome de anfitrião.
A referência do Debiandiz o nome do hostnão deve usar o FQDN:
3.5.5. O nome do host
O kernel mantém o sistemanome de anfitrião. O script de inicialização no nível de execução S que está vinculado simbolicamente a "/etc/init.d/hostname.sh" define o nome do host do sistema no momento da inicialização (usando onome de anfitriãocomando) para o nome armazenado em "/etc/nome do host". Este arquivo deve conterapenaso nome do host do sistema, não um nome de domínio totalmente qualificado.
Não vi nenhuma recomendação específica da IBM sobre qual usar, masalgum softwareparece ter uma preferência.
Minhas perguntas:
- Em um ambiente heterogêneo, é melhor usar a recomendação do fornecedor ou escolher uma e ser consistente em todos os hosts?
- Qual software você encontrou que é sensível ao fato de o nome do host estar definido como FQDN ou nome abreviado?
Responder1
Eu escolheria uma abordagem consistente em todo o ambiente. Ambas as soluções funcionam bem e permanecerão compatíveis com a maioria dos aplicativos. No entanto, há uma diferença na capacidade de gerenciamento.
Eu uso o nome abreviado como configuração HOSTNAME e defino o FQDN como a primeira coluna /etc/hosts
do IP do servidor, seguido pelo nome abreviado.
Não encontrei muitos pacotes de software que imponham ou exibam uma preferência entre os dois. Acho que o nome abreviado é mais limpo para alguns aplicativos, especificamente para registro. Talvez eu tenha tido azar em ver domínios internos como server.northside.chicago.rizzomanufacturing.com
. Quem quer ver isso nos logs ou em umprompt de shell?
Às vezes, estou envolvido em aquisições ou reestruturações de empresas onde os domínios e/ou subdomínios internos mudam. Gosto de usar o nome de host curto nesses casos porque o registro, kickstarts, impressão, monitoramento de sistemas, etc. não precisam de reconfiguração completa para dar conta dos novos nomes de domínio.
Uma configuração típica de servidor RHEL/CentOS para um servidor chamado "rizzo" com domínio interno "ifp.com" seria semelhante a:
/etc/sysconfig/network:
HOSTNAME=rizzo
...
-
/etc/hosts:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.100.13 rizzo.ifp.com rizzo
-
[root@rizzo ~]# hostname
rizzo
-
/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to
chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot
to directory '/app/upload/ftp/SRRID'
Responder2
Praticamente todos os softwares são sensíveis à configuração correta do nome do host. Enquanto eu trabalhava no Digg, uma vez deixei o site inteiro fora do ar por 2 horas devido a uma mudança aparentemente inocente que /etc/hosts
afetou a noção de nome de host do sistema. Pise levemente. Dito isto, você pode estar um pouco confuso aqui. Não acho que a HOSTNAME=
configuração seja diretamente equivalente a como as distribuições baseadas em Debian usam arquivos /etc/hostname
.
O que funciona para mim em um ambiente heterogêneo é:
- Defina o nome do host da maneira recomendada pelo fornecedor, usando uma condicional no seu software de gerenciamento de configuração.
- Use o
hostname
comando para definir o nome do host usado pelo kernel, etc. Em
/etc/hosts
:127.0.0.1 localhost 10.0.0.1 hostname.example.com hostname
Esta configuração ainda não me falhou.
Responder3
Você certamente não terá problemas em encontrar referências online que lhe dirão para fazer isso definitivamente de uma forma ou de outra. Parece-me, no entanto, que ter um nome abreviado como nome do host e ter o nome totalmente qualificado em /etc/hosts é certamente muito mais prevalente. Parece ser a maneira mais sensata, pois então os serviços que precisam de um nome totalmente qualificado podem ser adaptados para chamadas hostname --fqdn
.
Recentemente, encontrei apenas um software que exige rigidamente que um fqdn seja retornado por hostname
, que era ganeti. Eles documentam issoaqui. Não vejo nenhuma razão para que eles não possam se adaptar hostname --fqdn
, no entanto.
Responder4
Resposta curta:Geralmente uso o FQDN como nome do host (conforme recomendado nos documentos do RH6/7). No entanto, a abordagem mais correta seria usar um nome de rótulo único como nome do host, definindo o FQDN via /etc/hosts
. Portanto, escolha uma abordagem e siga-a sempre que possível.
Resposta longa:A principal vantagem de usar o FQDN como nome de host é que o nome da máquina incorpora intrinsecamente informações de domínio. Isso é muito útil ao receber alertas por e-mail e/ou logs para vários clientes/domínios, pois evita nomes de host duplicados (ou seja: nomes de host têm mais ou menos garantia de serem exclusivos em vários sites/clientes/domínios). Por exemplo, o SNMP sysName
mostra o nome do host por padrão e, ao usar o FQDN, simplesmente transmite informações mais úteis. O mesmo se aplica a zabbix-agent
(e outras ferramentas de monitor) ou a bash $HOSTNAME
. Embora você possa configurar essas ferramentas para usar FQDNs mesmo em máquinas com nome de host de rótulo único, ou configurá-las em um modelo hierárquico que mostre claramente o domínio que contém a máquina, isso é um trabalho adicional.
Algumas aplicações atéexigirusando um FQDN como nome de host, mas eles são uma exceção. Ainda assim, quando ocorre a exceção, o uso homogêneo do nome de host de rótulo único é perdido. Esta provavelmente é a principal razão por trás da recomendação da RedHat de usar um FQDN como nome de host no RH6/7. Documentos mais recentes são mais vagos. Sobre"Executando uma instalação padrão do RHEL 8"pode-se ler:
O nome do host pode ser um nome de domínio totalmente qualificado (FQDN) no formato hostname.domainname ou um nome de host curto sem nome de domínio. Muitas redes têm um serviço Dynamic Host Configuration Protocol (DHCP) que fornece automaticamente um nome de domínio aos sistemas conectados. Para permitir que o serviço DHCP atribua o nome de domínio a esta máquina, especifique apenas o nome abreviado do host
enquanto"Executando uma instalação avançada do RHEL 8"afirma:
Se a sua rede não fornecer um serviço DHCP, use sempre o FQDN como nome de host do sistema
Nos anos entre a pergunta original, os aplicativos de usuário aprenderam a tratar nomes de host FQDN sem o problema descrito nas respostas anteriores. Por exemplo, o PS1
prompt do bash usa \h
(o nome do host até o primeiro '.') por padrão e rsyslog
nãonãopreserve o FQDN nos arquivos de log por padrão. Em outras palavras, a desvantagem de usabilidade de um nome de host FQDN não existe mais para muitas ferramentas comuns. Por esses motivos, geralmente defino o nome do host do sistema como FQDN, deixando o nome abreviado ativado /etc/hosts
conforme necessário.
A razão paranãousar um nome de host FQDN é que, francamente, isso éA coisa certa a fazer. Conforme indicado respectivamente nodocumentos debianepágina de manual do nome do host:
Este arquivo deve conter apenas o nome do host do sistema, não um nome de domínio totalmente qualificado
e
Recomenda-se que este nome contenha apenas um rótulo, ou seja, sem pontos
Então, enquanto eu façosentirdesconfortável usar um nome de host FQDN,émais fácil usá-lo em meus ambientes.
Observe que este não é um apelo contra o nome de host de rótulo único. Se eles funcionarem para você, continue usando. Caso contrário, experimente o nome de host FQDN.