I have samba configured to resolve dhcp addresses of windows machines by using WINS. This is done by adding a WINS server to smb.conf and adding 'wins' to the end of the hosts line in nsswitch.conf. This has worked fine since samba-2.x up until 3.0.6-r3. However, I upgraded to 3.0.6-r4 and it stopped working. All WINS hosts are unknown. Switching back to r3 makes it work. I dont' even have to restart samba. If the r3 files are there...good. r4 files... bad. Reproducible: Always Steps to Reproduce: 1.configure samba to resolve dynamic address hostnames using WINS 2. emerge samba-3.0.6-r4ping <windows machine with dhcp address 3. ping <windows machine with dhcp address> Actual Results: host unknown Expected Results: the ping should resolve the hostname to the correct dhcp address by asking the WINS server. This worked fine in 3.0.6-r3, but is broken in r4.
I'm a bit puzzled. if you do a 'diff -Nu usr/portage/net-fs/samba/samba-3.0.6-r{3,4}*', you'll see that, if you don't use amd64 systems, the changes are only cosmetics. Are you sure the only change in your network is the samba version update?
I made packages of samba-3.0.6-r3, 3.0.6-r4 and just this morning 3.0.7 With nothing else happening on the system I did an emerge --usepkg =3.0.6-r3 ping config70 (a windows machine that gets its address from dhcp. This happens with all suck machines.) ping works as expected, hostname resolved. emerge --usepkg =3.0.6-r4 ping config70 ping: unknown host config70 emerge --usepkg =3.0.7 ping config70 ping: unknown host config70 emerge --usepkg =3.0.6-r3 ping config70 ping works as expected again. Note that I have not at any point restarted he samba services during this process. I also tried it with restarting the services just to be sure, but it seems to have no effect one way or the other. A concurr, that this is really strange.
nice done: this is a significative test. if you don't restart daemons, the cause can only be shared by libraries and runtime configuration. -- Libs: since you're using a binary package for 3.0.6-r3, could you do a backup of this and make a new 'emerge =samba-3.0.6-r3'? This way, 3.0.6-r3 will be compiled against your current system libs version. --Conf: If some tweaking in nsswitch.conf, smb.conf or resolv.conf don't resolve this issue, and you already set your conf as for http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html#id2528560, I'd suggest you to contact samba support upstream.
I wasn't using binary packages. I used quickpkg and emerge --buildpkgonly to make packages of these versions compiled locally so that I could swap them out quickly during testing. I was thinking about contacting samba support, but since the problem originally occurred between gentoo r3 and r4 I figured I'd try here first. However, now that I've seen it from 3.0.6 (good) and 3.0.7 (bad) I'll try opening a bug with them. I'll check out that howto and see how it goes. Thanks for the help.
One last thought: you're not using selinux nor amd64, I presume. If so, it could be something regarding profiles. If you edit samba-3.0.7, and comment out the 'append-ldflags -Wl,-z,now -L/usr/$(get_libdir)' (line 140 of /usr/portage/net-fs/samba/samba-3.0.7.ebuild), can you give it a try? Another question: stack-protector in CFLAGS?
I noticed the same error today. No selinux, amd64, stack-protector or anything special on my system. However, commenting out the append-ldflags-line in the ebuild did solve it for me. Samba-3.0.7 completed compiling a few minutes ago and I can ping other windows-hosts again (without restarting samba).
Yes, commenting out that line did fix the problem. Thanks for the help
*** Bug 64217 has been marked as a duplicate of this bug. ***
Can you give a try on samba-3.0.7-r1? You should have no problems, while retaining libs preload advantages
wins hostname resolution works in samba-3.0.7-r1
thanks: closing now and having a beer! :-)
