Rserve is configured by the configuration file /etc/Rserv.conf (can be changed at compile time by specifying -DCONFIG_FILE=..). Additional configuration files can be added by the --RS-conf command line argument. The possible configuration entries are as follows (all entries are optional; default values are in angled brackets):
workdir <path> [/tmp/Rserv]
pwdfile <file> [none=disabled]
remote enable|disable [disable]
auth required|disable [disable]
plaintext enable|disable [disable]
fileio enable|disable [enable]
interactive yes|no [yes] (since 0.6-2)
(since version 0.1-9):
socket <socket> [none=disabled]
port <port> 
maxinbuf <size in kb> 
(since version 0.3):
maxsendbuf <size in kb> [0=unlimited]
uid <uid> [none]
gid <gid> [none]
su now|server|client [none] (since 0.6-1)
(since version 0.3-16):
(since version 0.5 and unix only):
chroot <directory> [none]
sockmod <mode> [0=default]
umask <mask> 
(since version 0.5-3):
encoding native|utf8|latin1 [native]
(since version 0.6-2):
The list is now too long so best sources are the NEWS file and the rserve.conf Wiki on GitHub
Since 0.5 the following configuration options can use either hexadecimal (0x..), octal (0..) or decimal values: port, uid, gid, umask and sockmode. All other options and command-line options always assume decimal notation.
Most entries are self-explaining and their command line equivalents are described below. maxinbuf and maxsendbuf are rather special. Previous versions of Rserve had fixed buffer sizes. Since 0.1-9 internal buffers change per-connection automatically. The maxinbuf specifies (in kilobytes) the maximal allowable size of the input buffer, that is the maximal size of data transported from the client to the server. Analogously maxsendbuf sets the maximum size of the send buffer, that is the size of data sent from Rserve to the client. If your server is likely to process very many parallel connections you may want to lower this setting for security reasons. On the other hand if the server will process only few connections in parallel and you expect very large data, raise the value accorsing to your computer's memory. Baiscally the settings are present to prevent malicious users from crashing your server by supplying too large data. 0 has a special meaning telling Rserve to allow unlimited use.
uid, gid, umask and chroot are supported on unix computers only. If Rserve is run as root user, then it switches the user/group to the specified uid/gid before starting the server. Note: The directives are processed in the same sequence in which they occur in the config file. This implies that if using both uid and gid, you MUST use gid first, otherwise if setting uid first, then the user will have no right to change gid anymore! Also chroot must be used before uid as only root can use it.
A note about security: Anyone with access to R has access to the shell
via "system" command, so you should consider following rules:
NEVER EVER run Rserv as root (unless uid/gid entries are set) - this compromises the box totally
Use "remote disable" whenever you don't need remote access.
If you need remote access use "auth required" and "plaintext disable".
Consider also that anyone with the access can decipher other's passwords
if he knows how to. The authentication prevents hackers from the net
to break into Rserve, but it doesn't (and cannot) protect from
inside attacks (since R has no security measures).
You should also use a special, restricted user for running Rserv
as a public server, so noone can try to hack the box it runs on.
don't enable plaintext unless you really have to. Passing passwords
in plain text over the net is not wise and not necessary since both
Rserv and JRclient provide encrypted passwords with server-side
challenge (thus safe from sniffing).
- On unix consider using su client and cachepwd yes options with a password file that is only root-readable. That will prevent client password retrieval and clients from attacking the server (see NEWS for 0.6-1).
String encoding directive was introduced in Rserve 0.5-3. This means
that strings are converted to the given encoding before being sent to
the client and also all strings from the client are assumed to come
from the given encoding. (Previously the strings were always passed
as-is with no conversion). The currently supported encodings are
"native" (same as the server session locale), "utf8" and "latin1". The
server default is currently "native" for compatibility with previous
versions (but may change to "utf8" in the future, so explicit use of
encoding in the config file is advised).
If a server is used mainly by Java clients, it is advisable to set the
server encoding to "utf8" since that it the only encoding supported by
Java clients. (i.e. add encoding utf8 line to the config file).
For efficiency it is still advisable to run Rserve in the same locale
as the majority of clients to minimize the necessary conversions. With
diverse clients UTF-8 is the most versatile encoding for the server to
run in while it can still serve latin1 clients as well.