[rrd-developers] RRDCacheD - Client rewriting path

[Florian Forster]

Hi,

I have talked to Sebastian in person about this, but I think it'd be
good if I repeat this here:

On Sat, Aug 08, 2009 at 12:22:26PM +0200, Yann Jouanin wrote:
> It seems the behavior of RRD client when using RRDCacheD can make
> trouble when using RRDCacheD on another host than the one where using
> client.

The intention behind RRDCacheD was to move the cache outside of the
clients and into a generic daemon. The client would communicate with the
daemon using UNIX domain sockets and in general is was just two parts of
one application glued together by some IPC. That's why the relative path
behavior basically assumes that the daemon is on the same host.

The network sockets were just added because it was only a couple of
lines extra code. They were initially not meant to be used in
production.

> The translation between relative path and absolute path is done in
> client code (rrdc_flush) while it should only be done by the server.

No. Yes. Well, this depends on whether you regard RRDCacheD as a local
acceleration cache or a remote, networked daemon.

  * If you regard RRDCacheD as a rather complex abstraction layer over
    your local RRD files, then having the client resolve relative names
    is just the thing to do. It is hard for the daemon to figure out the
    client's current working directory, as Kevin has pointed out.

      Pro: Transparent and fast update. Existing applications don't need
           to be changed.
      Con: Limitation to the same host.


  * If RRDCacheD is a normal networked daemon for you, then having a
    daemon base directory and denying all absolute paths is probably the
    best thing you can do. However, if we do that, we should definitely
    follow through: Then *all* file access has to happen via the daemon,
    not just write (update) access. This means we need to add read-
    (fetch), create-, and delete-commands as well. Sooner or later we
    also need some sort of file browsing.

      Pro: More flexibility when designing setups. Possibly better
           scalability. I have the impression a lot of people want this.
      Con: Transparency is compromised; existing applications need to
           handle this somehow. Security becomes an issue.

On Mon, Aug 10, 2009 at 10:10:38AM +0200, Sebastian Harl wrote:
> I think that by following the principle of least surprise RRDcacheD
> should behave like that as well. Let people think about $HOST:1.rrd
> instead of 1.rrd (where $HOST might be remote or local) - we're
> referring to a file on some $HOST after all …

If the daemon should work as a real network daemon, then this style of
addressing is the way to go in my opinion. IIrc this was the outcome of
our discussion about the ‘rrdc_fetch’ patch I have sent a while back (I
have some docs ready by the way, I'll send an updated patch soon).

In my ideal world, this would look somewhat like this:

  * The ‘rrd_*_r’ functions always work on local files, the ‘rrdc_*’
    always use a daemon connection. Maybe it'd be a good idea to rename
    the `rrd_*_r' functions. ‘rrdl_*’ (‘l’ as in “local”) comes to mind.

  * Some magical version of the functions will check some sort of
    environment and call the appropriate function.

  * Files are addressed using some special syntax. Using something like
      rrdcache://user@host/relative/path
    could work okay. If ‘user’ is omitted, the local user name is used.
    The paths are always relative paths so the administrator can be sure
    all the files controlled by the daemon are beneath one directory.
    File names that do not contain “://” are assumed to be local files.
    (Personally I like the “user at host:path” syntax of ‘scp’ best, but I
    fear that there could be incompatibilities.)

  * The ‘RRDCACHE_HOST’ and ‘RRDCACHE_USER’ environment variables can be
    used to avoid the special syntax. If they are set, the daemon will
    be used.

  * To authenticate, the client code looks for a file called
    ~/.rrdcache_privkey which contains a private key file (the public
    key is required on the server and should be associated with the user
    name). If found, public key authentication is attempted, possibly
    via TLS.

    If no such file exists, the code will check for a password in
    ~/.rrdcache_password and, if found, will use it for password
    authentication.

    If neither file exists and the process has a controlling terminal,
    then it will try to read a password from /dev/console.

    If all else fails, try authenticating with an empty password.

> So, maybe the actual problem is that too much magic has been put into
> the way the daemon may be enabled (on the client side).

I hope the environment variables don't add too much confusion. Other
than that, I think the above approach is pretty straight forward and
easy to understand.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090810/91b76006/attachment.bin