Hello again David, On Sun, 22 Jun 2008, David Tomic wrote:
> Now that you mention it though ... I don't actually see anything in the > log about updating the slave .rrds. > > If I chmod the .rrd files to 777 though, I see them updating in the log, > but they still don't list a user in the output. There isn't a user in the logs I posted, it's a process name. There's also process id, so when you see something like this (at least in my system's /var/log/messages): Jun 22 13:11:03 tornado smokeping[3451]: Calling RRDs::update(/var/lib/smokeping/Local/[snip] it tells you that at 13:11:03 on June 22, on the host known as tornado, process id 3451 was running smokeping. It called the function called RRDs::update() to update a file in /var/lib/smokeping/Local/ although it doesn't say which user was running the process. You'd use 'ps' to find out: tornado:/var/log# >>> ps axufw | grep smoke | grep 3451 116 3451 0.0 0.3 56880 21528 ? S Jun20 0:02 \_ /usr/sbin/smokeping [FPing_14] It's user id 116 here, that's the smokeping users. Unfortunately I'd have to give some messy format commands to ps to get it to print the name rather than the numeric id, as 'smokeping' has nine characters and the default maximum for ps is eight. That's just history, and an unfortunate choice of name. > Sun Jun 22 21:49:42 2008 - Calling > RRDs::update(/var/lib/smokeping/TEST2/slave-test-new-777~david-slavebox.rrd > <snip> Which log is this? Your log doesn't give the host name, but we can manage without that. It's giving the year, which is good. I think it's also telling us that the message about the call to RRDs::update came from the stream that's known as 'stdin' (I guess you've heard about stdin, stdout and stderr). I think that's what the '-' just after the year means. But it doesn't tell us the process which is doing this. That's a shame. I take it that you haven't got something like this in your configuration: # specify this to get syslog logging syslogfacility = local0 which might give us a little more information. > Again, the slaves work fine if I chmod the .rrd files to 777, so I > really think that I'm just dealing with some sort of a permissions issue? Obviously permissions are involved, but there seems to be more to it than that. I'm trying to understand why our two setups behave in so very different ways. Perhaps it something else in the configuration, or... > > tornado:~# >>> smokeping --version > > 2.0030061 > > > [EMAIL PROTECTED]:~$ smokeping --version > 2.004000 I wonder if there's been a change from 2.3.6 to 2.4.0 in the way that the probes handle the data. The thing that bothers me is that the generally acccepted wisdom for Web servers is that they are by design given very little permission to do things like write to the file system. That's because they're often open to the whole wide world, and as a consequence suffer from attacks by the Bad Guys. So in general it's not a good idea to have your Web server able to write to files in some random place in your system, just in case an attack on the Web server is successful. The theory is that even if the Web server is compromised an attacker can do far less damage if the server process has restricted permissions. However if the compromised Web server process can write to the files in your smokeping directories, a successful attacker can probably do what he likes to them. If there happen to be suid binaries in there that can be written by the server then he 0wns the box. He probably does anyway. Now in my setup the Web server can't write directly to the smokeping .rrd files because they're owned by the smokeping user and it's the smokeping processes which I showed you which do the writing. When smokeping is started by root it could have root permissions, but the startup script relinquishes them. The Web server does just the same thing when it starts, it's very common to do this kind of thing for security. The server processes which serve pages (so are exposed to attack) have restricted permissions. Once upon a time user and group for Apache processes would be 'nobody' and 'nobody' (or 'nogroup') just to emphasize this intentional lowliness of Web server processes. Someone else on this thread said that your Web server should be able to write the .rrd files, and that might well be the case in version 2.4.0 of smokeping. You can easily test that. Instead of giving the world write permission to the files, simply change the 'group' of the files to a group that your Web server is in, and then make the files group writeable. Assuming that Apache is a member of group 'nogroup': chgrp nogroup smokepingfilename chmod 664 smokepingfilename The first command sets the group ownership to nogroup, the second gives read/write to owner and group, read-only to everyone else. You'd need to be root to do this. If this has the desired effect then we're a little further forward but then I think I'd need to take a look at the 2.4.0 code before saying much more. Perhaps Tobi would be able to save us some time, which is why I've mailed this to him too. > I don't have a separate config file for the slaves ... they're just > included in the main smokeping config file. It doesn't matter, as long as smokeping can find the configuration. -- 73, Ged. _______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
