[rrd-developers] RRDCacheD - Client rewriting path

[Sebastian Harl]

Hi,

On Mon, Aug 10, 2009 at 09:51:26PM +0200, Florian Forster wrote:
> On Sat, Aug 08, 2009 at 12:22:26PM +0200, Yann Jouanin wrote:
> > 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.
[…]

Thanks for being a bit more verbose about that than I was. I fully agree
with this differentiation.

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

Imho, if we're going to decide that this is _not_ what we want in the
long run, we should seriously think about removing networking support
again (which would have to happen now, before releasing 1.4). Imho,
having something that exist just because it was easy to implement but is
not really supported (as in: having some somewhat "half-baked" solution)
by the developers causes more pain than good.

Anyway, I don't think that this is what you want, so lets try to make
this a real network daemon :-)

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

Ack! Let's not put too much magic into the core.

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

That would imho be fine though as long as a (library) user still has
access to non-magical functions as well to be able to _explicitly_ state
what's supposed to be going on.

>   * 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.

Sounds good to me.

>     (Personally I like the “user at host:path” syntax of ‘scp’ best, but I
>     fear that there could be incompatibilities.)

Hrm … scp needs that to be able to tell apart absolute path names from
relative path names. Since we don't need / want that, I'd actually
prefer the solution suggested above.

>   * 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.

So, if those variables are defined, a user could simply use some
relative path name ("some/path/name.rrd") to access the daemon and that
path would be sent to the daemon without any modifications on the client
side? Imho, that would be the only sensible approach - handling some
special cases differently imho introduces too much magic that would
definitely cause a lot more confusion.

>   * 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.

Sounds good imho.

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

Well, that has the most potential for causing confusion but, then again,
the user should know what she's doing when using such features.

> Other than that, I think the above approach is pretty straight forward
> and easy to understand.

Full ack!

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090811/4ebfecc7/attachment.bin