Let's try to make some sense into this...
On 11/10/2017 04:25 PM, Robert Kudyba wrote:
/etc/nsswitch.conf on working system: [...] #hosts: db files nisplus nis dns hosts: files dns nisplus nis mdns4_minimal myhostname mymachines
According to https://www.freedesktop.org/software/systemd/man/nss-myhostname.html, nss-myhostname should be used as a fallback in case DNS or /etc/hosts do not provide an address for the local hostname. "[...] is resolved to all locally configured IP addresses ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local loopback) and the IPv6 address ::1 (which is the local host)."
nss-mymachines seems to be used for containers - I guess this isn't relevant, though.
/etc/nsswitch.conf on non-working system: #hosts: db files nisplus nis dns hosts: files nis mdns4_minimal [NOTFOUND=return] dns myhostname
That differs a lot from the other definition above. Essentially, it searches the local files (/etc/hosts), NIS and then via MDNS. Assuming that the MDNS server was reachable, but no entry found, the search is aborted. If the MDNS server is not available, search will continue with DNS/by asking the nameserver and if that was unsuccessful, too, by using the myhostname module. This is very different from the other machine, that doesn't stop the search in such a case, but continues with the myhostname module. Also, the nameserver will never be asked if the MDNS server was available but the specific entry not found.
/etc/hosts on working system: 127.0.0.1 localhost.localdomain localhost.localdomain localhost4 localhost4.localdomain4 localhost erdos ::1 localhost.localdomain localhost.localdomain localhost6 localhost6.localdomain6 localhost erdos
These entries include the short host name (erdos) directly. So the "files" module will already able to find an entry for the short name (but not for the FQDN.)
Minor nitpick: localhost.localdomain seems to have been added twice, probably by mistake. The first entry should be "localhost" only.
150.108.64.52 dsm.dsm.fordham.edu dsm /etc/hosts on non-working system: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
150.108.64.57 sobolev.dsm.fordham.edu sobolev
Okay, interesting: here, the short name will not resolve to 127.0.0.1, but rather a public IPv4 address. Also, the FQDN will equally resolve via the hosts file only. Maybe that's a problem for local connections?
I don't see where this could be happening but there are some differences from the 2 files you asked about.
Well, maybe something expects a local address. In case of the not working machine, the hostname resolves to a public IPv4 address instead.
Note that the ipv6 option is commented OUT on the non-working system but could that be a reason?
I don't think missing IPv6 addresses are problematic in this case (though it sounds odd to deactivate this. I'd expect problems in general due to this.)
On the respective machines, let's see what the system resolver gives us:
getent adns $(hostname -s) getent adns $(hostname -f)
HA! I was finally able to reproduce your issue locally!
In a Fedora 26 VM, I set the hostname as follows:
hostnamectl set-hostname fedora.local.home.ionic.de
Then, I edited /etc/hosts and added:
192.168.122.128 fedora fedora.local.home.ionic.de
This leads to exactly the problem you described.
If I change "fedora" to resolve to 127.0.0.1 instead (with fedora.local.home.ionic.de staying on 192.168.122.128), I can connect via X2Go again.
Can you confirm this?
Mihai