[Pkg-samba-maint] Bug#591752: Bug#591752: samba-common: please change the name resolv order

[Fabian Greffrath]

Dear samba-developers,

on request of Christian PERRIER of Debian's pkg-samba-maint team, I 
contact you about an issue that I initially filed to the Debian Bug 
Tracking System [1].

Please find a transcript of my original request below:

---8<---

Dear samba-maintainers,

I'd like to give some background information before I explain my 
actual request: My wife has a computer running Windows XP and mine is 
running Debian, obviously (but it is not the computer I am writing 
this actual bug report from). Both computers are connected via LAN to 
a router which in turn acts as DHCP server and internet gateway. Both 
computers receive dynamic IP addresses via the router's DHCP service.

For quite some time now, nautilus on my computer is not able to show 
shares on my wife's coputer anymore. It complains with the "Failed to 
retrieve share list from server" gvfs error message. The error only 
occurs if I try to connect to the computer via its name, if I try to 
explicitely connect to its IP address, it works.

The reason for this behaviour is quite simple, but hard to find: Samba 
on my computer uses the standard name resolv order, which is: "lmhosts 
host wins bcast". Since I do not have a lmhosts file, it tries the 
next best method which is "hosts". This in turn is configured via 
/etc/nsswitch.conf to first look into the /etc/hosts file (where it 
does not find my wife's computer, since it is configured via DHCP and 
thus has a dynamic IP address) and then do a DNS query. Our router 
forwards this DNS query to our ISP's DNS server, which - now comes the 
important part - instead of returning a failure notice, because it 
does not know how to resolv my wife's computer's name, leads us to 
some dubious webpage which contains advertisments and "suggestions" to 
use some notorious internet search engines on the requested name. Of 
course, when our ISP's DNS server resolvs this request and returns the 
IP address of this dubious  webpage, nautilus will not find any shares 
on this computer. Since for samba, the "host" method obviously 
succeeded, it does not try further attempts with the "wins" or "bcast" 
methods and my request for the computer's share list is doomed to fail.

Please don't get me wrong, I know this is absolutely not samba's but 
our ISP's fault. But by internet research I found quite a lot of 
people with similar problems and would thus like to propose a general 
resolution for this problem. This solution would be to put "bcast" 
before "host"  in the name resolv order list and only have the latter 
as a fallback, i.e. "lmhost bcast host wins".

I believe this is safe, because "lmhost" should always be the first 
method. "bcast" is error prone, because it depends on the target host 
being on a locally connected subnet. On the other hand, if the target 
host is *not* in the locally connected subnet, AFAICT it would need an 
entry in one of the lmhost or host files anyway. I am not quite sure 
about "wins", though, i.e. if it should be queried before or after 
"host". But, to sum up, "bcast" should come before "host".

I do not know upstream's opinion on this, i.e. if this would be 
considered a Debian-specific deviation, but at least in the 
smb.conf(5) manpage I found my proposed name resolv order among the 
examples. However, please consider changing this setting for the sake 
of users with heterogenous networks and stupid ISPs. ;)

Cheers,
  - Fabian

--->8---

PS: Please keep me in the CC in your replies.

[1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591752>

Am 05.08.2010 13:23, schrieb Christian PERRIER:
> I'm afraid we won't. About two years ago, we adopted a policy where we
> avoid deviations form upstream default as much as possible. That
> helped a lot in having a better interaction with upstream (where
> nobody can really tell 'eh, these folks at Debian changed default
> settings we madethis way because we have good reasons for'....
>
> In that specific case of network resolution and browsing, I think that
> there are not valid reasons to change the default even if that change
> is needeed for your specific configuration.
>
> If you think that the default should be changed, I suggest talking to
> upstream.