9. 运行系统的组件

9.1. /var/lib/news：CNews 控制区域

此目录更广为人知的是 $NEWSCTL。它包含配置、日志和状态文件。这里不存放文章或二进制文件。让我们看看其中一些文件的用途。控制文件在 "第 4.3 节>" 中有更详细的介绍。

• sys：每行一个系统/NDN，列出每个系统订阅的所有新闻组层级。每行都以系统名称为前缀，以 ME: 开头的行表示我们将要接收的内容。查阅以下命令的手册页：newssys.

• explist：此文件包含条目，指示哪些新闻组的文章何时过期，以及是否需要存档。新闻组的列出顺序很重要。请参阅以下命令的手册页：expire以了解文件格式。

• batchparms：此处指定了如何向其他站点/NDN 馈送的详细信息，例如批处理的大小、传输模式（UUCP/NNTP）。要参考的手册页：newsbatch.

• controlperm：如果您希望在对控制消息执行任何操作之前对其进行身份验证，则必须在此处输入与身份验证相关的信息。controlperm手册页将详细列出所有字段。

• mailpaths：它包含每个审核新闻组的版主的电子邮件地址，版主负责批准/不批准发布到审核新闻组的文章。在mailpaths文件中的示例tar将让您了解如何创建条目。

• nntp_access/user_access：这些文件包含服务器名称和用户名条目，当访问新闻组时，限制将应用于他们。同样，tarball 中的示例文件应解释文件的格式。

• log, errlog：这些是日志文件，随着接收的每个批处理而不断增大。log文件包含每个文章的条目，告诉您它是否已被您的新闻服务器接受或拒绝。要了解此文件的格式，请参考CNews指南的第 2.2 章。消化文章时发生的任何错误都记录在errlog中。这些日志文件必须滚动，因为这些文件会占用大量磁盘空间。

• nntplog：此文件记录nntpd的信息，提供有关何时建立/断开连接以及发出了哪些命令的详细信息。此文件需要在syslog 中配置，并且syslogd

• active：此文件每行一个新闻组，列出您的新闻服务器中要找到的新闻组。除了其他内容外，它还告诉您每个新闻组中当前存在的文章数量。它在每次消化批处理或文章过期时更新。active手册页将提供有关其他参数的更多详细信息。

• history：此文件也包含每个文章一行，将message-id映射到新闻组名称，并给出其在该新闻组中的关联文章编号。它在每次消化馈送以及doexpire运行时更新。在循环检测中起关键作用，并充当文章数据库。阅读newsdb, doexpire的手册页以了解文件格式。

• newsgroups：它对每个新闻组都有一行描述，解释了每种新闻组中包含哪些类型的帖子。理想情况下，它应该涵盖active文件中找到的所有新闻组。

• 杂项文件：诸如mailname, organisation, whoami之类的文件包含形成文章某些标头所需的信息。mailname形成From标头的内容，以及organisation形成Organisation标头的内容。whoami包含新闻系统名称。请参阅guide.ps的第 2.1 章，以获取$NEWSCTL区域中文件的详细列表。阅读RFC 1036以了解文章标头的描述。

9.2. /var/spool/news：文章存储库

这也称为$NEWSARTS或$NEWSSPOOL目录。这是文章驻留在您的磁盘上的位置。二进制文件或控制文件不应属于此处。应为此目录分配足够的空间，因为文章数量随着消化的每个批处理而不断增加。以下子目录的解释将使您对此目录有一个概览。

• in.coming：来自 NDN 的馈送/批处理/文章在到达时以及在处理之前都驻留在此目录中。处理后，它们会出现在$NEWSARTS中或其bad子目录中（如果存在错误）。

• out.going：此目录包含要发送到您的 NDN 的批处理/馈送，即要推送到您邻近站点的馈送在传输之前驻留在此处。它为sys文件中提到的每个 NDN 包含一个子目录。这些子目录包含名为togo的文件，这些文件包含有关文章的信息，例如message-id或排队等待传输的文章编号。

• >新闻组目录：对于新闻服务器订阅的每个新闻组层级，都会在$NEWSARTS下创建一个目录。在父目录下创建进一步的子目录，以保存特定新闻组的文章。例如，对于像comp.music.compose这样的新闻组，父目录comp将出现在$NEWSARTS中，并且在下将创建一个名为musiccomp的子目录。下将创建一个名为子目录应包含一个名为compose的进一步子目录，并且comp.music.compose的所有文章都应驻留在此处。实际上，新闻组comp.music.compose的文章 242 应映射到文件$NEWSARTS/comp/music/compose/242.

• control：control 目录仅存放此站点收到的控制消息。控制消息可以是以下任何一种：newgroup、rmgroup、checkgroup和cancel出现在文章的主题行中。更多信息请参见 "第 2.4 节>"

• junk：junk目录包含新闻服务器已接收并在处理后确定不属于其订阅的任何层级的文章。新闻服务器将此目录中的所有文章传输/传递给订阅了junk层级的 NDN。

9.3. /usr/lib/newsbin：可执行文件

稍后添加

9.4. crontab 和 cron 任务

Usenet 新闻服务器的核心是在固定时间间隔运行的各种脚本，这些脚本处理文章、消化/拒绝文章并将文章传输到 NDN。我将尝试列举足够重要以至于需要 cron 的脚本。 :)

• newsrun：关键脚本。此脚本选取in.coming目录中的批处理，如有必要，对其进行解压缩，并将其馈送到relaynews，然后 relaynews 处理每篇文章，消化和批处理文章，并记录任何错误。此脚本需要通过cron运行，频率取决于您希望消化馈送的频率。对于非关键需求，每半小时应该足够了。

• sendbatches：运行此脚本以将togo目录中形成的out.going文件传输到您的 NDN。它读取batchparms文件以确切了解如何以及向谁传输批处理。频率也可以根据您的需求设置。每小时一次应该足够了。

• newsdaily：此脚本执行维护任务，例如滚动日志并保存日志、报告错误/异常以及执行清理作业。它通常应每天运行一次。

• newswatch：此脚本比 newsdaily 更详细地查找新闻问题，例如查找持久锁定文件或无人值守的批处理、确定空间短缺问题等。此脚本通常应每小时运行一次。有关此脚本和上述脚本的更多信息，请阅读newsmaint手册页。

• doexpire：此脚本根据控制文件explist中的设置使旧文章过期，并更新active文件。如果您不希望不必要/不需要的文章占用您的磁盘空间，则这是必要的。每天运行一次。手册页expire

• newsrunning off/on：此脚本为您关闭/启动新闻服务器。如果您认为新闻服务器在高峰时段占用大量 CPU 时间，并且希望对其进行检查，则可以选择将其添加到您的 cron 任务中。

9.5. newsrun和relaynews：消化接收到的文章

Usenet 新闻系统的核心和灵魂，newsrun只是拾取in.coming目录的$NEWSARTS中的批处理/文章，并解压缩它们（如果需要），然后调用relaynews。它应该从 cron 运行。

relaynews通过stdin逐个拾取每篇文章，通过查找sys文件来确定它是否属于订阅组，在history文件中查找以确定它是否已在本地存在，消化它，更新active和history文件，并将其批处理以供邻近站点使用。在处理文章时遇到问题时记录错误，如果碰巧是控制消息，则采取适当的措施。更多信息请参见relaynews.

9.6. doexpire和expire的手册页：删除旧文章

从$NEWSARTS区域中删除不需要/旧文章的好方法是每天运行一次doexpire。它从explist目录中读取$NEWSCTL文件，以确定今天哪些文章过期。如果配置了，它可以存档所述文章。然后，它会相应地更新active和history文件。如果您希望在history文件中保留文章条目，以避免在文章过期后将其作为新文章重新消化，请在控制文件中添加特殊的 /expired/; 行。有关选项和功能的更多信息，请参阅expire手册页。

9.7. nntpd和msgidd：管理 NNTP 接口

正如在关于设置软件的章节中已经讨论过的，nntpd是一个基于 TCP 的服务器守护程序，在inetd下运行。当 NNTP 端口上有传入连接时，它由inetd触发，并从那里接管对话。它读取$NEWSCTL中的 C-News 配置和数据文件，来自$NEWSARTS>的文章文件，并接收传入的帖子和传输。它忠实地将这些排队到$NEWSARTS/in.coming中，无论是作为批处理文件还是单个文章文件。

重要的是将inetd配置为以用户nntpdnews而不是root身份触发，就像它对其他守护程序（如telnetd或ftpd）所做的那样。如果未正确完成此操作，则可能会在以后导致 C-News 系统功能出现许多问题。

nntpd每次收到新的 NNTP 连接时都会触发nntpd，并在 NNTP 客户端关闭其连接后立即终止。因此，如果一个通过传入的批处理馈送（不是POST而是XFERnntpd）接收了一些文章，则另一个nntpd直到批处理被消化后才会知道这些文章的接收情况。如果多个上游 NDN 通过 NNTP 向我们的服务器馈送同一组文章，这将妨碍重复的新闻馈送检测。为了解决这个问题，msgidd使用了一个盟友，消息 ID 守护程序。此守护程序在服务器启动时通过newsboot$NEWSCTL触发一次，并在后台静默运行，在nntpd区域中的命名 Unix 套接字上监听。它在其内存中保存了各种

实例要求其记住的所有消息 ID 的列表。nntpd因此，当一个msgidd副本接收到传入的新闻文章馈送时，它会通过 Unix 套接字使用这些消息的消息 ID 更新nntpd。当稍后触发另一个nntpd，并且 NNTP 客户端尝试向其馈送更多文章时，msgidd会针对msgidd检查每个消息 ID。由于

将所有这些 ID 存储在内存中，因此查找速度非常快，并且重复的文章在 NNTP 接口本身就被阻止了。nntpd在运行的系统上，预计对于每个活动的 NNTP 连接，都会看到一个msgidd实例，并且只有一个nntpd实例在后台静默运行，几乎不消耗任何 CPU 资源。我们的nntpd配置为在 NNTP 连接空闲超过几分钟时终止，从而节省服务器资源。这不会给用户带来不便，因为现代 NNTP 客户端只需重新连接。如果发现

9.8. 实例运行了数天，则要么是由于网络错误而挂起，要么是从您的上游服务器接收非常长的传入 NNTP 馈送。我们过去每天通过持续 18 到 20 小时不间断的 NNTP 会话从我们的服务提供商那里接收主要传入馈送。nov

，新闻概述系统From, NOV，新闻概述系统是 C-News 和 NNTP 系统以及 NNTP 协议的最新增强功能。此子系统为每个活动新闻组维护一个文件，其中为当前每篇文章维护一行。此行文本包含有关文章的一些关键元数据，例如, SubjectDate实例运行了数天，则要么是由于网络错误而挂起，要么是从您的上游服务器接收非常长的传入 NNTP 馈送。我们过去每天通过持续 18 到 20 小时不间断的 NNTP 会话从我们的服务提供商那里接收主要传入馈送。的内容以及文章大小和消息 ID。这大大加快了 NNTP 响应。nntpd库已集成到

代码以及 C-News 的关键二进制文件中，从而在从存储库添加或删除文章时提供新闻概述数据库的无缝维护。newsrun当向starcom.test添加文章时，它还会更新$NEWSARTS/starcom/test/.overviewnntpd，并在其中添加一行包含相关数据（制表符分隔）的行。当与 NNTP 客户端一起启动并看到XOVERNNTP 命令时，它会读取此.overviewexpire文件，并将相关行返回给 NNTP 客户端。当NNTP 命令时，它会读取此删除文章时，它也会从

文件中删除相应的行。因此，NOV 数据库的维护是无缝的。

9.9. 使用 UUCP 和 NNTP 批处理馈送