Classic Chat

Never count the old dogs out: The IRC protocol, which was very popular in the bubble at the beginning of this millennium, is slightly less fashionable today, but undeservedly so because it offers a resource-friendly way of supporting text-based communication among staff in a corporate environment. Thus far, none of IRC's various protocol successors has even come close to finding as convenient an approach for allowing large groups of people to visit a single chatroom. At the same time, IRC impresses with absolutely minimal hardware requirements: You can easily set up an IRC server for several hundred users on legacy hardware, and IRC clients are plentiful, no matter what operating system you need to accommodate. In many cases, an IRC client is even part of the standard scope of a large IM solution (such as Gaim or Adium).

If sys admins are looking for an option to offer company employees a communication path via chat, IRC is a sensible solution. Because IRC is a few years old, you will find countless IRC server variants. Almost all originate from the original code, which is still in use today on IRCNet [1] and comes closest to the original IRC RFC [2]. Additionally, you will find a plethora of successors and forks: Each of the large public IRC networks has its own fork, and various forks exist in the form of private projects. The rising star among IRC servers in recent years has been Ratbox IRCd. The original Ratbox IRCd version is used on EFnet and the well-known OSS IRC network Freenode. (Freenode uses ircd-seven, a descendant of Charybdis and a Ratbox fork).

Installing Ratbox

If you want to run an IRC server with Ratbox, you need to do some work first: The distributions years ago abandoned the attempt to offer finished packets for the existing IRC server – only Ubuntu has a Ratbox package. For other distros, the Ratbox source files are available at the project website [3]. After unzipping, you can install with the classic three-command trick of configure, make, and make install.

That Ratbox uses /usr/local/ircd (Figure 1) as its default location prefix and not /usr/local does seem strange at first. If you would like to install the IRCd in /usr/local, use the --prefix= parameter to point configure in the right direction. Administrators also usually want to change the parameters that define the maximum length of nicknames on the IRC network and the maximum length of channel topics. By default, Ratbox uses nine characters (nickname) and 180 characters (topic), but this default is no longer ideal. The configure parameters --with-topiclen= and --with-nicklen= let you change the parameters. Last but not least, SSL also plays a role: Ratbox can run IRC over SSL, but libssl-dev is the prerequisite for this configuration. If you want SSL to work, you need to prepare the system accordingly.

IRCd Configuration

After the install, you need to configure the IRC server. This mainly involves a file called ircd.conf, which has to reside in /usr/local/ircd/etc/ircd.conf if you are using the default prefix. If you have configured an IRC server previously, you will remember the rather cryptic syntax, consisting of I-lines, O-lines, C-lines, and the infamous K-lines, to lock out users from the server. This syntax has completely disappeared from Ratbox; instead, a syntax with separate configuration sections makes the configuration much easier to understand.

Although it is beyond the scope of this article to address each and every parameter in the IRCd configuration separately, if you look at the source code folder in Ratbox, you fill find an example.conf as the basis for your ircd.conf in doc. Many entries in ircd.conf are self-explanatory (e.g., the serverinfo section in the sample contains the entry hades.arpa, which you need to replace with the name of your IRC server (that doesn't have to be a DNS-resolvable hostname).

The same section also needs to contain the name of the IRC network and a short description of this server. The ports on which Ratbox waits for incoming connections should also be defined (the classic IRC port is almost always 6667, which is the preset for most clients).

The auth section is interesting because this is where admins determine who can connect with the IRC server. This type of entry can occur multiple times in the configuration to allow various IP ranges or hosts access. The spoofed keyword is also interesting: spoofed lets you change the host of a person shown within the IRC network. For example, if you run an IRC server not only for internal communication in the company but also to allow customers access for support, you can designate company employees in this way. Finally, you can use a class definition to set up user classes to which individual auth sections are then assigned. Thanks to this system of user classes, you can define how many users can simultaneously connect to the server for each auth entry, how long the server should wait after the user fails to respond to PING requests before terminating, and how big to make the internal buffers the server creates for connected clients.

User and Operator Flags

The principle of user flags and operator flags has existed in IRC since the beginning. Flags allow users to access certain functions; in the case of administrators, flags provide information on the commands that admins can execute (Figure 2). The flags are assigned by the flags = keyword in ircd.conf, either in the auth block or the operator block. A detailed overview of the operator and user flags available in Ratbox can be found directly in example.conf, and the available operator flags are illustrated by the example.conf operator block. Incidentally: User flags can be enabled by the users, if they are allowed in the appropriate auth block. To use operator flags, you first need to log in as an operator to the IRC server. The command for this is opera.

MOTD

Ratbox optionally shows users a Message of the Day (MOTD) on opening a connection to the IRC server that can be used to post information relating to the use of the IRC server itself or for general informational purposes (e.g., the latest company announcement; Figure 3). Ratbox shows the ircd.motd content for the message; the file is located in the same folder as ircd.conf. No syntax is defined, but many IRC admins display a company logo generated with figlet. If the MOTD is not displayed, even though the file exists, it is a good idea to check permissions: Ratbox doesn't issue an error message that it can't read ircd.motd; it just doesn't display a MOTD.

Ratbox Services

IRC Services are found on virtually all IRC networks, with the exception of IRCnet. The IRC standard itself doesn't define these services, but with increasing awareness of IRC, the desire for certain features quickly arose. For example, many users want to register a nickname on the IRC network so others do not use it. Channels can also be registered in this way; the IRC services provide a meaningful replacement if IRC robots try to grab channels.

Ratbot Services is available for Ubuntu; on other systems: You need to install manually, but configure, make, and make install are again all you need. If you change the values for topiclen and nicklen in Ratbox, you should do so for Ratbox Services, too; otherwise, the services can't connect with Ratbox. An extensive example.conf is available in the configuration folder for ratbox-services.conf. After installing and configuring the services, the next step is to connect the actual IRCd with the services.

Server-to-Server Connection

The ability to connect an IRC server with another to create a contiguous network is something that all IRC servers offer. Service suites typically leverage this ability. Instead of using a separate client to connect to the server for each service (NickServ, ChanServ, NoteServ, etc.), the service daemon connects to an existing server on the network as an IRC server and acts just like an IRC server after doing so. For this to work, you need to configure both the existing Ratbox servers and the service to reflect these circumstances.

Your Ratbox ircd.conf first needs a class to which the IRCd server organizes the connections. Listing 1 shows a complete example of such a class called server.

01 class "server" {
02
03         ping_time = 5 minutes;
04
05         /* connectfreq: only used in server classes.  specifies the delay
06          * between autoconnecting to servers.
07          */
08         connectfreq = 5 minutes;
09
10         /* max number: the amount of servers to autoconnect to */
11         max_number = 1;
12
13         /* sendq: servers need a higher sendq as they send more data */
14         sendq=2 megabytes;
15 };

Additionally, ircd.conf lacks a block that allows connections to other servers; these are identified by the connect keyword. In this example, a connection to the services server could look like Listing 2, which contains a complete example.

01 /* connect {}: controls servers we connect to (OLD C:, N:, H:, L:) */
02 connect "services.irc.hastexo.com" {
03         /* the name must go above */
04
05         /* host: the host or IP to connect to.  If a hostname is used it
06          * must match the reverse dns of the server.
07          * /
08         host = "10.42.0.1";
09
10         /* passwords: the passwords we send (OLD C:) and accept (OLD N:).
11          * The remote server will have these passwords reversed.
12          */
13         send_password = "topsecret";
14         accept_password = "topsecret";
15
16         /* port: the port to connect to this server on */
17         port = 5556;
18
19         /* hub mask: the mask of servers that this server may hub. Multiple
20          * entries are permitted
21          */
22         hub_mask = "*";
23
24         /* class: the class this server is in */
25         class = "server";
26
27         /* flags: controls special options for this server
28          * encrypted    - marks the accept_password as being crypt()'d
29          * autoconn     - automatically connect to this server
30          * compressed   - compress traffic via ziplinks
31          * topicburst   - burst topics between servers
32          */
33         flags = compressed, topicburst;
34 };

In particular, make sure the entry directly following connect matches the services name in ratbox-services.conf. The port specification at this point is non-functional because the services connect with the IRC server; this principle does not work in reverse.

Finally, the services block itself should look like the code shown in Listing 3 (replace services.irc.hastexo.com with the name actually used by the services):

01 service {
02         /* name: the server name. These may be stacked. */
03         name = "services.irc.hastexo.com";
04 };

Setting Up a Services Connection

Finally, the services all need to know where to connect. In the example, you first need to set the name entry in the serverinfo block of ratbox-services.conf to services.irc.hastexo.com, as shown in Listing 2. Also set the vhost to match.

Then, ratbox-services.conf also needs a complete block with the connect keyword; Listing 4 shows an example. The connect keyword, in turn, is followed by the name, as specified for Ratbox in ircd.conf.

01 connect "irc.hastexo.com" {
02         /* host: the host to connect to */
03         host = "10.42.0.1";
04
05         /* password: the password to use */
06         password = "sehrgeheim";
07
08         /* port: the port to connect on */
09         port = 5555;
10
11         /* autoconn: auto connect to this server.  default yes */
12         autoconn = yes;
13 };

You can see in the server messages from Ratbox whether or not the configuration is working; you need to be logged in as an operator to see the server messages. As soon as the services are connected with Ratbox, the services are available. If the administrator of the IRC server also adds an operator account to ratbox-services (the commented example file provides a template), IRC admins on IRC can log in to the services as admins [4].