Initscript chown to user nagios hardcoded regardless of configuration

[kali]

When setting nagios-nrpe-server to run under any user that is not nagios, the initscript creates a conflict since it has a chown command hardcoded to
user nagios which is the default in the package.

The in the init script as per the package included in ubuntu precise:

*** 43,47 ****
  #since /var/run can be wiped completly we create our run directory here
  if [ ! -d "$PIDDIR" ]; then
        mkdir "$PIDDIR"
        chown nagios "$PIDDIR"
  fi
---

In my nrpe_local.cfg configuration I have nagios set to run as a custom user:

nrpe_user=srv-monitor
nrpe_group=srv-monitor

Hence when I restart the server the upstart script will leave the permissions messed up and the service will fail to start properly.

IMHO the initscript should either not try to chown the piddir at all, or at least parse this setting from /etc/default or any other config,
but the way the package is right now makes unpractical or simply impossible to run the service reliably unless with the default "nagios" user.

In my cluster I did add this setting as a variable in the header of the initscript. Ideally it should be parsed through the relevant /etc/default file.

-----
NAGIOS_USER=srv-monitor
[...]
        chown "$NAGIOS_USER" "$PIDDIR"
-----

Cheers,
-kali-

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: nagios-nrpe-server 2.12-5ubuntu1.2
ProcVersionSignature: Ubuntu 3.5.0-51.77~precise1-generic 3.5.7.33
Uname: Linux 3.5.0-51-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu17.6
Architecture: amd64
Date: Wed Jul 2 10:47:15 2014
InstallationMedia: Ubuntu 12.04.2 LTS "Precise Pangolin" - Release amd64 (20130213)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: nagios-nrpe
UpgradeStatus: No upgrade log present (probably fresh install)

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

> IMHO the initscript should either not try to chown the piddir at all, or at least parse this setting from /etc/default or any other config,

I agree that this would be nice.

> ...but the way the package is right now makes unpractical or simply impossible to run the service reliably unless with the default "nagios" user.

Can you not just modify the initscript, given that you're modifying the default configuration manually already? It's a conffile - the package manager will honour your changes, with the only disadvantage being that if the packaged initscript changes on upgrade, you'll be prompted to resolve the conflict manually.

As I believe there's an easy workaround available, I think this is of Wishlist importance.

I also suggest that you check what Debian does, file a bug there if has the same behaviour and a bug isn't already filed, etc. As Ubuntu's packaging is based on the Debian one, we would prefer changes to come from Debian where relevant.

[Bas Couwenberg (sebastic)]

Quoting from the bugreport in Debian:

"However, users != nagios are not supported and we won't ever support them."

[kali (drinkkali)]

This is so incredibly absurd from Debian, and I have discussed with them as well. The software DOES support running under a different user, and in fact the packaged software does have a setting in their config file for changing the user, with no notice whatsoever towards such mindless limitation imposed for no reason by Debian.

The initscript has the aforementioned section hackily chown'ing the /var/run/ directory with a hardcoded user, IMHO simply because the packager was too lazy to think about how to properly do it, or to realise whether the service does support running as a different user.

The solution to this bug is extemely simple and follows common sense and practices in dealing with owned files and directories by users running a service.

After privately discussing with Debian packagers it came clear to me that they are just plain lazy and arrogant and decided that the package does not support another user, while it DOES. This is not an opinion, it is a fact. Did the package not support another user, it would not contain a section in the config file towards changing that setting.

Moreover, by having such config section this might lead users to believe they can set the service to be run as another user, only to be smashed by a non-written, non-sense limitation imposed by a non thinking packager.

Simply outrageus.

I would have expected Ubuntu to be wiser.