This FAQ was started in february 1997. At that time, irc 2.9.2 was the current version, and 2.9.3 in beta. Now the latest version is 2.10.3p5 and we are awaiting 2.11.0 alpha! Hopefully, the FAQ will always be updated to cover the latest version.
This FAQ was created by Christophe Kalt and now is maintained by Piotr Kucharski <ircd-faq@irc.org>, the current IRC Software maintainer.
Make sure you have read the documentation in the package and that the answer is not there either. Then, you should know where to send your question (ircd-users@irc.org).
This might seem a bit harsh, but most questions do have their answer in the documentation files.
Oops, please notify me at ircd-faq@irc.org.
Piotr Kucharski <chopin+ircdf@sgh.waw.pl>, is the current maintainer.
There are several other people working on IRCD, and helping testing it. The list of contributors is long, and can be found in the packages, or by issuing an INFO command to the server.
The RFC 1459 is the best documentation about the original IRC protocol. Version 2.9 introduced many new extensions and changes. Along with version 2.10 came new RFCs: RFC 2810 (IRC: Architecture), RFC 2811 (IRC: Channel Management), RFC 2812 (IRC: Client Protocol), RFC 2813 (IRC: Server Protocol). And version 2.11 again changes the server protocol and probably will have its own RFC.
If something is not documented anywhere, the best way to find about it is to RTFS. Developers are known to often use this answer. I do sometimes, either because I really don't have the time to answer such an (easy) question, or simply because I do not know the answer myself. The code is huge, I don't know everything, and forget about some of the things I wrote myself.
First of all, you should look in the doc directory. Lots of information is there. Check the README as a starting point.
Here are some links of interest:
Make sure you are running the last version. Bug reports should be sent to ircd-bugs@irc.org.
May be, may be not.
Send a unified diff to ircd-users@irc.org explaining its purpose. We'll review it, and let you know what we think about it.
When sending a diff, make sure you follow the same kind of rules as the rest of the code about formatting, presentation and comments. Otherwise, your diff has little chances to get included.
2.10.0, 2.10.1 and 2.10.2 are fully compatible with 2.9.x servers. 2.9.x are fully compatible with 2.8.x servers. Be sure to #undef NoV28Links in the config.h file
Only versions 2.9.1 and 2.9.2 can be linked on a net where 2.7.x servers are present.
Only versions 2.9.1, 2.9.2 and 2.9.3 can be directly linked to a 2.8.x server.
No 2.10.x version can be directly linked to 2.8.x server.
For various reasons it's better to run a homogenous network of latest version.
ND stands for Nick Delay which is a mechanism to prevent
nickname collisions,
CD stands for Channel Delay which is a mechanism to prevent
channel collisions (op riding),
TS stand for TimeStamp which is a mechanism to solve
nickname and channel collisions by deciding which of the two
concerned parties is right, and which is wrong.
Here are some links to documents that should help you:
2.9.x and 2.10.x are the only versions implementing Nick and Channel Delay. These two mechanisms have proven to be effective in greatly reducing the number of channel takeovers, and nickname collisions. In recent years, however, they seem not enough for prolonged splits caused by (Distributed) Denial Of Service attacks.
This is the name for the feature which prevents the server to be flooded by clients. It can be tuned via the CLIENT_FLOOD define. It is different from the penalty system described below. Both are complementary.
If a client sends too much data to the server, its connection will be closed.
This feature appeared in 2.9.1 in replacement of some old less flexible equivalent mechanism. Each command of the server has a penalty which will be applied to the client running this command.
The penalty is defined in seconds. If a user's penalty exceeds 10 seconds, any incoming data is delayed, and only processed when the penalty goes under 10 seconds again.
Many people would like a list of penalties, unfortunately, it is quite difficult to make one. The only way to know is to RTFS. Most of the time, commands which affect the net have a high penalty. (For example, doing a remote WHOIS is more penalized than doing a WHOIS locally).
Bjørn Borud wrote ``A service is something between a client and a server connection. if you read the docs accompanying ircd 2.9.2 you will get some idea as to what it can be used for given some knowledge of the IRC protocol.''
2.9.3 is the first version fully supporting services (which abilities have been slightly enhanced).
Commands that a user can issue:
Services cannot join channels.
It is also interesting to note that services are not necessarily seen by the whole IRC network. A service which you cannot see cannot see you either. Services distribution is controlled by a mask, for example *.fr would restrict a service to be present only on french servers.
Here is a small perl script which behaves as a service.
This is defined in the common/struct_def.h file (see below) and tells why the client connection was closed.
#define EXITC_UNDEF '-' /* unregistered client */ #define EXITC_REG '0' /* normal exit */ #define EXITC_DIE 'd' /* server died */ #define EXITC_DEAD 'D' /* socket died */ #define EXITC_ERROR 'E' /* socket error */ #define EXITC_FLOOD 'F' /* client flooding */ #define EXITC_KLINE 'k' /* K-lined */ #define EXITC_KILL 'K' /* KILLed */ #define EXITC_MBUF 'M' /* mem alloc error */ #define EXITC_PING 'P' /* ping timeout */ #define EXITC_SENDQ 'Q' /* send queue exceeded */ #define EXITC_RLINE 'r' /* R-lined */ #define EXITC_REF 'R' /* Refused */If the character is not above, you have to check your copy of common/struct_def.h file.
2.9.3 extends logging information by providing the amount of data transferred during the connection between the client and the server:
Prefixes used are:
none I line with ident
^ I line with OTHER type ident
~ I line, no ident
+ i line with ident
= i line with OTHER type ident
- i line, no ident
See http://www.irc.org/tech_docs/ircnet/kills.html for a complete description of KILL notices.
Note that the description field of server kills has changed several times, this document describes the notices which can be generated by the version 2.9.3 (and further) of the server.
Yes.
However, it is possible to protect the server from such abuse. ircd reads the /etc/resolv.conf file to setup its own resolver and will use the nameservers defined in this file. There are two ways ircd can be tricked to accept a wrong answer, both can be defeated if the abusers cannot find the DNS server used by ircd.
The file used by ircd to setup its resolver can be changed at compile time. The default path (/etc/resolv.conf) is set in include/resolv.h up to version 2.9.3
The 2.9.4 version introduces the option --resconf to configure which makes it easy to use an alternate file.
No.
The compilation procedure is quite simple. It is described in the doc/INSTALL.txt file. Good luck!
It's a special mode that enable debugging code and notices. It can be useful for people developping, but it should NEVER be used on a production network. It makes the server to be much slower, and some special commands could be used to crash it.
A common problem with the configuration leads to the following errors:
In file included from ../ircd/s_defines.h:30,
from ../common/bsd.c:27:
../common/struct_def.h:317: parse error before `z_stream'
../common/struct_def.h:317: warning: no semicolon at end of struct or union
common/struct_def.h:318: warning: data definition has no type or s torage class
../common/struct_def.h:323: parse error before `}'
make: *** [bsd.o] Error 1
These are caused by the fact that you have defined ZIP_LINKS, but configure has not found the zlib which is required to support link compression. Check the section about configure in the INSTALL file for clues on how to make configure find the zlib (provided that it is installed on your system).
Some systems (in particular FreeBSD) have a weird ncurses library which autoconf detects and decides to use to compile the client. Unfortunately, it doesn't work and results in errors when linking the client. To get around this problem, run configure with the --without-ncurses option, and recompile the client.
Most questions about the configuration file should have an answer in the doc/INSTALL.txt document file. example.conf also has many interesting examples.
If you have a problem configuring the server, make sure to check these two files. They probably have the answer you're looking for.
chkconf is a small utility which I encourage you to use to find what is wrong in your ircd.conf.
A restricted user:
This file is used by the server to optimize memory usage, no manual editing is required, nor should be needed. As of version 2.9 of the server, several data which were statically allocated were changed to be allocated dynamically, and allowed to grow in size when needed in order to improve performance. The server stores these structures sizes in the ``ircd.tune'' file so the values are known and used upon restart which improves the memory allocation.
The file is overwritten everytime a value changes (grows), upon rehashing the server, and when a ``/die'' or ``/restart'' command is issued.
Typically you don't. However, here are couple facts you should know about the file:
The current implementation relies on IPv6 mapped IPv4 addresses. Some systems (OpenBSD)
do not support this at all, some (NetBSD, FreeBSD) ship with such mapping
disabled by default. Try
The server is not listening, your configuration is probably wrong, check your P lines. If you are using the virtual host support, check the configuration.
The server is refusing the connection according to its configuration file. Check your ircd.conf
This is often the first reaction of somebody upgrading from an old version, such as 2.8.*; it seems that the server lags 2 or 3 seconds with local clients.
This can be tuned with the HUB define in the config.h file. 2.9.x servers are optimized for networking, to the disadvantage of local clients.
Note that if you don't link many servers, HUB can be defined to 0. And if you don't link any server at all, you should probably simply #undef'ine HUB.
The code for these has been pretty broken in 2.9.1 and 2.9.2, but it is fixed in 2.9.3.
2.9.x versions of the server no longer support this user mode. To receive the server notices, you have to join some local channels:
This means that your server has opened as many file descriptors as it was allowed to. It is an OS dependant issue, but most unix shells have a ``limit'' command which can be used to put a limit lower than the actual kernel limit per process.
To solve your problem, make sure that your shell doesn't limit the number of descriptors. Then, if you still see this notice, it means you are hitting the kernel limit, in which case you should reconfigure your kernel.
The MAXCONNECTIONS define in the config.h should always be lower than the maximum number of file descriptors a process can open. If this is the case, the ``Too many open files'' notice will never show up.
This notice was changed to show (lowercase) ``o'' for global IRC operators, and (uppercase) ``O'' for local ones. The change was made to be coherent with the IRC protocol (RFC 1459) between servers.
It seems wrong because it is the opposite of the ``ircd.conf'' file.
This command was never part of the official distribution. There are several reasons which make it unlikely to ever be part of it. The ``KLINE'' command can be seen as a subset of commands allowing a client connected to IRC to modify the configuration of a server while online. Implementing such a command would mean introducing in the server the means of modifying the configuration in an uncomplete maneer. It also means allowing a client to interactively modify a file on disk, relying on poor authentication (typically, on IRC operator status).
The IRC server configuration file is complex. Currently there is no tool that can be used for remotely administrating it. Such a tool should not be implemented in the IRC server itself, but as a separate program using strong and secure authentication.
When you have uplinks to which you autoconnect, the server uses UDP to ping them. The pings are sent to the same port number as the one you use to autoconnect (unless specified otherwise, see doc/INSTALL.txt). If your uplink doesn't listen for UDP packets on this particular port, or if there is a firewall not letting the UDP packets go through, your server complains with the error message above.
You can most likely correct this by fixing either your, or your uplink's configuration. Check doc/INSTALL.txt on M and C lines about UDP pings.
NOTE: This error message was so confusing, that it is now default off.
When connecting to an unreachable host (manual or auto connect), the connection attempt will timeout after 30 seconds or so, at which point the ircd process hangs on some Solaris systems. The affected versions are 2.3, 2.4, 2.5 and 2.5.1; Solaris 2.6 doesn't have this problem.
Piotr Kucharski <ircd-faq@irc.org>
$Id: faq.html,v 1.23 2004/02/06 04:06:21 chopin Exp $