.if n .pH rn4.chap4 @(#)chap4	40.38
.\" Copyright 1989 AT&T
.BK "Software Notes"
.CH "Networking" "4"
.H 1 "Networking Notes"
.IX istart UNIX System V Release 4, networking notes
.H 2 "TCP/IP (DARPA Internet Protocol Suite)
.H 3 "Domain Name Service (DNS)"
.IX TCP/IP, \f4tlp\fP and \f4telnet\fP and using DNS
.IX Domain Name Service (DNS), using \f4tlp\fP and \f4telnet\fP
The default Internet Services, including \f4ftp\f1 
and \f4telnet\f1,
use a dynamic shared library \f4/usr/lib/libsockhost.so\f1
to provide \f4/etc/hosts\f1 name to address translation.
To use the Domain Name Service dynamic name to address translation
\f4/usr/lib/libsockdns.so\f1 library for the Internet Services,
proceed with the following instructions:
.AB C
The current contents of the \f4/usr/lib/libsocket.so\f1
file are mapped into running network processes, and 
these commands should be performed in
single user mode without any running network processes.
.AC
.DS 
  1. #mv within \f4/usr/lib\f1 retains the same fs-inode for shared segments
  2. mv \f4/usr/lib/libsocket.so\f1 to \f4/usr/lib/libOLDsocket.so\f1
  3. #make a copy of the appropriate library in \f4/usr/lib/libsocket.so\f1 
  4. cp \f4/usr/lib/libsockdns.so\f1 to \f4/usr/lib/libsocket.so\f1
  5. # after reboot, the old dynamic library can be discarded
  6. rm \f4/usr/lib/libOLDsocket.so\f1
.DE
.P
The same procedure can be followed to copy the
\f4/usr/lib/libsockhost.so\f1 dynamic library into \f4/usr/lib/libsocket.so\f1.
.P
This is a global change for all users because the \f4/usr/lib/libsocket.so\f1 dynamic library is used by most Internet Services.
.P
Until the TCP/IP streams are configured, the DNS processes
can not be contacted to provide name to address mapping.
However, the streams are initialized with addresses.
This difficulty is resolved by requiring the systems'
\f4/etc/hosts\f1 file to contain addresses
for \f4loopback\f1 and \f4uname -n\f1 TCP/IP interfaces.
They \f4/etc/hosts\f1 file is consulted after the DNS attempts
time out, so allow more time for booting.
.P
Some commands, such as \f4in.named\f1 and \f4nslookup\f1, 
are compiled with the Domain Name Services static \
library rather than the dynamic one.
The sequence of compilation options to use is:
 .DS
.ft CW
-lresolv -lnsl -lsocket
.ft 1
.DE
.P
For more information, consult 
Chapter 5: Using Domain Name Service in the 
\f2TCP/IP Network Administrator's Guide\f1.
.H 3 "Ethernet Boards"
.IX TCP/IP, Ethernet board addressing
.IX Ethernet board addressing
When a system has more than one Ethernet board
connected to the same physical Ethernet, the
\f4/etc/emd?.addr\f1 files must have different addresses.
Change should be limited to the last two digits of the number,
without altering its length.
.P
If the 
\f4prtconf\f1 command displays the Ethernet boards you are
using as NI devices rather than as EMD devices, you
should un-install and re-install the UNIX System V Release 4
EMD package.
.H 3 "Listener Addresses" 
.IX TCP/IP, listener addressing
.IX "listener addressing, TCP/IP and Release 4"
The TCP/IP listener address is
not same as UNIX System V Release 3 add-ons for TCP/IP.
In UNIX System V Release 3, the address was of the form
.DS I
\f4\ex00020401\f2Internet\f1 
.DE
where 
.I Internet 
is the system TCP/IP
address in eight hexadecimal digits, two per
octet.
The UNIX System V Release 4 address is of the form
.DS I
\f4\ex00020ACE\f2Internet\f40000000000000000\f1 
.DE
where 
.I Internet 
is the
system TCP/IP address in eight hexadecimal digits.  See
``Setting Up the Listener'' in the
.BT "TCP/IP Network Administrator's Guide"
for more information.
.H 3 NETPATH
.IX \f4NETPATH\fP environment variable
If the NETPATH environment variable is set, then at least one of 
the transports in the NETPATH path should be connectionless.
If NETPATH is set, but \f4/etc/netconfig\f1 lists
additional Transport providers, the
additional \f4/etc/netconfig\f1 providers will not
be used. [See \f2Programmer's Guide: Network
Interfaces\f1, and Programmer's Reference
Manual\f1,\f4Environ\f1(5)].
.H 3 "Pseudo Terminals"
.IX TCP/IP, pseudo terminal configuration
Pseudo terminals must be configured for TCP/IP services, such
as 
.UI telnet , 
and 
.UI rlogin , 
to work.  These may be selected when
the NSU or TCP/IP Internet packages are installed.
.H 3 "Shutdown Errors" 
.IX TCP/IP, shutdown errors
After the TCP/IP Internet package is installed, or when the
initialization scripts or data bases are customized for
configurations, the system may display errors when the
system is shutdown.  This behavior is the result of the
current software configuration in multi-user mode not
matching the initialization scripts, data bases, and
devices. For example, if the package is installed in
multi-user mode, the 
.UI /dev/ip 
and 
.UI /boot/IP 
device and module
are in the file system, but are not yet incorporated into
the running operating system.  When the system is shut down
from multi-user mode, the scripts and data bases will refer
to the 
.UI /dev/ip 
device, but they will not be able to open it
successfully until the operating system is reconfigured (by
.UI cunix 
or 
.UI shutdown ) 
to incorporate these drivers.  In another
case, if the system has been upgraded to be a router by
editing the 
.UI /etc/inet/strcf 
file to include another 
``cenet''
emd device, there will be an error when the system is
shutdown because the network will not currently be using
that device, though the system will try to disable it.
.H 3 "Startup Errors"
.IX TCP/IP, \f4epump\fP failure at system startup
.IX \f4epump\fP, failure at system startup
.UI "epump -d" 
can fail at system startup.  This is due to the
administrator's forcing an unlink of STREAMS still in use
or the current state of the Ethernet network.
This can be corrected by \f4reboot\f1.

.H 2 "NFS"
.H 3 "Automounter"
.IX NFS, automounter and maps
Direct map automounters do not always clean up after themselves.
They may leave files that are symbolic links to automount daemon
mount points for which the automount daemon no longer exists.
Attempts to access these files will result in \f4server not
responding\f1 messages.  These files can only be removed by
unlinking them, then running \f4fsck\f1, or by rebooting and then 
removing any remaining links.
The only other workaround is to avoid using direct maps with 
the automounter.
.P
Note that the automount daemon for direct maps mounts itself
on the mountpoint specified in the map, while the automounter
for an indirect map mounts itself on the directory specified
as the root for the indirect mount, i.e., one level above the
mount point for the resource in the indirect map. This can be
misleading to the user because the user may not expect anything
to be mounted above the mount point of the resource.  Because
the daemon mounts itself there, the previous contents of the
directory are covered for the duration of the life of the
automounter.  As with all file system mount points, it is
a good policy to use empty directories as automount root 
mount points.
.P
There is no entry in the \f4/etc/mnttab\f1 file corresponding to
the mount of the automount daemon on the automount root 
mount point. Therefore, it is possible for a user attempting
to mount a file system on a given mount point to get a 
"mount point busy" message even though that directory
is not noted in the \f4/etc/mnttab\f1 file as an existing mount
point.
.H 3 "Lock Manager"
.IX NFS, deadlock detection
.IX deadlock, NFS lock manager
The lock manager does not always detect deadlock.
.H 3 "Loopback"
.IX istart \f4nfsd\fP(1M)
.IX NFS, interrupted read or write
If a large read or write operation to a loopback mount with 
\f4biod\f1's running is interrupted, some of the \f4nfsd\f1's can hang
while waiting for the STREAMS code to free a STREAMS
message block.
.IX iend \f4nfsd\fP(1M)
.H 3 "Protocol Independence"
This feature is not mentioned in the NFS documentation.
See the \f2Programmer's Guide: Networking Interfaces\f1 or
the \f2System Administrator's Guide\f1 for procedures on Network
Selection administration and use.
.H 3 "Secure NFS mount"
.IX Secure NFS, \f4mount\fP
If a secure NFS mount is interrupted while waiting for
the keyserver to respond, it is possible for the 
filesystem to be mounted, but without a corresponding entry put
in the \f4/etc/mnttab\f1 file.  This occurs because the signal will
not be handled until after the mount system call has succeeded
and returned to the \f4mount\f1 command.  The command process will then 
be killed before it writes to \f4/etc/mnttab\f1.
.H 3 "Transport Independence"
.IX Starlan, NFS and workarounds
.IX NFS, transport independence
.IX NFS, multiple transports
.IX NFS, Starlan driver
NFS does not work over Starlan, due to a bug in the Starlan
driver.  Although Starlan
should not allow a process to bind to the
same address twice, it sometimes does causing \f4rpcbind\f1
to think the NFS daemon has died. The only workaround, until
Starlan is fixed, is to remove the test in \f4rpcbind\f1 that reports if
the server is still up.
.P
NFS can run over multiple transports (other than Starlan, see
above) simultaneously, provided that:
.AL a
.LI
both the client and the server agree on the maximum
packet size for a given transport; or,
the \f4-o rsize=,wsize=\f1 options are given to the 
\f4mount\f1 command to reduce the read and write sizes to a value
small enough for both machines (the minimum of the
packet sizes of the two machines' transports).
Note that the read and write transfer sizes should be
about 430 bytes smaller than the transport's packet
size to allow for RPC headers.
.LI
the transport can accept packets of at least a minimum
size, of approximately 1400 bytes.
.LE
.P
The NFS daemon (\f4nfsd\f1) does not listen on a specified address
over transports other than UDP.  Therefore, if the \f4nfsd\f1's are
killed and restarted it is likely that the new \f4nfsd\f1 will
listen on an entirely different address causing
any previously existing mounts to fail.
.H 3 "\f4share\fP Resources Command"
.IX istart \f4share_nfs\fP(1M), read and write permissions
If a resource is shared with a \f4ro= list\f1 and a \f4root= list\f1,
any host that is on the \f4root= list\f1 will be given only read-only
access, regardless of whether that host is specified in the \f4ro=
list\f1, unless \f4rw\f1 is declared as the default, or 
the host is mentioned in a \f4rw= list\f1. 
The same is true if the resource is shared with \f4ro\f1
as the default. For example, the following \f4share\f1 commands will
give read-only permissions to \f4hostb\f1:
.P
.nf
	\f4share -F nfs -oro=hosta,root=hostb /var
.sp 1
	share -F nfs -oro,root=hostb /var\f1
.P
While the following will give read/write permissions to hostb:
.sp 1  
	\f4share -F nfs -oro=hosta,rw=hostb,root=hostb /var
.sp 1
	share -F nfs -oroot=hostb /var\f1
.br
.P
Since this is not necessarily intuitive, it should be 
mentioned in the NFS share man page.
.IX iend \f4share_nfs\fP(1M), read and write permissions
.H 2 "RFS"
.IX RFS, compatibility with Release 4 implementation
Remote File Sharing (RFS) has been 
implemented as a file system type under VFS. 
Even though the new implementation fully 
supports the pre-Release 4 protocol, the new 
protocol has implications for compatibility 
and inter-operability with previous versions of RFS.
.P
Using \f4df\f1 with either the \f4-n\f1 or 
\f4-g\f1 options on a remote resource advertised from a 
pre-SVR4.0 system will give \f4unknown\f1 for the fstype.
.P
The \f4-c\f1 option to the \f4rfs\f1 specific \f4mount\f1 
command function is done by \f4-o\f1 nocaching.
The \f4-c\f1 option will be removed in a future
release.
.P
The \f4-d\f1 option for the \f4mount\f1 command is provided 
for compatibility, but its function is replaced by \f4-F rfs\f1, 
so the \f4-d\f1 will be removed in a future release.
.H 4 "Known Problems"
Facilities new to System V Release 4.0 cannot be provided
by an older RFS server. Although an SVR4 
RFS client can create a dynamic shared library 
on a pre-SVR4.0 server, the shared library cannot 
be \f4mmap\f1ped from that server, because the pre-SVR4
protocol does not support file mapping
or paging. The \f4rename\f1 system call 
(used by the \f4mv\f1 command) is not fully 
supported between SVR4 clients and SVR3 servers.
An attempt to \f4rename\f1 a directory on an SVR3 server will
fail with the error \f4EISDIR\f1.
.P
RFS does not support \f4mmap\f1ping of character devices
or the allocation of remote swap files.
.P
Users and administrators of RFS clients and servers are reminded
that the interpretation of absolute symbolic links encountered
on the server can lead to unexpected results because they
are relative to the root directory of the client.
.IX RFS, swap control
.H 3 "Swap Control"
Swap will not work over RFS (i.e., a swap device 
or file cannot be created on a resource mounted via RFS).  
If this is attempted, an \f4ENOSYS\f1 error will result. 
.IX iend UNIX System V Release 4, networking notes
.H 2 "Secure RPC"
.IX Secure RPC, with RFS
.IX RFS, Secure RPC
.H 3 "Secure RPC with RFS"
.IX Secure RPC, administrative files
The Secure RPC administrative files \f4/etc/masters\f1 and
\f4/etc/slaves\f1 contain the unames of RPC masters and slaves,
respectively, as documented in \f2Programmer's Guide:  
Networking Interfaces\f1.
Note, however, that if RFS is used to share the files from the
masters or the slaves, then those entries in either file should
contain the RFS domain name for that master/server followed
by a dot (.) and the uname, i.e., \f2rfsdomain.uname\f1.
.P
One of the Secure RPC administrative tasks of 
a slave server is to share its \f4/etc directory\f1, 
writable to its master and readable to its clients, 
as documented in Chapter 10 of the \f2Programmer's 
Guide: Networking Interfaces\f1.
.P
Note, when NFS is used to share the \f4/etc directory\f1, 
the share command should be in the form 
\f4share -F nfs -r rw=p,root=p,ro=i:j:k /etc\f1, 
where \f4p\f1 is the slave's master and \f4i\f1,\f4j\f1, 
and \f4k\f1 are the slave's clients.  
.H 2 "Networking Future Directions"
The X/Open Consortium has included a transport level
programming interface called XTI in the Third Issue
of the X/Open Portability Guide.  
This interface will be further updated for XPG4.  XTI
isimilar, but not identical, to the AT&T Transport
Interface (TLI).  
When the XPG:314 specification is complete
and formally adopted by the membership of X/Open, XT
I will be supported in UNIX System V.
.P
The design of XTI makes it possible that some existing TLI
applications will not be upwardly-compatible with an XTI
conformant library, since some XTI functions with syntax identical to
corresponding TLI functions have slightly different semantics.
One area of concern is that two new events, \f4T_GODATA\f1 and
\f4T_GOEXDATA\f1, have been added as possible return 
events from a call to the \f4t_look\f1 routine.
However, these events will only be returned if the application 
is sending data in non-blocking mode (\f4O_NONBLOCK\f1
or \f4O_NDELAY\f1 has been set for that transport endpoint) and
if flow control went into effect and has subsequently been
lifted.
A subsequent call to \f4t_snd\f1 or \f4t_sndudata\f1 would fail with
t_errno set to \f4TLOOK\f1 which currently does not happen with TLI.
Programs which block when sending data are not affected by this
change.
Application developers may choose to leave their applications
as is and wait until XTI is supported to see if there are any
incompatibilities.
However, to try to plan for the upcoming XTI library and
to be able to run an application with both TLI and XTI
libraries, a developer can make the following changes at this time.
Calls to \f4t_snd\f1 and \f4t_sndudata\f1 should not immediately 
fail if they return -1, but the program should
check the value of \f4t_errno\f1 and call \f4t_look\f1 if \f4t_errno\f1 
is set to \f4TLOOK\f1.
If an unrecognized event is returned by \f4t_look\f1, the program
should ignore it and continue.
