[smokeping-users] Master/Slave configuration trouble

[G.W. Haywood]

Hi Eric,

On Wed, 10 Jun 2009, Eric Chatham wrote:

> [snip] What user is trying to read the master from the slave?

It isn't quite like that.  The slave sends a request to the master to
say it has some data to hand over to the master.  If the master is
happy to accept it, it does so, and at the same time sends to the
slave an updated configuration if necessary.  They obviously need to
agree on a protocol to exchange the data, or things will go wrogn.
If the master doesn't like the slave's idea of the protocol it will
ignore the slave (see sub answer_slave in Master.pm).

The slave runs as some user.  So does the master.  Which user is up to
you to decide, which you do at the time you first install Smokeping.
It may be that you installed a 'package' from a distribution, in which
case the package usually has a 'maintainer' who probably decided on
that for you.  Unfortunately maintainers often stray a long way from
the path you'd take if you just grabbed the tarball from wherever it
lives, and installed it yourself.  This is often the case, with any
software, not just Smokeping.  So this is one of those cases where
nobody can know the answer without having more information.

It's possible to set up systems in many different ways.  One of the
things you can do is create users, for example on your systems you
might have created a user called 'eric'.  You might choose to log in
as eric and to run a few processes by starting them at the command
line.  Those processes will probably be running as user 'eric'.
Smokeping might even be one of them.  There are ways to find out,
using a utility such as 'top' or 'ps' for example.

> The smokeping process is run by root on both slaves and the master.

Then the processes _should_ be able to read the configuration files,
unless you're running SELinux, which is another kettle of worms.

> Does the apache user/group try to read the master config from the
> slaves?

Let's step back a little.  We need to get the terminology right or
we'll all be very confused.

You have four things going on.

1. A smokeping master daemon on a machine somewhere.  A daemon is a
'process'.  It has a life all of its own, it does things based on
things it finds in a configuration file, without you needing to type
anything to tell it to do them.  This one sends pings (using a variety
of tools, like fping) waits for replies, writes things into a database
of RRD files.  You can look at these files with RRDtool, that's how I
use 'collectd', but it isn't much fun that way and it's another story.
The daemon is started and runs with whatever user's permissions you
chose when you (or your package maintainer, or your predecessor, or...)
installed Smokeping.

2. (Optionally) some smokeping slave daemons, on other machines, which
do everything the master does except the bit about writing databases.
Instead of that, they collect their data and when they can they send
it to the master.  It thanks them very much and writes the data to a
(RRD) database, and tells them if their configuration has changed.
These slaves have the permissions you decided that they should have.
These slaves and the master daemon who need to agree on a protocol to
converse, and if they're all the same version then they will agree.

3. A Web server, probably Apache.  Apache can 'drop' permissions for
security reasons, so although root might start it (and therefore it
has permission to read its configuration files, which often only root
can read), it can start child processes which _can't_ read those files
(they don't need to) and in the unfortunate event that they're taken
over by some hacker out there on the Internet that is a Good Thing -
the hacker can't use them to see things he shouldn't.  Well, we hope.
The server is on the same machine as the Smokeping master daemon, but
I suppose you could change that if you really wanted to.  Don't try,
yet.  Anyway, an Apache server doesn't really do anything unless a...

4. ...client asks it to do something, using the HTTP protocol.  That's
the fun part.  The HTTP protocol isn't likely to be a problem, as it's
fairly stable. :)  The client (most often a browser) can be anywhere,
on any machine.

  ..oOo..

Processes do things.  Users don't.  Users have characteristics, amongst
which is their permissions to read, write, and execute files.  If we're
talking about a directory, 'execute' is treated like 'search'.

When the browser asks the Web server for some 'Smokeping' page, the
server runs a bunch of Perl code which came as part of the Smokeping
package.  This code tells the server (which is a process) to read the
RRD databases that the master made; make a few graphs; send them, and
other stuff, to the browser.  That's nothing to do with the smokeping
daemons really, they exist quite separately and just trundle along,
autonomously, collecting data and writing it to a database for your
eventual edification and delight, should you choose to look at it by
means of the client/server pair that is your browser and Apache.

The master config is not known to the slaves, so it would be pointless
any process trying to get it from them.  The 'apache' user, if there
is such a user, doesn't try to read anything.  It's processes that do
that, not users.  A process usually has the permissions associated
with a user.  The process might be run by a user called 'apache' but
that depends very much on your system.  Most often the Apache server
is actually several different processes, running with the permissions
of two different users.  Most often the process is known by the name
'httpd' - short for the unwieldy "HyperText Transfer Protocol Daemon".
The parent Apache (httpd) process is the one you actually started.  It
(usually) runs as user root, i.e. it has root permissions, and so it
has complete access to anything on the system.  The parent (usually)
starts some child httpd processes, and kills them when it needs to,
starts more when it needs to, writes the logs, keeps the score, and
does very little else.  The children run as a less-privileged user,
sometimes 'nobody', or 'www'.  They have the permissions associated
with that user, whatever they happen to be - or rather, whatever you
decided they should be.  On my Debian systems the user is 'www-data',
I ask you.  These child processes are responsible for actually serving
the requests from clients; the parent doesn't do that.  'Clients'
usually means 'browsers' but it could mean 'smokeping slave daemons'
who send their data to the master by means of HTTP requests.  So the
httpd child processes need to be able to put the data they get from
slaves into the database.

Did any of it help?

Tobi, I'd be grateful for any comments, corrections, additions.

--

73,
Ged.