Details on NIS+ installation
Frequently asked Questions/Answers on Solaris 2.x,
in the area of networks
Q) What is NIS+?
A) Network Information Service (NIS+) is an enterprise level
naming service designed to serve small to very large
networks. It is a replacement for earlier NIS (nee YP) and a
complete rewrite. In NIS compatibility mode, NIS+ serves NIS
client requests as well.
Q) What are the key differences between NIS and NIS+?
A) There are many differences, but here are the main four
- NIS had a flat name space, while NIS+ is hierarchical. So
with NIS+ one can easily manage growth and changes.
- NIS+ is secure and allows fine grain access control.
- NIS+ updates are on incremental basis and much faster (in
minutes).
- NIS tables were single key-value pairs while NIS+ has
multiple key value pairs. This means that you can do
searches based upon a particular value of a particular key.
Q) How will I benefit from NIS+?
A) Now, one no longer has to wait for 24 hours or more to get
the maps propagated. NIS+ does fast incremental updates. So,
it should be very fast and easy to update any of these
changes
You will be able to traverse through all the domains without
much trouble. Earlier there was no easy way to find out
information about other domains.
You will get improved fault tolerance even if some of the
NIS+ server die. Your client will attempt to bind to any of
the NIS+ servers even if they are not the same subnet.
Your local sysadmin can set policies such that you can change
some of the fields of your entries. For example, you could
change your shell or home directory without going through a
sysadmin.
Q) Can I still use all YP/NIS commands?
A) This will depend upon whether there is a NIS server
available for your domain OR whether the NIS+ server is
running in YP compat mode. If it is, then one should be able
to make use of all YP commands except those commands that
change the NIS maps such as yppasswd or chkey for publickey
information.
Even if your NIS and NIS+ domainnames are not the same, one
can run ypset and bind it to a different domain than its own
local domain.
You will also notice some differences in terms of the names
of the automounter maps. These maps no longer have any
embedded dots '.' in them. Also, some of the maps may now
look different, for example, the hosts map. If some of your
applications use NIS API and refer to maps with embedded dots
in them, then they will not be able to find those maps.
We recommend that you use NIS+ commands for your queries.
Q) Can I revert back to using NIS?
A) That depends upon the way things were set up. If there is
still a NIS server on your subnet, it can still be done. The
main change required will be
- change your domainname back to what it was
- change your /etc/nsswitch.conf to your earlier set up
Q) Can I still send/receive mail outside my domain? Is my
NIS+ domain same as my mail domain?
A) Yes, you should be able to send/receive mail as earlier.
For mail purposes, you are still a part of the domain above
you. For example, if you are currently in XYZ.Eng.Sun.COM,
for mail purposes, you are in Eng.Sun.COM domain. Your email
address may change depending upon the new NIS+ domainnames.
Q) Can I do lookups in other domains?
A) Yes, you just need to specify the complete NIS+ name of
the table/entity that you are trying to locate.
Q) Can I log in on machines in other domains?
A) Only if your local credentials have been added to that
other domain.
Q) I am running 4.X. Can I run NIS+ on my machine?
A) No, not as a client. We only support 4.X NIS+ servers.
There is no support for any of the name service switch
and the associated getxxbyyy routines in libc. However, from
a NIS+ 4.X server, one can execute all NIS+ commands.
Q) Will conversion to NIS+ give me performance problems?
A) In normal operations, you should not see any impact. A
few things have speeded up substantially, for example, doing
su with NIS+ has become very fast.
One may find that the number of packets that go to the
network have increased in number. We hope to address that in
493 release.
Q) What are the known major problems with NIS+?
A) NIS+ servers (when running in NIS compatibility mode) can
serve NIS requests from 4.X clients but it cannot forward 4.X
DNS requests to the nameserver. This means that one cannot
talk to other DNS domains. This is not a problem with Solaris
2.0 clients which use the name service switch to get the
appropriate access.
The installation isnt exactly fool-proof. We hope to address
this in a future release.
Q) What is involved in setting up NIS+ on my desktop?
A) You should be running Solaris 2.0 or higher to be able to
run NIS+.
The following should be done:
- change your domainname to the new NIS+ domainname
- create /var/nis directory
- add the IP address for your NIS+ server in your /etc/hosts
file
- change your /etc/nsswitch.conf file to use NIS+ instead of
NIS
- adding /etc/resolv.conf file along with nameserver entries
- make changes to your /etc/auto files to refer to
automounter
maps in auto_form from auto.form.
- adding NIS+ credentials in the cred table for yourself as
well as for your machine.
Q) Why do I have to have all these passwds? NIS did not
require one.
A) NIS+ is secure. i.e. the NIS+ server before giving you
any information verifies that you indeed have the rights to
get access to that information. This security is based upon
secure RPC, which needs you to have publickey and secretkey
stored with NIS+; and your secretkey is encrypted with your
passwd. Hence you need this extra passwd during chkey time.
If this passwd is not the same as your login passwd, then
you will not be able to make NIS+ calls unless you have done
an explicit keylogin(1).
NIS was not based upon secure RPC. So, there was no need for
a passwd there. You still needed a passwd for logging in,
just as in the old time-sharing days.
Q) Can I have different passwd for NIS+ and logging in? Are
there any impact if I have my own entry in my local
/etc/passwd file?
A) yes, you can; but this would mean that you will have to do
a keylogin(1) before you can make any NIS+ operations. So,
we recommend that this not be the case. It is perfectly
reasonable to have your passwd entry also in the /etc/passwd
file; just make sure that it is the same as in passwd table.
The only problem is when you change your keys. During the
installation time, you would normally do a chkey, and chkey
being a user level program cannot read your /etc/shadow file.
So, as a workaround, set your passwd entry in
/etc/nsswitch.conf to nisplus and files, do the chkey and
then put it back the original way. You will also have to
change your passwds at two places, once in your local passwd
file and then in the NIS+ passwd table with passwd(1) and
nispasswd(1), respectively.
Q) My machine name collides with someone's login name. What
do I do? Why should I care? It worked earlier, now it does
not, why?
A) Clients of NIS+ (called as NIS+ principals) can be both
machines as well as normal users. The NIS+ principals are
named as use_login.domainname or machinename.domainname. For
example, my NIS+ principal name is name.eng.sun.com. My
machine's NIS+ principal name is machine.eng.sun.com.
NIS+ does not distinguish between the two - both of them have
their own associated credentials and NIS+ access control
mechanism uses it to allow/deny permission to access
information.
So, the machines and users now share the same name space. In
the past, this was not a problem because anyone could be a
client of NIS and access NIS information.
Approximately 10% of users may find this collision.
In such cases, preference is being given to the user. i.e.
the user gets to keep the same name and the machine's name
has to be changed. We suggest that you choose a new name for
your machine and add an alias for your machine's old name.
Q) Is it still possible to play around in a NIS+ domain and
yet use NIS domain (different from NIS+ domain) for daily
operations?
A) It is possible but the steps are slightly complicated. The
problem comes from the fact that the domain names are
different and that all entries in /etc/nsswitch.conf assume
that they are all to be resolved to the current domainname.
Here is the hack:
# domainname newNIS+domain
# edit /etc/nsswitch.conf file to have only files for
publickey. Comment out the entry for "nobody" in your
/etc/publickey file.
# Kill ypbind
# Add the IP address of the NIS+ server in /etc/hosts file
# nisinit -c -H server_name
# nis_cachemgr
# test it by doing nisls or any other NIS+ operation on
the NIS+ domainname
# domainname old_domain_name
# restart your ypbind
With this hack, you are now accessing NIS+ tables as "nobody"
and you will have to specify the complete directory name for
any operation. Also, now you cannot make any secure RPC call.
Q) I recently installed a 486/50 machine as an NIS client in
house. and connected to our local network via a THICK net
ethernet drop. I now have that machine up at a vendor site
who has THIN ethernet and is not running NIS+ nor NIS, so I
specified NONE during the configuration. This is a class B
address i.e. 130.35.19.70 and the subnet mask is ffff0000 .
However, I am not able to
a) talk to any other machines
b) OPENWINHOME hangs consistently.
A) If you are using THIN net then make sure you reconfigure
the smc card for THIN net, the default is usually THICK net.
If you are not getting any error messages from the smc driver
during boot up then the IRQ and I/O address should be
correct. However, there might be a conflict of the shared
memory address and usually this is with the disk controller.
Q) I'm trying to use NIS+ on a PC running Solaris 86.
I have an SS2 set up is the NIS+ master server.
NISD is running with a security level of 0. I've
followed the directions in answerbook for setting up
and NIS+ client. I've created an account called markl
on sparc2 ( the nis server ). I've put the home directory
in /home2/markl, and am using the automounter to give me
a home path of /home/markl. I can log onto sparc2 without
problems. When I try to login as markl on solaris86 ( the
intel box ), I'm told that I don't have a password and I
should make one. It runs the passwd command ( you can see the
word passwd on the screen ) and then there is not markl
account. Then back to login. When I login to root, and do a
csh, I can su markl, I can cd ~markl, I can niscat
passwd.orig_dir and see the passwd data. It has an entry for
markl. If I su to junk, I'm told the junk is not a valid
account. It seems that the NIS bindings are working, just not
login.
Also, I can go to a system running SunOs 4.1.2 as an NIS
client ( not NIS+ ) and login as markl.
Has anyone tested the NIS+ client with a Sparc based NIS+
master server. Anyone have any ideas on what I'm doing
wrong??
A) The following is the workaround for this problem:
Apparently this problem is caused by the passwd file is used
to populate the passwd table by using the nisaddent "passwd"
command, it assumes that the file is a 5.X passwd file and
hence does not populate the "shadow" column of the passwd
table. The sysadmin is then supposed to run the nisaddent
command with the equivalent shadow file.
e.g.
# cat /etc/passwd | nisaddent -v passwd
# cat /etc/shadow | nisaddent -v shadow
However, in this particular case, there was no equivalent
shadow file
available and hence the passwd col was empty and hence no one
could login to these machines.
Workaround #1:
The work around is as follows:
e.g.
The /etc/passwd need to contain the encrypted password.
# cat /etc/passwd | nisaddent -v passwd
# awk -F: '{printf("%s:%s:6445::::::\n", $1, $2)}'
/etc/passwd > /tmp/shadow
# cat /tmp/shadow | nisaddent -v shadow
Workaround #2:
The other way to solve this problem is to use the -y option
of nisaddent. This only works if the customer has a running
YP domain setup. First ypxfr the passwd map to the machine
and then use nisadent -y
# /usr/lib/netsvc/yp/ypxfr -c -d YP_DOMAINNAME -h YP_SERVER
passwd.byname
# /usr/lib/nis/nisaddent -y YP_DOMAINNAME passwd
With this way, there is no need to run any awk script and
everything works fine.
Q) The NIS+ server was unavailable and the clients were not
allowing logins. What needs to be done?
A) Change the following two lines in the nsswitch.conf file
passwd: files nisplus
group: files nisplus
to
passwd: files [NOTFOUND=return] nisplus
group: files [NOTFOUND=return] nisplus
You should be able to login now.
Q) What is the significance of having the default entry as
networks: nis [NOTFOUND=return] files
in /etc/nsswitch.conf ?
A) The reason that the default nsswitch.conf file contains
"[NOTFOUND=return]" is that we wanted the default behaviour
to be 4.x-compatible, and 4.x generally follows a policy of
"only look at 'files' if 'nis' is unavailable". Thus entries
like
networks: nis [NOTFOUND=return] files
do the right thing for 4.x-compatibility
_____________________________________________________________
Installation of admintool and host manager
Frequently asked Questions/Answers on Solaris 2.x,
in the area of networks
Q) What does the choice of name service in Host Manager and
User Account Manager mean?
A) The choice of NIS+, NIS, or None is typically per-network.
Usually you should specify it the same way every time you
start Host Manager or User Account Manager on a network. Do
not change name services per-host or per-user. If you need
to edit a particular record in a particular database stored
by a particular name service, you can use the lower level
tool Database Manager.
Q) If name service should always be the same, why do Host
Manager and User Account Manager present a choice?
A) Firstly, admintool can't always figure out what the right
answer is and so is asking you for verification. And
secondly, sysadmins with unusual configurations sometimes
need to override the choice of name service.
Q) Can I select a different name service for each host when
adding clients through Host Manager?
A) The simplest answer is "No". All centrally administered
Solaris hosts on a network should use the same name
service(s). Even though Solaris provides another name
service (NIS+), a new set of administration tools
(admintool), and the ability to control the order of name
service lookups by database (/etc/nsswitch.conf), it still
expects all centrally administered hosts on the network to
use the same name service(s).
Unfortunately the appearance of the admintool tools has
misled some users to conclude that use of different name
service(s) by different Solaris hosts was intended to be
fully automatic and transparent.
Q) Are there exceptions to the rule that all Solaris hosts on
a network should use the same name service(s)?
A) Yes. Some support is provided to ease transition from NIS
to NIS+, or from None to NIS+. Knowledgeable users can use
the None option to set up some test configurations. And
power users may wish to modify the /etc/nsswitch.conf file on
their workstation.
Q) Does saying that all Solaris hosts should use the same
name service(s) mean they should use only one name service?
A) No. Hosts normally use a combination of local and network
name services to allow both independent bootup and easy
normal operation, and to provide local overrides to network-
wide information. For example the template
/etc/nsswitch.nisplus allows local entries for passwd, group,
automount, and aliases to override network-wide information.
Q) /etc/nsswitch.conf appears to provide a great deal of
flexibility, some of which isn't used. What's the file for?
A) The initial motivation for /etc/nsswitch.conf was to give
users full control over where and in what order
gethostbyname() looked, similar to Ultrix. The
implementation scheme used was so simple and powerful that
its use was extended to cover most name service lookups
rather than just gethostbyname() calls. This increased
flexibility is available to all users.
As distributed, Solaris uses one of only three standard
configurations of /etc/nsswitch.conf (templates
nsswitch.nisplus, nsswitch.nis, and nsswitch.files),
depending on whether the network name service is NIS+, NIS,
or None. A simple change to activate DNS for gethostbyname()
calls is included in the comments inside
/etc/nsswitch.nisplus.
Q) Why is the None name service option provided?
A) The primary reason for the None name service option is to
support customers who won't run either NIS or NIS+. Most
such customers keep a master copy of /etc configuration files
on a central machine and use `rdist` or a similar tool to
broadcast copies to all workstations.
The second reason for the None name service option is to
support local overrides to network-wide information.
The third reason for the None name service option is to help
work around the lack of programmatic updates to NIS.
Finally, the None name service option supports quick setup of
demo or test configurations by knowledgeable users who either
can't or don't want to update the name service.
Q) If I explicitly specify a different name service when
adding a client, will Host Manager "make it right"? For
example, if my network is running NIS+, yet before adding a
new dataless client I specify None, will Host Manager update
all the right files in the right way to make the new client
known all across the NIS+ domain?
A) No.
There is no combination of file and name service updates that
will make all such mixed configurations work right. No
matter how hard Host Manager tried, some combinations would
never work. Non-support of different kinds of name service
clients on the same network shows up throughout Solaris; it's
not just a restriction imposed by the admintool tools.
Q) How do the admintool tools support NIS?
A) All NIS maps can be read by all admintool tools.
No NIS map can be programmatically updated by any admintool
tool. Users of any admintool tool on a network using NIS must
perform a manual procedure. That procedure involves
pretending to use None name service, capturing the changes in
/etc files, manually merging the changes into the NIS master
files and remaking the NIS maps, and cleaning up the /etc
files. The new information will not be known across the
entire NIS domain until all the push operations initiated
during the manual procedure have completed.
Note that neither this use of the None name service option as
part of the manual workaround procedure, nor the on-screen
documentation of this manual procedure by some admintool
tools, change the fact that admintool tools do not expect
different Solaris hosts on the same network to use different
name service(s).
Q) The message Host Manager gives when I select NIS and try
to do an operation that might involve updating maps seems to
imply the lack of support for NIS updates has something to do
with mixed OS versions, and might change in the future. Is
this true?
A) No. Programmatic updates to NIS are not possible with any
combination of OS versions. And so no admintool tools will
update NIS under any circumstances.
The message Host Manager gives intends only to state that the
tool can't update NIS programmatically then tell the user how
to do so manually. Unfortunately the message can be
interpreted more broadly than it was intended, and may
mislead some users.
Q) Why can't the admintool tools update NIS automatically?
A) The NIS protocol doesn't support updates by programs. In
SunOS 4.x the only way to update NIS was to edit the files on
the NIS master then run `ypmake`. Solaris isn't any
different.
In fact, Solaris doesn't support `ypserv` at all. Customers
are encouraged to migrate from NIS to NIS+. NIS+ provides
much better security, better performance, and can be updated
by programs. NIS+ supports a "NIS compatibility mode" to
ease the transition.
Q) What does it mean to say a printer is a NIS+ Printer?
A) Printer Manager maintains a list of "registered" printers
across a whole network as a convenience to system
administrators. Typically system administrators will
register each locally attached printer in the list as they
set it up, then refer to that list later when setting up
remote access to printers for a client.
The list of registered printers happens to be stored by NIS+,
and the label "NIS+" fits on the button better than the label
"registered". That's the only reason these printers may be
called NIS+ Printers. The "lp" subsystem knows nothing about
the list of registered printers. Registered printers don't
function any differently than unregistered printers.
_____________________________________________________________
IP interface
Frequently asked Questions/Answers on Solaris 2.x,
in the area of networks
Q) Is there documentation that describes the interface
between IP and network drivers, namely, the SUN specific
requirements not outlined in the DLPI Version 2
specification?
A) IP is a STREAMS module in Solaris 2.X. Any module or
driver interface with IP should follow the STREAMS
mechanism.There are no specific requirements for the
interface between IP and network drivers.
Q) When an ifconfig device0 plumb is issued, the driver
immediately receives a DL_INFO_REQ. Exactly what is required
in the DL_INFO_ACK from a Style 2 provider?
A) Please look at 'dl_info_ack_t' struct in
/usr/include/sys/dlpi.h.
Q) Is it possible for the driver to be a CLONE driver and
also a DLPI Style 2 provider?
Yes.
Q) If so, how do I map the minor number selected in the open
routine to an instance prior to a DL_ATTACH_REQ? The
technique of using the minor number to obtain the instance
in the getinfo routine is not valid prior to the
DL_ATTACH_REQ. How do you suggest this be handled?
A) The 'DL_ATTACH_REQ' request is to assign a physical point
of attachment(PPA) to a stream. The 'DL_ATTACH_REQ' request
can be issued any time after a file or stream being opened.
I don't think the 'DL_ATTACH_REQ' request has anything to do
with assigning, retrieving or mapping minor/instance
number. Of course, you can issue a 'DL_ATTACH_REQ' request
for a file or stream with desired major/minor number. To the
question of mapping minor number to instance, usually the
minor number(getminor(dev) is the instance number.
Q) In the examples a minor node is created each time the
driver's attach routine is called. How would a CLONE driver
attach to multiple boards, that is, have multiple instances,
and still only create one minor node?
A) For the CLONE driver, I don't know if it is possible to do
that. For the non-CLONE driver, it is possible to use the
bits information in a particular minor number, for example
'FF', to map all other minor nodes.
Q) Does Solaris 2.1 TCP/IP support Streams???
A) Yes, The TCP and IP are STREAMS modules in Solaris 2.1.
The command 'strconf < /dev/tcp' will show you the modules.
Q) Does SunOS 4.x TCP/IP support Streams??
No.
Q) Does Solaris 2.1 ethernet drivers support LLI 2.0
interfaces???
A) Do you mean 'DLPI'(Data Link Provider interfaces) ?
The Solaris 2.1 ethernet drivers, le and ie. both support
DLPI. Please see man pages of le and ie.
Q) Does Solaris 2.1 DLPI provide both connection oriented
services and connection less services. Also, is your DLPI
Version 2.0, which includes multicast facilities.
A) Yes and yes. Please see man page of 'dlpi'.
Q) Is multicasting supported on SunOS 4.x? If not, how can
the customer obtain this feature?
A) IP multicast is a standard supported feature in Solaris
2.x, but we don't support it in SunOS 4.x. If the customer
wants to run an unsupported IP multicast on his/her SunOS 4.x
machines, it can be got from public domain object
distribution that Steve Deering, the inventor of IP
multicast, distributes. This is available via anonymous FTP
from gregorio.stanford.edu in the file vmtp-ip/ipmulti-
sunos41x.tar.Z.
_____________________________________________________________
Questions on RPC and TLI
Frequently asked Questions/Answers on Solaris 2.x,
in the area of networks
Q) We are using the TLI functions such as t_open and t_bind
in one of our programs. When we do a t_bind call, why do we
get an M_DATA ioctl rather than an M_PROTO? Do you intend
to do this permanently?
A) The t_bind() function does local management, so M_DATA
ioctl is an appropriate message block.
Q) I'm looking for RPC development kit for Macintosh.
Can you help?
A) You probably could get those informations by calling
'Apple'.
Q) Does Solaris 2.1 support XTI or TLI interfaces?
A) Solaris 2.1 support TLI and will support XTI in the near
future. Please see "Solaris 2.1 Standards Conformance Guide".
You can do a search of 'TLI' on AnswerBook.
Q) Does SunOS 4.1 support XTI or TLI interfaces?
A) It supports TLI interfaces. Please see man pages of
't_open', 't_bind', 't_snd', 't_close' ... etc.
_____________________________________________________________
NFS interoperation
Frequently asked Questions/Answers on Solaris 2.x,
in the area of networks
Q) With Solaris 2.x configured as a client, nfs mount with
with HP-UX or AIX machines will not work, even though
dfshares shows that the file systems are exported.The error
message "Server not responding" appears.
A) The following workaround is suggested (to be done on
solaris 2.x machine):
1. Append the following two lines into /etc/system
set nfs:nfs_portmon=0
set nfs:nfs_fastpath=0
2. Cut the number of group that root belongs to 6 in
the /etc/group if this is the case. Usually it happens if
root belongs to 11 groups or more.