☰

NRPE 命令的远程调用在一种情况下失败，但在所有情况下均在本地成功

tag-icon • tag-icon nagios selinux rhel7 nrpe
NRPE 命令的远程调用在一种情况下失败，但在所有情况下均在本地成功

我在监控通过 Nagios + NRPE 安装到 Linux 机器的 CIFS（SMB）共享文件夹时遇到了一个非常奇怪的问题。

NRPE进程在专用用户下的Linux机器上运行nrpe：

# systemctl status nrpe
  nrpe.service - Nagios Remote Program Executor
   Loaded: loaded (/usr/lib/systemd/system/nrpe.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2023-05-02 14:46:47 IDT; 20h ago
     Docs: http://www.nagios.org/documentation
  Process: 30216 ExecStopPost=/bin/rm -f /run/nrpe/nrpe.pid (code=exited, status=0/SUCCESS)
 Main PID: 30218 (nrpe)
   CGroup: /system.slice/nrpe.service
           └─30218 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f

# ps -ef | grep nrpe
nrpe     30218     1  0 May02 ?        00:00:05 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f

监控命令在其配置文件中定义/etc/nagios/nrpe.cfg如下：

command[check_backups_share]=/usr/lib64/nagios/plugins/check_disk -w 7% -c 5% -p /mnt/backups

nrpe如果我以用户身份在所有机器上手动运行该命令，它会成功：

# sudo -u nrpe bash
bash-4.2$ /usr/lib64/nagios/plugins/check_disk -w 7% -c 5% -p /mnt/backups
DISK OK - free space: /mnt/backups 2571991 MiB (61.32% inode=-);| /mnt/backups=1622248MiB;3900643;3984528;0;4194240

然而如果我称它为远程从 Nagios 来看，它在一台机器上成功，但在另一台机器上失败：

$ /usr/local/nagios/libexec/check_nrpe -2 -H Machine01 -c check_backups_share
DISK OK - free space: /mnt/backups 2575536 MiB (61.40% inode=-);| /mnt/backups=1618703MiB;3900643;3984528;0;4194240

$ /usr/local/nagios/libexec/check_nrpe -2 -H Machine02 -c check_backups_share
DISK CRITICAL - /mnt/backups is not accessible: Permission denied

上的所有其他远程 NRPE 命令均Machine02成功。此外，如果我卸载/mnt/backups上的文件夹Machine02，它也会成功（对于根文件系统）。但是当它被挂载时，我收到此Permission denied错误。

该文件夹以相同的方式安装在所有计算机上，具有相同的凭据和选项。在/etc/fstab文件中：

//Backups-Server/backups  /mnt/backups      cifs    vers=3.0,credentials=/path/to/creds    0 0

所以：

  • 所有凭证、权限、用户、组都相同；
  • 在同一用户下的所有机器上本地执行的命令产生相同的结果；
  • 但在远程执行时，它在一台机器上失败，抱怨权限问题，但在所有其他机器上都成功，
  • 而执行nrpe进程在所有机器上都以相同的方式配置，并具有相同的权限。

那么这到底是什么呢？

更新：

已解决，见下文。

答案1

更新：

感谢@NikitaKipriyanov，问题解决了。

在以下位置找到多个条目/var/log/messages：

[root@Machine02 /]# cat /var/log/messages | grep avc | grep check_disk

May  7 17:32:01 Machine02 kernel: type=1400 audit(1683469921.442:63546): avc:  denied  { getattr } for  pid=20931 comm="check_disk" path="/mnt/backups" dev="cifs" ino=3458764513820542747 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=dir permissive=0

May  7 17:32:21 Machine02 kernel: type=1400 audit(1683469941.508:63549): avc:  denied  { getattr } for  pid=20973 comm="check_disk" path="/mnt/backups" dev="cifs" ino=3458764513820542747 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=dir permissive=0

May  7 17:32:41 Machine02 kernel: type=1400 audit(1683469961.575:63552): avc:  denied  { getattr } for  pid=21025 comm="check_disk" path="/mnt/backups" dev="cifs" ino=3458764513820542747 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=dir permissive=0

生成策略以避免此类拒绝：

[root@Machine02 /]# cat /var/log/messages | grep avc | grep check_disk | audit2allow -M check_disk_policy

这产生了两个文件：

  • check_disk_policy.pp- 二进制
  • check_disk_policy.te- 文本，包含以下内容：
module nrpe 1.0;

require {
    type nrpe_t;
    type cifs_t;
    class dir getattr;
}

#============= nrpe_t ==============

#!!!! The file '/mnt/backups' is mislabeled on your system.  
#!!!! Fix with $ restorecon -R -v /mnt/backups
allow nrpe_t cifs_t:dir getattr;

运行restorecon -R -v /mnt/backups并没有帮助，所以我加载了策略：

[root@Machine02 /]# semodule -i check_disk_policy.pp

之后错误消失了。据我了解，此策略允许标有 的进程nrpe_t（该/usr/sbin/nrpe进程及其产生的子进程，例如/usr/lib64/nagios/plugins/check_disk）访问 CIFS 共享文件夹。

相关内容