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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
