 |
» |
|
|
|
An NIS+ namespace may be “flat,” consisting
of a single domain, or it may be hierarchical, like the HP-UX directory
structure. Every namespace has exactly one root domain. All other
domains are subdomains of the root domain. This section explains how to perform the following tasks.
Only the first six tasks are required to set up a “flat” namespace
consisting of a single domain. Set
Up the Root Master Server | |
Before you perform this task, make sure no one is using the
host that will be the root master server. The nisserver script copies the /etc/nsswitch.nisplus file to /etc/nsswitch.conf. This may render the host unusable until the NIS+
tables are populated and NIS+ is operational. Log in as root to the host that will be the root master server. Issue the following command to set the default domain
name: /usr/bin/domainname default_domain |
The domain name must have at least two components, for example, Wiz.Com. Do not type a period at
the end of the domain name. Set the PATH variable to include /usr/lib/nis. If you are running the C shell, type the following
command: setenv PATH $PATH:/usr/lib/nis |
If you are running the Bourne or Korn shell, type the following commands: PATH=$PATH:/usr/lib/nis
export PATH |
Issue the following command to set up the root master
server: If you want the server to run in NIS compatibility mode so
that it can serve NIS clients, add the -Y option. See “NIS
Compatibility Mode” for more information. The nisserver script asks you if the information it has is correct. You
can change it by typing n. The script then allows you to change each piece
of information. To make a change, just type the correct information
after the incorrect information and press [Return]. You cannot change the security level. When the nisserver script asks you for a password, type the root password.
The nisserver script will use the root password to create credentials
for the local host in the cred table. To verify that the nisserver script created the root domain successfully, issue
the following command: The nisls command should list the domain name, the org_dir and groups_dir NIS+ directories, the admin group, and all the
standard tables listed in Table 5-1 “Standard NIS+ Tables”. If the host was previously an NIS server or client,
set the NIS_MASTER_SERVER, NIS_SLAVE_SERVER, and NIS_CLIENT variables to 0 in the /etc/rc.config.d/namesvrs file. Create a cron job that runs nisping -Ca at least once a day, during a time when the network
is not busy. The following example crontab file runs nisping -Ca once a day, at 3:00 AM. It directs standard output
and standard error from the nisping command to the file /tmp/nisping.log. 0 3 * * * /usr/lib/nis/nisping -Ca > /tmp/nisping.log 2& >1 |
The nisping -Ca command causes all servers of the domain to update
their tables with the changes in the transaction log and to clear
the transaction log. If you do not issue the nisping -Ca command regularly, your transaction log may grow
too large, and you may not have enough disk space to checkpoint
it.
After you run the nisserver script, the local host is set up as the root master
server and as a client of the default domain. However, the domain tables
are still empty. The next section, “Populate
the NIS+ Tables on the Master Server”, explains how to fill the tables with data. For more information, see the following man pages: nisserver(1M), domainname(1M), nisls(1), nsswitch.conf(4), crontab(1), rpc.nisd(1M), and nis(1). Populate
the NIS+ Tables on the Master Server | |
You can populate NIS+ tables from files or from NIS maps.
Before you populate the master server’s tables, you must
run the nisserver script to create the tables. See “Set
Up the Root Master Server” or “Set
Up an NIS+ Subdomain”. | | | |  | NOTE: The nispopulate script may fail if there is insufficient /tmp space on the system. To keep this from happening,
you can set the environment variable TMPDIR to a different directory. If TMPDIR is not set to a valid directory, the script will
use the /tmp directory instead. | | | | |
Log in as root to the master server. If you will populate the NIS+ tables from files,
create a temporary directory, and copy the files into it from the /etc directory: mkdir /nis+files
cd /etc
cp auto_home auto_master group hosts mail/aliases netgroup \
networks passwd protocols rpc services TIMEZONE ../nis+files |
In the temporary directory, remove the entry for
root from the passwd file. Remove all other entries with user ID 0
(zero) from the passwd file. Remove all the system entries such as root and bin, with user IDs of less than 100, from the passwd file. This should be done both for security and
for interoperability with NIS and other NIS+ implementations. Remove
any other entries from the passwd, aliases, or hosts files that you do not want distributed across
the namespace. In the temporary directory, remove any fully-qualified
DNS domain names from the hosts file. NIS+ cannot find fully-qualified DNS domain
names in its hosts table unless the DNS domain name matches one of
the NIS+ domain names in its namespace. Replace any periods in AutoFS map names with underbars.
For example, if your master map is called auto.master, rename it to auto_master. If you will populate your NIS+ tables from NIS
maps, make sure your NIS map names contain no periods. If you will populate
your NIS+ tables from files, make sure your file names contain no
periods. To populate the NIS+ tables from files, issue the
following command. The -p option specifies the path to the files. nispopulate -F -p /nis+files -d domainname |
To populate the NIS+ tables from NIS maps, issue the following command: nispopulate -Y -h NIS_server_name -a NIS_server_address \
-y NIS_domain -d domainname |
The nispopulate script asks you if the information it has is correct. You
can change it by typing n. The script then allows you to change each piece
of information. To make a change, just type the correct information
after the incorrect information and press [Return]. If you are populating files on the root master server, you
do not need the -d domainname option, because the default domain is the domain the
host will serve. However, on subdomain master servers, it is very important
to specify the domain, because it is different from the default
domain. To verify that your tables have been populated successfully,
issue the niscat command for several standard tables. The standard
tables are listed in Table 5-1 “Standard NIS+ Tables”.
The following example lists the contents of the NIS+ passwd table: niscat passwd.org_dir.domainname. |
Issue the following command to checkpoint the domain: Reboot the host to force long-running processes
to read the new /etc/nsswitch.conf file. (The nisserver script copies /etc/nsswitch.nisplus to /etc/nsswitch.conf.)
The nispopulate script populates the cred table from the passwd and hosts files or NIS maps. Every NIS+ principal except
the root user on the root master server is given the default NIS+
password, which is nisplus. (The credentials for the root user on the root
master server were created using the root password.) When you run
the nisclient script to initialize a client host in the root
domain, the nisclient script will change the client’s credentials
to use the client’s root password instead of the default
NIS+ password. See “Set
Up NIS+ Client Hosts”. For more information, see the following man pages: nispopulate(1M), nispasswd(1), niscat(1), nisping(1M), and nis(1). Add
Administrators to the NIS+ admin Group | |
Follow this procedure to add administrators to the NIS+ admin group, or use SAM (System Administration Manager).
To run SAM type sam at the HP-UX prompt. For more information, type man 1M sam. Type the following command to add NIS+ principals to the admin group: nisgrpadm -a admin.domainname NIS+_principal [NIS+_principal ...] |
For example, to add users ming and sara to the admin group in the Wiz.Com. domain, you would type the following command: nisgrpadm -a admin.Wiz.Com. ming.Wiz.Com. sara.Wiz.Com. |
Issue the following command to list the members
of the admin group to make sure the administrators you added
are there: nisgrpadm -l admin.Wiz.Com. |
The members of the NIS+ admin group may make any modifications to the NIS+ objects
in the domain that the group owner is allowed to make. See “NIS+
Authentication and Authorization” for an explanation
of NIS+ permissions. It is useful to add non-root users to the admin group, because they can administer the domain
while logged into any host in the namespace. Root users must be
logged in as root to a specific host in order to be recognized as
members of the admin group. The admin group is an NIS+ group stored in the groups_dir subdirectory of the domain directory. It is not one
of the HP-UX groups stored in the /etc/group file or the NIS+ group table. For more information, type man 1M nisgrpadm or man 1 nis at the HP-UX prompt. Set
Up NIS+ Client Hosts | |
Before you set up an NIS+ client host, the master server must
be set up and running, and the client must have an entry in the
NIS+ hosts table on the master server. Also, make sure no one
is using the client host. The nisclient script copies the /etc/nsswitch.nisplus file to /etc/nsswitch.conf. This may render the host unusable until NIS+
is operational. Log into the master server and issue the following command
to determine whether the client host has NIS+ credentials in the domain’s
cred table: nisgrep client_hostname cred.org_dir.domainname |
The nispopulate script creates credentials for every host that
is in the /etc/hosts file or NIS hosts map when the command is run. If the client host
did not have a hosts entry when nispopulate was run, it will not have credentials in the cred
table. If the nisgrep command returns nothing, issue the following command
on the master server to add a credential for the client host: nisclient -co client_hostname |
When prompted for a password, type the default password, nisplus. Log in as root to the host that will be the NIS+
client. Issue the following command to set the NIS+ domain
name: /usr/bin/domainname domainname |
If the host was previously an NIS server or client,
set the NIS_MASTER_SERVER, NIS_SLAVE_SERVER, and NIS_CLIENT variables to 0 in the /etc/rc.config.d/namesvrs file. Set the PATH variable to include /usr/lib/nis. If you are running the C shell, type the following
command: setenv PATH $PATH:/usr/lib/nis |
If you are running the Bourne or Korn shell, type the following commands: PATH=$PATH:/usr/lib/nis
export PATH |
Issue the following command to initialize the client
host: nisclient -i -h master_server_name |
If the master server’s internet address is not in
the client’s /etc/hosts file, the nisclient script will prompt you for the master server’s
internet address. The nisclient script will prompt you for the secure RPC password for
root. Type the default NIS+ password, nisplus. The nisclient script will then prompt you for the root password
on the client host. After you type the password, the nisclient script will change the client host’s
entry in the cred table to use the root password instead of the
default password. Issue the following command on the new NIS+ client
host to verify that the host can receive information from the NIS+
server: The nisls command should list the domain name and the org_dir and groups_dir NIS+ directories. To verify that your client can get information from
NIS+ tables, issue the niscat command for several standard tables. The standard tables
are listed in Table 5-1 “Standard NIS+ Tables”. The following
example lists the contents of the NIS+ passwd table: Reboot the host to force long-running processes
to read the new /etc/nsswitch.conf file. (The nisclient script copies /etc/nsswitch.nisplus to /etc/nsswitch.conf.)
For more information, see the following man pages: domainname(1), nisaddcred(1M), nisclient(1M), nisls(1), and nis(1). Set
Up NIS+ Replica Servers | |
Before you can set up a replica server, the master server
must be set up and running, and the hosts table on the master server must contain an entry
for the host that will be a replica. When you run the nisserver script to initialize a replica server, the NIS+
tables on the master server are copied to the replica. Copying the tables
can take anywhere from a few minutes to a couple of hours, depending
on the size of your tables, the network load, and the system load
on the master and replica servers. Log in as root to the host that will be a replica server. Set the PATH variable to include /usr/lib/nis. If you are running the C shell, type the following
command: setenv PATH $PATH:/usr/lib/nis |
If you are running the Bourne or Korn shell, type the following commands: PATH=$PATH:/usr/lib/nis
export PATH |
If the host will be a root replica server, set it
up as a client in the root domain. If the host will be a non-root
replica server, set it up as a client in the parent domain of the
domain it will serve. See “Set
Up NIS+ Client Hosts”. Type the following command if the master server
is not running in NIS compatibility mode: Type the following command if the master server is running
in NIS compatibility mode: If the master server is running in NIS compatibility mode,
its replica servers must also run in NIS compatibility mode. See “NIS
Compatibility Mode” for more information. Set the NISPLUS_SERVER variable to 1 in the /etc/rc.config.d/namesvrs file: If the host was previously an NIS server or client, set the NIS_MASTER_SERVER, NIS_SLAVE_SERVER, and NIS_CLIENT variables to 0. Log in as root to the master server. Type the following command to initialize the replica
server: nisserver -R -h replica_host_name |
The nisserver script asks you if the information it has is correct. You
can change it by typing n. The script then allows you to change each piece
of information. To make a change, just type the correct information
after the incorrect information and press [Return]. Type the following command on the master server
to checkpoint the domain and copy the domain directories to the
new replica server: To verify that the replica server is operating correctly,
issue the following command: nisstat -H replica_host_name |
The nisstat command should return a list of statistics about
the replica server.
It is recommended that you have only a few replicas per domain,
for performance reasons. Do not configure more than 10 replicas
per domain. If your domain includes sites that are distant from
the master server, configure replica servers at the distant sites
to avoid unnecessary network traffic. For more information, see the following man pages: nisserver(1M), rpc.nisd(1M), nisping(1M), nisstat(1M), and nis(1). Initialize
NIS+ Client Users | |
Tell all of your non-root users to perform this task. This
task sets a user’s secure RPC password to be the same as
the user’s login password. Log into any NIS+ client host using your non-root user login. Issue the following command: /usr/lib/nis/nisclient -u |
The nisclient script will prompt you for the secure RPC password. Type
the default password, nisplus. The nisclient script will then prompt you for your login password. After
you type your login password, the nisclient script will change your cred table entry to use your login password instead
of the default password. To change your password in the future, use the nispasswd command, which changes your login password and
your secure RPC password at the same time.
For more information, see the following man pages: nisclient(1M), nispasswd(1), and nis(1). Set
Up an NIS+ Subdomain | |
Before you can set up a subdomain, the parent domain must
be set up, and its master server must be running. The master server
for the parent domain must have an entry in its hosts table for the master server of the new subdomain. Log in as root to the host that will be the master server
for the subdomain. Set the PATH variable to include /usr/lib/nis. If you are running the C shell, type the following
command: setenv PATH $PATH:/usr/lib/nis |
If you are running the Bourne or Korn shell, type the following commands: PATH=$PATH:/usr/lib/nis
export PATH |
Set up the host as a client in the parent domain.
For example, if the root domain is Wiz.Com., and you are setting up a subdomain called Eng.Wiz.Com., make the host a client in the Wiz.Com. domain. See “Set
Up NIS+ Client Hosts”. Type the following command if the new master server
will not run in NIS compatibility mode: If the new master server will be required to serve NIS clients,
type the following command to run the server in NIS compatibility
mode. See “NIS
Compatibility Mode” for
more information. Set the NISPLUS_SERVER variable to 1 in the /etc/rc.config.d/namesvrs file: If the host was previously an NIS server or client, set the NIS_MASTER_SERVER, NIS_SLAVE_SERVER, and NIS_CLIENT variables to 0. Log in as root to the master server for the parent
domain of the new subdomain. For example, if the new
subdomain will be called Eng.Wiz.Com., log in as root to the master server for the Wiz.Com. domain. Issue the following command if the master server
of the new subdomain will not run in NIS compatibility
mode: nisserver -M -d subdomain_name -h subdomain_master_server_name |
If the master server of the new subdomain will be required
to serve NIS clients, issue the following command to set up the
master server in NIS compatibility mode: nisserver -M -Y -d subdomain_name -h subdomain_master_server_name |
Log in as root to the master server of the new subdomain. Populate the new master server’s tables
from files or from NIS maps. See “Populate
the NIS+ Tables on the Master Server”. Be sure to specify the -d domainname option in the nispopulate command. To verify that the subdomain was created successfully,
issue the following command: The nisls command should list the subdomain name, the org_dir and groups_dir NIS+ directories, the admin group, and all the standard tables listed in Table 5-1 “Standard NIS+ Tables”. Create a cron job that runs nisping -Ca at least once a day, during a time when the network
is not busy. The following example crontab file runs nisping -Ca once a day, at 3:00 AM. It directs standard output
and standard error from the nisping command to the file /tmp/nisping.log. 0 3 * * * /usr/lib/nis/nisping -Ca > /tmp/nisping.log 2& >1 |
The nisping -Ca command causes all servers of the domain to update
their tables with the changes in the transaction log and to clear
the transaction log. If you do not issue the nisping -Ca command regularly, your transaction log may grow
too large, and you may not have enough disk space to checkpoint
it. Initialize the clients of the new subdomain. See “Set
Up NIS+ Client Hosts”. Set up one or more replica servers for the new subdomain.
See “Set
Up NIS+ Replica Servers”. Initialize the client users of the new subdomain.
See “Initialize
NIS+ Client Users”.
Every time you create a master server, you create a new subdomain.
You can create as many domains as you need. You can create subdomains beneath
subdomains. It is recommended that you keep your namespace hierarchy
as simple as possible and that you keep an accurate map of your
namespace. For more information, see the following man pages: nisserver(1M), rpc.nisd(1M), nispopulate(1M), nisclient(1M), and nis(1). Use
BIND With NIS+ | |
An NIS+ client can consult BIND (DNS), NIS, NIS+, or the /etc/hosts file when it needs to resolve a host name to an
IP address. The Name Service Switch determines where an NIS+ client
will look for host information. Some clients, like PCs, cannot use the Name Service Switch.
If your domain includes PC clients, you can configure the NIS+ server
to query BIND when its NIS+ hosts table does not contain the information that a client
requests. The server then returns the information to the client through
NIS+. Only NIS+ servers running in NIS compatibility mode may consult BIND
to answer client queries. See “NIS
Compatibility Mode” for more information. This section tells you how to perform the following tasks: If your NIS+ clients support the Name Service Switch, configure
the clients to query BIND. If your NIS+ clients do not support the Name Service Switch,
configure their server to return BIND information. | | | | | NOTE: BIND must already be configured and running before you
can configure an NIS+ client or server to query it. To configure
BIND, see the Installing and Administering Internet Services manual. | | | | |
To
Configure an NIS+ Client to Query BINDLog in as root to the NIS+ client host. Use a text editor to open the /etc/nsswitch.conf file, and find the line that begins with hosts. It probably looks something like this: hosts: nisplus [NOTFOUND=return] files |
Change the hosts line so that it looks like this: hosts: dns [NOTFOUND=return] nisplus [NOTFOUND=return] files |
The NIS+ client will now query BIND first for host information.
If the BIND server is down or unreachable, it will query NIS+. Then,
if no NIS+ server is available, it will consult its local /etc/hosts file. For more information, type man 4 nsswitch.conf at the HP-UX prompt. To
Configure an NIS+ Server to Return BIND Information to ClientsOnly servers running in NIS compatibility mode may return
BIND information to clients through NIS+. Log in as root to the NIS+ server. In the /etc/rc.config.d/namesvrs file, set the EMULYP variable to “-Y -B”, as follows: Kill the rpc.nisd daemon, and restart it with the -Y and -B options: ps -ef | grep rpc.nisd
kill PID
rpc.nisd -Y -B |
For more information, type man 1M rpc.nisd at the HP-UX prompt. Allow
an NIS+ User Authenticated Access to Another Domain | |
A user’s home domain is defined
as the domain where the user has a DES credential in the cred table. (Each NIS+ principal has a DES credential
in only one domain.) If a user needs to be authenticated in another
domain, the user must have a Local credential in that domain. In
domains where the user does not have a Local credential, the user
is treated as “nobody.” From any NIS+ client host, issue the following commands to
copy the passwd table entry from the user’s home domain
to the remote domain where the user needs authenticated access: nismatch name=username passwd.org_dir.user’s_homedomain \
> tempfile
nisaddent -a -f tempfile passwd remote_domainname |
If necessary, change the user ID in the entry to
ensure that it is unique in the passwd table of the remote domain. Each user ID may occur
only once in a passwd table. See “Modify
an Entry in an NIS+ Table”. From any NIS+ client host, issue the following command: nisaddcred -p UID -P loginname.domainname local remote_domainname |
The argument following the -p option is the user’s user ID from the NIS+ passwd table in the remote domain where the user needs authenticated
access. The argument following the -P option is the user’s NIS+ principal name
and must end with a period. The remote_domainname argument is the domain where the credential will
be created (the domain where the user needs authenticated access).
The following example allows NIS+ principal sara.Eng.Wiz.Com to be authenticated in domain Sales.Wiz.Com.: nisaddcred -p 7899 -P sara.Eng.Wiz.Com. local Sales.Wiz.Com. |
You must have create permission for the cred table and the passwd table in the remote domain in order to complete
this task. For more information, see the following man pages: nisaddcred(1M), nismatch(1), and nisaddent(1M). |
Printable version
