Bug 253100

The error indicate that the servers can't find the domain master browser not
that they are one.
I need some more info to understand if this is a configuration problem or a bug.

Just to be sure can you do the following:
1)
- Check that you can actually retrieve the DMB from the WINS server
  nmblookup -R -U<WINSserver> 'ESG#1B'

2)
- add local master = yes to all servers that need to be local master
- add domain master = no and preferred master = yes to all servers except the
domain master
- raise the log level of nmbd of one of the servers that fail and attach the
nmbd.log

1) Output from both the WINS/DMB server and client were the same:

name_query failed to find name ESG#1b

2) 'nmbd.log' file is attached.

Created attachment 161705 [details]
NMBD Log File

(In reply to comment #2)
> 1) Output from both the WINS/DMB server and client were the same:
> 
> name_query failed to find name ESG#1b

If this is the case then there is a problem with the wins server.
Can you provide the WINS server nmbd.log file ?

Created attachment 161714 [details]
'NMBD' log file for WINS server

I've attached the 'nmbd.log' file for the WINS server.

This log shows that the main server becomes a domain master browser.
Can you run the above nmblookup command on the WINS server directing it to
itself and verify if it resolves?

I ran it 3 different ways and it all produces the same resutls. Please note the
name of the DMB/WINS server is 'esg.esgrp.net' and the workgroup name is 'ESG'.

[root@esg ~]# nmblookup -R -U esg 'ESG#1B'
added interface ip=10.10.10.200 bcast=10.10.10.255 nmask=255.255.255.0
Socket opened.
querying ESG on 10.10.10.200
Negative name query response, rcode 0x03: The name requested does not exist.
name_query failed to find name ESG#1b

[root@esg ~]# nmblookup -R -U esg.esgrp.net 'ESG#1B'
added interface ip=10.10.10.200 bcast=10.10.10.255 nmask=255.255.255.0
Socket opened.
querying ESG on 10.10.10.200
Negative name query response, rcode 0x03: The name requested does not exist.
name_query failed to find name ESG#1b

[root@esg ~]# nmblookup -R -U localhost 'ESG#1B'
added interface ip=10.10.10.200 bcast=10.10.10.255 nmask=255.255.255.0
Socket opened.
querying ESG on 127.0.0.1
name_query failed to find name ESG#1b

Samba is allowed through the firewall, but I tried the command with an without
'iptables' running and it made no difference. I also disabled selinux's controls
of Samba by setting the following booleans:

smbd_disable_trans --> on
nmbd_disable_trans --> on

The thing that is odd is it actually is the master brower:

[root@esg ~]# smbclient -NL esg
Domain=[ESG] OS=[Unix] Server=[Samba 3.0.23c-2.el5.2.0.2]

        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (esg)
Domain=[ESG] OS=[Unix] Server=[Samba 3.0.23c-2.el5.2.0.2]

        Server               Comment
        ---------            -------
        ACCT-01              
        AMPERE               ampere
        ARCHIVE              archive
        BACKUP               backup
        ESG                  esg
        GAUSS                gauss
        ICEHAWK-CSK          
        JNU                  jnu
        MAXWELL              maxwell
        RDM                  rdm
        SCADA                scada
        SCANNER              
        SOS                  sos
        VCR                  vcr
        VOLT                 volt

        Workgroup            Master
        ---------            -------
        ESG                  ESG

If you run that same command without the #1B is does respond with a name lookup.

[root@esg ~]# nmblookup -R -U esg 'ESG'
added interface ip=10.10.10.200 bcast=10.10.10.255 nmask=255.255.255.0
Socket opened.
querying ESG on 10.10.10.200
Got a positive name query response from 10.10.10.200 ( 255.255.255.255 )
255.255.255.255 ESG<00>

Yes there seem to be a problem where the WINS server actually wins the DMB
elections but somehow forgets to set that into the WINS database itself, I need
to dig in the code to find out what's going on.

Meanwhile we have new packages in the beta channel you may want to try out, they
may fix your problem. If you do, can you please report abck if that fixes your
problem?

I'm not familiar with the beta channel, can you give me a link?

The searching I've done on Google groups would lead me to believe this may have
been is v3.0.24 but I didn't see anything technically significant as to what the
issue actually was.

(In reply to comment #12)
> I'm not familiar with the beta channel, can you give me a link?
> 
> The searching I've done on Google groups would lead me to believe this may have
> been fixed in v3.0.24 but I didn't see anything technically significant as to     
> what the issue actually was.

I meant "been fixed in v3.0.24"

(In reply to comment #12)
> I'm not familiar with the beta channel, can you give me a link?

it's an rhn channel, which you can subscribe to using the 'alter channel
subscriptions' link from the system's page on rhn

> The searching I've done on Google groups would lead me to believe this may have
> been is v3.0.24 but I didn't see anything technically significant as to what the
> issue actually was.

In the beta we have 3.0.25 that's why I am asking if you can try that out.

I tried the beta version (samba-3.0.25b-0.el5.4) and the results are the same.
The servers still do the exact same thing.

Please can you provide me the nmbd.log file of the DMB/WINS server at log level
=10 ? Please do a restart and let it log at that level for 5 minutes
Also set max log size = 0 during this tjme so that logs don't wrap.

(log level 10 can slow doiwn the server considerably, if it is a production
system better to do these test off peek hours).

Created attachment 161899 [details]
'nmbd.log' file at log level = 10

I've attached about 5 minutes worth of the 'nmbd.log' file with the "log level =
10" parameter set for the WINS server.

Thanks,
I am trying to reproduce it.

Tim,
I have reproduced the problem.
It is a configuration issue.
"socket address" is the culprit.
If you use it nmbd will not listen on 127.0.0.1 and it will not be able to send
to itself the WINS registration packets.

The socket address option is meant to be used only in very specialized
environment where you have multiple smbd running on a multi-homed system.
In those cases usually nmbd is given a different configuration.

Can you remove socket address and report if this fixes your problem?

Removing the "socket address" from the configurations on the RHEL 5 servers does
appear to have corrected the issue. Is this a bug or is just a misconfiguration?
This was not a problem in RHEL 4 (samba-3.0.10-1.4E.12.2). In any event, thank
you very much for your help.

I'll tag it as a misconfiguration, normally to restrict the interfaces you
listen to you can use: "interfaces" and "bind interfaces only" and the
documentation warns you to always include "lo" or localhost or bad things happen.
"socket address" is a very obscure and stricter thing that allows you to
restrict smbd to a single specific address. But this is generally unwanted and
should be used with care and in environments where a multihomed system is used
to run smbd with "different" configurations on different ip address.

Thanks for bringing this up, it will help others if they spot the same problem.