Hi Nico, Thanks for your reply.
However, my configuration is entirely based on the recommendations from samba.org for setup of clustered file sharing using samba, ctdb, Kerberos, wins (& ocfs2). http://ctdb.samba.org/configuring.html & http://wiki.samba.org/index.php/CTDB_Setup : Quote: "Name resolution You need to setup some method for your Windows and NFS clients to find the nodes of the cluster, and automatically balance the load between the nodes. We recommend that you use public ip addresses using CTDB_PUBLIC_INTERFACE/CTDB_PUBLIC_ADDRESSES and that you setup a round-robin DNS entry for your cluster, listing all the public IP addresses that CTDB will be managing as a single DNS A record." So as far as I can tell this is how it is supposed to work. Perhaps it is an issue with Kerberos? Cheers -----Original Message----- From: samba-boun...@lists.samba.org [mailto:samba-boun...@lists.samba.org] On Behalf Of Nico Kadel-Garcia Sent: Friday, 20 January 2012 11:40 PM To: Peter Tan Cc: samba@lists.samba.org Subject: Re: [Samba] Problem Accessing Samba share from Windows workstation via DNS Round Robin On Fri, Jan 20, 2012 at 1:38 AM, Peter Tan <p...@ipswich.qld.gov.au> wrote: > I have set up a 2 node linux cluster and wish to share a ocfs2 mount on san storage. I have configured ctdb, samba and Kerberos and am able to map the share on my windows workstation when I hit the ip of each of the two nodes. > > I am able to mount this share via nfs on other linux servers ok. > > However it does not appear to be authenticating when I try to map to the DNS hostname that has been set up to round robins across the two ip's - I keep getting prompted for a login and password and I get the following in /var/log/messages: "krb5_rd_req failed (Key table entry not found)" Nor should it. They're not the same machine, and Kerberos tickets for one are not going to be valid on the other. and DNS "round robin" is always a crap shoot due to client DNS caching and ordering of returned entries, over which you have *no* control from the server side. NFS is an.... *entirely* different game. Once the mount is created, it's tied to the IP address, not the DNS entries, and remains that way unless detached and a new mount created. Autofs supports this sort of thing, but most NFS setups don't rely on Kerberos tickets or, in fact, any reliable authentication, especially the much simpler NFSv3 setups. Simple setups use the uid's and gid's reported by the client and assume that is enough. (It's really not for secure environments, which is why Kerberos works so hard to make sure you really are who you say you are, on both ends and is incorporated into NFSv4 and integrated automatically most modern CIFS setups.) > Node 1: 10.101.4.16 > Node 2: 10.101.4.17 > DNS A Name: clusterpub 10.101.4.16 > DNS A Name: clusterpub 10.101.4.17 This is not "round robin" unless your DNS server is prepared to re-arrange the response order for lookups of "clusterpub", and even then, clients can mess it up. It's duplicate A records: it's important to keep this straight. > I have set the "netbios name = clusterpub" in smb.conf on both nodes But they're not the same host. Presenting them both as the same host is begging for confusion. > Interestingly, I am able to successfully connect to the "clusterpub" share from one of the nodes via smbclient. > > # smbclient //clusterpub/archive -U <user> > Enter <user> password: > Domain=[COUNCIL] OS=[Unix] Server=[Samba 3.5.4-0.83.el5] > smb: \> dir > . D 0 Fri Jan 20 14:28:01 2012 > .. D 0 Wed Jan 18 13:56:46 2012 > hello-from-samba 0 Fri Jan 20 14:28:01 2012 > > 64000 blocks of size 16777216. 63805 blocks available > smb: \> > > What am I missing? > > Peter Tan That "round robin DNS" is not your friend, and never will be. Also, smbclient is not the same as mounting a file system. You might consider giving different netbios names: duplicate A records are most usefully published *as well* as distinct hostnames, so you can gracefully select one or the other host, and reverse DNS compatble specific hostname to differentiate reverse DNS lookups between the two hosts. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba