知识管理

四个字：知识管理。

USENET在1979年末，UNIX V7公布、引进UUCP後不久诞生。由Duke University 两位研究生Tom Truscott 及Jim Ellis提出构想、用来在UNIX间交换讯息。由南加 大的Steve Bellovin设计。Steve Daniel用Ｃ程式语言重新改写，经Tom Truscott 修改後为第一个正式版本(RELEASE A)。

1981年Berkeley的研究生Mark Horton及高中生Matt Glickman重新改写，以增 加功能，并且处理日益增加的News流量。此版本为B ── B News。

在Center for Seismic Studies的Rick Adams接替维护B News的工作。在1986 年年末，B News 2.11 公布，奠定了目前USENET的规模。现在B News已经退休了， 为C News或INN所取代。

1986年三月，公布了一个新的套装程式，使用一种新的传输News的协定 Network News Transfer Protocol (NNTP) 。此协定使用TCP/IP的方法交换资料， 而非传统使用UUCP的方法。

1987年秋，C News公布。

1992年八月二十InterNetNews公布 (INN)。

目前最常用的 NEWS Server 有 CNEWS和INN。

至于新闻组中的中文发展的沉浮，可以参考这篇文档《新闻组是什么？》。

INN帮助文档中经常提到 feeder（喂食者） 和 reader（读者），也有人将其翻译为上游和下游。但是根据新闻组的架构，往往难以分清这两个角色。

对于集中控制（单一服务器）的新闻组，结构非常简单，只需要一台机器控制外部来的喂信（incoming feed）、向外部喂信（outgoing feed），建立和用户的连接，提供文章发布（posting）和阅读（reading）。缺点是存在单点故障。

分布式结构有使用共享池，文章复制等结构。参见：《INN Architecture Guide》。

当INN被设定为批处理方式进行 newsfeed的情况下， 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 传输的篇幅中, 更详细的介绍。

一个典型的新闻文章结构：头部信息、一个空行、正文部分。头部信息的每一行又是由关键字、冒号、空格和内容构成。

头信息中必须包含的有："From", "Date", "Newsgroups", "Subject", "Message-ID", 和 "Path"。可选的关键字有："Followup-To", "Expires", "Reply-To", "Sender", "References", "Control", "Distribution", "Keywords", "Summary", "Approved", "Lines", "Xref", 和 "Organization"。

From: jerry@eagle.ATT.COM (Jerry Schwarz)                     
Path: cbosgd!mhuxj!mhuxt!eagle!jerry                          
Newsgroups: news.announce                                     
Distribution: nj,ny                                           
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>                               
Date: Fri, 19 Nov 82 16:14:55 GMT
Followup-To: news.misc
Expires: Sat, 1 Jan 83 00:00:00 -0500
Organization: AT&T Bell Laboratories, Murray Hill
                                                              
The body of the message comes here, after a blank line.

	发件人的邮件地址
	文章每经过一个新闻网关，就会在最左边加上主机名，主机名之间用感叹号分隔。PATH 除了可以看出文章的转发路由外，还有一个重要功能——减少冗余。即根据PATH中的主机名，判断是否需要接收以及向下游喂信。
	新闻组名称。可以为用逗号分隔的多个新闻组名。
	传播区域，该部分为可选信息。配合头信息的新闻组（Newsgroups）设置，更有效设置新闻的转播范围。并不常用。
	格式为尖括号扩起来的字符串。字符串不能包含空格、尖括号。为符合RFC-822，字符串格式为：<unique@full_domain_name>。 Message-ID 的一个重要作用就是防止文章的重复粘贴：新来的文章和 history 对比，如果已有，则丢弃。当然还可以利用文章中 PATH 中的信息有效防止新闻转递的冗余。
	空行

INN (innd) 决定收哪些 newsgroups 主要由 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 配置文件有四个域, 各域间以一个空格为间隔, 注意, 最后的域(也就是flags)之后没有空格。 最后的flags域, 最常见者为y 与 m，如下：

检验 active 文件正确性的方法：

$ inncheck
$ scanspool

news.daily 应该以 news 管理员身份运行，而不是以 root 用户运行。它能完成：状态报告，删除过期文章，日志文件处理，处理active文件等功能。

通常在 crontab 中建立 news.daily 的调用。如果要在一天内多次运行，应该加上 norotate 参数，避免日志文件过快的回滚。

命令格式：news.daily 参数...

inn.conf - Configuration data for InterNetNews programs

修改文件etc/inn.conf，修改之处已经加亮显示：

##  $Id$
##
##  inn.conf -- INN configuration data
##
##  Format:
##      <parameter>:<whitespace><value>
##
##  Blank values are allowed for certain parameters.
##
##  See the inn.conf(5) man page for a full description of each of these
##  options.  This sample file is divided into two sections; first, there
##  are the parameters that must be set (or should be set in nearly all
##  cases), and then all parameters are given with their defaults for
##  reference in the same order and with the same organization as the
##  inn.conf(5) documentation.

# The following parameters are most likely to need setting, although the
# defaults generated by configure may be reasonable.

mta:                    /usr/sbin/sendmail -oi -oem %s
organization:           Unknown   
ovmethod:               tradindexed
pathhost:               news
pathnews:               /usr/local/news

# General Settings

domain:			worldhello.net
innflags:
mailcmd:                /usr/local/news/bin/innmail
server:

# Feed Configuration

artcutoff:              60
bindaddress:
hiscachesize:           256   
ignorenewsgroups:       false
immediatecancel:        false
linecountfuzz:          0
maxartsize:             500000
maxconnections:         50
pathalias:
pgpverify:              false
port:                   119
refusecybercancels:     false
remembertrash:          true
sourceaddress:
usecontrolchan:         false
verifycancels:          false
wanttrash:              false
wipcheck:               5
wipexpire:              10

# Article Storage

cnfscheckfudgesize:     0
enableoverview:         true
groupbaseexpiry:        true
mergetogroups:          false
overcachesize:          15
ovgrouppat:
storeonxref:            false
useoverchan:            false
wireformat:             false
xrefslave:              false

# Reading

allownewnews:           true
articlemmap:            false
clienttimeout:          600
nnrpdcheckart:          true
nnrpperlauth:           false
nnrppythonauth:         false
noreader:               false
readerswhenstopped:     false
readertrack:            false

# Reading -- Keyword Support
#
# Enabling this without stopping innd and deleting the existing overview
# database and adding will probably confuse a lot of things.  You must
# have compiled this support in too.

keywords:               false
keyartlimit:            100000
keylimit:               512
keymaxwords:            250

# Posting

addnntppostingdate:     true
addnntppostinghost:     true
checkincludedtext:      false
complaints:
fromhost:
localmaxartsize:        500000
moderatormailer:
nnrpdauthsender:        false
nnrpdposthost:                
nnrpdpostport:          119
spoolfirst:             false
strippostcc:            false

# Posting -- Exponential Backoff

backoffauth:            false
backoffdb:
backoffk:               1
backoffpostfast:        0
backoffpostslow:        1
backofftrigger:         10000

# Monitoring

doinnwatch:             true
innwatchbatchspace:     800
innwatchlibspace:       25000
innwatchloload:         1000
innwatchhiload:         2000
innwatchpauseload:      1500
innwatchsleeptime:      600
innwatchspoolnodes:     200
innwatchspoolspace:     8000

# Logging

docnfsstat:             false
logartsize:             true
logcancelcomm:          false
logcycles:              3
logipaddr:              true
logsitename:            true
nnrpdoverstats:         false
nntpactsync:            200
nntplinklog:            false
status:                 0
timer:                  0

# System Tuning

badiocount:             5
blockbackoff:           120
chaninacttime:          600
chanretrytime:          300
icdsynccount:           10
maxforks:               10
nicekids:               4
nicenewnews:            0
nicennrpd:              0
pauseretrytime:         300
peertimeout:            3600
rlimitnofile:           -1

# Paths

patharchive:            /usr/local/news/spool/archive
patharticles:           /usr/local/news/spool/articles
pathbin:                /usr/local/news/bin
pathcontrol:            /usr/local/news/bin/control
pathdb:                 /usr/local/news/db
pathetc:                /usr/local/news/etc
pathfilter:             /usr/local/news/bin/filter
pathhttp:               /usr/local/news/log
pathincoming:           /usr/local/news/spool/incoming
pathlog:                /usr/local/news/log
pathoutgoing:           /usr/local/news/spool/outgoing
pathoverview:           /usr/local/news/spool/overview
pathrun:                /usr/local/news/run
pathspool:              /usr/local/news/spool
pathtmp:                /usr/local/news/tmp

	Set this to the name of your organization as you want it to appear in the Organization: header of all articles posted locally and not already containing that header. This will be overridden by the value of the ORGANIZATION environment variable (if it exists). If neither this parameter nor the environment variable or set, no Organization: header will be added to posts which lack one.
	The amount of memory (in kilobytes) to allocate for a cache of recently used history file entries. Setting this to 0 disables history caching. History caching can greatly increase the number of articles per second that your server is capable of processing. A value of 256 is a good default choice.

配置文件：/etc/readers.conf ，被程序 nnrpd 用来进行权限控制。控制谁可以连接新闻服务器以及用户的访问权限。

配置文件中有两种不同的配置组组成：auth 和 access。auth 组用来判定用户身份——是谁？ access 组用来判定用户的权限——能干什么？

如何将 auth 和 access 配置组联系在一起呢？首先遍历所有的 auth 配置组，最后一个匹配的 auth 配置组负责分配一个标识，通常（参见下面的例子）通过 auth 配置组中的 default 和 default-domain 组合成形如 default@default-domain 的 ID 标识。这个标识去和 access 配置组的 users 去匹配。匹配通过，则分配 access 配置组中相应的权限。

对如下的 auth 配置组：

auth <name> {
    hosts: <host-wildmat>
    auth: <auth-program>
    res: <res-program>
    default: <defuser>
    default-domain: <defdomain>
    # ...possibly other settings
}

如果定义了 "res: <res-program>"，则用程序 res-program 检查用户的连接信息，如果返回一个 用户名（不带 @ 字符），则 auth 配置组返回的标识为 用户名@<defdomain>；如果带 @ 字符，则直接返回 res-program 的返回值；如果 res-program 返回 false 或者根本没有定义 res 参数，则返回 <defuser>@<defdomain>

如果用户连接之后，发出认证的命令（AUTHINFO USER/PASS commands），则用户名和口令传递给程序 <auth-program>，如果定义了 auth 参数的话。 <auth-program>认证通过，则返回新的用户标识，即用户提供的用户名，而不再使用 <defuser> 名称。

如果有多个 auth 配置组，则最后一个匹配用户连接状态或者认证状态的配置组才是最终起作用的。

然后进行第二个步骤，用获得的唯一用户标识去和各个 access 配置组匹配。一个 access 配置组如下：

access <name> {
    users: <identity-wildmat>
    newsgroups: <group-wildmat>
    # ...possibly other settings
}

同样 access 后面的 <name> 除了可视之外，没有其它用途。起作用的是 users 参数，它的值用来匹配 auth 配置组返回的用户标识，如果匹配则具有该 access 配置组赋予的相应权限。同样对于多个 access 配置组，类似的最后一个匹配的 access 配置组起作用。

在权限设置复杂的情况下，还可以通过 auth 配置组中的 key 字段，限制匹配范围。即只去检查具有相通 key 字段的 access 配置组，如果 auth 配置组返回的用户标识和对应的 access 配置组的 key 匹配，则分配相应 access 组定义的权限。

	参见 MAN 手册： readers.conf(5), ckpasswd(1)

受控新闻组（Moderated Groups）就如同受控邮件列表一样，不允许用户直接发表文章，而是转发到管理员，由管理员审核后，再次发布到新闻组中，从而实现受控新闻。

受控新闻组，约定俗成的名字为：group_name.mod ，但这不是强制的。

管理员的邮件地址列在 moderators 文件中。

受控新闻参见：NetNews Moderator's Handbook。

撤销和管理文章，实际上是再次发表带有控制信息的文章，服务器根据其包含的控制信息进行相应动作。

显而易见的问题是，如何确定控制信息不是伪造的？

最广泛使用的方法是：将发信人的邮件地址列在 control.ctl 文件中，定义哪些用户是可以信任的，哪些用户不能信任（忽略其控制信息）。

control.ctl 示例：

## -------------------------------------------------------------------------
##      DEFAULT
## -------------------------------------------------------------------------

# Default to dropping control messages that aren't recognized to allow
# people to experiment without inadvertently mailbombing news admins.
all:*:*:drop

## -------------------------------------------------------------------------
##      CHECKGROUPS MESSAGES
## -------------------------------------------------------------------------
# Default to mailing all checkgroups messages to the administrator.
checkgroups:*:*:mail

## -------------------------------------------------------------------------
##      NEWGROUP/RMGROUP MESSAGES
## -------------------------------------------------------------------------

## Default (for any group)
newgroup:*:*:mail
rmgroup:*:*:mail

参见：News Groups Maintenance

配置文件 incoming.conf，用来控制来自外部的喂信（incoming feed）；配置文件 newsfeeds，用来控制本服务器向外部的喂信（outgoing feed）。

streaming:              true   # streaming allowed by default
max-connections:        8      # per feed

peer ME {
  hostname:         "localhost, 127.0.0.1"
}

ME:!*/!local,!collabra-internal::

    peer remote.example.com {
        patterns: "*, @local.*"
        hostname: "remote.example.com, news.example.com"
    }

4.11.3. 向外喂信

由配置文件newsfeeds控制。newsfeeds档案的设定, 算是INN News Server最重要的工作, 也是困难度最高的部份。 innd 靠 newsfeeds 来决定要丢哪些 newsgroups 的 articles 给哪些 site 负责的程序 (nntplink) 或产生批处理, 让其它的程序来转送。

INN newsfeeds档案至少必须定义自己（ME）以及一个喂送下游 Server。

该文件由一系列 feed 项构成。每一个配置项由四个部分构成，用冒号分开。

sitename[/exclude,exclude,...]\                   
     :pattern,pattern...[/distrib,distrib...]\    
     :flag,flag...\                               
     :param                                       

	第一个部分格式为：唯一地址名和排除列表 唯一地址名一般配置成远程的主机名，从而保障了名字的唯一性。名称之后的排除列表是可选项，可以在地址名后面跟一个斜线和逗号分隔的排除列表。如果该地址名出现在文章头信息的 PATH 部分，则文章将不被传递。同样，如果文章的PATH部分包含排除列表中的名称，则该文章也不再需要处理。 要确定 sitename 和 排除列表很容易，只要分析远程主机的新闻的文件头即可。合理配置，可以有效防止文章的重复粘贴。
	此部分定义需要处理的新闻组列表，可以看做是该地址订阅的新闻组列表。其中的 distribution-list 是可选项，可以用来进一步和文章头部的 Distribution 项匹配，但并不常用。
	标志位。常见的标志位有： T? 用于定义传送方式。传送新闻基本上都牵涉两类程式在配合。 a) innd 整理 (根据 newsfeeds) 往外丢的资讯, 以 file, channel, log, funnel, program 等几种型式呈现. ( innd 有时也整理提供一些 local, 不外传的资讯, 如 overchan, ..); b) 不同的传送程式, 撷取不同的资讯, 将 news articles 往外传。 Tf File mode: 前者写一个 batch file (per site), 後者事後再根据这一个 batch file, 取出必要的资讯, 往外传 articles. 如 nntpsend/innxmit。最后一个域param，为文件名。 Tl Log entry: innd 每收到一篇 article, 都会有一笔 log (/var/log/news/news), 其中记有哪一些 site (all), 要这一篇 articles, 然後对应的程式, 可以到这个 log, 取出所要的资讯. 目前最常见的程式 nntplink (log mode), 假设可能有□N 个下游站(但所要的 newsgroups, 不见得相同), 用这个方式, 就会有 N 个程式被跑起来, 都根据同一个 log file, 来传送. Tm Funnel mode: 漏斗方式。是前两者的折衷. 如果下游站多, 待外传的 articles 量多, 使用 file mode 使 disk I/O 太多,(每一个 site 个别运作. ) 使用 log mode 可能又效率不高. funnel mode 通常都需配合 exploder 程式来运作。 funnel(漏斗) file: 把好几个 out.going 的资讯, 汇集成一个 file. exploder 程式, 将 funnel file, "展开", 取出必要的资讯,往各别站传. Tc 前面三种, (a) 和 (b) 是分开 run 的程式。 channel(通道) mode, 则是 两者同时在跑. OS 上列的 concurrent processes, (想像一下, Unix 上 pipeline 程式组的运作方式)。目前比较常见的, 就是 innd (channel mode) 配 nntplink (stdin). Tp 程序模式。类似于 Channel 模式, 不过是 one-shot mode. 理论上 channel mode, (a) 和 (b) 一直跑. 但 program mode, 只有在一篇 articles 进来时, innd 才会去 fork 一个 (b) 的程式来处里, 之後, (b) 自动结束, 就 exit. W？ 通过文件、通道等喂信，这个标记用来确定写入什么信息。
	第四部分作为参数传递，根据第三部分的选项，而有不同意义。如：对于 文件方式的feed（file feeds，Tf），本部分为相应的文件名；对于漏洞方式（funnel feeds，Tm）方式，则为某一已经定义的 feed 配置项；对于 channel feeds (Tc)，本部分则是要运行的相应的处理程序。

ME:!*/!local,!collabra-internal::

配置项 ME，是必不可少的一个配置项，有着特殊作用。其 newsgroup pattern 部分（本例为“!*”），将加到所有其它的配置项的 newsgroup pattern 的前面，定义了确省的向外喂信的新闻组列表。亦即定义所有 site, 共同的 pre-subscription list。

而其 distribution pattern 则通过匹配文章头部的 Distribution 域，确定允许接收哪些文章。不过distribution 作为一个限制流传的功能, 很少有人用，已几乎名存实亡。

remote.example.com/news.example.com\
    :<newsgroups>\
    :Tf,Wnm:

这条配置项，将对匹配的文章的 Message-ID, storage token 写入文件 ~news/spool/outgoing/remote.example.com。crontab 中的配置将会定期根据文件外发数据。

    innfeed!\
        :!*\
        :Tc,Wnm*:/usr/local/news/bin/startinnfeed -y

    remote.example.com/news.example.com\
        :<newsgroups>\
        :Tm:innfeed!

funnel feed 示例，注意 innfeed 后面的感叹号。

上例采用 innfeed 向外部服务器 remote.example.com 喂信。正确运行 innfeed 还需要配置文件 innfeed.conf。

对于如何管理文章的存储方式，有四种存储方法，可供选择。

配置文件 storage.conf ：用来配置存储方式。

该配置文件由一个或多个存储配置规则构成。

method <methodname> {                           
     class: <storage_class>                     
     newsgroups: <wildmat>                      
     size: <minsize>[,<maxsize>]
     expires: <mintime>[,<maxtime>]
     options: <options>
}

	下列可用的存储方式的一种：timecaf, timehash, cnfs, tradspool 和 trash。对于符合该规则的新闻组使用该储存方式。
	该存储配置规则的 ID。在整个配置文件中保持唯一的一个数字。这个 ID 被配置文件 expire.ctl 文件引用，对该存储规则设置过期策略。
	用来匹配新闻组名。如果 inn.conf 中配置了 storeonxref: true，则和文章 header 中的 Xref 去匹配；否则（确省情况），和文章 header 中的Newsgroups匹配。

inncheck 检查的文件有：

active
control.ctl
expire.ctl
incoming.conf
inn.conf
moderators
newsfeeds
overview.fmt
nntpsend.ctl
passwd.nntp

inncheck -v 显示了检查的相近过程：

$ inncheck -v
Looking at /usr/local/news/db/active...
Looking at /usr/local/news/etc/control.ctl...
Looking at /usr/local/news/etc/expire.ctl...
Looking at /usr/local/news/etc/incoming.conf...
Looking at /usr/local/news/etc/inn.conf...
Looking at /usr/local/news/etc/moderators...
Looking at /usr/local/news/etc/newsfeeds...
ME, done.
Looking at /usr/local/news/etc/nntpsend.ctl...
Looking at /usr/local/news/etc/overview.fmt...
Looking at /usr/local/news/etc/passwd.nntp...
Looking at /usr/local/news/etc/readers.conf...

$ ctlinnd newgroup local.announce        y johnson.AT.worldhello.net
$ ctlinnd newgroup local.test            y johnson.AT.worldhello.net

... 修改文件 newsgroups ...
$ cat >> db/newsgroups << EOF
local.announce          Announcement for all.
local.test              For newbie test.
EOF

或者

$ ctlinnd pause 'edit active'
$ vi active
$ inncheck -v active
$ ctlinnd reload 'edit active'
$ ctlinnd go 'edit active'

... 修改文件 newsgroups ...

如果只有一两个 newsgroups 要砍, 可直接执行 ctlinnd rmgroup <group-name> 来砍, 如果一次有好几百个 newsgroups 要砍, 请依照以下步骤:

$ ctlinnd pause "removing idle newsgroups"
... 改动 active 文件，删除相应的行
$ ctlinnd reload active "removing idle newsgroups"
$ ctlinnd go "removing idle newsgroups"

待续...

inn 提供的 perl 脚本 —— mailpost，可以完成邮件到新闻组的转换。配置方法：

inn 提供的 perl 脚本 —— news2mail，可以将新闻组文章以邮件方式转发。

new2mail 通过在配置文件 newsfeeds 中，添加相应的 channel feed 实现。还有一个重要的配置文件 news2mail.cf，用来和相应的 channel feed 的地址名匹配，提供相应的邮件地址。

例如：下面的示例，将新闻组：internal.list.linux.kernel ，发往邮件地址：linux-kernel@vger.kernel.org 。

new2mail 为防止DOS攻击，将邮件排入队列，而不是直接发送。因此邮件发送是否及时，由 sendmail 启动时的 -q 参数决定，或者将 "sendmail -q" 放入 crontab。 但是我在调试过程中，发现以参数 "-odq" 调用 sendmail，邮件队列中没有邮件，邮件发送失败！因此需要修改脚本 news2mail，修改调用 sendmail 的参数。

还有在调试 news2mail 过程中，发现 perl 脚本的 syslog 调用并不能出现预期结果。原因是 syslogd 启动时默认不接收外部的 syslog 事件，导致 perl 的 syslog 调用不能显示。修改文件 /etc/sysconfig/syslog，加上 '-r' 参数启动 syslogd。

参见：FAQ News2Mail and Mail2News Gateway。