主页 / server / 问题 / 1130248
Accepted
Cat Mucius
Asked: 2023-05-03 16:43:54 +0800 CST

NRPE comman 的远程调用在一种情况下失败，而在所有情况下都在本地成功

  • 772

我在监视通过 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进程在所有机器上以相同的方式配置并具有相同的权限。

那么这到底是什么呢？

更新：

已解决，见下文。

nagios

1 个回答

  1. Best Answer

    更新：

    感谢@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 共享文件夹。

    • 1

相关问题