Chapter 12: Managing Taylor UUCP

Chapter 12
Managing Taylor UUCP

12.1 History
12.2 Introduction
12.3 UUCP Configuration Files
12.4 The Do's and Don't of UUCP - Tuning Permissions
12.5 Setting up your System for Dialing in
12.6 UUCP Low-Level Protocols
12.7 Troubleshooting
12.8 Log Files

12.1 History

UUCP는 70년대 후반 AT&T Bell Laboratories의 Mike Lesk가, 전화라인 상에서 단순한 형태의 다이얼 업 네트웍을 제공하고자 디자인한 것이다. 대부분의 사람들이 아직도 집에 앉아서 모뎀을 통해 통신하여 email과 Usenet News를 얻고자 하므로 UUCP는 대중적으로 남아있다. 다양한 하드웨어 플랫폼과 운영체제상에서 실행되는 무수한 implementation이 존재하지만, 그것끼리는 높은 수준의 호환성을 보인다.

그러나 대부분의 소프트웨어가 "표준"으로 자리잡는데 몇년이 걸리듯, UUCP엔 the UUCP라 부를만한 것이 없다. 그것은 1976년에 구현된 첫번째 버전 이후로 꾸준한 발전과정을 거쳐, 현재는 근본적으로 하드웨어의 지원과 설정방식이 다른 두개의 메이저 종(種)이 있다. 또 이들에서 파생된 여러 implementaion이 존재하며, 서로간에 약간씩의 차이점을 가지고 있다.

한가지 종은 흔히 "Version 2 UUCP"라고하는 것으로, Mike Lesk와 David A. Novitz, Greg Chesson이 1977년에 구현한 것이다. 비록 그것이 좀 낡은 것임에도, 아직도 자주 사용된다. 최근에의 Version 2 구현은 좀더 새로운 종류의 UUCP라는 더많은 편의를 제공한다.

두 번째 종은 1983년에 개발되었고, 흔히 BNU (Basic Networking Utilities), HDB (HoneyDanBer UUCP)라고 칭하는데, 그 이름은 저자명, 즉 P. Honeyman, D.A. Novitz, B. E. Redman에서 유래한 것이다. HDB는 Version 2 UUCP의 단점을 줄인 것으로, 예를 들자면 새로운 전송 프로토콜이 추가된 것, 스풀 디렉토리를 나눔으로써 UUCP traffic을 교환하는 각 사이트마다 하나의 디렉토리를 별개로 가지게 한 점 등이다.

리눅스에서 현재 배포되는 UUCP implementation은 Taylor UUCP 1.04로, 이 장에서는 이를 기준으로 삼는다. Taylor UUCP 버전 1.04는 1993년 2월에 릴리즈 되었다. Taylor UUCP는 전통적인 설정파일과는 별개로 새로운 스타일의 - a.k.a "Taylor" - 설정파일을 읽도록 컴파일 되어 있다.

버전 1.05는 최근에 릴리즈 되었으며, 곧 대부분의 배포판에 들어갈 것이다. 이 버전간의 차잇점이라고 해봐야 대부분 당신이 절대로 사용하지 않을 기능에 영향을 주는 것들이므로, 이 책에서 설명하는데 따라 Taylor UUCP 1.05를 설정해도 될 것이다.

대부분의 리눅스 배포판에 포함되어 있듯, Taylor UUCP는 보통 BNU호환으로 컴파일 되거나, Taylor 설정체계, 혹은 둘 다 호환되도록 컴파일 된다. 후자의 경우가 훨씬 유연성 있는 것이고, 또한 추상적인 BNU설정파일 보다는 다소 이해하기 쉽기 때문에, 여기선 Taylor 체계를 설명하기로 한다.

이 장의 목표는 UUCP 커맨드에 대한 커맨드 라인의 옵션에 어떤 것이 있고 어떤일을 하는지 장황하게 설명하는 것이 아니라, 어떻게 UUCP 노드로 동작하게 셋업하는가를 소개하는 것이다. 첫 번째 섹션은 어떻게 UUCP가 리모트 실행과 파일 전송을 수행하는가에 관해 소개한다. 만약 당신이 UUCP를 처음 대하지 않는다면, UUCP를 셋업하는데 사용되는 다양한 파일들을 설명하는 UUCP Configuration Files 섹션으로 건너 뛰어도 좋다.

하지만 우리는 당신이 UUCP 슈트(suite)의 사용자 프로그램인 uucp와 uux에는 친숙하다고 가정할 것이다. 설명을 원한다면 온라인 매뉴얼 페이지를 참고하라.

누구나 억세스할 수 있는 프로그램, 즉 uucp와 uux외에도 UUCP엔 관리적인 목적만으로 사용되는 몇가지 커맨드 역시 포함되어 있다. 이들은 당신의 노드를 통하는 UUCP traffic을 모니터하고, 오래된 log 파일을 제거하거나 통계를 내는데 사용된다. 이들 중 어느것도 여기서 거론하지는 않을 것인데, 그 이유는 이것들이 단지 UUCP의 주된 임무에 말초적인 것들이기 때문이다. 또한 그것들은 문서화가 잘 되어 있고 이해하기도 쉽다. 그러나 실제 UUCP의 "work horse"를 포괄하는 세 번째 범주도 존재하는데, 그것들은 uucico(cico는 copy-in copy-out의 약어이다)와, 리모트 시스템에서 보내온 job을 실행하는, uuxqt라 하는 것들이다.

12.1.1 More Information on UUCP

이 장에서 원하는 모든 것을 얻지 못한 사람들은 패키지에 딸려오는 문서를 읽어보기 바란다. 이는 Taylor 설정 체계를 이용한 셋업을 기술하는 texinfo 파일 세트이다. texinfo는 tex와 makeinfo를 이용하여 각각 DVI와 GNU info file로 변환할 수 있다.

만약 BNU나 심지어 (무시무시한!!) Version 2 설정파일을 사용하고자 한다면 그에 관해 좋은 책이 있는데, "Managing UUCP and Usenet"([OReilly89])는 아주 유용할 것이다. 리눅스 상의 UUCP에 관한 정보에 대한 또다른 좋은 소스는 Vince Skahan의 UUCP-HOWTO로, 정기적으로 comp.os.linux.announce에 포스팅 된다.

UUCP에 대해 논의하는 뉴스그룹인 comp.mail.uucp도 존재한다. 만약 Taylor UUCP에 특성화된 질문은 갖고 있다면 그들에게 질문하는 것이 comp.os.linux에 질문하는 것 보다 낫다.

Introduction

Layout of UUCP Transfers and Remote Execution

UUCP를 이해하는데 핵심이 되는 것은 job의 개념이다. 사용자가 uucp나 uux로 착수한 모든 전송을 일컬어 job이라 한다. 그것은 리모트 시스템 상에서 실행되는 커맨드와 사이트간에 전송되는 파일들의 모음으로 구성되며, 이들 중 하나는 생략될 수 있다.

예로써, 당신의 호스트에 다음과 같은 커맨드로 호스트 pablo에 netgiude.ps파일을 UUCP copy시켜, 다시 그 파일을 lpr 커맨드로 프린트 시킨다고 가정하자.

     $ uux -r pablo!lpr !netguide.ps

UUCP는 일반적으로 job을 곧바로 실행시키지 않는다. (그렇지 않다면 kermit으로 그 일을 하도록 시킬 수 있다). 대신에, 그것은 잠시간 job description을 저장해 두는데, 이를 스풀링이라 부른다. job이 저장되는 디렉토리는 스풀 디렉토리라 부르며, 일반적으로 /var/spool/uucp 내에 위치한다. 우리의 예제에서, job description은 실행되는 리모트 커맨드(lpr)과 실행을 요구한 유저, 그리고 다른 몇가지 아이템에 관한 정보를 지닌다. job description에 더하여, UUCP는 입력된 파일인 netguide.ps를 저장해야한다.

스풀 파일의 정확한 위치와 명칭은 컴파일 시의 옵션에 따라 변할 수 있다. HDB 호환 UUCP는 보통 /var/spool/uucp/site라는 이름의 디렉토리내에 스풀 파일을 보관하며, site는 리모트 사이트의 이름이다. Taylor 설정용으로 컴파일 할 때 UUCP는 서로 다른 타입의 스풀 파일에 대한 사이트-특정 스풀 디렉토리아래에 서브 디렉토리를 생성한다.

일정 간격으로 UUCP는 리모트 시스템에 다이얼 업한다. 리모트 머신으로의 커넥션이 성립되면 UUCP는 입력된 파일에 더하여, job을 기술한 파일을 전송한다. 들어온 job은 즉시 실행되지 않고, 연결이 종료된 후에 실행된다. 이는 uuxqt에 의해 이루어지는데, 그것은 다른 사이트에 대한 job을 포워딩하는 역할도 한다.

중요한 job과 덜 중요한 job을 구별하지 위해 UUCP는 각 job마다 등급(grade)을 부여한다. 이것은 한 글자로 이루어져 있으며, 0에서 9, A에서 Z,그리고 a에서 z까지로 우선도가 떨어진다. mail은 전통적으로 B 또는 C 등급으로 스풀 되며, new는 N 등급으로 스풀된다. 높은 등급을 가진 job이 먼저 전송된다. uucp나 uux를 실행할 때 g플래그로 등급을 지정해 줄 수 있다.

주어진 등급 아래의 job이 전송되지 못하게 할 수도 있는데, 이를 일컬어 전송간 허용 최대 스풀 등급(maximum spool grade)이라 하며, 디폴트로 Z에 맞춰져 있다. 여기서 용어의 모호성에 주의하자. 파일은 최대 스풀등급 이상일 때 전송된다.

12.2.2 The Inner Working of uucico

왜 uucico가 특정한 몇가지 사항을 알고 있어야만 하는지를 이해하기 위해, 여기선 어떻게 그것이 실제로 리모트 시스템이 연결하는지에 대한 짧은 설명을 적어보고자 한다.

당신이 커맨드라인에서 uucico -s system을 실행시킬 때, 그것은 먼저 물리적으로 연결해야 한다. 커넥션의 타입에 따라, 커넥션을 열기 위한 동작이 취해진다. - 예를 들어, 전화라인을 사용할 때, 그것은 모뎀을 찾아서 다이얼 한다. TCP 상에서 그것은 네임을 네트웍 주소로 변환하지 위해 gethostbyname(3)을 호출하고, 열기위한 포트를 찾아 소켓에 상응하는 주소로 바인딩해야 한다.

이러한 연결이 성립된 후, 일반적으로 로그인 네임과 패스워드에 대한 리모트 시스템에 요청하는, 인증절차를 거친다. 이를 보통 login chat이라 부른다. 인증 절차는 getty/login 슈트에 의해서, 혹은 TCP 소켓 상에서 uucico 자체로 수행된다. 만약 인증이 성공적으로 끝난다면, 리모트 쪽은 uucico를 구동한다. 커넥션을 시작한 uucico의 로컬 카피를 master, 그리고 리모트 카피를 slave라 칭한다.

다음으로 뒤따르는 것이 handshake phase이다: 이제 마스터는 자신의 호스트 네임에 몇가지 플래그를 더해 보내고, 슬레이브는 이 호스트 네임이 로그인 하고 파일을 주고 받는 등의 일에 대해 허가된 것인지 검사한다. 그 플래그는 (다른 것들 중에서도) 전송하는 스풀 파일의 최대 등급에 관해 설명하는데, 만약 그것이 사용가능한 상태라면, conversation count 또는 call sequence number 체크가 이 시점에 이루어진다. 이 기능으로 양 사이트는 성공적인 연결의 카운트를 유지하고 서로 비교한다. 만약 서로 일치하지 않는다면, handshake는 실패로 끝난다. 이것은 가명을 사용하는 사기꾼으로부터 당신을 보호하는데 유용하게 쓰인다.

마지막으로, 두 uucico는 공동의 전송 프로토콜을 받아들이고자 한다. 이 프로토콜은 데이터를 전송하고 일관성을 검사하며, 에러시 재 전송하는 방법을 결정하는 것이다. 서로 다른 커넥션 타입을 지원하기 위해 서로 다른 프로토콜이 필요하다. 예를 들어, 전화 라인은 에러에대해 비관적인 "안전한" 프로토콜을 요하며, TCP 전송은 원래가 신뢰성이 보장되는 것이므로 더 능률적인 프로토콜을 사용할 수 있다.

handshake가 완료된 후 실제 전송단계로 접어든다. 양쪽은 선택된 프로토콜 드라이버를 켜고, 그 드라이버는 가능하다면 프로토콜 특정의 초기화 단계를 수행한다.

먼저, 마스터는 리모트 시스템에 queue된 것 중, 스풀 등급이 충분히 높은 모든 파일을 보낸다. 그것을 마친후, 마스터는 슬레이브에 그것이 끝났으며, 슬레이브가 이제 hang up할 수 있음을 알린다. 슬레이브는 hang up하거나, conversation을 인계 받는다. 이는 역할의 변경을 말하는 것으로, 이제 리모트 시스템이 마스터로, 로컬은 슬레이브가 된다. 새로운 마스터는 이제 파일을 보내고, 모든 것이 끝났다면 양쪽 uucico는 종료 메시지를 교환하고 커넥션을 닫는다.

이에 대해 보다 자세히 언급하지는 않겠다. 이를 위해선 소스나 UUCP에 관한 서적을 참고하기 바란다. 물론 넷에 떠도는 정말로 케케묵은 글도 있는데, David A. Naitz가 쓴 것으로 UUCP 프로토콜에 관해 자세히 설명한다. Taylor UUCP FAQ 역시나 UUCP가 실행되는 방법에 대해 자세히 논하고 있으며, 정기적으로 comp.mail.uucp에 포스팅 된다.

uucico12.2.3 Command Line Options

이 섹션에선 uucico의 가장 중요한 커맨드라인 옵션들에 관해서 기술한다. 완전한 옵션 목록은 uucico(1) 매뉴얼 페이지에 있으니 참고하기 바란다.

-s system call 타임 제한에 걸리지 않는다면 system을 호출한다.
-S system 상태에 제한 없이 system을 호출한다.
-r1 마스터 노드내의 uucico를 구동한다. 이는 -s나 -S가 주어지면 디폴트로 같이 주어진다. 혼자 주어지면, -r1옵션은, call 또는 retry 타임 제한에 걸리지 않을 경우 uucico가 sys내의 모든 시스템에대한 호출 시도를 하게 한다.
-r0 uucico를 슬레이브 모드로 구동한다. 이는 -s나 -S가 주어지지 않을 때 디폴트이다. 슬레이브 모드에선 표준 입/출력이 시리얼 포트에 연결되어 있다고 가정되거나, -p옵션으로 지정된 TCP 포트가 사용된다.
-x type, -X type
지정된 타입의 디버깅을 켠다. 여러 타입을 지정할 땐 쉼표로 구분하며, abnormal, chat, handshake, uucp -proto, port, config, spooldir, execute, incoming, outgoing이, 지원되는 타입이다. all을 사용하면 모든 옵션을 켠다. 다른 UUCP implementation과의 호환성을 위해 숫자를 대신 줌으로써, 위의 리스트에서 n번째 아이템에대한 디버깅을 켤 수도 있다.
디버깅 메시지는 /var/spool/uucp아래의 Debug파일에 로그로 남는다.

12.3 UUCP Configuration Files

단순한 파일 전송 프로그램과는 대조적으로, UUCP는 모든 전송을 자동으로 다룰 수 있도록 디자인 되었다. 한 번 적절히 셋업하고 나면, 매일 관리자가 간섭할 필요가 없다. 이에 요구되는 정보는 /usr/lib/uucp 디렉토리 내의 몇가지 설정 파일에 보존된다. 이를 파일의 대부분이 dial out할 때만 사용되는 것들이다.

12.3.1 A Gentle Introduction to Taylor UUCP

UUCP의 설정에 대해 말로써 설명한다는건 좀 어려운 일이다. 그것은 정말 감당하기 힘든 주제이고, 설정파일의 간략한 포맷을 보여준다고 해서 더 쉽게 만들어 주진 못한다. (그래도 Taylor 포맷이 HDB나 Version 2의 오래된 포맷보다는 읽기에 더 쉬울 것이다).

어떻게 이 모든 파일이 상호작용하는가를 느낄 수 있도록, 가장 중요한 한가지를 소개하고 이 파일의 예제를 살펴보도록 하겠다. 지금은 모든 것을 자세히 설명하지는 않고, 좀 더 세세한 내용은 아래 별개의 섹션에서 살펴보도록 한다. 당신의 머신을 UUCP로 사용하도록 셋업하려면, 몇가지 샘플 파일로 시작하여 서서히 당신의 환경에 적용시켜 나가는 것이 최선이다. 아래에 있는 것이나, 선호하는 배포판에 들어 있는 것, 어느것을 사용하든지 무방하다.

이 절에서 논하는 모든 파일은 /usr/lib/uucp나 이것의 서브 디렉토리 내에 있다. 몇몇 리눅스 배포판에는 HDB와 Taylor 설정이 모두 가능하고 각 설정파일 세트에 대해 별개의 서브 디렉토리를 사용할 수 있는 UUCP 바이너리가 들어 있기도 한다. 보통 /usr/lib/uucp 내에 README에 그 설명이 들어 있다.

UUCP가 적절하게 작동하기 위해, 이 파일들은 반드시 uucp 유저의 소유여야만 한다. 그들 중 패스워드와 전화 번호를 담고 있는 것들은 반드시 600의 퍼미션에 맞춰 주어야한다.

핵심 UUCP 설정 파일은 /usr/lib/uucp/config으로, 일반적인 파라미터를 지정하는데 사용된다. 그것들중 가장 중요한 (현재로썬 단 하나 뿐이지만) 것은 당신 호스트의 UUCP 네임이다. Virtual Brewery 에서는 그들의 UUCP 게이트웨이로 vstout을 사용한다.

     # /usr/lib/uucp/config - UUCP main configuration file
     hostname          vstout

다음으로 중요한 설정파일은 sys 파일이다. 그것은 당신 사이트의 모든 시스템 상의 정보를 담고 있다. 이는 사이트 명과, 모뎀 링크를 사용할 때 쓰는 전화 번호 같은 링크 자체에 대한 정보를 담고 있다. 모뎀으로 연결된 pablo라는 사이트의 엔트리는 다음과 같다.

     # /usr/lib/uucp/sys - name UUCP neighbors
     # system: pablo
     system             pablo
     time               Any
     phone              123-456
     port               serial1
     speed              38400
     chat               ogin: vstout ssword: lorca

port는 사용할 포트를 지정하고, time은 전화걸도록 허용된 시간을 지정한다. chat은 로그인 chat 스크립트를 지정한다. - uucico가 pablo에 로그인 하도록, 문자열은 연속적으로 교환된다. 이 chat 스크립트에 대해선 나중에 다시 살펴보도록 한다. port 커맨드가 /dev/cua1같은 디바이스 특수파일을 명시해 주진 않는다. 대신, port 파일 내의 엔트리 네임을 명명하는 것이다. 당신은 port내의 적절한 엔트리를 참조할 수 있다면 얼마든지 긴 이름을 사용할 수도 있다.

port 파일은 링크자체에 특정된 정보를 담고 있다. 모뎀 링크의 경우, 그것엔 사용할 디바이스 특수 파일, 지원되는 속도 범위, 그리고 포트에 연결되는 다이얼링 장비의 타입이 적혀 있다. /dev/cua1(COM2) 아래의 엔트리, NakWell 모뎀이 연결된 포트는 38400bps까지의 속도를 낼 수 있다. 엔트리 네임은 sys 파일 내에 주어진 포트 네임과 맞는 것이 선택 된다.

     # /usr/lib/uucp/port - UUCP ports
     # /dev/cua1 (COM2)
     port               serial1
     type               modem
     device             /dev/cua1
     speed              38400
     dialer             nakwell

dialer 자신에 대한 정보는 또다른 파일에 보관되며, 그 이름은 dial이다. 각 dialer 타입마다, (그것은 기본적으로 리모트 사이트에 다이얼 업 할 때 실행되는 커맨드의 시퀀스를 갖고 있다) 전화번호가 주어진다. 다시금 이는 chat 스크립브로써 지정되는데, 예를 들어 NakWell에 관한 엔트리는 다음과 같다.

     # /usr/lib/uucp/dial - per-dialer information
     # NakWell modems
     dialer             nakwell
     chat               "" ATZ OK ATDT\T CONNECT

chat으로 시작하는 라인은 모뎀 chat을 지정하는 것으로, chat은 모뎀이 그것을 초기화하고 원하는 번호로 다이얼하도록 모뎀과 주고 받는 연속된 커맨드이다. (가령 위의 예제에서, 스크립트가 ATZ을 보내고나서 모뎀이 OK를 보낼 때 까지 기다리고, 또 ATDT\T를 보내고 CONNECT가 모뎀에서 돌아올 때까지 기다리는 식으로 진행되는 스크립트이다. - 역자주) "\T" 시퀀스는 uucico에 의해 전화번호로 대체된다.

uucico가 어떻게 설정파일을 다루는지에 관한 대략적인 지식을 제공하지 위해, 당신이 다음의 커맨드를 실행했다고 가정하자.

     $ uucico -s pablo

uucico가 처음으로 하는 일은 sys 파일 내에 pablo를 검색한다. pablo에 대한 sys 파일 엔트리에서, 그것은 커넥션 수립을 위해 serial1 포트를 사용해야 한다는 것을 보게 된다. port 파일은 이것이 모뎀 포트이고 NakWell 모뎀이 달려있다고 그것에 말해준다.

이제 uucico는 NakWell 모뎀에 관한 엔트리를 위해 dial을 찾고, 그것을 찾아내면 시리얼 포트 /dev/cua1을 열어 dialer chat을 실행한다. 즉, 그것은 "ATZ"를 보내고 "OK"를 기다리는 등의 작업을 말한다. "\T" 문자열을 만나면 uucico는 전화번호(123-456)을 sys 파일에서 얻어, 그에 대치시킨다.

모뎀이 CONNECT를 리턴하면, 커넥션은 수립되고 모뎀 chat은 완료된다. uucico는 이제 sys 파일로 되돌아와 로그인 chat을 실행한다. 우리의 예제에선 "login:" 프롬프트를 기다리고 유저네임(neruda)을 보내고, 다시 "password:"를 기다리다가 패스워드인 "lorca"를 보낸다.

인증이 완료된 후, 리모트 측이 자신의 uucico를 구동하면, 양측은 이전 섹션에서 기술한 handshake 단계로 들어갈 것이다.

설정파일의 종속관계는 그림 12.1에서 볼 수 있다.

그림 12.1: Taylor UUCP 설정파일간의 상호작용

12.3.2 What UUCP Needs to Know

UUCP 설정파일에 관해 서술하기에 앞서, 당신은 그것이 알고있어야만 하는 몇가지 정보를 모아야 한다.

먼저, 당신의 모뎀이 달려있는 시리얼 디바이스가 무엇인지 알아야한다. 보통 (DOS)포트 COM1에서 COM4까지는 디바이스 파일 /dev/cua0에서 /dev/cua3까지와 동일하다. Slackware 같은 배포판에선 적절한 cua* 디바이스 파일의 링크로 /dev/modem을 만들고, kermit과 seyon 등을 이 일반적인 파일을 사용하게 설정한다. 이러한 경우엔 /dev/modem을 UUCP 설정에도 사용할 수 있다.

이렇게 하는 이유는, 모든 dial-out 프로그램이 lock file이란 것을 사용하여 시리얼 포트가 사용중임을 알리기 때문이다. 이러한 lock file의 이름은 LCK..을 디바이스 파일 이름 앞에 붙인 것으로, 예를 들자면 LCK..cua1과 같이 된다 하겠다. 만약 프로그램들이 동일한 디바이스에 다른 이름을 사용한다면, 그것들은 서로의 락 파일을 인식하지 못할 것이다. 그 결과로, 동시에 구동될 때 서로의 세션을 방해한다. 이는 당신이 crontab 엔트리를 사용하여 UUCP 콜을 스케쥴할 때 별로 달갑지 않은 일이다.

시리얼 포트를 셋업하는데 관한 자세한 것은 chapter 4를 참고하라.

다음으로, 당신의 모뎀과 리눅스가 통신하는 속도가 얼마인지 알아야 하며, 이를 최대 유효 전송률(maximum effective transfer rate)로 지정해야 한다. 유효 전송률은 모뎀이 낼 수 있는 물리적 전송률보다 높게 잡아야 한다. 예를 들어, 많은 모뎀이 데이터를 2400bps(bit per second)로 주고 받으나, V.42vis같은 압축 프로토콜을 사용하면 실제 전송률은 9600bps까지로 올라간다.

물론, UUCP가 무언가를 하기 위한 것이므로, 전화 걸 시스템의 전화 번호가 필요하다. 물론, 리모트 머신에 로그인 id와 패스워드 또한 가지고 있어야 한다.

역시나 당신은 어떻게 시스템에 로그인 하는지를 정확히 알고 있어야 한다. 예를 들어, 로그인 프롬프트가 나타나기 전에 BREAK 키를 눌러야 하는가? 그것이 login:를 출력하는지 아니면 user:를 출력하는제? 이는 chat 스크립트를 구성하는데 필요한 것으로, 어떻게 로그인 하는지를 uucico에 말해준다. 만약 당신이 알지 못한다거나 보통의 chat 스크립트가 실패할 경우, kermit이나 minicom 같은 터미널 프로그램으로 시스템에 전화를 걸어 정확히 어떻게 해야하는지를 적는다.

12.3.3 Site Naming

TCP/IP 기반 네트워킹에서처럼, UUCP 네트워킹에서도 당신 호스트를 이름지워줘야 한다. 단순히 직접 다이얼 업하는 사이트 또는 로컬 네트웍 상에서 파일 전송을 위해 UUCP를 사용한다면, 이 이름은 표준을 고려할 필요가 없다.

하지만 mail이나 news 링크에 UUCP를 사용한다면, UUCP 매핑 프로젝트에 등록된 명칭을 사용하고자 할 것이다. UUCP 매핑 프로젝트에 관해선 chapter 13에서 논한다. 게다가 만약 한 도메인에 참여코자 한다면, 당신의 사이트에 공식적인 UUCP 네임을 가지는 것을 고려해 보아야 한다.

종종, 사람들은 UUCP 네임을 그들의 FQDN의 첫 번째 컴포넌트로 사용한다. 가령 당신 사이트의 도메인 주소가 swim.twobirds.com이라면 UUCP 호스트 네임은 swim이 될 것이다. UUCP 사이트는 각각 first-name 기반으로 서로를 인식한다. 물론, FQDN에 연관되지 않은 이름을 사용할 수도 있다.

그러나, official UUCP 네임으로 등록되지 않은 unqulified 사이트 명을 mail 주소에 사용하지 않았는지 확인해야 한다. 등록되지 않은 UUCP 호스트로의 mail은 소멸될 것이다. 이미 다른 사이트가 지닌 이름을 사용한다면, 이 메일은 그 사이트로 라우트 될 것이고, 그곳의 postmaster는 끝없는 두통에 시달리게 될 것이다.

디폴트로, UUCP 슈트는 hostname 커맨드로 지정된 네임을 그 사이트의 UUCP 네임으로 사용한다. 이 네임은 보통 /etc/rc.local 스크립트 내에 지정되어 있다. 만약 호스트 네임으로 지정한 것과는 다른 UUCP 네임을 사용코자 한다면, uucico에 당신의 UUCP네임에 관해 말해주기 위해 hostname을 config파일에 사용해야 한다. 이는 아래에서 설명할 것이다.

12.3.4 Taylor Configuration Files

이제 설정파일로 돌아가 보자. Taylor UUCP는 다음의 파일에서 정보를 얻는다.

config 이는 주 설정 파일이다. 당신 사이트의 UUCP 네임을 여기에 정의할 수 있다.
sys 이 파일엔 당신이 알고 있는 모든 사이트가 적혀 있다. 각 사이트 마다, 그것의 이름과 전화 걸 시간, 전화 번호, 사용하는 디바이스 타입과 어떻게 로그인하는지가 적혀 있다.
port 지원되는 라인 속도와 사용되는 dialer와 함께, 사용가능한 각 포트에 관해 기술하는 엔트리가 들어 있다.
dial 전화 커넥션을 수립하는데 사용되는 dialer를 기술한다.
dialcode 심볼릭 다이얼 코드에 대한 확장(expensions)을 포함한다.
call 시스템에 전화걸 때 사용되는 로그인 네임과 패스워드를 포함한다. 거의 사용되지 않는다.
passwd 로그인 할 때 시스템이 사용할 수 있는 로그인 네임과 패스워드를 갖고 있다. 이 파일은 uucico가 자신 고유의 패스워드 체킹을 할 때만 사용된다.

Taylor 설정 파일은 일반적으로 키워드-값의 짝을 지니는 라인들로 구성된다. 해쉬기호는 그 라인 끝까지가 주석임을 표시한다. 해쉬 기호 자체를 사용하려면 백 슬래쉬를 앞에 붙여 escape 시켜 줘야 한다.

이 설정 파일에서 조절할 수 있는 몇가지 옵션이 존재하는데, 모든 파라미터를 여기서 살펴보진 않고, 가장 중요한 것들만 다루도록 하며, 그것은 모뎀 기반 UUCP를 설정할 수 있게 하는 것들이다. 추가적으로 TCP/IP상 또는 시리얼 라인 직접 연결 상에서 사용할 수 있게끔 수정하는 것또한 다른 절에서 설명한다. 완전한 레퍼런스는 Taylor-UUCP 소스에 들어 있는 Texinfo 문서에서 구할 수 있다.

UUCP 시스템을 완전하게 설정했다고 생각한다면, uuchk 툴(/usr/lib/uucp내에 있다)을 사용하여 설정한 것을 체크할 수 있다. uuchk는 설정파일을 읽어 각 시스템에 대해 사용되는 설정 값에관한 상세한 보고를 출력해 준다.

12.3.5 General Configuration Options - the config File

당신은 UUCP 호스트 네임을 지정하는 용도 이외의 것으로 이 파일을 사용하지 않을 것이다. 디폴트로 UUCP는 hostname 커맨드로 지정한 네임을 사용하지만, UUCP 네임을 별도로 지정해 주는 것이 일반적으로 좋은 생각이다. 아래는 그 예제 파일이다.

     # /usr/lib/uucp/config - UUCP main configuration file
     hostname          vstout

물론, 여기에 지정할 수 있는 자잘한 파라미터들, 가령 스풀 디렉토리 네임이나 anonymous UUCP에 대한 억세스 권한 같은 것들도 존재한다. 억세스 권한에 관해선 이후의 섹션에서 논한다.

12.3.6 How to Tell UUCP about other Systems - the sys File

sys 파일엔 당신의 시스템이 알고 있는 다른 시스템에 관해 적혀있다. 하나의 엔트리는 system 키워드로 시작된다. 다음 system 지정까지의 라인들은 그 사이트에 특정된 파라미터를 열거한다. 보통 한 시스템의 엔트리엔 전화번호와 로그인 chat같은 파라미터등이 정의된다.

첫 번째 system 라인 이전의 파라미터는 모든 시스템에 공통적으로 사용되는 디폴트 값을 지정한다. 보통 프로토콜 파라미터같은 것들이 디폴트 섹션 내에 지정된다.

아래는 가장 중요하다 할 수 있는 필드에 관해 어느정도 상세히 논한 것이다.

System name

system 키워드는 리모트 시스템의 이름을 명시한다. 만약 동일한 시스템에 대해 (uucico가 차례로 시도할 서로다른 전화번호 같은) 몇가지 설정 세트를 사용하고자 한다면, alternates를 지정하면 된다. alternates에 관해선 아래에서 설명하고 있다.

Telephone Number

만약 리모트 시스템이 전화라인을 통해 연결하는 것이라면, phone 필드는 모뎀이 다이얼할 번호를 지정한다. 그것도 uucico의 다이얼링 프로시저에 의해 해석되는 몇 개의 토큰을 포함할 수 있다. '=' 부호는 2차 다이얼 톤을 대기하라는 의미이고, '-' 기호는 1초간 쉼을 표시한다. 예를 들어, 어떤 전화설비에서는 prefix 코드를 먼저 누르고 잠깐 쉰 뒤에 전화번호를 다이얼 해야 한다.

[이에 대한 적절한 영어적 표현을 잘 모르겠다 - 당신은 회사의 내부 설치와 같은 곳에서 전화를 걸기전에 0 또는 9를 눌러주어야 하는 경우를 알 것이다.]

내재된 알파ㅂ 문자열들은 사이트 종속적인 정보, 가령 지역번호(area code) 같은 것을 숨기는데 사용된다. 그러한 문자열은 dialcode 파일을 사용하여 번역된다. 당신이 다음과 같은 dialcode 파일을 갖고 있다고 가정하자.

     # /usr/lib/uucp/dialcode - dialcode translation
     Bogoham          024881
     Coxton           035119

이러한 번역을 통해 sys 파일에 Bogoham7732같은 전화번호를 사용함으로써 좀더 읽기 쉽게 만들 수 있다.

Port and Speed

port와 speed 옵션은 리모트 시스템을 호출하는데 사용되는 디바이스를 선택하고, 그 디바이스의 최대 속도를 지정하는데 쓰인다. system 엔트리는 이 중 어느 한 옵션을 사용하거나, 둘 다 결합해서 사용할 수 있다. port 파일에서 적당한 디바이스를 검색할 때, 포트네임 그리고/또는 속도 범위가 일치하는 포트가 선택된다.

일반적으로 speed 옵션만 사용해도 충분하다. 만약 port내에 하나의 디바이스만이 정의 되어 있다면, uucico는 언제나 옳은 것만을 선택하므로, 어쨌든 원하는 속도만을 주어도 된다. 만약 시스템에 몇 개의 모뎀이 달려 있다해도, 일치하는 것들이 몇 개 있으면, uucico가 사용중이지 않은 것을 찾을때까지 차례로 각 디바이스에 시도를 해 보기 때문에 꼭 특정포트에 이름을 지어 주지 않아도 된다.

The Login Chat

위에서 우리는 이미, 어떻게 리모트 시스템에 로그인 할 것인지 uucico에게 말해주는, 로그인 chat 스크립트를 본 적이 있다. 그것은 로컬 uucico 프로세스가 기다리고, 보내는 문자열을 지정해 주는 토큰의 리스트로 구성된다. 이것의 의도는 uucico로 하여금, 리모트 머신이 로그인 프롬프트를 보낼 때까지 기다린 후, 패스워드를 보내게 한다. expect와 send 문자열은 번갈아 주어지는데, uucico는 send 문자열 뒤에 자동으로 캐리지 리턴 캐릭터(\r)를 덧 붙인다. 단순한 chat 스크립트는 다음과 같다.

     ogin:  vstout ssword:  catch22

expect 필드가 모든 프롬프트를 포함하진 않는다는데 주목하자. 이는 리모트 시스템이 login: 대신에 Login:을 보내오더라도 로그인을 성공하게 만들어 준다.

uucico는 일종의 조건부 실행도 허용하는데, 예를 들어, 리모트 시스템의 getty가 프롬프트를 보내기 전에 reset되어야 하는 경우가 있다. 이를 위해 expect 문자열에 대쉬를 오프셋으로 sub-chat을 덧붙인다. sub-chat은 메인 expect가 실패할 경우, 이를테면 타임아웃이 일어날 때와 같은 때에 실행된다. 이러한 기능을 사용하는 한 방법은, 리모트 사이트가 로그인 프롬프트를 표시하지 않을 때 BREAK를 보내는 것이다. 다음 예제는 로그인 프롬프트가 나타나기 전에 리턴키를 쳐야하는 경우에도 동작하는 포괄적은 chat 스크립트이다. ""는 UUCP가 대기하지 않고 바로 다음의 send 문자열로 넘어가게 하기 위함이다.

     "" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22

chat 스크립트에서 쓸 수 있는 몇가지 특수 문자열과 escape 캐릭터가 존재하는데, 다음은 expect 문자열에 사용가능한 캐릭터를 중 몇가지를 나열한 것이다.

"" 공백 문자열. 이는 uucico가 대기하지 않고 다음의 send 스트링으로 즉시 넘어가게 한다.
\t 탭 캐릭터.
\r 캐리지 리턴 캐릭터.
\s 공백 문자. chat 스트링 내에 공백 문자를 넣고자 할 때 필요하다.
\n 뉴라인 캐릭터
\\ 백 슬래쉬

send 문자열에선, 다음의 escape 캐릭터와 문자열을 추가로 쓸 수 있다.

EOT 전송의 끝(^D
BREAK 브레이크 캐릭터
\c 문자열의 끝에 캐리지 리턴을 붙여 보내지 않게 한다.
\d 1초 동안 보냄을 지연시킨다.
\E echo 체킹을 켠다. 이는 uucico가 쓰는 문자열이 디바이스에서 되돌아올 때까지 uucico가 chat을 계속 진행하지 않고 대기하게한다. 이것은 주로 모뎀 chat(아래에서 볼 수 있다) 내에 사용될 때 유용하다. echo 체킹은 디폴트로 꺼져 있다.
\e echo 체킹을 끈다.
\K BREAK와 동일하다.
\P 아주 잠깐동안 멈춘다.

Alternates

때때로 하나의 시스템에대해 여러개의 엔트리를 가져야 할 필요가 있다. 예를 들어, 그 시스템에 다른 모뎀라인으로 연결할 수 있는 경우가 그에 해당된다. Taylor UUCP에서는 alternate라는 것을 정의하여 이렇게 할 수 있다.

alternate 엔트리는 모든 세팅을 메인 시스템 엔트리에서 얻고, 디폴트 시스템 엔트리 내의 것들을 override하거나 그에 추가되는 값만이 지정된다. alternate 엔트리는 alternate 키워드 라인을 기준으로 시스템 엔트리와 구분된다.

pablo에 두 개의 전화번호를 사용하려면, 다음과 같이 해당 sys 엔트리를 수정하면 된다.

     system     pablo
     phone      123-456
     ... entries as above ...
     alternate
     phone      123-455

pablo에 전화를 걸 때, uucico는 이제 먼저 123-456으로 다이얼하고, 실패할 경우 alternate를 시도한다. alternate 엔트리는 모든 세팅을 메인 시스템 엔트리에서 얻으며, 오직 전화번호만을 오버라이드한다.

Restricting Call Times

Taylor UUCP는 리모트 시스템에 전화를 것 수 있는 시간을 제한하는 몇가지 방법을 제공한다. 리모트 시스템이 일과시간(bussiness hours)에만 서비스를 제공하게 제한하거나, 단순히 통신량이 많은 시간대를 피하기 위해서 이를 사용한다. 주의할 것은 call time restriction은 -s나 -f옵션을 uucico에 주어서 언제나 오버라이드 할 수 있다는 것이다.

디폴트로 Taylor UUCP는 어떠한 시간대에도 연결을 허용하지 않으므로, sys 파일에 일종의 시간대 지정흘 해 주어야만 한다. 만약 call time restriction을 사용하지 않을 생각이라면 sys 파일의 time 옵션에 Any의 값을 지정해 주어야 한다.

call time을 제한하는 가장 단순한 방법은 time 엔트리 뒤에 요일과 시간 문자열을 주는 것이다. 요일은 Mo, Tu, We, Th, Fr, Sa, Su의 조합 또는 Any, Never 또는, 월요일에서 일요일까지를 나타내는 Wk중 어느것을 사용해도 무방하다. 시간대는 대쉬로 나뉜 2개의 24시간 시계로 구성되며, 전화걸 수 있는 시간대의 범위를 지정한다. 이들 토큰의 조합은 서로간에 공백없이 적으며, 여러개의 요일·시간대 지정은 쉼표로 함께 그룹화 할 수 있다. 예를 들어,

     time       MoWe0300-0730,Fri1805-2000

는 월요일과 화요일에는 오전 3시에서 7시 30분까지, 그리고 금요일에는 오후 6시 5분부터 8시까지 전화를 허용한다. 시간대 필드가 자정을 경과할 때, 가령 Mo1830-0600같은 경우에는, 실제로 자정에서 오전 6시까지, 그리고 오후 6시 30분에서 자정까지를 의미한다.

특수한 문자열로 취급되는 Any와 Never는, 언제나 전화를 허용하거나 절대 허용하지 않음을 각각 의미한다.

time 커맨드는 선택적인 두 번째 인자를 통해 retry 타임을 분단위로 받는다. 커넥션 성립에 실패하면, uucico는 특정 인터벌 동안 리모트 호스트에 다시 다이얼업 시도를 하지 못하게 할 것이다. 디폴트로 uucico는 실패를 거듭할수록 retry 인터벌이 증가하는 exonential backoff 체계를 사용한다. 예를 들어 5분으로 retry 타임을 지정해 놓았다면, uucico는 가장 최근에 실패한 이후로 5분동안 리모트 시스템에 전화 걸기를 거부할 것이다. (원본자체가 문맥에 맞지 않음-역자주)

timegrade 커맨드는 스케쥴에 최대 스풀 등급을 덧붙인다. 예를 들어, 다음의 timegrade 커맨드를 system 엔트리내에 적었다고 가정해보자.

     timegrade          N Wk1900-0700,SaSu
     timegrade          C Any

이는 C와 그 이상의 스풀 등급을 가진 job(혼히 mail은 B나 C의 등급으로 queue된다)이 call이 수립될 때마다 전송되게하고, news(보통 N의 등겁으로 queue된다)는 주말이나 밤에만 전송되도록 한다.

time과 마찬가지로, timegrade도 세 번째 인자를 통해 분단위로 retry 인터벌을 받으며, 세 번째 인자는 생략 가능하다.

그러나 스풀등급에 관한 결점을 하나씩 들어보자면, 먼저 timegrade 옵션을 당신의 시스템이 보내는 것에만 적용되는 것이기 때문에, 리모트 시스템은 그것이 원하는 모든 것을 보낼 수 있다. call-timegrade 옵션을 별도로 사용하여 위에서 스풀등급이 주어진 job만을 리모트에서 보내도록 요구할 수는 있지만, 그것이 꼭 그 요구에 따른다는 보장은 없다.

이와 유사하게, timegrade 필드는 리모트 시스템이 전화걸어 들어올 때 체크되지 않으므로, 전화건 시스템에 queue되는 어떠한 job도 보내어진다. 그러나 리ㅊ모트 시스템은 당신의 uucico가 자신을 특정 스풀 등급으로 제한하도록 별도로 요구할 수 있다.

12.3.7 What Devices there are - the port File

port 파일은 uucico에 사용가능한 포트에 관해 알려준다. 이들은 모뎀 파트일 수도, 또는 다이렉트 시리얼 라인이나 TCP 소켓같은 다른 타입일 수도 있다.

sys> 파일과 마찬가지로, port 파일은 port 키워드로 시각하고, 뒤에 포트 네임이 붙는 별개의 엔트리들로 이루어져있다. 이 포트네임은 sys 파일의 port 선언문에의해 사용되는 것으로, 꼭 고유한 이름일 필요는 없다. 만약, 동일한 이름을 가진 포트가 여러개 존재한다면, uucico는 현재 사용되고 있지 않는 포트를 찾을때까지, 각각 차례로 시도한다.

port 커맨드 바로 뒤에는, 포트의 타입을 기술하는 type 선언문이 붙는다. 선언문의 값으로 쓸 수 있는 적절한 타입으론 modem, 다이렉트 커넥션을 나타내는 direct, 그리고 TCP소켓을 위한 tcp가 있다. 만약 port 커맨드가 없다면 포트 타입은 디폴트로 모뎀에 맞춰진다.

이 섹션에서 우리는 모뎀포트만을 다룰 것이다. TCP 포트와 다이렉트 라인은 이후의 절에서 논한다.

모뎀과 다이렉트 포트의 경우, device 지정을 통하여, 전화거는 디바이스를 지정해 주어야한다. 보통 이는 /deev/cua1과 같은 /dev 디렉토리 내의 디바이스 특수 파일의 이름이다.

모뎀 디바이스의 경우, 포트 엔트리는 어떤 타입의 모뎀이 포트에 연결되어 있는지도 결정한다. 다른 종류의 모뎀은 다르게 설정되어야 한다. Hayes 호환이라는 모뎀들 조차도 실제로 꼭 같게 만들어지진 않는다. 그러므로 uucico에 어떻게 그 모뎀을 초기화하는지, 어떻게 원하는 번호로 다이얼하게 만드는 지를 알려줘야 한다. Taylor UUCP는 모든 dialer에 대한 것을 dial이라는 파일에 보관한다. 이들 중 어느 것을 사용하더라도, dialer 커맨드를 이용하여 dialer의 이름을 지정해 줘야한다

이따금씩, 전화걸 시스템에 따라 모뎀을 다르게 사용하고자 할 때가 있는데, 예를 들어, 어떤 오래된 모뎀은 고속 모뎀이 14000bps로 연결을 시도할 때, 이를 이해하지 못한다. 이를 테면, 9600bps로 연결을 협약하는 대신에 단순히 라인을 drop해 버린다. 이런 바보같은 모뎀을 사용하는 drop이라는 사이트를 안다고 할 때, 그것에 전화 걸 경우엔 모뎀을 다른 방식으로 셋업해줘야 한다. 이제 새로운 포트에 다른 이름, serial1-slow 같은 것을 주고, sys 내의 drop 시스템 엔트리 내에 port 지정을 사용하자.

더 나은 방법은, 지원하는 속도에 따라 포트를 구별하는 것이다. 예를 들어, 위와 같은 경우에대한 두 개의 포트 엔트리는 다음과 같은 형태로 쓸 수 있다.

     # NakWell modem; connect at high speed
     port       serial1         # port name
     type       modem           # modem port
     device     /dev/cua1       # this is COM2
     speed      38400           # supported speed
     dialer     nakwell         # normal dialer

     # NakWell modem; connect at low speed
     port       serial1         # port name
     type       modem           # modem port
     device     /dev/cua1       # this is COM2
     speed      9600            # supported speed
     dialer     nakwell-slow    # don't attempt fast connect

drop 사이트에대한 시스템 엔트리는 serial1을 포트네임으로 주나, 9600bps에 한해서만 사용할 것을 요구한다. 그러면 uucico는 자동으로 두 번째 포트 엔트리를 사용한다. 시스템 엔트리내의, 38400bps의 속도를 지닌 나머지 모든 사이트들에는 첫 번째 포트엔트리를 사용하여 전화를 건다.

12.3.8 How to Dial a Number - the dial File

dial 파일엔 사용되는 여러 dialer가 사용되는 방법이 적혀 있다. 전통적으로 UUCP는 모뎀보다는 다이얼러라고 일컫는데, 왜냐하면 오래전엔 하나의 자동 다이얼링 디바이스가 모든 모뎀 탱크를 제공하는 것이 보통이었기 때문이다. 오늘날에는 대부분의 모뎀에 다이얼링 지원이 탑재되어 있어, 이들간의 구분이 다소 흐릿해 졌다.

그럼에도, 서로다른 다이얼러 또는 모뎀은 다르게 설정될 필요가 있다. dial 파일에 그들 각각을 기술할 수 있다. dial 내의 한 엔트리는 dialer 커맨드로 다이얼러의 이름을 지정하는 것부터 시작한다.

이 외에 가장 중요한 엔트리는 모뎀 chat으로, chat 커맨드를 통해 지정된다. 로그인 chat과 비슷하게, 그것은 uucico가 다이얼러에 보내고 되돌아오길 기대하는 문자열의 연속으로 이루어져 있다. 모뎀 chat은, 모뎀을 어떤 알려진 상태로 리셋하고, 번호를 다이얼하는데 사용된다. 다음의 다이얼러 엔트리의 예제는 Hayes 호환 모뎀의 일반적은 모뎀 chat을 보여준다.

     # NakWell modem; connect at high speed
     dialer      nakwell         # dialer name
     chat        "" ATZ OK\r ATH1E0Q0 OK\r ATDT\T CONNECT
     chat-fail   BUSY
     chat-fail   ERROR
     chat-fail   NO\sCARRIER
     dtr-toggle  true

모뎀 chat은 "", 즉 공백 expect 문자열로 시작한다. 그러면 uucico는 첫 번째 커맨드(ATZ)를 보낸다. ATZ은 모뎀을 리셋하는 Hayes 커맨드이다. 그것은 모뎀이 OK를 보낼때까지 기다리고, 로컬 echo를 끄는 등의, 다음 커맨드를 보낸다. 모뎀이 다시 OK를 리턴하면, uucico는 다이얼림 커맨드(ATDT)를 보낸다. escape 시퀀스 \T가 이 문자열에 있는데, 이는 sys 파일에서 얻어지는 전화번호로 대체된다. uucico는 모뎀에게서, 리모트 모뎀과의 커넥션이 성공적으로 수립되었음을 알리는 CONNECT 스트링을 리턴되길 기다린다.

종종, 다른 시스템이 다른 누군가와 대화 중이거나 통화중이면, 모뎀은 리모트 시스템에 연결하지 못하고 실패한다. 이러한 경우에 모뎀은 원인을 지시하는 에러 메시지를 리턴할 것이다. 모뎀 chat은 그러한 메시지를 감지할 능력이 없으므로, uucico는 타임아웃될 때까지 expect 문자열을 계속 기다릴 것이다. 그리하여 UUCP는 파일에 log를 남기고, 진짜 이유대신에 "timeout in chat script"를 보여준다.

그러나, Taylor UUCP는 위에 적힌 것처럼 chat-fail 커맨드를 사용하여 이러한 에러 메시지에 관해 uucico에 말해줄 수 있다. uucico가 모뎀 chat 실행중에 chat-fail을 감지하면, 그것은 전화걸기를 중단하고 UUCP 로그파일에 에러메시지를 남긴다.

위의 예제에서 마지막 커맨드는, 모뎀 chat을 시작하기 전에 UUCP가 DTR 라인을 토글하게 한다. 대부분의 모뎀은 DTR 라인의 변화를 감지할 때 on-hook으로 설정되고 커맨드모드로 들어간다.

12.3.9 UUCP Over TCP

처음들으면 이 말이 다소 이치에 닿지않는 듯하지만, TCP 상에서 UUCP를 사용하여 데이터를 전송하는게 꼭 나쁜생각은 아니며, Usenet news같은 많은 량의 데이터를 전송할 때엔 더욱 그렇다. TCP 기반 링크상에서 news는 일반적으로 압축이나 그 외의 최적화를 거치지 않고, 글을 독립적으로 요청하고 보내는 NNTP를 통해 교환된다. 대규모 사이트에선 동시발생적인 뉴스 제공방식이 적절할 지 모르지만, 이러한 기술은 ISDN과 같은 느린 커넥션을 지닌 소규모 사이트에선 달갑지 않은 방법이다. 이들 사이트는 보통, TCP의 질적인 면과, news를 큰 덩어리로 묶어 압축함으로써 낮은 오버헤드로 전송할 수 있는 잇정을 조합할 수 있었으면 한다. 이 덩어리를 전송하는 표준적인 방법은 TCP 상에서 UUCP를 사용하는 일이다.

sys내에, TCP로 호출할 시스템은 다음의 방법으로 지정할 수 있다.

     system     gnu
     address    nes.groucho.edu
     time       Any
     port       tcp-conn
     chat       ogin: vstout word: clouseau

address 커맨드엔 호스트의 IP 주소 또는 FQDN을 준다. 이에 대응되는 port엔트리는 다음과 같다.

     port       tcp-conn
     type       tcp
     service    540

이 엔트리는, sys 엔트리가 tcp-conn을 참조할 때 TCP 커넥션이 사용될 것이고, uucico가 리모트 호스트의 540번 TCP 네트웍 포트에 연결을 시도할 것이라고 알린다. 540번 포트는 UUCP의 디폴트 포트이다. 포트 번호 대신에 심볼릭 네임을 service 커맨드에 줄 수도 있다. 이 서비스 네임에 상응하는 포트 번호는 /etc/services 검색을 통해 얻어지며, UUCP 서비스에 대한 표준 서비스 네임은 uucpd이다.

12.3.10 Using a Direct Connection

당신의 시스템 vstout에서 tiny로 연결된 라이렉트 라인을 사용한다고 가정해보자. 모뎀의 경우와 아주 유사하게, sys 파일에 시스템 엔트리를 적어줘야 한다. port 커맨드는 tiny가 연결되어 있는 시리얼 포트를 식별한다.

     system     tiny
     time       Any
     port       direct1
     speed      38400
     chat       ogin: cathcart word: catch22

port 파일내에 다이렉트 커넥션을 위한 시리얼 포트를 적어줘야 한다. dialer 엔트리는, 다이얼링이 필요치 않으므로 적을 필요가 없다.

     port       direct1
     type       direct
     speed      38400

12.4 The Do's and Dont's of UUCP - Tuning Permissions

12.4.1 Command Execution

UUCP의 임무는 한 시스템에서 다른 곳으로 파일을 카피하고, 리모트 호스트에서 특정 커맨드를 실행하도록 요청하는 것이다. 물론, 당신은 관리자로서 다른 시스템을 받아들이는 권한을 조절하고자 할 것이다. - 그들이 아무 커맨드나 당신시스템에서 실행하도록 허용하는 일은 전적으로 좋지 않은 생각이다.

디폴트로 Taylor UUCP가, 다른 시스템이 당신 시스템에서 실행할 수 있도록 허용하는 커맨드는, email과 Usenet news를 UUCP 상에서 교환하는데 사용되는 rmail과 news뿐이다. uuxqt가 사용하는 디폴트 search path는 /bin, /usr/bin, /usr/local/bin을 포함하며, 컴파일 타입에 옵션으로 지정할 수도 있다. 특정 시스템에대한 커맨드 세트를 변경하기 위해, sys 파일 내에 commands 키워드를 사용할 수 있다. 이와 비슷하게 search path 역시 command-path 선언문으로 변경할 수 있다. 예를 들어, pablo가 rmail과 rnews에 더하여 rsmtp를 실행하도록 허용하고자 한다고 가정한다면,

     system     pablo
     ...
     commands rmail rnews rsmtp

12.4.2 File Transfers

Taylor UUCP는 파일 전송을 세부적으로 조절홀 수 있게 한다. 극단적일 경우, 특정 시스템과의 전송을 할 수 없게 할 수도 있다. request를 no로 설정하는 것 만으로 리모트 시스템은 당신의 시스템에서 파일을 얻거나 파일을 보내지 못하게 된다. 비슷하게, 당신은 transfer를 no로 세팅하여 어떤 시스템과 파일을 주고 받지 못하게 할 수 있다. 디폿트로 로컬과 리모트 시스템의 유저 모두는 파일의 업로드와 다운로드가 허용되어 있다.

게다가, 당신은 파일이 카피되는 디렉토리를 설정할 수도 있다. 보통 리모트 시스템에서의 억세스를 단일 디렉토리 계층내로 제한하고자 하나, 유저가 자신의 홈 디렉토리에서 파일을 보낼 수 있도록 허용한다. 통상적으로, 리모트 유쥬는 public UUCP 디렉토리인 /var/spool/uucppublic에서만 파일을 얻을 수 있는데, 이는 인터넷의 무수한 FTP 서버들처럼, 파일을 공개하는 전통적인 장소이다. 이 디렉토리는 흔히 틸드 캐릭터(~)를 사용하여 지시된다.

Taylor UUCP는 또한, 파일을 보내고 받는 디렉토리를 설정하는 4개의 커맨드를 제공한다. 유저가 파일을 보내도록 요청할 수 있는 디렉토리를 지정하는 local-send와, 유저가 파일을 받도록 요청하는 디렉토리를 지정하는 local-recieve, 그리고 이와 유사한 일을 외부시스템에 지정하는 remote-send와 remote-recieve들이 그것 다. 다음의 예제를 생각해보자.

     system             pablo
     ...
     local-send         /home ~
     local-receive      /home ~/receive
     remote-send        ~ !~/incoming !~/receive
     remote-receive     ~/incoming

local-send 커맨드는 당신 호스트상의 유저들이 /home과 public UUCP 디렉토리 아래의 파일을 pablo로 보낼 수 있도록 허용한다. local-receive 커맨드는 world-writable한 uucppublic내의 receive 디렉토리 또는 /home 아래의 world-writable한 디렉토리에 파일을 받을 수 있도록 허용한다. remote-send 지정은 pablo가 /var/spool/uucppublic에서, incoming과 receive 디렉토리하의 파일을 제외하고, 요청할 수 있게한다. 이는 디렉토리 이름 앞에 느낌표를 붙여ㅍ uucicoㅍ에 알려준다. 마지막 라인은 pablo가 incoming에 어떤 파일도 올릴수 있게끔 한다.

UUCP를 사용한 파일전송이 가지는 가장 큰 문제점은 파일을 수신하는 디렉토리가 반드시 world-writable해야 한다는 것이다. 이는 몇몇 유저들로 하여금 다른 유저에 대한 트랩을 설치해 놓는 등의 일을 하도록 유혹하지만, UUCP 파일전송을 모두 불가능하게 하지 않는한 이 문제점을 피할 방법이 없다.

12.4.3 Forwarding

UUCP는 당신을 대신하여 다른 시스템이 파일 전송을 수행하게 만드는 메카니즘을 제공한다. 예를 들어, 이는 seci가 당신을 위해 uchile에서 파일을 얻어 당신 시스템으로 보내게 만들 수도 있으며, 다음은 그 커맨드이다.

     $ uucp -r seci!uchile!~/find-ls.gz ~/uchile.files.gz

몇몇 시스템을 거쳐 job을 넘겨주는 이러한 기술을 일컬어 forwarding이라 한다. 위의 예제에서 포워딩을 사용하는 이유는 seci가 uchile에 UUCP 억세스 할 수 있으나, 당신의 호스트는 그럴 수 없기 때문이다. 그러나 만약 당신이 UUCP 시스템을 돌린다면, 최신 X11R6 소스 릴리즈를 다운로드하도록 만들어 무시무시할 정도의 전화요금을 써버리지 않는다고 믿는 몇몇 호스트에게만으로 포워딩 서비스를 제한하고자 할 것이다.

디폴트로 Taylor UUCP는 포워딩이 전부에게 모두 불가능하다. 특정 시스템에 대해 포워딩을 가능토록 하기 위해선 forward 커맨드를 써주면 된다. 이 커맨드는 job을 포워드하라고 요청할 수 있는 시스템의 리스트를 지정한다. 예를 들어 seci의 UUCP 관리자는 다음의 라인을 sys 파일에 추가하여 pablo가 uchile의 파일을 요청할 수 있게 만든다.

     ####################
     # pablo
     system         pablo
     ...
     forward       uchile
     ####################
     # uchile
     system        uchile
     ...
     forward-to     pablo

uchile에 대한 forward-to 엔트리는 리턴되는 파일을 실제로 pablo에 넘겨주는데 필요하다. 만약 이를 적어주지 않는다면 UUCP는 그것을 drop해 버릴 것이다. 이 엔트리는 seci를 통해 pablo에 파일을 보내는 것만을 uchile에 허용하도록 forward 커맨드를 사용했다. 그 외의 다른 것은 허용하지 않는다.

모든 시스벰에 포워딩을 허용하려면, 특수 키워드인 ANY를 사용하라(대문자로 써야한다).

12.5 Setting up your System for Dialing in

당신의 사이트를 다이얼인 할 수 있게 셋업하려면, 시리얼 포트에 로그인을 허용하고, UUCP 계정을 제공하도록 몇가지 시스템 파일을 맞춰주어야 한다. 이것이 이 섹션에서의 주요 논점이 될 것이다.

12.5.1 Setting up getty

시리얼 라인을 다이얼인 포트로 사용하고자 한다면, 이 포트에 getty 프로세스를 켜 두어야 한다. 그러나, 몇가지 setty implementation들은 이에 사실상 적합하지 않은데, 왜나하면 당신은 보통 전화받거나 전화거는데 시리얼 포트를 사용하고자 하기 때문이다. 그러므로 당신이 uucico나 minicom과 같은 여타 프로그램들과 라인을 공유할 수 있는 getty를 사용하고 있는지 확인해야 한다. 이러한 프로그램 중의 하나가 바로 getty-ps 패키지의 uugetty이다. 대부분의 리눅스 배포판에 포함되어 있으니 /sbin 디렉토리내에 uugetty가 있는지 체크하라. 내가 일고 있는 또다른 프로그램은 Gert Doering의 mgetty로, 팩시밀리의 수신도 지원한다. 최신 버전은 sunsite.unc.edu에서 바이너리와 소스로 구할 수 있다.

uugetty와 mgetty가 로그인을 다루는 방법에 있어서의 차이점은 이 짧은 절에서 설명할 만한 것이 아니므로, 좀 더 설명을 원한다면 Grag Hankins의 Serial HOWTO나, getty-ps와 mgetty에 딸려오는 문서를 참고하라.

12.5.2 Providing UUCP Accounts

다음으로 당신은 리모트 사이트에서 당신 시스템으로 로그인하여 커넥션을 열 수 있도록 유저 계정을 셋업해 주어야 한다. 일반적으로 각 시스템마다 서로다른 로그인 네임을 제공하는데, 시스템 pablo에 대한 계정을 셋업할 때, 유저네임으로 Upablo를 준다고 하자.

시리얼 포트를 통해 다이얼인 하는 시스템마다, 패스워드파일, /etc/passwd에 이 계정을 추가해 주어야 한다. 모든 UUCP 로그인을 uuguest와 같은 특수한 그룹에 집어 넣은 것도 좋은 예이다. 그 계정의 홈 디렉토리는 퍼블릭 수풀 디렉토리인 /var/spool/uucppublic로, 로그인 쉘은 uucico로 지정한다.

만약 당신이 shadow 패스워드를 인스톨하였다면, useradd 커맨드로 이렇게 할 수 있다.

     # useradd -d /var/spool/uucppublic -G uuguest -s /usr/lib/uucp/uucico Upablo

만약 shadow 패스워드 슈트를 사용하지 않는다면, 손으로 직접 /etc/passwd를 수정하여, 아래에 보이는 것과 같은 추가하라. 여기엔 5000과 150의 uid와 gid 번호가 각각 유저 Upablo와 그룹 uuguest에 할당되어 있다.

     Upablo:x:5000:150:UUCP Account:/var/spool/uucppublic:/usr/lib/uucp/uucico

이 계정을 만들고 난 뒤에는, passwd 커맨드로 그것의 패스워드를 세팅하여 주어야한다.

TCP 상에서 UUCP 시스템이 당신의 시스템에 연결할 수 있도록 하기위해선, uucp 포트상의 인커밍 커넥션을 핸들링할 수 있도록 inetd를 셋업해 주어야한다. 다음의 라인을 /etc/inetd.conf에 추가함으로써 이와같이 할 수 있다.

     uucp   stream  tcp   nowait  root  /usr/sbin/tcpd  /usr/lib/uucp/uucico -l

-l 옵션은 uucico가 그것의 로그인 인증을 수행하게 만든다. 그것은 표준 login프로그램과 꼭 같은 로그인 네임과 패스워드 프롬프트를 띄울 것이나, /etc/passwd가 아니라 독자적인 패스워드 데이터 베이스에 의존한다. 이 고유 패스워드 파일은 /usr/lib/uucp/passwd이며, 로그인 네임과 패스워드를 담고 있다.

     Upablo  IslaNegra
     Ulorca  co'rdoba

물론, 이 파일은 uucp의 소유여야 하고, 퍼미션은 6000으로 주어져 있어야 한다.

이 데이터 테이스를 보통 시리얼 로그인에 사용하는 것이 좋은 생각처럼 들릴지 모르겠지만, 몇가지를 고치지 않고선 볼가능하다. 우선 이를 위해 Taylor UUCP 1.05가 필요한데, 그 이유는 그것이 -u 옵션을 사용하여 getty가 uucico에 전화건 유저의 로그인 네임을 넘겨 줄 수 있게 하기 때문이다. 그러면 당신이 보통의 /bin/login 대신에 uucico를 실행하는 것처럼 getty를 속여야 하는데, getty-ps로 설정파일에 LOGIN 옵션을 세팅해 주어 이렇게 할 수 있다. 그러나, 이는 인터랙티브 로그인을 완전히 불가능하게 만든다. 반면에 mgetty는 유저가 주는 네임에 기반하여 서로 다른 로그인 커맨드를 실행할 수 있게 하는 나이스한 기능을 지니고 있다. 예를 들어, mgetty에게 대문자 U로 시작하는 로그인 네임을 주는 모든 유저에 대해 uucico를 사용하나, 그 외의 모든 유저에겐 표준 login 커맨드를 통해 핸들링하라고 말해 줄 수 있다.

잘못된 시스템 네임을 주어 그들의 모든 mail을 걷어가는 사람들에게서 당신의 UUCP 유저들을 보호하기 위해선, sys 파일 내예 각 시스템 엔트리마다 called-login 커맨드를 추가해 주어야 한다. 이는 아래의 Protecting Yourself Against Swindlers 섹션에서 적고 있다.

12.5.3 Protecting Yourself Against Swindlers

UUCP가 안고 있는 가장 큰 문제점은 전화거는 쪽 시스템에서 자신의 이름을 속일 수 있다는 것으로, 전화 받는 시스벰에 로그인한 후 그것의 네임을 알리지만 서버에선 이를 체크할 방법이 럽다는 것이다. 그리하여 attacker는 자신의 UUCP계정으로 로그인한 후, 다른 사람인 체하여 다른 사이트의 메일을 집어올 수 있다. 이는 당신이 anonymous UUCP를 통한 로그인을 제공할 경우, 패스워드가 공개되므로 더욱 문제거리가 된다.

당신 시스템에 전화거는 모든 사이트가 정직하다고 믿을 수 있을 지라도, 당신은 반드시 이러한 부류의 사기꾼에 대한 대처방안을 마련해 두어야한다. 이러한 재난에대한 해결법은 sys내에 called-login을 지정하여 각 시스템이 특정한 로그인 네임을 사용하길 요구하는 것이다. 다음은 시스템 엔트리 예제이다.

     system          pablo
     ... usual options ...
     called-login    Upablo

이것의 결과로, pablo라고 행세하는 시스템이 로그인 할 때, uucico는 그것이 Upablo로서 로그인해 들어왔는지를 체크할 것이다. 만약 그렇지 않다면 전화건 시스템은 거부되며 커넥션은 drop된다. sys 파일에 추가하는 모든 system 엔트리마다 called-login 커맨드를 추가하는 것을 버릇으로 들이도록 하라. 그것이 당신의 사이트에 전화를 걸든, 그렇지 않든가에 상관ㅇ뷇이 이를 모든 시스템에 해 주어야 한다는 것이 중요하다. 전화를 걸찌 않을 그러한 사이트들에 대해선 neverlogin와 같은 허위 유저네임을 called-login에 지정해 주는 것이 좋다.

12.5.4 Be Paranoid - Call Sequence Checks

사기꾼을 막고 감지하는 또다른 방법은 콜 시퀀스 체크(call sequence check)이다. 콜 시퀀스 체크는 당신이 UUCP 시스템에 로그인할 때 쓰는 패스워드를 찾기 위해 무언가를 조작해대는 훼방꾼을 막을 수 있도록 도와준다.

콜 시퀀스 체크를 사용할 때, 양쪽 머신은 커넥션이 성립된 수를 보존하는데, 그것은 각 커넥션마다 증가한다. 로그인한 후 caller는 자신의 콜 시퀀스 번호를 보내고, callee는 자신의 번호에대해 체크한다. 만약 그것들이 일치하지 않는다면, 커넥션 시도는 것부될 것이다. 만약 최소번호가 랜덤으로 선택된다면 attacker는 옳은 콜 시컨스 넘버를 유추해내기 어려울 것이다.

그러나, 콜 시퀀스 넘버는 이보다 더 많은 일을 해준다. 어떤 똑똑한 사람이 당신의 패스워드와 콜 시퀀스 넘버를 찾았다면 당신은 이를 알아낼 수 있다. attacker가 당신의 UUCP feed에 전화를 걸어 mail을 도둑질해 갔다면, 이는 콜 시퀀스 넘버를 1 증가 시키게 된다. 다음번에 당신이 로그인 하려할 때 리모트 호스트의 uucico는 그 번호가 더이상 일치하지 않기 때문에 당신을 몰아낼 것이다.

콜 시퀀스 체크를 활성화 시켰다면, 어택의 가능성 여부에대한 힌트를 주는 에러메시지가 있는지 로그파일을 수시로 체크해 주어야 할 것이다. 만약 당신의 시스템이 calling 시스템이 넘겨준 콜 시퀀스 넘버를 거부한다면, uucico는 로그파일에 "Out of sequence call rejected"라는 메시지를 집어넣을 것이다. 만약 당신의 시스템이 시퀀스 넘버의 불일치로 거부당했다면, 그것은 로그파일에 "Handshake failed(RBADSEQ)"라는 메시지를 남길 것이다.

콜 시퀀스 체크를 활성화하기 위해선, 다음의 커맨드를 system 엔트리에 추가하면 된다.

     # enable call sequence checks
     sequence       true

이 외에도, 시퀀스 넘버를 지닌 파일을 만들어 주어야하는데, Taylor UUCP는 리모트 사이트의 스풀 디렉토리내의 .sequence라는 파일에 시퀀스 넘버를 보존한다. 그것은 반드시 uucp의 소유여야하며, 600모드(즉, uucp에게만 읽기가 가능한)로 지정되어 있어야한다. 상호 동의하에 임의로 시작 값을 사용하여 파일을 초기화 해 주는 것이 최선이다. 그렇지 않다면 attacker는 임의의 값, 이를테면 60까지의 모든 값을 시도해 그 번호를 알아내려 할 수 있을 것이다.

     # cd /var/spool/uucp/pablo
     # echo 94316 > .Sequence
     # chmod 600 .Sequence
     # chown uucp.uucp .Sequence

물론, 리모트 사이트에서도 콜 시퀀스 체크를 활성화해 주어야하며, 당신과 정확히 동일한 시퀀스 넘버를 사용하여 시작해야한다.

12.5.5 Anonymous UUCP

당신의 시스템에 anonymous UUCP 억세스를 제공하고자 한다면, 먼저 위에서 기술한 것처럼 특수한 계정을 셋업해 주어야 한다. 통상적으로 uucp를 로그인 네임과 패스워드로 준다.

또한 unknown 시스템에 대한 몇가지 보안 옵션도 지정해 주어야 하는데, 예를 들면 그들이 당신 시스템 상에서 어떤 커맨드를 실행하지 못하게 하는 것이다. 그러나 이러한 파라며터를 sys 파일에서 지정해 줄 수 럽는 것이, system 커맨드가 시스템의 이름을 요하는데, 우리는 그걸 모르기 때문이다. Taylor UUCP는 이러한 딜레마를 unknown 커맨드로 해결한다. unknown은 config 파일에서 사용할 수 있으며, system 엔트리에서 일반적으로 쓸수 있는 어떠한 커맨드도 지정할 수 있다.

     unknown        remote-receive ~/incoming
     unknown        remote-send ~/pub
     unknown        max-remote-debug none
     unknown        command-ppath /usr/lib/uucp/anon-bin
     unknown        commands rmail

이는 unknown 시스템이 /usr/spool/uucppublic 아래의 pub 디렉토리내의 파일을 다운로드할 수 있고, 파일 업로드는 incoming 디렉토리에 하도록 제한한다. 그 다음의 라인은 uucico가 리모트 시스템에서의 디버깅 활성화 요청을 무시하게 만든다. 마지막 두 라인은 unknown 시스템이 rmail 커맨드들 실행하도록 허용하나, 지정된 커맨드 패스로 인해 uucico는 private 디렉토리인 anon-bin에서만 rmail을 검색한다. 이는 당신이 특수한 rmail, 가령 조사를 위한 목적으로 모든 메일을 슈퍼유저에게 포워드시키는 것을 제공할 수 있게 한다. 이것으로 anonymous 유저들이 시스템의 운영자에게 연락할 수는 있으나, 그와 동시에 다른 사이트로 mail을 집어 넣는 일을 막을 수 있다.

anonymous UUCP를 동작시키려면 config 파일에 적어도 하나의 unknown 커맨드는 들어있어야 한다. 그렇지 않다면, uucico는 모든 unknown 시스템을 거부할 것이다.

12.6 UUCP Low-Level Protocols

세션 컨브롤과 파일 전송에 대해 리모트 측과 협상하기 위해, uucico는 표준 메시지 셋을 사용하는데, 이는 종종 high-level 프로토콜이라 지칭된다. 초기화 단계와 hang-up 단계에 이 메시지들은 문자열의 형태로 단순히 보내진다. 그러나, 실제 전송 단계에선 추가적인 low-level 프로토콜이 채용되는데, 이는 상위 레벨에 대부분 투명하다. 이것은, 이를테면 신뢰성이 떨어지는 라인을 사용할 경우에 에러 체크를 가능하게 만들어 준다.

Protocol Overview

UUCP가 시리얼 라인이나 TCP 또는 심지어 X.25와 같은 서로 다른 타입의 커넥션상에서 사용되므로, low-level 프로토콜의 지정이 필요하다. 게다가, UUCP의 몇몇 implementation은 거의 같은 일을 하는 서로 다른 프로토콜을 채용한다.

프로토콜은 두개의 범주로 나뉘는데, 그것은 스트리밍(streaming) 프로토콜과 패킷 지향(packet-oriented) 프로토콜이다. 전자의 프로토콜은 파일을 전체로 전송하며 가능하다면 그에대해 checksum을 계산한다. 이는 오버헤드가 거의 없으나, 에러가 발생하면 파일 전체를 재 전송해야하므로, 신뢰성 있는 커넥션을 필요로한다. 이러한 프로토콜은 TCP 커넥션 상에서 보통 사용되나, 전화라인에서 사용하기엔 적합치 않다. 요즘의 모뎀이 비록 에러 교정을 잘 해낸다고 하더라도, 완전한 것은 아니며, 컴퓨터와 모뎀 사이의 에러는 감지할 수 없다.

반면에, 패킷 프로토콜은 파일을 동응한 사이즈의 덩어리로 나눈다. 각 패킷은 개별적으로 송수신되고 checksum이 계산되며 acknowledgement가 보낸쪽으로 리턴된다. 이를 좀더 효율화 하기 위해서, 미해결의 acknowledgement의 수(window)를 제한할 수 있로록 하는 슬라이딩 윈도우(sliding window) 프로토콜이 고안되었다. 이는 전송시에 uucico가 대기해야하는 시간을 크게 줄였으나, 아직도 스트리밍 프로토콜에 비해 상대적으로 많은 오버헤드때문에, 패킷 프로토콜은 TCP상에서 사용하기엔 비 효율적이다.

데이터 패스(data path)의 폭도 역시나 어려움을 준다. 때때로, 시리얼 커넥션 상에서 8비트 캐릭터를 보내는 일은 불가능한데, 예를 들어 멍청한 터미널 서버를 거치는 경우, 8비트 셋의 캐릭터는 반드시 전송시에 quote되어야한다. 8비트 캐릭터를 7비트 커넥션 상에서 전송할 때, 최악의 경우에 대한 고려가 있어야 하며, 이는 비록 하드웨어에 의해 이루어지는 압축이 이를 보충하더라도, 전송되는 데이트 량이 배가 된다. 임의의 8비트 패릭터를 전송할 수 있는 라인을 보통 8 비트 클린하다고 한다. 이는 모든 TCP 커넥션에 해당되며 대부분의 모뎀도 그러하다.

다음의 프로토콜은 Taylor UUCP 1.04에서 사용가능한 것들이다.

g 이는 대부분의 통상적인 프로토콜이며 거의 모든 uucico가 이해할 수 있는 것이다. 이는 에러 체킹을 수반하므로 노이즈가 많은 전화선 링크에 아주 적합하다. g는 8비트 클린 커넥션을 필요로 하며, slide window 테크닉을 사용하는 패킷지향 프로토콜이다.
i 이는 동시에 보내고 받을 수 있는 양방향 패킷 프로토콜이다. 이는 완전 이중의 커넥션과 8비트 클린 데이터 패스를 요구한다. 현재 Taylor UUCP에서만 지원되는 프로토콜이다.
t 이는 TCP 커넥션 상에서, 혹은 정말로 에러 없는 커넥션에서 사용하기 위한 의도의 프로토콜이다. 이는 1024바이트의 패킷을 사용하며 8비트 클린 커넥션을 필요로한다.
e 기본적으로 t와 동일한 일을 한다. 주된 차이점은 e가 스트리밍 프로토콜이라는 점이다.
f 이는 신뢰성있는 X.25 커넥션에 사용하고자 하는 의도의 프로토콜이다. 그것은 스트리밍 프로토콜이며 데이터 패스가 7비트라고 생각한다. 8비트 캐릭터는 quote되는데, 이는 이 프로토콜의 효용성을 아주 떨어뜨린다.
G 이는 g 프로토콜의 System V Release 4 version이다. 몇가지 다른 UUCP버전에서도 이를 지원한다.
^ 이 프로토콜은 ZMODEM과 유사하다. 그것은 8비트의 케넥션을 요하나, XON이나 XOFF같은 몇가지 특정 캐릭터들을 quote시킨다.

12.6.2 Tuning the Transmission Protocol

모든 프로토콜에서 패킷사이즈, 타임아웃등을 조절할 수 있다. 보통 디폴트는 표준적인 상황하에서 잘 동작하도록 주어지나, 당신의 실정엔 적합하지 않을 수 있다. 예를 들어, g 프로토콜은 1에서 7까지의 윈도우 사이즈와 64에서 4096의 범위를 가지는 패킷사이즈를 사용한다. 만약 당신의 전화라인이 잡음이 많이 끼고 모든 패킷의 5퍼센트를 drop한다면, 패킷 사이즈를 줄이고 윈도우를 축소시켜야 한다. 반면, 성능 좋은 전화라인에서 128 바이트마다 ACK를 보내는 프로토콜의 오버헤드는 낭비적이므로, 패킷사이즈를 512 또는 1024로 늘이는 것이 좋다.

Taylor UUCP는 sys파일의 protocol-parameter 커맨드로 이러한 파라미터를 조절하여 당신의 요구에 적합하게하는 메카니즘을 제공한다. 예를 들어, pablo와 통신할 때 g 프로토콜의 패킷 사이즈를 512로 지정하기위해선 다음을 추가하면 된다.

     system         pablo
     ...
     protocol-parameter g  packet-size 512

조절가능한 파라미터와 그 이름은 프로토콜마다 천차면별이다. 완전한 리스트는 Taylor UUCP 소스내에 같이 들어있는 문서를 참조하기 바란다.

12.6.3 Selecting Specific Protocols

모든 uucico의 implementation이 각 프로토콜을 지원하진 않으므로, 초기 handshake 단계에서 양쪽 프로세스는 공통의 프로토콜에 상호 동의해야한다. 마스터 uucico는 Pprotlist를 보냄으로써 지원되는 리스트를 슬레이브에게 제공하고, 슬레이브는 이들 중 하나를 선택한다.

사용되는 포트(모뎀, TCP또는 다이렉트)의 타입에 기반하여, uucico는 디폴트 프로토콜 리스트를 작성할 것이다. 모뎀과 다이렉트 커넥션의 경우, 이 리스트는 보통 i, a, g, G, j로 구성된다. TCP 커넥션의 경우 이 리스트는 t, e, i, a, G, j, f이다. 당신은 system 엔트리나 port 엔트리에 protocols 커맨드를 지정해 줌으로써, 이 디폴트 리스트를 오버라이드 할 수 있다. 예를 들자면, 당신의 모뎀 포트에 대해 port 파일 엔트리를 다음과 같이 에디트할 수도 있다.

     port           serial1
     ...
     protocols      inG

이는, 이 포트를 통하여 들어오거나 나가는 커넥션이 i, g, G를 사용하길 요구한다. 만약 리모트 시스템이 이들 중 어느것도 지원하지 않는다면, 교신은 실패로 끝날 것이다.

12.7 Troubleshooting

이 섹션에선 당신의 UUCP 커넥션에 무엇이 잘못되었는지를 기술하고, 어디서 에러를 찾아낼 수 있는지 제안한다. 그러나 다음의 사항은 나의 머리속에서 편집된 것인만큼, 이보다 더 많은 문제들이 존재한다.

어떠한 경우에서도, -xall로 디버깅을 활성화하고 스풀 디렉토리 내의 Debug에 결과를 들여다 보라. 그것은 어디에 문제가 낫는지 빨리 인지할 수 있도록 도와 준다. 모뎀이 연결되지 않을 때 모뎀의 스피커를 켜는 것도 역시나 도움이 된다. Hayes 호환 모뎀에서는 dial파일내의 모뎀 chat에 "ATL1M1 OK"를 추가하여 이렇에 할 수 있다.

먼저 체크해야할 것은 언제나 모든 파일 퍼미션이 제대로 설정되었는지이다. uucico는 setuid 되어야하고, /usr/lib/uucp와 /var/spool/uucp, /var/spool/uucppublic내의 모든 파일은 uucp의 소유여야한다. 스풀 디렉토리내엔 히든파일(hidden file)도 존재하는데, 물론 이것 역시 uucp의 소유로 설정되어 있어야한다.

uucico가 계속 "Wrong time to call"이라고 말한다: 이는 sys내의 시스템 엔트리 내에, 리모트 시스템이 전화받을 시간대를 지정하는 time 커맨드를 주지 않았거나, 현재 전화가 금지된 시간을 주었음을 나타낸다. 만약 콜 스케쥴을 지정해 주지 않았다면, uucico는 그 시스템이 언제나 전화를 거부한다고 생각한다.

그 사이트가 이미 lock되었다고 uucico가 투덜거린다: 이것은 uucico가 /var/spool/uucp 내에서 리모트 시스템에 대한 lock파일을 찾았음을 의미한다. 그 lock 파일은 이전의 콜 도중 시스템이 다운되었거나, 프로세스가 kill된데 원인이 있다. 그러나, 다른 uucico 프로세스가 리모트 시스템에 다이얼하려 chat 스크립트를 사용하다가 멈춘 것일 수도 있다. 이러한 uucico 프로세스가 리모트 시스템과의 연결에 성공하지 못한다면, hangup 시그널로 죽이고, 남아있는 lock 파일도 제거해 주자.

리모트 사이트에 연결은 할 수 있으나 chat 스크립트는 실패한다: 리모트 사이트에서 수신하는 텍스트를 살펴보라. 만약 그것이 왜곡되어 있다면, 이는 속도관계의 문제이다. 그렇지 않다면, 그것이 당신의 chat 스크립트에서 기대하는 그것과 실제로 같은지 확인해 보라. chat 스크립트가 expect 문자열로 시작한다는 것을 기억하자. 만약 당신이 로그인 프롬프트를 수신했고 당신의 로그인 네임을 보냈으나 패스워드 프롬프트를 받지 못한다면, 로그인 네임을 보내기 전에 약간의 딜레이를 주거나, 글자 사이에 딜레이를 주라. 아마도 당신이 모뎀에 비해 너무 빠르기 때문일 것이다.

모뎀이 다이얼하지 않는다: 만약 당신의 모뎀이 uucico가 전화걸 때 DTR 라인이 떳는지 표시하지 않는다면, 올바른 디바이스를 uucico에게 주지 않았을 가능성이 높다. 만약 당신의 모뎀이 DTR 라인을 인식한다면, 터미널 프로그램으로 직접 적어넣어 체크하라. 이것이 제대로 동작한다면, 모뎀 chat의 시작부분에 \E를 주어 echoing을 켜도록하자. 이렇게 했을때, 모뎀 chat도중에 당신의 커맨드를 echo되지 않는다면, 라인스피드가 당신의 모뎀보다 너무 빠르거나 느린게 아닌지 체크하라. 그렇지 않고 echo를 볼 수 있다면, 당신이 모뎀 response를 비활성화 해 놓았거나 그것을 숫자로 지정해 주지 않았는가 확인하라. chat 스크립트 자체도 정확한지 확인하라. 백슬래쉬 하나를 보내기 위해선 2개를 적어줘야한다는 것을 잊지 말자.

모뎀이 다이얼을 시도하나, 외부로 나갈수는 없다: 전화번호에 딜레이를 집어넣자. 이는 특히 회사의 내부 전화망에서 다이얼 아웃할 때 유용하다. 유럽에서 보통 pulse 톤으로 다이얼하는 사람들은 touch 톤을 시도해보라. 몇몇 국가에선 우편 서비스에서 최근들어 그들의 넷을 업그레이드하고 있으므로, touch 톤이 때때로 도움이 되기도 한다.

로그 파일이말하길, 내가 극도로 높은 패킷 유실률을 갖고 있다고한다: 이는 속도 문제처럼 보인다. 아마도 모뎀과 컴퓨터간의 링크가 너무 늦거나(최고의 효율을 낼 수 있로록 접합시켰는지 기억해보라), 당신의 하드웨어가 제때에 인터럽트를 하지 못할만큼 느린것이 아닌가? 시리얼 포트에서 NSC 16550A 칩셋으로 38kbps는 상당히 잘 동작한다. 그러나 FIFO(16450칩처럼)없이는 9600bps가 한계이다. 시리얼 라인에서 하드웨어 handshake가 가능한지도 역시나 확인해야한다.

또다른 원인으론 포트상에서 하드웨어 핸드쉐이크가 가능하지 않은 것이 있다. Taylor UUCP 1.04에선 RTS/CTS 핸드쉐이크를 조절하는 어떠한 준비도 되어있지 않다. 당신은 rc.serial에 다음의 커맨드를 사용하여 따로 이것을 활성화해 주어야한다.

     $ stty crtscts < /dev/cua3

로그인 할 수는 있으나, 핸드쉐이크는 실패한다: 이것엔 여러가지 문제가 있을 수 있다. 로그파일의 내용이 당신에게 더 많은 것을 알려줄 것이다. 리모트 사이트가 제공하는 프로토콜(그것은 핸드쉐이크 중에 Pprotlist 스트링을 보낸다)엔 어떤 것이 있는지 살펴보자. 아마도 어떤 공통의 것을 지니고 있지 않을 것이다. (당신은 sys나 port에서 어떠한 프로토콜을 선택하고 있는가?)

만약 리모트 시스템이 RLCK를 보내면, 리모트 시스템에 당신에 대한 낡는 lock파일이 존재한다는 것이다. 그것이 다른 라인을 통해 당신이 이미 리모트 시스템에 연결하고 있어서가 아니라면, 제거해 달라고 요청하라.

리모트에서 RBADSEQ를 보내면, 다른 사이트가 당신에 대해 교신 카운터 체크를 하여, 그 수가 일치하지 않음을 뜻한다. 리모트에서 RLOGIN을 보낸다면 당신은 이 id로 로그인 할 수 없다.

12.8 Log Files

UUCP 슈트를 Taylor 스타일의 로깅(logging)을 사용하도록 컴파일할 때, 당신은 3개의 전역 로그파일만을 가지며, 이들 모두는 스풀 디렉토리 내에 있다. 메인 로그파일의 이름은 Log이며, 성립된 커넥션과 전송된 파일에 대한 모든 정보를 담고 있다. 다음은 일반적인 Log에서 발췌한 것이다. (페이지에 맞도록 약간 재구성하였다.)

     uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3)
     uucico pablo - (1994-05-28 17:15:39.25 539) Login successful
     uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful
                    (protocol 'g' packet size 1024 window 7)
     uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj
     uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai
     uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at
     uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as
     uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2
     uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1
     uucico pablo - (1994-05-28 17:16:02.05 539) Protocol 'g' packets: sent 15,
                     resent 0, received 32
     uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26 seconds)
     uucico pablo postmaster (1994-05-28 17:16:11.41 546) Excuting X.pabloX04ai
                     (rmail okir)
     uucico pablo postmaster (1994-05-28 17:16:13.30 546) Excuting X.pabloX04as
                     (rmail okir)
     uucico pablo postmaster (1994-05-28 17:16:13.51 546) Excuting X.pabloX04c1
                     (rmail okir)

다음으로 중요한 로그 파일은 Stats로, 파일 전송통계를 나열한다. 다음은 위의 전송에 해당하는 Stats의 일부이다.

     postmaster pablo (1994-05-28 17:15:44.78)
                       received 1714 bytes in 1.802 seconds (951 bytes/sec)
     postmaster pablo (1994-05-28 17:15:46.66)
                       received 57 bytes in 0.634 seconds (89 bytes/sec)
     postmaster pablo (1994-05-28 17:15:49.91)
                       received 1898 bytes in 1.599 seconds (1186 bytes/sec)
     postmaster pablo (1994-05-28 17:15:51.67)
                       received 65 bytes in 0.555 seconds (117 bytes/sec)
     postmaster pablo (1994-05-28 17:15:55.71)
                       received 3217 bytes in 2.254 seconds (1427 bytes/sec)
     postmaster pablo (1994-05-28 17:15:57.31)
                       received 65 bytes in 0.590 seconds (110 bytes/sec)

또 다시 말하지만, 위의 라인은 페이지에 맞도록 나누어진 것이다.

세번째 파일은 Debug이다. 여기엔 디버깅 정보가 적힌다. 당신이 디버깅을 사용한다면, 이 파일이 600모드로 되어 있는지 확인해야한다. 선택한 디버그 모드에 때라, 리모트 시스템에 연결하기 위해 당신이 사용하는 로그인 네임과 패스워드를 담고 있을 수도 있기 때문이다.

리눅스 배포판에 포함된 몇가지 UUCP 바이너리는 HDB 스타일의 로깅을 사용하도록 컴파일 되어 있다. HDB UUCP는 /var/spool/uucp/.Log아래에 저장된 로그 파일 묶음 전체를 사용한다. 이 디렉토리는 3개의 디렉토리, uucico와 uuxqt,uux를 더 포함하는데, 그것들은 각각 상응하는 캐맨드가 발생시킨 결과물을, 각 사이트마다 다른 파일로 정렬하여 로그를 남긴다. 그리하여 uucico가 pablo에 전화걸 때 생기는 출력물은 .Log/uucico/pablo로 가게되며, 뒤따르는 uuxqt는 .Log/uuxqt/pablo에 적힌다. 그러나 단지 여러파일에 적히는 것일뿐, 실제 적히는 메시지는 Taylor 로깅과 동일하다.

당신이 HDB 스타일 로깅을 하도록 컴파일된 UUCP에서 디버깅 출력물을 보도록 설정한다면, 그 출력물은 /var/spool/uucp아래의 .Admin디렉토리로 갈 것이다. 외부로 전화를 걸 때의 디버깅 정보는 .Admin/audit.local로, 누군가가 전화를 걸 때 uucico의 출력물은 .Admin/audit으로 갈 것이다.

Other Chapters

1. Introduction to Networking
2. Issues of TCP/IP Networking
3. Configuring the Networking Hardware
4. Setting up the Serial Hardware
5. Configuring TCP/IP Networking
6. Name Service and Resolver Configuration
7. Serial Line IP
8. The Point-to-Point Protocol
9. Various Network Applications
10. The Network Information System
11. The Network File System
12. Managing Taylor UUCP
13. Electronic Mail
14. Getting smail Up and Running
15. Sendmail+IDA
16. Netnews
17. C News
18. A Description of NNTP
19. Newsreader Configuration

Appendix

A. A Null Printer Cable for PLIP
B. Sample smail Configuration Files
C. The GNU General Public License