Hi Tom,
Your test with dig is wrong - dig and nslookup always query a DNS server.
Maybe 'host' command can show it.
I'm using /etc/hosts only for critical systems - like any kind of clusters as based on my experience - you never know when your DNS will be unreachable (in my case it was a network issue, not a DNS actually).
Of course , a local (same subnet) DNS caching/forwarding server can help and provide offloading for the DNS servers.
Also, I prefer to set all cluster memebers in ntp/chrony's config as peers - because even if your time servers are down , the cluster will stay in sync which is very important.
Have you tried setting an entry like this:
IP FQDN hostname
Then 'hostname' will show something like 'mdskvm-p01' instead of FQDN.
Best Regards,
Strahil Nikolov
On Sep 24, 2019 04:31, TomK
wrote:
>
> Hey All,
>
> My hosts below:
>
> [root@mdskvm-p01 ~]# cat /etc/hosts
> 127.0.0.1 localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
> [root@mdskvm-p01 ~]# hostname
> mdskvm-p01.nix.mds.xyz
> [root@mdskvm-p01 ~]# hostname -f
> mdskvm-p01.nix.mds.xyz
> [root@mdskvm-p01 ~]#
>
> [root@mdskvm-p02 ~]# cat /etc/hosts
> 127.0.0.1 localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
> [root@mdskvm-p02 ~]# hostname
> mdskvm-p02.nix.mds.xyz
> [root@mdskvm-p02 ~]# hostname -f
> mdskvm-p02.nix.mds.xyz
> [root@mdskvm-p02 ~]#
>
> My take on the /etc/hosts file discussion:
>
> 1) If hostname / hostname -f returns any valid values, the software
> should capture it.
>
> 2) There is no benefit or need to use /etc/hosts in a small setup.
> Larger setups resolving hosts against an enterprise DNS behind many
> switches could be a problem. Managing our /etc/hosts files using
> Ansible helped to reduce some of these problems esp since lookups are
> logged against the connection tracking tables, that can get full,
> network response time could vary etc. ("Semi static" I guess might
> describe this approach best?) These are populated, if changes are
> needed, via an initial DNS lookup once a day. Invariably, managing
> /etc/hosts is time consuming and messy.
>
> 3) Running a good DNS cluster, something like a two node IPA cluster
> that I run for a small setup, prevents such outages. This particularly
> when also placing a VIP across the nodes and locating cluster nodes
> across different hardware and locations.
>
> 4) Point 2) should be no reason why an application cannot obtain or
> resolve proper DNS entries in 1).
>
> Having said that, decided to check if there's any benefit to having
> entries in /etc/hosts:
>
> [root@mdskvm-p01 ~]# time $(dig mdskvm-p01.nix.mds.xyz >/dev/null)
>
> real 0m0.092s
> user 0m0.087s
> sys 0m0.005s
> [root@mdskvm-p01 ~]# time $(dig mdskvm-p02.nix.mds.xyz >/dev/null)
>
> real 0m0.092s
> user 0m0.084s
> sys 0m0.008s
> [root@mdskvm-p01 ~]# cat /etc/hosts
> 127.0.0.1 localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
> 192.168.0.60 mdskvm-p01.nix.mds.xyz mdskvm-p01
> 192.168.0.39 mdskvm-p02.nix.mds.xyz mdskvm-p02
> [root@mdskvm-p01 ~]# vi /etc/hosts
> [root@mdskvm-p01 ~]# time $(dig mdskvm-p01.nix.mds.xyz >/dev/null)
>
> real 0m0.093s
> user 0m0.082s
> sys 0m0.010s
> [root@mdskvm-p01 ~]# time $(dig mdskvm-p02.nix.mds.xyz >/dev/null)
>
> real 0m0.093s
> user 0m0.085s
> sys 0m0.007s
> [root@mdskvm-p01 ~]# time $(dig mdskvm-p01.nix.mds.xyz >/dev/null)
>
> real 0m0.094s
> user 0m0.084s
> sys 0m0.010s
> [root@mdskvm-p01 ~]# time $(dig mdskvm-p02.nix.mds.xyz >/dev/null)
>
> real 0m0.092s
> user 0m0.081s
> sys 0m0.011s
> [root@mdskvm-p01 ~]# cat /etc/hosts
> 127.0.0.1 localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
> [root@mdskvm-p01 ~]#
>
> So with /etc/hosts file entries present makes little difference in small
> setup when governed by /etc/nsswitch.conf .
>
> Having entries in /etc/hosts, doesn't affect how gluster displays the
> entries when calling gluster volume status .
>
> Cheers,
> TK
>
> On 9/23/2019 11:36 AM, Joe Julian wrote:
> > Perhaps I misread the intent, I apologize if I did. I read "static
> > entries" as "ip addresses" which I've seen suggested (from my
> > perspective) far too often. /etc/hosts is a valid solution that can
> > still adapt if the network needs to evolve.
> >
> > On 9/23/19 8:29 AM, ROUVRAIS Cedric wrote:
> >> Hello,
> >>
> >> I gue________
Community Meeting Calendar:
APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314
NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users
