diff --git a/doc/rrdcached.pod b/doc/rrdcached.pod
index c75b9e0e415bc3bd317b9003432e93bb857f6928..fd565239845be1bca72f1e6636022ff451f20ffa 100644 (file)
--- a/doc/rrdcached.pod
+++ b/doc/rrdcached.pod
=head1 SYNOPSIS
-B<rrdcached> [B<-l> I<address>] [B<-w> I<timeout>] [B<-z> I<delay>] [B<-f> I<timeout>] [B<-j> I<dir>] [-F]
+B<rrdcached> [B<-l/-L> I<address>] [B<-w> I<timeout>] [B<-z> I<delay>] [B<-f> I<timeout>] [B<-j> I<dir>] [-F] [B<-b> I<dir> [B<-B>]]
=head1 DESCRIPTION
If the B<-l> option is not specified the default address,
C<unix:/tmp/rrdcached.sock>, will be used.
+=item B<-L> I<address>
+
+Same as B<-l>, except creates a low-privilege socket. See B<SECURITY
+CONSIDERATIONS> for more information.
+
=item B<-w> I<timeout>
Data is written to disk every I<timeout> seconds. If this option is not
updated by the daemon, assuming the base directory
"/tmp".
+=item B<-B>
+
+Only permit writes into the base directory specified in B<-b> (and any
+sub-directories). This does B<NOT> detect symbolic links. Paths
+containing C<../> will also be blocked.
+
=back
-=head1 EFFECTED RRDTOOL COMMANDS
+=head1 AFFECTED RRDTOOL COMMANDS
The following commands may be made aware of the B<rrdcached> using the command
line argument B<--daemon> or the environment variable B<RRDCACHED_ADDRESS>:
are printed to C<STDERR>. One of the steps when starting up is to fork to the
background and closing C<STDERR> - after this writing directly to the user is
no longer possible. Once this has happened, the daemon will send log messages
-to the system logging daemon using L<syslog(3)>. The facility used it
+to the system logging daemon using L<syslog(3)>. The facility used is
C<LOG_DAEMON>.
=head1 HOW IT WORKS
+---+----+---+ +------+-----+ +---+----+---+
! File: foo ! ! File: bar ! ! File: qux !
! First: 101 ! ! First: 119 ! ! First: 180 !
- ! Next: ---+--->! Next: ---+---> ... --->! Next: - !
+ ! Next:&bar -+--->! Next:&... -+---> ... --->! Next:NULL !
+ | Prev:NULL !<---+-Prev:&foo !<--- ... ----+-Prev: &... !
+============+ +============+ +============+
! Time: 100 ! ! Time: 120 ! ! Time: 180 !
! Value: 10 ! ! Value: 0.1 ! ! Value: 2,2 !
=head1 SECURITY CONSIDERATIONS
-This daemon is meant to improve IOE<nbsp>performance for setups with thousands
-of RRDE<nbsp>file to be updated. So security measures built into the daemon can
-be summarized easily: B<There is no security built in!>
+The client/server protocol does not have any authentication or
+authorization mechanism. Therefore, take care to restrict which users can
+connect to the daemon.
+
+Control sockets are divided into high-privilege (B<-l>) and low-privilege
+(B<-L>) sockets. High-privilege sockets accept all commands, whereas
+low-privilege sockets accept only B<FLUSH>, B<STATS>, and B<HELP>.
+
+For a multi-user environment where only certain users require read/write
+access, the recommended configuration uses two sockets as follows:
+
+=over
+
+=item B<-l> I</protected/dir/rrd.sock>
-There is no authentication and authorization, so B<you> will have to take care
-that only authorized clients can talk to the daemon. Since we assume that graph
-collection is done on a dedicated machine, i.E<nbsp>e. the box doesn't do
-anything else and especially does not have any interactive logins other than
-root, a UNIX domain socket should take care of that.
+Create a high-privilege unix-domain socket. This should be protected with
+the same Unix permissions that are used to protect the RRD files. Updates
+should be directed to this socket.
+
+=item B<-L> I<127.0.0.1>
+
+Create a low-privilege TCP socket listening on localhost. All users on
+the local system may use this to trigger FLUSH of individual files. Users
+with read-only access should be directed to this socket.
+
+=back
If you (want to) use the network capability, i.E<nbsp>e. let the daemon bind to
an IPv4 or IPv6 socket, it is B<your> job to install a packet filter or similar
Causes the daemon to start flushing ALL pending values to disk. This
returns immediately, even though the writes may take a long time.
+=item B<PENDING> I<filename>
+
+Shows any "pending" updates for a file, in order. The updates shown have
+not yet been written to the underlying RRD file.
+
+=item B<FORGET> I<filename>
+
+Removes I<filename> from the cache. Any pending updates B<WILL BE LOST>.
+
=item B<HELP> [I<command>]
Returns a short usage message. If no command is given, or I<command> is
updates have already been applied. It is I<only> valid in the journal; it
is not accepted from the other command channels.
+=item B<BATCH>
+
+This command initiates the bulk load of multiple commands. This is
+designed for installations with extremely high update rates, since it
+permits more than one command to be issued per read() and write().
+
+All commands are executed just as they would be if given individually,
+except for output to the user. Messages indicating success are
+suppressed, and error messages are delayed until the client is finished.
+
+Command processing is finished when the client sends a dot (".") on its
+own line. After the client has finished, the server responds with an
+error count and the list of error messages (if any). Each error messages
+indicates the number of the command to which it corresponds, and the error
+message itself. The first user command after B<BATCH> is command number one.
+
+ client: BATCH
+ server: 0 Go ahead. End with dot '.' on its own line.
+ client: UPDATE x.rrd N:1:2:3 <--- command #1
+ client: UPDATE y.rrd N:3:4:5 <--- command #2
+ client: and so on...
+ client: .
+ server: 2 Errors
+ server: 1 message for command 1
+ server: 12 message for command 12
+
=back
=head2 Performance Values