[rrd-developers] rrdcached daemonize failed, exiting
kbrint at rufus.net
Wed Sep 24 23:39:55 CEST 2008
On Wed, Sep 24, 2008 at 11:27:39PM +0200, Tobias Oetiker wrote:
>> ( Also, keep in mind that realpath() will also resolve sym-links and
>> ../../etc. This is important when we consider that the rrdcached data
>> structure only keys by strcmp(). If the client makes it absolute that
>> is very helpful )
> it will no resolve bind mounts I guess ... ?
Not sure what you mean.
>> (I1) as a local service
>> - purpose is largely to ease disk burden
>> - cannot expect users to know cached is present
>> - optimize for the use cases that work today
>> - i.e. refer to file by any valid path
> yes this was the original idea, i think we got this pat-down. The
> only issue to solve here is how to provide read-only access through
> the daemon for setups where some users can read the rrds while
> others can read and write ...
I like the two-sockets approach.. Let the users pick which sockets are
read-write vs. read-only, and advise them to protect the read-write
sockets with UNIX permissions.. Optionally, force inet sockets to be
> one option here would be to service two sockets, one allows all
> operations while the other only accepts the flush commands. The two
> sockets would go into two sub directories with different user
> permissions it would not be as fine grain as the file system, but it
> should get us along way.
The read-write should be a Unix-domain socket protected by the same Unix
permissions as the RRD files themselves. Anyone that could write the
files could also just clobber the RRDs.
The read-only socket can be a network socket on localhost..
This is what I'm doing on my environment. All users inherit the
$RRDCACHED_ADDRESS environment variable when logging in, and it points to
the network socket. Once I add the read-vs-read/write, I'll start
pointing my pollers to a separate, protected, Unix socket.
> another option would be to identify the process that is connecting
> the socket (at least on linux this is possible as fahr as I know)
> the daemon could then ensure that the owner of the process has the
> respective rights on the rrd file.
Not portable at all.
> Maybe we should forget about 'remote access' alltogether. After
> all, we are duplicating effort here in designing yet another server
> ... even rrdtool itself can be run as a service via inted.
Yes, let's get rid of it for now.
The protocol is simple enough to implement; if someone needed remote
socket operations they could (theoretically) write their own client.
> In the real world, the while networking stuff may well happen in
> the application layer above rrdtool. After all there is no real
> advantage in being able to run rrdtool update remotely as oposed to
> pushing the numbers collected to a webserver or some other service
> on the server. This would relieve us from even thinking about all the
> remote access issues.
I think it's best left for later.
Patches to follow...
kevin brintnall =~ /kbrint at rufus.net/
More information about the rrd-developers