开源新闻组软件 INN 在 Ubuntu 上的安装配置指南1. 项目概述为什么都 2025 年了还要装 INN我最近在一台 Ubuntu 22.04 服务器上完整部署了一次 INNInterNetNews也就是经典的 Usenet 新闻组服务器软件。这东西在国内确实冷门网上的中文教程要么是十几年前的古董帖要么只是简单地apt install inn2就完事了完全没有把权限控制、存储策略、消息投递这些核心环节讲清楚。我这次趁着部署机会把整个流程完整跑了一遍也踩了不少坑所以干脆整理成一篇能直接照着做的教程。INN 是什么简单说它就是互联网新闻组服务NNTP的服务端实现1991 年由 Rich Salz 在伯克利大学开发后来由 ISCInternet Systems Consortium维护。它的核心作用有两块第一作为新闻组服务器接收和存储文章第二通过 NNTP 协议向客户端提供阅读和投递服务。放到今天的场景它依然在一些企业内部论坛、技术社区镜像站、教育实验环境、离线消息分发系统里发挥作用因为 NNTP 协议本身就支持主动推送和增量同步非常适合做低带宽环境下的多节点内容复制。我这次部署就是给一个内部技术论坛做离线同步源要求稳定、干净、可控。这篇文章适合谁看如果你是运维工程师、自建服务的爱好者或者正在研究 NNTP 协议和 Usenet 生态想在 Ubuntu 上跑一个真正能用的新闻组服务那这篇就是为你准备的。我会从安装方式的选择开始讲一直讲到配置文件逐段拆解、踩坑排查确保你看完之后能独立部署出一套可以对外提供服务的 INN 实例。有一点先说明INN 的官方文档和配置文件注释都是英文的术语也比较老派比如“expire”表示过期清理、“feeds”表示消息投递关系阅读时需要一点耐心。但只要你理解了它背后的几个核心概念整个配置其实并不复杂我就是按“先懂原理再动配置最后调试”的顺序带你走一遍。2. 核心概念解析INN 的架构和关键技术点在动手敲命令之前我建议先花几分钟搞清楚 INN 的架构。如果你直接去看/etc/news下面那一堆配置文件很容易被吓住。其实 INN 就是由几个分工明确的组件构成的理解每个组件干什么配置起来顺理成章。2.1 核心组件拆解INN 的主要组件包括innd守护进程负责接收外来文章、本地投递和管理存储后端是 INN 的核心。nnrpd面向客户端的服务进程处理读者reader clients的 NNTP 连接、登录认证、文章读取和投递。它是由 innd 按需拉起的子进程。controlchan处理控制消息control messages比如newgroup、rmgroup、cancel这些管理指令。expire和expireover负责文章过期清理和概览overview数据库维护。actived维护活动列表active file记录当前服务器上有哪些新闻组及各组状态。这些组件通过一套配置和运行目录协同工作。Ubuntu 上安装后主要路径我整理如下路径作用/etc/news/所有配置文件所在目录/var/lib/news/运行时数据包括 active 文件、历史数据库/var/spool/news/文章存储目录按新闻组分层/var/log/news/日志文件所在目录/usr/lib/news/bin/INN 自带的一些辅助脚本和二进制工具注意 Ubuntu 上 INN 运行的用户是news所以上述目录属主几乎都是 news操作时需要留意权限别没事就去chown给 root后面会引发写入失败的问题。2.2 INN 的运行机制INN 被设计为持续运行的常驻服务启动后innd监听 119 端口默认通过nnrpd处理客户端连接。处理一条投递请求的链路大致是这样客户端或上游新闻组服务器发起 NNTP 连接发送POST请求。innd接受连接后将文章写入存储后端。文章写入成功后INN 更新历史数据库和概览数据库。如果配置了转发newsfeedsinnd 会按照 feeds 规则将文章同步给下游服务器或写入文件输出。这个链路保证了文章从接收到存储、再到分发的一整套流程是解耦的接收和投递相互独立读操作由 nnrpd 处理写操作由 innd 处理二者之间通过 buffer 和日志保持一致。很多初次接触的人会混淆inn.conf和readers.conf的关系。其实记住一条就够了inn.conf定义服务器自身行为和全局参数readers.conf认的是“谁能读、谁能写”newsfeeds管的是“文章往哪送、怎么送”。2.3 存储后端的选型INN 支持多种存储方法常见的是timecaf、cnfs和trash。我推荐使用timecaf因为它按时间分片存储文章结合 CNFSCyclic News File System的循环写入特性在大规模场景下性能好、清理方便。对于大多数中小规模部署timecaf已经足够。在storage.conf中我为所有新闻组配置了一个默认存储方法Method timecaf { newsgroups: * class: 0 storageapi: 2 }timecaf把文章按照到达时间写入timecaf目录下的分片文件配合cnfs的循环缓冲区用法可以避免单文件无限增长。如果你文章量不大日新增几千篇以内timecaf加默认的expire策略完全够用。如果你有超大流量需求再考虑调整存储策略后面我会专门讲参数取舍。3. 安装向导Ubuntu 上两种安装方式对比INN 在 Ubuntu 上的安装无非两条路线apt 安装和源码编译。我强烈建议普通场景直接选择 apt因为 Ubuntu 的inn2软件包维护得还算及时依赖也都给你处理好十来秒就装完了。源码编译适合需要定制特性比如启用 IPv6 、嵌入特殊认证模块或者想研究源码的场景但也意味着你要自己解决openssl、libdb、perl模块等一堆依赖。下面我把两条路都写清楚。3.1 方式一apt 安装推荐sudo apt update sudo apt install inn2 -y安装完成后INN 会自动创建news用户和相关目录。安装过程中debconf 可能会询问你是否要自动生成配置文件一般选“是”。装完后可以通过以下命令确认服务状态sudo systemctl status inn2如果提示找不到服务先检查是否已经启动了innd进程ps aux | grep inndUbuntu 的inn2包安装后并不会默认开机启动需要手动 enablesudo systemctl enable inn2这个细节很多教程没提我第一次装完发现重启后服务没起来查了半天才发现是这个原因。3.2 方式二源码编译安装进阶如果你确实需要源码安装可以先安装依赖sudo apt install build-essential libssl-dev libdb-dev libkrb5-dev libtool autoconf然后从官方仓库拉取源码git clone https://github.com/InterNetNews/inn cd inn ./configure --prefix/usr/local/news --with-openssl make -j$(nproc) sudo make install源码安装的默认路径是/usr/local/news和 apt 安装的/etc/news不一样之后配置路径跟着变容易搞混。这也再次说明没有特别需求的话先乖乖用 apt省下的时间够你喝一杯咖啡。套用一句我常对同事说的话“用默认的、成熟的、被打包好的版本是减少故障率的第一步。”INN 不是那种你需要追新版本来获得神奇功能的软件稳定运行比什么都重要。3.3 安装后的初始目录调整安装完成后我建议先做一次目录盘点ls -la /etc/news ls -la /var/lib/news ls -la /var/spool/news如果发现spool/news下缺少news子目录需要手动创建并设置属主sudo mkdir -p /var/spool/news/timecaf sudo chown -R news:news /var/spool/news这一步如果遗漏后面 innd 启动时会一直报“cannot mkdir”之类的错误因为 news 用户没有权限在 spool 根目录下创建自己需要的目录结构。4. 配置文件逐段详解从 inn.conf 到 readers.confINN 的核心配置都集中在/etc/news/平时最需要关注的是inn.conf、storage.conf、readers.conf、newsfeeds这几个文件。我一个个讲每段都配解释方便你“抄作业”。4.1 inn.conf定义服务器的“性格”inn.conf是 INN 的总配置文件里面的注释非常完整几乎每个参数都有说明。我用的是如下核心配置organization: Example News server: news.example.com pathalias: /usr/lib/news/bin domain: example.com inndport: 119 pathnews: /usr/lib/news pathdb: /var/lib/news pathrun: /var/run/news pathlog: /var/log/news pathspool: /var/spool/news patharticles: /var/spool/news/articles pathoverview: /var/lib/news/overview关键点解释organization声明本服务器的组织机构会出现在NNTP-Posting-Host头附近不能乱填因为它是面对用户的可见信息。server服务器 FQDN推荐填正式域名。如果留空或填写 localhostNNTP 响应头会不好看某些严格客户端还会拒绝。inndport默认 119端口一旦被占用INN 会启动失败。检查端口用ss -lnt | grep 119。pathspool和patharticles定义文章存放的根目录。如果你用了timecaf存储具体文章并不直接放在patharticles下而是由storage.conf告诉 INN 到底往哪个目录写。domain用于自动生成 Message-ID 等场景如果填错会导致投递异常。可以填一个有效的域名或子域。修改完inn.conf后最好做一次语法检查sudo -u news inncheckinncheck会遍历配置文件检查常见错误和权限问题输出一堆警告时不要慌先看warning级别的再看error级别的。这条命令算是 INN 部署的“体检中心”。4.2 storage.conf决定文章往哪放storage.conf用来绑定新闻组和存储方法。我的最小配置如下Method timecaf { newsgroups: * class: 0 storageapi: 2 }参数含义newsgroups: *匹配所有新闻组意味着所有文章都进这个方法。class: 0存储类 ID0 表示默认类可以理解为一个标识符。storageapi: 2指定存储 API 版本一般保持 2。如果你希望不同的新闻组使用不同存储策略可以写多个 Method 块并用newsgroups精确指定。比如把高频组和低频组分开存储Method timecaf { newsgroups: comp.* class: 1 storageapi: 2 } Method timecaf { newsgroups: alt.* class: 2 storageapi: 2 }这样做的意义在于你可以针对 class 1 和 class 2 设定不同的过期策略和存储目录运维时可以按类型精细化管理。不过在初期建议先一刀切等摸清流量模型再拆。4.3 readers.conf客户端访问控制的“门禁”readers.conf是配置客户端权限的文件非常容易写错。我用的是最直接的一组配置auth local { hosts: localhost, 127.0.0.1, ::1 auth-type: ckpasswd } access local { users: local newsgroups: * read: * post: * }这段配置的含义auth块定义认证来源允许来自本地回环地址的连接通过ckpasswd认证也就是本机新闻阅读器可以直接用系统账号或 news 账号登录。access块定义访问权限用户local可以读取和投递到所有新闻组。如果你需要开放远程访问需要改成auth remote { hosts: * auth-type: ckpasswd } access remote { users: * newsgroups: * read: * post: * }但请注意users: *意味着所有通过认证的用户都生效如果没有用户数据库这实际上等于匿名开放安全性很低。生产环境务必要接上认证常见做法是使用ckpasswd配合/etc/news/passwd.nntp或者配置基于 LDAP 的认证。这里不展开太多但安全底线要守住。readers.conf还有一个容易踩的坑hosts字段支持 IP 段写法例如*.example.com或者10.0.0.0/8但这依赖反向 DNS 解析容易出连锁问题。实测下来写 IP 段比写域名通配稳得多。4.4 newsfeeds消息投递的“调度表”newsfeeds负责定义把接收到的文章投递到哪里去。对于单机新闻组服务这个文件通常可以保持默认只定义自身回环ME::*转发场景下需要增加另一台服务器的定义upstream!\ /etc/news/upstream.news\ Tf,Wnsm*这样配置的含义是将文章以文件方式写入upstream.news再由同步工具传走。注意ME行是 INN 的特殊条目表示“所有新闻组都属于本服务器”每台 INN 机器都必须有否则 innd 可能因为缺少 ME 行而自动生成一个过窄的本地组列表。newsfeeds的语法比较抽象我踩过最大的坑是过度添加 fan-out 类型的配置导致 innd 启动时直接把文章投递到上游而实际上我还没有配置上游服务器于是日志里满屏连接错误。建议初期就保持最小配置先把“读和写”跑通再考虑转发。5. 实操过程从启动到验证的完整流程前面原理讲透了接下来就是动真格的操作。我会按照我实际部署的步骤走一遍尽量把命令和能看到的输出也写出来。5.1 初始化新闻组和数据库首次启动前需要初始化 INN 的数据库和新闻组列表。Ubuntu 的inn2包安装后已经预置了一个最小新闻组集但你可能需要自定义操作如下先停止服务如果之前启动过sudo systemctl stop inn2清理现有数据库注意备份sudo -u news touch /var/lib/news/history sudo -u news makehistory -b -f /var/lib/news/historymakehistory的作用是扫描历史数据库并建立文章索引。-b表示批量模式-f指定历史文件名。如果你的/var/spool/news中还没有文章这条命令很快结束。生成新闻组列表的首条记录sudo -u news ctlinnd newgroup local.test如果没有local.test可以先创建一个测试新闻组。创建后可以查看active文件确认cat /var/lib/news/active | grep local.test正常会输出类似local.test 0000000000 0000000000 y三个数字的解释第一个是组内最高文章号第二个是最低文章号第三个是状态标志y 表示允许投递。5.2 启动 INN 服务确认配置正确后启动服务sudo systemctl start inn2如果一切正常systemctl status inn2应该显示active (running)。此时查看端口监听ss -lnt | grep 119输出类似LISTEN 0 128 0.0.0.0:119 0.0.0.0:*表示 innd 已经在 119 端口监听。如果启动失败先看日志sudo tail -n 100 /var/log/news/news.notice sudo tail -n 100 /var/log/news/news.errnews.err是排查错误的重点文件。最常见的原因是inn.conf中domain值非法或者pathspool目录权限不对。这两个问题我在第一次部署时都遇到了后面在“常见问题”部分详细讲。5.3 使用 telnet 手动测试 NNTP 协议当你怀疑“服务到底通不通”时最快的办法是用 telnet 手动敲 NNTP 命令telnet localhost 119连接成功后服务器会返回200 news.example.com InterNetNews NNRP server INN 2.7.1 ready (posting ok).接着敲list查看新闻组列表正常会响应215和一组新闻组信息。再敲quit退出215 Newsgroups in form group high low flags local.test 0000000001 0000000001 y . 221 Bye这个小测试能验证服务是否真正工作。如果 telnet 报Connection refused说明 innd 没监听或防火墙拦截了如果没有任何响应多半是 innd 配置有问题需要立刻查日志。5.4 使用新闻阅读器客户端做端到端验证命令行测试通过后我还用实际的新闻阅读器客户端验证了一下数据链路。比较稳妥的组合是使用slrn或tin这样的传统客户端它们虽然界面老旧但是直接支持 NNTP。我以slrn为例sudo apt install slrn slrn --server localhost连接后应该能看到local.test组尝试发一篇文章再重新进入组内确认文章已经在服务器上。如果文章能正常 POST 并被读到说明整条读写链路彻底打通。注意一点slrn默认可能需要配置新闻服务器可以直接在启动时指定。实际使用中别忘了本地跑的话要用localhost远程访问则改用服务器 IP 或域名。6. 常见问题与排查技巧实录这一节我专门把自己部署 INN 时掉进去的坑和排查方法整理成速查表希望能帮你少走弯路。6.1 innd 启动失败日志提示无法写 /var/spool/news这是典型的权限问题。Ubuntu 安装inn2后/var/spool/news可能是 root 所有而 innd 以 news 身份运行写入失败。解决方法sudo chown -R news:news /var/spool/news sudo chmod -R urwX /var/spool/news排查时先看/var/log/news/news.err如果是Permission denied直接检查目录属主。6.2 telnet 连接后无响应或返回“400”200 是正常欢迎响应如果返回400说明 innd 认为你不被允许访问。最常见原因是readers.conf没有把对应 hosts 加入白名单。比如你在远程机器上测试但readers.conf只允许localhost那么远程连接就会被拒绝。解决方法是在hosts字段中加入你的公网 IP 或网段。另外hosts: *在这里的含义是“允许所有来源连进来尝试认证”不代表匿名访问别把这两个概念混了。6.3 文章 POST 失败提示“441 Posting failed”441在 NNTP 里表示“投递被拒绝”。原因通常是readers.conf的post权限没开新闻组状态为只读active 文件里标志是n文章格式有问题缺少必要的头字段或 Message-ID 冲突。排查手段先telnet手动 POST 一个最小文章IHAVE test-ID-001example.com如果也返回435说明 innd 层面就拒绝了文章可能是inn.conf里的pathalias或domain配置导致 Message-ID 生成失败。6.4 防火墙导致外部无法连接Ubuntu 自带的 ufw 如果启用需要放行 119 和 563如果使用 NNTP 加密端口sudo ufw allow 119/tcp sudo ufw allow 563/tcp云服务器的话还要在安全组里放行相应端口。这一步做过一次就容易忘但部署到公网时是必须检查的。6.5 开机自启动设置没有生效inn2的 systemd 服务默认是disabled装完要手动enable。如果你的服务在重启后没有起来再执行一遍sudo systemctl enable inn2 sudo systemctl start inn2有好奇心的同学还可以检查sudo systemctl list-unit-files | grep inn正常输出应该是inn2.service enabled。7. 进阶调优与运行维护建议服务跑起来只是开始真正要长期稳定运行还需要做几件细活。7.1 文章过期策略调整INN 通过expire.ctl控制文章保留时间。我的默认配置是/tread60 /remember90意思是文章保留 60 天后清除文章历史记录保留 90 天。高频大流量的服务器可以把 60 调低到 30 天减少磁盘占用。注意remember必须大于等于read否则历史索引会被过早清理导致同一条 Message-ID 被重复接收。修改后可以手动触发过期作业sudo -u news expire -v7.2 日志轮转与监控INN 的日志文件如果不处理会一直增长好在 Ubuntu 安装后自带logrotate配置。不过建议你还是定期检查一下sudo logrotate -f /etc/logrotate.d/news我的习惯是每天凌晨自动跑一次expire和makehistory -b并检查news.err是否有新增错误。配合最简单的 cron 就能实现0 3 * * * /usr/sbin/news.dailynews.daily是 INN 自带的每日维护脚本集成了 expire、overview 更新和备份强烈建议在 cron 里配置。运行前用sudo -u news news.daily手动跑一遍观察有没有错误输出。7.3 基于 TLS 的加密 NNTP 支持如果要在公网提供新闻组服务明文 119 端口不太安全。INN 2.6 以上支持通过外部 TLS 包装器实现加密连接常见做法是配合stunnel使用。简单说就是让 innd 只监听回环地址的 1199 端口然后由 stunnel 对外提供 563 端口的加密转发。stunnel 配置示例[nntps] accept 563 connect 127.0.0.1:1199 cert /etc/ssl/certs/news-server.pem这样客户端通过nntps://协议连接时传输内容是加密的。不过要注意INN 本身在 1199 端口监听时仍按明文处理只是通信链路被 stunnel 加密了用户认证还是在 INN 层完成。7.4 性能参数调优硬核玩家的选择如果你的服务器负责处理大量新闻源innd 的--runtime参数和一些缓冲池配置就需要调整。比如在启动脚本里加上OPTIONS-b1 -p3-b1打开缓冲区写盘优化。-p3设置较激进的扫描周期。但说实话中小规模部署直接默认值就好这些参数调不好反而容易出问题。我见过把缓冲池调太大导致 OOM 的案例属实没必要。8. 工具选型与周边生态最后简单聊聊部署 INN 时周边常用的一些工具和资源。onefetch / newsfetch一些辅助抓取新闻组数据的脚本工具适合需要批量镜像的场景但大多年久失修脚本兼容性要自己测。slrn / tin传统文本界面的新闻阅读器调试时很好用体积小、依赖少。NeMutt / Thunderbird支持 NNTP 的现代邮件客户端Thunderbird 自带新闻组功能日常管理新闻组很方便。innreport通过对 INN 日志生成流量报表的 Perl 脚本可以帮你了解文章流入流出情况。如果是从上游新闻源接收全量文章需要注意 INN 的incoming.conf配置文件它定义了哪些上游服务器被允许发送文章到本机。默认配置比较宽松生产环境务必收紧。peer upstream { hostname: news.upstream.example.com auth: authstring }没有配置incoming.conf中的 upstreaminnd 对未知来源的 FEED 连接会直接拒绝这也能避免开放投递端口后被滥用。9. 最后的经验总结对我来说INN 最大的特点是“老但不旧”只要理解了它的存储、认证和投递三块核心剩下的都是熟练活。整套流程中最容易卡住人的不是安装而是/etc/news下那堆配置文件的语义——readers.conf管的是谁来看newsfeeds管的是文章往哪去storage.conf管的是盘里怎么放只要把这三条主线理清INN 立刻从“上古神器”变成“顺手工具”。如果你按着这篇文章操作下来最后能在 Ubuntu 服务器上跑通一条从 telnet 到阅读器客户端发帖的完整链路那这套 INN 实例就已经可以进入日常维护了。后面再尝试接入真实新闻源或者做多级转发都会有更扎实的基础。