[Linux-cluster] nfs4 kerberos

Santeramo Luc l.santeramo at brgm.fr
Mon Apr 11 09:01:23 UTC 2011 

Ian,

First, thanks for all those information.
You have spent a lot of time to make it work on an active/passive cluster, but I was wondering if you tried to make it work on an active/active cluster ?
Do you think that using VMs is the only solution ?

Thanks,

--
Luc

De : linux-cluster-bounces at redhat.com [mailto:linux-cluster-bounces at redhat.com] De la part de Ian Hayes
Envoyé : vendredi 8 avril 2011 01:31
À : linux clustering
Objet : Re: [Linux-cluster] nfs4 kerberos

Hmm. I think you're overcomplicating it a bit. Instead of tweaking /etc/sysconfig/rpcbind, I did this:

Edit /etc/init.d/portmap
start() {
        hostname nfsserver.mydomain
        echo -n $"Starting $prog: "
        daemon portmap $PMAP_ARGS
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/portmap
        return $RETVAL
}

Start order is : IP, portmap, rpcgssd, rpcidmapd, nfs. My goal was to get the hostname changed to whateve the service principal in Kerberos was named to before the Kerberized daemons start up.

You can also play by manually changing the hostname on one of the nodes and firing up the service just to see that everything works.
On Thu, Apr 7, 2011 at 4:16 PM, Daniel R. Gore <danielgore at yaktech.com<mailto:danielgore at yaktech.com>> wrote:
Still could not get it to work.

I tried changing the host name that rpcbind binds to during start up
with arguments in the /etc/sysconfig/rpcbind file.

RPCBIND_ARGS="hostname fserv.mydomain"

rpcbind started correctly with not errors.  I then restarted the other
rpc daemons and nfs.

Got the same error: rpc.svcgssd indicates "wrong principal"

I know the ip is working correctly because I can ssh into using the file
server name (fserv.mydomain).

Looking for more ideas!

Thanks.

Dan

On Thu, 2011-04-07 at 14:58 -0400, danielgore at yaktech.com<mailto:danielgore at yaktech.com> wrote:
> Ian,
>
> You can find it here;
>
>
> http://sourceware.org/cluster/doc/nfscookbook.pdf
>
> > I had written up a rather large set of build documentation for many common
> > clustered services. NFS4, Samba, Postfix/Cyrus, Squid and some other
> > stuff.
> > But those docs stayed with my employer, so.... I don't think I've seen
> > this
> > cookbook, is it some wiki-type thing where new docs can be contributed?
> >
> > On Thu, Apr 7, 2011 at 5:08 AM, Daniel R. Gore
> > <danielgore at yaktech.com<mailto:danielgore at yaktech.com>>wrote:
> >
> >> A better solution for NFSv4 in a cluster is really required.
> >>
> >>
> >> A better cookbook with more real life likely scenarios for clustering
> >> solutions would be really helpful.  How many people actually setup the
> >> complex three layered solutions depicted, as compared to people setting
> >> up simple two/three node servers to for authorization, authentication,
> >> file and license serving.  It appears that the small business applicable
> >> system is completely ignored.
> >>
> >>
> >> On Thu, 2011-04-07 at 11:44 +0100, Colin Simpson wrote:
> >> > That's interesting about making the portmapper dependant on the IP,
> >> was
> >> > this for the same reason I'm seeing just now. I used the method from
> >> NFS
> >> > cookbook where I pseudo load balancing by distributing my NFS exports
> >> > across my nodes. Sadly the RHEL 6 portmapper replacement (rpcbind)
> >> > replies on the node IP and not the service IP, and this breaks NFSv3
> >> > mounts from RHEL5 clients with iptables stateful firewalls.
> >> >
> >> > I opened a bug on this one and have a call open with RH (via Dell) on
> >> > this:
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=689589
> >> >
> >> > But I too would like a good clean method of doing kerberized NFSv4 on
> >> a
> >> > RHEL6 cluster. I thought NFSv4 being so central to RHEL6 this would be
> >> > easy on a RHEL6 cluster (without using XEN)? Can the cookbook be
> >> > updated?
> >> >
> >> > Which brings up another point. The RHEL cluster documentation is good,
> >> > however it doesn't really help you implement a working cluster too
> >> > easily (beyond the apache example), it's a bit reference orientated. I
> >> > found myself googling around for examples of different RA types. Is
> >> > there a more hands on set of docs around (or book)? It could almost do
> >> > with a cookbook for every RA!
> >> >
> >> > Thanks
> >> >
> >> > Colin
> >> >
> >> > On Thu, 2011-04-07 at 02:52 +0100, Ian Hayes wrote:
> >> > > Shouldnt have to recompile rpc.gssd. On failover I migrated the ip
> >> > > address first, made portmapper a depend on the ip, rpc.gssd depend
> >> on
> >> > > portmap and nfsd depend on rpc. As for the hostname, I went with the
> >> > > inelegant solution of putting a 'hostname' command in the start
> >> > > functions of the portmapper script since that fires first in my
> >> > > config.
> >> > >
> >> > > > On Apr 6, 2011 6:06 PM, "Daniel R. Gore" <danielgore at yaktech.com<mailto:danielgore at yaktech.com>>
> >> > > > wrote:
> >> > > >
> >> > > > I also found this thread, after many searches.
> >> > > > http://linux-nfs.org/pipermail/nfsv4/2009-April/010583.html
> >> > > >
> >> > > > As I read through it, there appears to be a patch for rpc.gssd
> >> which
> >> > > > allows for the daemon to be started and associated with multiple
> >> > > > hosts.
> >> > > > I do not want to compile rpc.gssd and it appears the patch is from
> >> > > > over
> >> > > > two years ago.  I would hope that RHEL6 would have rpc.gssd
> >> patched
> >> > > > to
> >> > > > meet this requirement, but no documentation appear to exist for
> >> how
> >> > > > to
> >> > > > use it.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Wed, 2011-04-06 at 20:23 -0400, Daniel R. Gore wrote:
> >> > > > > Ian,
> >> > > > >
> >> > > > > Thanks for the info.
> >> > > > >
> >> > > > >...
> >> > > >
> >> > >
> >> > > plain text document attachment (ATT114553.txt)
> >> > > --
> >> > > Linux-cluster mailing list
> >> > > Linux-cluster at redhat.com<mailto:Linux-cluster at redhat.com>
> >> > > https://www.redhat.com/mailman/listinfo/linux-cluster
> >> >
> >> > This email and any files transmitted with it are confidential and are
> >> intended solely for the use of the individual or entity to whom they are
> >> addressed.  If you are not the original recipient or the person
> >> responsible
> >> for delivering the email to the intended recipient, be advised that you
> >> have
> >> received this email in error, and that any use, dissemination,
> >> forwarding,
> >> printing, or copying of this email is strictly prohibited. If you
> >> received
> >> this email in error, please immediately notify the sender and delete the
> >> original.
> >> >
> >> >
> >> >
> >> > --
> >> > Linux-cluster mailing list
> >> > Linux-cluster at redhat.com<mailto:Linux-cluster at redhat.com>
> >> > https://www.redhat.com/mailman/listinfo/linux-cluster
> >> >
> >>
> >>
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >> --
> >> Linux-cluster mailing list
> >> Linux-cluster at redhat.com<mailto:Linux-cluster at redhat.com>
> >> https://www.redhat.com/mailman/listinfo/linux-cluster
> >>
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> > --
> > Linux-cluster mailing list
> > Linux-cluster at redhat.com<mailto:Linux-cluster at redhat.com>
> > https://www.redhat.com/mailman/listinfo/linux-cluster
>
>
>



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
Linux-cluster mailing list
Linux-cluster at redhat.com<mailto:Linux-cluster at redhat.com>
https://www.redhat.com/mailman/listinfo/linux-cluster

**********************************************************************************************
Pensez a l'environnement avant d'imprimer ce message
Think Environment before printing
 
Le contenu de ce mel et de ses pieces jointes est destine a l'usage exclusif du (des) destinataire(s) designe
(s) comme tel(s). 
En cas de reception par erreur, le signaler a son expediteur et ne pas en divulguer le contenu. 
L'absence de virus a ete verifiee a l'emission, il convient neanmoins de s'assurer de l'absence de 
contamination a sa reception.
 
The contents of this email and any attachments are confidential. They are intended for the named recipient
(s) only. 
If you have received this email in error please notify the system manager or the sender immediately and do 
not disclose the contents to anyone or make copies. 
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20110411/58039d71/attachment.htm>

More information about the Linux-cluster mailing list