Ian,
Thanks for the feedback. RHEL 6 replaced portmap with rpcbind, but you
solution should work the same. I will give it a try tomorrow and let
you know.
Thanks for the starting order also. I was wondering if I got that
correct.
Dan
On Thu, 2011-04-07 at 16:30 -0700, Ian Hayes wrote:
> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx>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@xxxxxxxxxxx>
> > >> > > > 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@xxxxxxxxxx
> > >> > > 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@xxxxxxxxxx
> > >> > 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@xxxxxxxxxx
> > >> 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@xxxxxxxxxx
> > > 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@xxxxxxxxxx
> 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@xxxxxxxxxx
> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
