[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 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 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 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 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 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 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 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 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 redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]