Subject: Solaris 2.x Freqeuntly Asked Questions - networking

Description :


아래 내용은 Network  관련하여 자주 제기되는 질문에 대한 답입니다.
참고하시기 바랍니다.



Frequently asked Questions/Answers on Solaris 2.x networking:

   NIS+
   admintool and networking
   IP interface
   RPC and TLI
   NFS interoperation


SOLUTION SUMMARY:

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.


KEYWORDS: NIS+, NIS, RPC, TLI, interoperability, admintool

OS RELEASE: Solaris x86

Revision History

작성일자 : 96.06.12
작성자 : 김현

수정일자 : 
수정자