[smokeping-users] Master/Slave configuration trouble

[Eric Chatham]

On G.W. Thursday, June 11, 2009 03:11, Ged wrote,


> 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.
>

Hi Ged,

This information was very helpful.  I'll save this for future reference.

CONFIDENTIAL.  This e-mail and any attached files are confidential and should be destroyed and/or returned if you are not the intended and proper recipient.