IRC-Server-Net-HOWTO
This document should guide nearly anyone who wishes to get his very own IRC Server network up and running. It is somewhat obsoleted by the advent of ngircd.
One should have basic system administration skills to successfuly complete this task without much headache. Note that I assume you're using the irc-2.10.2 package. Notice also that this document is not a replacement for reading the docs and manpages! Finally note that this is only a guide. I'm not responsible if you shoot your network into the orbit with the help this guide. You didn't read the docs. Not me. :-)
Build your own server
The first important step is to make sure, your ircd[1] had HUB defined at compile time. Best to go is: Get the sources and recompile, which isn't very hard to do. You'll probably also find them in an srpm/deb on one of your hundred install CD-ROMs.
Unpack the sources, do a
./configure --prefix=/usr
in the now existing subdirectory. Configure will create a subdirectory with your platform (here it is i586-pc-linux-gnu) and put a ready-for-action Makefile into it. Please read the output of configure. If it complains about a possible broken poll() system call, take the appropriate action as mentioned.
Chdir into this subdirectory and edit config.h. Read slowly. Take time, or you will waste it later with recompiling. The options are explained in doc/INSTALL.txt in more detail. The most important part is to define HUB or you won't be able to link more than 2 servers together:
/* * A pure non-routing leaf server can undefine HUB for best performance. * If your server is running as a a HUB Server then define this. * A HUB Server has many servers connect to it at the same as opposed * to a leaf which just has 1 server (typically the uplink). */ #define HUB
You may also have a look at CRYPT_OPER_PASSWORD and CRYPT_LINK_PASSWORD options. If you define the latter, all hosts must have defined this. Else your network is a not-work.
I also commented out IRC_UID and IRC_GID. Ircd will be owned by irc in my setup and flagged setuid (u+s), so it runs as user irc anyway. I could not see any security disadvantages from this as CMDLINE_CONFIG is not defined.
Then type
make server install-server
to get the stuff installed. Runtime configuration files should be placed in /usr/lib/ircd (where an example-config will linger around for you). Rename it to ircd.conf and we may take the next step.
Run-time configuration
Carefully read the example config and write your own stuff into it.
It is really important to understand the meaning of the Server NAME field of the M line: What you define here has
nothing to do with your real host name. Think about this a user name. For your ISP you need a user name, a password and a phone number to successfully dial in. So is with ircd when connecting to other servers.
You may use the P line to pre-restrict any connection to your server. I didn't :-):
P::::6667:
Uncomment the class lines 2 and 14. In class 2, increase the number of links (field 4) to minimum the number of irc servers which should connect to you. You may want to significantly increase the values in fields 6 and 7 for class 14.
Getting the link to work
The interesting part are the c and N lines. These always come in pairs. Every c line should have an according N line on your configuration. Also important are the L and H lines, which also are some kind of pair.
Explanation of the c and N lines:
- C is for connect". You tell your server to connect to another one with a
cline. - N is for networked. You tell your server who is permitted to connect to it with a
Nline.
c:<TARGET Host Addr>:<Password>:<TARGET Server NAME>:<TARGET PORT>:<Class>
TARGET Host Addr is the real host name[2] to which your server should connect (the phone number, see above).
Password… guess what?
TARGET Server NAME is the user name as mentioned above, the server as you named it in the M line.[3]
TARGET PORT is the port on which the opposite end listens for connections. If you leave this field blank, your server doesn't make any attempt to connect to the remote end. But since c/N lines must come in pairs the remote server itself may decide to connect to yours. So, one side must fill in the port number but both may.
Class is the connection class, here we use 2.
N:<TARGET Host Addr>:<Password>:<TARGET Server NAME>:<Domain Mask>:<Class>
TARGET Host Addr is the name as returned by gethostbyaddr() of the remote end. You may use wildcards.[2]
Password: Guess what? And hey, this may be different from the one in the c line!
TARGET Server NAME is the user name as mentioned above, the server as you named it in the M line.[3]
Domain Mask: Use zero here. You don't need anything else here. If you do, you're a wizzard and won't read this document either.
Class is the connection class, here we use 2.
If your server acts as a irc hub you also may want to restrict your downlinks to not do do further downlinking themselves with the L line. Here you must also use the login name as defined by the M line and not the real host name of your downlink servers (opposite).
If your server acts as a leaf site (has only one connection to the rest of the world) you must define a H line if your uplink server has more than the only connection to you. Even here you must also use the 'login name as defined by the M line and not the real host name of your uplink server (opposite).
Twisted brain? Read on…
Configuration Examples
Take the following (simplified) situation:
+--------+ +---------+ +-------+
| sirrus | | achenar | | atrus |
+---+----+ +----+----+ +---+---+
| | |
…-+---------------+--------------+-…
All these hosts are connected via a network. Whether directly over ethernet or halfways over the earth is of no interest for our purposes. Sirrus and Achenar are leaves whether Atrus is not: He serves both of these two.
Now, take the following table to get an idea what's happening:
sirrus achenar atrus M-Line irc.here.org irc.there.org irc.mist.org c-Line(s) atrus:piper:irc.mist.org::2 atrus:stormy:irc.mist.org::2 sirrus:shipment:irc.here.org:6667:2
achenar:postit:irc.there.org:6667:2N-Line(s) atrus:shipment:irc.mist.org:0:2 atrus:postit:irc.mist.org:0:2 sirrus:piper:irc.here.org:0:2
achenar:stormy:irc.there.org:0:2L-Line(s) :sirrus::irc.here.org::
:achenar::irc.there.org::H-Line :atrus::irc.mist.org:: :atrus::irc.mist.org::
Atrus tries to connect to Sirrus (shipment) and Achenar (postit) via port 6667 via his c-Lines and verifies that these are irc.here.org and irc.there.org respectively. Sirrus and Achenar will accept connections from atrus as irc.mist.org with the respective passwords.
Since c and N must come in pairs, the reverse must be set up accordingly. With the only little difference that neither Sirrus nor Achenar should try to connect to Atrus: The port field is empty. So Sirrus pseudo-connects to Atrus with the password piper and Achenar pseudo-connects to Atrus with the password stormy. Atrus himself accepts these connections via his N-Lines (since also he is restricted to the pair-thingie).
To improve security and get a bit more sophisticated setup, one can use H and L lines to put the final spice to this
simple setup: Atrus leaves-out Sirrus and Achenar via L lines so that they get disconnected immediately after they connect to another irc server. Sirrus and Achenar respective restrict incoming servers to Atrus: Only he gets trusted.
If one has a reliable ident daemon running all around, one can improve security even more down to user basement.
Oh, and don't worry when things seem to not work: IRC-Server connections need some time until they get established.
Prepare to restart the ircd automatically if you have a dynamic ip address. It just can't deal with such a thing at runtime.