uucp_manual_setup man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

uucp_manual_setup(7)					  uucp_manual_setup(7)

NAME
       uucp_manual_setup  -  Describes how to manually set up the UNIX-to-UNIX
       Copy Program (UUCP)

DESCRIPTION
       Setting up UUCP manually includes the  following	 tasks:	 Checking  for
       required	 directories  Optionally,  creating the UUCP manager's account
       Creating UUCP accounts for remote systems Configuring remote communica‐
       tions  links,  which  consists  of editing the following files: Devices
       /etc/inittab Dialers Systems Dialcodes Permissions Poll	remote.unknown
       /etc/inetd.conf	Configuring the uucico daemon Verifying the configura‐
       tion files Setting up TCP/IP communications

       Before you set up UUCP, be certain that all of the appropriate hardware
       is  in  place.  For  information	 on required hardware, see the Network
       Administration: Services manual.

CHECKING FOR REQUIRED DIRECTORIES
       Verify that the directories, programs, and support  files  required  to
       operate	the  UUCP programs are available on the local system.  To per‐
       form the verification, log in as superuser and  enter  the  uucheck  -v
       command.	  The  uucheck	program	 displays  an explanation of how it is
       checking the file structure. Errors reported by uucheck could  indicate
       that the software installation process did not complete successfully.

       See the Network Administration: Services manual for more information.

CREATING UUCP ACCOUNTS FOR REMOTE SYSTEMS
       For a user on a remote system to log in to the local system, the remote
       system must have an entry in the local /etc/passwd file,	 or  the  user
       must  know  the	login ID and password for a designated UUCP account on
       the local system.  Likewise, for a user on the local system to  log  in
       to  a  remote system, the local system must have an entry in the remote
       system's /etc/passwd file, or the user must know the login ID and pass‐
       word of a designated UUCP account on the remote system.	You must coor‐
       dinate assigning	 system	 login	names  and  passwords  for  the	 local
       /etc/passwd file with the system administrator of the remote system.

       By  convention,	the  login ID assigned to remote systems is the remote
       system's name with an uppercase U added as a prefix. Many systems, how‐
       ever, have a single UUCP account for all remote systems to use.

       You  must add a user account to the /etc/passwd file for remote systems
       that log in to your system.

       Use the following procedure to set up a remote system's account: Invoke
       vipw to edit the /etc/passwd file: # vipw

	      The format for entries in the /etc/passwd file is:

	      name: password: UID: GID: class: home_dir: shell

	      The following is a sample entry for a remote system:

	      Uhost1::4:2:uucp login for host1:/usr/spool/uucppublic:\
		  /usr/lbin/uucp/uucico

	      For more information, see the passwd(4) reference page.  Use the
	      passwd command to set a password for the new account.  Note that
	      the  password  you supply does not echo to the screen.  # passwd
	      Uhost1 Changing password for Uhost1.  New password:  Retype  new
	      password:

	      The Permissions file is used to further control incoming connec‐
	      tions and remote systems' access to the local system.  For  more
	      information  on the Permissions file, see the Permissions refer‐
	      ence page.

CONFIGURING REMOTE COMMUNICATIONS LINKS
       There are three ways to set up the link needed  for  remote  communica‐
       tions:  Use  a  hardwired line with a device such as a workstation. The
       hardwired connection links a port on the local system to a port on  the
       remote  system.	A  hardwired  line is advantageous when users on local
       systems communicate frequently with remote systems; the link is	always
       available  and  access  time is short. However, a port used for a hard‐
       wired communications link is not available for any other purpose.

	      A hardwired connection is made over an RS-232 or	RS-422	serial
	      port  at transmission rates of up to 19,200 bits per second. The
	      recommended length of such direct	 links	is  50	feet  or  less
	      because  signal  noise becomes a problem with greater distances.
	      It is possible to obtain longer lengths by using a lower	trans‐
	      mission  rate,  limited  distance modems (short-haul modems), or
	      both at both ends of the link.  Use  a  telephone	 line  with  a
	      modem.   In  this case, the user on the local system establishes
	      the connection to a remote system through an  Automatic  Calling
	      Unit  (ACU),  also  referred to as an autodialer or a modem. The
	      modem attached to the remote system answers the  telephone,  and
	      the communications software then completes the connection.

	      The  advantage  of a modem connection using a phone line is that
	      the local and remote ports are not dedicated to a single system.
	      The  disadvantage	 is  that the port of the remote system may be
	      busy handling a connection with another system.  A  dialup  link
	      also requires additional software and hardware, such as the ACU,
	      that is not necessary with a hardwired connection.  Use a TCP/IP
	      connection over a local area network (LAN).

       In  order  for  UUCP  to function correctly at your site, configure the
       remote communication  facilities	 by  doing  the	 following:  Edit  the
       Devices	file  and  add a list of the devices used to establish a hard‐
       wired communications link, a communications link	 using	TCP/IP,	 or  a
       communications  link  using  a  telephone  line	and a modem.  For more
       information, see the Devices(4) reference page.	Edit the Dialers  file
       and  add	 a list of autodialers (modems) used to contact remote systems
       using the telephone network. For more information, see  the  Dialers(4)
       reference  page.	  Edit	the  Systems file and add a list of the remote
       systems with which the local system can communicate. For more  informa‐
       tion,  see  the	Systems(4) reference page.  Optionally, edit the Dial‐
       codes file and add a list of alphabetic abbreviations representing  the
       prefixes of telephone numbers used to contact the specified remote sys‐
       tems. For more information, see the Dialcodes(4) reference page.	  Edit
       the  Permissions file and add the appropriate access permissions speci‐
       fying the way in which local and remote systems	can  communicate.  For
       more information, see the Permissions(4) reference page.	 Edit the Poll
       file and add a schedule for monitoring the  networked  remote  systems.
       For more information, see the Poll(4) reference page.

CONFIGURING THE UUCICO DAEMON
       The  uucico  daemon  transfer  UUCP command, data, and execute files to
       remote systems.	Both the local and remote systems run the uucico  dae‐
       mon, and the two daemons communicate with each other to complete trans‐
       fer requests.

       Typically, the uucico daemon is set up as the UUCP users's login	 shell
       for incoming connections, or it is automatically called by various UUCP
       commands for outgoing connections, and no further configuration is nec‐
       essary.	 However,  you	might need to specify the type of flow control
       uucico uses for certain UUCP transfers.	For example, if you  establish
       a connection to a terminal server via a modem and then telnet to a UUCP
       account, you might require a different type of flow control than a user
       who initiates UUCP transfers via a serial port connection.

       To  specify  the	 type of flow control that the uucico daemon uses, set
       the FLWCTL environment variable for the accounts on  your  system  that
       are  used  for  UUCP  connections.  Permitted values for FLWCTL are: HW
       (hardware), SW (software), HSW (hardware and software), and NONE.   The
       local  and remote systems should use the same type of flow control.  If
       the remote site runs UUCP on a different platform, FLWCTL should be set
       to NONE on the Tru64 UNIX system.

       For  example, if you need to establish a UUCP connection over telnet as
       previously described, you would set flow control to NONE as follows:  $
       export FLWCTL=NONE $ /usr/lib/uucp/uutry remote_site

       On a system that is configured to allow other sites to dial in, you can
       create a customized script that will automatically set the FLWCTL vari‐
       able  as	 follows: Create a file, optionally called uu_start, that con‐
       tains the following commands:

	      #! /bin/ksh  export  FLWCTL=NONE	exec  /usr/lib/uucp/uucico  $*
	      Change  the  permissions	on  the	 file to make it executable: #
	      chmod +x /usr/local/bin/uu_start Change the UUCP account's login
	      shell  from  /usr/lib/uucp/uucico	 to the new executable file: #
	      chsh   uucp   Old	  shell:   /usr/lib/uucp/uucico	  New	shell:
	      /usr/local/bin/uu_start

VERIFYING THE CONFIGURATION FILES
       When  the  UUCP	files  are customized for your site, issue the uucheck
       command to check for possible errors in the Permissions file.  Remember
       that  the  uucheck  command does not check file or directory modes, nor
       does it check for duplicate login or MACHINE names.

       Issue the uucheck -v command to obtain a detailed  explanation  of  the
       way that UUCP interprets the Permissions file.

       If the uucheck -v command displays an error message, use the pg command
       to examine the Permissions file and make sure the entries are  correct.
       Then reissue the uucheck -v command.

       Use  the	 uuname	 command  to ensure that all the hosts included in the
       Systems file on the local system are actually on the UUCP network.   If
       a  system  is  networked correctly, it appears on the list displayed on
       the screen. The hosts on this list are the systems to which  users  can
       send mail.

SETTING UP TCP/IP COMMUNICATIONS
       The  uucpd  daemon handles communications between UUCP and TCP/IP. This
       daemon enables users on systems linked over a local area network	 (LAN)
       to  establish  uucp  connections	 to other systems using TCP/IP connec‐
       tions.

       Use the following procedure to enable UUCP and TCP/IP  to  communicate:
       Check  to  see  whether	the  /etc/services file includes the following
       line:

	      uucp	   540/tcp	   uucpd

	      If it does not, add it to the file.  To have  the	 uucpd	daemon
	      start automatically each time the inetd daemon receives one UUCP
	      request, remove the comment symbol (#) from the  following  line
	      in  the  /etc/inetd.conf	file:  #  uucp	stream tcp nowait uucp
	      /usr/sbin/uucpd  uucpd

	      Restart the inetd daemon.	  Be  sure  that  the  TCP/IP  network
	      between the local and remote systems is working.	Issue the ping
	      command to test  that  the  systems  can	communicate  with  one
	      another.	Replace rhost1 with the name of the appropriate remote
	      host.  # ping rhost1

	      See the ping(8) reference page for more information.  Update the
	      Systems,	Devices,  and  Permissions  files in the /usr/lib/uucp
	      directory to include the relevant TCP/IP entries, as follows: To
	      update  the Systems file do, the following: Select the appropri‐
	      ate TCP/IP conversation protocol to enter in the TCP caller sub‐
	      field. There are four kinds of protocols: g, t, e, and f.	 The g
	      protocol, the default, provides error checking and thus is  use‐
	      ful over modem connections. However, it creates a large overhead
	      when running UUCP commands.  The t protocol presumes  an	error-
	      free channel and thus it is not reliable for use with modem con‐
	      nections. You can use the t protocol to communicate with a  site
	      running  both Tru64 UNIX and Berkeley versions of UUCP.  Use the
	      e protocol to communicate with sites  running  both  Tru64  UNIX
	      UUCP  and other versions of UUCP. The e protocol is not reliable
	      for modem connections.  Use the f protocol to  communicate  with
	      sites running versions of UUCP other than Tru64 UNIX. The f pro‐
	      tocol is not reliable for modem connectors.  Add the appropriate
	      entries to the Systems file.

	      For  example,  to connect the local system to system host7 using
	      the default g protocol, enter the following line in the  Systems
	      file:

	      host7   Any   TCP	  -  -	in:--in: uucp1	word: passuucp Replace
	      the send and expect characters in the example Login  field  with
	      the  login  prompt,  login,  password  prompt, and password that
	      applies to the remote system to which you are connecting.

	      The following example shows how to specify that  you  are	 using
	      TCP/IP with the t protocol:

	      host7  Any  TCP,t	 -  -  in:--in: uucp1  word: passuucp

	      To  update the Devices file, do the following: Enter the follow‐
	      ing line in the Devices file:

	      TCP  -  -	 -  TCP Specify TCP in the Caller field.  Enter dashes
	      (-)  in  the  Line,  Line2,  and	Class fields. Enter TCP as the
	      Dialer. This is done to ensure that outgoing calls  over	TCP/IP
	      are  enabled.   To update the Permissions file, enter the appro‐
	      priate LOGNAME and MACHINE entries.  See the Network Administra‐
	      tion: Services manual for information on editing the Permissions
	      file.

       Note that you must set up an appropriate login ID and password for  any
       remote system that initiates uucico and uuxqt activities.

RELATED INFORMATION
       uucico(8), uucp(1), uucp_intro(7), uucpd(8), uucpsetup(8)

       Network Administration: Services

							  uucp_manual_setup(7)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net