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

Re: "NFS Slave"??



> Cool.  Could I ask for some help then?  I think that I've "tried 
> everything" now, including purging and reinstalling NIS on head2, 
> rebooting head1 and head2, reading all of the NIS documentation very 
> carefully, etc., but it doesn't quite work.
> 
> I can use head2 as an NIS server just fine on the main network (e.g. 
> machine3 on the same network as head1 and head2 can use head2 as NIS 
> server), but not on the subnet hanging off head2.  The subnet off head2 
> (10.0.0.*) is different from that off head1 (10.1.1.* and 10.2.2.*), but 
> I have both in /etc/ypserv.securenets on head1, and all of the machines 
> in /etc/hosts of head1 and head2.

Hummm, this doesn't look quite right. I don't think it makes any sense
having the machines of the private network of head2 on either
ypserv.securenets or hosts of head1 and vice-versa. Each front-end should
list only its private net on hosts and ypserv.securenets, even if you are
using masquerading. The machines within either private network cannot
interchange packets directly with any machine outside and their addresses
are invisible for machines outside, they don't exist for them.

> I also have entries for all of the 
> machines in head1's ypserv.conf with lines like:
> 
> 10.0.0.2:*:none
> 
> But 10.0.0.2 and the others can't use head2 as a server, /etc/init.d/nis 
> start just prints "Starting NIS services: ypbind " then sits there and 
> does nothing.

Well, setting up a slave server is always a pain... Here we never changed
ypserv.conf, but of course you do need the appropriate network entries on
ypserv.securenets. You also need to set yp.conf on the nodes pointing to
the correct domain and server. If I remember well, the order of operations
is this (if you get the order wrong loop around until it works):

0) Make sure the master server is operating.
1) Go to the machine which is to be a slave server and change "false" to
   "slave" on /etc/init.d/nis; don't change its yp.conf yet; restart NIS.
2) Run /usr/lib/yp/ypinit -s <hostname-of-master> on the future slave
   server; note how this ypinit is not on the path; this should pull the
   maps from the master server.
3) Now you can change the yp.conf of the slave to bind it to itself if you
   wish (this is generally convenient).
4) Go to the master server, reinitialize NIS with /usr/lib/yp/ypinit -m
   and include the slave server on the list of servers.
5) Go to /var/yp and change the Makefile there to activate pushing the
   maps to the slave server each time NIS is updated; there is a line for
   this with "NOPUSH" or something in it.
6) Touch ypservers in /var/yp and run "make" there to see if it all goes
   through.

This _is_ a pain to get all up and working, I always mess up the order and
wander around a bit until I get it going, every time I try!... |:-)

> I see.  This kind of seems like cheating, but if it works, that's cool. :-)
> 
> I can see why old kernels might not have supported it: getting multiple 
> mount requests from the same physical machine would be kind of wierd.

Well, not really, it is like mounting several filesystems from a server.
You can even mount the same filesystem from a server in many different
mount points in a client with no problems, try it. The problem with old
kernels is that they didn't know hot to handle NFS's randomly assigned
network ports. The 2.4 series has a conntrack module that does that.

> Ohmygod, it works!  Look at that!  The clients hang for a little while 
> (~1-2 minutes) while mounting, but it's all there.  Most excellent.

Hummm, there is something wrong, it shouldn't take that long...

> One question: what does "ftp" have to do with NFS?  I don't need the 
> machines to be able to use ftp, NFS is the only service we need from 
> outside the subnet.  Or does ftp mean nfs in some way?

No, that was just an aside remark. Masquerading works OK without further
ado for most protocols, but you get in trouble if a protocol is such that
the outgoing connection (which is easy to masquerade) causes a related
incomming connection to pop up, such as the data connection of ftp. In
this case the kernel must know about it in order to handle it, hence the
special module. This is true for ftp, some gaming connections, etc. FTP
has nothing to do with NFS and you may not need it indeed.

> Thank you very much!  Now if I can just get NIS to work...  How about 
> via masquerading?  Nope, that doesn't work.  Oh well.

Yes it does! Except for distributing the load on several slave servers,
this might be the best way to do it. Of course, the nodes inside your
private nets must have Internet domain service available and must have
their yp.conf files pointing to the server outside. DNS also works via
masquerading. Pretty much _everything_ works.
							Cheers,

----------------------------------------------------------------
        Jorge L. deLyra,  Associate Professor of Physics
            The University of Sao Paulo,  IFUSP-DFMA
       For more information: finger delyra@latt.if.usp.br
----------------------------------------------------------------


-- 
To UNSUBSCRIBE, email to debian-beowulf-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: