ch44.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

exists there. When it finds the proper remote system name, <TT>uucico</TT> reads

the rest of the entries for that system, including the port to be used. From there,

<TT>uucico</TT> uses <TT>/usr/lib/uucp/port</TT> and <TT>/usr/lib/uucp/dial</TT>

(Taylor UUCP) or <TT>/usr/lib/uucp/Devices</TT> and <TT>/usr/lib/uucp/Dialers</TT>

(HDB UUCP) to start the modem connection (assuming it is a modem used to establish

the session, of course). When the modem is in use, <TT>uucico</TT> creates a lock

on the device so no other application can use it (the lock is a file starting with

<TT>LCK..</TT> and followed by the device name, such as <TT>LCK..cua0</TT>).</P>

<P>Once the <TT>chat</TT> scripts for setting up and dialing the modem have been

executed and the remote system is connected, <TT>uucico</TT> uses the <TT>chat</TT>

script in the <TT>/usr/lib/uucp/sys</TT> or <TT>/usr/lib/uucp/Systems</TT> file to

log into the remote. Once logged in, the remote machine starts up its copy of <TT>uucico</TT>,

and the two <TT>uucico</TT> processes establish handshaking between themselves. Finally,

after the handshaking has been established, <TT>uucico</TT> goes ahead and handles

any transfers that are queued.</P>

<P>When completed with the session, the local machine checks to make sure that the

remote has nothing further to send and then breaks the connection. Finally, <TT>uucico</TT>

terminates.

<H3 ALIGN="CENTER"><A NAME="Heading9<FONT COLOR="#000077">Direct Connections</FONT></H3>

<P>If your two machines are directly connected through a serial port, for example

(no modems involved in the connection), you can use UUCP as a simple network protocol

for file transfer. The only changes to the configuration files mentioned earlier

are in the port specification. Instead of using a modem device, you specify a direct

connection. For example, in the <TT>/usr/lib/uucp/sys</TT> file (Taylor UUCP), you

would have an entry like<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">port      direct1

</FONT></PRE>

<P>with a matching entry in the <TT>/usr/lib/uucp/port</TT> file that looks like

this:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">port      direct1

type     direct

speed     38400

device     /dev/cua1

</FONT></PRE>

<P>with the speed of the direct connection and the port which uses it specified.

The entries in the HDB UUCP version are similar, using the <TT>/usr/lib/uucp/Systems</TT>

and <TT>/usr/lib/uucp/Devices</TT> files.

<H3 ALIGN="CENTER"><A NAME="Heading10<FONT COLOR="#000077">Login Scripts</FONT></H3>

<P>The login scripts that form part of the <TT>/usr/lib/uucp/sys</TT> or <TT>/usr/lib/uucp/Systems</TT>

file can be the most difficult part of a UUCP connection to get correct. If the machine

you are logging into is a typical UNIX system, there should be only the usual login

and password prompts to worry about. Other systems may require some special handling

to gain access. For this reason, the login script is worth a quick look.</P>

<P>Generally, the layout of the login script is in a pattern-action pair, with the

pattern coming from the remote machine and the action from the local. A simple login

is<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">login: merlin password: secret1

</FONT></PRE>

<P>In this case, the local system waits until it sees the string <TT>login:</TT>

coming from the remote, sends <TT>merlin</TT>, waits for <TT>password:</TT>, and

then sends <TT>secret1</TT>. You can simplify the script a little by cutting out

extra letters from the remote, because all you really need are the last couple of

characters and the colon. The script could have been written like this:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">gin: merlin word: secret1

</FONT></PRE>

<P>This type of script has a good use. Suppose the remote system sends <TT>Login:</TT>

instead of <TT>login:</TT>; then the shortened form will work and the longer match

won't.</P>

<P>One useful feature of the <TT>uucico</TT> <TT>login</TT> script is the ability

to wait for the remote machine to reset itself (or start a <TT>getty</TT> process,

more likely). This is implemented by using a hyphen and the word <TT>BREAK</TT> in

the script, which tells <TT>uucico</TT> to send a break sequence if the remote site

hasn't responded in a timely manner. For example, the script would be similar to

this:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">ogin:-BREAK-ogin: merlin sword: secret1

</FONT></PRE>

<P>In this case, if the remote machine doesn't respond with a <TT>ogin</TT>: prompt

after a short period of time, the local machine sends a break sequence and waits

for the prompt again.</P>

<P>A few special characters can be used in the login script. The most important ones

for most UUCP purposes are the following: 

<TABLE BORDER="0">

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\c</TT> </TD>

		<TD ALIGN="LEFT">Suppresses sending carriage return (send only) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\d</TT> </TD>

		<TD ALIGN="LEFT">Delays one second (send only) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\p</TT> </TD>

		<TD ALIGN="LEFT">Pauses for a fraction of a second (send only) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\t</TT> </TD>

		<TD ALIGN="LEFT">Sends a tab (send and receive) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\r</TT> </TD>

		<TD ALIGN="LEFT">Sends a carriage return (send and receive) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\s</TT> </TD>

		<TD ALIGN="LEFT">Sends a space (send and receive) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\n</TT> </TD>

		<TD ALIGN="LEFT">Sends a newline (send and receive) </TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD WIDTH="31" ALIGN="LEFT"><TT>\\<BR>

			</TT></TD>

		<TD ALIGN="LEFT">Sends a backslash (send and receive)<BR>

					</TD>

	</TR>

</TABLE>

Sometimes you need to use one or more of the characters to get the remote machine

to respond to a modem login. For example, the script<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">\n\r\p ogin: merlin word: secret1

</FONT></PRE>

<P>sends a carriage return-line feed pair before starting to match characters. This

is usually enough to get the remote machine to start a <TT>getty</TT> on the port.

<CENTER>

<H3><A NAME="Heading11<FONT COLOR="#000077">Changing Access Times</FONT></H3>

</CENTER>

<P>Both Taylor and HDB UUCP versions let you specify a time to call the remote systems.

While the examples so far show <TT>Any</TT> (meaning the system can be called at

any time, day or night), you may want to restrict calls to local-cost times, or on

certain days of the week. The reason for limiting calls may be at your end (costs,

for example), or at the remote (limited access times during the day, for example).</P>

<P>To specify particular days of the week to allow calls, use a two digit abbreviation

of the day (<TT>Mo</TT>, <TT>Tu</TT>, <TT>We</TT>, <TT>Th</TT>, <TT>Fr</TT>, <TT>Sa</TT>,

<TT>Su</TT>), or <TT>Wk</TT> for weekdays (Monday through Friday), <TT>Any</TT> (for

any time), or <TT>Never</TT> (for not allowed to connect). Any combination of the

days may be used, as you will see in a moment. The times for connecting are specified

as a range, in 24-hour format, when a time span is required. If no time is given,

it is assumed that any time during the day is allowed.</P>

<P>Dates and times are run together without spaces, while subsequent entries are

separated by commas. Here are some examples of restricted access times:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">Wk1800-0730

MoWeFi

Wk2300-2400, SaSu

</FONT></PRE>

<P>The first example allows connection only on weekdays between 6 p.m. and 7:30 a.m.

The second allows connection any time on Monday, Wednesday, or Friday. The last example

allows connections only between 11 p.m. and midnight on weekdays, and any time on

weekends. You can build up any time and date specifications you want. These apply

to both Taylor and HDB UUCP versions.

<CENTER>

<H3><A NAME="Heading12<FONT COLOR="#000077">UUCP Security</FONT></H3>

</CENTER>

<P>The permissions of the UUCP configuration files must be carefully set to allow

UUCP to function properly, as well as to allow better security for the system. Simply

stated, the files should all be owned by <TT>uucp</TT>, and the group should be <TT>uucp</TT>

on most systems that have that group in the <TT>/etc/group</TT> file. The ownerships

can be set either by making all the file changes while logged in as <TT>uucp</TT>,

or by setting the changes as <TT>root</TT> and then issuing the following commands

when you are in the <TT>/usr/lib/uucp</TT> directory:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">chown uucp *

chgrp uucp *

</FONT></PRE>

<P>As a security precaution, you should set a strong password for the <TT>uucp</TT>

login if there is one on your system. Some versions of Linux do not supply a password

by default, leaving the system wide open for anyone who can type <TT>uucp</TT> at

the login prompt!</P>

<P>The file permissions should be set very tightly, preferably to read-write (and

execute for directories) only for the owner (<TT>uucp</TT>). The group and other

permissions should be blanked because a read access can give valuable login information,

as well as passwords to someone.</P>

<P>When UUCP logs into a remote system it requires a password and login. This information

is contained in the <TT>/usr/lib/uucp/sys</TT> or <TT>/usr/lib/uucp/Systems</TT>

files, and should be protected to prevent unauthorized snooping by setting file ownerships

and permissions as mentioned.</P>

<P>If you have several systems connecting into yours, they can all use the same <TT>uucp</TT>

login and password, or you can assign new logins and passwords as you need them.

All you need to do is create a new <TT>/etc/passwd</TT> entry for each login (with

a different login name from <TT>uucp</TT>, such as <TT>uucp1</TT>, <TT>uucp_arthur</TT>,

and so forth) and a unique passwd. The remote system can then use that login to access

your system. When you create new UUCP users in the <TT>/etc/passwd</TT>, force them

to use <TT>uucico</TT> only to prevent access to other areas of your system. For

example, the login <TT>uucp1</TT>, shown here, forces <TT>uucico</TT> as the <TT>startup</TT>

command:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">uucp1::123:52:UUCP Login for Arthur:/usr/spool/uucppublic:/usr/lib/uucp/uucico

</FONT></PRE>

<P>The home directory is set to the <TT>uucppublic</TT> directory, and <TT>uucico</TT>

is the only startup program that can be run. Using different logins for remote machines

also allows you to grant different access permissions for each system, preventing

unwanted access.</P>

<P>You should also carefully control the commands that remote systems can execute

on your local machine. This is done through the permissions fields of the local access

file and should be monitored carefully to prevent abuse and unauthorized access.

In a similar manner, if you are allowing forwarding of files through your system,

you should control who is allowed to forward, and where they are forwarded to.</P>

<P>Most important of all is to ensure that whoever accesses your system on a regular

basis is someone you want access to be granted to. Don't leave your system wide open

for anyone to enter because you are guaranteeing yourself disaster. Carefully watch

logins and make sure file permissions and ownerships are properly set at all times.

<CENTER>

<H3><A NAME="Heading13<FONT COLOR="#000077">Using UUCP</FONT></H3>

</CENTER>

<P>Once you have configured UUCP, you can use it to transfer files and e-mail. In

order to use UUCP, you have to know the addressing syntax, which is different than

what you may know from the Internet. The UUCP address syntax is<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">machine!target

</FONT></PRE>

<P>where machine is the remote machine name, and target is the name of the user or

file that you are trying to get to. For example, to send mail to the user <TT>yvonne</TT>

on machine <TT>arthur</TT>, you would use the <TT>mail</TT> command with the destination

user name:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">mail arthur!yvonne

</FONT></PRE>

<P>UUCP lets you move through several machines to get to a target. This can help

save on telephone bills, or make a much wider network available to you from a small

number of connections. Suppose you want to send mail to a user called <TT>bill</TT>

on a system called <TT>warlock</TT>, which isn't in your configuration files but

can be connected to through <TT>arthur</TT>. If you have permission to send mail

through the system <TT>arthur</TT> (called a &quot;hop&quot;), you could send the

mail with this command:<FONT COLOR="#0066FF"></FONT>

<PRE><FONT COLOR="#0066FF">mail arthur!warlock!bill

</FONT></PRE>

<P>When UUCP decodes this address, it reads the first system name (<TT>arthur</TT>)

and sends it to that system. The UUCP processes on <TT>arthur</TT> then examines

the rest of the address and realizes the mail is to be sent on to <TT>warlock</TT>.

If you have permission to forward through <TT>arthur</TT>, UUCP on <TT>arthur</TT>

sends the mail through to <TT>warlock</TT> for you. You can have many hops in an