☰

Ubuntu 14.04 服务器中的 SNMPD 绑定错误

tag-icon • tag-icon ubuntu-14.04 snmpd
Ubuntu 14.04 服务器中的 SNMPD 绑定错误

我正在尝试让 SNMPD 在运行 Ubuntu Server 14.04 的 Zenoss 服务器上运行。我已安装并配置了它，但启动时，我在 syslog 中收到以下错误：

Aug 14 08:19:16 zenoss snmpd[9904]: Turning on AgentX master support.
Aug 14 08:19:16 zenoss snmpd[9904]: Turning on AgentX master support.
Aug 14 08:19:16 zenoss snmpd[9904]: Error opening specified endpoint "udp:127.0.0.1:161"
Aug 14 08:19:16 zenoss snmpd[9904]: Server Exiting with code 1

如果我在命令行运行 SNMPD（sudo /usr/sbin/snmpd -f），它会正常工作。我执行了 netstat -oan | grep 161，没有其他任何东西绑定到端口 161。这是我的配置文件（删除了注释）：

agentAddress  udp:127.0.0.1:161
view   systemonly  included   .1.3.6.1.2.1.1
view   systemonly  included   .1.3.6.1.2.1.25.1
rocommunity public  localhost
rwcommunity private localhost
rouser   authOnlyUser
sysLocation    Virtual Machine
sysContact     IT Manager
sysServices    72
load   12 10 5
trap2sink    localhost public
master          agentx

我的 snmpd 设置文件（已删除注释）：

export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'
TRAPDRUN=no
TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'

答案1

问题似乎出在这里：

-c /etc/snmp/snmpd.conf

从 /etc/default/snmpd 中删除它，使其看起来像这样：

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf -p /var/run/snmpd.pid'

如果您想要让 snmpd 监听 0.0.0.0（或所有接口），那么编辑：

/etc/snmp/snmpd.conf

所以它看起来像这样：

#  Listen for connections from the local system only
#agentAddress  udp:127.0.0.1:161
#  Listen for connections on all interfaces (both IPv4 *and* IPv6)
agentAddress udp:161,udp6:[::1]:161

重新启动 SNMP。

答案2

这可能是权限问题。

正常情况下，非root用户不能绑定到Linux中的端口<1024。

但是，如果 SNMPD 在创建套接字/端点后放弃其权限，那么这应该不是您的问题。

答案3

打开指定端点“udp:127.0.0.1:161”时出错

这看起来像是 snmpd 代码库中一个相当容易出问题的区域 - 不确定这是 snmpd（作为 Net-SNMP 的一部分）还是 Debian 及其它同类产品的属性。

我刚刚在 Debian 11.3 中遇到了这个问题。

懒得深入研究源代码，我设法使用strace: 找到了另一个错误症状，即 strace -f -o /var/trace.txt snmpd -u root -g root。在输出跟踪中，您会在 0.0.0.0:161 上获得两次连续的 bind() 调用，第一次成功，第二次调用失败，EADDRINUSE = address already in use。最初我没有注意到有两次连续的 bind() 尝试，所以我使用 寻找罪魁祸首netstat -lnp，但没有找到任何候选者。然后，我衰老的灰质中冒出一连串与套接字相关的关键字，类似于 TIME_WAIT、SO_LINGER、SO_REUSEADDR（请注意，这可能仅指向 TCP，而不是 UDP）——直到我注意到 snmpd 本身实际上是罪魁祸首！

有类似这样的 Debian 错误报告，于 2017 年为 snmpd v5.7 提交。我已经用到了 v5.9，但显然这个 bug（或类似 bug）仍然存在。

还有另一个使用 Net-SNMP 提交的错误报告2019 年的 v5.8 版本中声称第一次 bind() 尝试实际上源自trapsink配置文件中某处的关键字，指定本地主机地址，并默认为端口 161。我尝试遵循该建议，但似乎不适用于我的情况。

我遇到的似乎是上述“debian 风格”的错误。实际上我最好的办法是排除（注释掉）agentAddress配置文件中任何地方的任何引用 - 在这种情况下，snmpd 将最终启动，netstat 报告为在 0.0.0.0:161 上监听。如果我添加自己的声明agentAddress，它不能与默认 IP 地址（0.0.0.0）重叠，这是不可能的，或者它必须包含不同的 UDP 端口（或 TCP 而不是 UDP）。如果我满足该规则，这两个套接字都会打开，进行监听，并且我会从两者那里得到对我的 SNMP 查询的相同响应。

除此之外，我注意到“配置文件的优先级”有一些特殊之处，例如：

  • 如果我在和中都指定了 agentAddress ，/usr/share/snmp/snmpd.conf则 /etc/snmp/snmpd.conf中的声明/etc/snmp/snmpd.conf将被忽略，而中的声明/usr/share/snmp/snmpd.conf将占上风——尽管我可以在 strace 输出中看到这两个文件都打开了。
  • snmpd 周围的 debianese systemd 包装器，称为 /etc/systemd/system/multi-user.target.wants/snmpd.service 包含一些额外的命令行参数：ExecStart=/usr/sbin/snmpd -LOw -I -smux,mteTrigger,mteTriggerConf这些参数对于我来说有点难以理解它们各自的结果，并且它们确实会影响加载的 MIB（与我在命令行手动运行 snmpd 相比）- 如果我通过 systemd 启动 snmpd，我会加载 lmSensors MIB，否则不会。选项排除的模块可能很-I -麻烦。此外，systemd 包装器包含一个额外的条件：ConditionPathExists=/etc/snmp/snmpd.conf。所以我不能直接删除 /etc/snmp/snmpd.conf。如果我只是“触摸”一个空文件，snmpd 会启动，但不会响应 lmSensors OID。

有趣的东西。

换句话说，在默认 IP 和套接字绑定方面存在几种类似的错误行为，以及这是否会被显式 agentAddress 覆盖（或与其发生冲突）。此外，根据不同人报告的解决方法，配置文件的优先级在发行版之间也可能不同。我很好奇，这听起来像是代码库中一个相当无聊的领域，而且它有错误 - 然而，神秘的 SNMP 引擎和模块化架构（可插入子代理）似乎坚如磐石。

相关内容