[rrd-developers] rrdcached daemonize failed, exiting

[kevin brintnall]

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
read-only.

> 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/