linux中的泰勒式UUCP

   電腦店訊   U U C P是二十世紀7 0年代後期，由AT & T公司貝爾實驗室的Mike Lesk設計出來，用於通過公用電話線路，提供一個簡單的撥號網絡。由於許多人都想在自己的家中，通過m o d e m收發電子郵件和U s e n e t新聞，所以U U C P至今仍然非常流行。盡管不同的硬件平台和操作系統上運行著大量不同的實施方案，但總的說來，都不會產生沖突。但是，若干年來，有的軟件越來越“標准”，已經沒有能夠稱為U U C P的U U C P了。自1 9 7 6年發布第一個版本以來， U U C P一直處於一個非常穩定的發展過程。目前， U U C P主要分為兩大類，其區別表現在硬件支持和它們的配置上。還有其他許多實施方案，大都與這兩類

大同小異。         其中一類就是所謂的“版本2 UUCP”，它起源於1 9 7 7年，由Mike Lesk、David A. Novitz和Greg Chesson合作編寫的第一版U U C P。盡管它相當老了，但仍然廣為使用。新近發布的版本2，使最近的U U C P更為好用。第二類是在1 9 8 3開發的，常被稱為B N U（基本連網程序）、HoneyDanBer UUCP或H D B。這個奇怪的名字源於其作者： P. H o n e y m a n、D.A. Novitz和B . E . R e d m a n。H D B被認為是消滅了版本2 UUCP之不足的功臣。例如，增加了新的傳輸協議，拆分了假脫機目錄，能讓你與之進行U U C P通信的每個站點上只有一個目錄。當前，軟件廠商在其產品中捆綁的U U C P實施是Taylor UUCP 1.04（該程序是Ian Ta y l o r於1 9 9 3年編寫並申請版本），它是本文所講的版本的基礎。以下將其統稱為泰勒式U U C P，其1 . 0 4版本是1 9 9 3年2月發布的。除了識別傳統的配置文件外，對泰勒式U U C P稍作編譯，也能夠識別新式（比如a . k . a .“Ta y l o r”）的配置文件。        本書編寫過程中，最新的1 . 0 5版本也發布了，很快將進入分銷渠道。這兩個版本的不同之處對你而言，沒什麼影響，因此，你大可利用本書中的信息，配置泰勒式UUCP 1.05。本文的目的不是徹底論述U U C P命令的命令行選項有哪些，其作用是什麼，而是向大家介紹如何設置一個正在運行的U U C P節點。第一小節簡要介紹U U C P是怎樣實施遠程命令執行和文件傳輸的。但是，我們將假設這個前題：大家對U U C P套件的用戶程序有所了解。它們是u u c p和u u x。有關說明可參考在線手冊。 除了公開供用戶訪問的程序、u u c p和u u x程序外， U U C P套件中還包含有大量的只用於管理的命令。這些命令用於監控節點間的U U C P通信，刪除舊的日志文件和編譯特性等。詳細情況未作討論，因為我們這裡的重點是U U C P。除此以外，這些命令已經編入文檔，非常容易理解。但是， U U C P套件中還有第三種類型，這類由真正的U U C P“工程兵”組成，它們叫作u u c i c o（c i c o表示copy-in copy-out）和u u x q t，後者執行從遠程系統發來的作業。
11.1 關於UUCP        對於那些在本文內找不到自己需要的資料的用戶來說，應該仔細閱讀軟件包自帶的文檔。它是一個t e x i n f o文件集，對利用泰勒式配置方案進行的設置進行了詳細說明。利用t e x和m a k e i n f o，可將t e x i n f o分別轉換為D V I和GNU info文件集。如果想采用B N U甚至版2配置文件，則可參考另一本好書《Managing UUCP和U s e n e t》。我覺得這本書講得非常透徹。關於L i n u x系統上可用的U U C P，其詳情可參考Guylhem Aznar（郵件地址g u y l h e m @ . o e i l . q c . c a）編寫的U U C P - H O W TO文檔，該文檔定期在c o m p . o s . l i n u x . a n -n u o n c e發布。另外，還有一個U U C P新聞組，名為c o m p . m a i l . u u c p。如果有和泰勒式U U C P相關的問題，最好提交到該新聞組，讓其中的專家為你解決疑難，而不是訪問c o m p . o s . l i n u x。
11.1.1 UUCP傳輸和遠程作業的執行        理解U U C P的關鍵在於搞清“作業”（j o b s）一詞的概念。用戶利用u u c p或u u x發起一次傳輸就叫作一個作業。一次作業由一個命令和一個文件集組成，這個命令將在遠程系統上執行，而文件集則將在不同站點間進行傳輸。U U C P一般不會立即調用遠程系統來執行作業(或你可利用k e r m i t執行)。相反地，它會臨時性地將作業說明保存起來。這就是所謂的“假脫機”（s p o o l i n g）。下面保存作業說明的目錄樹就被稱作假脫機目錄（ spool directory），一般位於/ v a r / s p o o l / u u c p內。我們的示例中，作業說明中包含與即將執行的遠程命令（ l p r）相關的信息、請求執行作業的用戶和兩個其他的項目。除了作業說明外， U U C P還必須保存輸入文件n e t g u i d e . p s。s p o o l文件的確切位置和命名可能會依據某些編譯時選項而發生變化。兼容於H D B的U U C P一般將s p o o l文件保存在名為/ v a r / s p o o l / u u c p / s i t e的目錄內，而“ s i t e”代表的是站點名。在針對泰勒式配置方案進行編譯時， U U C P將在站點專有的s p o o l目錄下，為不同類型的s p o o l文件創建子目錄。        U U C P定期撥入遠程系統。與遠程主機建立連接之後， U U C P將說明作業的文件和所有的輸入文件傳遞給它。進入遠程主機的作業不會立即執行，而是在連接中斷之後才進行。這是由u u x q t來完成的。u u x q t還會將目的地是另一個站點的作業進行轉發。為了將重要和次要作業區分開來， U U C P為各個作業制定了級別（ g r a d e）。從0到9的級別用字母來表示，即從A到Z。級別越高，越優先。郵件對應的級別一般是B或C，而新聞對應的則是N。級別越高的作業，其傳輸次序也優先。級別的分配是在調用u u c p或u u x時，利用- g標記來分配的。某些時候，還可禁止傳輸低於指定級別的作業。這就是所謂的對話期間的最高s p o o l級別，其默認設置是- z。注意：只有其級別等於或高於最大s p o o l級別的文件，才能得以傳輸。
11.1.2 uucico的內部運行         為了解u u c i c o需要知道某些情況的原因，先簡要談談它在事實上是如何與遠程系統建立連接的。當你從命令行執行uucico -s系統時，它首先必須有一條物理上的連接。根據連接類型，開始采取行動，比如，在使用電話線時，它必須先找到一個m o d e m。在T C P鏈接上，它必須調用g e t h o s t b y n a m e ( 3 )，將主機名轉換為網絡地址，再找出應該打開的端口，並將網絡地址綁定到相應的套接字上。在鏈接建立之後，必須傳遞一個身份驗證進程。這個進程一般由要求登錄名的遠程系統和一個密碼組成。這就是常說的“登錄對話”（login chat ）。身份驗證進程要麼由常用的g e t t y / l o g i n套件執行，要麼由u u c i c o自己在T C P套接字上執行。如果驗證成功，遠程主機就會發起u u c i c o。用於初始化鏈接的u u c i c o之本地備份常被稱為主管，遠程備份常稱為從屬。接下來是握手階段：現在，主管主機發送其主機名和一些標記。從屬便查看這個主機名是否能夠登錄，收發文件等等。標記說明了准備傳輸的s p o o l文件的最高級別。如果一切正常，就將產生對話計數或呼叫下個號碼檢查。有了這一特性，兩個站點便可維持成功的鏈接。如果文件的級別低於指定的級別，握手就會失敗。這個特性特別適合於對付網絡騙子。        最後，兩端的u u c i c o試圖與常用的傳輸協議達成一致。這個協議掌管數據傳輸、數據一致性檢查和出現錯誤時的重新傳送數據的方式。為什麼需要不同的協議呢？因為需要支持不同的連接類型。比如，由於電話線路擔心出錯，因此要求一個“安全”協議，而T C P傳輸又是天生的可靠，可以使用一個更為高效的協議，這類協議將摒棄特殊錯誤查找。握手結束之後，真正的文件傳輸階段開始了。連接雙方都打開選定的協議驅動程序。這些驅動程序將可能執行協議特定的初始化序列。        其一，主管將排隊等候遠程系統的所有文件發送出去，這些文件的s p o o l級別非常之高。發完之後，它便通知從屬發送完畢，而從屬此刻可能已經掛斷。現在，從屬要麼同意掛斷，要麼接管登錄對話。這時，角色發生了變化：此刻，遠程主機成了主管，本地主機則成為從屬。現在，新任的主管開始發送自己的文件。發送完畢之後，兩個u u c i c o的交換終止消息並關閉連接。我們不打算繼續深入討論。詳情參考U U C P源代碼或相關書籍。網上有一篇見解獨到的好文章，是David A.Novitz寫的，其中詳細介紹了U U C P協議。泰勒式U U C P常見問題集也對U U C P的實施進行了細致的探討。這個FA Q集定期出版於c o m p . m a i l . u u c p。
11.1.3 uucico命令行選項         本小節只說明幾個最重要的命令行選項，要想獲得一份關於所有選項的完整列表，請參考u n c i c o手冊。
11.2 UUCP配置文件        與較為簡單的文件傳輸程序相比，設計U U C P的目的是為了能夠自動處理所有的文件傳輸。一旦正確設置了U U C P，管理員就不必在每日不變的一些基本操作上花太多的時間。設置U U C P所需的信息保存在兩個配置文件內，這兩個文件駐留在/ u s r / l i b / u u c p目錄下。它們只用於撥號。注意本文中，大家還將看到若干個實例，其中引入的示例目前還不能用。雖然留有相 關的文本說明，但最好參考它們的LDP。
11.2.1 泰勒式UUCP簡介        說U U C P配置很難，並非言過其實。它的確涵括了許許多多的細節問題，即便配置文件的簡潔格式也無法使事情變得簡單（盡管與老式的H D B和版本2中的格式相比，泰勒式U U C P的格式更易於理解）。為了讓大家感覺一下這些文件是如何相互影響的，我們將介紹幾個最重要的文件，看看這些文件內的條目。但現在不打算一一細講；將在隨後的幾個小節內，重點介紹其中的一個。如果將自己的機器設置為U U C P，最好從某些示范文件著手，並逐步地改編它們。示范文件可從下面的示例中選出，也可從你自己喜歡的軟件產品中選出。        本小節提到的所有文件都包含在/ u s r / l i b / u u c p或子目錄t h e r e o f內。有的軟件產品中還有U U C P二進制文件（這些文件為H D B和泰勒式配置方案的啟用提供了支持），並分別為每個配置文件采用不同的子目錄。/ u s r / l i b / u u c p內，一般都有一個R E A D M E文件。要想U U C P運行無誤，這些文件必須只能歸u u c p用戶所用。其中一些文件中包含密碼和電話號碼，因此，它們應該有6 0 0模式許可。注意盡管多數U U C P命令都必須s e t u i d為u u c p，但你同樣必須確定u u c h k不是u u c p。否則，用戶將能顯示密碼，即使他們擁有模式600。
     核心的U U C P配置文件是/ u s r / l i b / u u c p / c o n f i g，用於設置常規參數。它們之中，最重要的是（迄今為止，也是唯一的）你的主機之U U C P名。下個重要配置文件是s y s文件。該文件中包含的信息和與你鏈接的站點之系統有關。其中包括站點名和關於鏈接本身的信息（比如使用m o d e m連接時采用的電話號碼）。p o r t命名准備使用的端口。t i m e指定何時撥號。c h a t說明登錄對話腳本—字串順序必須進行交換，以便允許u u c i c o登錄進入P a b l o。稍後再回頭討論對話腳本。p o r t命令不會命名/ d e v / c u a 1之類的設備專有文件名，而是命名端口文件內的條目。只要這些名字引用的是端口文件內的有效條目，你就可以按照自己的喜好，對它們進行分配。         端口文件中保存有與鏈接本身相關的信息，它說明了即將使用的設備專有文件名、支持的速率范圍和連接到該端口的撥號設備的類型。隨後的條目說明了/ d e v / c u a 1（a.k.a COM2），連接到這個設備的N a k Well modem的速率可高達38 400bps。選擇這個條目的名稱時，應該使它和s y s文件指定的端口名相符。關於撥號者本身的信息，則保存在另一個文件內，名為d i a l。對每類撥號者，它一般都包含撥叫遠程站點時執行命令的序列和具體的電話號碼。再次提醒大家注意，它也可作為一個對話腳本。對話中的第一行指定m o d e m對話，表示命令的執行序列（這些命令或發給m o d e m，或是從m o d e m發回），用於初始化m o d e m並令其撥叫指定的電話號碼。T序列將由u u c i c o用電話號碼來替換。        u u c i c o的第一步是在s y s文件內查找P a b l o。從P a b l o的s y s文件條目中，得知它應該采用s e r i a l 1端口來建立連接。端口文件告訴它這是一個m o d e m端口，而且已經綁定了一個N a k We l lm o d e m。接著，u u c i c o便開始搜索描述N a k Well modem的撥號條目，找到之後，便打開/ d e v / c u a 1，執行撥號者對話。也就是說，它發出一個“ AT Z”，並等待“O K”應答等。如果碰到T這個字串，它就將其替換為電話號碼1 2 3 - 4 5 6 7，這個號碼取自s y s文件。m o d e m返回C O N N E C T之後，表示已經建立連接， m o d e m對話已經完成。現在， u u c i c o返回s y s文件，並執行登錄對話。在我們的示例中，它將等待l o g i n :提示，然後，再發自己的用戶名（N e r u d a），等到出現p a s s w o r d :提示時，在發自己的密碼l o r c a。身份驗證完成之後，遠程端主機便假定發起自己的u u c i c o。然後，連接雙方開始進入握手階段（參見前一小節）。
11.2.2 UUCP需要知道些什麼        在開始編寫自己的U U C P配置文件之前，必須收集一些它需要知道的信息。首先，必須搞清楚你的m o d e m所綁定的串行設備是什麼。一般說來， D O S端口C O M 1到C O M 4對應的設備特有文件是/ d e v / c u a 1到/ d e v / c u a 3。許多軟件（比如S l a c k w a r e），都創建了一個/ d e v / m o d e m鏈接，鏈接到其相應的c u a *設備文件，配置k e r m i t、s e y o n等，從而能夠使用這些文件。這種情況下，也應該在你的U U C P配置文件內采用/ d e v / m o d e m鏈接。這樣做的原因是所有的撥號器都采用所謂的鎖文件來標識串行端口正在使用中。這些鎖文件名是一連串的L C K . .字串和設備文件名。比如L C K . . c u a 1。如果撥號器對同一個設備采用了不同的設備名，它們就不能對彼此的鎖文件進行識別。其結果是，在開始的那一刻，同時中斷彼此的會話。這在你利用c r o n t a b條目，安排自己的U U C P調用時，是不太可能的。        接下來，必須找出m o d e m的傳輸速率。必須將其值設為自己希望得到的最大有效傳輸速率。有效傳輸速率可以稍高於m o d e m規定的原始物理傳輸速率。比如，許多m o d e m收發數據的速率都是2 400bps。而利用V. 4 2 b i s之類的壓縮協議時，真正的傳輸速率可高達9 600bps。當然，如果希望自己的U U C P十項全能，肯定還需准備要撥叫的那個系統之電話號碼。而且，還需要一個有效的登錄I D和密碼。提示如果你正准備拿UUCP做試驗，最好能找到一個離你較近的歸檔站點。記下其登錄名和密碼—是可隨意下載的。多數情況下，它們是類似於u u c p / u u c p和n u u c p / u u c p的。另外，還必須知道如何才能真正地登錄到遠程系統。舉個例子來說，在登錄提示出現之前，有必要按B r e a k鍵嗎？登錄提示顯示的是“ l o g i n :”，還是“ u s e r :”？這一點對編寫對話腳本來說，是非常必要的，對話腳本是告訴u u c i c o如何登錄的“劇本”。如果不知道這一點，或平常所用的對話腳本失效了，就試著用k e r m i t或m i n i c o m之類的終端程序來撥叫遠程系統，並准確地記下你必須做的事。
11.2.3 站點的命名         由於有基於T C P / I P的連網，所以你的主機必須有一個用於U U C P連網的主機名。如果只想將U U C P用於站點間或本地網絡上的文件傳輸，這個名就不需要符合任何標准。唯一的限制是不得超過7個字符，而且不得與文件系統的主機名有沖突。但是，如果打算把U U C P用於郵件或新聞鏈接，就應該考慮使用UUCP Mapping Project（U U C P映射工程）注冊的名字。即使你參與了一個域，也有必要考慮為自己的站點選擇一個正式的U U C P名。        一般說來，人們愛在自己的完整資格域名中，選擇第一個組件來作為自己的U U C P名。比如，如果你的站點域名地址是s w i m . t w o b i r d s . c o m，那麼，你的U U C P主機名就是S w i m。許多U U C P站點都采用這一命名原則。當然，也可采用一個和自己的完整資格域名完全不相干的U U C P名。但是，務必保證不要在郵件地址中使用未取得資格的站點名，除非你已經將其注冊為自己的正式U U C P名（U U C P映射工程負責對全球的所有U U C P主機名進行注冊，並保證它們的唯一性。要注冊自己的U U C P主機名，可詢問負責處理你的郵件之站點維護人員，他們能夠幫助你）。因為，如果向尚未注冊的U U C P主機發郵件，最終會猶如泥牛入海。如果你使用的名稱與別的站點雷同，郵件也會被路由到那個站點，對其郵發主管來說，是件非常頭疼的事。默認情況下， U U C P套件采用的主機名是站點的U U C P名。這個名字通常是在/ e t c / r c . l o c a l腳本內設置的。如果你的U U C P名和你自己設置的主機名不同，就必須利用c o n f i g文件內的主機名選項，將你的U U C P名告知u u c i c o。這是下文討論的主題。
11.3 泰勒式配置文件        現在回過頭來看看配置文件。泰勒式配置文件一般由若干行組成，這些行中包含一些關鍵字-值對。#號代表一個批注， 表示這一行是備注。如果程序本身要采用#號，就可以在#前加一個斜槓。利用這些配置文件，可對相當多的選項進行調整。我們不打算對所有的參數進行深入講解，只講一些最重要的。有了它們，才可能配置基於m o d e m的U U C P鏈接。如果你想在 T C P / I P或直接串行線路上使用U U C P，則可參見其他小節，它們對一些必要的修正進行了說明。其全面而完整的參考資料包含在泰勒式U U C P源代碼附帶的Te x i n f o文檔內。當你認為自己已經完成U U C P系統的配置時，可利用u u c h k工具（位於/ u s r / l i b / u u c p），對自己的配置進行校驗。u u c h k讀取你的配置文件，再打印一份詳細報告，報告中對每個系統所用的配置值進行了詳細說明。
11.3.1 常規配置選項：config文件        一般情況下，除了U U C P主機名外，是不用這個文件的。默認情況下， U U C P采用的是h o s t n a m e命令設置的主機名，但最好顯式設置U U C P名。當然，還有許多參數是可以設置的，比如假脫機目錄名和匿名U U C P的訪問權限等。後者將在稍後進行討論。
11.3.2 如何將其他的系統告知UUCP：sys文件         s y s文件描述的是你的機器所了解的系統。條目是系統關鍵字引入的；後面幾行則是系統為站點指定的參數。一般說來，系統條目會對電話號碼和登錄對話之類的參數進行定義。第一個系統行之前的參數設置的是用於所有系統的默認值。通常情況下，應該在默認值這部分設置協議參數等等。下面，便為大家詳細介紹最典型的幾個字段。 1. 系統名        s y s t e m命令用於命名遠程系統。必須指定規范的遠程系統名，而不是你自行發明的別名，因為u u c i c o將在你登錄時，再次檢查遠程系統廣播的系統名（版本2 UUCP在調用時，不會廣播系統名，但新版本的U U C P實施通常都會這樣做，泰勒式U U C P也不例外）。每個系統名可能只出現一次。如果你想針對同一個系統，采用多個配置文件集（比如多個電話號碼，讓u u c i c o依次撥打），就可以指定備用配置文件。下面將具體介紹備用配置。
2. 電話號碼        如果遠程系統能夠通過電話線路抵達，p h o n e字段指定的就是m o d e m應該撥叫的電話號碼。該字段內可能包含若干個記號，這些記號的解釋由u u c i c o過程負責。等號=表示等待第二次撥號音調，“－”號則產生1秒鐘的暫停。例如，在撥打區號和電話號碼之間，如果沒有暫停的話，有些電話線路會中斷（不知道應該用哪個術語來表達這種情況，說簡單點，有點類似於 公司的內部電話，必須先撥打0或9才能打出去）。任何一個內含阿拉伯數字的字串都可用於隱藏站點比如區號之類的站點相關信息。利用d i a l c o d e文件，便可將此類字串翻譯成d i a l c o d e。有了翻譯文件，就可以在s y s文件內采用Bogoham 7732之類的電話號碼，它們更容易理解。
3. 端口和速率        端口和速率選項用於選定撥打遠程系統的設備和設置設備的最大速率（ t t y的波特率至少和最大傳輸速率一樣高）。系統條目即可以單獨采用一個選項，又可以兩者都用。在端口文件內查找合適的設備時，只能選定那些有匹配端口名和／或速率范圍的端口。一般情況下，用速率選項就夠了。如果端口文件內，只定義了一個串行設備，無論如何，u u c i c o始終都會選擇右邊的端口，你只須為它指定合適的速率。如果你的系統上備有多個m o d e m，通常也不願意命名一個特殊的端口，因為u u c i c o一旦發現有這麼多個設備，就會依次地嘗試每一個設備，直到找到沒有使用的設備為止。
4. 登錄對話         由上可知，登錄對話腳本是告訴u u c i c o如何登錄到遠程系統的腳本。它由一連串記號組成，用於指定本地u u c i c o進程發出和希望收到的字串。其目的在於令u u c i c o等待遠程主機向其發送登錄提示，隨後返回登錄名，等待遠程系統向其發送密碼提示，最後，再發送密碼。e x p e c t（希望收到）和s e n d（發送）字串是在備用文件中指定的。u u c i c o自動將回車字符（ r）添加到s e n d字串上。u u c i c o還考慮到了某些違例情況，比如，在發送提示之前，遠程主機的g e t t y需要進行重新 設置。所以，你可將一個子對話添加到一個e x p e c t字串上，偏移一個“－”。只有主要的e x p e c t字串失敗時（比如，發生超時），才執行這個子對話。利用這一特性的方法之一是：遠程站點沒有顯示登錄提示時，發送一個B R E A K。下面的例子給出了一個全面的對話腳本，如果你必須在登錄提示出現之前按回車的話，這個腳本應該是有效的。L i n u x系統中，要求U U C P不等待提示，即刻進行下一個s e n d字串的發送。

 

5. 備用

       有的時候，對於一個單獨的系統，我們希望能夠有多個配置。比如，可以通過不同的m o d e m線路，接通這一系統等。利用泰勒式U U C P，定義一個所謂的備用，就能立即實現這一想法。備用條目中保持主要系統條目中的所有設置，並只指定了默認系統條目中那些應該改寫或增添的值。備用從系統條目偏移含有關鍵字“備用”（a l t e r n a t e）的一行。在撥打P a b l o時，u u c i c o首先撥打1 2 3 - 4 5 6，如果失敗，再撥打備用條目中的號碼。備用條目中保持有主要系統條目中的所有設置，並只改寫了電話號碼。
6. 限制撥打次數        泰勒式U U C P提供了許多方法，可以用來限制撥打遠程系統的次數。為什麼要限制撥打次數呢？其原因不外乎遠程主機只在上班時間提供服務，或只是為了避免高頻率的撥打次數。        注意，只要為u u c i c o提供- S或- f選項，就能改寫撥打次數限制。默認情況下，泰勒式U U C P不允許隨時連接，所以你必須采用s y s文件內的時間規格。如果不在意撥打次數限制，可利用s y s文件內的A n y值，指定t i m e選項。要限制撥打次數，最簡單的方法是利用時間條目，這個條目後面跟一個字串，該字串由兩個子字段組成：日期和時間。日期可以是M o、Tu、We、T h、F r、S a、S u，或A n y、N e v e r 和代表工作日的W k。時間則由兩個2 4時的時鐘值組成。這些時間記號之間沒有空格符或制表符。任何一個日期和時間規格都必須用逗號列為一組。特殊的時間字串A n y和N e v e r分別表示：隨時撥打或從不撥打。t i m e命令采用了一個可選的第二個參數，該參數以分鐘計，說明幾分鐘後重試。在連接嘗試失敗之後， u u c i c o不允許在特定的時間間隔內，另行嘗試撥打遠程系統。默認情況下，u u c i c o采用的是一個exponential backoff方案，也就是說，時間間隔隨失敗次數的增多而增大。例如，你指定的重試時間間隔是5分鐘， u u c i c o將在上次嘗試失敗之後的5分鐘內，拒絕撥打遠程系統。        t i m e g r a d e命令允許你在作業安排中增加一個最大假脫機級別。這樣一來，只要一建立撥號連接，假脫機級別為C或更高的作業（郵件的隊列級別是B或C）就能得以傳輸，而新聞（其隊列級別一般是N）只能在夜間或周末得以傳輸。和t i m e命令一樣， t i m e g r a d e命令也采用了一個重試時間間隔（以分鐘計）作為其第三個可選參數。然而，與假脫機級別有關的說明則適合這種情況：首先， t i m e g r a d e命令只適用於你的系統發出的作業；遠程系統仍然一如既往地傳輸自己的作業。因此，你可利用c a l l - t i m e g r a d e選項，顯式請求它只發送假脫機級別高於指定級別的作業；但這樣不能保證它會接受一個請求 （如果遠程系統運行的是泰勒式U U C P，它就會接受這一請求）。類似地，遠程系統撥入本地時，不會對t i m e g r a d e字段進行檢查，所以所有排隊等候撥叫系統的作業都能得以發送。但是，遠程系統可以顯式請求你的u u c i c o限定發送特定級別的假脫機作業。
11.3.3 設備：端口文件        端口文件用於告訴u u c i c o哪些端口是可以用的。既可以是m o d e m端口，又可以是其他類型的端口（比如直接串行線路）或已獲支持的T C P套接字。與s y s文件一樣，端口文件由幾個獨立的條目組成。首先是關鍵字p o r t，然後是端口名。這個名可以供s y s文件內的端口語句使用。端口名不必是唯一的；如果幾個端口同名， u u c i c o將依次嘗試於各個端口建立連接，直到找出一個目前尚未使用的為止。p o r t命令後面應該緊跟t y p e語句，該語句用以說明端口類型。有效的類型有m o d e m、用於直接連接的d i r e c t和用於T C P套接字的t c p。如果不采用p o r t命令，端口類型就會采用默認的m o d e m類型。        本小節中，我們只介紹m o d e m端口，T C P端口和直接串行線路將留在稍後進行討論。對m o d e m和直接端口來說，都必須利用device directive（設備指令）指定用於撥出的設備。通常，這個設備是一個設備專有文件名，位於/dev目錄下，比方說/dev/cua1這個例子就是如此。注意有人偏愛ttyS*設備，這類設備只能用於撥入。如果是m o d e m設備，端口條目還能用於判斷連接到這個端口的m o d e m類型是什麼。不同類型的m o d e m必須采用不同的配置。即使它聲明自己采用的是賀氏標准也是如此。你必須告訴u u c i c o如何初始化m o d e m、如何令其撥打指定的電話號碼。泰勒式U U C P將所有撥號器的相關描述保存在一個名為d a i l的文件內。要想采用這些撥號器，必須利用d i a l e r命令，指定撥號器名稱。        根據自己撥打的系統，你可能想采用別的方式來利用m o d e m。例如，高速m o d e m試圖以14 400bps的速率連接老式的m o d e m時，後者不能識別它們，只是將線路斷掉，而不是協商以9 600bps的速率連接。如果你得知自己准備連接的站點采用的正是這類該進博物館的m o d e m時，就必須另行設置自己的m o d e m。所以，就需要在端口文件內增加一條端口條目，指定另外的撥號器。現在，可以為新端口指定一個新端口名，比如s e i a l 1 - s l o w，並采用s y s文件中d r o p系統條目內的端口指令。要想區分各個端口，最好看它們支持的速率。站點d r o p的系統條目將s e r i a l 1作為其端口名，但只請求以9 600bps的速率進行連接。然後， u u c i c o自動采用第二個端口條目。最後，利用第一個端口條目，撥打系統條目中有38 400bps速率的其他所有站點。
11.3.4 如何撥號：撥號文件        撥號（d i a l）文件說明的是不同的撥號器采用的方法。過去， U U C P提到的是撥號器，而不是m o d e m，因為早期，普遍采用一個（非常昂貴）自動撥號設備來充當m o d e m。今天，許多m o d e m都有內置的撥號支持，所以撥號器和m o d e m之間的界線才日益淡化。有的甚至干脆把撥號器叫作m o d e m。不管怎麼說，不同的撥號器和m o d e m都可能要求不同的配置。你可將各類撥號器和m o d e m的相關描述寫入d i a l文件內。d i a l文件內的條目以d i a l e r命令開頭，該命令會給出撥號器 的名稱。         除d i a l e r命令之外，另一個最重要的條目就是c h a t命令指定的modem chat（m o d e m對話）。它和登錄對話類似，由一連串字符組成，這些字符是由u u c i c o發給撥號器的字串和依次返回的應答字串組成。它常用於將m o d e m重新設置為已知狀態並進行撥號。uucico modem對話以空的e x p e c t字串開始。因此， u u c i c o立即發送第一條命令（ AT Z）。AT Z是H a y e s兼容m o d e m采用的命令，用於重新設置m o d e m。然後， u u c i c o等待m o d e m發回O K之後，再發送下一條命令，這條命令將關閉本地應答，如此等等。m o d e m再次發回O K之後，u u c i c o便發出撥號命令（AT D T）。這個字串中的避開序號T被系統條目文件內的電話號碼所代替。然後，u u c i c o就等待m o d e m返回C O N N E C T字串，後者標志著與遠程m o d e m的連接已經成功建立。         m o d e m不能連接到遠程系統，這是常有的事。比如，遠程系統正忙於和別人對話，線路正忙等。這時， m o d e m返回的錯誤消息，能夠指出不能連接的原因。m o d e m對話不能偵測此類消息；所以u u c i c o將繼續等待自己希望收到的字串，直到超時為止。因此， U U C P日志文件中將只能有這樣一行：“timed out in chat script”（對話腳本超時），而不能記錄不能連接的真正原因。但是，泰勒式U U C P允許你利用前面所講的c h a t - f a i l（對話失敗）命令，將錯誤消息告知u u c i c o。u u c i c o在執行m o d e m對話期間，一偵測到c h a t - f a i l字串，就會中止撥號，將錯誤消息記錄在U U C P日志文件內。        前面的示例中，最後一個命令要求U U C P在開始m o d e m對話之前，一直停留在D T R這一行。偵測到D T R行有變動時，許多m o d e m都可被配置為掛起，並進入命令模式。注意也可將有些modem配置為偵測到DTR發生變化時，自行重新設置。但是有的則不能這樣，有時還會自行掛斷。
11.3.5 TCP上的UUCP        利用U U C P，在T C P鏈接上傳輸數據，乍一聽，有些可笑。事實上，這並不是個壞主意，特別是在傳輸U s e n e t新聞組之類的大型數據時。在基於T C P的鏈接上，新聞通常是用N N T P協議來交換的，在N N T P協議中，文章的請求和發送是單獨進行的，無須壓縮和任何優化。盡管這對大型的站點來說，可以同時接收多個新聞傳輸，但對通過速度較慢的連接（比如I S D N） 接收新聞的小型站點來說，這種方法並不理想。這類站點通常想綜合利用T C P的傳輸質量和大批量發送新聞的好處，也就是說既能夠對新聞進行壓縮，又能夠降低傳輸開銷。傳輸批量新聞的標准作法是在T C P鏈接上使用U U C P。
11.3.6 直接連接的使用        假設你采用一條直接線路將自己的系統v s t o u t連接到t i n y。與m o d e m連接的情況極為相似，必須在s y s文件內寫入一條系統條目。p o r t命令標識串行端口t i n y已處於連接狀態。端口文件中，必須對直接連接所用的串行端口進行說明。這裡不需要撥號器條目，因為沒必要進行撥號。
11.4 UUCP的注意事項：調節權限 11.4.1 命令執行        U U C P的任務是把文件從一個系統復制到另一個系統，並請求在遠程主機上執行特定的命令。當然，作為管理員的你，肯定想對各系統的命令執行權進行控制—允許它們在你的系統上執行所有命令並不是件好事。默認情況下，泰勒式U U C P允許其他系統在你的機器上執行的命令只有兩條，那就是r m a i l和r n e w s。這兩個命令常用於在U U C P上交換電子郵件和U s e n e t新聞。u u x q t采用的默認搜索路徑是一個編譯時選項，但其中通常應該包含/ b i n、/ u s r / b i n和/ u s r / l o c a l / b i n。要針對特定的系統改變命令設置，可采用s y s文件內的命令關鍵字。類似地，也可以用c o m m a n d - p a t h（命令路徑）語句，改變搜索路徑。例如，可以讓系統P a b l o在執行r m a i l和r n e w s命令之外，還執行r s m t p命令。 11.4.2 文件傳輸          泰勒式U U C P還允許更為詳細地優化文件傳輸。甚至還可以取消將文件傳輸到特定系統或禁止從特定的系統傳輸文件。只須把請求設置為N o，遠程系統就不能向你的系統上傳或下載文件。類似地，你也可將傳輸設置為N o，禁止你的用戶向特定的系統上傳或下載文件。默認情況下，本地和遠程系統上的用戶都可上傳和下載文件。另外，可以配置准備復制文件的目錄。通常情況下，作為系統管理員的你，多半打算限制遠程系統用戶訪問你的目錄結構，但仍允許你自己的用戶發送其根目錄中的文件。此時，遠程系統用戶將只能接收公用U U C P目錄（/ v a r / s p o o l / u u c p p u b l i c）中的文件。這個目錄中常放置一些公用文件，與因特網上的F T P服務器非常類似。這個目錄常用“ ~”符號來表示。為此，泰勒式U U C P為收發文件提供了四個用於配置目錄的不同命令。它們是： l o c a l - s e n d（指定一份目錄清單，用戶要求U U C P發送這一系列目錄中的文件）、l o c a l -r e c e i v e（給出一份目錄清單，用戶要求U U C P將收到的文件放入這些目錄）、r e m o t e - s e n d和r e m o t e - r e c e i v e，對遠程系統的收發請求進行類似的處理。 l o c a l - s e n d命令允許你的用戶將/ h o m e目錄下和公用U U C P目錄中的所有文件發給P a b l o。l o c a l - r e c e i v e命令允許他們接收發向人人可寫的目錄或/ h o m e目錄下的人人可寫文件，這些人人可寫的目錄在u u c p p u b l i c 的r e c e e i v e 目錄中。r e m o t e - s e n d 指令允許P a b l o 請求/ v a r / s p o o l / u u c p p u b l i c內的文件，但i n c o m i n g和r e c e i v e目錄下的文件除外。u u c i c o是怎樣得知這一點的呢？原來目錄名前面有一個感歎號！最後一行允許P a b l o將任何文件上傳到i n c o m i n g目錄。        利用U U C P傳輸文件時，最大的問題是它只接收那些發到人人可寫的目錄中的文件。這將導致有的用戶為其他用戶設計一些圈套，或捉弄他們。但是，這個問題是無法避免的，除非你不用U U C P文件傳輸。
11.4.3 文件轉發        U U C P提供了一種機制，可令其他系統在你這一端執行文件傳輸。例如，允許你使s e c i為自己取得u c h i l e上的文件，並將它發送到自己的系統中。這種通過多個系統的傳輸機制就叫作“轉發”。上面的例子中，使用轉發機制的原因可能是s e c i能夠通過U U C P訪問u c h i l e，你的主機卻不能。但是，如果你的主機也運行U U C P系統，可能想將轉發服務限定在自己信得過的少數幾台主機上，以免自己為了下載最新的X 11 R 6源代碼不得不支付巨額的電話賬單。默認情況下，泰勒式U U C P完全不允許轉發。要針對特定的系統啟用轉發機制，可以采用f o r w a r d命令。這個命令指定一系列站點，系統要求你將轉發作業交給這些站點去完成。u c h i l e的f o r w a r d - t o條目是非常必要的，因為它返回的任何一個文件事實上都會傳遞到P a b l o。如果沒有這個條目， U U C P就會將這些文件丟棄。這個條目采用的是f o r w a r d命令的變體，允許u c h i l e通過s e c i，只把文件發給P a b l o；不得發向別的系統。如果想把文件轉發到所有的系統，可采用一個特殊的關鍵字A N Y（必須采用大寫）。
11.5 如何設置撥入        如果你想將自己的站點設置為撥入，必須允許用戶登錄到你的串行端口，並自定義一些系統文件，提供U U C P賬號。這就是我們這一小節的主題。
11.5.1 設置getty         如果打算將串行線路用作撥入端口，就必須在這個端口上啟用一個g e t t y進程。但是，有些g e t t y實施的確不適合撥入，因為人們通常想采用同一個串行端口進行撥入和撥出。因此，必須保證你使用的g e t t y進程能夠和其他程序（比如u u c i c o和m i n i c o m）共享同一條線路。具有此功能的一個程序是g e t t y p s包內的u u g e t t y。許多軟件中都有這個程序，在/ s b i n目錄下，可找到它。我所知道的另一個程序是m g e t t y，它是Gert Doering編寫的，同樣具有這一功能。可從s u n s i t e . u n c . e d u獲得其最新版本。        至於u u g e t t y和m g e t t y在控制登錄方面的不同，不在本書討論之列。有興趣的讀者，可參考Greg Hankins編寫得《Serial HOWTO》，以及g e t t y p s和m g e t t y自帶的文檔。
11.5.2 提供UUCP賬號        接下來，必須設置的是用戶賬號，有了賬號，遠程站點才能登錄到你的系統，建立U U C P連接。一般說來，要為每個撥入系統提供一個獨立的登錄名。在為P a b l o系統設置賬號時，可將U p a b l o作為它的用戶名。對於通過串行端口撥入的系統，通常情況下，你都必須將其賬號添加到系統密碼文件/ e t c / p a s s w d中。最好把所有的U U C P登錄信息統統歸為一個特殊的組，比如u u g u e s t。系統賬號的根目錄應該設為公用假脫機目錄/ v a r / s p o o l / u u c p p u b l i c；其登錄外殼腳本必須是u u c i c o。如果系統中已經安裝了影子密碼套件，就可以用u s e r a d d命令來設置賬號： # useraddr -d /var/spool/uucppublic -G uuguest -s /usr/lib/uucp/uucic 如果沒有安裝影子密碼套件，則需要手工編輯/ e t c / p a s s w d。即增加下面這一行，其中5 0 0 0和1 5 0是數字化的u i d和g i d，分別分配給用戶U p a b l o和組u u g u e s t。Upablo;x:5000:150:UUCP Account:/var/spool/uucppublic:/usr/lib/uucp/u 安裝賬號之後，必須激活它。也就是說利用p a s s w d命令，將其設置為密碼。針對通過T C P連接到你的站點上的U U C P系統，如果要為它們提供服務，必須設置i n e t d，令其處理進入u u c p端口的連接。在/ e t c / i n e t d . c o n f內增加下面這一行即可： uucp stream tcp nowait root /usr/sbin/tcpd /usr/lib/uucp/uuc 注意通常情況下，tcpd有700模式，所以你必須以root用戶的身份來調用它，這一點和uucp是不同的。 - 1選項令u u c i c o執行其本身的登錄身份驗證。u u c i c o將像標准的登錄程序一樣，提示登錄名和密碼，但依據是自己的私用密碼數據庫，而不是/ e t c / p a s s w d。這個私用密碼數據庫文件名為/ u s r / l i b / u u c p / p a s s w d，其中包含成對的登錄名和密碼，比如： Upablo IslaNegra Ulorca co’r d o b a 當然，這個文件的擁有者必須是u u c p，其保護模式為6 0 0。如果你認為這個數據庫不錯的話，還可將其用於普通的串行登錄。首先，你需要泰勒式UUCP 1.05，因為它允許g e t t y利用- u選項，將撥號用戶的登錄名傳遞給u u c i c o（1 . 0 4版本中也有- u選項，但它只是一個n o - o p）。然後，必須讓你正在使用的g e t t y，調用u u c i c o，而不是常用的/ b i n / l o g i n。有了g e t t y p s，就可以通過在配置文件內設置L O G I N選項來達到這一目的。但是，與此同時，也取消了交互式登錄對話。另一方面， m g e t t y有一個討人喜歡的特性，允許你根據用戶提供的登錄名，調用不同的登錄命令。比如，你可以要求m g e t t y針對特定的所有用戶（他們提供的登錄名統統以大寫的U開頭）使用u u c i c o，而個別用戶則采用標准的登錄命令。要保護自己的U U C P用戶，防止惡意呼叫者指定一個假系統名，中途攔截那些用戶的所有郵件，你應該在s y s文件內的每一條系統條目中，增加c a l l e d - l o g i n命令。
11.5.3 預防措施         關於U U C P，最大的問題之一是呼叫系統可以采用假名；它在登錄之後，向被呼叫系統聲明自己的名字。因此，攻擊者可能登錄到他／她自己的U U C P賬號，假裝某某人，中途截取其他站點的郵件。如果你提供通過匿名U U C P的登錄，這個問題就嚴重了，因為，這樣的話，登錄密碼幾乎是公開的。除非你知道自己信得過呼叫自己的那些站點，不然，你必須采取適當的措施，來防范那些欺騙者。具體的做法是在s y s中指定一個c a l l e d - l o g i n，要求每個系統都使用一個特定的登錄名。這樣做的結果就是，一旦某個系統登錄進入，並偽稱自己是P a b l o，那麼u n c i c o就會查實它是否曾以U p a b l o的身份登錄過。假如沒有，那麼呼叫的系統就會被拒絕，並取消此次連接。大家應養成為增加到s y s文件的每個系統條目，增加一個c a l l e d - l o g i n命令的習慣—無論它們是否曾經呼叫過你的站點。對那些從未呼叫過你的站點，或許也應將c a l l e d - l o g i n設為某些明顯是偽造的用戶名，比如n e v e r l o g s i n等等。
11.5.4 呼叫序列號檢查         要想防范網絡騙子，有效地探測那些虛假的登錄，另一個辦法是利用“呼叫序列號檢查”。利用呼叫序列號檢查，可防范非法闖入者找出我們登錄進入U U C P系統時使用的密碼。在使用呼叫序列號檢查的情況下，雙方的機器都會追蹤並維護著迄今為止建立過的連接數量。每建立一次連接，這個序列號都會遞增1。登錄進入後，呼叫者需發出它的呼叫序列號。同時，被呼叫者需要將其與自己的號碼核對。假如兩者不同，連接請求便會被拒絕。因此，假如初始的編號是隨機選定的，那麼攻擊者很難猜出正確的呼叫序列號是多少。除此以外，呼叫序列號還能做更多的事情：即使某些“異常聰明”的人能偵測出你的呼叫序列號，同時找到你使用的密碼，我們也能及時地發現這一情況！一旦攻擊者調用了你的UUCP feed，並偷走你的郵件，那麼f e e d s調用序列號就會增1。我們下一次調用自己的f e e d，並試圖登錄時，遠程的u u c i c o就會拒絕登錄，因為數字（編號）已不再相符了！假如啟用了呼叫序列檢查功能，便應定期檢查自己的日志文件，找出那些可能是由於外來攻擊而造成的錯誤消息。假如你的系統拒絕由呼叫系統提供的一個序列號， u u c i c o就會在日志文件中記錄一條錯誤消息，類似於“ Out of sequence call rejected”（序列調用被拒絕）。假如由於序列號不同步，而造成f e e d拒絕你的系統登錄，它就會在日志文件中寫入一條錯誤消息，注明“Handshake failed(RBADSEQ)”（握手失敗）。        接下來，我們必須實際地創建文件，文件中包括序列號本身。Taylor UUCP將序列號保存在一個名為. S e q u e n c e的文件中。該文件放在遠程站點的s p o o l目錄下。注意該文件必須由u u c p所有，而且必須采用模式6 0 0（亦即只能由u u c p讀寫）。最好用一個任意的值對這個文件進行初始化。否則的話，攻擊者就有可能輕松地猜出序列號，並用小於它的所有值進行嘗試（比如小於6 0）。當然，遠程站點也必須允許呼叫序列檢查。而且在最開始的時候，采用和我們指定的完全一樣的序列號。
11.5.5 匿名UUCP        如果要為系統提供匿名U U C P訪問權限，首先必須設置一個特殊的賬號（原因如前所述）。一種常見的做法是將它的登錄名和密碼都設為u u c p。除此以外，必須針對那些未知的系統，設定幾個安全防護選項。舉個例子來說，或許應禁止它們在我們的系統上執行任何命令。但是，我們不能在s y s文件條目中設置這些參數。這是由於s y s t e m命令要求用到系統的名字，但這個名字是我們所沒有的。Taylor UUCP解決這個問題的辦法是使用u n k n o w n命令。可在c o n f i g文件中使用該命令，指定那些通常可在一個系統條目中出現的任何命令。        這樣一來，我們就可以限制未知的系統從p u b目錄中下載任何文件，並能禁止它們將文件上載到/ v a r / s p o o l / u u c p p u b l i c目錄下的i n c o m i n g目錄中。下一行可令u u c i c o忽略來自遠程系統的、從而打開本地調試功能的任何請求。最後兩行則允許未知的系統執行r m a i l；但是，指定的命令路徑將令u u c i c o只在一個名為a n o n - b i n的私用目錄內查找r m a i l命令。這樣一來，你就可以提供某一特殊的r m a i l命令，將所有郵件轉發到超級用戶那裡進行檢查。這樣便允許匿名用戶抵達系統維護人員那裡，與此同時，還防止他們將郵件投入其他站點。要啟用匿名U U C P，必須在c o n f i g文件內至少指定一條未知語句。否則， u u c i c o就會拒絕任何一個未知系統。
11.6 UUCP低級協議        為了與遠程終端協商會話控制和文件傳輸， u u c i c o采用了一個標准化的消息集。這就是通常所說的“高級協議”。在初始化階段和掛斷階段，這些消息被作為一系列字串得以傳輸。但是，在真正的傳輸階段，采用的就是低級協議，這些低級協議對高級協議來說，大部分是透明的。這樣很方便進行錯誤檢查，特別適用於使用不太可靠的傳輸線路的情況。  11.6.1 協議概述          由於U U C P使用在不同類型的連接上，比如串行線路和T C P，甚至於X . 2 5，所以需要采用某些特殊的低級協議。另外，幾個U U C P實施方案已介紹了不同的協議。協議大致可分為兩類：流式傳輸協議和面向包的傳輸協議。近來的協議通過計算校驗和的方式，將一個文件作為一個整體進行傳輸。這幾乎沒有任何開銷，但要求有一條非常可靠的連接，因為任何一個錯誤都可能導致整個文件被重新傳輸。這些協議常用於T C P連接，但不適於電話線連接。盡管如今的m o d e m的確能夠及時糾錯，但仍然不夠理想，不能對你的計算機和m o d e m之間存在的錯誤進行偵測。        另一方面，面向包的傳輸協議則是將文件分為若干個相同大小的數據包。每個包單獨進行收發，單獨計算校驗和，並向發送方返回收到確認。為了使這類協議更為有效，人們還發明了滑動窗口協議，極大地減少了u u c i c o在文件傳輸過程中，必須等候的時間。與流式傳輸協議相比，包傳輸協議的開銷較大，所以它不太適合於T C P連接。數據路徑的寬度也有所不同。有時，根本不可能通過串行連接發送8位字符。比如，如果連接通過一個反應遲鈍的終端服務器，就會出現這種情況。此時，傳輸過程中，帶有8位字符集的字符必須用引號表示出來。在通過7位連接傳輸8位字符時，這種情況被視為是最糟糕的；因為它增加了一倍的數據傳輸量，盡管硬件可以對這些數據進行壓縮。可傳輸任意8位字符的線路叫作8-bit clean。所有T C P連接和大多數m o d e m連接都屬於這種情況。
11.6.2 傳輸協議的調節        所有協議都允許對數據包的大小、超時等進行調整。通常情況下，默認設置能夠保證數據包得以正常傳輸，但對具體情況而言，可能不是最好的選擇。比如， g協議采用的窗口大小是1到7之間，包的大小則是從6 4到4 096之間的2的乘冪個字節（包含在開發軟件中的多數二進制都默認采用窗口大小在7到1 2 8字節之間的包）。如果你使用的電話線路噪音很大以至於丟包率高達5 %，那你就應該減少包的大小，縮小窗口的大小。另一方面，如果電話線路較好，每個1 2 8字節的包都發送一個A C K（收到確認），又太浪費開銷了，所以可以將包的大小增大至5 1 2，甚至1 024 個字節。泰勒式U U C P提供了一種機制，可滿足你的不同需求，即利用s y s文件內的p r o t o c o l -p a r a m e t e r命令，對傳輸參數進行調節。不同協議的可調節參數和參數名是不相同的。要想得到一份相關的完整列表，請參考泰勒式U U C P源代碼中包含的文檔信息。
11.6.3 如何選定特殊協議         並不是每個u u c i c o實施方案都能分辨和識別出每個協議，所以在起初的握手階段，兩方的進程都必須同意采用一個常見的協議。主管u u c i c o向其從屬u u c i c o發送P r o t l i s t，為其提供一份已獲支持的協議列表，從屬再從其中挑選一個協議。根據使用端口的類型（ m o d e m、T C P或直接連接），u u c i c o將組建一個默認的協議列表。對m o d e m和直接連接來說，這份列表通常包含i、a、g、G和j。對T C P連接來說，則包含t、e、i、a、g、G、j和f。你也可利用p r o t o c o l s命令，改寫默認的協議列表，該協議命令可在系統條目和端口條目中指定。協議列表要求所以輸進或輸出的連接都要通過這個端口，采用i、g或G協議。如果遠程終端不支持這些協議，連接對話就會失敗。
11.7 故障排除         本小節將對U U C P連接可能出現的故障進行描述，並建議從哪裡著手查錯。但是，這方面的問題太多了，無法一一列舉，本文將著眼於一些比較常見的重要問題。任何情況下，利用- x a l l啟用調試，都可在假脫機目錄中的D e b u g內查看調試輸出。它將有助於你快速識別問題所在。同時，我還發現在m o d e m沒有連接時，它還可幫助我打開m o d e m。對采用賀氏標准的m o d e m 來說，具體作法是在撥號文件內的m o d e m 對話內，增加AT L 1 M 1 O K。 第一步通常是檢查所有的文件訪問許可是否設置正確。u u c i c o應該被s e t u i d為u u c p，而/ u s r / l i b / u u c p、/ v a r / s p o o l / u u c p和v a r / s p o o l / u u c p p u b l i c內的所有文件都應該屬u u c p擁有。另外，假脫機目錄內還有一些隱藏文件（也就是說，其文件名以“ .”開頭的文件；此類文件一般不能通過l s命令顯示出來），同樣也必須歸u u c p所有。uucico總是說“Wrong time to call”（呼叫時間有誤）：通常意味著s y s文件內的系統條目中，沒有指定t i m e命令，該命令詳細規定了呼叫遠程系統的時間，或目前禁止呼叫你指定的系統。如果不指定呼叫時間表， u u c i c o就會假定從不呼叫該系統。uucico總是抱怨站點被鎖：這通常意味著u u c i c o偵測到遠程系統的/ v a r / s p o o l / u u c p內有一個鎖文件。該鎖文件可能源於上一次呼叫的已崩潰或已被殺死的系統。但是，更可能存在另一個u u c i c o進程，該進程准備呼叫遠程系統，但又凝在對話腳本中。如果這個u u c i c o進程未能成功連接到遠程系統，就應該用掛斷信號將其殺死，並刪除所有的鎖文件。我能夠連接到遠程站點，但對話腳本卻不能：查看你從遠程站點收到的文本。如果它含混不清，可能就是速度方面的問題。否則，就確定它真的與你的話腳本所希望的行為保持一致。記住，對話腳本的開頭是一個e x p e c t字串。在你收到登錄提示時，就應該發送自己的用戶名，但絕不可能在發送密碼之前得到密碼提示，插入延時。可能是因為你的m o d e m太慢了的緣故。         我的modem不能撥號：u u c i c o在撥出時，如果你的m o d e m沒有指明D T R線路已被激活，可能是因為你沒有為u u c i c o指定一個恰當的設備。如果你的m o d e m識別出了D T R，就會利用你可以寫入的終端程序進行驗證。如果這樣做行得通，就在m o d e m對話開始之即，利用E打開應答。如果在m o d e m對話期間，它沒有對你的命令作出應答，就查看自己的m o d e m，線路速率是否設置過高或過低。如果有了應答，就看你是已經取消m o d e m響應，還是將它設置為數字代碼。最後再驗證對話腳本本身是否正確。記住，你必須寫入兩個後斜槓，並將其中之一發給m o d e m。我的modem在撥號時，總不能成功：在電話號碼中插入延時。這樣做是非常有用的，特別是通過公司內部電話網撥出時。        日志文件說我的包丟失率非常之高：這看來是速度問題。計算機和m o d e m之間的連接是不是太慢（記住將其速率調整為最高）？或你的硬件速度太慢，以至於不能及時提供服務？如果你的串行端口采用的是N S C - 1 6 5 5 0 A芯片，3 8 K b p s這個速率是比較理想的；但是，如果沒有F I F O（比如1 6 4 5 0芯片），9 600bps就是極限了。另外，你還應該保證串行線路上已經啟用硬件握手。另一個可能存在的問題是端口上未啟用硬件握手。泰勒式UUCP 1.04沒有打開硬件握手這一規定。我能夠登錄，但不能握手：產生此類故障的原因很多。日志文件中的輸出應該能夠給出一大堆原因。看看遠程站點提供的協議是什麼（在握手期間，它發送了一個P p r o t l i s t字串）。但也許日志文件內什麼東西也沒有（如果你沒有在s y s或端口文件內選定協議的話）。如果遠程系統發回R L C K，說明遠程系統上有一個很早以前的鎖文件。如果因為你已經通過另外的線路連接到遠程系統它沒有與你握手的話，就可要求將它刪除。如果它發回R B A D S E Q，另一個站點就會為你啟用對話計數檢查，但數字不符。如果它發回R L O G I N，就說明你不能通過這個I D進行登錄。
11.8 日志文件        在編輯U U C P套件，使其能夠采用泰勒式登錄時，只有三個日志文件，這三個日志文件都駐留在假脫機目錄內。主要的日志文件名為L o g，與已建立連接和已傳輸文件相關的所有信息統統包含在這個文件內。下一個比較重要的日志文件是S t a t s，它列出了文件傳輸特性。第三個日志文件便是D e b u g。該文件內主要保存一些調試信息。使用調試時，應該保證這個文件的保護模式是6 0 0。根據你所選定的調試模式，該文件中可能包含用於連接遠程系統的登錄和密碼信息。已發布的L i n u x產品中，有的U U C P二進制文件已被編輯為采用H D B式記錄。HDB UUCP采用了大量的日志文件，這些文件保存在/ v a r / s p o o l / u u c p / . L o g目錄下。這個目錄中包含另外三個子目錄，名為u u c i c o、u u x q t和u u x。這三個子目錄中包含每條相應命令生成的記錄輸出，而且這些輸出被保存在各個站點的不同文件內。因此，在撥叫p a b l o站點時，u u c i c o的輸出將記入. L o g / u u c i c o / p a b l o文件，而後來u u x q t的運行結果將被寫入. L o g . u u x q t / p a b l o。但是，寫入不同日志文件的各行輸出和泰勒式記錄的一樣。在你啟用H D B式記錄的調試輸出時，它將被寫入/ v a r / s p o o l / u u c p目錄下的. A d m i n目錄。在 撥出期間，調試信息也會被發送到. A d m i n / a u d i t . l o c a l中，在有人撥入時， u u c i c o的輸出結果將被記入. A d m i n / a u d i t。