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://u...@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 “u...@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/
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers