
大體上, 這一篇文章, 對 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
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  請注意, 這裏是說 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.

