hostname diferencia maiúsculas de minúsculas - saída diferente para getent

2
[root@GFVM4 ~]# hostname
GFVM4
[root@GFVM4 ~]# 
[root@GFVM4 ~]# 
[root@GFVM4 ~]# getent hosts gfvm4
192.168.122.151 GFVM4
[root@GFVM4 ~]# getent hosts GFVM4
fe80::5054:ff:feac:787 GFVM4
[root@GFVM4 ~]# 
[root@GFVM4 ~]# 
[root@GFVM4 ~]# 
[root@GFVM4 ~]# ifconfig ens5
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.151  netmask 255.255.255.0  broadcast 192.168.122.255
        inet6 fe80::5054:ff:feac:787  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:ac:07:87  txqueuelen 1000  (Ethernet)
        RX packets 452  bytes 33008 (32.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 204  bytes 26112 (25.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@GFVM4 ~]# 

O comportamento esperado acima é

?

Como você pode ver, eu configurei todas as letras maiúsculas HOSTNAME GFVM4.

se eu usar o mesmo nome (ALL CAPS), ele retornará o endereço ipv6. Se eu usar o nome do host com letras pequenas, ele retornará o endereço ipv4.

Este comportamento é correto?

Executando o Fedora21 como uma VM baseada em qemu.

Obrigado

    
por kumar 22.09.2015 / 11:39

2 respostas

1

Esta não será uma resposta completa, só quero compartilhar minhas descobertas, e é muito longa para caber nos comentários ...

Primeiro, se você quiser responder em getent , você precisa ter a configuração correta em /etc/nsswitch.conf , /etc/resolv.conf , /etc/hosts , etc. Eu tenho um Fedora 22 e ele tem a seguinte linha em /etc/nsswitch.conf .

hosts:    files mdns4_minimal [NUTFOUND=return] dns myhostname

getent hosts localhost e getent hosts LOCALHOST fornecem resultados diferentes. Mas depois que eu mudei /etc/nsswitch.conf para ter hosts: files , eles deram o mesmo resultado.

Acho que quando você tem várias fontes para pesquisar, elas podem tratar o caso de forma diferente e fornecer resultados inconsistentes.

Em segundo lugar, você pode querer experimentar getent ahost . Usa getaddrinfo() em vez de gethostbyname2() . Dá respostas mais consistentes, pelo menos no meu caso. Consulte man getent .

Em terceiro lugar, achei interessante ler o código-fonte getent.c e observar o rastreamento por %código%. Lá você pode ver ltrace getent hosts localhost e inet_pton() . Você também pode rastrear chamadas do sistema por gethostbyname2() e você pode ver quais arquivos estão abertos, como ltrace -S .

Abaixo está a saída de /etc/hosts . AF_INET6 (10) é tentado antes de AF_INET (2).

[a@localhost ~]$ ltrace getent hosts LOCALHOST
__libc_start_main([ "getent", "hosts", "LOCALHOST" ] <unfinished ...>
mtrace()                                                                                                     = <void>
setlocale(LC_ALL, "")                                                                                        = "en_US.UTF-8"
textdomain("libc")                                                                                           = "libc"
argp_parse(0x606440, 3, 0x7ffc1cf8a7c8, 0)                                                                   = 0
strcmp("hosts", "hosts")                                                                                     = 0
inet_pton(10, 0x7ffc1cf8c67a, 0x7ffc1cf8a680, 0)                                                             = 0
inet_pton(2, 0x7ffc1cf8c67a, 0x7ffc1cf8a680, 0x658e2f20)                                                     = 0
gethostbyname2(0x7ffc1cf8c67a, 10, 0x7ffc1cf8a680, 0x658e2f20)                                               = 0
gethostbyname2(0x7ffc1cf8c67a, 2, -20, 0x7f166586c8f5)                                                       = 0x7f1665b16260
inet_ntop(2, 0xc47000, 0x7ffc1cf8a620, 46)                                                                   = 0x7ffc1cf8a620
printf("%-15s %s", "127.0.0.1", "localhost.localdomain")                                                     = 37
__overflow(0x7f1665b13620, 32, 0, 0x7fffffda)                                                                = 32
fputs_unlocked(0xc47041, 0x7f1665b13620, 0x7f1665d36025, 0xfbad2a84)                                         = 1
__overflow(0x7f1665b13620, 10, 0xc47050, 0x74736f686c61636f127.0.0.1       localhost.localdomain localhost
)                                                 = 10
+++ exited (status 0) +++

Por fim, minha sugestão é 1) controlar a origem de ltrace em getent ; ou 2) mantenha seu próprio banco de dados / dicionário.

    
por 03.10.2015 / 06:49
0

Apenas um palpite, mas a partir do link :

hosts     When no key is provided, use sethostent(3), gethostent(3),
                    and  endhostent(3)  to enumerate the hosts database.  When
                    one or more key arguments are provided, pass each  key  to
                    gethostbyaddr(3)   or   gethostbyname2(3),   depending  on
                    whether a call to inet_pton(3) indicates that the  key  is
                    an IPv6 or IPv4 address or not, and display the result.

Em link "if (argc = = 2) "significa"% hosts getent "(nenhuma chave fornecida), então isso é feito:

    for (i = 2; i < argc; i++) {
        if (inet_pton(AF_INET6, argv[i], (void *)addr) > 0)
            he = gethostbyaddr(addr, IN6ADDRSZ, AF_INET6);
        else if (inet_pton(AF_INET, argv[i], (void *)addr) > 0)
            he = gethostbyaddr(addr, INADDRSZ, AF_INET);
        else
            he = gethostbyname(argv[i]);
        if (he != NULL)
            hostsprint(he);
        else {
            rv = RV_NOTFOUND;
            break;
        }
    }

Eu não sou grande em C, e a única fonte que encontrei em um googling rápido foi o NetBSD, mas parece que se o primeiro inet_pton ( link ) encontra uma entrada para IPv6, a segunda função para IPv4 é ignorada. Além disso, eu não vi qualquer forçamento do caso à primeira vista (o que significa que o caso-insento não parece forçado).

Dito isto, você pode ter 2 entradas para GFVM4, uma é superior e outra é menor. O superior provavelmente possui um endereço IPv6 associado.

Seria ótimo se você pudesse confirmar ou não as diferentes entradas em diferentes casos, para confirmar (ou não). Se confirmado, eu diria que é o comportamento esperado do software getent.

    
por 05.10.2015 / 17:04