Previous Section  < Day Day Up >  Next Section

Hack 95 Set Up Your Own IRC Server for Unix/Linux

figs/moderate.gif figs/hack95.gif

Whether it's for testing bots or chatting with your mates, set up your own server for the ultimate power and sense of achievement.

At some point you may want to run your own server—maybe to test a bot without disturbing other users, to learn how the IRC operator commands work, or as a place for your friends to chat. It isn't easy to run your own server, as there is a lot to understand and configure, but it is a good learning experience and quite good fun too!

IRC servers are often called IRC daemons, which are also typically abbreviated as ircds. The code that most IRC servers are based on dates back to the original ircd. Jarkko Oikarinen wrote this in 1988 at the University of Oulu in Finland. The code is licensed under the GPL, and therefore developers are free to extend it under that license.

You have a large choice of ircds. Many of these are listed on http://directory.google.com/Top/Computers/Software/Internet/Servers/Chat/IRC. A lot of IRC networks have their own ircd. Some make small modifications to another ircd, while others may add major new features. Although the server-to-server communication format is documented in RFC 1459, modern IRC servers do not strictly adhere to it, as many extensions have been made (and continue to be made). If you are connecting to an existing IRC network, you will have to use an ircd that is compatible.

One of the most popular and full-featured ircds is Unreal. It has versions for both Windows and Unix operating systems. This hack will guide you through installing and configuring it. There is a lot to learn, so this hack will just help you with the basics—setting up a single server with the most basic configuration needed to run. You should read the Unreal documentation and learn about all the features if you are serious about running an ircd for public use.

15.2.1 Installing Unreal

Download Unreal from http://www.unrealircd.com. If you have downloaded the version for Windows, it should be already compiled, and you can skip to the configuration stage. Although you can compile it under Windows, it is much easier to use the precompiled version, so this section will focus on Unix-based systems.

You may need to change some of the filenames depending on which version you download. Extract the source with the tar command:

% tar zxvf Unreal3.2.tar.gz

Then change directory to the extracted directory:

% cd Unreal3.2

To compile the ircd, you first need to configure it. This is so you can choose where to install it and set some compile-time options:

% ./Config

This will ask you some questions and then run the configure script for you. Accepting the defaults is fine, unless you want one of the features that are disabled by default.

Then to compile the ircd:

% make

Normally, the ircd is run from within the source directory; however, if you specified a different location when you ran the ./Config command, you will also need to run make install like so:

% make install

Traditional ircd configuration files have followed a format in which each line is identified by a single letter and followed by fields separated by colons. The advantage of this is it is easy to write the parser for the file. Unfortunately, it leads to rather cryptic configuration files, because you need to know what each letter stands for and what order the fields should be in. Some of these are easy to remember, as some letters are commonly used—even by users who may have no idea of their true origin. For example, K-lines (server bans on an address) are named after their format in the configuration file.

Fortunately, Unreal 3.2 has a new-style configuration format that is much more verbose, allowing a clearer configuration file.

To make a configuration file, copy the file doc/example.conf to unrealircd.conf. Open this file with your favorite text editor. The configuration file may seem very long and scary at first. Well, it is a bit scary, but a lot of the file is full of comments that explain what all of the options do. Comments are text enclosed with /* */, like C comments.

Each part of the configuration is separated into blocks. A block is a set of configuration variables that are related. Taking the "me" block as an example, the format of the configuration file can be explained:

me {

   name "irc.example.com";

   info "An example server";

   numeric 1;

};

The first line has the name of the block and a { symbol to show it is the start of the block. The next line sets the variable name to the string irc.example.com. Strings must be enclosed in quotation marks, as shown in the code block. All statements must end with a semicolon. Numbers—unlike strings—should not be quoted, as shown by the numeric variable 1. A closing } is used to end the block—notice that the block requires a semicolon at the end. Each line with a variable on it is indented for clarity. While not essential, this makes it much easier to read the file when you have blocks nested within other blocks.

The first block in the example configuration file is the previously mentioned "me" block. The name should be a valid DNS hostname. This could be the hostname of the machine the ircd will run on or a name such as irc.example.com. The info is a description of the server and can be seen by clients when they execute the /whois command on a connected user, among other places. The numeric is a number between 1 and 255 that is unique to this server in a network; 1 is fine if this is the only or the first server in a network. You should change the value of these to ones suitable for your network.

The "admin" block specifies what gets shown when a user runs the /admin command. It is common practice to put contact information here.

Class blocks define various values such as times and the number of clients that can connect. They are referred to by other blocks, such as server connections and client allow blocks. They are the first blocks that can exist more than once—they must also be given a name on the same line as the block name. However, this name is not quoted like other strings. The default classes should be fine to start with, so there is no need to change anything.

The "allow" blocks allow clients to connect. Unless you want to limit your server to specific users, the default is fine.

Each IRC operator on the server must have an "oper" block; you can edit the example for the first operator. The account name goes after the oper in the block name. The "from" is a list of user hosts allowed to use this operator block. This is a standard IRC host mask (without a nickname) and can include the * wildcard. It is a good idea to change the password to something more secure. Flags specify what the operator is allowed to do—a netadmin is allowed to do most things and is probably what you want for yourself. It's up to you what permissions you give to other users. To become an IRC operator, you should connect with your IRC client and type:

/oper  account-name password 

The "listen" block defines the ports the IRC server will listen on. Port 6667 is the standard IRC port and what most people expect to connect to, so it's a good idea to leave this as it is. Obviously, you can open extra ports for whatever reason—maybe some institutions block traffic on port 6667, so you can be kind and open up another port number as well. If you chose to enable SSL during the ./Config process, you will also need to specify an SSL port.

The "link" and "ulines" blocks are used for linking other servers and Services to the server. The link defines the password and remote address of the server and will be covered in the next hack on Services, so you can comment out the link block for now. A ulines block allows Services to change modes on channels.

The "drpass" block defines passwords for the /restart and /die commands, which restart and stop the ircd, respectively. The main purpose of each password is merely to prevent accidental usage of the commands, as the user must be an IRC operator to be able to run these commands.

Several other blocks provide extra functionality. The defaults for these should be fine, so don't worry too much. These options cover logging, aliases, tld (display different MOTDs to different users), banning, exceptions, deny (block some DCC file types), and vhost (allow users to change host via a password system). You should comment out features you don't intend to use—at the very least, you will need to remove tld or create the files it needs and remove the default exception.

At the end of the example configuration file, you'll find the "set" blocks. There are some very important settings to make here. The first set block is network settings. The network settings in the example configuration file are for a network called ROXnet, and you should change the names to something more appropriate. It's best to use a valid domain name for the hostnames. However, apart from the default-server setting, the hostnames themselves do not need to be valid hostnames, as they are used only within IRC. The cloak-keys should be set to three different random values greater than 10000—they are needed so that Unreal's masked hosts are secure.

The second set block deals with settings specific to the server. The "kline" address should be set to something valid, and the DNS server should be set to the IP address of your DNS server. If you are unsure what the IP address of your DNS server is, look at the file /etc/resolv.conf on a Unix system. On Windows 2000 and later versions, you can open a command prompt and run the command ipconfig /all. Older Windows machines will display their IP address and DNS server if you run winipcfg.

Now you have most of the settings sorted out, so the server should be ready to run. To test it on a Unix system, run:

% ./unreal start

When the server starts up, you should see something like Figure 15-1.

Figure 15-1. Running Unreal under Linux
figs/irch_1501.gif


Windows users can just start the Unreal ircd program on Windows. When it starts, it will display a control panel as in Figure 15-2. If there is an error, it should give you some idea of the problem, so check the configuration file carefully to see if you can fix it. If the server has started correctly, you should be able to connect to the server by connecting to localhost:6667 with any IRC client.

Figure 15-2. Unreal for Windows has a control panel when running
figs/irch_1502.gif


Once you have connected, you should be able to become an IRC operator using the /oper command, with the username and password that you set in the file. There are lots of IRC operator commands. Typing /helpop opercmd will show a listing, and then /helpop command will show help on that particular command.

David Leadbeater

    Previous Section  < Day Day Up >  Next Section