[smokeping-users] No data being displayed for slave machine

[G.W. Haywood]

Hello again David,

On Sun, 22 Jun 2008, David Tomic wrote:

> Now that you mention it though ... I don't actually see anything in the
> log about updating the slave .rrds.
>
> If I chmod the .rrd files to 777 though, I see them updating in the log,
> but they still don't list a user in the output.

There isn't a user in the logs I posted, it's a process name.  There's
also process id, so when you see something like this (at least in my
system's /var/log/messages):

Jun 22 13:11:03 tornado smokeping[3451]: Calling RRDs::update(/var/lib/smokeping/Local/[snip]

it tells you that at 13:11:03 on June 22, on the host known as tornado,
process id 3451 was running smokeping.  It called the function called
RRDs::update() to update a file in /var/lib/smokeping/Local/ although
it doesn't say which user was running the process.  You'd use 'ps' to
find out:

tornado:/var/log# >>> ps axufw | grep smoke | grep 3451
116       3451  0.0  0.3  56880 21528 ?        S    Jun20   0:02  \_ /usr/sbin/smokeping [FPing_14]

It's user id 116 here, that's the smokeping users.  Unfortunately I'd
have to give some messy format commands to ps to get it to print the
name rather than the numeric id, as 'smokeping' has nine characters
and the default maximum for ps is eight.  That's just history, and an
unfortunate choice of name.

> Sun Jun 22 21:49:42 2008 - Calling RRDs::update(/var/lib/smokeping/TEST2/slave-test-new-777~david-slavebox.rrd  <snip>

Which log is this?

Your log doesn't give the host name, but we can manage without that.
It's giving the year, which is good.  I think it's also telling us that
the message about the call to RRDs::update came from the stream that's
known as 'stdin' (I guess you've heard about stdin, stdout and stderr).
I think that's what the '-' just after the year means.  But it doesn't
tell us the process which is doing this.  That's a shame.  I take it
that you haven't got something like this in your configuration:

# specify this to get syslog logging
syslogfacility = local0

which might give us a little more information.

> Again, the slaves work fine if I chmod the .rrd files to 777, so I
> really think that I'm just dealing with some sort of a permissions issue?

Obviously permissions are involved, but there seems to be more to it
than that.  I'm trying to understand why our two setups behave in so
very different ways.  Perhaps it something else in the configuration,
or...

> > tornado:~# >>> smokeping --version
> > 2.0030061
> >
> david at david-desktop:~$ smokeping --version
> 2.004000

I wonder if there's been a change from 2.3.6 to 2.4.0 in the way that
the probes handle the data.

The thing that bothers me is that the generally acccepted wisdom for
Web servers is that they are by design given very little permission
to do things like write to the file system.  That's because they're
often open to the whole wide world, and as a consequence suffer from
attacks by the Bad Guys.  So in general it's not a good idea to have
your Web server able to write to files in some random place in your
system, just in case an attack on the Web server is successful.  The
theory is that even if the Web server is compromised an attacker can
do far less damage if the server process has restricted permissions.
However if the compromised Web server process can write to the files
in your smokeping directories, a successful attacker can probably do
what he likes to them.  If there happen to be suid binaries in there
that can be written by the server then he 0wns the box.  He probably
does anyway.

Now in my setup the Web server can't write directly to the smokeping
.rrd files because they're owned by the smokeping user and it's the
smokeping processes which I showed you which do the writing.  When
smokeping is started by root it could have root permissions, but the
startup script relinquishes them.  The Web server does just the same
thing when it starts, it's very common to do this kind of thing for
security.  The server processes which serve pages (so are exposed to
attack) have restricted permissions.  Once upon a time user and group
for Apache processes would be 'nobody' and 'nobody' (or 'nogroup')
just to emphasize this intentional lowliness of Web server processes.

Someone else on this thread said that your Web server should be able
to write the .rrd files, and that might well be the case in version
2.4.0 of smokeping.  You can easily test that.  Instead of giving the
world write permission to the files, simply change the 'group' of the
files to a group that your Web server is in, and then make the files
group writeable.  Assuming that Apache is a member of group 'nogroup':

chgrp nogroup smokepingfilename
chmod 664 smokepingfilename

The first command sets the group ownership to nogroup, the second
gives read/write to owner and group, read-only to everyone else.
You'd need to be root to do this.

If this has the desired effect then we're a little further forward but
then I think I'd need to take a look at the 2.4.0 code before saying
much more.  Perhaps Tobi would be able to save us some time, which is
why I've mailed this to him too.

> I don't have a separate config file for the slaves ... they're just
> included in the main smokeping config file.

It doesn't matter, as long as smokeping can find the configuration.

--

73,
Ged.