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. <div class="gmail_quote">On Thu, Apr 7, 2011 at 4:16 PM, Daniel R. Gore <<a href="mailto:danielgore@yaktech.com">danielgore@yaktech.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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 <div><div></div><div class="h5"> On Thu, 2011-04-07 at 14:58 -0400, <a href="mailto:danielgore@yaktech.com">danielgore@yaktech.com</a> wrote: > Ian, > > You can find it here; > > > <a href="http://sourceware.org/cluster/doc/nfscookbook.pdf" target="_blank">http://sourceware.org/cluster/doc/nfscookbook.pdf</a> > > > 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 > > <<a href="mailto:danielgore@yaktech.com">danielgore@yaktech.com</a>>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: > >> > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=689589" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=689589</a> > >> > > >> > 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" <<a href="mailto:danielgore@yaktech.com">danielgore@yaktech.com</a>> > >> > > > wrote: > >> > > > > >> > > > I also found this thread, after many searches. > >> > > > <a href="http://linux-nfs.org/pipermail/nfsv4/2009-April/010583.html" target="_blank">http://linux-nfs.org/pipermail/nfsv4/2009-April/010583.html</a> > >> > > > > >> > > > 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 > >> > > <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> > >> > > <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> > >> > > >> > 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 > >> > <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> > >> > <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> > >> > > >> > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> -- > >> Linux-cluster mailing list > >> <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> > >> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> > >> > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > -- > > Linux-cluster mailing list > > <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> > > <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Linux-cluster mailing list <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> </div></div></blockquote></div>