Sending commands to clients

It is generally not possible to send commands to clients, because the client does not listen on the network (the client needs root privileges to perform its tasks, and you don't want a root network daemon).

However, it is possible to send a command if and when a client connects to deliver a message. As of version 1.8.0, clients use a new version of the client/server protocol, which includes a set of pre-defined commands that are understood by the client. Currently implemented are RELOAD to reload the configuration, and STOP to terminate the client.

Pre-1.8.0 clients, or clients build with the (optional) old protocol version, will simply ignore such commands.

Asking the server to send a command

As of version 1.8.0, yule can send a command to a client if and when a client connects to deliver a message, e.g. a timestamp message (clients are not listening on the network, and thus commands can only be sent together with the confirmation when a message is received).

Of course the server needs to know which (if any) command to send. Therefore it can open a unix domain socket upon startup (in the same directory as the PID file). Opening this command interface must be requested explicitely with the option SetUseSocket=yes (in the [Misc] section).

A separate application yulectl is compiled together with the server that provides a command-line interface to access this facility. Use yulectl -h for help.

Currently, authentication is done by passing the credentials of the socket peer to the server (this is a special feature of unix domain sockets), and requiring the UID of the the socket peer (i.e. the user using the yulectl program) to match a UID as set with the SetSocketAllowUid=UID option (default is 0, i.e. only root can use the interface). On systems where passing of credentials is unsupported (Solaris, probably also AIX, HP-UX), the socket interface will not be opened by the server.

If passing credentials is supported by the OS, it is not possible to fake these credentials - they are supplied by the kernel. Therefore, the server can rely on the fact that the user process writing to the socket has indeed the UID passed via the socket. Thus, the access rights to the socket are basically not important (on some systems, they are not even recognized/respected at all).