SunSolve Internal


Infodoc ID   Synopsis   Date
11988   NIS+ PSD/FAQ   13 Oct 1999

Description Top

Tip Sheet for Sun NIS+ 

Revision: 1.6
Date Top
April 30, 1998


Preface
1.0: About NIS+
  1.1: An Explanation of the Basic NIS+ Objects
2.0: Debugging NIS+
  2.1: Authentication Problems
  2.2: Examining NIS+ Tables
  2.3: Using snoop
  2.4: Performance Problems
3.0: Common How Tos
  3.1: How to Prepare Your Site for NIS+
  3.2: How to Set Up a Root NIS+ Master
  3.3: How to Set Up a NIS+ Client
  3.4: How to Set Up a Root NIS+ Replica
  3.5: How to Set Up a Subdomain NIS+ Master
  3.6: How to Set Up a Subdomain NIS+ Replica
  3.7: How to Configure the Root Server for an IP Address Change
  3.8: How to Add a User to the Admin Group
  3.9: How to Change a NIS+ user passwd
  3.10: How to Change a NIS+ root passwd
  3.11: How to Administer NIS+ Credentials
  3.12: How to Administer NIS+ Groups
  3.13: How to Administer NIS+ Tables
  3.14: How to Examine NIS+ tables
  3.15: How to Modify NIS+ Tables
  3.16: How to Regularly Administer NIS+
  3.17: How to Remove NIS+
  3.18: How to define the printer table
  3.19: How to Remove a Replica
4.0: Some Frequently Asked Questions
  4.1: Miscellaneous Questions
  4.2: NIS+ Setup Problems
  4.3: User Login Problems
  4.4: NIS+ Lookup Problems
5.0: Patches
  5.1: Solaris 2.3 NIS+ Patches
  5.2: Solaris 2.4 NIS+ Patches
6.0: Known Bugs & RFEs
7.0: References
  7.1: Important Man Pages
  7.2 Sunsolve Documents
  7.3 Sun Educational Services
  7.4: Solaris Documentation
  7.5: Third Party Documentation
  7.6: RFCs
8.0: Supportability
9.0: Additional Support

Preface 

The purpose of this support document is to give an overview of the 
nis+ naming service, give references to other documentation for detailed 
explanations and procedures where applicable and to include certain procedures 
that do no exist in other documentation.  This document will also include a FAQ
section and a section on debugging NIS+.

This document will not include in depth descriptions that can be found
in other Sun documentation, nor will it include procedures that can be found 
in same. This document is intended to be used as a reference.  The following 
list of documents will be referenced frequently and are all part of the 
standard doc set for their appropriate releases.

        Solaris 2.3

        SunOS 5.3 Administering NIS+ and DNS
        NIS+ Quick Start

        Solaris 2.4

        Name Services Administration Guide
        Name Services Configuration Guide 
        NIS+ Transition Guide

        Solaris 2.5

        NIS+ and FNS Administration Guide
        NIS+ and DNS Setup and Configuration Guide
        NIS+ Transition Guide

This document will also contain references to patches and it should
be noted that patches are very dynamic and the revisions occur frequently.
Thus it is always best to check with Sunsolve or the solution center to see
what the current version of a patch is before installing it.

1.0: About NIS+  

NIS+ stands for Network Information Service Plus. It was designed to
replace NIS, and is a default naming service for Solaris. NIS+ can
provide limited support to NIS clients via a YP-compatibility mode.
NIS+ was mainly designed to address problems that NIS cannot address.

One important thing to note is that there is no relation between NIS+
and NIS. The commands and the overall structure of NIS+ are different
from NIS. In addition, some command syntax in NIS+ is different from
the NIS commands. NIS+ was designed from scratch.

NIS+ increases security by using an additional authentication method.
Users will still have their standard LOGIN PASSWORD, will will give
them access to the system. They will also have a SECURE RPC PASSWORD
or NETWORK PASSWORD. This new password is necessary to actually access
NIS+, and is what provides the new security. Usually, a user's LOGIN
PASSWORD and NETWORK PASSWORD will be the same, and a user will
automatically have access to all NIS+ functionality when they login
with their login password. However, if they are different, a user will
have to KEYLOGIN and type his network password to get access to NIS+.

There are a huge number of programs related to NIS+. The most
important ones are explained elsewhere in this document. All are
listed in Section 7.1  you should consult the man pages for any
additional information. Of special notes are the NIS+ daemons:

RPC.NISD and NIS_CACHEMGR are the standard NIS+ daemons. You should
see them running on every NIS+ server and client.

1.1: An Explanation of the Basic NIS+ Objects

NIS+ objects are structural elements used to build and define the NIS+
namespace. There are 5 basic NIS+ objects. Objects are always
seperated by dots.

DIRECTORY OBJECTS: Similar to a UNIX system directory, in that it can
contain one or more objects such as: table objects, group objects,
entry objects or link objects. Directory objects form an inverted
tree-like structure, with the root domain at the top and the
subdomains branching downwards. They are used to divide namespace into
the different parts. Each main directory object will contain that
domain's org_dir and groups_dir directory objects. The org_dir
directory objects contain table objects for that domain. The
groups_dir directory objects contain NIS+ administrative group
objects.

  Example of DIRECTORY OBJECTS:

  Sun.Com.
  org_dir.Sun.Com.
  groups_dir.Sun.Com.

TABLE OBJECTS: Similar to NIS maps. They store a variety of network
information. Tables may contain zero or more ENTRY OBJECTS. There are
a total 17 predefined table objects. Tables can be administered with
nistbladm or nisaddent command. Table entry objects form a row in the
table and each row stores one record.

  Example of TABLE OBJECTS: 

  Passwd.org_dir.Sun.Com.
  Hosts.org_dir.Sun.Com.

  Example of ENTRY OBJECTS:

  [name=user1],passwd.org_dir.Sun.Com.

GROUP OBJECTS: These are NIS+ namespace administrative user groups. They
permit controlled access rights to namespace modification on a group
basis. They are administered with the nisgrpadm command.

  Example of GROUP OBJECTS:

  admin.groups_dir.Sun.Com.

LINK OBJECTS: These are pointers to other objects. They are similar to
symbolic links. They typically point to table or object entrys.
Administered with the nisln command.

2.0: Debugging NIS+  

Before trying to debug a NIS+ problem, you should always make sure
that you have the recommended patches installed on the system. In
particular, the kernel patch should be at the current patch level, and
all the systems have the same patch rev. 

2.1: Authentication Problems 

Most of the problems in NIS+ are authentication related problems.
Assuming that you are running rpc.nisd at security level 2 on your
master server, you can use niscat to determine if a user is
authenticated:

  %%%% /usr/bin/niscat passwd.org_dir

If the user can see the encrypted passwds, then the user is
authenticated. If the user sees *NP* in place of encrypted passwds,
then he does not have permission to read the passwd column. In this
case, you could run 'keylogin' to try and reauthenticate the user. If
that works, the user might need to run 'chkey' to sync his login and
network passwords.

If keylogin still does not authenticate the user, it is likely that
his credentials have not been set up correctly. You can check that
someone actually has credentials by examining the cred table:

  %%%% /usr/bin/niscat cred.org_dir

You can create credentials for a user with nisclient:

  %%%% /usr/lib/nis/nisclient -c username

When having credential problems, also consider that it might be a
problem with the credentials of the workstation as well. If known-good
users fail on a specific workstation, you will probably want to try
and set the workstation back up, as described in Section 3.3.

2.2: Examining NIS+ Tables 

Some NIS+ problems will be related to information missing from tables.
You can examine the contents of tables with a variety of commands.

niscat will output the entire contents of a table for you:

  %%%% /usr/bin/niscat passwd.org_dir

You can also examine the object properties of a table:

  %%%% /usr/bin/niscat -o passwd.org_dir

This can be very helpful, because it will show you if a table has
weird permissions which may be restricting access.

nismatch can also be used to find things in a table:

  %%%% /usr/bin/nismatch -h joe passwd.org_dir

niscat and nismatch both directly access the NIS+ tables. getent, on
the other hand, will look up tables in the order defined in the
/etc/nsswitch.conf. A typical getent command would be the following:

  %%%% getent passwd joe

This would look up the user joe in passwd. In a typical environment,
it would access files first, and then NIS+. If you find that getent
and nismatch give you different answers, you should look at your
nsswitch.conf. Perhaps a naming service that is listed earlier in your
nsswitch.conf has different info. Alternatively, maybe NIS+ is not
listed at all in your nsswitch.conf.

2.3: Using Snoop 

If you are having intermittent problems, snoop is often useful to
debug them. To use snoop correctly, you must run it from an uninvolved
machine. For example, if you have a client that is having intermittent
problems with NIS+, you should run snoop on a machine on the same
subnet as the problem client, but the machine must be neither the
client nor any of the NIS+ servers:

  unrelated-machine# snoop problem-machine

This will tell you about all of the packets going in and out of the
problem-machine. You should look for NIS+ packets, taking careful
notes of errors. If you are getting some type of intermittent errors,
it is useful to see which Server your Client was talking with at the
time of your problem. Possibly one of your Servers has bad or old
information?

2.4: Performance Problems 

Some NIS+ problems may be related to performance. You might find NIS+
servers overloaded. You might get "NIS+ Server Unreachable" errors
because your network is overloaded. The commands 'snoop' and 'netstat'
may be used to examine such problems further, but Performance Tuning
is beyond the scope of the help that SunService can provide. Sections
8.0 and 9.0 explain other places you can get help from within Sun.

3.0 Common How Tos

3.1: How to Prepare Your Site for NIS+ 

Before configuring NIS+ namespace you need to do initial planning
including: verifying hardware and software requirements, deciding the
name of the domain, determining security level and planning your
domain hierarchy.

In general you need a solaris 2.3 or higher Operating system. 32 to 64
MB of memory and about 128 MB of swap space is recommended for a
medium to large domain. The size of /var/nis is recommended to be
about 20 MB. All of these requirements can be found in the
Administering Name Services Manual (see Section 7.4).

The domainname for the root server should be at least two labels long.
This means that the domain name "xyz." is not supported, but the
domainname "xyz.com." is a correct domain name.

Another thing to think about is security level. The default security
level is 2. If you want a secure enviroment, then you should run NIS+
at security level 2. If you have SunOS client machines on the network,
which are going to get served by the NIS+ server, then you need to run
NIS+ in YP compatibility mode. You should also decide about the access
rights you want to give to users and administrative group.

Lastly, you should learn about imporatant NIS+ concepts such as the
difference between the login passwd and the network passwd. It's very
important to know this difference while troubleshooting authentication
related problems.

Once you are ready to begin configuring your domain, it is recommended
that you use the quick startup scripts to configure NIS+ namespace.
For example, to configure the root server use the nisserver script  to
configure clients use the nisclient script. These scripts are easy to
use and reduce chances for errors. The following Sections outline the
use of thse scripts.

3.2: How to Set Up a Root NIS+ Master 

To set up a root server, become the superuser on the root master, and
use the nisserver script to build the root domain:

  root-server# /usr/lib/nis/nisserver -v -r -d domain_name

(where domain_name is your NIS+ domain and make sure you specify a trailing
dot after your domain name, for example:   xxx.yyy.zzz.   )

Afterwards, you will want to populate the NIS+ tables from a set of
ASCII files. It is a good idea to create a seperate directory and then
edit the files required to populate the tables there.

For example, create a directory /var/tmp/nisfiles and copy the files
from the /etc directory to /var/tmp/nisfiles, and then edit the files.
You may wish to edit the passwd file, for example, because you only
need the entries for the normal users in the NIS+ passwd table.

Following is the list of standard NIS+ tables, which you may wish to
include when you populate your maps (although it is not required that
they all be included):

  aliases
  auto_home
  auto_master
  bootparams
  cred
  group
  hosts
  netgroups
  netmasks
  networks
  passwd
  protocols
  rpc
  services
  timezone

To populate the tables, change to the directory where the edited files
are, and then run the nispopulate script:

  root-master# cd /var/tmp/nisfiles
  root-master# /usr/lib/nis/nispopulate -v -F  

One important thing to note is the network passwd created in the
credential table for all the users is "nisplus". This should be
changed to something more secure. For normal users, every user needs
to run keylogin and then do the chkey command and enter a new network
passwd. It is highly recommended that login passwd and the network
passwd be the same. In the NIS+ enviroment, login explicitly runs
keylogin and so, if the network passwd is same as the login passwd,
users don't have to do a seperate keylogin to authenticate.

When the nispopulate is done, you should reboot your server. When it
comes back up, you can verify that NIS+ is working correctly by
running the standard NIS+ commands:

  root-master%%%% /usr/bin/nisls
  root-master%%%% /usr/bin/niscat passwd.org_dir

3.3: How to Set Up a NIS+ Client 

To set up a NIS+ client, first become root on the master server, and
verify that NIS+ host table has an entry for the client. If it does
not, use admintool to add it. Afterwards, run the nisclient script to
create credentials for the client machine:

  root-master# /usr/lib/nis/nisclient -v -d domain_name -c client_machine

(where domain_name is your NIS+ domain, and client_machine is the name
of your new client.)

Do not worry if nisclient tells you that the credentials already exist
for your client_machine.

Next, login to your client machine as root, and run nisclient to
initialize it:

  client# /usr/lib/nis/nisclient -v -i -h master_machine -a master_ip -d
domain_name

(where master_machine is the name of your NIS+ master, master_ip is
the IP address of your NIS+ master and domain_name is the name of your
NIS+ domain.)

3.4: How to Set Up a Root NIS+ Replica 

After your root replica has been set up as a client system (see
Section 3.3), start the NIS+ server daemon:

  root-replica# /usr/sbin/rpc.nisd

Then, you can execute the nisserver command on the root-master:

  root-master# /usr/lib/nis/nisserver -v -R -d domain_name -h replica_machine

(where domain_name is your NIS+ domain and replica_machine is the name
of your root-replica.)

Finally, run nisping on the master server to propagate the tables to
the replica server:

  root-master# /usr/lib/nis/nisping domain_name.
  root-master# /usr/lib/nis/nisping org_dir.domain_name.
  root-master# /usr/lib/nis/nisping groups_dir.domain_name.

(where domain_name is your NIS+ domain.)

3.5: How to Set Up a Subdomain NIS+ Master 

The subdomain server must already be setup as a client of the domain
above it (see Section 3.3). This may be the root domain, or some
subdomain. After it is, you should start rpc.nisd:

  subdomain-master# /usr/sbin/rpc.nisd

Then, you should login to the master of the domain above your current
domain, and execute nisserver (root-master is used in this example,
but this could also be some higher subdomain-master):

  root-master# /usr/lib/nis/nisserver -v -M -d subdomain_name -h
subdomain_master

(where subdomain_name is the name of your new NIS+ subdomain, and
subdomain_master is the name of your Subdomain master.)

You will then want to populate the NIS+ tables for your new Subdomain.
This is done on your subdomain master, in a similar manner to that
described in Section 3.2:

  subdomain-master# cd /var/tmp/nisfiles
  subdomain-master# /usr/lib/nis/nispopulate -v -F  

Afterwards, reboot your new subdomain master.

3.6: How to Set Up a Subdomain NIS+ Replica 

The same procedure as is described in Section 3.4, should be used to
set up a Subdomain Replica. However, the commands will be run on the
subdomain-master, not the root-master.

3.7: How to Configure the Root Server for an IP Address Change 

The old method of dumping the tables that used to be listed here has been
removed as it is not nessceary to bring down the domain to perform an IP
address change, instead Follow SRDB 11728.  

3.8: How to Add a User to the Admin Group 

In your default setup, only root on your master machine will be able
to make modifications to most of your NIS+ maps. You will probably
want to extend these permissions to all of the system administrators.
This is typically done by putting all of the system administrators
into the admin group:

  # /usr/bin/nisgrpadm -a admin.domain_name. joe
  # /usr/bin/nisgrpadm -a admin.domain_name. liz

The above command will give joe and liz the ability to modify most
NIS+ tables from their own accounts. This can give considerable
privilege, so you should make sure that joe and liz are trusted, and
also that their accounts are secure.

If you want to list the members of the admin group use the -l option:

  # /usr/bin/nisgrpadm -l admin.domain_name.
    Group entry for "admin.nisplus.lab.net." group:
    Explicit members:
        omni.nisplus.lab.net.
        cascades.nisplus.lab.net.
        kevinc.nisplus.lab.net.
    No implicit members
    No recursive members
    No explicit nonmembers
    No implicit nonmembers
    No recursive nonmembers

3.9: How to Change a NIS+ user passwd 

On Solaris 2.5 machines and later the passwd command now performs 
all functions previously performed by nispasswd.  

  %% /usr/bin/passwd -r nisplus

As root on Solaris 2.5 and later you either use adminsuite or
  # /usr/bin/passwd -r nisplus username

On Solaris 2.4 and earlier the passwd for a normal user can be changed
by them running the nispasswd command:

  %% /usr/bin/nispasswd

This updates the passwd in the passwd table, and also updates the
credential table. 

Root can change passwds for users by using adminsuite or by running:

  # /usr/bin/nispasswd user_name

However, this procedure should NEVER be used for changing the root passwd.

3.10: How to Change a NIS+ root passwd 

To change a root passwd, you MUST use the following procedure.

First, issue the passwd command, and supply new passwd:

  # /usr/bin/passwd

Do not use nispasswd!

This will change the passwd in the local /etc/passwd file. Then, run
chkey -p and enter the new network passwd:

  # /usr/bin/chkey -p

Updating nisplus publickey database.
Reencrypting key for 'unix.total@joe.com'.
Please enter the Secure-RPC password for root: <--- This was the original
passwd
Please enter the login password for root: <--- This is the newly assigned
passwd
#

If you use any other method for updating your root passwd, you can
totally mess up your NIS+ domain.

3.11: How to Administer NIS+ Credentials 

The nisaddcred command can be used to create, update and remove LOCAL
and DES credentials.

To create or update credentials for another NIS+ principal:

  %%%% /usr/bin/nisaddcred -p uid -P principal-name local
  %%%% /usr/bin/nisaddcred -p rpc-netname -P principal-name des

The rpc-netname is unix.uid@domain_name for a user, and
unix.hostname@domain_name for the root user on a host. Note that these
domainnames do NOT contain a trailing dot, unlike most NIS+ commands.
The principal-name is name.domain_name., where name can be user name
or a hostname.

For example, joe (uid 555) in the example.com domain has the following
names:

  principal-name:       joe.example.com.
  rpc-netname:          unix.555@example.com

While root on the machine testhas the following names:

  principal-name:       test.example.com.
  rpc-netname:          unix.test@example.com

A few caveats: you can only create DES credentials for a client
workstation. DES credentials may only be created in the client's home
domain. However, you can create LOCAL credentials for a client user in
other domains.

To remove credentials:

 %%%% /usr/bin/nisaddcred -r principal-name

3.12: How to Administer NIS+ Groups 

The following commands may all be used to administer NIS+ groups. Be
aware that NIS+ groups are not the same thing as normal UNIX groups.

You can list the object properties of a group with niscat:

  %%%% /usr/bin/niscat -o group-name.groups_dir.domain_name.

The nisgrpadm command creates, delets and performs miscellaneous
administartion operations on the nis+ groups.

To create a group:

  %%%% /usr/bin/nisgrpadm -c group-name.domain_name.

The group you cretae will inherit all the object properties specified
in the NIS_DEFAULTS variable. You can view the defaults using the
nisdefaults command:

  root-master# /usr/bin/nisdefaults
  prinicipal name : master.domain_name
  domain name : domain_name
  Host Name   : master.domain_name
  Group Name: 
  Access Rights  : ----rmcdr---r---
  Time to live   :12:0:0
  Search Patch : domain-name

To delete a group:

  %%%% /usr/bin/nisgrpadm -d group-name.domain_name.

To list the group members:

  %%%% /usr/bin/nisgrpadm -l group-name.domain_name.

To add members to a NIS+ group:

  %%%% /usr/bin/nisgrpadm -a group-name member

To remove members from a NIS+ group:

  %%%% /usr/bin/nisgrpadm -r group-name member

To determine if a member belongs to a NIS+ group:

  %%%% /usr/bin/nisgrpadm -t group-name member

3.13: How to Administer NIS+ Tables 

The nistbladm command is the primary NIS+ table administration
utility. With this command, you can create, modify or delete tables
and table entries. To create a table you must have create rights to
the directory under which you will create. To delete a table you must
have a destroy rights to the directory. To modify a table, or to add,
change or delete the entries you must have modify rights to the table
or the entries.

Table column can have following characteristics:

  S Searchable 
  I case insensitive
  C encrypted

To create a table:

  %%%% /usr/bin/nistbladm -c table-type column-spec .... table-name

For example, to create a table of type 'computers' and of name
'computers.example.com.', with two columns, 'name' and 'model', which
are both searchable, you would use the following command:

  %%%% /usr/bin/nistbladm -c computers name=S model=S computers.example.com.

(assuming your domain_name is example.com)

To delete a table:

  %%%% /usr/bin/nistbladm -d table-name

For example, to delete your computers table, you would use the following
command:

  %%%% /usr/bin/nistbladm -d computers.example.com.

For more info about adding entries or modifying entires, refer to the
nistbladm man page.

3.14: How to Examine NIS+ tables 

The niscat command displays the contents of NIS+ tables.

To display the object properties of a table:

  %%%% /usr/bin/niscat -o table-name

Or:

  %%%% /usr/bin/niscat -o entry

To display the contents of a table:

  %%%% /usr/bin/niscat -h table-name

3.15: How to Modify NIS+ Tables 

NIS+ tables may be modified in a number of ways. One note for all of
these mesthods is that a NIS+ principal must be a member of the admin
NIS+ group for them to make modifications to most tables (see Section
3.8).

The best method is to use the admintool GUI to modify them. The only
downsides to this approach are: admintool requires X to be running 
not all the standard tables are available through admintool  and new
tables will never be available through admintool.

If you can not use admintool to modify a table, nisaddent is the best
alternative. The nisaddent command loads information from text files
or from NIS maps into NIS+ tables. It can also dump the contents of
the NIS+ tables back to text files. The following options are used
along with the nisaddent command:

  -a append: add the contents of the source to the table
  -r replace: substitute contents of the source for the contents of the table
  -m merge: merge the contents of the source with the contents of the table.
  -d dump : dump the contents of the table to stdout

(With no -a, -r or -m options, the default is REPLACE)

You can put new entries into a file, and then merge those changes in:

  %%%% /usr/lib/nis/nisaddent -m -f filename table-type

For example:

  %%%% /usr/lib/nis/nisaddent -m -f /etc/hosts hosts

Or, you could dump a table, make changes and then replace the copy of
the table in NIS+

For example:

  %%%% /usr/lib/nis/nisaddent -d hosts > /tmp/hosts
  %%%% vi /tmp/hosts
  %%%% /usr/lib/nis/nisaddent -rvf /tmp/hosts hosts

There is a special case to modify the password table using nisaddent.

Example:

  %%%% /usr/lib/nis/nisaddent -d passwd > /tmp/passwd
  %%%% /usr/lib/nis/nisaddent -d shadow > /tmp/shadow
  %%%% vi /tmp/passwd
  %%%% /usr/lib/nis/nisaddent -r -f /tmp/passwd passwd
  %%%% /usr/lib/nis/nisaddent -m -f /tmp/shadow -t passwd.org_dir shadow

The reason that you must do the passwd table this way is that is you don't
reload all the shadow information your passwords will be lost.

If you do not want to use nisaddent, your final option is to use
nistbladm to directly modify the table. This can be fairly complex.
Examine the nistbladm man page for more information on how to do so.

3.16: How to Regularly Administer NIS+ 

Depending on the updates one performs in the namespace, it is a good
idea to frequently perform nisping -C (it is recommended that you nisping
all the directory objects:  the domain, org_dir.domain and groups_dir.domain)
so that log files gets written to the disk. You may wish to put this into 
a cron tab on your root-master server, to make sure that it is executed daily.

Another important NIS+ administration task is to regularly backup
the /var/nis directory and the /etc/.rootkey file, to make sure that 
you can recover in the case of a massive failure.

Lastly, keep in mind that you should always have 'flat file' backups of your
NIS+ data.  Make sure that you dump your tables regularly (see section 3.7)
and especially if you make all your changes via Solstice Adminsuite.  Making
changes via Adminsuite does not give you a flat file copy of the data and
if you experience a loss of /var/nis you will not be able to recover
that data without a backup of /var/nis or your flat files to rebuild with

3.17: How to Remove NIS+ 

If you wish to remove NIS+, you should run the following commands on
all of your NIS+ machines.  (NIS+ clients will not be running rpc.nisd):

  # cp /etc/nsswitch.files /etc/nsswitch.conf
  # kill <PID_of_rpc.nisd>                      (This step is only for NIS+
servers)
  # kill <PID_of_nis_cachemgr>
  # rm -f /etc/.rootkey
  # rm -rf /etc/defaultdomain
  # rm -rf /var/nis/*

It is suggested that you start with the clients, and do the servers
last.

3.18:  Administering the Printer Namespace with NISPLUS and FNS. 

FNS provides the capability to store printer bindings in the FNS namespace.
This gives the print servers the means to advertise their services and allow 
users to browse and choose amoungst the available printers.  Nisplus cannot do 
this without FNS!

Refer to the "NIS+ and FNS Administration Guide" for Solaris 2.x for 
installation of FNS.  

NOTE: This is Sun Soft Print Client (SSPC) only.  

1, Verify the nisplus/fns namespace exist 

master# /usr/bin/fnlist -l org

        if it returns something besides not found, continue on.
        if it returns not found, then:

master# /usr/sbin/fncreate -t org org//

2,  Create the printer context on the nisplus master.

master# /usr/sbin/fncreate_printer -f /etc/printers.conf
thisorgunit/service/printer

        Note: use this exact syntax

3,  Modify/create the printers.conf file on the master.
        syntax:
master# /usr/bin/lpset -n fns -a bsaddr=(printserver host),(printername)
(printername)

        Where:
                (pinterserver hosts) is the machine where the printer is 
                   physically resident.
                (printername) is the exact printer name.

        eg.
master# /usr/bin/lpset -n fns -a bsdaddr=machine1,printer1 printer1

4, Printer bindings (contexts) in NIS+ can be removed using the fndestroy 
   command.

Refer to the "NIS+ and FNS Administration Guide" for more detailed information.


NOTE: You must be running Sun Soft Print Client (SSPC) to centrally administer
your printers.conf via NIS+.  SSPC is NOT bundled with the generic
installation of 2.5.1 and below.  You *must* have a functional SSPC print
environment PRIOR to configuring this table.  SSPC is the default
print environment as of 2.6.

3.19 How to remove a replica 

It is better to do this if the replica is still available but it can
still be done if it is down.

First use `nisstat -H <replicaname>` to find out which directories
that replica is serving.  This will usually just be org_dir, groups_dir
and possibly ctx_dir if FNS has been setup.

For each of the directories servered by the replica removing the directory
objects using nisrmdir, eg:

The domain object should bre removed last.
    
     root-master# /usr/bin/nisrmdir -f -s <replica> org_dir.domainname.
     root-master# /usr/bin/nisrmdir -f -s <replica> groups_dir.domainname.
     root-master# /usr/bin/nisrmdir -f -s <replica> domainname.

   Note: Use ending dots and do the domainname last.

The -f flag forces the operation and should only ever be used if the
replica is actually down or otherwise unable to contact the master.

Usually replicas are a member of the admin group, this is the default unless
it has been manually removed.  We should now remove the replica from the
admin group.

      root-master# /usr/bin/nisgrpadm -r admin.domainname.
<replica>.domainname.

If the replica is available then re-initialise it as a NIS+ client, this
is the ONLY safe way to tidy up the /var/nis/data directory if the replica
is becoming a NIS+ client of the same domain it was previously serving.  
This also ensures that rpc.nisd is killed off and nis_cachemgr is properly
restarted with a new NIS_COLD_START file that doesn't reference itself as
a NIS+ server.

3.20 How to re-initalize the Coldstart file 

There are lots of reasons why there may be errors reading in the cold
start file. If a quick truss doesn't help you then you are probably
better off reinitialising the cache. This should be all you need to
do:

        kill the nis_cachemgr   <-- get rid of the current process
        # /usr/sbin/nisinit -c -H server        <-- get a new cold start file
        # /usr/sbin/nis_cachemgr -i             <-- start using it and throw
out the old cache

You shouldn't need to do anything else. If there still are error reading 
the file, then perhaps there is a more fundamental problem with your
NIS+ domain.

4.0 Some Frequently Asked Questions

4.1: Miscellaneous Questions 

Q1: What are the main features of NIS+?
Q2: What new functionality does NIS+ have?
Q3: What are the differences between NIS and NIS+?

A: NIS name space is a flat namespace, which means that it does not
support subdomains. Under NIS, only one domain is accesible from a
given host. In NIS+, the namespace is hierarchical. This hierarchical
structure is similar to the UNIX filesystem structure. Since the NIS+
namespace is hierarchical, it can be configured to conform with the
logical hierarchy of the organization. This means that you can create
subdomains for different levels of organizations.

In NIS, even for a small change in the map, the master server needs to
push the whole map to the slave servers. Whereas, in NIS+, the
database updates are incremental. This means that only changes in the
map are replicated to replica servers. Therefore, NIS+ database
updates are more efficient and less time consuming.

Another important difference between NIS and NIS+ is server binding.
In NIS, clients are hard bound to a specific server. During the bootup
time, the ypbind process on the client side binds to a specific
server. However, the NIS+ client library is not a seperate process.
In NIS, the ypwhich command can tell you to which specific server the
client is bound to, but that is not possible in NIS+. In other words,
the binding in nis+ is soft binding.

NIS maps can be searched by only one predefined searchable column.
NIS+ tables allow more than one searchable columns.

NIS supports UNIX groups and netgroups. NIS+ also supports the concept
of NIS+ group. One or more NIS+ users can be grouped together into a
NIS+ group. Multiple NIS+ groups can be defined, each with different
access and modification rights to the NIS+ namespace.

NIS+ also has much improved security:

NIS does not support authentication, authorization and secure RPC,
whereas NIS+ supports authentication, authorization and secure RPC.

Q: What is my network passwd?

A: In most cases, your network passwd should be the same as your login
passwd. When NIS+ is just getting setup, network passwds are often set
to 'nisplus'.

Q: Why can't I have machines and users with the same name?

A: All machines and users must have credentials created for them. If
you have a machine and a user with the same name, only one of them
will be able to have credentials. In case of a naming conflict of this
sort, you should change the machine's name  you may have to recreate
credentials for the user and machine afterwards:

  %% /usr/lib/nis/nisclient -c user
  %% /usr/lib/nis/nisclient -c machine


4.2: NIS+ Setup Problems 

Q: Why does nisserver fail when I run it, as described in Section 3.4?

A: If for some reason the nisserver script fails, check the error
message. It will give some ideas about the failure. Another option is
to do the configuration manually using nisinit, and nissetup, as is
described in the Name Services Administration Guide. This will give an
idea about which step the script is failing in. This can help to
diagnose the problem better. If the nisinit -r step hangs, then check
if you are running DNI. The DNI installation modifies /etc/netconfig
file with this line:

  nsp   tpi_cots_ord    -       decnet  nsp     /dev/nsp       
/usr/lib/straddr.so

If you comment this line out and then run the script again, it will
work correctly.

4.3: User Login Problems 

Q: Why do I get the following error on login:

  "Password does not decrypt secret key for ..."

A: This means that the user's login password and network password do
not match. After login, the user must run keylogin to get their NIS+
credentials:

  %% /usr/bin/keylogin

They will have to type their NIS+ network password at the keylogin
prompt. This may very well be 'nisplus' if the user is logging in for
the first time. Afterwards, the user should run chkey, to synch his
login and network passwds:

  %% /usr/bin/chkey -p

They have to again type their NIS+ network password (nisplus) and
then their login password (password typed in when logging into
system)

Q: Why do I get the following error on login:

  "/usr/bin/passwd:  <user> does not exist"
  "Connection closed by foreign host."

A1: This can be the result of selecting "cleared until first login" in
admintool, when you initially create a user. You should instead select
a normal password for a user when you create his account.

A2: If you are trying to use password aging, you must install the
password aging point patch, as noted in Section 5.0.

Q: Why can't I log in via xdm?

A: This is a known bug. Sections 5.3 and 5.4 list the patches for this
problem.

4.4: NIS+ Lookup Problems 

Q: Why do I get inconsistant results when I do certain NIS+ lookups?

A: In NIS+, the server binding is a soft binding. That is, every query
may be accessing a different server. Therefore, if a replica is not in
sync with the master, clients will get inconsistant information for
every query. When you get inconsistant information for queries run the
snoop command (see Section 2.3) to find out which server is providing
the incorrect information.

5.0: Patches 

The following is the list of all of the NIS+ patches for 5.3 and 5.4.
If you are having NIS+ problems, installing the patches is a good
place to start, especially if you recognize the general symptoms noted
below.

In order for a machine to be stable, all of the recommended patches
should be installed as well. The list of recommended patches for your
operating system is available from sunsolve.sun.com

5.1: Solaris 2.x NIS+ Patches 

Solaris 2.3 NIS+ Patches

101318 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)

  An important patch that should be installed on any machines. Since
  it contains a large number of NIS+ fixes, it is an absolute
  necessity for a NIS+ machine.

101384 SunOS 5.3: Admintool Jumbo patch

  Fixes a large number of bugs related to NIS+ and admintool. This
  patch must be installed if you use admintool to modify your NIS+
  databases.

101582 SunOS 5.3: POINT PATCH: Password aging & NIS+ don't work (together)

  This optional patch should be installed only if you want to to
  combine NIS+ and password aging.

101736 SunOS 5.3: nisplus patch

  Fixes errors in the NIS+ library. Should be installed on all NIS+
  machines.

102447 OpenWindows 3.3: xdm cannot be used on NIS+ networks

  Corrects a bug which prevented NIS+ users from logging in via xdm.


5.2: Solaris 2.4 NIS+ Patches

101945 SunOS 5.4: jumbo patch for kernel

  An important patch that should be installed on any machines. Since
  it contains a large number of NIS+ fixes, it is an absolute
  necessity for a NIS+ machine.

102294 OpenWindows 3.4: xdm cannot be used on NIS+ networks

  Corrects a bug which prevented NIS+ users from logging in via xdm.

101973 SunOS 5.4: fixes for libnsl and ypbind

  This is a required patch for nis+.

102277 SunOS 5.4: nss_nisplus.so.1 fixes

102153 SunOS 5.4: Admintool Jumbo patch

102273 SunOS 5.4: nisupdkeys -a does not deal properly with multi-homed systems

102336 SunOS 5.4: POINT PATCH: 1091205 - Password aging & NIS+ don't work

  This optional patch should be installed only if you want to to
  combine NIS+ and password aging.

102521 SunOS 5.4: rpc.nisd leaks one file descriptor each checkpoint request
               *** OBSOLETED BY 101973-15 or later

102677 SunOS 5.4: nispasswd coredumps in mailoc with SEGV

102608 SunOS 5.4: nisaddent and nispopulate fixes

103064 SunOS 5.4: nis_cachemgr fixes

5.3:  Solaris 2.5 NIS+ Patches

103093 SunOS 5.5: kernel jumbo patch (2170949 bytes) 
103708 SunOS 5.5: rpc.nisd_resolv rebuild for BIND 4.9.3 
103279 SunOS 5.5: nscd breaks password shadowing with NIS+ 
103266 SunOS 5.5: nissetup default permissions for password 
   table not secure 
103187 SunOS 5.5: SunOS 5.5: libc, libnsl, libucb, 
   nis_cachemgr and rpc.nisd patch 
103661 SunOS 5.5: nisaddent patch
103774 SunOS 5.5: nistbladm patch
103790 SunOS 5.5: nss_nisplus.so.1 patch
104000 SunOS 5.5: nispasswdd fixes

5.4:  Solaris 2.5.1 NIS+ Patches

103640 SunOS 5.5.1: kernel patch 
103686 SunOS 5.5.1: rpc.nisd_resolv patch 
103680 SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3 
103612 SunOS 5.5.1: libc, libnsl, libucb, nis_cachemgr
       and rpc.nisd patch
103643 SunOS 5.5.1: /usr/lib/nis/nisaddent fixes
103770 SunOS 5.5.1: nistbladm patch
103785 SunOS 5.5.1: nss_nisplus.so.1 patch
103995 SunOS 5.5.1: rpc.nispasswdd patch
104255 SunOS 5.5.1: POINT PATCH: 1257084 - /usr/lib/nss_nis.so.1


5.5:  Solaris 2.6 NIS+ Patches


105401 SunOS 5.6: libnsl and NIS+ commands patch 
105552 SunOS 5.6: /usr/sbin/rpc.nisd_resolv patch 
105743 SunOS 5.6: /usr/lib/libxfn.so.2 patch 
105562 SunOS 5.6: chkey and keylogin patch 
105564 SunOS 5.6: /kernel/misc/rpcsec patch 
105403 SunOS 5.6: /usr/lib/netsvc/yp/ypbind patch 
105216 SunOS 5.6: /usr/sbin/rpcbind patch 
106044 SunOS 5.6: /usr/lib/nss_nisplus.so.1 patch

6.0: Known Bugs & RFEs  

There are no known open issues on NIS+.

7.0 References

7.1: Important Man Pages 

  chkey
  keylogin
  newkey
  nis
  nis_cachemgr
  nisaddcred
  niscat
  nisaddent
  nischgrp
  nischown
  nischttl
  nisclient
  nisdefaults
  nisgrep
  nisgrpadm
  nisinit
  nislog
  nisls
  nismatch
  nismkdir
  nisping
  nispopulate
  nisrm
  nisrmdir
  nisserver
  nistbladm
  nisudpkeys
  rpc.nisd

7.2: Sunsolve Documents 

There are a number of Sunsolve documents concerning NIS+ The ones
listed below either contain some additional information not in this
document, or reference rare problems, or rare how-tos.

7.2.1: FAQs

1012   NIS+ questions

7.2.2: Infodocs

2216   NIS+ questions
11742  How to convert a NIS+ root replica server to a root mas

7.2.3: SRDBs

5874   nis+ database recovery
6285   change of root passwd on NIS+ server breaks authenticat
6487   differences between NIS and NIS+
6640   why does NIS+ require passwords
6616   is it possible to revert to NIS
7202   cannot change NIS passwords served by NIS+ servers
10448  Changing the NIS+ master server.
10941  NIS+ error messages
10951  NIS+ servers unreachable
11728  Changing a NIS+ server's IP address.

7.3: Sun Educational Services 

NIS+ concepts and administration offered by SUNED (contact 1-800 number to get 
more information)

7.4: Solaris Documentation 

_Name Services Administration Guide_, part #801-6633-10
_Name Services Configuration Guide_, part #801-6635-10

7.5: Third Party Documentation 

_All About Administering NIS+_, by Rick Ramasey,  Prentice Hall

7.6: RFCs 

There are no RFCs on NIS+.

8.0 Supportability  

Sun is not responsible for the initial configuration of your
NIS+ environment. In addition, Sun cannot diagnose your NIS+
performance problems, or suggest NIS+ tuning guidelines.

We can help resolve problems where NIS+ is not behaving correctly, but
in such cases the contact must be a system administrator who
understands how the NIS+ domain is setup.

9.0 Additional Support  

For initial configuration, or NIS+ performance tuning guidelines,
please contact your local SunService office for possible consulting
offerings. Sun's Customer Relations organization can put you in touch
with your local SunIntegration or Sales office. You can reach Customer
Relations at 800-821-4643.

Top

SunWeb Home SunWeb Search SunSolve Home Simple Search

Sun Proprietary/Confidential: Internal Use Only
Feedback to SunSolve Team