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

Re: [Linux-cluster] nfs4 kerberos



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 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
>         
> 
> 
> -- 
> 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.


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