The Server Program ypserv
ypserv!setup
NIS!ypserv setupThis document only describes how to set up the "ypserv" NIS server.If you run your server as master, determine what files you require to be
available via NIS and then add or remove the appropriate
entries to the "all" rule in /var/yp/Makefile.
You always should look at the Makefile and edit the Options at the
beginning of the file.Now edit /var/yp/securenets and
/etc/rc.conf.
For more information, read the ypserv(8) manual page and /etc/rc.conf comments.Make sure the portmapper (portmap(8)) is running, and start the
server ypserv. The command
% rpcinfo -u localhost ypserv
should output something like
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting
The "version 1" line could be missing, depending on the ypserv version and
configuration you are using. It is only necessary if you have old
SunOS 4.x clients.Now generate the NIS (YP) database. On the master, run
% /usr/sbin/ypinit -m
On a slave make sure that ypwhich -m works. This means,
that your slave
must be configured as NIS client before you could run
% /usr/sbin/ypinit -s masterhost
to install the host as NIS slave.That's it, your server is up and running.If you have bigger problems, you could start ypserv and
ypbind in debug
mode on different xterms. The debug output should show you what goes
wrong.If you need to update a map, run make in the
/var/yp
directory on the NIS master. This will update a map if the source file
is newer, and push the files to the slave servers. Please don't use
ypinit for updating a map.You might want to edit the system crontab (/etc/crontab) *on the slave* server and add the
following lines:
20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid
55 19 * * * root /usr/libexec/ypxfr hosts.ypname
This will ensure that most NIS maps are kept up-to-date, even if an
update is missed because the slave was down at the time the update was
done on the master.You can add a slave at every time later. At first, make sure that
the new slave server has permissions to contact the NIS master. Then run
% /usr/sbin/ypinit -s masterhost
on the new slave. On the master server, add the new slave server name
to /var/yp/ypservers and run
make in /var/yp
to update the map.If you want to restrict access for users to your NIS server, you'll have
to setup the NIS server as a client as well by running ypbind and adding the
plus-entries to /etc/master.passwd _halfway_
the password file. The library
functions will ignore all normal entries after the first NIS entry, and
will get the rest of the info through NIS. This way the NIS access rules
are maintained. An example:
root:x:0:0:root:/root:/bin/bash
daemon:*:1:1:daemon:/usr/sbin:
bin:*:2:2:bin:/bin:
sys:*:3:3:sys:/dev:
sync:*:4:100:sync:/bin:/bin/sync
games:*:5:100:games:/usr/games:
man:*:6:100:man:/var/catman:
lp:*:7:7:lp:/var/spool/lpd:
mail:*:8:8:mail:/var/spool/mail:
news:*:9:9:news:/var/spool/news:
uucp:*:10:50:uucp:/var/spool/uucp:
nobody:*:65534:65534:noone at all,,,,:/dev/null:
+dennis:::::::::
+*:::::::::/bin/false
[ All normal users AFTER this line! ]
tester:*:299:10:Just a test account:/tmp:
obrien:1765:01:10::0:0:David O'Brien:/home/obrien:/bin/sh
Thus the user "tester" will exist, but have a shell of /bin/false. obrien
will have normal access.Alternatively, you could edit the /var/yp/Makefile file
and set NIS to use
another source password file. On large systems the NIS password and group
files are sometimes stored in /etc/yp/. If you do this the normal
tools to administrate the password file such as passwd, chfn,
adduser will not work anymore and you need special homemade tools
for this.However, yppasswd, ypchsh and ypchfn will
work of course.