[smokeping-users] Master/Slave configuration trouble
echatham at broadvox.com
Thu Jun 11 16:13:40 CEST 2009
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
> 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.
> 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.
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.
More information about the smokeping-users