|
|
This article is available in: English Deutsch Francais Nederlands Portugues Turkce |
by Frédéric Raynal <pappy(at)users.sourceforge.net> About the author: Frédéric Raynal is currently preparing his final theses at the INRIA in computer science. I often listen to the latest album of "16 Horse Power" (very fine, but also powerful) and "The for carnation", a little cold but still very good. Translated to English by: Guido Socher (homepage) Lorne Bailey [proof read] <sherm_pbody(at)yahoo.com> Content: |
Abstract:
In this article we present a step by step installation of a NIS server. We will take a look at the required software, configuration files and the creation of a database.
In this article we will now see how to configure the server side and we will give some tips on how to use NIS.
In this article we talk about this more recent version of ypserv. We recommend a version later than 1.3.2 since we want to support shadow passwords. In other words, we are really talking about NYS and not the "traditional NIS", although we will use the word NIS throughout the article.
First we will explain the steps that are necessary to install the server. In this article we are working on a host called "charly". The NIS domain is "bosley" and the slave servers are "iron1", "iron2" and "iron3".
Next, you need to decide the name of the NIS domain. This is not a domain from DNS but a name for the YP region. For security reasons, this name should be different from the name of the NIS server.
The domain is set with the command domainname :-) In our case this is:
root@charly >> /bin/domainname bosleyThis command sets the NIS domain name only in RAM. To make it permanent you need to add the following line to /etc/sysconfig/network:
NISDOMAIN=bosleyThis will then set the NIS domain name automatically at the next reboot.
Before we can start the ypserv daemon we need to configure it by editing the file /etc/ypserv.conf. This is a ASCII file with the following syntax:
option: [yes|no]Possible options are dns, the server will ask DNS to find the clients which are not in the hosts-maps, sunos_kludge, obsolete and xfr_check_port to use a port below 1024 for the server (default is yes).
host:map:security:mangle[:field]These rules decide who may see what information.
Now we can start the server:
root@charly >> /etc/rc.d/init.d/ypserv startTo run the server automatically at startup you need to edit the rc.d files or under Redhat you can run the command :
root@charly >> /sbin/chkconfig --level 345 ypserv onTo verify that everything is running use:
root@charly >> /usr/sbin/rpcinfo -u localhost ypservBefore going into details we should remember what we learned in the first article. There are 2 types of servers: master and slave. The slave servers only have a copy of the master server's database. These servers supplement the master server when it is taking too long to answer the client's requests or when the master server goes down. The database needs to be maintained on the master only. It is copied over to the clients.
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting
Everything is now ready ... except for the database. We have to generate it first. Generate means, use a Makefile ;-] The Makefile is pre-prepared so we just need to change a few lines. The Makefile is in /var/yp and is clearly commented. The most important line is the one where the maps are defined. On host charly that is:
all: passwd group hosts rpc services netid protocols mail shadowIn addition to the default you should add shadow password handling. To do that you need to add "passwd" and "shadow" to the list of files and set the value of the variable MERGE_PASSWD to true. MERGE_PASSWD determines if the files /etc/passwd and /etc/shadow are merged.# netgrp publickey
# networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
A final detail before we start the server: Access writes. There are two methods to control the access. Either ypserv's own methods or via tcp_wrapper. We will talk about ypserv's own security methods.
If you only have binaries of ypserv then the option -v prints out the configuration options that ypserv was compiled with. We need option "securenets" to use ypserv's own access control.
root@charly >> /usr/sbin/ypserv -vThe file /var/yp/securenets contains pairs of netmask/network numbers which we can use to control server access. By default this is:
ypserv - NYS YP Server version 1.3.9 (with securenets)
0.0.0.0 0.0.0.0This allows access for everybody in the world. We must change that. To allow connections from any host within the 131.234.223.0 network you would write:
255.255.255.0 131.234.223.0Please note that you can only have IP addresses in this file. It is not possible to use host names.
Now we can create the NIS-Database using the command ypinit. By default (defined in the Makefile) it will read the files from /etc and write to /var/yp. The files that will go into our database are /etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/netgroup, /etc/rpc.
The option -m allows you to initialize the Server with raw data (-m for master), the option -s copies the master database to a slave (-s like slave).
On Charly we initialize our database as follows:
root@charly >> /usr/lib/yp/ypinit -mEt voila, the database is ready :). On each of the slave servers the command ypinit needs now to be executed:At this point, we have to construct a list of the hosts which will run NIS
servers. localhost is in the list of NIS server hosts. Please continue to add
the names for the other hosts, one per line. When you are done with the
list, type a <control D>.
next host to add: localhost
next host to add: iron1
next host to add: iron2
next host to add: iron3
next host to add:
The current list of NIS servers looks like this:localhost
iron1
iron2
iron3Is this correct? [y/n: y] y
We need some minutes to build the databases...
Building /var/yp/bosley/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/bosley'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
Updating shadow.byname...
# shadow publickey # networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
gmake[1]: Leaving directory `/var/yp/bosley'
root@iron3 >> /usr/lib/yp/ypinit -s charlyTo test the system use one of the servers as a client and run a request from it:
root@iron3 >> ypcat passwd mulder:x:500:100::/home/mulder:/bin/csh scully:x:501:100::/home/scully:/bin/bashYou can also see that the shadow passwords are working. We have an "x" where the password should be :)
|
|
To add a new slave server
run the command
/usr/lib/yp/ypinit -s charly
on the
new server and to add its name to the file /var/yp/ypservers on the master server.
If you add a new user then several maps will change (passwd, shadow, alias, etc ...).
After the maps have been changed you just run make in /var/yp/ on the master server. This will update the databases and push the data (using yppush) to the slaves.The program rpc.ypxfrd can speed up the transaction between master and slave by just copying them from the master instead of re-creating them on the slave. rpc.ypxfrd should be started at the same time as ypserv and solely on the master. This program is only needed if you have very big maps.
Just as there are passwords which are easy to guess, there are predictable NIS domain names. Obvious candidates are machine names and it is possible to test the NIS domain with ypwhich.
The NIS domain name shows up in several places, especially in the directory /var/yp and its subdirectories. They should not be readable for anyone other than root and must not be exported via NFS.
It doesn't hurt to use tcp_wrapper in addition to /var/yp/securenets to control the portmap process.
It is also an advantage to have no default route on the NIS server and use only static routing to the clients and the slave servers. That way the server can not answer requests that come from unknown hosts.
Firewall rules on the router are a very effective measures to control access to the NIS servers.
These security measures do not improve the security of NIS itself but the framework around it. Despite these problems, is NIS a very valuable tool.
|
Webpages maintained by the LinuxFocus Editor team
© Frédéric Raynal, FDL LinuxFocus.org Click here to report a fault or send a comment to LinuxFocus |
Translation information:
|
2001-10-27, generated by lfparser version 2.19