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

Re: "NFS Slave"??

Jorge L. deLyra wrote:

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 see. The reason I did this was that inspection of the files in /var/yp/mydomain.edu on head2 showed the hosts and securenets of head1. Well, when I get it working, I'll try removing them from head1's list and see what happens.

I also have entries for all of the machines in head1's ypserv.conf with lines like:*:none

But 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

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!... |:-)

Hmm, I just re-did all of this, and make in /var/yp on head1 works fine, but the clients still don't ypbind properly...

Is there a yp.log file somewhere? I can't find it, and nothing shows up in messages, dmesg, or daemon.log -- oh wait, syslog has an entry for a refused connection, but that was when the slave tried to connect to itself but wasn't in its own ypserv.securenets (that was an easy one). I can't find anything for the clients, nor does anything show up when machines on the main network use head2 to start nis -- which works just fine.

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.

I see, makes sense.

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

Yes, I think I know what the problem was. A mistake on my part in using the diskless package. This may also be what's causing the nis problems, but without physical access to the machines just now, I can't test this.

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.

Okay, I can't get it to work, but as I said, I'll try fixing the other problem first.

Thank you again,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe! <http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

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

Reply to: