[rrd-developers] rrdcached daemonize failed, exiting

[Tobias Oetiker]

Hi Kevin,

> How would the client decide which way to send?  Do we try to differentiate
> between local and remote inet sockets?

this or via an option ...

> I think the most common use case is local rrdcached, in which case I think
> having the client use realpath() makes the most sense.  That preserves the
> user's ability to refer to the file by any relative file name (the
> expected result).  Also, it permits us to use the path-based restrictions
> I mentioned earlier.

I agree for the local case it makes total sense ...

> ( 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 ... ?

> If we have to get into mapping file locations between client and server,
> that could get really hairy.  I see five paths that make sense for
> exposing rrdcached over a network:
>
>  (1) a client option --base "/my/base" that points to the same location as
>      the rrdcached's -b "/server/base".  Matching environment variable
>      $RRDCACHED_BASE.
>
>      PRO: allows for arbitrary remapping, relative paths sent to daemon
>      CON: need to convert absolute paths to relative

my idea was, that for the 'remote case', the path of the rrd file
is like some sort of url. In the same way, you do not see the
document_root in the url, the client would not know aber the root
of the server. It would access the rrd files in some 'virtual'
file tree which is based at the -b root of the server.


>  (2) a client option --relative (and matching $ENV) that instruct the
>      client not to make the paths absolute.
>
>      PRO: easy to implement
>      CON: client needs to chdir(base directory) for paths to make sense
>           both locally and remote
>
>  (3) rrdcached knows about the its clients, and where its base dir is
>      mounted on their systems
>
>      PRO: clients continue to realpath() their paths
>           - users can address file by any valid path
>           - simpler client API
>           - resolves any sym-links and relative paths
>
>      CON: how to keep rrdcached up to date?  stop/start to add more
>           clients doesn't make sense

hmm this is interesting, becaust in all likelyhood there should be
only one client for each rrd file ...

>  (4) rrdcached-like proxy on the client machine that translates paths?
>
>      PRO: no extra work on client or caching daemon
>      CON: another moving part, perhaps unnecessary?
>
>  (5) require same mount point
>      CON: obvoius
>
> I see two main install types for rrdcached..  This is what I would target:
>
> (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 ...

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.

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.

> (I2) large collection systems
>      - purpose is to distribute polling load
>      - users on the polling systems need to handle path discrepancy
>        between pollers and storage
>         - likely to be common administration
>         - we can expect them to do it themselves if we provide the switches
>      - users on the rrdcached system work just like "local service" above

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.

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.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900