[rrd-developers] RRDCacheD - Client rewriting path

[Sebastian Harl]

Hi Tobi,

On Sat, Sep 26, 2009 at 12:24:14AM +0200, Tobias Oetiker wrote:
> Yesterday Sebastian Harl wrote:
> > On Tue, Aug 11, 2009 at 10:44:17AM +0200, Sebastian Harl wrote:
> > > On Tue, Aug 11, 2009 at 07:48:30AM +0200, Tobias Oetiker wrote:
> > > > I guess its time to finally push out 1.4 so that the code can move
> > > > again ...
> > >
> > > As much as I'd hate to further delay the 1.4 release, I think we should
> > > come to a conclusion about further directions first. Else, we might end
> > > up with some functionality (I'm e.g. thinking about the client side path
> > > "translation") that's going to be hard to support in the future. I know
> > > how much you hate to break backward-compatibility, so let's try to avoid
> > > some trouble trying to keep that up.
> >
> > Any further comments on that? Tobi, what do you think about regarding
> > RRDCacheD as either a fully networked daemon or some local acceleration
> > daemon? As much as I hate repeating myself, I think this should be
> > sorted out before 1.4 ?
> 
> as I see it, rrdcached in 1.4 is a local acceleration daemon with
> some network abilities for the adventurous (since there is neither
> authentication nor authorization built in)

Side note: I don't think networking support is for the adventurous only.
There are *plenty* of other ways to make that secure, depending on your
setup. You just need to know, what you're doing (which is something I'd
expect from any serious users of RRDCacheD - the others will probably be
screwed anyway, as they're gonna have tons of other problems).

The collectd network plugin did not have auth* built-in for a long time.
Sure, there were some users requesting that every once in a while but it
did not seem to be any kind of show stopper for a large number of
people.

> this also means that use of the daemon should be transparent,
> to use ... for file paths this means at least when running local,
> that the curent directory of the rrdupdate command does matter ...
> 
> when running remotely this is not the case and should probably  be
> handled differenly ...

Hrm … as I might have mentioned before, I'm not a big fan of inconsis-
tent behavior - even it that's supposed to handle some specific cases
"more elegant". Imho that adds more confusion than benefit. Anyway, the
final decision is up to you, of course.

> but then again, remote use of rrdcached will see some further changes
> with authentication and authorization anyway ...

Yes, but (as far as I see it) that should be possible without breaking
backward-compatibility (since the fine-grained permission handling has
been included).

Changing the path-name handling (either way) should not be hard to
implement. I'm willing to provide a patch for that once we've come to a
conclusion about how to do it.

> I will have time to spend on all my OSS projects in the next few
> weeks and will do so. The means 1.4 will definitly come RSN (;

Great! :-)

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/20090926/5369e859/attachment.pgp