Versions 2.10.x will soon be covered.
This might seem a bit harsh, but most questions do have
their answer in the documentation files.
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
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.
Here are some links of interest:
Send a diff (preferably unified) to firstname.lastname@example.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.
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.
For many reasons (bandwidth usage, ND, CD) it is better to
run a homogenous network. (Either all 2.8.x, or all 2.9.x).
Here are some links to documents that should help you:
2.9.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.
If a client sends too much data to the server, its
connection will be closed.
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
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).
The code implementing services in the 2.9.2 server is not complete, and a bug prevents services to be seen on the whole irc network. 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.
#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 */
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 of the server.
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.
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
about configure in the INSTALL file for clues on how to make configure
find the zlib (provided that it is installed on your system).
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.
The file is overwritten everytime a value changes (grows),
upon rehashing the server, and when a ``/die'' or
``/restart'' command is issued.
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.
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
It seems wrong because it is the opposite of the
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.
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.
Christophe Kalt <email@example.com>
$Id: faq.html,v 1.19 2000/05/03 16:09:40 kalt Exp $