◇ 曾桑談如何架設 News Server (修正版)


### 著 作 權 聲 明 ### * 作者: 曾瑞源 * * yuan@UUserv.Net.tw * * * * 任何個人都可未經授權自行列印閱讀, 這裡「個人」指任何人, * * 「自行列印」指的是非刪改作者原作情況下, 自行由電腦印表機 * * 列印。本著作權規範不限制您列印數量, 但凡商業性出版使用、 * * 轉排版印刷都不被允許。 * * * * 關於本著作物(電子書)的轉發行規定, 您被鼓勵將之擺放在任何 * * Internet FTP檔案庫上 Gopher/WWW站、或者任何聯盟的PC BBS * * 站臺, 作者歡迎並感激您願意如此做, 因為這樣做受益的朋友必 * * 然會更多。最後, 本版權聲明是本著作的一部份, 任何將本聲明 * * 與本著作分離的動作已經侵權並違法。其它未定事宜, 或您認為 * * 本版權聲明有不合時宜之處, 請聯絡作者。我再次感謝您讀我, * * 再見。 * * * Netnews Server (一) INN 曾瑞源 Usenet News 入門介紹 筆者發覺, 事實上已經有很多產業界及商業界的朋友知道Internet連 線可以對公司帶來很大的好處。 我希望讀者朋友能夠進一步知道, Usenet 就是Internet最有用的應用之一, Usenet可以為您或您公司帶來最珍貴的 東西 -- 資訊(Information) 以及免費的全球性交流及顧問管道。 假若貴公司或單位已經克服的技術上的困難連上Internet (不論是 UUCP、 PPP、 SLIP或Router/DSU), 我建議首先引入兩個Internet應用。 第一, 建立電子信件服務系統 (筆者以後專欄中會有介紹), 如此整個公 司的同仁都可以享有全球電子信件服務。 第二, 建立Netnews服務系統, 筆者看來, Netnews 系統很可能是您透過Internet受惠最大的應用! 本期 就以Netnews為介紹對象。 有關Usenet應用面的討論, 筆者在去年(1993) 二月到四月分三期在 本雜誌已經有很詳細介紹, 除此之外, 在筆者「新版Internet實務手冊」 (第三波) 也加上有應用面以及 Tin 界面軟體的介紹。 讀者若不了解 Usenet究竟能為您公司或個人帶來什麼好處, 可以去圖書館找那三期雜 誌 (該三期專欄的電子版可以用FTP在NCTUCCCA.edu.tw:/Chinese/YuanInfo /UNIXWORLD目錄下找到) 或者這本於1994七月底剛出版的新書。 以下所 要介紹的, 被定位在技術面或者系統管理面為主, 我想往下系列介紹對大 公司裡的MIS部門、 任何單位的電腦應用決策者、 以及所有對Internet 應用技術有興趣的個人應該會有幫助。 □ Usenet是什麼 Usenet是一種網路信息交換系統, 它跨越存在於各種不同的網路, 各 自位於不同地域、不同網路的電腦系統藉由截然不同的方法來交換信息。 大部分的Netnews是討論性的, 這讓全球相同癖好、 相同所學或同業交換 經驗。 Netnews另一部份東西則純是訊息性的, 這類的東西屬於單向流通, 供應這資訊的有些是商業服務, 有些不是, 這類訊息從期貨股票訊息到各 地方新聞都有, 以上主要是指全球性的Netnews而言。 至於以目前可得的 臺灣地方資訊來說, 我們可以在Netnews上讀到中國時報即時新聞、 氣象 、 各地藝術節目等等, 另外各種電腦及非電腦之專業技術性討論在臺灣 也已經非常熱絡。 Usenet 只是一種電腦網路應用, Usenet本身不是一個網路 (它屬性 上大不相同於Internet、 BITNET、 及FidoNet等等), 這一點很多朋友會 誤解。 Usenet News、 Netnews 或甚至News 是大部分人對Usenet網路應用 的稱呼, 本文在不同地方分別會使用Netnews或News這兩個名詞來稱呼。 目前參與Usenet交換的, 應該是以Internet的用戶最多。 與Usenet相關的軟體名詞相當多, 底下筆者沒有一一做解釋, 若讀者 讀起來很吃力, 則剛剛推薦的書籍及文章, 讀者不妨想辦法拿來讀。 □ Netnews軟體技術解析 我們從技術面看, 執行Netnews服務的軟體可以分為三個層面來看, 一 般使用者所注意到的只有第一個層面, 那就是News Reader界面軟體, 使用 者透過這一個界面軟體來讀取(Read)、 回應 (Follow-Up/Reply)或者 發送 (Post) 信息。 順便一提, News界面軟體也就是News Client。 在臺 灣, 最廣為使用的News界面軟體很可能是 Tin, Tin是Unix的應用軟體, 另 外在MS-Windows環境下可以看到Trumpet及WinSpan等等, 這是Windows的 News 應用軟體。 第二層面則是Netnews Server, 這部份真正是News軟體的主幹, 這 部份本系列專欄會介紹INN及C-News 兩套軟體, 這兩個都是 Unix應用軟 體。 News Server是負責將News 討論信(Article) 收入歸檔(Filing)、 執行轉送(Forwarding)服務、 News過期管理、 以及News閱讀及傳輸權 限的設定, 諸如此類的瑣事。 News Server一旦設定完成後, 以上的動 作都會全自動的執行, 而無須人工涉入。 News Server的管理技術是本 文討論的重點。 News Server對News Client的服務, 通常可以透過兩種方式, 一種 是讀取自己機器檔案系統內的News, 這方式, 您在該機器內要實際擁有 一個帳號。 另外一種方式則是透過 NNTP 提供 News 讀取服務, 這方式 主要用在 TCP/IP 網路上。 以 NNTP 方式讀News的話, 您所使用的News Reader軟體必須支援NNTP才行, 同時, 提供您讀News的機器也必須支援 NNTP。 舉個例子來說, 對公司內原本熟悉Unix的使用者來說, 不妨直接 在Server上開個帳號, 使用者login 到機器內, 以Tin來閱讀, 這樣的讀 法可以充份發會Tin功能強大及彈性。 可是對於那些強烈排斥Unix但是熟 悉中文 MS-Windows 的使用者來說, 系統管理者就可以幫忙安裝Trumpet 或WinSpan這類的軟體給他(她)們使用, 這類的軟體是用NNTP當界面取得 News Server的服務, 如此使用者就可以用原本的操作習慣來讀News, 而 無須login到Unix機器, 自然的不會碰到Unix。 第三個層面則是負責傳輸(Transport)的部份, News 傳輸工具主要 存在於Server對Server的喂送, 一般常用的傳輸方法有NNTP、 UUCP及 E-Mail等等, INN 與 C-News都支援以上三種傳輸方法, 不過 C-News內 定只支援UUCP及E-Mail傳輸, INN內定只支援NNTP及UUCP傳輸。 以下我分別會針對News Server與News Transport做詳細介紹。 □ News 的運作原理 關於News的運作, News 使用者是透過News Reader軟體來讀取(Read) 或發送 (Post) , 這類軟體可以稱之為News界面軟體或者News讀取軟體。 當使用者發送出一封討論信時, News Server 立刻接手處理。首先Server 會把該封討論信放在自己的News Spool (/var/spool/news) 之下, 同時 在外送預備區 (通常是/var/spool/news/out.going/site 或 /var/spool /news/out.going/site/togo) 留下一份記錄。 這裡, News Server對 News Reader的服務是即時的, 也就是說, 以上這些流程是一瞬間完成, 而且是連貫的。 接下來就由News Transport軟體接手, 不過, News Server到News Transport之間就不一定是即時進行, 正常的話, 負責執行傳輸的軟體 是由 cron 定時啟動, 之後依照/var/spool/news/out.going/site這份 記錄, 把News外送到下游的News Server。 照內定狀態, INN 與 C-News 的傳輸工作都必須透過 cron 來帶動, 這是典型的批次處理模式, 至於 如何達到即時處理, 我之後會介紹。 整個Usenet的架構, 就是這樣一個News Server 把討論信傳給另一 部News Server, 如此由點而面, 構成一個資訊傳輸網。 再次提醒讀者, Usenet 中的 諸多News Server彼此之間的差異可能非常大, 諸多常見的 傳送方法包括衛星傳送、 NNTP over TCP/IP傳送、 UUCP dialup、 UUCP over TCP/IP、 E-mail (用任何可能的Mail Transport Agent)等 等, 一部Server Server只要使用何其上下游News Server 相同的傳輸 方法即可, 而無須顧慮外面世界究竟如何。 另外還有一點與News Transport相關的觀念, 對NNTP傳輸方式來說, News 的喂送, 通常是上游的News Server「主動」將News喂送到下游的 News Server。 舉個例子來說, 我們所需要的Newsgroups, 是我們的上 游News依照我們所要求的 (也就是我們指定訂閱的) 討論區newsgroups, 不多不少的傳送過來, 我們只需要「被動」的接受即可, 換個角度, 對 於我們這一端產生的東西, 也是我們主動傳給我們的上游News Server。 這個說明適用於大部分的情況, 至於其例外, 我會在後面專門來介紹News 傳輸的篇幅中, 更詳細的介紹。 上面提到很多「下游」、「上游」 的關係, 其實, 您上游的News Server也就是下游的News Server, 兩部News Server之間的關係, 彼此 既是上游也是下游, 筆者借用這個名詞只是幫助讀者瞭解而已。 □ 哪一種情況需要建立自己的News Server 首先我們有必要知道, 假如您公司或單位只有一兩個人有讀取News的 習慣或需求, 我們也許沒有必要投資額外的人力與設備來建立一部News Server, 何況News Server後續的維護也同樣需要人力成本。 這種情況, 您只需要裝設News Reader軟體就可以了, 或者連Reader 軟體都可以不要。 前者的方法是夠過支援NNTP的News Reader軟體, 來讀 取遠端也同樣支援有NNTP的News Server (該Server必須有開放您讀取才 行), 後者則是想辦法在別部裝有News Server的機器上取得一個帳號 , 之後由那部機器來讀取News就行(假設該部News Server 也同時裝有News Client), 資策會SEEDnet網路服務與電信局HiNet網路服務都包含有這類 服務。 假如貴公司或單位有三四個人以上, 會經常性的由News取得一些情 報, 或由News 與全球同業互換訊息, 這時有一部自己的News Server是 很值得的, 因為這樣做, 您把所有的Information實際的引入公司內, 並 牢靠的存放於自己的硬碟內! 假如您的情況正是如此, 請往下看下去。 □ 什麼是INN 這一節與下一節所介紹的東西, 讀者朋友可以在INN FAQ發現詳細的說 明, 這裡筆者只做補充性的說明。 INN (InterNetNews) 是Unix環境下的News Server軟體, 這些Unix系 統包括Linux、 BSD系列、 AIX、 SunOS、 Ultrix、 HP-UX、 A/UX、 OSF、 Solaris、 SCO UNIX 等等。 INN 內建支援NNTP協定, 這是最值得一提的一點。 □ INN vs NNTP 這是一個相當有趣的問題, 也最容易把人給弄糊塗了。 INN是一套News軟體, NNTP (Network News Transport Protocol) 則是 個通訊協定規格, 這兩者是完全無法做比較的 (就好像拿船跟大海比)。 另外,更困擾人的, 由於真正存在NNTP-1.5.11軟體, 使得我們更不容易分 辨。 NNTP-1.5.1 是完全與INN無關的軟體, NNTP-1.5.1通常被用來搭配 C-News使用, 使得C-News Server也可以支援NNTP傳輸以及接收News Reader 以NNTP方式讀取。 □ INN/C-News 擺在哪個目錄 大部分情況, 我們取得INN或C-News軟體是以Source Code情況存在, 這 情況我們可以決定, 究竟該把Server軟體擺在檔案系統的哪裡, 筆者建議 如下(這建議極可能也是大部分人所採用的狀況): /usr/lib/news: News Server的相關設定檔案 /usr/lib/news/bin: News Server附屬相關工具程式 以上可以分別用/usr/local/lib/news及/usr/local/lib/news/bin取代, 至於News 的存放Spool, 想當然爾是/var/spool/news。 另外一點, 不論選擇C-News或INN, 都要把 inews 與 rnews兩之工具 程式擺在PATH路徑之內, 通常是/usr/bin或/usr/local/bin, 實際上的作 法可以使用連結檔, 連結到INN或C-News所附的inews/rnews。 這兩支程 式也是News Server工具程式中, 唯一必須確定位於一般使用者通用路徑 中的兩支程式。 □ INN vs C-News 這是一個相當好的話題, 也是相當具有爭議性的話題。 網路上常聽到 「C-News已經過時, 請改用INN」的說法, 在筆者看來, 這種說法是不對的 ,這就類似「SLIP已經不行、 請改用PPP」或者「UUCP已經老邁、 請改用 TCP/IP」...等等的說法, 這些都是偏見, 因為其各有長處與短處, 特別是 其各自有不同的適用場合。 照筆者經驗, C-News是一個相當容易裝設與管理的News Server軟體, INN則相對需要更多的細心照料, 比方說, 不小心以root帳號執行INN的系 統管理, 這就足以使INN罷工! 關於參考文件上, INN 有豐富的線上使用 手冊及其他電子文件可以參考 (主要是INN FAQ 1-4及Install.ms), 以上 兩點我覺得C-News 稍微遜色一些, 不過 C-News 則比較容易找到傳統網 路書籍的介紹。 以功能來說, INN軟體約等於C-News+NNTP1.5.11, 這兩者同樣都支援 UUCP、NNTP及E-mail傳輸。 INN 可以做到完全即時的News交換, 對於上 游喂送進來的News, 可以直接在記憶體中處理, 之後直接收入News Spool 歸檔。 對於送出的News也一樣, 它可以做到沒有停頓的立刻送到下游 News Server。 INN 能夠如此, 是用大量系統資源換來的, 因為INN佔用 到較多的CPU時間與記憶體空間。 對C-News+NNTP1.5.11來說, 由於兩者 都沒有常駐記憶體, 所以可以相對節省CPU及記憶體的使用, 不過 C-News 以及NNTP1.5.11 施加於硬碟的讀寫負荷遠高於INN很多。 最後一點讀者不妨知道的, INN 與 C-News這兩個News Server 都不 是單純一支服務程式組成, 而是由一群工具程式與配備檔 (Configuration Files) 所構成。 INN 可以稱之為一個完整的News套裝軟體, 因為它已經 包含了所有必要的NNTP傳輸工具, C-News則單純只是一個News Server, 它 沒有附帶任何UUCP以及NNTP軟體。 □ NNTP/UUCP/E-mail 喂送方式 News Server對News Server的喂送方式有很多種, 這裡我們介紹三 種傳輸方式, NNTP 適用在TCP/IP網路場合, UUCP 可以用在UUCP (也就 是Dial-up) 以及TCP/IP網路, E-mail則可以用在以上兩種都不適用時的 特殊場合。 另外一種成本效益比非常好的衛星喂送方式, 這裡不介紹。 對初次裝設News Server 的公司來說, 假如有 Internet連線的話, 選擇NNTP作為News Server的傳輸工具非常適當 (也就是選擇INN), 至於 那些透過Dial-up連線者, 則可以選用UUCP (也就是選擇C-News)。 但是若把News傳送速度以及網路使用效率考慮進去就有趣了。 假如 您希望您所發出去的討論信, 在最短的時間內就可以傳遍全世界的每一 個角落, 即時性的NNTP傳送可以達到如此。 但是假如您想讓您的線路頻 寬做最經濟實惠的使用, 則UUCP壓縮傳送可以達成這目標, 照筆者的測 試, UUCP可以具體的節省百分之64的傳輸量, 或者這樣說, 原本100MB的 討論信, UUCP可以壓縮至20MB到50MB之間 (隨討論信內容屬性、 以及壓 縮軟體種類而有差異), 之後才進行傳送作業。 UUCP這樣的壓縮傳送對於 那些低速線路 (56K bps以下) 的Internet用戶來說, 非常有意義, 因為 您們可以接收更多的News, 卻付出較少的代價。 以上所說的UUCP可以是 UUCP over TCP/IP, 也可以是Dialup UUCP。 有關UUCP的部份, 在我往 後的專欄中會有介紹。 額外說明一點, 真正執行壓縮的, 不是UUCP, 而是News Server (INN 與C-News都可以做到), 或者, 更準確的說, 其實是News Server呼叫外部 壓縮工具來執行壓縮作業。 我上一段故意是UUCP壓縮, 其實是錯誤的, 但 這技術上的細節, 我們大部分人都沒有必要知道。 INN News Server 的建立 對於已經熟讀前面介紹的讀者朋友來說, 您應該已經具備了很清楚的 基本News或網路知識, 假如接下來您要親自架設一部News Server系統, 您最需要的指引文件是Install.ms及INN FAQ 1-4冊, 這些指引文件可以 指引您有關編譯 (Compile) 、安裝INN以及之後的設定工作。 至於我往下 的說明只介紹INN設定, 而且只是精簡的介紹。 □ INN FAQ 入門 INN 有一個相當不錯的FAQ (Frequently Asked Questions) 文件, 到 目前 (1994九月) 為止, 這文件分成四冊, 第一冊專門回答一般性疑問, 這些疑問主要是那些從未使用過INN者所問的問題, 第二冊主要是除錯 (Debugging) 導覽, 第三冊則是有關於INN日常系統維護一些注意事項, 第 四冊則主要是為Sun Solaris 1.1 用戶而寫的安裝指南。 INN FAQ 可以用 FTP在NCTUCCCA.edu.tw:/packages/news/inn目錄下取得, 不過您無法上 Internet, 就沒有辦法了。 至於更不可錯過的 Install.ms 則像極了一本專門書籍, 非常詳細的 說明有關編譯及安裝INN所需要的所有的技術性細節。 Install.ms 這文件 就附在INN套裝軟體裡面, 讀者可以groff -man -Tascii Install.ms | more 指令來閱讀。 □ 取得及安裝 INN 整個 INN 套裝軟體的原始程式碼可以用FTP在NCTUCCCA.edu.tw: /packages/news/inn/inn1.4sec.tar.gz 取得。 取得後, 通常您可以製 作一個/usr/local/src/inn目錄, 把INN軟體移到這目錄, 之後解壓縮。 接下來編譯以及安裝的動作您就是根據前面提到的Install.ms以及 INN FAQ來做, 這些文件已經說明的非常清楚。 前面我有介紹News Server所安裝的路徑, 假如您按照筆者所推薦路 徑安裝 INN 的話, 您的 INN News Server的佈局會大致如下, 您最好檢 查看看是否有少於一下的東西, 尤其假若沒有in.coming及out.going, 您 可以 cd /var/spool/news ; mkdir in.coming out.going ; chown news.news * 這組指令來做。 /usr/lib/news # 所有 INN 設備檔 /usr/lib/news/etc # innd 啟動檔案 /usr/lib/news/bin # INN 工具程式 /usr/bin/inews # INN 界面工具, 負責傳News給innd /usr/bin/rnews # INN 界面工具, 收受UUCP進來的News /var/spool/news/in.coming /var/spool/news/out.going /var/log/news # News 記錄檔所在目錄 □ INN 綜合觀念及注意事項 INN對檔案系統存取由權(Permission and Ownership) 非常過敏, 當執 行INN系統管理工作時, 除了啟動(或重新啟動, Relaod) 動作必須以root 身分來做, 其餘切記必須以news身分來做。 這一原則同樣也適用於C-News , 但C-News的要求比較不嚴謹。 INN的一部分工具程式是以Perl寫成, 所以您必須在您的Unix系統上裝 置Perl才行, 假如Perl沒有擺在/usr/bin/perl, 最好也做一個連結檔到這 位置。 另外一點非常重要, INN 是以daemon型態提供服務, 也就是說, INN 持續掛在背景執行, 緊緊看著編號 119 的 nntp port, 由於這原因, 我們 必須確定 /etc/inetd.conf 沒有提供nntp服務, 若有的話, 在該nntp所在 的一行最前面加上 # , 使成為註解行, 之後執行下面指令從新啟動in.inetd 。 $ kill -1 `ps -ax | grep inetd | grep -v grep | colrm 6` □ INN 基本設定 下面我們就來看看架設INN時, 幾個最基本的設定檔案 (Configuration File) 的調整。 有關這些設定檔案您都可以在您的INN軟體程式碼的samples 目錄下找到樣本作為參考, 拿這些樣本作為我底下的補充, 您會發覺真的 一點也不難! * 取得newsgroups 信區說明檔 假如您這部新的News Server有 Internet連線, 您可以照下面操作取 得newsgroups檔案, 取得後編輯該檔案(拿掉抬頭六行), 之後擺在News Server的主要目錄 (/usr/lib/news)。 假如該機器不在Internet, 可以 拜託上游的New Server 用E-mail送過來一份。 $ su - news # 以news身分進行操作 $ telnet news.csie.nctu.edu.tw nntp > /tmp/newsgroups list newsgroups quit Connection closed by foreign host. $ vi /tmp/newsgroups (或用pico、joe等文字編輯器悉聽尊便, 這目 的是要刪除前面幾行) $ mv /tmp/newsgroups /usr/lib/news/newsgroups * 取得active 並做歸零整理 $ su - news # 以news身分進行操作 $ telnet news.csie.nctu.edu.tw nntp > /tmp/active list active quit Connection closed by foreign host. $ vi /tmp/active # 同樣用編輯器把抬頭拿掉 # 下面指令歸零整理, 並把成品輸出為/usr/lib/news/active $ awk '{ $2 = "0000000000" $3="0000000001" ; print }' \ /tmp/active > /usr/lib/news/active * INN 基本配備檔介紹 以下基本配檔案所在位置都假設在/usr/lib/news 之下, 讀者參考 時, 不要忘記依照您的情況手工修改。 active 定義所有Newsgroup newsfeeds 決定本News Server所引入、 以及喂送到下游的Server hosts.nntp 定義哪些機器被允許與本機器進行NNTP傳輸 nnrp.access 定義哪些NNTP Client被允許讀取本Server的東西 inn.conf 關於本News Server 的基本定義 nntpsend.ctl定義那些以nntpsend送出的下游Server 以上幾個配備檔是最重的的部份, 其關係著INN 執行與否, 不能有一 絲毫的錯誤, 以下幾個配備檔案的重要性則為其次, 沒有詳細介紹, 讀者 請分別參考其線上使用手冊的說明, 比方說 man expire.ctl。 # passwd.nntp 用於對方Server有設通行密碼的情況 # expire.ctl 對各Newsgroups保留期限之定義 # control.ctl 有關Usenet 控制類信息, 本Server所允許之存取權限定義 # moderators 自動轉寄所有moderated newsgroup到moderator。 # overview.fmt Overview 資料庫的格式 設定INN並不是非常困難, 最困難的是如何謹慎的來設定, 以及萬一出 錯時, 如何由系統的記錄檔來輔助除錯。 下面我們就來詳細看看個別配備檔的設置。 # active active檔案格式為 name himark lomark flags, 我們用下例來說明。 tw.bbs.comp.network 0000000000 0000000001 y tw.bbs.netnews 0000000000 0000000001 y tw.bbs.announce 0000000000 0000000001 m 照前面筆者推薦的方法取得這檔案並稍微切除前面幾行, 正常的話, 您就擁有一個現成的active配備檔了。 通常您可以執行inncheck active 指令查看該檔是否正確, 如下操作說明。 $ /usr/lib/news/bin/inncheck active /usr/lib/news/active:1: malformed line. /usr/lib/news/active:208: malformed line. 上面訊息表示第1及208行格式錯誤, 有這情況時, 您就必須以編輯器 來修改active檔案, 依照man active線上手用手冊以我下面的說明調整。 想反的, 若執行inncheck active指令後沒有回應, 則表示設定正確。 接下來我稍微介紹一下active這檔案。 active這檔案有四個欄位, 各 欄位間以一個空格為間隔, 很重要的一點, 最後欄位(也就是flags)之後 沒有空格。 有關最後欄位flags, 最常見者為y 與 m, y 者代表這個 討論區接受讀者post, m 則代表這個討論區設有專門管制人來看管, 讀者 若post到這的討論區, 該post通常會自動被轉到該討論區管制人(Moderator) 的E-mail信箱中, 該管制人若認可您post的內容, 他(或她) 會幫你post到 該newsgroup。 有關active檔案的細節, 請以man active指令查詢。 # newsfeeds newsfeeds檔案的設定, 算是INN News Server最重要的工作, 也是困 難度最高的部份。 newsfeeds檔案決定這部News Server要接收哪些 newsgroup, 以及要喂送哪些newsgroup出去。 INN newsfeeds檔案至少必須定義自己以及一個喂送下游 (也就是上游 ) Server。 我想這道理很容易明白, 因為我們這部新News Server所產生 的東西, 也必須藉由我們上游這部News Server 傳出去。 這裡我再重複一 次, 對於您所接收的東西, 您必須清楚的告訴您的上游Server的系統管理 者: 哪些東西送、 以及哪些東西不送。 ## /usr/lib/news/newsfeeds ## ME這一行定義本Server所接收的Newsgroup, 以#開頭的為註解行, 這裡 ## 只定義接收凡是以comp、news、tw等等開頭的newsgroup, local.test為內 ## 部測試專用。 ME:!*,comp.*,news.*,tw.*,local.test:: ## NNTP feed using 'send-nntp', foo1為本Server的上游, 這裡把相同的 ## 東西喂送回去。 foo1/foo1.com.tw\ :!*,comp.*,news.*,tw.*,local.test\ :Tf,Wnm: ## ## UUCP feed foo2/foo2.com.tw\ :!*,tw.*,local.test\ :Tf,Wfb,B4096/1024: ## End of /usr/lib/news/feeds file 定義這檔案時有些基本規則, 所有以#符號開頭者, 代表此行為註解 行, 以反斜號結 \ 尾者, 表示斷行, 由下一行接下去。 每一行有四個欄位 , 各欄位以冒號 : 隔開。 這裡我只做基本的說明, 讀者不妨以這範本來 修該即可, 萬一仍有困難, 這時再參考man newsfeeds的線上說明。 在這示範中, ME一行是定義自己這部News Server所接收的東西, 這 裡定義接收comp.*、 news.*、 tw.* 以這三個開頭的newsgroups, 另外 local.test為暫時性測試用途, 這裡local.test只在ME、foo1及foo2三部 機器間流傳。 在這裡, foo1是我的上游, 所以所有它喂送給我的newsgroups, 我也 對應喂送給它, 這裡請注意一下, 只有本地post出來的, 或者由foo2所 喂送出來的, 才會送出去給foo1 (也就是不會有回流的情況發生)。 至於 foo2, 我只把全部tw.* 臺灣本地的東西喂送過去。 至於傳輸方式, 如同註解行的說明, 我與foo1之間的傳輸是NNTP, 我將用send-nntp這程式來執行傳送服務, 至於與foo2之間的傳輸則是 UUCP, 我將用sendbatch程式把外送的東西收集包裹, 之後丟給UUCP軟 體去處理。 有關傳輸的這部份, 我會在後面做更詳細介紹。 # hosts.nntp 這裡我們定義讓foo1.com.tw及foo2.com.tw兩部Server可以有 Transfer的權力, 也就是說, 這兩部機器可以喂送News過來。 ## /usr/lib/news/hosts.nntp foo2.com.tw: foo1.com.tw: # nnrp.access nntp.access則是定義本News Server開放讀取(Read及Post) 的情況 。 有關nnrp.access的設定細節, 請參考man nnrp.access的說明。 這裡我順帶一提, INN 對於Clinet端透過NNTP的讀取請求, 是由nnrpd 這個daemon執行服務, 而不是innd, 這裡也請讀者留意, nnrpd並沒有掛 在系統背景, 而是被innd所啟動。 ## /usr/lib/news/nnrp.access ## 下面這一行的設定, 關閉所有讀取服務, 之後幾行定義的, 則是允許 ## 從幾部機器下使用者以NNTP來讀News。 *:: -no : -no :!* ## 下面這一行允許本Server自己的使用者, 使用NNTP Client讀取所有的 ## 討論信區。 foo0.com.tw:Read Post:::* 修改nnrp.access檔案後, 不需要更動innd, 這是因為nnrpd每次被 innd叫用時, 會重新讀取nnrp.access檔。 # inn.conf inn.conf 是INN Server本身的定義檔。 您每封您發送出去的討論信 中, 您都可以看到很多訊息附在其中, 這些訊息就是inn.conf檔案造成的。 ## /usr/lib/news/inn.conf fromhost: foo0.com.tw pathhost: foo0.com.tw organization: 公司大名 (Foo's Co.,) server: foo0.com.tw domain: com.tw # nntpsend.ctl 定義那些以nntpsend傳送的下游Server ## /usr/lib/news/nntpsend.ctl foo1:foo1.com.tw:: □ inncheck 上面這些INN設定檔案修改完成後, 我們可以先來查看一下是否有誤, INN所附 innecheck 這支程式可以幫我們做初步的檢查, 假如有明顯的 錯誤, 我們可以從 inncheck 的執行結果看出來。 下面示範的結果表示 設定正常。 $ /usr/lib/news/bin/inncheck -v Looking at /usr/lib/news/active... Looking at /usr/lib/news/control.ctl... Looking at /usr/lib/news/expire.ctl... Looking at /usr/lib/news/hosts.nntp... Looking at /usr/lib/news/inn.conf... Looking at /usr/lib/news/moderators... Looking at /usr/lib/news/newsfeeds... ME, foo1, foo2, /usr/lib/news/newsfeeds:0: ME entry accepts all incoming article distributions done. Looking at /usr/lib/news/nnrp.access... Looking at /usr/lib/news/nntpsend.ctl... Looking at /usr/lib/news/overview.fmt... Looking at /usr/lib/news/passwd.nntp... □ 如何啟動INN 假若所有的設定檔都完成了, 這時我們可以測試看看INN能否正常執行。 啟動INN的方法很簡單, 我們以root的身分執行/usr/lib/news/etc/rc.news, 這結果會產生/usr/lib/news/etc/innd -p4 -i0 的process 常駐在背景, 我們可以ps指令看到。 INN News Server成功的在背景等待服務之後, 我們就可以開始測 試。 順便一提, 假如經過一陣子運轉, 一切都順利的話, 我們就可以考慮 是否把/usr/lib/news/etc/rc.news指令加入/etc/rc.local (Linux在 /etc/rc.d.rc.local) 檔案內, 如此每次開機時就可以帶動INN的運轉。 這建議供您參考。 □ 設定測試信區並進行測試 當您覺得大致就緒後, 這時候就可以試著Post一些東西, 看這新News Server運轉正不正常。 執行測試時, 特別要記住一點, 不要隨意張貼! 通常個別區域性的 Newsgroup都有測試專用區, 像tw.test及tw.bbs.test等等是全臺灣性的 測試區。 假如設定正確的話, 您可以成功執行下面操作: $ inews -h # 執行inews, 手工張貼 Newsgroups: tw.bbs.test Subject: test of INN posting # 空一格空白行 Sorry, test, please ignore! ^D # 按Ctrl-D結束 現在照下面操作, 看看Post是否成功, 正常的話, 這一個動作會自動 產生/var/spool/news/tw/bbs/test目錄, 並且一個檔名為 1 的檔案, 1 是編號為 1, 下一封則命名為 2。 $ ls -l /usr/spool/news total 3 drwxr-xr-x 3 news news 1024 Jul 21 16:06 in.coming/ drwxr-xr-x 2 news news 1024 Aug 6 12:30 out.going/ drwxrwxr-x 4 news news 1024 Jul 21 16:06 tw/ $ cd /var/spool/news/tw/bbs/test # 產生編號 1 的檔案 $ ls -l -rw-rw-r-- 1 news news 342 Jul 26 17:01 1 另外讀者也可以查看/usr/lib/news/log檔案, 以剛剛這動作來說, 該 檔案會有類似下面這一行的記錄, 這表示INN運轉正常。 我們從該記錄也可 以看出來, INN 本身也經接受該post, 並且它根據newsfeeds檔案的設定, 把該post轉往foo1及foo2。 Aug 6 20:21:16.437 + not-for-mail <320rbs$ii@foo0.com.tw> foo1 foo2 INN 知道要把這封測試信轉往 foo1 及 foo2 兩部News Server, INN 究竟是如何讓負責News傳輸的軟體知道這一點? 很簡單, 記得我們前面 提過, INN 會留下一個記錄在/var/spool/news/out.going目錄, 這就是 INN 的為送News存放區。 □ 外送News存放區 (Outgoing News Spool) 筆者使用這個「外送News存放區」名詞或許不妥, 因為或許這會誤導 讀者以為所有外送的東西其內容都額外存在這裡一份, 不是的, 這裡實際 上只是一個記錄區域, 記錄所有外送討論信其檔名、 討論信編號等等這 類的訊息而已, News 傳輸軟體就是根據這記錄去抓取所有外送討論信的 內容, 傳遞到foo1 及 foo2兩部News Server。 照筆者介紹內定的News(批次)傳送方式, 所有從我們News Server喂 送出去的東西, 會先記錄在「外送News存放區」, 這通常是/var/spool/ news/out.going/site-name, 對新的INN News Server來說, 這個目錄通 常是不存在的, 我們可以下面命令來執行: $ su - news # 以 news 身分執行 $ mkdir /usr/spool/news/out.going 我們延續剛剛這個測試結果來說, -rw-rw-r-- 1 news news 34 Aug 7 20:30 foo1 -rw-rw-r-- 1 news news 34 Aug 7 20:31 foo2 我們就來看看該檔案的內容: $ cat foo1 to/test/1 <323i0v$1rv@foo0.com.tw> □ 如何取得News喂送 (Newsfeeds) 到目前為止的介紹內容中, 筆者都假設我們已經知道誰可以作為我們 的上游, 把News喂送下來, 這情況, 我們現在就可以通知該上游News Server 的管理者, 開始把我們指定接收 (Subscribe) 的News傳送過來。 可是通常的情況並不是如此, 很多時候, 在我們決定建立自己的News Server時, 我們並不知道有誰願意 (或能夠) 把News喂送給我們, 這就是 本節所要介紹: 如何取得News喂送。 取得News喂送的意義, 也就是說, 我們希望透過一部Usenet News Server的幫忙, 也成為Usenet的一員。 要成為Usenet的一員非常簡單, 您不需要經過任何的申請, 您只需要一部News Server把News喂送下來, 不過最好您能有額外接洽另外一部News Server做備份喂送, 這部次要 (Secondary) News Server平常並沒有真正送News過來, 當您的上游 Server 當掉時, 您就可以緊急聯絡這部次要News Server的管理者把 News送過來。 最常見的情況, 提供您Internet連線服務的公司 (Internet Provider) 就可以提供您News喂送服務, 您與他們聯絡, 告訴他們你所要 的Newsgroups以及傳送方式 (NNTP or UUCP or whatever)。 假如您第一 次管理News, 最好您先知道究竟您的上游Server接收有哪些東西, 一天的 交通量大概有多大, 這一點非常重要, 請看我後面的分析。 對整體News 交通量有概念後, 您才會知道如何根據自己的情況及條件, 接收所有您公 司有相關或者有幫助的討論信區。 假如因任何理由, 您無法由您的Internet Provider取得News喂送, 假如您在臺灣的話, 您不妨在tw.bbs.netnews這個討論區發佈(Post)一個 請求信, 懇求其他News Server 管理者的幫忙。 另外的情況, 假如您還沒有Internet連線, 您則可以透過Dialup UUCP 取得News, 不過目前在臺灣仍沒有UUCP服務 (筆者是指由UUCP連線Internet) 的服務 (不過就快有了), 對這方面有興趣的朋友, 請密切注意 tw.bbs.netnews、tw.announce及tw.bbs.comp.network這幾個討論信區。 照筆著粗淺的經驗, 一部剛誕生的News Server究竟適合接收多少的 News, 有幾點必須顧慮, 第一點就是系統本身的負荷, News Server會佔用 相當多的CPU時間、 記憶體以及Disk I/O的負荷, 您必須密切評估並觀察 機器的運轉情況。 第二點是硬碟空間, 假如以正常情況來說, 一般News 討論信保存期限為兩週, 則您的硬碟News Spool空間必須大於一天所收到 的量再乘以14。 最後一點則是網路負荷, 這一點非常重要, 假如您公司是 以PPP或SLIP連上Internet, 最好留意, 不要讓過重的News交通量佔用了全 部線路, 您可以加減乘除您的線路頻寬以及所接收的News交通量, 以下我 就來介紹各討論信區的交通量。 根據1994 七月底UUNET所統計的Usenet交通量報導 (公佈在news.lists 這個討論信區), 單單以目前臺灣本地的討論信 (凡以tw開頭之信區) 來說, 平均一天的交通量約為1.4 MB之間, 這數字還沒有把hinet.*、seed.*及 nsysu.* (時報即時新聞) 等包含進去。以全球性電腦相關討論信區 (以 comp開頭者) 來說, 一天就有超過11MB 的交通量, news.*討論區則約有 2.7 MB。 每天大約有如您的News Server接收tw.*、 news.* 及comp.* 這 三個範圍的討論信 (如果能夠, 筆者建立您公司至少接收這三類的信區), 每一天少說就有13MB的News交通量會佔用掉您的線路 (假設說您沒有壓縮 傳送)。其它的部份您可以參考下表, 下表的數據是兩週的交通量。 Article Total Category Count Mbytes Percent Mbytes 1 alt 222772 840.095999 50.7% 962.952712 *2 rec 176243 256.291224 15.5% 348.578895 *3 comp 120211 190.221057 11.5% 255.132679 *4 soc 59688 125.437859 7.6% 159.241423 *5 misc 31388 45.973892 2.8% 62.360896 6 clari 37041 43.925094 2.7% 65.271367 7 relcom 43129 40.029670 2.4% 68.871250 *8 sci 21257 39.352688 2.4% 51.005692 9 bit 24449 35.160489 2.1% 51.075306 *10 news 5660 33.943109 2.0% 37.502226 *11 talk 14170 33.264778 2.0% 41.964600 12 de 12047 25.320396 1.5% 32.673115 13 fj 12277 23.689749 1.4% 31.518749 14 fido 21990 22.026869 1.3% 34.959081 15 fido7 20226 19.593260 1.2% 36.562108 16 zer 13106 19.292393 1.2% 29.273975 17 ncar 9198 19.107149 1.2% 23.817022 18 tw 18107 12.349069 0.7% 19.754560 □ News 如何喂送進來 當上游News Server第一次將News喂送進來後, INN 會自動在 /usr/spool/news目錄下建造對應目錄, 比方一個屬於tw.bbs.netnews信 區的討論信進來後 (且其在active及newsfeeds有指定), INN 會自動的 造出/usr/spool/news/tw/bbs/netnews/1 目錄及檔名, 該檔名為 1 的檔 案就收存有這封討論信的內容。 □ cron 設定 cron 的設定是News Server最後一個步驟了, 不論INN或C-News 來說, 都有很多工作必需依賴 cron 來啟動執行, News的外送與每日News的維護 工作就是其中之二。 我建議以news身分, 編輯一個crontab.news檔案, 該檔案下加入以下 內容: ## cron table for news ## invoke send-nntp to send news to foo1 very 10 minutes 0,10,20,30,40,50 * * * * /usr/lib/news/send-nntp foo1 foo1.com.tw ## invoke send-uucp to send news to foo1 very 4 hours 0 0,4,8,12,16,20 * * * /usr/lib/news/send-uucp foo2 之後執行以下指令 (您的Unix系統若不一樣, 請查看man crontab): $ crontab -r crontab.news 或者 $ crontab crontab.news □ 重新啟動INN 由於INN 把所有配備檔案存留在記憶體, 當我們修改配備檔之後, 我 們可以只要INN重新載入該配備檔, 如此該修改部份可以立刻生效, 而無須 重新啟動INN。 /usr/lib/news/bin/ctlinnd reload active "INN active file modified" /usr/lib/news/bin/ctlinnd reload hosts.nntp "hosts.nntp modified" /usr/lib/news/bin/ctlinnd reload newsfeeds "newsfeeds updated" /usr/lib/news/bin/ctlinnd reload overview.fmt "overview.fmt updated" 有關ctlinnd 指令的說明, 請用ctlinnd -h及man ctlinnd來查閱。 □ 由News本身求助 初次管理News Server的朋友很容易會遇到各式各樣的困難, 但是由 於News管理技術目前在臺灣仍不普遍, 您想要找個人可以當面詢問, 應該 是很難的。 我建議您不妨由News本身來求助。 Usenet News 有相當多相關的討論信區, 您可以在這些信區提出問題 。 以下筆者建議的三個信區中, tw.bbs.netnews 屬於臺灣本地的信區, 這信區的討論範圍包含了任何跟News Server、 News Transport 及 News Reader有關的話題。 news.software.nntp 則是全球性NNTP傳輸相關話題 。 tw.bbs.netnews tw.bbs.comp.network news.software.nntp □ 範例: 如何增加一個下游 這裡筆者就用一個簡單的例子來回顧一下以上的設定細節。 假設這 部新INN News Server 引經能夠穩定運轉, 這時候您接到一個請求, 有 另外一部新的News Server請求您的喂送支援, 這時候您大概要做底下幾 件事: (假設該機器的是newman.com.tw) 1. 修改hosts.nntp, 我們第一步就是要給這部機器有傳輸的權力, 我們 可以在該檔案內加入底下這一行。 newman.com.tw: 之後 inncheck hosts.nntp # 檢查是否有錯 ctlinnd reload hosts.nntp "updated INN xfer permission" 2. 修改newsfeeds, 我們根據對方所請求的newsgroups, 來修改該檔案, 假設對方希望接收全部tw.* 開頭的臺灣本地討論信區。 newman/newman.com.tw:!*,tw.*:Tf,Wnm: 之後執行 inncheck newsfeeds ctlinnd reload newsfeeds "updated newsfeeds for newman" 3. 在cron 加入對newsman定時傳輸的設定 以news身分, 在news的crontab中加入: 0,10,20,30,40,50 * * * * /usr/lib/news/send-nntp newman newman.com.tw 之後重新執行crontab crontab。 只有三個步驟, 夠簡單吧! □ Linux INN 在這裡我順便把話題引入Linux, 這是因為Linux是最出色的Unix, 尤 其在網路與通訊方面。 Linux 的INN 不傷您的腦筋, 您輕易調整就可以 派上用場。 Slackware Linux 附有C-News 與 INN兩套News Server軟體 (指定安 裝所有n系列的軟體, 就可以擁有), 這兩套都已經是可執行碼, 而且都已 經是正確安裝好的軟體, 您唯一要做的就是照我上面的說明, 並按照您的 需求來調整即可, 這是為何我剛剛說Linux 的 INN不傷您腦筋。 採用Linux 來提供網路解決方案的讀者需要注意一點, INN 與C-News 絕對不能混著用, INN 與 C-News 有各自的inews與rnews。 照Slackwre Linux的內定情況, 系統的/usr/bin/inews與/usr/bin/rnews是連結到 /usr/local/lib/news目錄之下, 不只這一點, Linux 的 Tin 內建會去讀 取/usr/local/lib/news這個位置的News Server, 這是C-News所在。 簡單 的說, C-News是內定News Server。 有關C-News的介紹, 我會在下一期專 欄介紹。 若您想改用INN作為News Server的話, 您大約有幾件事: 下面的操作是換掉/usr/local/lib/news, 改為連結檔, 連到/usr/lib/news $ mv /usr/local/lib/news /usr/local/lib/c-news $ cd /usr/local/lib $ ln -s ../../lib/news news 下面的操作換掉inews與rnews (也就是改用INN的inews與rnews) $ cd /usr/bin $ ln -sf ../lib/news/inews inews $ ln -sf ../lib/news/rnews news 最後一個動作是取消/etc/inetd.conf內nntp port, 如此inetd 這個 super server就不會去看守nntp (編號119) 這個port, 而讓INN自己來。 結尾: 本文中, 筆者花了很多的時間與心血, 來思考如何把相關News技術性 的整體觀念做介紹, 我猜想, 這可以幫助剛要開始接觸News系統管理的讀 者朋友知道事情是怎麼一回事, 同時也可以知道, 各部份News軟體是如何 配合作業。 但是筆者也知道, 本文有關INN介紹的深度仍然非常有限, 尤 其相當多的操作細節與設定, 筆者只做最精簡的介紹, 更沒有提到如何除 錯, 對於這部份, 我希望讀者自行由INN FAQ補足, INN FAQ是一個絕對不 能錯過的指南。 最後, 希望讀者們可以由本文受益。 有進一步詢問筆者問題的朋友, 請直接聯絡我, 筆者很樂意看到讀者朋友們直接的來函交流, 尤其懇請其 他先進能夠不吝來函指教, 在此我也先致謝交大陳昌盛先生(chen@cc.nctu. edu.tw) 的大力指導。 朋友們請以E-mail聯絡我, 來函中英文皆可, 請 用E-mail寄到yuan@UUserv.Net.tw。 我們下回見。 <================== 以下為陳昌盛先生對此文之評論=============================> > -------------------------------------------------------------------------- < 大體上, 這一篇文章, 對 NetNews services 的介紹, 相當深入, 文筆也相當流暢. 不過, 個人仔細閱讀一下. 其中有許多地方, 我有許多不同的看法. 甚至我發現, 有幾個地方的說明是錯誤的. ( 底下將一一列出. ) * 關於 INN newsfeeds 的設定, 原來的文章的說明, 有錯誤. * 根據一般的了解, Disk I/O 是影響 News server performance 最關鍵的因素, 接下來才是 network bandwidth. 再其次是 memory size. 至於 CPU 的影響力, 除了許多要額外提供 UUCP, 檔案壓縮服務的站台外, 一般 News server 的 CPU 使用率, 並不高. ----------------------------------------------------------------- Note: 雖然, 原文末尾, 有我的名字, 但是個人卻是近日, 經由這一個 repost, 才首次, 得以讀到這一篇文章的內容. ----------------------------------------------------------------- Hwang Yi-Min (hym84@cs.ccu.edu.tw),25 Feb 1996 06:27:45 GMT wrote: : □ Netnews軟體技術解析 [delete] : : 第二層面則是Netnews Server, 這部份真正是News軟體的主幹, 這 : 部份本系列專欄會介紹INN及C-News 兩套軟體, 這兩個都是 Unix應用軟 : 體。 News Server是負責將News 討論信(Article) 收入歸檔(Filing)、 : 執行轉送(Forwarding)服務、 News過期管理、 以及News閱讀及傳輸權 : 限的設定, 諸如此類的瑣事。 News Server一旦設定完成後, 以上的動 : 作都會全自動的執行, 而無須人工涉入。 News Server的管理技術是本 最後一小段的說明, "無須人工涉入", 這一點的說法, 似乎宜稍加修改. News 是一個 相當 active 的 services. 上面所列的設定, 雖然並不 是所有都需經常修改, 但是過一陣子小修一番, 卻是非常有必要. : 第三個層面則是負責傳輸(Transport)的部份, News 傳輸工具主要 : 存在於Server對Server的喂送, 一般常用的傳輸方法有NNTP、 UUCP及 : E-Mail等等, INN 與 C-News都支援以上三種傳輸方法, 不過 C-News內 : 定只支援UUCP及E-Mail傳輸, INN內定只支援NNTP及UUCP傳輸。 不太了解這堜珓的 e-mail 傳輸是什麼. INN 本身也可以設定成, 將某些 newsgroups 的 articles 直接寄出來, 只要稍為加些設定, INN 也可以接受 sendmail 寄來, 所轉成的 post ( rnews and/or inews ). : 關於News的運作, News 使用者是透過News Reader軟體來讀取(Read) : 或發送 (Post) , 這類軟體可以稱之為News界面軟體或者News讀取軟體。 : 當使用者發送出一封討論信時, News Server 立刻接手處理。首先Server : 會把該封討論信放在自己的News Spool (/var/spool/news) 之下, 同時 : 在外送預備區 (通常是/var/spool/news/out.going/site 或 /var/spool : /news/out.going/site/togo) 留下一份記錄。 這裡, News Server對 : News Reader的服務是即時的, 也就是說, 以上這些流程是一瞬間完成, : 而且是連貫的。 : : 接下來就由News Transport軟體接手, 不過, News Server到News : Transport之間就不一定是即時進行, 正常的話, 負責執行傳輸的軟體 : 是由 cron 定時啟動, 之後依照/var/spool/news/out.going/site這份 : 記錄, 把News外送到下游的News Server。 照內定狀態, INN 與 C-News : 的傳輸工作都必須透過 cron 來帶動, 這是典型的批次處理模式, 至於 : 如何達到即時處理, 我之後會介紹。 關於 News server 運作原理這一段, 少了一個 batch processing 的前提, 事實上, 許多 News server 還有好幾種不同的處理方式. 一般 News server 的動作, 只有在 batch mode, 動作才是照上面的描述. 例如, 如果是透過 nntplink 等傳輸程式, 可以使用其他的 logfile mode, 甚或 channel mode (or stdin), 那麼 News server 的動作, 就和這些, 有相當 程度的差異. ( 可以參考 nntplink 的 README ) 以 INN 的 channel mode 為例, 當 nnrpd 接收到一個 post 時, 會轉而設法 將該 article 交給 innd, 然後 innd 一方面, 根據 newsfeeds 的設定, 設法將 該 article 立刻轉交給相關的 nntplink(s), 另一方面也設法, 將 這個 article 存到對應的 directory ( News Spool ). 如果搭配得當, 不會有 site and/or togo 這些 file 的產生, 除了 filing (存入 Spool) 那一次外, 不需要其它額外的 Disk I/O. 另外, 如 logfile mode, 也不會產生這一些 batch. : □ INN/C-News 擺在哪個目錄 : : 大部分情況, 我們取得INN或C-News軟體是以Source Code情況存在, 這 : 情況我們可以決定, 究竟該把Server軟體擺在檔案系統的哪裡, 筆者建議 : 如下(這建議極可能也是大部分人所採用的狀況): : : /usr/lib/news: News Server的相關設定檔案 : /usr/lib/news/bin: News Server附屬相關工具程式 這應該是許多 Linux packages 內附的 INN 的設定, 原先 INN 的 config.dist 的 default 應該是 /usr/local/news. : 另外一點, 不論選擇C-News或INN, 都要把 inews 與 rnews兩之工具 : 程式擺在PATH路徑之內, 通常是/usr/bin或/usr/local/bin, 實際上的作 : 法可以使用連結檔, 連結到INN或C-News所附的inews/rnews。 這兩支程 : 式也是News Server工具程式中, 唯一必須確定位於一般使用者通用路徑 : 中的兩支程式。 這一些, 已經比較不重要了. 目前透過 NNTP 來讀 News 已經是大勢所驅, 這些 News reader, 不管是 Unix, Dos, Windows,... 等都附有 mini-inews. 除了 e-mail post or UUCP 外, News server 上的 inews and/or rnews, 幾 乎已無用武之地. : □ INN vs C-News 用 INN or C-News, 還是有許多客觀的指標. 其中之一, C-News 發展在前, INN 在後. 現在有興趣的 user, 不妨去讀一讀 news.software.b, news.software.nntp, 這幾個 newsgroups 上的 articles, 就可以體會 大多數的話題, 都圍繞在 INN 上. : 以功能來說, INN軟體約等於C-News+NNTP1.5.11, 這兩者同樣都支援 : UUCP、NNTP及E-mail傳輸。 INN 可以做到完全即時的News交換, 對於上 : 游喂送進來的News, 可以直接在記憶體中處理, 之後直接收入News Spool : 歸檔。 對於送出的News也一樣, 它可以做到沒有停頓的立刻送到下游 : News Server。 INN 能夠如此, 是用大量系統資源換來的, 因為INN佔用 : 到較多的CPU時間與記憶體空間。 對C-News+NNTP1.5.11來說, 由於兩者 : 都沒有常駐記憶體, 所以可以相對節省CPU及記憶體的使用, 不過 C-News : 以及NNTP1.5.11 施加於硬碟的讀寫負荷遠高於INN很多。 這一段的描述, 已經大略點出, INN 和 C News 的主要的不同點. - 現在的 RAM 相對已經很便宜了, 為了 performance, 多多用 RAM, why not ? INN 主要有 innd 這一個 daemon 在主控全局. 事實上 innd 比 C-News + nntpd, 強太多了. INN 的 newsfeed檔的, 這一項設計, 幾乎可以說是相當成功的地方. 可以讓許多有創造力的管理者, 將許多外掛的 services 和 News , 相當容易的, 結合在一起. ( INN/newsfeeds vs sendmail/sendmail.cf ) : □ NNTP/UUCP/E-mail 喂送方式 : 個角落, 即時性的NNTP傳送可以達到如此。 但是假如您想讓您的線路頻 : 寬做最經濟實惠的使用, 則UUCP壓縮傳送可以達成這目標, 照筆者的測 用 UUCP 是考量頻寬的選擇之一. 只是用 UUCP 並不一定是, 廉價的. 透過 UUCP 來轉送 News, 模式基本上如下. 1) 是先作 batch, 2) 再壓縮, 3) 再傳. ( tranmission phase ) 4) 到目的地後, 再解壓縮, 5) 在 un-batch. 1), 2) 是上游 News server 所必需負擔的重任. 不要小看這些 batching, compressing 的 load, 許多額外的 Disk I/O 及額外的 CPU time, 絕對是 必要的. 從下游 News server 只處理單一個 link (batch) 當然不會覺得如何, 但是從上游 site 來看, 下游的接收 site 一多, 就很有得瞧... 另外, UUCP 是另外一套 packages, 所以除了 News 以外, 管理者還必須懂這一套. 針對這一點, 目前網路上, 也已經有人發展出, 許多 NNTP 的變形, - xbatch, 雖然是 NNTP, 但是卻是先經由 compress 之後, 再傳. 送到目的地 後, 再解壓縮. 原理和, UUCP batching, compress ,.. 等流程相似. 網路上, 可以找到這一組程式, 基本上只要 patch INN 的程式, 不需要再另外, 依賴 UUCP 等程式. - streaming NNTP, 修改目前 NNTP 的傳送模式, 單位時間內, 可以傳送更多 的 news articles. 像 innunoff2,3,4 等, 就有這一組功能. ( streaming vs pipeline ) BTW, 其實, 像現在很多公司, WWW server 也陸陸續續有建, 64k 以上的專線, 幾乎是 跑不掉的. 頻寬問題, 反而已經不是主要的考量. : INN 有一個相當不錯的FAQ (Frequently Asked Questions) 文件, 到 網路上流傳的 INN 的 FAQ, 目前已經細分為 9 個 parts. : * INN 基本配備檔介紹 [deleted] : active 定義所有Newsgroup : newsfeeds 決定本News Server所引入、 以及喂送到下游的Server ^^^^^^^^^^^^^^^^^^ 這一點是錯誤的. 曾先生的文章, 關於 INN 的 newsfeeds 中, ME 這一個 entry 的功能 的說明, 有一個嚴重的錯誤. ( 我猜, 可能是從 C News 系統上, 得來的印象 ). ME 照字面, 很容易讓人聯想到, me (英文的 我), C News 的用法, 的確 是代表, 關於本站的設定, 但是在 INN 1.4 卻不是這樣. 詳情, 可參考 INN 所附的 manual pages. ==> man newsfeeds : # newsfeeds : : newsfeeds檔案的設定, 算是INN News Server最重要的工作, 也是困 : 難度最高的部份。 newsfeeds檔案決定這部News Server要接收哪些 : newsgroup, 以及要喂送哪些newsgroup出去。 INN (innd) 決定收哪些 newsgroups 主要由 active 來決定. 不是由 newsfeeds. innd 靠 newsfeeds 來決定, 要丟 哪些 newsgroups 的 articles 給哪些 site 負責的程式 (nntplink) or 產生 batch files, 讓其它的程式來轉送. 關於, newsfeeds 這個檔, 其中, ME 這一項, 有兩個特別功能: 1) 定義所有 site, 共同的 pre-subscription list. 2) 定義, 本站所特別 care 的 distributions ( 不是 newsgroups ). - 這一個功能, 是多加一個過濾的動作, 就是在根據 active 檔的紀錄中, 接取近來的 articles, 再加以比對. 在 distribution 的範圍內, 或者沒有 distribution 限制, 就接收. 否則, 就捨棄. distribution 是一個限制流傳的功能, 不過目前一般網路上的習慣, 這一項功能, 已幾乎名存實亡. 不用的人, 比用的人, 多太多了... : ## /usr/lib/news/newsfeeds : ## ME這一行定義本Server所接收的Newsgroup, 以#開頭的為註解行, 這裡 : ## 只定義接收凡是以comp、news、tw等等開頭的newsgroup, local.test為內 : ## 部測試專用。 : ME:!*,comp.*,news.*,tw.*,local.test:: 這一套註解是錯誤的. ME 的功用, 只是做為底下各 site 的 pre-subscription list. 也就是, 這一堆 "!*,comp.*,...local.test" 會加在底下, foo1, foo2, ... 每一個 site 的接收 的 newsgroups list 之前. ( prepend ) : ## NNTP feed using 'send-nntp', foo1為本Server的上游, 這裡把相同的 : ## 東西喂送回去。 : foo1/foo1.com.tw\ : :!*,comp.*,news.*,tw.*,local.test\ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 這一個例子. 這一個 "!*" 已經將 ME 所定義的東西, 完全捨棄. (last match) ( Or, 從另一個角度看, 括起來的 string, 實際上是多餘的, 因為 ME 欄已經填了. ) : : 在這示範中, ME一行是定義自己這部News Server所接收的東西, 這 : 裡定義接收comp.*、 news.*、 tw.* 以這三個開頭的newsgroups, 另外 這一段敘述是錯誤的. 說明如上. : $ /usr/lib/news/bin/inncheck -v : Looking at /usr/lib/news/active... [delete] : Looking at /usr/lib/news/newsfeeds... : ME, foo1, foo2, /usr/lib/news/newsfeeds:0: : ME entry accepts all incoming article distributions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 請注意, 這堿O說 distributions. 像底下的例子, ME:!*/!local:: 則不接收所有, 附有 這一類 header 的 articles. Distribution: local.test
C.S.Chen [ 陳昌盛 ] * E-mail: chen@cc.nctu.edu.tw Computer Center of National Chiao-Tung University, Hsinchu, Taiwan, R.O.C.