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