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