SUMMARY: How NIS+ works

From: venkatesh <venkatesh_ch_at_yahoo.com>
Date: Fri Aug 24 2001 - 06:53:17 EDT
 Here is the response from all the managers. Thanks a
lot for the responses.
 -Venkatesh


From: Adrian Stovall  
www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html 

www.muc.de/~ralfl/nisplus/faq.html 


or go to www.google.com and type in "NIS+ FAQ"

HTH


From: Daniel Tate  


You may have already heard this suggestion. 

1: Buy some Tylenol.  Extra strength, gelcaps. 
2: Expense this book, if you can:
http://www.amazon.com/exec/obidos/ASIN/0133095762/qid=998590191/sr=2-1/ref=aps_sr_b_1_1/002-4724014-8248843

I'm not sure anyone on the planet knows everything
about NIS+.. IMHO, it's rather sloppy.   There are a
few NIS+ FAQ's laying around.. 

http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html

http://docs.sun.com/ab2/coll.47.8/NISQSTART/ 
http://docs.sun.com/ab2/coll.47.8/NETNAME 


From: gcarr@lanl.gov (Gary Carr)  



http://docs.sun.com has a full set of Sol 8
documentation. There is 
NIS+ 
info scattered throughout the System Administration
documentation. I'e 
found "Solaris Naming Setup and Configuration Guide",
and "Solaris 
Naming 
Administration Guide" the most useful.

http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html
is an online 
FAQ 
for NIS+.

http://www.sunsolve.com/ has quite a few "Info Docs"
on NIS+. Info Doc 
11988, "NIS+ PSD/FAQ" is a good general reference. I
don't know if you 
can 
get to Info Docs if you cannot login to the site.

I think there was a fairly extensive set of notes on
NIS+ sent to this 
mailing list at one time, I've misplaced my copy of
it, but you might 
try 
the archives.

There are, of course, the man pages for all the nis...
commands.


This has everything !!!!!!!

From: "Karl Vogel"   

---------------------------------------------------------------------------
#!/bin/sh
# Cleanly repopulate the hosts and netgroup tables.
# Running nispopulate isn't enough if we delete
entries from either.

PATH=/bin:/usr/sbin:/usr/lib/nis
NIS_PATH=org_dir.$:$
export PATH NIS_PATH

umask 027
tag=`basename $0`

# don't forget the trailing dot
domain="YOUR.DOMAIN.GOES.HERE."

alltables="hosts netgroups"
yes='y
y'

for table in $alltables
do
    clear="nistbladm -R $table"
    populate="nispopulate -F -p /etc -d $domain
$table"
    echo "running $clear ..."
    logger -t $table "$clear"
    $clear

    echo "running $populate ..."
    logger -t $table "$populate"
    echo "$yes" | $populate
done

logger -t $tag "checkpointing NIS logs"
nisping -C org_dir
logger -t $tag "done"
exit 0

---------------------------------------------------------------------------
INFODOC ID: 11988
SYNOPSIS: NIS+ PSD/FAQ
DETAIL DESCRIPTION:
SunService Tip Sheet for SUN NIS+
Revision: 1.3
Date: May 24, 1996

Mail to: support@network.East.Sun.COMMail to:
support@network.East.Sun.COM

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

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: References
    5.1: Important Man Pages
    5.2 Sunsolve Documents
    5.3 Sun Educational Services
    5.4: Solaris Documentation
    5.5: Third Party Documentation
    5.6: RFCs


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 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
  separated 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 entries.
  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:

    % niscat passwd.org_dir

  If the user can see the encrypted passwords, then
the user is
  authenticated.  If the user sees *NP* in place of
encrypted passwords,
  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:

    % niscat cred.org_dir

  You can create credentials for a user with
nisclient:

    % 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:

    % niscat passwd.org_dir

  You can also examine the object properties of a
table:

    % 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:

    % 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 environment, 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 important 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 these 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# nisserver -v -r -d domain_name

  (where domain_name is your NIS+ domain.)

  Afterwards, you will want to populate the NIS+
tables from a set of
  ASCII files.  It is a good idea to create a separate
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             netmasks
    auto_home           networks
    auto_master         passwd
    bootparams          protocols
    cred                rpc
    group               services
    hosts               timezone
    netgroups

  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# 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+ environment, login
explicitly runs
  keylogin and so, if the network passwd is same as
the login passwd,
  users don't have to do a separate 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% nisls
    root-master% 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# 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# 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# rpc.nisd

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

    root-master# 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# nisping domain_name.
    root-master# nisping org_dir.domain_name.
    root-master# 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# 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# 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# 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

  Unfortunately, there is no easy way to configure the
root server again
  when the IP address is changed.  This is because the
clients maintain
  the server's IP address in their cold start file,
and the server has
  the old IP address in its cache.  You must totally
reinitialize the
  Root Server for an IP address change.

  The best way to do this is first dump the NIS+
tables to ASCII files
  using the nisaddent command:

    root-master# cd /var/tmp/nisfiles
    root-master# nisaddent -d aliases > aliases
    root-master# nisaddent -d bootparams > bootparams
    root-master# nisaddent -d ethers > ethers
    root-master# nisaddent -d group > group
    root-master# nisaddent -d hosts > hosts
    root-master# nisaddent -d netgroup > netgroup
    root-master# nisaddent -d netid >
    root-master# nisaddent -d netmasks > netmasks
    root-master# nisaddent -d networks > networks
    root-master# nisaddent -d passwd > passwd
    root-master# nisaddent -d protocols > protocols
    root-master# nisaddent -d publickey > publickey
    root-master# nisaddent -d rpc > rpc
    root-master# nisaddent -d services > services
    root-master# nisaddent -d shadow > shadow
    root-master# nisaddent -d timezone > timezone
    root-master# nisaddent -d -t auto_home.org_dir
key-value > auto_home
    root-master# nisaddent -d -t auto_master.org_dir
key-value > auto_master

  Then, you must clean out old NIS+ info:

    root-master# cp /etc/nsswitch.nisplus
/etc/nsswitch.conf
    root-master# /etc/init.d/rpc stop
    root-master# rm -f /etc/.rootkey
    root-master# rm -rf /var/nis/*
    root-master# /etc/init.d/rpc start

  And finally, you can reconfigure your NIS+ server,
as described in
  Section 3.2.

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:

    # nisgrpadm -a admin.domain_name. joe
    # 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.

3.9: How to Change a NIS+ user passwd

  The passwd for a normal user can be changed by them
running the
  nispasswd command:

    % nispasswd

  This updates the password in the passwd table, and
also updates the
  credential table.  Root can change passwords for
users by running:

    # 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:

    # passwd

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

    # chkey -p

  Finally, do keylogin -r to update /etc/.rootkey file
with the new
  private key for the server:

    # keylogin -r

  This changes the private key for the server, while
the public key
  remains the same.  This is necessary because clients
use server's
  public key for authentication.

  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:

    % nisaddcred -p uid -P principal-name local
    % 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 test has 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:

   % 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:

    % niscat -o group-name.groups_dir.domain_name.

  The nisgrpadm command creates, deletes and performs
miscellaneous
  administration operations on the nis+ groups.

  To create a group:

    % nisgrpadm -c group-name.domain_name.

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

    root-master# nisdefaults
    principal 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:

    % nisgrpadm -d group-name.domain_name.

  To list the group members:

    % nisgrpadm -l group-name.domain_name.

  To add members to a NIS+ group:

    % nisgrpadm -a group-name member

  To remove members from a NIS+ group:

    % nisgrpadm -r group-name member

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

    % 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:

    % 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:

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

  (assuming your domain_name is example.com)

  To delete a table:

    % nistbladm -d table-name

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

    % nistbladm -d computers.example.com.

  For more info about adding entries or modifying
entries, 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:

    % niscat -o table-name

  Or:

    % niscat -o entry

  To display the contents of a table:

    % 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 methods 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:

    % nisaddent -m -f filename table-type

  For example:

    % 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:

    % nisaddent -d hosts > /tmp/hosts
    % vi /tmp/hosts
    % nisaddent -r -f /etc/hosts hosts

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

  Example:

    % nisaddent -d passwd > /tmp/passwd
    % nisaddent -d shadow > /tmp/shadow
    % vi /tmp/passwd
    % nisaddent -r -f /tmp/passwd passwd
    % 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 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
  /var/nis, to make sure that you can recover in the
case of a massive
  failure.

3.17: How to Remove NIS+

  If you wish to remove NIS+, you should run the
following commands on
  all of your NIS+ machines:

    # cp /etc/nsswitch.files /etc/nsswitch.conf
    # /etc/init.d/rpc stop
    # rm -f /etc/.rootkey
    # rm -rf /var/nis/*
    # rm -rf /etc/defaultdomain
    # /etc/init.d/rpc start

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

3.18: How to define the printer table in NIS+

  Run the following command, as root, to set up the
NIS+ printers
  table definition:

  # nistbladm -c -D access=n+r,o+rmcd,g+rmcd,w+r
printers
  printer_name=S,o+rmcd,g+r,w+r
printer_host=S,o+rmcd,g+r,w+r
  description=,o+rmcd,g+r,w+r
printers.org_dir.`domainname`.

  Once you have set up this definition, you can
confirm the permissions
  are set properly:

   # niscat -o printers.org_dir
   Object Name   : printers
   Owner         : ppp.hans.com.
   Group         : admin.hans.com.
   Domain        : org_dir.hans.com.
   Access Rights : r---rmcdrmcdr---
   Time to Live  : 12:0:0
   Object Type   : TABLE
   Table Type          : printers
   Number of Columns   : 3
   Character Separator :
   Search Path         :
   Columns             :
       [0]     Name          : printer_name
               Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
               Access Rights : ----rmcdr---r---
       [1]     Name          : printer_host
               Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
               Access Rights : ----rmcdr---r---
       [2]     Name          : description
               Attributes    : (TEXTUAL DATA)
               Access Rights : ----rmcdr---r---

  After this, Admintool or the nisaddent command can
be used to populate
  the printers table.

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
accessible 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 separate
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 passwords
  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:

    % nisclient -c user
    % 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:

    % 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 synchronize
  his login and network passwords:

    % 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:   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 inconsistent 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
inconsistent information
  for every query.  When you get inconsistent
information for queries
  run the snoop command (see Section 2.3) to find out
which server is
  providing the incorrect information.

5.0 References

5.1: Important Man Pages

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

5.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.

5.2.1: FAQs

  1012   NIS+ questions

5.2.2: Infodocs

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

5.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.


---------------------------------------------------------------------------
Date: Thu, 31 Jul 1997 10:21:35 -0700 (PDT)
To: sun-managers@ra.mcs.anl.gov
Subject: SUMMARY: NIS+ tips
Message-ID: 
From: Stuart Kendrick 

I've been wrestling with NIS+ for a couple years now,
and the sun-managers
list has been helpful during the steep parts of my
learning curve.  Thank you
to the many correspondents who have helped me.

Here is a compilation of what I know about NIS+; I
hope this helps others.
This is the document to which I refer whenever I need
to refresh my memory
about how I've constructed our NIS+ space and how to
monitor it, manage it,
trouble-shoot it.

My understanding is incopmlete, please be advised that
my notes may simply
be wrong, incorrect, bogus.  This is not a clean
document, merely
notes to myself.  Take it all with salt.

Corrections, insights, suggestions welcome.

Special thanks to Marc Gibian and Martin Trampler for
their thorough
explanations.

--sk
Stuart Kendrick
Network Services
FHCRC


NIS+ in CNS

Overview
Support
Building the NIS+ domain from scratch
Changing your password under NIS+
Fixing Credential Problems
Adding/Modifying Users
Netgroups
Administering the NIS+ tables
Tuning the NIS+ tables
Restoring NIS+ after tragedy
Maintaining the NIS+ space
Troubleshooting
Removing a NIS+ client
Removing a NIS+ replica
Removing the NIS+ space entirely
Useful NIS+ scripts
Sun NIS+ documents


Overview
This document is a compilation of notes I made to
myself while I learned NIS+.

I started working with NIS+ under Solaris 2.3.  Under
Solaris 2.4.  And under
Solaris 2.5.1 (I skipped 2.5).  I would describe NIS+
as broken until 2.5.1.
It is possible that patches delivered since have fixed
the brokenness I
discovered under 2.3 and 2.  4.

At points within this document, I instruct the
operator to "wait a few
minutes".  Alternatively, one can type "nisping
org_dir" instead; this
command instructs nis_cachemgr to propagate changes
immediately.

Support
Read all the NIS+ FAQs on SunSolve.  Subscribe to the
sun-managers list.
Make extensive use of your Sun Service contract.

Building the NIS+ domain from scratch

In this example, I assume that the root master is
rmaster.

Note that in NIS+ the absence or inclusion of a
trailing dot is important.

Whenever messing with NIS+, keep a separate window to
that box open with a
"tail -f /var/log/syslog" running.

Create the root master

On rmaster:
-Create a file called /etc/defaultdomain containing
the single line "fhcrc.org"
-reboot.
-nisserver -r -v -d fhcrc.org. -g admin.fhcrc.org.
-Edit /etc/nsswitch.conf and modify as necessary:

# /etc/nsswitch.conf 7/10/97 --sk
#
# "hosts:" and "services:" in this file are used only
if the
# /etc/netconfig file has a "-" for nametoaddr_libs of
"inet" transports.

# The next two lines enable the use of netgroups
passwd:         compat
passwd_compat:  nisplus

# This is the standard nsswitch.conf line, which does
not support netgroups
# Files *must* precede nisplus
#passwd:     files nisplus

# I don't currently include the standard groups in
NIS+, so "files" is a
# necessary component of this line
group:      nisplus files

# According to Sun, files *must* go first to allow the
machine to boot
hosts:      files nisplus dns

# Standard tables
services:   nisplus files
networks:   nisplus files
protocols:  nisplus files
rpc:        nisplus files
ethers:     nisplus files
netmasks:   nisplus files
bootparams: nisplus files

# These two are pure NIS+ constructs, ergo no mention
of files
publickey:  nisplus
netgroup:   nisplus

# Standard tables.  The mail relays must have files
before nisplus ...
# so all our boxes do, in order to standardize
nsswitch.conf
automount:  files nisplus
aliases:    files nisplus

# At this point, I don't use NIS+ to propagate
sendmail variables; rather,
# I manually copy sendmail.cf
sendmailvars:   files


- Populate the tables (typically,
/opt/local/config/files contains the latest
nisdump ...  so you won't need to make this directory
and copy files to it.
But there again, if you are starting entirely from
scratch, on a brand-new
box, you will.)

-mkdir /opt/local/config/files

-Copy the following files to /opt/local/config/files:
auto_home, auto_master,
group, netmasks, networks, protocols, rpc, services,
timezone.  I skip
ethers and bootparams because we don't use them. 
Leave out hosts and
aliases for now.  Edit passwd and group and remove all
the system accounts
(root et al).  Leave "sysadmin" in group ... 
currently "sysadmin" includes
four UIDs: dweeb1, dweeb2, dweeb3, dweeb4

- nispopulate -v -F -d fhcrc.org. -l 1124cns5063 -p
/opt/local/config/files 

The ending message will say:
"nispopulate failed to populate the following tables:
 hosts mail_aliases"
This is fine.

-copy rmaster:/home/hostops/etc/hosts and
rmaster:/home/mailops/etc/aliases.nisplus to
/opt/local/config/files/hosts
and /opt/local/config/files/aliases.  Also, copy the
passwd and shadow files
to /opt/local/config/files

-verify that no host name is the same as a username in
imported in the
nispopulate step above.  NIS+ does not like seeing
usernames and hostnames
the same (both contain entries in cred.org_dir ... 
and allowing users and
hosts to share the same name would introduce ambiguity
into this table.)

-nisaddent -v -f /opt/local/config/files/hosts hosts
-nisaddent -v -f /opt/local/config/files/aliases
aliases
-nisaddent -v -f /opt/local/config/files/passwd passwd
-nisaddent -v -f /opt/local/config/files/shadow shadow

[I don't use "nispopulate" to import hosts and aliases
into NIS+ because
nispopulate adds *credentials* for all hosts and
aliases ...  and I don't
want to add credentials for *everybody*, just for the
users in passwd.
nisaddent just imports data into tables; it doesn't
mess with credentials.
I don't include passwd and shadow because nispopulate
seems to be broken at
the moment when it comes to creating credentials for
users ...  I do this
manually below.]

I am having trouble delivering NIS+ credentials and
synced NIS+/login
passwords.  I use the following procedure: I run the
following for each
username (e.g.  dweeb1, dweeb2, dweeb3, dweeb4):

nisclient -c -v -d fhcrc.org. -l 1124cns5063 username

Each user must then log in and sync their login
password (what they type
when they log in) with the Secure-RPC password
(1124cns5063).  The first
procedure ought to work ...  but doesn't seem to at
the moment.  The second
procedure always works.

(a)  Type "nisclient -u"
(b)  Type "keylogin", then "chkey -p"

nischmod n+r admin.groups_dir.fhcrc.org.

[This fixes a permission problem - the default install
doesn't give read
permission to group nobody ...  yet this is necessary
before one can list
or modify group admin.]

-nisgrpadm -a admin.fhcrc.org.  dweeb1.fhcrc.org. 
dweeb2.fhcrc.org.
dweeb3.fhcrc.org.  dweeb4.fhcrc.org.

[This adds these four users to the NIS+
"admin.fhcrc.org."  group.  Members
of this group are allowed to modify the NIS+ tables. 
Use "nisgrpadm -l
admin.fhcrc.org."  to list the members of a group. 
When a machine is listed,
that means that the root UID on that machine is a
member of the group.]

-nisping -C fhcrc.org.

-nislog | more
rmaster{root}: nislog | more
NIS Log printing facility.
NIS Log dump :
        Log state : STABLE.
Number of updates    : 3
Current XID          : 5258
Size of Log in bytes : 516
*** UPDATES ***
@@@@@@@@@@@@@@@@ Transaction @@@@@@@@@@@@@@@@@@
#00000, XID : 5256
Time        : Thu Nov 21 14:36:39 1996
 
Directory   : groups_dir.fhcrc.org.
Entry type : UPDATE time stamp.
Entry timestamp : Thu Nov 21 14:36:39 1996
Principal       : rmaster.fhcrc.org.
Object name     : groups_dir.fhcrc.org.
.................. Object .....................
Object Name   :
Directory     : groups_dir.fhcrc.org.
Owner         :
Group         :
Access Rights : ----------------
Time to Live  : 0:0:0
Creation Time : Wed Dec 31 16:00:00 1969
Mod. Time     : Wed Dec 31 16:00:00 1969
Object Type   : NONE
...............................................
@@@@@@@@@@@@@@@@ Transaction @@@@@@@@@@@@@@@@@@
#00001, XID : 5257
Time        : Thu Nov 21 14:26:27 1996
 
Directory   : org_dir.fhcrc.org.
Entry type : UPDATE time stamp.
Entry timestamp : Thu Nov 21 14:26:27 1996
Principal       : rmaster.fhcrc.org.
Object name     : org_dir.fhcrc.org.
.................. Object .....................
Object Name   :
Directory     : org_dir.fhcrc.org.
Owner         :
Group         :
Access Rights : ----------------
Time to Live  : 0:0:0
Creation Time : Wed Dec 31 16:00:00 1969
Mod. Time     : Wed Dec 31 16:00:00 1969
Object Type   : NONE
...............................................
@@@@@@@@@@@@@@@@ Transaction @@@@@@@@@@@@@@@@@@
#00002, XID : 5258
Time        : Thu Nov 21 14:36:33 1996
 
Directory   : fhcrc.org.
Entry type : UPDATE time stamp.
Entry timestamp : Thu Nov 21 14:36:33 1996
Principal       : rmaster.fhcrc.org.
Object name     : fhcrc.org.
.................. Object .....................
Object Name   :
Directory     : fhcrc.org.
Owner         :
Group         :
Access Rights : ----------------
Time to Live  : 0:0:0
Creation Time : Wed Dec 31 16:00:00 1969
Mod. Time     : Wed Dec 31 16:00:00 1969
Object Type   : NONE
...............................................

This is what the nislog should look like.  The key
items are in front:
...
Log state : STABLE.
Number of updates    : 3
Current XID          : 5258
Size of Log in bytes : 516
...

Log state should be STABLE.  If it is something else,
either the master is
busy performing updates (?)  or something is wrong.

Number of updates should be "3"; this implies that
there are no updates.
Size of log in bytes:  516

If these last two parameters are anything else, then
the master has updates
waiting to be checkpointed (removed) from its logs. 
"nisping -C" should
flush these updates.  If it doesn't, then either a
replica is unavailable
or something is wrong.


-Done creating the server

 
Users who would like to authenticate against NIS+ --
typically, dweeb1, dweeb2,
dweeb3, and dweeb4, should log on and see whether or
not an error message about
not decrypting the public key appears.  If it appears,
run nisclient as below.
If it doesn't .  ..  then the nispopulate process
successfully created NIS+
credentials.  I don't understand why this works
sometimes and not other times.

-To create credentials for users -- public/prviate key
combinations -- each
user needs to run the following.  When prompted for
the "Secure RPC network
password", s/he needs to type "1124cns5063"

-nisclient -u

Create NIS+ client machines

To create a NIS+ client machine ("guru", in this
example), do the following:

-Log onto any machine in the NIS+ space
-nisaddcred -p unix.guru@fhcrc.org -P guru.fhcrc.org.
des
-Log onto the client-to-be as root
-Verify that /etc/inet/hosts contains the line:
140.107.10.102 rmaster
-Create a file called /etc/defaultdomain containing
the single line "fhcrc.org"
-nisclient -i -d fhcrc.org. -h rmaster
-Edit /etc/nsswitch.conf as appropriate
reboot
-/usr/sbin/rpc.nisd
 
[On subsequent reboots, rpc.nisd will load
automatically.]


Create NIS+ replica machines

To convert a NIS+ client into a NIS+ replica server,
do the following:

Log onto the master

-nisserver -R -v -d fhcrc.org. -h client
[Client must be the box's node name, e.g.  not
fully-qualified.  This is
because we carry only node names in our NIS+ tables,
e.g.  we don't populate
them with the fully-qualified versions of each name.]

-On the client, perform the following:
-keylogin -r

-Back on the master, type the following commands. 
Pause in between each,
watching syslog on both machines.  Wait for the nisd
messages to stop
before continuing with the next command. 
Semi-reassuring messages which
include strings like "Finish handshake" and "1
updates, 0 errors" indicate
successful completion of a step.  The step which
requires the longest to
complete is the "nisping org_dir.fhcrc.org" command,
which will use messages
like "update_directory: 3000 objects, still running"
to indicate progress.
Do NOT reboot or otherwise kill NIS+ processes during
this procedure.
Under Solaris 2.4, doing so incurred painful
consequences.

-nisping fhcrc.org.
-nisping groups_dir.fhcrc.org.
-nisping org_dir.fhcrc.org.
-nisping -C fhcrc.org.

Here is a sample of the entire experience, from the
master's syslog:

{nisping fhcrc.org}

Nov 25 13:51:28 rmaster nisd[400]: killing read only
child: pid #919
Nov 25 13:55:18 rmaster nisd[1055]: nis_dump_svc:
sending full dump of
fhcrc.org. to guru.fhcrc.org.
Nov 25 13:55:18 rmaster nisd[1055]: nis_dump_svc: good
dump of fhcrc.org., 2
totalobjects.
Nov 25 13:55:22 rmaster nisd[1055]: nis_dump_svc:
Finish handshake returned
RPC: Timed out

{nisping org_dir.fhcrc.org.}

Nov 25 13:55:44 rmaster nisd[1057]: nis_dump_svc:
sending full dump of
org_dir.fhcrc.org. to guru.fhcrc.org.
Nov 25 13:59:05 rmaster nisd[1057]: nis_dump_svc: good
dump of
org_dir.fhcrc.org.,4924 total objects.
Nov 25 13:59:08 rmaster nisd[1057]: nis_dump_svc:
Finish handshake returned
RPC: Timed out
{nisping groups_dir.fhcrc.org.}

Nov 25 13:59:34 rmaster nisd[1059]: nis_dump_svc:
sending full dump of
groups_dir.fhcrc.org. to guru.fhcrc.org.
Nov 25 13:59:34 rmaster nisd[1059]: nis_dump_svc: good
dump of
groups_dir.fhcrc.org., 1 total objects.
Nov 25 13:59:37 rmaster nisd[1059]: nis_dump_svc:
Finish handshake returned
RPC: Timed out

{nisping -C fhcrc.org.}

Nov 25 14:07:50 rmaster nisd[400]: killing read only
child: pid #1061


Changing your password under NIS+.

This is a pain in the butt

Don't bother with "nispasswd", under Solaris 2.5 and
above, "passwd" works just fine.

guru% passwd
passwd:  Changing password for dweeb4
Enter login(NIS+) password:
New password:
Re-enter new password:
        NIS+ password information changed for dweeb4
 
The credential information for dweeb4 will not be
changed.
        User dweeb4 must do the following to update
his/her
        credential information:
        Use NEW passwd for login and OLD passwd for
keylogin.
        Use "chkey -p" to reencrypt the credentials
with the
        new login passwd.
        The user must keylogin explicitly after their
next login.
 
guru%

-Enter your current password when prompted for "Enter
login(NIS+) password:"
-Log out of *all* sessions to guru
-Wait a few minutes
-Log back in, use your new password
-You will see the message "Password does not decrypt
secret key for
unix.18602@fhcrc.org."
-Use the keylogin procedure to authenticate yourself
to NIS+

guru% keylogin
Password:
guru%

-Use your *old* password when challenged by keylogin
-Use the "chkey" procedure to sync your login and NIS+
passwords

guru% chkey -p
Updating nisplus publickey database.
Reencrypting key for 'unix.18602@fhcrc.org'.
Please enter the Secure-RPC password for dweeb4:
Please enter the login password for dweeb4:
guru%

-Use your *old* password when asked for the
"Secure-RPC password".  Use your new password when
asked for "login password".
-Wait a few minutes


Fixing Credential Problems

For reasons I don't understand, users sometimes don't
have NIS+ credentials.
Or the ones they have don't work.

-nisaddcred -rp unix.123456@fhcrc.org -P
name.fhcrc.org.
-wait a few minutes
-nisaddcred -p unix.123456@fhcrc.org -P
name.fhcrc.org. DES

where 123456 is the user's UID and "name" is the
user's login name.

The second "nisaddcred" command will ask for the
user's login password.
If you don't have the user's login password, use any
string ...  and tell
the user that string ...  they will need to perform
the keylogin/chkey
routine above in order to sync their NIS+ password
(the string you typed)
and their login password.


Adding/Modifying Users

The GUI tool is the easiest method.  Run "solstice"
and choose "Users"
from the resulting display.  This creates a user with
NIS+ credentials
(both LOCAL and DES credentials).

Also, check out the /opt/SUNWadm/bin command-line
utilities, notably admuseradd
and admusermod.  For best results, run these only from
the NIS+ master.

(e.g if you run admusermod from anything but the NIS+
master, all sorts of
grotestque things happen to /export/home on the user's
home machine.
Notably, "chown -R username /export/home/*; chgrp -R
username /export/home/*".
Not what you intended.  I think this is a bug.)

There are several approaches to using the command-line
utilities.

Add the users to /etc/passwd using the "useradd"
command.  Use the "passwd"
command to add them to /etc/shadow.  Extract the
entries to pseudo-passwd
and pseudo-shadow files, place them in a temporary
directory, say, /junk.

nispopulate -v -F -p /junk -d fhcrc.org. -S 0
or
nisaddent -v -f /junk/passwd -d fhcrc.org. passwd
nisaddent -v -f /junk/shadow -d fhcrc.org. shadow

Either of these will add users to the NIS+ space ... 
but will *not* create
NIS+ credentials for them.

nispopulate -v -F -p /junk -d fhcrc.org. -l
1124cns5063

This will add users to the NIS+ space and will create
NIS+ credentials for them.

Or, acquire a copy of a password and a shadow file and
edit them.
Use "nisaddent -avf filename1 passwd; nisaddent -avf
filename2 shadow"
to add new users.  If you have a canonical passwd and
shadow file (from
/opt/local/config/files, for instance), then you can
use "nisaddent -mvf
passwd passwd; nisaddent -mvf shadow shadow".  Notice
how easy it is to
mangle the passwd table in NIS+ when using these
commands.

Net groups
I use these to implement access control.

/etc/passwd
...
+@unix-admin:x:::::

/etc/shadow
...
+@unix-admin::9933::::::

"+" means allow members of this group, "-" means
disallow members of this group.

The second field in the passwd file, "x", in this
example, says that the
actual password is stored in the shadow file.  The
second field in the shadow
file, empty in this example, normally holds the users
encrypted password.
If this field is empty, for a netgroup, then members
of that group can log on.
If the field contains an "x", then members of that
group *cannot* logon ...
even though the "+@" syntax in the passwd field would
seem to imply otherwise.

After creating a new netgroup (using nisaddent or
solstice GUI), I add the
appropriate entry to /etc/passwd.  Then I run "pwconv"
to add the appropriate
entry to /etc/shadow.  By default, pwconv disables
login for members of that
netgroup, e.g.  it puts an
 "x" in the second field of /etc/shadow.


Administering the NIS+ tables

The NIS+ group "admin" controls who can modify NIS+
tables.  Any member of
"admin" can modify the NIS+ tables in any way.

To list the members of "admin":

rmaster{dweeb4}41: nisgrpadm -l admin.fhcrc.org.
Group entry for "admin.fhcrc.org." group:
    Explicit members:
        guru.fhcrc.org.
        rmaster.fhcrc.org.
        dweeb1.fhcrc.org.
        dweeb4.fhcrc.org.
        dweeb2.fhcrc.org.
        dweeb3.fhcrc.org.
    No implicit members
    No recursive members
    No explicit nonmembers
    No implicit nonmembers
    No recursive nonmembers
rmaster{dweeb4}42:

Note that the "root" ID on a box is represented by
that box's name, rather
than by the string "root".  Thus, the users who can
modify the NIS+ tables
in the NIS+ domain fhcrc.org.  are: root on rmaster,
root on guru, dweeb1,
dweeb4, dweeb2, and dweeb3.

If I wanted to prevent root on guru from modifying the
NIS+ tables, I could:
nisgrpadm -r admin.fhcrc.org.  guru.fhcrc.org.
e.g.
"remove root on guru from the admin group"

I don't do this on rmaster because I want to run the
/home/nisops/bin/nisupdate cron job, which imports
/home/hostops/etc/hosts
and /home/mailops/etc/aliases.master into the NIS+
space.  Only a member of
the NIS+ group "admin" (admin.fhcrc.org.)  can do th
is.  Only the root ID can
run NIS+ authenticated cron jobs ...  because root's
credential is written to
disk /etc/.rootkey.  No other user can run NIS+
authenticated cron jobs ...
unless you play with some hack to "keylogin" at the
beginning of the cron
jo b ...  but then you would have to put that user's
password in clear text
in the cron job script.  (Actually, removing root on
rmaster from the admin
group would have catstrophic effects on the NIS+
domain.)

Another way to grant access to a table is to use the
nischown command.
nischown hostops hosts.org_dir
would change owernship of the hosts table from rmaster
(root) to hostops.
This would allow hostops to modify the hosts table,
without being a member
of the admin group.

nischmod could be used to refine these privileges,
e.g.  hostops might be
allowed to create new entries but not allowed to
delete current entries,
given the appropriate nischmod command.

To look at the NIS+ database files, look in
/var/nis/data.  This is a quick
way to identify the names of the NIS+ tables, also. 
(Note, for instance,
that the aliases table is not
aliases.org_dir.fhcrc.org., as one might think,
but rather mail_aliases.org_dir.fhcrc.org.  Barf!)


Permissions and the NIS+ tables

3-12-97
I typed:
nischmod n-r x.org_dir

for x in (auto_master, auto_home, bootparams, ethers,
group, hosts,
mail_aliases, netgroup, passwd, sendmailvars,
netmasks, networks, protocols,
rpc, services, timezone)

This removed the "read" permission from the group
"nobody", meaning that
non-NIS+ authenticated users cannot look at most of
the tables.  I figured
this was good for security.  The only users we
maintain which don't have NIS+
credentials are the backdoor account and the
operations accounts (hostops,
mailops, netops, etc.)  Unauthenticated users thus no
longer have access to the
services table ...  which means they can't perform
outbound telnet or ftp ...

To disallow authenticated NIS+ users from looking at
the tables, I typed:
nischmod w-r x.org_dir
except for cred.org_dir.

Before doing this, I added all NIS+ client machines to
group admin.

nisgrpadm -a admin.fhcrc.org snap.fhcrc.org.
spitbug.fhcrc.org.

To allow pseudo-users like netops to write to syslog,
I allow read access
to the syslog entry in the services table.

nischmod n+r '[cname=syslog],services.org_dir'

I noticed that the encrypted password field in
passwd.org_dir was readable by
unauthenticated NIS+ users (group nobody) and that
NIS+ users themselves had
trouble changing their passwords.  niscat-o
passwd.org_dir revealed that the
table had read permissi on set for group nobody and
that the shadow column
had no permissions set for anyone.  nischmod n-r
passwd.org_dir removed read
permission for group nobody from the passwd table. 
The following command
added read permission for the owner to the shadow col
umn of the passwd table.

nistbladm -u -t passwd_tbl shadow=o+r passwd.org_dir
nistbladm -u -t passwd_tbl home=o=r passwd.org_dir

4/25/97
I blew away the NIS+ space and rebuilt from scratch. 
Here are the default
permissions:

guru% nisls -l fhcrc.org.
fhcrc.org.:
D r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:40 1997 org_dir
D r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:40 1997 groups_dir
guru% nisls -l groups_dir
groups_dir.fhcrc.org.:
G ----rmcdr---r--- rmaster.fhcrc.org. Fri Apr 25
11:12:06 1997 admin
guru% nisls -l org_dir
org_dir.fhcrc.org.:
T ----rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:41 1997 passwd
T ----rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:42 1997 group
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:42 1997 auto_master
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:43 1997 auto_home
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:43 1997 bootparams
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:44 1997 cred
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:44 1997 ethers
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:45 1997 hosts
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:45 1997 mail_aliases
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:46 1997 sendmailvars
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:46 1997 netmasks
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:47 1997 netgroup
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:47 1997 networks
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:48 1997 protocols
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:48 1997 rpc
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:49 1997 services
T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:49 1997 timezone
guru% nisls -l passwd.org_dir
Object Name   : passwd
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : ----rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:41 1997
Mod. Time     : Fri Apr 25 11:11:41 1997
Object Type   : TABLE
Table Type          : passwd_tbl
Number of Columns   : 8
Character Separator : :
Search Path         : 
Columns             :
        [0]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : r---r---r---r---
        [1]     Name          : passwd
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----rm--r---r---
        [2]     Name          : uid
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : r---r---r---r---
        [3]     Name          : gid
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---r---r---r---
        [4]     Name          : gcos
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---rmcdrmcdr---
        [5]     Name          : home
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---rmcdrmcdr---
        [6]     Name          : shell
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---rmcdrmcdr---
        [7]     Name          : shadow
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% nisls -l group.org_dir
T ----rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25
11:11:42 1997 group.org_dir.fhcrc.org.
guru% niscat -o group.org_dir
Object Name   : group
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : ----rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:42 1997
Mod. Time     : Fri Apr 25 11:11:42 1997
Object Type   : TABLE
Table Type          : group_tbl
Number of Columns   : 4
Character Separator : :
Search Path         : 
Columns             :
        [0]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : r---rmcdrmcdr---
        [1]     Name          : passwd
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----rmcdrmcdr---
        [2]     Name          : gid
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : r---rmcdrmcdr---
        [3]     Name          : members
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---rmcdrmcdr---
guru% niscat -o auto_master.org_dir
Object Name   : auto_master
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:42 1997
Mod. Time     : Fri Apr 25 11:11:42 1997
Object Type   : TABLE
Table Type          : automount_map
Number of Columns   : 2
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : key
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : ----------------
        [1]     Name          : value
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% nisact -o auto_home.org_dir
nisact: Command not found
guru% niscat -o auto_home.org_dir
Object Name   : auto_home
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:43 1997
Mod. Time     : Fri Apr 25 11:11:43 1997
Object Type   : TABLE
Table Type          : automount_map
Number of Columns   : 2
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : key
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : ----------------
        [1]     Name          : value
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------

guru% niscat -o bootparams.org_Dir
Object Name   : bootparams
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:43 1997
Mod. Time     : Fri Apr 25 11:11:43 1997
Object Type   : TABLE
Table Type          : bootparams_tbl
Number of Columns   : 2
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : key
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : value
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% nisact -o cred.org_dir
Object Name   : cred
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:44 1997
Mod. Time     : Fri Apr 25 11:11:44 1997
Object Type   : TABLE
Table Type          : cred_tbl
Number of Columns   : 5
Character Separator : :
Search Path         : 
Columns             :
        [0]     Name          : cname
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : auth_type
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : auth_name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : public_data
                Attributes    : (TEXTUAL DATA)
                Access Rights : -----m----------
        [4]     Name          : private_data
                Attributes    : (TEXTUAL DATA)
                Access Rights : -----m----------

guru% niscat -o ethers.org_dir
Object Name   : ethers
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:44 1997
Mod. Time     : Fri Apr 25 11:11:44 1997
Object Type   : TABLE
Table Type          : ethers_tbl
Number of Columns   : 3
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : addr
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% nisact -o hosts.org_dir
Object Name   : hosts
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:45 1997
Mod. Time     : Fri Apr 25 11:11:45 1997
Object Type   : TABLE
Table Type          : hosts_tbl
Number of Columns   : 4
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : cname
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : addr
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o mail_aliases.org_dir
Object Name   : mail_aliases
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:45 1997
Mod. Time     : Fri Apr 25 11:11:45 1997
Object Type   : TABLE
Table Type          : mail_aliases
Number of Columns   : 4
Character Separator : 
Search Path         : 
Columns             :
        [0]     Name          : alias
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : expansion
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : comments
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
        [3]     Name          : options
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o sendmailvars.org_dir
Object Name   : sendmailvars
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:46 1997
Mod. Time     : Fri Apr 25 11:11:46 1997
Object Type   : TABLE
Table Type          : sendmailvars
Number of Columns   : 2
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : key
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : ----------------
        [1]     Name          : value
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------

guru% niscat -o netmasks.org_dir
Object Name   : netmasks
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:46 1997
Mod. Time     : Fri Apr 25 11:11:46 1997
Object Type   : TABLE
Table Type          : netmasks_tbl
Number of Columns   : 3
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : addr
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : mask
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% nisact -o netgroup.org_dir
Object Name   : netgroup
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:47 1997
Mod. Time     : Fri Apr 25 11:11:47 1997
Object Type   : TABLE
Table Type          : netgroup_tbl
Number of Columns   : 6
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : ----------------
        [1]     Name          : group
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : ----------------
        [2]     Name          : host
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : user
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                Access Rights : ----------------
        [4]     Name          : domain
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [5]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o networks.org_dir
Object Name   : networks
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:47 1997
Mod. Time     : Fri Apr 25 11:11:47 1997
Object Type   : TABLE
Table Type          : networks_tbl
Number of Columns   : 4
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : cname
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : addr
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o protocols.org_dir
Object Name   : protocols
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:48 1997
Mod. Time     : Fri Apr 25 11:11:48 1997
Object Type   : TABLE
Table Type          : protocols_tbl
Number of Columns   : 4
Character Separator :  
Search Path         :
Columns             :
        [0]     Name          : cname
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : number
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o rpc.org_dir
Object Name   : rpc
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:48 1997
Mod. Time     : Fri Apr 25 11:11:48 1997
Object Type   : TABLE
Table Type          : rpc_tbl
Number of Columns   : 4
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : cname
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : number
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o services.org_dir
Object Name   : services
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:49 1997
Mod. Time     : Fri Apr 25 11:11:49 1997
Object Type   : TABLE
Table Type          : services_tbl
Number of Columns   : 5
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : cname
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [2]     Name          : proto
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [3]     Name          : port
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [4]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o timezone.org_dir
Object Name   : timezone
Directory     : org_dir.fhcrc.org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 12:0:0
Creation Time : Fri Apr 25 11:11:49 1997
Mod. Time     : Fri Apr 25 11:11:49 1997
Object Type   : TABLE
Table Type          : timezone_tbl
Number of Columns   : 3
Character Separator :  
Search Path         : 
Columns             :
        [0]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE INSENSITIVE)
                Access Rights : ----------------
        [1]     Name          : tzone
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
        [2]     Name          : comment
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
guru% niscat -o fhcrc.org.
Object Name   : fhcrc
Directory     : org.
Owner         : rmaster.fhcrc.org.
Group         : admin.fhcrc.org.
Access Rights : r---rmcdrmcdr---
Time to Live  : 24:0:0
Creation Time : Wed Dec 31 16:00:00 1969
Mod. Time     : Fri Apr 25 11:52:16 1997
Object Type   : DIRECTORY
Name : 'fhcrc.org.'
Type : NIS
Master Server :
        Name       : rmaster.fhcrc.org.
        Public Key : Diffie-Hellman (192 bits)
        Universal addresses (6)
        [1] - udp, inet, 140.107.10.102.0.111
        [2] - tcp, inet, 140.107.10.102.0.111
        [3] - -, inet, 140.107.10.102.0.111
        [4] - -, loopback, rmaster.rpc
        [5] - -, loopback, rmaster.rpc
        [6] - -, loopback, rmaster.rpc
Replicate : 
        Name       : guru.fhcrc.org.
        Public Key : Diffie-Hellman (192 bits)
        Universal addresses (3)
        [1] - udp, inet, 140.107.46.113.0.111
        [2] - tcp, inet, 140.107.46.113.0.111
        [3] - -, inet, 140.107.46.113.0.111
Replicate : 
        Name       : pooh.fhcrc.org.
        Public Key : Diffie-Hellman (192 bits)
        Universal addresses (3)
        [1] - udp, inet, 140.107.10.101.0.111
        [2] - tcp, inet, 140.107.10.101.0.111
        [3] - -, inet, 140.107.10.101.0.111
Replicate : 
        Name       : rserver1.fhcrc.org.
        Public Key : Diffie-Hellman (192 bits)
        Universal addresses (3)
        [1] - udp, inet, 140.107.10.110.0.111
        [2] - tcp, inet, 140.107.10.110.0.111
        [3] - -, inet, 140.107.10.110.0.111
Replicate : 
        Name       : rserver2.fhcrc.org.
        Public Key : Diffie-Hellman (192 bits)
        Universal addresses (3)
        [1] - udp, inet, 140.107.10.111.0.111
        [2] - tcp, inet, 140.107.10.111.0.111
        [3] - -, inet, 140.107.10.111.0.111
Time to live : 12:0:0
Default Access rights :
guru%

Restoring NIS+ after tragedy

Generally, this is no need to restore the NIS+ files. 
A client can be
re-introduced into the NIS+ space simply by following
the standard process
for creating a NIS+ client.  A replica server can be
re-introduced into the
space by deleting /va/nis/{server name}.log and
issuing a "nisping -C" command.

A master server is theonly machine for which one might
want to go to backup
files.  To restore a master server's NIS+ data,
restore the following files:

/var/nis/*
/etc/.rootkey
/etc/defaultdomain
/etc/nsswitch.conf

reboot

/opt/local/sbin/nisdump, run by cron on rmaster every
night, saves /var/nis
in /opt/local/config/files/var_nis.tar.Z.  It also
saves /etc/.rootkey in
/opt/local/config/files/safe.rootkey.  (Although, of
course, .rootkey is easy
to recreate, just type "key login -r", enter root's
password, and 'tis done.)

Another cron job archive's copies of
/opt/local/config/files in
/opt/local/config/backup; keeps a week's worth.

Files are imported into the NIS+ space using the
nisaddent command.

nisaddent -avf hosts hosts # This adds the contents of
hosts to the hosts table
nisaddent -mvf hosts hosts # This merges the contents
of hosts with the
		hosts table
nisaddent -avf auto_home -t auto_home key-value #This
adds the contents of
		the file auto_home to the auto_home table
nisaddent -mvf passwd passwd    #These two commands
import the passwd and
nisaddent -mvf shadow shadow    #and shadow files into
the NIS+ passwd table


There is also a way to recreate the root master from
the files in
rmaster:/opt/local/config/files; I need to document
this here.

Maintaining the NIS+ space

When a change is made to the NIS+ space, it is stored
in RAM by niscachemgr.
Every two minutes, a box with new changes in
niscachemgr propagates those
changes to niscachemgr on other boxes.  "nisping
org_dir", "nisping group_dir"
can be used to propagate these changes immediately.

At some point, one wants to commit these changes to
disk.  "nisping -C'
accomplish this; rmaster runs this as a cron job twice
a night.  (Why twice?
In case the first one fails for some reason.  I have
no evidence to suggest
that a checkpoint would ever fail.)

For the first few months of 1997, rmaster ran this
every hour.  After
conversations with Sun Service, I abandoned this. 
Apparently, nisping -C
uses lots of machine resources, and while a checkpoint
is happening, access
to NIS+ tables can be interrupted.

We also postulated that this kind of behavior may have
been causing aliases
to drop out of mail_aliases.org_dir.

Troubleshooting

"no public key for unix.machine"

Look for "no publc key for unix.machine" in syslog. 
This occurs transiently
when a client machine is added or removed but should
not occur otherwise.

If it does occur, the machine in question is having
trouble with credentials.
Try the following procedure.

-Verify that /etc/inet/hosts contains the line: 
140.107.10.102 rmaster
-On the troubled machine:
-rm -rf /var/nis/*
 -nisclient -I -d fhcrc.org. -h rmaster
-init 6

If this fails, then perform the following steps before
repeating the above
	procedure.
-From any other machine in the NIS+ domain
-nisaddcred -rp unix.machine@fhcrc.org -P
machine.fhcrc.org.
-wait a few minutes
-nisaddcred -p unix.machine@fhcrc.org -P
machine.fhcrc.org. des
-wait a few minutes

In some situations, when NIS+ is hosing a machine, the
box will not go down
with "init 6".  In these situation, kill any "umount"
processes on the box;
the reboot should then proceed normally.


"possible loop in name space"
 
Thus far, this has meant that the root master is
corrupt, time to wipe the
NIS+ space and rebuild from scratch.

These seem like serious problems.

"xdr_array: out of memory"

"WARNING: db_dictionary"


Removing a NIS+ client

-Run /opt/local/sbin/nukenis
-Rebooting is not entirely necessary ... but is
desirable

Note that nukenis replaces /etc/nsswitch.conf with a
straight files + dns
configuration file.

If you want to be utterly thorough, remove the
client's NIS+ credentials.
-On any box still living in the NIS+ space (where
"guru" is the example name
of the box):
nisaddcred -rp unix.guru@fhcrc.org -P guru.fhcrc.org.


Removing a NIS+ replica server

On the NIS+ replica server, perform the same steps as
are outlined for
removing NIS+ from a client.

On the master server (rmaster):
nisrmdir -fs guru.fhcrc.org. groups_dir.fhcrc.org.
nisrmdir -fs guru.fhcrc.org. org_dir.fhcrc.org.
nisrmdir -fs guru.fhcrc.org. fhcrc.org.
nisclient -co guru

On the ex-replica server:
rm -r /var/nis/*
rm /etc/.rootkey
ps -ef | grep nis , kill pids for all nisd's and
nis_cachemngrs
nisclient -i -d fhcrc.org. -h rmaster
mod /etc/nsswitch.conf as desired
reboot
/usr/sbin/rpc.nisd

Ignore complaints about not being able to find the
/var/nis coldstart file.

If the replica server is up and functioning when you
start this process, you can skip the "f" parameter in
the nisrmdir commands.

Why would I want to do this?  The NIS+ logs on rmaster
are only checkpointed
if updates have been propagated to *all* replica
servers.  If a replica server
is going to be down for a while, then I might choose
to tell rmaster that
this downed box is no longer a replica server, thus
allowing the checkpoints
on the logs to complete.  When the downed box returns
to life, I would repeat
the steps to reinstate it as a replica server.

Removing the NIS+ space entirely

Just repeat the steps outlined in "Removing a NIS+
client" on every single
box.  Try to traverse the tree from the leaves in,
e.g.  pure clients first,
replica servers second, master servers next, root
server last.


Useful NIS+ Admin scripts

nisdump:
#!/bin/sh
PATH=/usr/lib/nis
cd /opt/local/config/files
nisaddent -d aliases > aliases
nisaddent -d bootparams > bootparams
nisaddent -d ethers > ethers
nisaddent -d group > group
nisaddent -d hosts > hosts
nisaddent -d netgroup > netgroup
nisaddent -d netid > netid
nisaddent -d netmasks > netmasks
nisaddent -d networks > networks
nisaddent -d passwd > passwd
nisaddent -d protocols > protocols
nisaddent -d publickey > publickey
nisaddent -d rpc > rpc
nisaddent -d services > services
nisaddent -d shadow > shadow
nisaddent -d timezone > timezone
nisaddent -d -t auto_home.org_dir key-value >
auto_home
nisaddent -d -t auto_master.org_dir key-value >
auto_master
#nisaddent -d -t auto_direct.org_dir key-value >
auto_direct

/usr/bin/chmod 600 shadow

/usr/bin/tar cfp var_nis.tar /var/nis
/usr/bin/cp /etc/.rootkey safe.rootkey


nispoing:
#!/bin/sh
#Checkpoint the NIS+ domain
/usr/lib/nis/nisping -C fhcrc.org.
/usr/lib/nis/nisping -C org_dir.fhcrc.org.
/usr/lib/nis/nisping -C groups_dir.fhcrc.org.
/usr/lib/nis/nisping fhcrc.org.
/usr/lib/nis/nisping org_dir.fhcrc.org.
/usr/lib/nis/nisping groups_dir.fhcrc.org.


nukenis:
#!/bin/sh
# Run this as root to remove NIS+ from a machine
# You may want to manually copy ASCII files from
/opt/local/config/files to 
# the relevant locations.  --sk 2-26-97


echo "Replacing /etc/nsswitch.conf ..."
if [ -f /opt/local/config/root/etc/nsswitch.dns ];
then
        cp /opt/local/config/root/etc/nsswitch.dns
/etc/nsswitch.conf
else
        cp /etc/nsswitch.files /etc/nsswitch.conf
        echo "Remember to add 'dns' to
/etc/nsswitch.conf"
fi
echo "Stopping rpc services"
/etc/init.d/rpc stop
/etc/init.d/nscd stop
/etc/init.d/sendmail stop
echo "Nuking NIS+ files"
rm -f /etc/.rootkey
rm -rf /var/nis/*
rm -rf /var/nis/.*
rm -rf /etc/defaultdomain
/etc/init.d/rpc start
/etc/init.d/nscd start

if [ -f /opt/local/config/root/etc/nsswitch.dns ];
then
        /etc/init.d/sendmail start
else
        echo "Add 'dns' to /etc/nsswitch.conf before
restarting sendmail"
fi


This script compares the NIS+ tables to the file-based
masters.  If there
is a difference, scream.  I wrote this script during a
period when alias
entries were dropping out of the NIS+ table randomly. 
Turns out that this
was occurring because I was running "nisping -C
fhcrc.org."  too frequently
- every hour or more.  When I yanked that cronjob, the
"missing aliases"
problem stopped.

monitor_nisplus:

#!/usr/local/bin/perl
# If aliases.org_dir is not identical to 
# bug0:/home/mailops/etc/aliases.nisplus then scream
to sk.  --sk 4-11-97
# If hosts.org__dir is not identical to
/home/hostops/etc/hosts then
# scream to sk.  --sk 6-20-97

use Sys::Syslog;
use POSIX;
use File::Copy 'cp';

$logdir = "/home/nisops/log";
$tmpdir = "/home/nisops/tmp";

######################################################################
# Aliases table
######################################################################

$dumpfile = "aliases.dump";
$lockfile = "monitor_aliases.lock";
$logfile = "aliases.log";
$masterdir = "/home/mailops/etc";
$masterfile = "aliases.nisplus";
$upaliases = "/tmp/upaliases.lock";


# If master text file isn't readable, bail
if (! -r "$masterdir/$masterfile") { exit; }

# If upaliases is running, bail
if (-e "$upaliases") { exit; }

# Dump aliases.org_dir to a file
system ("/usr/lib/nis/nisaddent -d aliases >
'$tmpdir/$dumpfile'");
cp ("$masterdir/$masterfile", "$tmpdir/aliases.file");

# Clean the dump file
open (DUMP, "<$tmpdir/$dumpfile");
open (OUT, ">$tmpdir/aliases.dump1");
while () {
  s/^#.*\n//;       # Strip comments at beginning of
line
  s/\s*#.*//;       # Strip comments in middle of line
  s/:\s*\n/: /;     # Join lines which end with ":"
  s/:\s*/:\$\$\$/;  # Save colon plus space
combinations
  s/,\s*\n/,/;      # Join lines which end with ","
  s/\(.*?\)//g;     # Strip parens and their contents
  s/\t//g;          # Strip tabs
  s/ //g;           # Strip spaces
  s/^\n//;          # Strip blank lines
  s/:\$\$\$/: /;    # Restore space after colon
  print (OUT $_);
}
close DUMP;
close OUT;
system ("/usr/bin/sort '$tmpdir/aliases.dump1' >
'$tmpdir/aliases.dump2'");    

# Clean the master file
open (MASTER, "<$tmpdir/aliases.file");
open (OUT, "> $tmpdir/aliases.file1");
while () {
  s/.*#.*\n//;          # Strip comments
  s/:\s*\n/: /;         # Join lines which end with
":"
  s/:\s*/:\$\$\$/;      # Save colon plus space
combinations
  s/,\s*\n/,/;          # Join lines which end with
","
  s/\(.*?\)//g;         # Strip parens and their
contents
  s/\t//g;              # Strip tabs
  s/ //g;               # Strip spaces
  s/^\n//;              # Strip blank lines
  s/:\$\$\$/: /;        # Restore space after colon
  print (OUT $_);
}
close MASTER;
close OUT;
system ("/usr/bin/sort '$tmpdir/aliases.file1' >
'$tmpdir/aliases.file2'");

# If there are differences and this is news, scream
$diff = (system ("/usr/bin/diff $tmpdir/aliases.dump2
$tmpdir/aliases.file2"))/256;
if (($diff == 1) && (! -e "$tmpdir/$lockfile")) {
  $diff = `/usr/bin/diff $tmpdir/aliases.dump2
$tmpdir/aliases.file2`;
  open FILE, ">$tmpdir/aliases.msg";
  print FILE "NIS+ aliases not the same as files. 
--monitor_nisplus";
  close FILE;
  system "/usr/bin/mailx -s 'skendric'
apager\@fhcrc.org < $tmpdir/aliases.msg";
  system "/usr/bin/mailx -s 'NIS+ aliases not the same
as files' skendric\@fhcrc.org < $tmpdir/aliases.msg";
  system ("/usr/bin/touch $tmpdir/$lockfile");
  open LOG, ">>$logdir/$logfile";
  print LOG scalar localtime, "\n";
  print LOG $diff, "\n";
  close LOG;
}

# If there are no differences but the lockfile exists,
then a problem has been
# fixed, remove the lockfile

if (($diff == 0) && (-e "$tmpdir/$lockfile")) {
  unlink "$tmpdir/$lockfile";
}

# If the lock file exists, a problem has occurred;
leave the temp files until
# the problem is resolved

if ( ! -e "$tmpdir/$lockfile") {
  unlink <$tmpdir/aliases.*>;
}


######################################################################
# Hosts table
######################################################################

$dumpfile = "hosts.dump";
$edho = "/tmp/edho.lock";
$lockfile = "monitor_hosts.lock";
$logfile = "hosts.log";
$masterdir = "/home/hostops/etc";
$masterfile = "hosts";
$uphosts = "/tmp/uphosts.lock";

# If edho or uphosts are running, bail
if ( (-e $edho) || (-e $uphosts) ) {exit};

# Dump hosts.org_dir to a file
system ("/usr/lib/nis/nisaddent -d hosts >
'$tmpdir/$dumpfile'");
cp ("$masterdir/$masterfile", "$tmpdir/hosts.file");

# Clean the dump file
open (DUMP, "<$tmpdir/$dumpfile");
open (OUT, ">$tmpdir/hosts.dump1");
while () {
  s/^\n//;        # Strip blank lines
  s/^#.*\n//;     # Strip comments
  s/\s#.*//;      # Strip comments
  s/\t/ /g;       # Replace tabs with spaces
  s/ +/ /g;        # Reduce all white space to a
single space
  s/ \n/\n/;      # Strip trailing space
  s/ (.*?) .*/ $1/;
  print (OUT $_);
}
close DUMP;
close OUT;
system ("/usr/bin/sort '$tmpdir/hosts.dump1' >
'$tmpdir/hosts.dump2'");

# Clean the master file
open (MASTER, "<$tmpdir/hosts.file");
open (OUT, "> $tmpdir/hosts.file1");
while () {
  s/^\n//;        # Strip blank lines
  s/^#.*\n//;     # Strip comments
  s/\s#.*//;      # Strip comments
  s/\t/ /g;       # Replace tabs with spaces
  s/ +/ /g;        # Reduce all white space to a
single space
  s/ \n/\n/;      # Strip trailing space
  s/ (.*?) .*/ $1/;
  print (OUT $_);
}
close MASTER;
close OUT;
system ("/usr/bin/sort '$tmpdir/hosts.file1' >
'$tmpdir/hosts.file2'");

# If there are differences and this is news, scream
$diff = (system ("/usr/bin/diff $tmpdir/hosts.dump2
$tmpdir/hosts.file2"))/256;
if (($diff == 1) && (! -e "$tmpdir/$lockfile")) {
  $diff = `/usr/bin/diff $tmpdir/hosts.dump2
$tmpdir/hosts.file2`;
  open FILE, ">$tmpdir/hosts.msg";
  print FILE "NIS+ hosts not the same as files. 
--monitor_nisplus";
  close FILE;
  system "/usr/bin/mailx -s 'skendric'
apager\@fhcrc.org < $tmpdir/hosts.msg";
  system "/usr/bin/mailx -s 'NIS+ hosts not the same
as files' skendric\@fhcrc.org < $tmpdir/hosts.msg";
  system ("/usr/bin/touch $tmpdir/$lockfile");
  open LOG, ">>$logdir/$logfile";
  print LOG scalar localtime, "\n";
  print LOG $diff, "\n";
  close LOG;
}

# If there are no differences but the lockfile exists,
then a problem has been
# fixed, remove the lockfile

if (($diff == 0) && (-e "$tmpdir/$lockfile")) {
  unlink "$tmpdir/$lockfile";
}

# If the lock file exists, a problem has occurred;
leave the temp files until
# the problem is resolved

if ( ! -e "$tmpdir/$lockfile") {
  unlink <$tmpdir/hosts.*>;
}


Useful Sun NIS+ documents
Document ID: 1010

SYNOPSIS:  NIS+ database recovery

DETAIL DESCRIPTION:

Regarding backup/restore strategy of nis+ data, if the
root server goes down,
can it recover from a replica server?

Is a simple dump/restore of /var/nis enough for
backing up the nis+ domain?


SOLUTION SUMMARY:

If you use backup and restore on /var/nis that is
sufficient.  However there
are a couple of caveats.

1) If you restore a master server from an out of date
(with respect to the
namespace) /var/nis directory, the slaves will all do
full resyncs to get
back to this _older_version of the data and thus
delete any changes that
had occurred later in the cycle.

2) If you change the name or IP address of a NIS+
server the backup will no
longer be valid.

3) For replicas you can just delete
/var/nis/servername.log and ping the
master to get a fresh copy of the data.  (forces a
full resync)

4) Since the log file has ufs "holes" in it, you must
use a backup program
that understands about this feature. 
(ufsdump/ufsrestore does)


DATE APPROVED: 11/20/95
KEYWORDS:      nis+ database recovery backup restore
OS RELEASE:    Solaris


--------------------------------------------------

SunService Tip Sheet for SUN NIS+ 

Revision: 1.5
Date: November 11, 1996
Mail to: support@network.East.Sun.COM

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
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
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 NISplus

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:

  %% 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:

  %% niscat cred.org_dir

You can create credentials for a user with nisclient:

  %% 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:

  %% niscat passwd.org_dir

You can also examine the object properties of a table:

  %% 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:

  %% 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# nisserver -v -r -d domain_name

(where domain_name is your NIS+ domain.)

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# 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%% nisls
  root-master%% 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# 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# 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# rpc.nisd

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

  root-master# 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# nisping domain_name.
  root-master# nisping org_dir.domain_name.
  root-master# 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# 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# 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# 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

Unfortunately, there is no easy way to configure the
root server again
when the IP address is changed. This is because the
clients maintain
the server's IP address in their cold start file, and
the server has
the old IP address in its cache. You must totally
reinitialize the
Root Server for an IP address change.

The best way to do this is first dump the NIS+ tables
to ASCII files
using the nisaddent command:

  root-master# cd /var/tmp/nisfiles
  root-master# nisaddent -d aliases > aliases
  root-master# nisaddent -d bootparams > bootparams
  root-master# nisaddent -d ethers > ethers
  root-master# nisaddent -d group > group
  root-master# nisaddent -d hosts > hosts
  root-master# nisaddent -d netgroup > netgroup
  root-master# nisaddent -d netid > 
  root-master# nisaddent -d netmasks > netmasks
  root-master# nisaddent -d networks > networks
  root-master# nisaddent -d passwd > passwd
  root-master# nisaddent -d protocols > protocols
  root-master# nisaddent -d publickey > publickey
  root-master# nisaddent -d rpc > rpc
  root-master# nisaddent -d services > services
  root-master# nisaddent -d shadow > shadow
  root-master# nisaddent -d timezone > timezone
  root-master# nisaddent -d -t auto_home.org_dir
key-value > auto_home
  root-master# nisaddent -d -t auto_master.org_dir
key-value > auto_master

At this point, edit the newly dumped hosts file to
reflect the new 
ipaddress(es).  

Then, you must clean out old NIS+ info:

  root-master# cp /etc/nsswitch.nisplus
/etc/nsswitch.conf
  root-master# /etc/init.d/rpc stop
  root-master# rm -f /etc/.rootkey
  root-master# rm -rf /var/nis/*
  root-master# /etc/init.d/rpc start

And finally, you can reconfigure your NIS+ server, as
described in
Section 3.2.  After you have reconfigured the Root
Master server you will
need to reinitialize the nis+ clients.  On the
clients, remove the old NIS+ 
info as detailed above and follow the procedure in
Section 3.3 to 
reinitialize the clients. 

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:

  # nisgrpadm -a admin.domain_name. joe
  # 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.

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.  

  %passwd -r nisplus

As root on Solaris 2.5 and later you either use
adminsuite or
  #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:

  % 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:

  # 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:

  # 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:

  # chkey -p

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:

  %% nisaddcred -p uid -P principal-name local
  %% 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:

 %% 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:

  %% 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:

  %% 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# 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:

  %% nisgrpadm -d group-name.domain_name.

To list the group members:

  %% nisgrpadm -l group-name.domain_name.

To add members to a NIS+ group:

  %% nisgrpadm -a group-name member

To remove members from a NIS+ group:

  %% nisgrpadm -r group-name member

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

  %% 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:

  %% 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:

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

(assuming your domain_name is example.com)

To delete a table:

  %% nistbladm -d table-name

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

  %% 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:

  %% niscat -o table-name

Or:

  %% niscat -o entry

To display the contents of a table:

  %% 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:

  %% nisaddent -m -f filename table-type

For example:

  %% 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:

  %% nisaddent -d hosts > /tmp/hosts
  %% vi /tmp/hosts
  %% nisaddent -r -f /etc/hosts hosts

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

Example:

  %% nisaddent -d passwd > /tmp/passwd
  %% nisaddent -d shadow > /tmp/shadow
  %% vi /tmp/passwd
  %% nisaddent -r -f /tmp/passwd passwd
  %% 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 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
/var/nis, to make sure that you can recover in the
case of a massive
failure.

3.17: How to Remove NIS+

If you wish to remove NIS+, you should run the
following commands on
all of your NIS+ machines:

  # cp /etc/nsswitch.files /etc/nsswitch.conf
  # /etc/init.d/rpc stop
  # rm -f /etc/.rootkey
  # rm -rf /var/nis/*
  # rm -rf /etc/defaultdomain
  # /etc/init.d/rpc start
  
It is suggested that you start with the clients, and
do the servers
last.

3.18:  How to define the printer table in NIS+

Run the following command, as root, to set up the NIS+
printers table
definition:

# nistbladm -c -D access=n+r,o+rmcd,g+rmcd,w+r
printers \
printer_name=S,o+rmcd,g+r,w+r
printer_host=S,o+rmcd,g+r,w+r  \
description=,o+rmcd,g+r,w+r
printers.org_dir.`domainname`.

Once you have set up this definition, you can confirm
the permissions
are set properly:

 # niscat -o printers.org_dir
 Object Name   : printers
 Owner         : ppp.hans.com.
 Group         : admin.hans.com.
 Domain        : org_dir.hans.com.
 Access Rights : r---rmcdrmcdr---
 Time to Live  : 12:0:0
 Object Type   : TABLE
 Table Type          : printers
 Number of Columns   : 3
 Character Separator :
 Search Path         :
 Columns             :
         [0]     Name          : printer_name
                 Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                 Access Rights : ----rmcdr---r---
         [1]     Name          : printer_host
                 Attributes    : (SEARCHABLE, TEXTUAL
DATA, CASE SENSITIVE)
                 Access Rights : ----rmcdr---r---
         [2]     Name          : description
                 Attributes    : (TEXTUAL DATA)
                 Access Rights : ----rmcdr---r---

After this, Admintool or the nisaddent command can be
used to populate
the printers table.

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:

  %% nisclient -c user
  %% 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:

  %% 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:

  %% 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:   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 agin 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
sunsolve1.sun.com.5.1: Solaris 2.x NIS+ Patches
 
Solaris 2.3 NIS+ Patches

101318-82 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-08 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-03 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-03 SunOS 5.3: nisplus patch  
 
  Fixes errors in the NIS+ library. Should be
installed on all NIS+
  machines.
 
102447-01 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-43 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-01 OpenWindows 3.4: xdm cannot be used on NIS+
networks  

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

101973-24 SunOS 5.4: fixes for libnsl and ypbind  

  This is a required patch for nis+.

102277-02 SunOS 5.4: nss_nisplus.so.1 fixes  

102153-04 SunOS 5.4: Admintool Jumbo patch  

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

102336-01 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-01 SunOS 5.4: rpc.nisd leaks one file
descriptor each checkpoint request
               *** OBSOLETED BY 101973-15 or later

102677-01 SunOS 5.4: nispasswd coredumps in mailoc
with SEGV  

102608-03 SunOS 5.4: nisaddent and nispopulate fixes  

atch-ID#  SunOS 5.4: nis_cachemgr fixes  


5.3:  Solaris 2.5 NIS+ Patches

103060-05 SunOS 5.5: nis_cachemgr fix  

atch-ID#  SunOS 5.5: rpc.nisd hangs in write(2)  

103279-02 SunOS 5.5: nscd breaks passwd shadowing with
NIS+ 

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 

SunService is not responsible for the initial
configuration of your
NIS+ environment. In addition, SunService can not
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.

        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.


 From sbk@fhcrc.org Tue Nov 26 11:27:06 1996
 Received: from bug1.fhcrc.org (bug1.fhcrc.org 
         [140.107.10.110]) by gnat.fhcrc.org
(8.8.3/8.8.2) with ESMTP 
         id LAA00696 for ; Tue, 26 Nov 1996 
         11:27:05 -0800 (PST) 
 Received: from spitbug.fhcrc.org (spitbug.fhcrc.org 
         [140.107.46.101]) by bug1.fhcrc.org
(8.8.3/8.8.2) with ESMTP 
         id LAA09434 for ; Tue, 26 Nov 1996 
         11:25:33 -0800 (PST) 
 Received: (from sbk@localhost) by spitbug.fhcrc.org 
         (8.8.3/8.8.2) id LAA03550; Tue, 26 Nov 1996
11:25:52 -0800 
         (PST) 
 Date: Tue, 26 Nov 1996 11:25:52 -0800 (PST)
 From: Stuart_Kendrick 
 To: skendric@fhcrc.org
 Subject: Re: SUMMARY:  NIS+ root replica --> root
master (fwd)
 Message-ID:  

---------- Forwarded message ----------
Date: Thu, 21 Nov 1996 12:14:35 GMT
From: Kevin Davidson 
To: Stuart Kendrick 
Subject: Re: SUMMARY:  NIS+ root replica --> root
master

>>>>> Stuart Kendrick  writes:
sbk> I asked about recovery strategies should a master
server croak.
sbk> There are no canned strategies -- no way to
promote a replica server to
sbk> master, for instance.

sbk> In theory, it should be possible to take recent
file dumps and create a
sbk> server from them.  And in theory, it could be
possible to restore from a
sbk> recent backup.  I haven't tried either to date. 
The key issue would be
sbk> whether or not current replica servers would
survive the experience.

 Maybe I missed your original message ? We proved
yesterday that you
*can* successfully rebuild a NIS+ master (and a
replica) simply by
preserving /var/nis.

 Our two main servers (our NIS+ master and replica)
were both upgraded
from 2.4 to 2.5.1. As the partitions were strangely
sized (we set them
up before we really got to grips with Solaris, so we
had /var in the
root partition) we opted to jumpstart them to install
2.5.1 from
scratch and then customise them. Obviously we had to
do one at a time
to maintain the NIS+ service.

 All it takes is to put back /var/nis from a dump and
then keylogin -r
(for some reason preserving /etc/.rootkey didn't
work).

 Also you can use this script to dump your NIS+ tables
to flat files
for rebuilding with nispopulate. Beware that the
services table gets
screwed up (unless that's been fixed by a Sun patch to
nisaddent).

#!/bin/sh
# Dump NIS+ tables to text files
PATH=/usr/lib/nis:$PATH; export PATH

cd /nis+files

for table in bootparams ethers group hosts netgroup
netmasks networks \
		passwd protocols rpc services timezone ; do
  nisaddent -d -t $table.org_dir $table > $table
done

nisaddent -d -t mail_aliases.org_dir aliases > aliases
nisaddent -d -t passwd.org_dir shadow > shadow
chmod 600 shadow
nisaddent -d -t cred.org_dir publickey > publickey

for table in auto_master auto_home auto_direct
auto_projects auto_local \
	auto_objlocal auto_contrib auto_cns auto_caad
auto_cdrom auto_floppy
do
  nisaddent -d -t $table.org_dir key-value > $table
done



-- 
|Kevin.Davidson@edinburgh.ac.uk +-+ Centre for
Cognitive Science/HCRC,        |
|tkld@cogsci.ed.ac.uk           | | University of
Edinburgh,                  |
|+44 (0)131 650 6879     .oOo.  | | 2 Buccleuch Place,
EH8 9LW.        .oOo.  |
`-------------------------------'
`-------------------------------------------'


Date: Wed, 27 Nov 1996 11:52:31 GMT
From: Stephen Hickey ISI ext 53847 
To: sbk@fhcrc.org
Cc: gibian@stars1.hanscom.af.mil
Subject: Re: SUMMARY:  NIS+ root replica --> root
master

> To: sysadmin
> Subject: SUMMARY:  NIS+ root replica --> root master
> Status: RO
> 
>
==================================================================
> Date: Wed, 20 Nov 1996 11:07:32 -0800 (PST)
> From: Stuart Kendrick 
> Subject: SUMMARY:  NIS+ root replica --> root master
>
==================================================================
> 
> I asked about recovery strategies should a master
server croak.
> 
> There are no canned strategies -- no way to promote
a replica server to
> master, for instance.
> 
> In theory, it should be possible to take recent file
dumps and create a
> server from them.  And in theory, it could be
possible to restore from a
> recent backup.  I haven't tried either to date.  The
key issue would be
> whether or not current replica servers would survive
the experience.
> 
> Thanks to Marc Gibian for thorough reponses to this
and related issues.
> 
> --sk
> 

Hello, 

I did not see your original posting but I have some
info for you. 
It is possible to recreate your NIS+ master server
using several methods

- restore /var/nis and /etc/.rootkey
- recreate the NIS+ domain using previously dumped
NIS+ tables

Both methods work if you are "rebuilding" on the same
machine or using new
hardware because the original machine is dead! This
works because the server 
is only referenced using the IP address and name
(contained  in the 
/var/nis/NIS_COLD_START file. Providing these stay the
same, you NIS+ replicas
and clients will recover

The prefered method (for me!) is to restore /var/nis
and the /etc/.rootkey.

We have a cronjob that runs every day that dumps the
tables in text format and 
makes a "tar" of /var/nis and /etc/.rootkey. I have
attached the script. Have a look
at it and see if you find it usefull.

Hope this helps,

Steve.

_________________________________________________________________________
|                                                     
                 |
| Stephen Hickey        e-Mail    
Hickey.S@isi.bankgesellschaft.de     |
| UNIX System Admin.    Telephone  +(49) 030 245 53847
                 |
|_______________________________________________________________________|


> Original post and responses follow:
> 
> To: sun-managers@ra.mcs.anl.gov
> Subject: NIS+ root replica --> root master
> 
> It seems to me that once my master server is toast,
I can't manage
> my NIS+ domain anymore.  Does anyone know
differently?
> 
> -When the master is dead, the replicas still provide
all
> services to clients ... but I can't mod nor dump the
NIS+ tables.
> -When the master is dead, there is no way to convert
(promote) a
> replica to master.
> 
> Has anyone successfully recovered a master from
backup?  /var/nis,
> /etc/.rootkey, and /etc/nsswitch.conf would seem to
be the only needed
> items.  But it is not obvious to me what happens if
/var/nis from backup
> tape is "behind" /var/nis on a replica.  In theory,
time stamps should
> allow the replica to bring the recovered master back
in sync ...  Has
> anyone actually done this?
> 
> --sk
> 
> Stuart Kendrick
> Network Services
> FHCRC
> 
> Date: Wed, 13 Nov 1996 14:21:36 -0500
> From: "Marc S. Gibian" 
> To: sbk@fhcrc.org
> Subject: Re: NIS+ root replica --> root master
> 
> You are correct that root replicas don't buy you as
much as one
> might think should your root master fail. I have
been developing
> procedures/scripts and what have you for my
customer's product including
> the area of NIS+ management. One case we care about
is when a root master
> goes away without notice. I originally thought that
setting up root
> replicas would allow us to just convert a root
replica into the new root
> master. WRONG! You can't get there from here... the
procedure Sun makes
> available for converting a root replica into a root
master requires the
> original root master to be running, although even
then the procedure
> never has worked for us. I believe you CAN use the
technique for dumping
> NIS+ table contents to flat files, used for changing
IP address of root
> masters, to get checkpoints from which you can then
create a new root
> master if needed. We haven't had time to try this,
but given that I
> have the IP change working (for the root master) and
it uses the same
> technique, I think it should work (let me know if
you try it).
>
> Personally, I believe two critical shortcomings in
NIS+'s implementation
> are:
>
> 1. No integral mechanism for changing IP addresses
on servers. This CAN
> be done, but only through a lengthy and error prone
procedure (though I
> have it encapsulated in a (huge) shell script).
>
> 2. No integral mechanism for converting a root
replica into the root
> master.
>
> Unfortunately, my customer has no software support,
so I can not submit
> these as problem reports to Sun.
> 
> -Marc
> 
> Marc S. Gibian
> Telos Consulting Services     phone: (617) 377-6350
> PRISM/TFS                     email:
gibian@stars1.hanscom.af.mil


#!/bin/sh -f
# - dump_all_tables
# Could be run by cron...
# First saves the old nis info then dump the new
tables,
# /var/nis and /etc/.rootkey

echo "dump_all_tables: Starting ......\c"

NIS_D="/export/home1/root/NIS_source"
NIS_SAFE_D="/export/home1/root/NIS_safe"

#
# Save the old info...
#
ls ${NIS_D} | while read MY_FILE
do
        /usr/bin/mv ${NIS_D}/${MY_FILE} ${NIS_SAFE_D}
done

#
# Dump all the tables...
#
/usr/lib/nis/nisaddent -d passwd >                    
         ${NIS_D}/passwd
/usr/lib/nis/nisaddent -d ethers >                    
         ${NIS_D}/ethers
/usr/lib/nis/nisaddent -d group  >                    
         ${NIS_D}/group
/usr/lib/nis/nisaddent -d hosts >                     
         ${NIS_D}/hosts
/usr/lib/nis/nisaddent -d netmasks >                  
         ${NIS_D}/netmasks
/usr/lib/nis/nisaddent -d networks >                  
         ${NIS_D}/networks
/usr/lib/nis/nisaddent -d netgroup >                  
         ${NIS_D}/netgroup
/usr/lib/nis/nisaddent -d protocols >                 
         ${NIS_D}/protocols
/usr/lib/nis/nisaddent -d rpc >                       
         ${NIS_D}/rpc
/usr/lib/nis/nisaddent -d services >                  
         ${NIS_D}/services
/usr/lib/nis/nisaddent -d -t timezone.org_dir timezone
>        ${NIS_D}/timezone
/usr/lib/nis/nisaddent -d -t auto_home.org_dir
key-value >      ${NIS_D}/auto_home
/usr/lib/nis/nisaddent -d -t auto_master.org_dir
key-value >    ${NIS_D}/auto_master
/usr/lib/nis/nisaddent -d -t bootparams.org_dir
key-value >     ${NIS_D}/bootparams
/usr/lib/nis/nisaddent -d -t auto_direct.org_dir
key-value >    ${NIS_D}/auto_direct
/usr/lib/nis/nisaddent -d -t auto_apps.org_dir
key-value >      ${NIS_D}/auto_apps
#
niscat mail_aliases.org_dir >                         
         ${NIS_D}/aliases
#
/usr/lib/nis/nisaddent -d netid >                     
         ${NIS_D}/netid
/usr/lib/nis/nisaddent -d publickey >                 
         ${NIS_D}/publickey
/usr/lib/nis/nisaddent -d shadow >                    
         ${NIS_D}/shadow
#
# Save also the /var/nis directory in compress form
and the /etc/.rootkey
#
/usr/bin/tar cfp ${NIS_D}/var_nis.tar /var/nis
/usr/bin/compress ${NIS_D}/var_nis.tar
#
/usr/bin/cp -p /etc/.rootkey ${NIS_D}/safe.rootkey
#

echo "Done"

exit



SRDB ID: 10941
SYNOPSIS: NIS+ error messages
DETAIL DESCRIPTION:

The following NIS+ error messages appear on the
client:

- authdes_seccreate: unable to gen conversation key
- authdes_marshal: DES encryption failure
- authdes_validate: DES decryption failure
- authdes_refresh: unable to encrypt conversation key

These error messages are among those displayed on the
server side:

- _svcauth_des: no public key for 
- _svcauth_des: key_decryptsessionkey failed for 
- _svcauth_des: bad nickname
- _svcauth_des: decryption failure for 
-_svcauth_des: encryption failure
- _svcauth_des: corrupted window from 
- _svcauth_des: replayed credential from 
- _svcauth_des: invalid timestamp received from 
- _svcauth_des: timestamp is earlier than the one
previously seen from
   
- _svcauth_des: timestamp expired for 

SOLUTION SUMMARY:

The following are some of the NIS+ error messages that
may appear
on the client or the server.  This is not a complete
list of all NIS+
messages.  Another good reference besides this article
includes the
Solaris 2.4 manual, "Name Services Administration
Guide".

Client Messages

A. authdes_seccreate: unable to gen conversation key
     Keyserv is unable to generate a random DES key.
     This is not recoverable without user/admin.
intervention.
  
   Possible causes:
   - Keyserv is down or not responding.
   - Keyserv was restarted but other long running
processes
     that use secure-rpc (or make nis+ calls) were not
started.

   Possible action:
   - Check if keyserv is running/responding.  If it is
not
     then start it, start other processes, and do a
keylogin.
   - Restart processes that log this error (most
likely,
     automountd, rpc.nisd, and sendmail).

B. authdes_marshal: DES encryption failure
   authdes_validate: DES decryption failure
     DES encryption/decryption of some authentication
data failed.
     This is not recoverable without admin.
intervention.
  
   Possible causes:
   - Corruptedargument to a library function.
   - Problem with DES chip (if used).

   Possible action:
   - Call Sun customer service and report the problem.

C. authdes_validate: verifier mismatch
     The timestamp (T{n}) that the client sent to the
server does not
     match the one received from the server.
     This is not recoverable within a secure-rpc
session.
       
     Possible causes:
     - Client/server cache corrupted -
sessionkey/timestamp.
     - Server deleted session key from cache for still
active sessions.
     - Network data corruption.

     Possible actions:
     - Re-execute command

D. authdes_marshal: DES encryption failure
     Client/server clock synchronization fails.
     This is automatically recoverable within a
session.
 
     Possible causes:
     - Rpcbind on server not responding.

     Possible actions:
     - Admin. should manually synchronize the clocks
if
       this message is followed by any timestamp
related error(s).
     - Check remote rpcbind.
 
E. authdes_refresh: unable to encrypt conversation key
     Keyserv fails to encrypt the session key with the
publickey given.
     This is not automatically recoverable within a
session.
        
     Possible causes:
     - Keyserv is dead or not responding.
   - Client has not keylogged in.
     - Client (host) does not have credentials.
     - DES encryption failure -- see B above.
     - Keyserv was restarted but not the other long
running processes
       that use secure-rpc (or make nis+ calls).

Possible actions:
     - Check if keyserv is running/responding.  If it
is not
       then start it and do a keylogin.
     - Restart processes that logs this error (most
likely,
       automountd, rpc.nisd and sendmail).
 
Server Messages

F. _svcauth_des: no public key for 
     Server cannot get clients' publickey.
     This is not recoverable without user/admin.
intervention.
     Error returned to client = AUTH_BA DCRED.

     Possible causes:
     - Specified principal has no publickey.
     - Depending on the Name Service switch
(/etc/nsswitch.conf), the
       name service specified is not responding.

     Possible actions:
     - Check if principal has "DES" credentials, if
not add
       and keylogin.
     - Check if name service is responding.
 
G. _svcauth_des: key_decryptsessionkey failed for 
     Keyserv fails to decrypt the session key with the
publickey given.
     This is not automatically recoverable within a
session.
     Error returned to client = AUTH_BADCRED.

     Possible cause(s):
     - Keyserv is dead or not responding.
     - Server principal has not keylogged in.
     - Server principal (host) does not have
credentials.
     - DES encryption failure.
     - Keyserv was restarted but other long running
processes
       that use secure-rpc (or make nis+ calls) were
not.

     Possible actions:
     - Check if keyserv is running/responding, if it
is not
       then start it and do a keylogin.
     - Restart processes that logs this error (most
likely,
       automountd, rpc.nisd and sendmail).
 
H. _svcauth_des: bad nickname
     The nickname received from the client is invalid,
probably corrupted
     along the way.
     This is not automatically recoverable within a
session.
     Error returned to client = AUTH_BADCRED.

     Possible causes:
     - Congested network.

     Possible action(s):
     - None
         
I. _svcauth_des: decryption failure for 
   _svcauth_des: encryption failure
     DES encryption/decryption of some authentication
data failed.
     This is not recoverable without admin.
intervention.
     Error returned to client = AUTH_FAILED.

     Possible causes:
     - Corrupted argument to library function.
     - Problem with DES chip (if used).
  
Possible actions:
     - Call Sun customer service and report the
problem.

J. _svcauth_des: corrupted window from principal
     The window sent does not match the one sent in
the verifier.
     This is not recoverable without user/admin.
intervention.
     Error returned to client = AUTH_BADCRED.

     Possible causes:
     - Server's key-pair changed, client used server's
old public
       key and server has new secret key cached with
keyserv.
     - Client's key-pair changed and client has
notre-keylogged
       in on the client system (i.e. using client's
old secret key),
       and server uses client new public key.
     - Network corruption of the data.

     Possible actions:
     - Re-keylogin on both client and server.
     - If using NIS+, check that the correct public
key is
       cached in the directory object(s).

K. _svcauth_des: replayed credential from 
     This is seen if the server receives a request and
finds an entry
     in its cache for the same client name and
conversation key but the
     timestamp in the request is before the one in the
cache.
     This is not recoverable without user/admin.
intervention.
     Error returned to client = AUTH_REJECTEDCRED.
        
     Possible causes:
     - Clock skew between client and server.
     - Server receives subsequent requests in random
order.
        
     Possible actions:
     - Synchronize client/server clocks.
     - Use tcp if supported by the application.

L. _svcauth_des: invalid timestamp received from 
     Timestamp received from client is corrupted or
server decrypts using
     the wrong key.
     This is not recoverable without user/admin.
intervention.
     Error returned to client = AUTH_BADVERF on
initial requests,
     REJECTEDVERF on subsequent requests.
      
     Possible causes:
     - Congested network.
     - Server cached out the entry for this client.
       
     Possible actions:
     - Re-execute command.
     - Check the network load.

M. _svcauth_des: timestamp is earlier than the one
previously seen from
   
     Timestamp received from client (subsequent calls
only) is earlier
     than the one seen previously from this client.
     This is not recoverable without user/admin.
intervention.
Error returned to client = REJECTEDVERF
        
     Possible causes:
     - Clock skew between client and server.
     - Server cached out the entry for this client.
       
     Possible actions:
     - Synchronize client/server clocks.
     - Re-execute command.
 
N. _svcauth_des: timestamp expired for 
     Timestamp received from client is not within the
window sent.
     This is not recoverable without user/admin.
intervention.
     Error returned to client = AUTH_BADCRED on
initialrequests,
     REJECTEDVERF on subsequent requests.
        
     Possible causes:
     - Window too small to account for slow
servers/network congestion.
     - Client and server clocks differ enough that the
window cannot
       for the skew.
     - Server has cached out the client entry.
       
     Possible actions:
     - Synchronize client/server clocks.

PRODUCT AREA: Gen. Network
PRODUCT: NIS+
SUNOS RELEASE: Solaris 2.3
HARDWARE: any



---------- Forwarded message ----------
Date: Tue, 25 Feb 1997 19:36:22 +0100 (MET)
From: Martin Trampler 
To: Stuart Kendrick 
Subject: nischmod n-r x.org_dir

Hi Stuart,

>>>>> "SK" == Stuart Kendrick  writes:

    SK> I ran this command for the standard tables in
the NIS+ space,
    SK> e.g. foreach x in (auto_home, auto_master,
bootparams, cred,
    SK> ethers, group, hosts, mail_alaises, netgroup,
netmasks,
    SK> networks, passwd, protocols, rpc,
sendmailvars, services,
    SK> timezone).  As I understand it, this removes
read permission
    SK> for unauthenticated NIS+ users (NIS+ group
"nobody") on all
    SK> tables.

Well, actually all I can give you is an excerpt from
the NIS+ Manpage:
-----------------------
Note that for bootstrapping reasons, directory objects
 that
are  NIS+  domains,  the  org_dir  subdirectory and
the cred
table within that subdirectory must have read access
to  the
nobody  principal.   This  makes navigation of the
namespace
possible when a client is in the  process  of 
locating  its
credentials.   Granting  this access does not allow
the con-
tents of other tables within org_dir to be read (such
as the
entries in the password table) unless the table itself
gives
"real" access rights to the nobody principal.
-----------------------

Since I'm only a novice in the black magic of NIS+ I
can't help you
much farther, but here are my 2cents (actually
pfennigs) to your
questions:

1.) Why does removing read permission for group nobody
on the services
    table disable telnet, ftp, etc.?

It should do this only for users who lack
nis+-credentials. These
programs make all kind of system-calls
(getprotobyname, gethostbyname)
which depend on the tables in org_dir

2.) Why does removing read permission for group nobody
cause this slow
    and painful death of the NIS+ space

The secret key of nis+-principals is stored by a
daemon (keyserv). It
stays there, even after the principal logged out. The
cached value is
removed from the keyserv after an explicit
"keylogout". I think (can't
verify it) that the key also expires from keyserv
after a specific
amount of time if it's no longer used. If the
principal needs to
regain his secret key (which is encrypted with his
login-passwd and
stored in cred.org_dir) but cred.org_dir is not
readable for him (who
-at this stage- has not authentification) he can't get
his encrypted
key. (What I just wrote makes sense for "human" users.
Workstations
have their decrypted private key stored in
/etc/.rootkey, so from the
top of my head I can't tell why this should happen for
Machines)

3.) Is there a way for me to fix this remaining cred
table problem, 
    short of nuking the NIS+ space and rebuilding it
from scratch?

>From here I can't tell. If I were you, I would (after
having read the
Manpages and Answerbook-Entries) do some "niscat -o
...", nisls ...,
and nis... to get a better understanding of the
problem. Have you
tried an explicit "keylogin" as member of the admin
group ?

Sorry not to be able to solve your problem but maybe I
could give you
some hints what to look for.

Cheers

   Martin Trampler




---------- Forwarded message ----------
Date: Tue, 18 Mar 1997 09:50:19 +1100 (EST)
From: David Montgomery 
To: Stuart_Kendrick 
Subject: Re: nispopulate

> 
> Hi David,
> 
> OK, I'm interested in your expect script.  Would it
be possible for you to
> send that to me?

#! /usr/local/bin/expect --
set user $env(LOGNAME)
stty -echo
send_user "Password: "
expect_user {
        timeout {
                send_user "\nSorry\n"
                exit
        } -re "(.*)\n" {
                set password $expect_out(1,string)
        }
}
send_user "\n"

send_user "Verify Password: "
expect_user {
        timeout {
                send_user "\nSorry\n"
                exit
        } -re "(.*)\n" {
                set password1 $expect_out(1,string)
        }
}
send_user "\n"

if {[string compare $password1 $password]} {
        send_user "\nPassword mismatch.\n"
        exit
}

spawn /bin/keylogin
expect "Password:"
send "$password\r"
spawn /bin/chkey
expect "Secure-RPC password for $user:"
send "nisplus\r"
expect "login password for $user:"
send "$password\r"
stty echo
expect eof

> More importantly, though, I am having trouble with
the nisaddent commands.
> Sometimes they work ... and sometimes they don't. 
By "work" I mean
> sometimes the user can login afterward ... and
sometimes they can't.
> 
> And I can't even change their password from root. 
If I type "passwd
> {name}", I am prompted for their *current* login
password ... which of
> course I don't know.
> 
> Of course, sometimes the nisaddent procedure works
fine, users can login,
> can run nisclient, everything is wonderful.
> 
> Have you had this experience?  Or does nisaddent
work reliably for you?

I had trouble with it months ago when I started
playing around with a test
namespace and since time was running out I put it in
the "too hard basket".
Now that the start of term rush is almost over I'll be
looking at this as
well as other methods of making NIS+ administration
simpler.

> 
> --sk
> 
> On Sat, 8 Mar 1997, David Montgomery wrote:
> 
> > Hello Stuart,
> > 
> > > 
> > > I want to import an /etc/passwd and an
/etc/shadow file into the NIS+
> > > space.
> > >
> > > nispopulate -v -F -d {domain} -l {string} -p
/nis+files If I use
> > > the above command (where /nis+files contains
passwd and shadow and
> > > "string" is an eleven character alpha-numeric
string), then I get
> > > appropriately populated passwd and cred tables
... but those users
> > > can't log in. I can reset their password, using
"passwd" from the
> > > root account, and then they can log in. And run
nisclient -u to sync
> > > their NIS+ and login passwords. But that is
tedious.
> > >
> > > nisaddent -mvf passwd passwd nisaddent -mvf
shadow shadow If I run
> > > these two commands (after cd'ing to /nis+files),
then users can log
> > > in fine. But they have no credentials. I have to
run nisclient -c for
> > > each and every one. Then, each user can run
nisclient -u to sync NIS+
> > > and login passwords. Tedious.

> > This is the approach I took. After adding new
users I have a script to
> > run nisclient -c for them. I also have an expect
script which prompts
> > for the user's login password then does a keylogin
and chkey (using the
> > default network password which I use). This way
the users doesn't need
> > to know anything about a "network password". It
worked ok for about
> > 1000 accounts last week. Do you want a copy of the
expect script?
> > 
> > > 
> > > Neither solution scales to large numbers. Now, I
could write an
> > > expect script which automates the manual,
per-user steps, but this
> > > would be a lot of work. Isn't there a canned
strategy? Why doesn't
> > > nispopulate work? (or, rather, it works fine ...
but no one can log
> > > in until I've reset their passwords.)
> > >
> > > And is there anyway around requiring each user
to run nisclient -u?
> > > Or is that an unavoidable step?
> > >
> > > Solaris 2.5.1 with a selection of the latest
patches.
> > > 
> > 
> > David Montgomery
> > Department of Computer Science
> > University of Newcastle
> > University Drive                    Phone: +61 49
216174
> > Callaghan 2308 NSW                  Fax  : +61 49
216929
> > AUSTRALIA                           Email:
david@cs.newcastle.edu.au

David Montgomery
Department of Computer Science
University of Newcastle
University Drive                        Phone: +61 49
216174
Callaghan 2308 NSW                      Fax  : +61 49
216929
AUSTRALIA                               Email:
david@cs.newcastle.edu.au


SRDB ID: 15047
SYNOPSIS: Unable to authenticate
NIS+ server

DETAIL DESCRIPTION:

"nisaddcred" failed with the error message "Unable to
authenticate NIS+ server"


POSSIBLE CAUSE or USER ERRORS
-----------------------------
(In no particular order.)

- Change root password in /etc/passwd on a NIS+ server
without re-encrypting
  the secret key stored in the cred table. Should do
"chkey -p" immediately
  after changing the password.
 
  *Note that this problem may lurk for some time. If
the superuser secret
  key is already stored in the keyserv when the root
password is changed,
  you'll probably not see any problem until the
keyserv is restarted (usually
  at the next system reboot).
 
- Remove DES cred table entry for any NIS+ server.
 
- Overwrite existing credentials, by executing
nisaddcred,
  chkey (without "-p"), or newkey for any NIS+ server.
 
- Keyserv killed and not restarted on any NIS+ server.

- Keyserv restarted on NIS+ server, without restarting
rpc.nisd. The
  rpc.nisd has an open connection to the existing
keyserv, and is
  unable to re-open that connection.
 
- /etc/.rootkey removed, or replaced with a copy that
doesn't match the
  secret key stored in the cred table, and internally
in the NIS+ table
  headers.
 
- The publickey entry in /etc/nsswitch.conf isn't just
"nisplus", so
  secure RPC keys can be obtained from some source
(NIS, files) that is
  inconsistent with the NIS+ tables.

SOLUTION SUMMARY:

Several SRDBs discuss recovering from the lost or
corrupted 
encrypting key, but there is no sure and safe scheme
to retrieve 
the public key once it is mingled.

The following two methods will bring the NIS+ back in
operation.

1)  Rule #1 with NIS+.  BACK UP the /var/nis directory
of all the NIS+ 
    servers.   Recovery from tape always works.

2)  If that is not available, dump the contents of
NIS+ namespace, and
    reinitialize the NIS+ server.   
 
 Run the following Bourne-shell script:
 
#!/bin/sh
# GENERIC NIS+ DUMP SCRIPT
 
if [ ! -d /etc/nis+files ]
then
        mkdir /etc/nis+files
fi
cd /etc/nis+files
 
/usr/lib/nis/nisaddent -d aliases > aliases
/usr/lib/nis/nisaddent -d bootparams > bootparams
/usr/lib/nis/nisaddent -d ethers > ethers
/usr/lib/nis/nisaddent -d group > group
/usr/lib/nis/nisaddent -d hosts > hosts
/usr/lib/nis/nisaddent -d netgroup > netgroup
/usr/lib/nis/nisaddent -d netid > netid
/usr/lib/nis/nisaddent -d netmasks > netmasks
/usr/lib/nis/nisaddent -d networks > networks
/usr/lib/nis/nisaddent -d passwd > passwd
/usr/lib/nis/nisaddent -d protocols > protocols
/usr/lib/nis/nisaddent -d publickey > publickey
/usr/lib/nis/nisaddent -d rpc > rpc
/usr/lib/nis/nisaddent -d services > services
/usr/lib/nis/nisaddent -d shadow > shadow
/usr/lib/nis/nisaddent -d timezone > timezone
/usr/lib/nis/nisaddent -d -t auto_home.org_dir
key-value > auto_home
/usr/lib/nis/nisaddent -d -t auto_master.org_dir
key-value > auto_master
 
# End of script

Clean out leftover NIS+ material and processes by
following these steps:
1. Issue the following commands from the Bourne shell:
 
          /etc/init.d/rpc stop
          rm -f /etc/.rootkey
          rm -rf /var/nis/*
          cp /etc/nsswitch.files /etc/nsswitch.conf
          /etc/init.d/rpc start
          

Login and initialize NIS+ on the new root master by
following these steps:

1. Login as root on new root master.
2. Set the domain name with the following command:

       % domainname top.com

  NOTE: DO NOT USE PERIOD AFTER COM!

3. Re-direct domainname output into /etc/defaultdomain
with the
   following command:

        % domainname > /etc/defaultdomain

4. Run the nisserver script.

   For YP compat support, use the following command:

        % /usr/lib/nis/nisserver -r -Y

   For default support, use the following command:

        % /usr/lib/nis/nisserver -r

5. Populate the new NIS+ tables with the nispopulate
   command.  If you want to restore your original
data, change
   directory to the directory you used to backup your
original:
 
        % /usr/lib/nispopulate -F -p /
 
   where  is the location of the original NIS+ data.
 
The root master is now set up.
 
You must change each NIS+ client to match the new
domain name,
IP address network prefix (if required), and client
binding.
 
You updated the hosts map in /etc/nis+files to reflect
all new IP address assignments, host names, and so
forth.
 
If the IP address needs to be changed on the client to
match the new
network portion of the NEW ROOT MASTER's IP address,
do the following:
 
1. Login as root on client.
 
2. Run the/usr/sbin/sys-unconfig command on the
client. This script
   removes all references to the old IP address, host
name, network
   service information and so forth.
 
3. Enter the new information after the system reboots
from the sys-unconfig
   command.
 
4. When sys-unconfig asks for Network Information
Service, close NIS+ client.


PRODUCT AREA: Gen. Network
PRODUCT: NIS+
SUNOS RELEASE: Solaris 2.x
HARDWARE: any

refer to infodoc #11988 NIS+ PSD/FAQ

edit your /etc/nsswitch.conf file after you make the
system an nis+ 
root master, replica, or client 

 these lines should appear as follows
(assuming you also use dns for name service lookups)

hosts: files nisplus dns
rpc: files nisplus
services: files nisplus
netmasks: files nisplus


Note Adminsuite 2.3 is released and it also has
patches


2.5.1 


Make sure your systems are up to rev for the patches



103612-26: SunOS 5.5.1: libc, libnsl, nis_cachemgr and
rpc.nisd patch
103903-03: SunOS 5.5.1: /kernel/drv/le patch
103640-08: SunOS 5.5.1: kernel patch
103630-06: SunOS 5.5.1: ip ifconfig arp udp icm
103582-12: SunOS 5.5.1: /kernel/drv/tcp and
/usr/bin/netstat patch
103738-03: SunOS 5.5.1: /usr/sbin/syslogd patch
103699-01: SunOS 5.5.1: ping dumps core when packet is
blocked
104317-01: SunOS 5.5.1: nfsd patch
104166-01: SunOS 5.5.1: usr/lib/nfs/statd patch
104334-01: SunOS 5.5.1: lockd patch
104672-02: SunOS 5.5.1: usr/lib/fs/nfs/mount patch
103591-07: SunOS 5.5.1: /kernel/fs/ufs and
/usr/lib/fs/ufs/fsck fixes
103847-02: SunOS 5.5.1: /usr/lib/fs/ufs/ufsdump patch
104490-01: SunOS 5.5.1: ufsrestore patch
104742-01: SunOS 5.5.1: usr/lib/fs/ufs/mkfs patch
104266-01: SunOS 5.5.1: inetd patch
104654-02: SunOS 5.5.1: automountd patch
103600-14: SunOS 5.5.1: nfs, tlimod and rpcmod patch
104331-02: SunOS 5.5.1: rpcbind patch
103597-01: SunOS 5.5.1: sockmod fix

103502-04: Soltice AdminSuite 2.2 AdminSuite patch
103558-07: SunOS 5.5.1: admintool patch
103680-01: SunOS 5.5.1: nscd/nscd_nischeck rebuild for
BIND 4.9.3
103686-02: SunOS 5.5.1: rpc.nisd_resolv patch
103643-04: SunOS 5.5.1: /usr/lib/nis/nisaddent fixes
103785-01: SunOS 5.5.1: nss_nisplus.so.1 patch
103995-01: SunOS 5.5.1: rpc.nispasswdd patch
104255-01: SunOS 5.5.1: POINT PATCH: 1257084 -
/usr/lib/nss_nis.so.1
103770-03: SunOS 5.5.1: nistbladm patch

Generic compilation tip sheet for nis+ questions

___________________________________________________________________________

To prepare for the upgrade of the root master to the
next release of the o/s

Run checkpoint on the original root master.
Perform  a zero level dump of the root master.
Create the ascii files from which you will rebuild the
root master

(see below for commands in a script)

Copy /etc/nsswitch.files to /etc/nsswitch.conf
remove or rename /etc/.rootkey , /var/nis tree, and
/etc/defaultdomain

then upgrade to 2.5.1 reboot to single user mode
and apply the recommended 2.5.1 patches

OR

start with a fully patched next release of o/s
networked system 

Then make this system a nis+ root master following
guidelines
in the Solaris documentation using the ascii files as
the source
for the build of the nis+ database files.

*Note /etc/nsswitch.conf for all systems, you will
need to
edit on root master and replica afer these are built.

hosts: files nisplus dns
rpc: files nisplus
services: files nisplus
netmasks: files nisplus


Assure that client machines can bind to the new root
master.


Follow instructions to make another new o/s system a
replica server.
The root master and replicas should be at the same o/s
version.


That's it.


_____________________________________________________________________________

Run checkpointing on a regular basis so that the log
file is
flushed to permanent disk resident database entries.

We recommend this order....

nisping -C your.domain.name.
nisping -C org_dir.your.domain.name.
nisping -C group_dir.your.domain.name.
nisping your.domain.name.
nisping org_dir.your.domain.name.
nisping groups_dir.your.domain.name.

Commands should be put in cron and run at least once a
day; and, more often,
if there are a lot of NIS+ transactions throughout the
day that create a
large log file.

Refer to the following Solaris documentation

NIS+ and DNS Setup and Configuration Guide-this is
about 1/4 inch
thick and it is essential that you read this manual
and then go on
to use this next document for reference

NIS+ and FNS Adminsitration Guide

This script can be used to make sure you have ascii
files from
which to rebuild a nis+ root master. You should run
this periodically
as an emergency procedure. Also make sure you have a
zero level dump
of /etc/.rootkey and /var/nis tree as the root master
can be rebuilt
if you can restore the files and directory tree. Both
methods should
be used to insure that you can bring the system back
promptly.
Both in the event of a hardware failure or if the
system cannot be
accessed for other reasons (root master password has
been changed
improperly).

___________________________________________________________________________
Instructions for dumping the NIS+ tables to ascii
files

This is shell script that will use nisaddent to dump
the
current NIS+ tables to ascii files in the
/etc/nis+files
directory, which will be created if it does not
already
exist.

Notice that it uses niscat to dump the automount
tables.

#!/bin/sh
if [ ! -d /etc/nis+files]
then
        mkdir /etc/nis+files
fi
cd /etc/nis+files
/usr/lib/nis/nisaddent -d aliases > aliases
/usr/lib/nis/nisaddent -d bootparams > bootparams
/usr/lib/nis/nisaddent -d ethers > ethers
/usr/lib/nis/nisaddent -d group > group
/usr/lib/nis/nisaddent -d hosts > hosts
/usr/lib/nis/nisaddent -d netgroup > netgroup
/usr/lib/nis/nisaddent -d netid > netid
/usr/lib/nis/nisaddent -d netmasks > netmasks
/usr/lib/nis/nisaddent -d networks > networks
/usr/lib/nis/nisaddent -d passwd > passwd
/usr/lib/nis/nisaddent -d protocols > protocols
/usr/lib/nis/nisaddent -d publickey > publickey
/usr/lib/nis/nisaddent -d rpc > rpc
/usr/lib/nis/nisaddent -d services > services
/usr/lib/nis/nisaddent -d shadow > shadow
/usr/lib/nis/nisaddent -d timezone > timezone
/usr/lib/nis/niscat auto_home.org_dir > auto_home
/usr/lib/nis/niscat auto_master.org_dir > auto_master
/usr/lib/nis/niscat auto_direct.org_dir > auto_direct


__________________________________________________________________________

How to modify an entry in a NIS+ table


Enter bourne shell by typing sh at root prompt

nistablm -m new-entry old entry

for example from page 213 of the NIS+ and FNS Admin
Guide

nistbladm -m name='R&D' Site=SanFran Manager=kuznetsov
\

[name='R&D', Site=SanFran,Manager=vattel],
depts.wiz.com.


nistbladm -m name=username home=newhomedir \

[name=username , home=oldhomedir] ,
passwd.org_dir.domain.


However, the nis+ team recommends you dump the passwd
table
edit it and rebuild the map when you need to make
changes to
hundreds of entries



_____________________________________________________________________________
Adding a nis+ user to a group

#nistbladm -m members=kevinb,charlie,bruce
[name=sysadmin]group

# niscat group

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,tty,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin:*:14:kevinb,charlie,bruce
nobody::60001:
noaccess::60002:
nogroup::65534:


_______________________________________________________________________________
Instrucions for modifying an automount table to be
maintained by nis+

USING THE BOURNE SHELL 

CREATE THE AUTO_DIRECT TABLE FIRST

# nistbladm -c automount_map key=S value=S
auto_direct.org_dir.labs.com.

POPULATE THE AUTO_DIRECT TABLE FROM THE ASCII FILE
/tmp/auto_direct

# nisaddent -rf /tmp/auto_direct -t
auto_direct.org_dir key-value

VERIFY THAT THE TABLE WAS POPULATED

# niscat auto_direct
/usr/dist2 -ro,intr,noquota newdist:/usr/dist
/opt -ro,intr,noquota newdist:/opt
___________________________________________________________________________
This procedure will remove a nis+ replica:
the order of the nisping -C is important do the
domainname first.

as root user on root master system:

1) nisrmdir -f -s  org_dir.yourdomainname.
							    ^ you need this 
		end dot example: nisrmdir -f -s roy org_dir.mdc.com.

2) nisrmdir -f -s  groups_dir.yourdomainname.
         nisrmdir -f -s roy groups_dir.mdc.com.

3) nisrmdir -f -s  yourdomainname.
         nisrmdir -f -s roy mdc.com.

4) nisclient -co  (This overwrites creds for replica
machine, it asks for root passwd of ex replica)

as root user on ex replica:

1) rm -r -f /var/nis/*
2) rm /etc/.rootkey
3) ps -ef |grep nis , kill pids for all nisd's and
nis_cachemngrs
4) nisclient -i -d  -h 
	ex: nisclient -i -d mdc.com. -h pat 
	(complains about cant find /var/nis coldstart file
ignore this)
5) reboot ex replica ( it will now be a nis+ client
only)..


 to redo as replica,  as root user on ex replica:

1) start rpc.nisd on 

as root user on root master system:
1) nisserver -R -d  -h  ex: nisserver -R -d 
		mdc.com. -h roy
2) nisping -C 
3) nisping -C groups_dir.
4) nisping -C org_dir. ex: nisping -C org_dir.mdc.com.
5) reboot replica..

sometimes the nisping -C complains that checkpoint
failed. Kill all nisd's on 
replica and restart one..  one time only, and try
again.

also: It will complain that nisd is busy when you do
nisping -C 
groups_dir. sometimes because the first checkpoint of 

org_dir is still going , try again in 5 minutes.

______________________________________________________________________________

 NIS+ tables - question
> 
> I have created an NIS+ table. printers.org_dir of
type printers.  I
> would like to populate it from a file. 
Unfortunately, the nisaddent
> command only supports the 17 standard table types. 
Do you have a quick
> way (short of perl scripting) of populating this
table from my existing
> file?

Assuming that you are running in the bourne shell and
the printer.org_table
is empty at this point try the following:

nisaddent -rf  -t printer.org_dir key-value.

This will put everything that is in the ascii file
into the nis+ table,
it does a complete replace of the table, another words
everthing the is in
the table prior to executing this command will be over
written.  If you
want to merge the data then use the -m option instead
of the -r option.
This is explained in the man pages of nisaddent.

_____________________________________________________________________________

Instructions for internet address change on NIS+
replica

 To change ip adress for root replica..

1) change address of replica in nis table..

a) vi /etc/hosts on master and nisaddent -rf
/etc/hosts hosts.

2) nisping org_dir

3) nisupdkeys -a -H  org_dir
4) nisupdkeys -a -H  groups_dir
5) nisupdkeys -a -H  `domainname`

6) change address in /etc/hosts on replica and reboot
it..


thats it>>

All clients will have wrong ip address cached untill
time to 

live expires and refreshes them. Unless you do a kill;

1) nis_cachemgr


2) nisinit -c -H rootmaster

3) nis_cachemgr -i


____________________________________________________________________________

adduser script

# more adduser
#
#!/bin/sh -v
/usr/bin/nistbladm -D owner=$1.labs.com. -a name=$1
uid=$2 gid=$3 home=/home/$1 
shell=/bin/sh shadow=::::::\
 passwd 
/usr/lib/nis/nisclient -co $1
/usr/bin/nischown $1 [cname=$1,auth_type=DES]cred
/usr/bin/passwd -r nisplus $1

1)This works for 2.5  for 2.4 use nispasswd instead of
passwd -r nisplus
2) replace any occurance of labs.com. with actual
domainname

example adduser bruce 1005 30 

___________________________________________________________________________-
Instructions for nis+, how to modify automount map on
root master

#!/bin/sh
if [ ! -d /etc/nis+files]
then
        mkdir /etc/nis+files

cd /etc/nis+files

/usr/lib/nis/niscat auto_master.org_dir > master

vi master and delete the  +auto_master line


nisaddent -r -f /etc/nis+files/master -t
auto_master.org_dir key-value

nisping org_dir if you have replicas

niscat auto_master.org to verify change took place

on the automount client machine 

automount -v 

_____________________________________________________________________________
Instructions for changing all ips in nis+ domain

This is a correction to first mail

1) login to root master and dump tables to flat files.
  a) mkdir /etc/nis+files
  b)cd /etc/nis+files
/usr/lib/nis/nisaddent -d aliases > aliases
/usr/lib/nis/nisaddent -d bootparams > bootparams
/usr/lib/nis/nisaddent -d ethers > ethers
/usr/lib/nis/nisaddent -d group > group
/usr/lib/nis/nisaddent -d hosts > hosts
/usr/lib/nis/nisaddent -d netgroup > netgroup
/usr/lib/nis/nisaddent -d netid > netid
/usr/lib/nis/nisaddent -d netmasks > netmasks
/usr/lib/nis/nisaddent -d networks > networks
/usr/lib/nis/nisaddent -d passwd > passwd
/usr/lib/nis/nisaddent -d protocols > protocols
/usr/lib/nis/nisaddent -d publickey > publickey
/usr/lib/nis/nisaddent -d rpc > rpc
/usr/lib/nis/nisaddent -d services > services
/usr/lib/nis/nisaddent -d shadow > shadow
/usr/lib/nis/nisaddent -d timezone > timezone
/usr/bin/niscat auto_home.org_dir > auto_home
/usr/bin/niscat auto_master.org_dir > auto_master
/usr/bin/niscat auto_direct.org_dir > auto_direct


 2) login to clients as root, one at a time. This
applies to replicas also.

   a) rm -f -r /var/nis/*
   b) rm /etc/.rootkey
   c) rm /etc/defaultdomain
   d) vi /etc/hosts and change ip addresses of host
and root machines
   e) cp /etc/nsswitch.files /etc/nsswitch.conf , halt
machine

 3) login to master as root
  
   a) rm -f -r /var/nis/*
   b) rm /etc/.rootkey
   c) vi /etc/hosts and change ip addresses of all 
machines
   d) cp /etc/nsswitch.files /etc/nsswitch.conf
   e) rm /etc/defaultdomain
   f) init 6 (this reboots master)

 4) login to master as root user and ;

   a) add /usr/lib/nis to path
	   example: in csh,  setenv PATH $PATH:/usr/lib/nis
   b) nisserver -r -d  domainname.
   c) cd /etc/nis+files, mv netid /tmp ,  mv 
publickey  /tmp .
   d) vi hosts and change ip adresses..
   e) nispopulate -F -d domainname.
   f) nisaddent -d publickey|grep unix.yourmastername
>> /tmp/publickey
	   (this will add masters current creds to bottom of
file)
   g) vi /tmp/publickey and remove first entry for
root master after making sure 
current cred for rootmaster
      added to bottom.
   h) nisaddent -rv -f /tmp/publickey publickey
	   (this resets all users rpc passwd to the one
before ip change)
   i) nisaddent -rv -f /tmp/netid netid
   j) nisping -C domainname.

 
  5) reboot clients and run     nisclient -i -d
domainnanme. -h rootmaster
  6) If you had replicas start rpc.nisd on those
clients one at a time.
  7) On root master run         nisserver -R -d
domainname. -h replica
  8) nisping all three directory objects
	  nisping -C org_dir , nisping -C groups_dir, nisping
-C domainname.
  9) reboot replica
  10) do 6 thru 9 for next replicas..

note: This will work for domain change also just skip
step 2 d , 3 c, 4 d.

________________________________________________________________________________

This procedure for changing the ip address for a nis+
root master 
server assumes the following:

1) You are either directly logged into the console as
root or you have telneted
   into the server as root.

2) Your credentials are good and the server is
authenicated.

3) You are running the bourne shell

4) You have read the entire procedure and understand
it before you start,
   if not please ask questions before starting.

5) You are familiar with nis+

Change the root master`s ip address in the nis+ hosts
table.  This is done
on the root master and the single quote found in these
commands are located
on the double quote and single quote key, not to be
confused with the quote
on the tilda key that is used for command
substitution.

         nistbladm -m addr= '[name=],hosts.org_dir'
         nistbladm -m addr=
'[name=loghost],hosts.org_dir'

Update the universal address of the root master
server.  Don't forget the 
trailing dot '.'.  This is done on the root master.

        nisupdkeys -a org_dir.`domainname`.     
        nisupdkeys -a groups_dir.`domainname`.
        nisupdkeys -a `domainname`.


Change ip address of the root master in /etc/hosts. 
This is done on the root 
master.

        vi /etc/hosts and change the address

Reboot root master

Kill the cache manager on the root master

        ps -ef | grep nis
        kill 

On the root replica, change ip address of the root
master in /etc/hosts

        vi /etc/hosts and change the address

Make sure the replicas /etc/nsswitch.conf hosts entry
has files first.

On the root replica, stop rpc, then get a new
cold_start file, then kill the 
cache manager, and then start rpc.

        /etc/init.d/rpc stop
        nisinit -c -H 
        /etc/init.d/rpc start
        kill  


On the root master, perform nisping to transfer the
new root.object

        nisping -r (this may take several minutes
depending on your network, so 
		be patient).

        nisping org_dir.`domainname`.
        nisping groups_dir.`domainname`.
        nisping `domainname`.

Verify that the domain still functions

        niscat, nisls, etc....

Restart the cache manager on the root master and the
replica.
        
        nis_cachemgr -i

Get new cold_start files for all nis+ clients by
running the following
commands on the nis+ clients.

        ps -ef | grep nis
        kill 
        nisinit -c -H hostname 
        nis_cachemgr -i


_______________________________________________________________________________

How to add user without adminsuite on 2.5 

go into bourne shell by typing sh at root prompt

rootmaster# sh

#nistbladm -a name=bruce passwd= uid=30001 gid=30005
gcos=Bruce home=/ 
shell=/bin/csh shadow=:::::::: passwd.org_dir

#nisping org_dir (if replicas)

#niscat passwd.org_dir | grep bruce

bruce::30001:30005:Bruce:/:csh:::::::::

# nisclient -co bruce

You will be adding DES credentials in domain xxx.com.
for bruce

** nisclient will overwrite existing entries in the
credential
** table for hosts and users spedified above.

Do you want to continue? (type 'y' to continue, 'n' to
exit this script) y

checking xxx.com. domain...

checking cred.org_dir.xxx.com. permission...

adding LOCAL credential for bruce...
adding DES credential for bruce...
Adding key pair for unix.30001@labs.com
(bruce.labs.com.).
Enter bruce's login password:
Retype password:
For all new NIS+ users added, you will need to update
their keys on all machines that they are currently
logged
in by running keylogin(1), chkey(1), or nisclient(1M).
# nispasswd bruce
New password:
Re-enter new password:
        NIS+ password information changed for bruce

The credential information for bruce will not be
changed.
        User bruce must do the following to update
his/her
        credential information:
        Use NEW passwd for login and OLD passwd for
keylogin.
        Use "chkey -p" to reencrypt the credentials
with the
        new login passwd.
        He/she must keylogin explicitly after his/her
next login.

#nisping org_dir(if replicas)

# niscat passwd.org_dir | grep bruce

bruce:QJAcjcbLZHboA:30001:30005:Bruce:/:/bin/csh:9612:-1:-1:-1:-1::0




_____________________________________________________________________________

The NIS+ PSD contains the same mistake I made after
reading the man page.

nisaddent -m (for merge) does not "add" records.

The PSD says:

   You can put new entries into a file, and then merge
those changes in:
 
     % nisaddent -m -f filename table-type
 
   For example:
 
     % nisaddent -m -f /etc/hosts hosts
 
The key thing that is wrong is "you can put new
entries into a file, and..."
                                            ^^^

If you put only the *NEW* entries in the file, then,
when you are done,
you will have **ONLY** the new entries in the table.

The difference between -m (merge) and -r (replace) is
*HOW* it does the work
not *WHAT* it does.  They both make the table look
like the file.

-r does it by removing everything in the table and
loading the file into it.

-m has the same result, but accomplishes it by a more
complex method:
   - compare the table to the file
   - ignore all the records which are the same in both
   - update the records that are different with the
contents of the file
   - remove the records in the table which are not in
the file
   - add the records in the file which are not already
in the table

   The intent is that -m will be much more efficient
in many cases.

   If you only have a few adds/modifies/deletes, use
nisaddent -m
   If more is changing than remaining the same, use
nissaddent -r
____________________________________________________________________________

NIS+ Credential Fix


Do all the the following as root in the bourne shell

*** kill nis_cachemgr and startup rpc.nisd at level
zero on all nis+ servers. 
***

kill   on all nis+ servers.
kill   on all nis+ servers.
rpc.nisd -S 0 on all nis+ servers.

*** Now redo the creds for the root master on the root
master ***

nisaddcred -p unix.@`domainname` -P .`domainname`. des

enter the root passwd when prompted for passwd.

(If the above command hangs then rm /etc/.rootkey and
kill keyserv)

*** next do the following  on the root master ***

rm /etc/.rootkey

kill < PID for keyserv>

*** EXECUTE THE FOLLOWING COMMANDS ON THE ROOT MASTER,
NOTE THE TRAILING DOTS 
THAT YOU MUST HAVE ON THE NEXT 3 COMMANDS ***

nisupdkeys org_dir.`domainname`.

nisupdkeys groups_dir.`domainname`.

nisupdkeys `domainname`.

*** nisping all 3 objects on the root master ***

nisping org_dir
nisping groups_dir
nisping `domainname`

*** On the root master execute the following. ***
keylogin -r

enter the root passwd when prompted

*** EXECUTE THE FOLLOWING COMMANDS ON THE REPLICA
SERVERS, NOTE THE TRAILING 
DOTS THAT YOU MUST HAVE ON THE NEXT 3 COMMANDS ***
 
nisupdkeys org_dir.`domainname`.
 
nisupdkeys groups_dir.`domainname`.
 
nisupdkeys `domainname`.

*** Now startup rpc.nisd at level 2 and startup
nis_cachemgr on all servers ***

kill rpc.nisd -S 0

rpc.nisd

/usr/sbin/nis_cachemgr -i

____________________________________________________________________________

To change a user's password.

You will need to install Adminsuite 2.2 or 2.3 and
corresponding patches in
order to change passwords for a user via the gui
interface to the databases
when you do not know the user's previous password (for
instance when the
user forgets the password).

The only way that you can change a password for a user
from the command line
mode is if you know the previous password, for
instance when a new account
has been setup.

Then you can use password -r nisplus username and
follow the directions.
Use man on password for additional information.

 Thank u all ...





__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Received on Fri Aug 24 11:53:17 2001

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:25:02 EDT