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. _______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
