[smokeping-users] gid problems

[Lee Elliott]

> Lee:
> 
> I think that the deb/ubuntu install assumes a master install - and doesn't
> consider slave installation. [It really should - though including permissions for
> apache could introduce some security issues, if that was the default and one
> was running Apache for public access.
> Though why one would be running a smokeping slave on the same box one is
> using for a production apache server seems crazy.]

To clarify, it is on the master server that the smokeping folders and rrds need the group permissions to be set to the httpd group but I'm not sure it would be much of a security problem - the httpd group only needs read permissions on the master and, on Debian at least, the /var/lib/smokeping folder already has world read permissions, which is why it seems odd that I need to set explicit read access for www-data in the first place - in fact it's possibly not actually a permissions issue but an internal check in the smokeping code.

> 
> So, IMO, your criticism about no clear docs on slave mode is on target. [And
> the fact that the question about slave mode comes up very consistently
> seems to bear out the fact that it's not obvious, and it's missing from any
> docs.]
> 
> Perhaps adding exactly how you've fixed this to the list would be somewhat
> helpful - and perhaps asking Tobi to add it to the docs would be nice too.
> 
> -Greg

Hello Greg,

Changing the group permissions on /var/lib/smokeping to www-data (apache/httpd) and then chmod +s /var/lib/smokeping sorts the permissions out for any new location folders and rrds.

However, the 'slaves' page at:

 http://oss.oetiker.ch/smokeping/lib/Smokeping::Slave.en.html

says...

" In slave mode we just hit our targets and submit the results to the server. If we can not get to the server, we submit the results in the next round. The server in turn sends us new config information if it sees that ours is out of date."

...which I interpret as meaning that the slave should automatically pick up the new config, including the new target it has to monitor, after it sends its next batch of results to the master, but after adding a new slaved target, restarting the master smokeping instance and then waiting for 30 minutes I still got no data from the slave.  Manually restarting the slave gets it working though, and it displays the message:

 "Starting smokeping latency logger daemon: smokeping[]Sent data to Server and got new config in response."

So the slave doesn't appear to be picking up the new config in-flight, as it were.

Note though, that the master here is running the Debian Squeeze smokeping package, which is version 2.3.6-5, whilst the slave is running the Debian Wheezy smokeping package, which is version 2.6.8-2.  So the smokeping master instance is quite old and the reason that the slave isn't automatically picking up the new config might be due to that.

LeeE