Chromium does not work with .local mdns/avahi name resolution


#1

most likely caused by

the current chromium snap does not allow to open any .local urls

with the removal of the chromium deb and the switch to a snap-only deployment for this browser this is a pretty solid regression that should be addressed …


#2

Thanks for the report @ogra. I’ve filed bug #1838038 to track the issue.


#3

One way to get things working would be to install unscd or nscd, similar to what’s described here:

In that case, it was to provide a snap access to non-standard user/group NSS plugins, but the same should apply for host name lookup via NSS.


#4

well, since @oSoMoN can not reproduce the issue on his install (according to the bug discussion) i wonder if he has that daemon installed …

though if this is really the case, nscd should be a dependency of snapd or some such, but i think it was demoted to universe for a reason :slight_smile:
(probably @jdstrand has an opinion here )


#5

ok, i can confirm installing nscd and restarting the browser makes it work, but given that avahi/mdns support is a default in ubuntu since over 10 years i think it should work OOTB as it did before and not regress when we switch users from the deb to the snap, so there is still some action needed for a proper solution (beyond the fact that it will not work either on non-ubuntu distros anymore) and if only by forcing nscd into the default install.


#6

Historically nscd has had a reputation for being a bit unstable. That’s probably at least partly down to type of workloads requiring nscd including far less robust NSS plugins. When a bug in a plugin has the ability to take out name resolution in every process on the system rather than just one, it amplifies the problem.

uncsd tries to avoid this by treating NSS plugins as untrusted and running them in their own process. I’m not sure how that affects performance.

If we want to pursure this as a general solution, then perhaps snap-confine should map in an nscd socket into the sandbox that talks to a reliable nscd implementation on the host side. That would at least limit any downsides of using nscd to snap confined applications.


#7

i personally think the cleaner way would be to ship
/lib/<arch triplet>/libnss_mdns4_minimal.so.2 inside core/core18 and fix the missing bit in nsswitch.conf of the core/core18 snaps:

$ grep hosts /etc/nsswitch.conf 
hosts:          files mdns4_minimal [NOTFOUND=return] dns
$ grep hosts /snap/core/current/etc/nsswitch.conf 
hosts:          files dns myhostname

that way we wouldnt rely on the host having mdns (or any workarounds like nscd/unscd) available


#8

The documentation for nss-mdns says the following:

`nss-mdns` tries to contact a running
[avahi-daemon](http://avahi.org/) for resolving host names and
addresses and making use of its superior record cacheing. If
Avahi is not available at lookup time, the lookups will fail.

So it isn’t clear that adding nss-mdns to nsswitch.conf in the sandbox would be sufficient without also plugging avahi-observe (or adjusting the network plug to grant access to /var/run/avahi-daemon/socket).


#9

and isnt that good ? it gives us/the admin full control and allows to switch it off if desired :wink:


#10

Well, there’s no way for a sysadmin to add an avahi-observe plug to a snap that doesn’t have it, so you’re still at the mercy of the packager.

If mDNS name resolution is important, then surely you’d want it working for every snap that performs host name lookups, which is why I suggested updating network.


#11

well, i think this is jamie territory anyway …
i’d personally leave it to the packager/admin for finer grained control … but i guess either is fine in the end.

what i find inportant is that it also works on core where you do not have the opportunity to easily install nscd or unscd outside of the snap (indeed we chould ship either in the core snap but that means moving it to main in the end).