2.1 Configure johd Sockets

Johd reads its configuration from the command line. Only the traditional short options are used. The order in which you place options is important: some of them affect others that appear further in the command line.

The ‘-l’ option configures a socket to listen on (hence its mnemonics: listen). Its argument is an URL or address specification for the socket. Normally, this specification is the desired IP address and port number, separated by a colon. For example, to have johd listen on IP address 127.0.0.1, port 1111, you would write:

 
johd -l 127.0.0.1:1111

If you wish it to listen on a given port on all configured network interfaces, just specify that port alone, without a specific IP address, as in:

 
johd -l 1111

In fact, Johd is able to work with three distinct socket families: UNIX sockets, IPv4 and IPv6 inet addresses. There are various ways to specify these. For a detailed discussion of them, see URLs.

Any number of ‘-l’ options can be given: johd will open all required sockets and will listen for connections on any of them.

The important point is the class of the socket to open. As you already know, johd works with two distinct socket classes: HTTP sockets, which are supposed to receive data formatted in accordance with the HTTP protocol, and auxiliary CGI sockets, which are designed to communicate with joh.cgi. By default, the latter is assumed(2). The class of the socket to open is changed by the ‘-c’ command line option: ‘-c HTTP’ tells johd to open all subsequent sockets for listening on HTTP requests, and ‘-c CGI’ instructs it to open them for handling internal CGI protocol data. The ‘-c’ option affects all ‘-l’ options that appear to the right of it in the command line, until another ‘-c’ option is encountered, which changes the default. To illustrate this, consider the following invocation:

 
johd -l 127.0.0.1:1111 \
     -c HTTP -l 10.10.0.1 -l 192.168.0.2 \
     -c CGI 10.10.0.1

It opens two sockets for auxiliary CGI: one at 127.0.0.1:1111 (it appeared before the first ‘-c’ option and therefore belongs to the default class, which is ‘CGI’) and the other at 10.10.0.1, which appears after an explicit ‘-c CGI’. Notice that this later has no port specification. If the port is missing. johd will select the default port for this class. The default port for ‘CGI’ is 1100(3), and the default for ‘HTTP’ is, of course, 80. Therefore, the command above will listen for HTTP requests on 10.10.0.1:80 and 192.168.0.2:80.

Each incoming connection is validated via TCP wrappers(4). The default daemon (or service) name for validation coincides with the name johd was invoked with (i.e. is ‘johd’, unless you renamed the program or started it via a symlink). However, the validation rules will most probably depend on the class of socket that received the connection: internal ‘CGI’ sockets in most cases should not be visible outside your host, whereas ‘HTTP’ ones should be accessible to everybody, Therefore, a special option is provided, which changes the TCP wrapper service name for subsequent sockets. This is the ‘-S’ option (mnemonics: Service name). Similarly to ‘-c’, the ‘-S’ option affects all ‘-l’ options to the right of it, until another ‘-S’ option or end of the command line is encountered, whichever occurs first.

Now, let's illustrate this by an improved version the example above:

 
johd -l 127.0.0.1:1111 \
     -S johd-http -c HTTP -l 10.10.0.1 -l 192.168.0.2 \
     -s johd-cgi -c CGI 10.10.0.1

In this configuration, the 127.0.0.1:1111 socket will be protected by the TCP service name ‘johd’, the two ‘HTTP’ sockets — by service name ‘johd-http’ and the ‘CGI’ socket 10.10.0.1 — by service name ‘johd-cgi’.

Connections to remote Jabber servers are also validated using TCP wrappers. However, they use different service name. The service name for validating a requested jabber connection is created using the following pattern:

 
srvname/jabber@ipaddr

where srvname is the TCP service name, as described above, and ipaddr is the IP address of the server.

Footnotes

(2)

The decision which class to take as the default is somehow arbitrary, we might as well have chosen HTTP, but historically it happened to be CGI.

(3)

Again, the choice was somewhat arbitrary, but we know of no other service using this number.

(4)

See hosts_access(5), for detailed description of TCP wrapper access control files.

Note also, that this feature can be disabled at compile time, by the ‘--without-tcp-wrappers’ option to configure, although this is highly unrecommended.