Snapped Nagios plugin issues

I’m trying to get my snapped nagios check ro run, but I’m not able to get it to execute.

I’m not 100% sure why yet, but I suspect this has to do with this.

Works for root

root@juju-04a5eb-5:# /snap/bin/nagios-substrate.blocksync -H ‘kilt-rpc.dwellir.com’ -c ‘1’ -w ‘2’ Block sync OK - 1172476/1172477

Fails for nagios

root@juju-04a5eb-5:# sudo -u nagios /snap/bin/nagios-substrate.blocksync -H ‘kilt-rpc.dwellir.com’ -c ‘1’ -w ‘2’ Sorry, home directories outside of /home are not currently supported. See Support for non /home homedirs for details.

I’m curious how this guy got it to work since I can’t see anything special going on here. https://github.com/dmp1ce/check_cgminer

This is how I specify in my check_command (for those that knows nagios)

# 'check_substraterpc' command definition
define command{
	command_name	check_substraterpc
	command_line	/snap/bin/nagios-substrate.blocksync -H '$HOSTADDRESS$' -w '$ARG1$' -c '$ARG2$'
	}

UPDATE: This post tells me a nasty story: https://snapcraft.io/docs/home-outside-home

Nagios plugins runs as the user “nagios” which is in turn an account which should not have an account with home under /home. I hope there is a way to run plugins for nagios as a snap?

This is the account details for nagios on my system:

cat /etc/passwd

nagios:x:112:118::/var/lib/nagios:/usr/sbin/nologin

So, I’ve tried this path (which breaks other things of course)

But, to no avail on Ubuntu 20.04

root@juju-04a5eb-5:/home/nagios# sudo -u nagios nagios-substrate.blocksync -H kusama-rpc.dwellir.com
cannot create user data directory: /home/nagios/snap/nagios-substrate/x1: Permission denied
root@juju-04a5eb-5:/home/nagios# sudo -u nagios touch /home/nagios/snap/nagios-substrate/x1/somefiletest
root@juju-04a5eb-5:/home/nagios# ls -la /home/nagios/snap/nagios-substrate/x1/somefiletest
-rw-r--r-- 1 nagios nagios 0 Mar 21 14:15 /home/nagios/snap/nagios-substrate/x1/somefiletest

I’m trying to address the issue with check_cgminer on Github. https://github.com/dmp1ce/check_cgminer/issues/1

Perhaps you could just try copying the binary from Github instead of using Snaps as a temporary solution. Here is the latest release. https://github.com/dmp1ce/check_cgminer/releases/tag/v0.7.12.0

1 Like

I would have thought the “Bind mount home directories” would have worked but I wouldn’t want to do that on my server either.

1 Like

I think it’s more or less a dead end using snaps with a system user with a home directory located anywhere but under /home or /root

I’m dropping this and will not use snap. I spent a few hours putting together a npm package and will not go further here.

Nagios checks will not work with snap. The end.

Thanx for the help though.

I would still like to get this fixed. Perhaps there is another directory I could use to make the snap work for nagios user. I’m looking through the documentation. https://snapcraft.io/docs/data-locations

It looks like I do need the /home directory even when using the snap data directories.

Snaps without the home interface declared and/or connected cannot access the disk. The $SNAP_USER_DATA directory will still be created and exist in the user’s home directory but it can contain no files

1 Like

I hope you will be able to. Let me know if you succeed.

I was able to do the bind mount and got the nagios user working with check_cgminer snap. There was a little problem with the documentation for the bind mount however.

I think the bind mount is the way to go for nagios check snaps until snaps are allowed to have a home directory outside of /home.

I don’t think the bind mount will cause any issues with nagios or anything else on the system, so why not go that route?

To test I just did sudo -u nagios check_cgminer --help and I got the expected output. If there is another issue, please let me know.

What was that issue?

The awk command was slightly wrong. I updated the wiki and others had commented about the issue as well.

What awk command ? I don’t see any…

The awk command on this page: https://snapcraft.io/docs/home-outside-home

It looks like it was fixed 6 days ago.

1 Like