diff options
Diffstat (limited to 'doc/INSTALL.sgml')
| -rw-r--r-- | doc/INSTALL.sgml | 1388 |
1 files changed, 1388 insertions, 0 deletions
diff --git a/doc/INSTALL.sgml b/doc/INSTALL.sgml new file mode 100644 index 0000000..b24e36f --- /dev/null +++ b/doc/INSTALL.sgml @@ -0,0 +1,1388 @@ +<!doctype linuxdoc system> + +<article> + +<title>Installing IRC - The Internet Relay Chat Program +<author>SGML version by Christophe Kalt +<date>$Id: INSTALL.sgml,v 1.38 1999/08/13 17:19:52 kalt Exp $ +<abstract> +This document describes how to install, and configure IRC 2.10.3. +</abstract> + +<sect>Installing IRC. +<sect1>The configure script +<p> +This package uses a GNU configure script for its configuration. +You simply need to untar the distribution and run the +``configure'' script. This will run configure which will probe +your system for any peculiarities it has and setup the Makefile +and a file of default #define's ($arch/setup.h). +<p> +There are a few options to ``configure'' to help it out, or +change the default behaviour: +<descrip> +<tag/--prefix=DIR/ changes the default directory into which +ircd will install using ``make install''. This defaults +to /usr/local +<tag/--sbindir=DIR/ changes the default directory where the +system admin executable files will go. It is important to +set this properly. (default is prefix/sbin) +<tag/--logdir=DIR/ changes the default directory where the +irc log files will go. (default is prefix/var/log/ircd) +<tag/--sysconfdir=DIR/ changes the default directory where +the irc server configuration files will go. (default is prefix/etc) +<tag/--localstatedir=DIR/ changes the default directory +where the irc server state files will go. (default is prefix/var/run) +<tag/--resconf=FILE/ defines the file to be used by ircd to +initialize its resolver. (default is /etc/resolv.conf) +<tag/--zlib-include=DIR/ specifies in which directory the +include file from the zlib is located. +<tag/--zlib-library=DIR/ specifies in which directory the +zlib library is located. +<tag/--zlib-prefix=DIR/ specifies the prefix for zlib +location. It overrides the 2 previous options. (The +include directory is supposed to be in prefix/include, and +the library in prefix/lib). +<tag/--with-zlib/ is the default. ``configure'' looks on your +system to find the zlib. If found, ircd will be linked using +it. This does NOT mean you can use server link compression, +for this you also need to define ZIP_LINKS (see section below). +<tag/--without-zlib/ tells ``configure'' not to look for the zlib. +Defining this will keep you from using server link compression. +<tag/--enable-ip6/ Enable IPv6 support (See notes below) +<tag/--enable-dsm/ Enable Dynamically Shared Modules support for iauth +</descrip> + +<sect1>Notes for Cygwin32 users +<p> +The daemon of 2.10.3 release compiles properly on W32 +systems which have the GNU-Win32 environment (<url +url="http://www.cygnus.com/misc/gnu-win32/">) setup. At the +time of the release, tests were made using the version b20.1 +of the Cygwin32 library. +<p> +When compiling on such system, you want to make sure that +you have carefully followed the Cygwin32 installation +notes. In particular, you will need to make sure that the +following files exist: <bf>/bin/cp.exe</bf>, +<bf>/bin/mv.exe</bf>, <bf>/bin/rm.exe</bf> and +<bf>/bin/sh.exe</bf>. +<p> +Also, the IRC server needs a <bf>resolv.conf</bf> file in +order to initialize the resolver. This file can be anywhere +(see configure options), and is typically in <bf>/etc</bf> +on UNIX systems. +<p> +Finally, iauth is automatically disabled. Even though the +iauth program compiles properly, extra work is required to +have a working communication channel between the IRC server +and the iauth program. + +<sect1>Notes concerning IPv6 support +<p> +The only part of the software that doesn't use IPv6 is the +server internal resolver. It relies on the name servers +defined in ``/etc/resolv.conf'' to be IPv4 addresses. +<p> +This version was tested on the following IPv6 systems: +BSD/OS+KAME, Digital Unix, FreeBSD+KAME, Linux, NetBSD+INRIA. +<p> +Because IPv6 numeric addresses contain ``:'' characters, +<bf>the separator for the server configuration file was +changed to ``%''</bf>. + +<sect>The config.h file +<p> +The second step consists of defining options before the +compilation. This is done by editing the ``config.h'' file +and changing the various #DEFINE's. + +<sect1>Define what type of UNIX your machine uses. +<p> +Pick the machine type which best describes your machine and +change the #undef to #define (if needed).Some +flavours of Unix require no #define and in such cases +all others should be #undef'd. + +<sect1>DEBUGMODE +<p> +Define DEBUGMODE if you want to see the ircd debugging +information as the daemon is running. Normally this function +will be undefined as ircd produces a considerable amount of +output. DEBUGMODE must be defined for either of -t or -x +command line options to work. Defining this induces a large +overhead for the server as it does a large amount of self +diagnostics whilst running. +<p> +<bf>This should only be defined for test purposes, and never +used on a production server.</bf> + +<sect1>CPATH, MPATH, LPATH, PPATH, TPATH, QPATH, OPATH +<p> +Define CPATH to be the directory path to the ``ircd.conf'' +file. This path is usually /usr/local/lib/ircd/ircd.conf. The +format of this file will be discussed later. +<p> +The LPATH #define should be set to ``/dev/null'' unless +you plan to debug the ircd program. Note that the logfile grows +very quickly. +<p> +Define MPATH to be the path to the ``motd'' (message of the +day) file for the server. Keep in mind this is +automatically displayed whenever anyone signs on to your +server. +<p> +The PPATH is optional, but if defined, should point to a +file which either doesn't exist (but is creatable) or a +previously used PPATH file. It is used for storing the +server's PID so a ps(1) isn't necessary. +<p> +Define QPATH to be the directory path to the ``iauth.conf'' +file. This path is usually /usr/local/lib/ircd/iauth.conf. +The format of this file is described by a manual page. +<p> +The OPATH #define should be set to ``/dev/null'' unless +you plan to debug the iauth program. Note that the logfile grows +very quickly. + +<sect1>CACHED_MOTD +<p> +The server sends the ``motd'' to every client connecting. +Every time, it reads it from the disk. This is quite +intensive and can be undesirable for busy servers. +<p> +Defining CACHED_MOTD will make the server store the ``motd'' +in memory, and only read it again from the disk when +rehashing if the file has changed. + +<sect1>CHROOTDIR +<p> +To use the CHROOTDIR feature, make sure it is #define'd +and that the server is being run as root. The server will +chroot to the directory name provded by ``IRCDDIR'' (in +Makefile). + +<sect1>ENABLE_SUMMON, ENABLE_USERS +<p>For security conscious server admins, they may wish to +leave ENABLE_USERS undefined, disabling the USERS command +which can be used to glean information the same as finger +can. ENABLE_SUMMON toggles whether the server will attempt +to summon local users to irc by writing a message similar to +that from talk(1) to a user's tty. + +<sect1>SHOW_INVISIBLE_LUSERS, NO_DEFAULT_INVISIBLE +<p> +On large IRC networks, the number of invisible users is +likely to be large and reporting that number cause no pain. +To aid and effect this, SHOW_INVISIBLE_LUSERS is provided to +cause the LUSERS command to report the number of invisible +users to all people and not just operators. The +NO_DEFAULT_INVISIBLE define is used to toggle whether +clients are automatically made invisible when they register. + +<sect1>OPER_KILL, OPER_REHASH, OPER_RESTART, LOCAL_KILL_ONLY +<p>The three operator only commands, KILL, REHASH and +RESTART, may all be disabled to ensure that an operator who +does not have the correct privilidges does not have the +power to cause untoward things to occur. To further curb the +actions of guest operators, LOCAL_KILL_ONLY can be defined +to only allow locally connected clients to be KILLed. + +<sect1>ZIP_LINKS, ZIP_LEVEL +<p> +As of the 2.9.3 version of the server, server-server +connections may be compressed using the zlib. In order to +compile the server with this feature, you MUST have the zlib +package (version 1.0 or higher) already compiled and define +ZIP_LINKS in the config.h file. Compression use for +server-server connections is separately configured in the +ircd.conf file for each server-server link. ZIP_LEVEL +allows you to control the compression level that will be +used. Values above 5 will noticeably increase the CPU used +by the server. +<p> +The zlib package may be found at <url +url="http://www.cdrom.com/pub/infozip/zlib/">. The data format used +by the zlib library is described by RFCs (Request for +Comments) 1950 to 1952 in the files <url +url="ftp://ds.internic.net/rfc/rfc1950.txt"> (zlib format), +rfc1951.txt (deflate format) and rfc1952.txt (gzip +format). These documents are also available in other formats +from <url url="ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html"> + +<sect1>SLOW_ACCEPT +<p> +This option is defined by default and is needed on some +OSes. It creates an artificial delay in processing incoming +connections. On a given port, no more than 1 connection per +2 seconds will be processed. +<p> +Undefining this will let the server process connections as +fast as it can which can cause problems on some OSes (such +as SunOS) and be abused (fast massive join of clonebots..), +for these reasons, if you decide to undefine SLOW_ACCEPT you +MUST define CLONE_CHECK. + +<sect1>CLONE_CHECK +<p> +This option acts as a wrapper, by checking incoming +connections early before starting ident query. By default, +the server will not accept more than 2 connections from the +same host within 10 seconds. + +<sect1>Other #define's +<p> +The rest of the user changable #define's should be +pretty much self explanatory in the config.h file. It is +*NOT* recommended that any of the file undef the line with +"STOP STOP" in it be changed. + +<sect>Editing the Makefile, and compiling +<p> +This package now uses GNU autoconf to probe your system and +generate the correct Makefile. However you need to edit it +to specify specific information, such as ``prefix'', +``irc_mode'', ``ircd_mode'' and ``ircd_dir''. +<p> +Now to build the package, type ``make all''. If everything +goes will, you can then install it by typing ``make install''. +<p> +If you have trouble compiling ircd, copy Makefile.in to +Makefile and edit Makefile as appropriate. + +<sect>The ircd.conf file +<p> +After installing the ircd and irc programs, edit the +ircd.conf file as per the instructions in this section and +install it in the location you specified in the config.h +file. There is a sample conf file called example.conf in +the doc/ directory. +<p> +Appendix A (See INSTALL.appendix) describes the differences +between IP addresses and host names. If you are unfamiliar +with this, you should probably scan through it before +proceeding. +<p> +The ircd.conf file contains various records that specify +configuration options. The record types are as follows: +<enum> +<item>Machine information (M) +<item>Administrative info (A) +<item>Port connections (P) +<item>Connection Classes (Y) +<item>Client connections (I,i) +<item>Operator privileges (O) +<item>Restrict lines (R) +<item>Excluded accounts (K,k) +<item>Server connections (C,c,N) +<item>Deny auto-connections (D) +<item>Hub connections (H) +<item>Leaf connections (L) +<item>Version limitations (V) +<item>Excluded machines (Q) +<item>Service connections (S) +<item>Bounce server (B) +<item>Default local server (U) +</enum> +<p> +Except for types ``M'' and ``A'', you are allowed to have +multiple records of the same type. In some cases, you can +have concurrent records. <bf>It is important to note that +the last matching record will be used</bf>. This is +especially useful when setting up I records (client +connections). + +<sect1>Machine information +<p> +<descrip> +<tag/Introduction/ +IRC needs to know a few things about your UNIX site, and the +``M'' command specifies this information for IRC. The fomat +of this command is: +<tag/Format/ +<verb>M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port></verb> +<tag/M/ +``M'' specifies a Machine description line +<tag/Server NAME/ +The name of YOUR server adding any Internet DOMAINNAME that +might also be present. If this hostname can be resolved, the +IP# found will be used to for outgoing connections. +Otherwise the default interface address of the host is used. +The server name may not be FQDN of another host. (This +means all outgoing connections will be done from the same +IP#, even if your host has several IP#). +<tag/YOUR Internet IP#/ +If the machine on which you run the server has several IP +addresses, you can define which IP# to use for outgoing +connections. This overrides overrides the ``Server NAME''. +<p>See Also the ``Port Connections'' section. +<tag/Geographic Location/ +Geographic Location is used to say WHERE YOUR SERVER is, and +gives people in other parts of the world a good idea of +where you are! If your server is in the USA, it is usually +best to say: <CITY> <STATE>, USA. Like for +Denver I say: ``Denver Colorado, USA''. Finnish sites (like +tolsun.oulu.fi generally say something like ``Oulu, +Finland''. +<tag/Port/ +Defines the port on which your server will listen for UDP +pings from other servers. This should be the port were +other servers are set to autoconnect. (Also see the port +field description in connect lines). +<tag/Example:/ +M:tolsun.oulu.fi::Oulu, Finland:6667: +<p> +This line reads: My Host's name is ``tolsun.oulu.fi'' and my +site is located in ``Oulu, Finland''. +<p> +M:orion.cair.du.edu::Denver Colorado, USA:6667: +<p> +This line reads: My Hosts name is ``orion.cair.du.edu'' and +my site is located in ``Denver Colorado, USA''. +</descrip> +<p> + +<sect1>Administrative info +<p> +<descrip> +<tag/Introduction/ The ``A'' line is used for administrative +information about a site. The e-mail address of the person +running the server should be included here in case problems +arise. +<tag/Format/<verb>A:<Your Name/Location>:<Your Electronic Mailing Addr>:<other>::</verb> +<tag/A/This specifies an Admin record. +<tag/Your Name & Location/ Use this field to say tell +your FULL NAME and where in the world your machine is. Be +sure to add your City, State/Province and Country. +<tag/Your Electronix Mailing Addr/ Use this field to specify +your Electronic Mailing Address preferably your Internet +Mailing Address. If you have a UUCP or ARAPnet address - +please add that as well. Be sure to add any extra DOMAIN +information that is needed, for example ``mail jtrim@orion'' +probably won't work as a mail address to me if you happen to +be in Alaska. But ``mail jtrim@orion.cair.du.edu'' would +work because you know that ``orion'' is part of the DOMAIN +``cair.du.edu''. So be sure to add your DOMAINNAMES to your +mailing addresses. +<tag/Other/ This is really an OTHER field - you can add what +you want here. +<tag/Example/ +(the line is just one line in the confuration file, here it +is cut into two lines to make it clearer to read): +<p> +A:Jeff Trim - Denver Colorado, USA:INET jtrim@orion.cair.du.edu UUCP {hao,isis}!udenva!jtrim:Terve! Heippa! Have you said hello in Finnish today?;):: +<p> +Would look like this when printed out with the /admin command: +<p> +Jeff Trim - Denver Colorado, USA +INET jtrim@orion.cair.du.edu UUCP {hao,isis}!udenva!jtrim +Terve! Hei! Heippa! Have you said hello in Finnish today? ;) +<p> +Note that the A record cannot be split across multiple +lines; it will typically be longer than 80 characters and +will therefore wrap around the screen. +</descrip> + +<Sect1>Port connections +<p> +<descrip> +<tag/Introduction/ The port line adds flexibility to the +server's ability to accept connections. By use of this line +in the ircd.conf file, it is easy to setup both Unix Domain +ports for the server to accept connections on as well as +extra internet ports. +<tag/Format/<verb>P:<Internet IP#>:<*>:<Internet IP Mask>:<Port>: +P:<Directory>:<*>:<*>:<Port>:</verb> +</descrip> +<itemize> +<item>Internet Ports +<descrip> +<tag/Internet IP#/ If the host on which the server runs has +several IP addresses, you can define for which IP address +connections will be accepted. If no is defined here, server +will bind to all interfaces (INADDR_ANY). See also MACHINE +CONFIGURATION section to properly configure outgoing +connections. +<p> +P:192.168.1.194:::6664: +<tag/Internet IP# Mask/ This defines where connections may +come from and be accepted. The IP mask uses either *'s or +0's as wildcards. The following two lines are the same: +<p> +<verb>P:::128.2.*:6664: +P:::128.2.0.0:6664: +</verb> +<p> +The incoming isn't matched against the mask, rather the ip# +string is decoded and compared segment by segment. Thus +<p> +P:::128.2*.1.2:6664: +<p> +will not match 128.20.1.2. +<tag/Port/ The port number field tells the server which port +number it should listen on for incoming connections. +</descrip> +<item> Unix Socket Ports. +<descrip> +<tag/Directory/ The path set in this field should be the +directory name in which to create the unix socket for later +listening to. The server will attempt to create the +directory before creating the unix socket. +<tag/Port/ The port field when used in combination with a +pathname in a P-line is the filename created in the +directory set in the first field. +<tag/Example/ P:/tmp/.ircd:::6667: +<p> +Creates a unix socket in the /tmp/.ircd directory called +``6667''. The unix socket (file) must be a numerical. +</descrip> +</itemize> +<descrip> +<tag/Note/ You need at least one P line. +</descrip> + +<sect1>Connection Classes +<p> +<descrip> +<tag/Introduction/ To enable more efficient use of +MAXIMUM_LINKS, connection classes were implemented. All +clients belong to a connection class. +<p>Each line for a server should have the same number as the +sixth field. If it is absent, the server deaults it to 0, +using the defaults from the config.h file. +<p>To define a connection class, you need to include a Y: +line in the ircd.conf file. This enables you to define the +ping frequency, connection frequency (for servers) and +maximum number of links that class should have. +<p>Currently, the Y: line <bf>MUST</bf> appear in the +ircd.conf file <bf>BEFORE</bf> it is used in any other way. +<tag/Format/<verb>Y:<Class>:<Ping Frequency>:<Connect freq>:<Max Links>:<SendQ>:<Local Limit>:<Global Limit></verb> +<tag/Y/ This specifies a Class record. +<tag/Class/ This is the class number which gains the following +attributes and should match that which is on the end of the +C/c/N/I/O/S line. +<tag/Ping Frequency/ This field defines how long the server will let +the connection remain ``silent'' before sending a PING message +to make sure it is still alive. Unless you are sure of what +you are doing, use the default value which is in your +config.h file. +<tag/Connect Frequency/ By changing this number, you change +how often your server checks to see if it can connect to +this server. If you want to check very occasionally, use a +large value, but if it is an important connection, you might +want a smaller value so that you connect to it as soon as +possible. +<tag/Max Links/ This field defines the maximum number of +links this class will allow from automatic connections (C +lines). Using /CONNECT overrides this feature. Also +defines the maximum number of users in this class for I/O +lines per I/O line. +<tag/SendQ/ This field defines the ``SendQ'' value for this +class. If this field is not present, the default (from +config.h) is assigned. +<tag/Local limit/ This field is used to limit the number +of local concurrent connections. The format is +<x>.<y> +<itemize> +<item> x: defines the maximum number of clients from the +same host (IP) will be allowed. +<item> y: defines the maximum number of clients from the +same user@host (IP) will be allowed. Read note below. +</itemize> +Only x or y may be set, any unset value defaults to zero. +<tag/Global limit/ This field has the same use as the +``Local limit'' field. But, the connection counts are done +for all clients present on the net instead of only counting +local clients. +<tag/Note/ leaving any of the fields (except SendQ) out +means their value is 0 (ZERO)!! The SendQ field default +value is dynamically determined. +<tag/Note/ If you plan to use the local user@host limit, +please read the following very carefully. The ``user'' +value is the ident reply for the connection. If no reply +was given then it defaults to ``unknown'' and thus the +effective limit will be per host, not per user@host. Also, +some ident servers return encrypted data which changes for +every connection making the limit void. +<tag/Note/ Only the local limitation is accurate. +<tag/Note/ If you define a gobal limit, you should also +define a local limit (same or lower) as it won't take more +CPU and will make the global limit more accurate. +<tag/Note/ The local and global limits only affect users (I +lines), not servers nor services. +<tag/Example/ Y:23:120:300:5:100000:0:0: (server class) +<p> +This defines class 23 to allow 5 auto-connections, which are +checked every 300 seconds. The connection is allowed to +remain silent for 120 seconds before a PING is sent. NOTE: +fields 3 & 4 are in seconds. The SendQ is set to 100000 +bytes. +<p> +Another feature of connection class is the ability to do +automatic routing by using the class as a ``priority''. If +you are connected to a server which has a class lower than +one of the servers that is ``behind'' it, the server will +disconnect the lower class one and schedule a ``new'' +connection for the higher class server. +<p> +Y:1:60:0:50:20000:2:5: (client class) +<p> +In case of a client class, the fields are interpreted a bit +differently. This class (number 1) can be used by up to 50 +users. The connections are allowed to remain silent for 60 +seconds before a PING is set. The SendQ is set to 20000 +bytes. A new connection in this class will only be allowed +if there aren't more than 2 other local connections from the +same IP address, or more than 5 other connections on the net +from the same hostname. +<p> +Y:2:60:0:50:20000:2.1:5: (client class) +<p> +In case of a client class, the fields are interpreted a bit +differently. This class (number 1) can be used by up to 50 +users. The connections are allowed to remain silent for 60 +seconds before a PING is set. The SendQ is set to 20000 +bytes. A new connection in this class will only be allowed +if there aren't more than 2 other local connections from the +same IP address, 1 other local connection from the same user +from the same IP address, or more than 5 other connections +on the net from the same hostname. +</descrip> + +<sect1>Client connections +<p> +How to let clients connect to your IRCD. +<descrip> +<tag/Introduction/ A client is a program that connects to +the ircd daemon (ircd). There are clients written in C, GNU +Emacs Lisp and many other languages. The ``irc'' program is +the C client. Each person that talks via IRC is running +their own client. +<p> +The ircd.conf files contains entries that specify which +clients are allowed to connect to your irc daemon. +Obviously you want to allow your own machine's clients to +connect. You may want to allow clients from other sites to +connect. These remote clients will use your server as a +connection point. All messages sent by these clients will +pass through your machine. +<tag/Format/ +<verb>I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> +i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class></verb> +<tag/TARGET Host Addr/Specifies the IP address(es) of the +machine(s) that are allowed to connect. If ``user@'' +prefixes the actual IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. Wildcards are permitted +unless using a bitmask (e.g. 1.2.3.0/24). +<tag/Password/The password that must be given by the client +to be allowed on the server. +<tag/TARGET Host NAME/Specifies the host name(s) of the +machines allowed to connect to the server. If ``user@'' +prefixes the actual IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. Wildcards are permitted. +<p> +This field can be empty, it then has a special meaning. See +Below. +<tag/Port/Specifies the port number for which this +configuration line is valid. An empty field, or ``0'' +matches all ports. +<tag/Class/This field should refer to an existing class. +Connections classes are usefull to limit the number of users +allowed on the server. +<tag/Note/The server first checks if the client hostname (or +any aliases) matches the <bf>TARGET Host NAME</bf> field. +If a match is found, the client is accepted. If not, the +server checks if the IP address of the client matches the +<bf>TARGET Host Addr</bf> field. The matching field is used +to set the name of the client: for example, if the client +matches the <bf>TARGET Host Addr</bf> field, it will show on +IRC with a numerical address (even if this address is +resolvable). If the <bf>TARGET Host NAME</bf> field is +empty, then the host name is always used (when available). +<tag/Examples/ +For example, if you were installing IRC on tolsun.oulu.fi +and you wanted to allow examples sake let us assume you were +making this file for tolsun and you wanted to let your own +clients to connect to your server, you would add this entry +to the file: +<p> +I:x::tolsun.oulu.fi::1 +<p> +If you wanted to let remote clients connect, you could add +the following lines: +<p> +I:x::*.du.edu::1 +<p> +Allow any clients from machines whose names end in +``.du.edu'' to connect with no password. +<p> +I:128.214.6.100::nic.funet.fi::1 +<p> +Allow clients from a machine with that IP number to +connect. Numeric match is enough, name is not required +anymore. +<p> +I:x:secret:*.tut.fi::1 +<p> +Allow clients from machines matching ``*.tut.fi'' to connect +with the password ``secret''. +<p> +I:*::*::1 +<p> +Allow anyone from anywhere to connect your server. +<p> +This is the easiest way, but it also allows people to for +example dump files to your server, or connect 1000 (or how +many open sockets per process your OS allows) clients to +your machine and take your network ports. Of course the same +things can be done by simply telnetting to your machine's +SMTP port (for example). +<p> +I:x::*.fi:6667:1 +<p> +Allow clients from machines matching ``*.fi'' to connect on +the port 6667. +<p> +I:135.11.35.*::*.net::1 +<p> +Allows clients from machines which host name matches +``*.net'' or which IP address matches ``135.11.35.*'' to +connect to the server. If the host name does not match +``*.net'' then the IP address is used for these clients, +even if the host name is known. +<p> +I:135.11.35.*::::1 +<p> +Allows clients from machines which IP address matches +``135.11.35.*'' to connect to the server. If the host name +is known, is it used as address for these clients. +<tag/NEW!!!/ As of the 2.7.2d version of the server, the +server is able to accept connections on multiple +ports. I-lines are required for each P-line to allow +connections to be accepted. For unix sockets, this means +either adding I:/path/port::/path/port or some variation +(wildcards are recognised here). For internet ports, there +must be an I-line which allows the host access as normal, +but the port field of the I-line must match that of the port +of the socket accepting the connectiion. A port number of 0 +is a wildcard (matches all ports). +<tag/NEW!!!/ As of the 2.9.1 version of the server, i lines +are introduced. They work the same way as I lines, but the +clients matching an i line will have a restricted +connection. (no nick/mode change, no kick). Such users will +have their username prefixed by +, = or - depending on the +ident reply. +</descrip> + +<sect1>Operator priviliges +<p> +How to become the IRC administrator on your site +<descrip> +<tag/Introduction/ To become an IRC Administrator, IRC must +know who is authorized to become an operator and what their +``Nickname'' and ``Password'' is. +<tag/Format/<verb>O:<TARGET Host NAME>:<Password>:<Nickname>:<Port>:<Class></verb> +<tag/O/ Speficies Operator record. If you use capital letter +(``O'') in it, it specifies a global operator. Small letter +(``o'') specifies a local operator. Local operator has +basically the same rights except global operator with some +restrictions. +<tag/TARGET Host NAME/ Tells IRC which host you have the +privileges FROM. This means that you should be logged into +this host when you ask for the priviliges. If you specify +``tolsun.oulu.fi'' then IRC will expect your CLIENT to be +connected at ``tolsun.oulu.fi'' - when you ask for OPERATOR +privileges from ``tolsun.oulu.fi''. You cannot be logged in +at any other host and be able to use your OPERATOR +privileges at tolsun, only when you are connected at TOLSUN +will this work - this is a safeguard against unauthorized +sites. +<tag/Password/ If your AUTHORIZATION Password - this is the +password that let's IRC know you are who you say you are! +Never tell anyone your password and always keep the +``ircd.conf'' file protected from all of the other users. +<tag/Nickname/ The Nickname you usually go by - but you can +make this what you want. +<tag/Port/ Unused. +<tag/Class/ The class field should refer to an existing +class (preferably having a lower number than that for the +relevant I-line) and determines the maximum number of +simultaneous uses of the O-line allowable through the +max. links field in the Y-line. +<tag/Example/ O:orion.cair.du.edu:pyunxc:Jeff::1 +<p> +There is an OPERATOR at ``orion.cair.du.edu'' that can get +Operator priviliges if he specifies a password of ``pyunxc'' +and uses a NICKNAME of ``Jeff''. +</descrip> + +<sect1>Restrict connections +<p> +Let an external program decide if a client should be allowed +or not. +<descrip> +<tag/Introduction/ R lines provide a convenient way to +handle user access to the server with an external program. +The outside program given three parameters: the client's +username (set by the USER command), the client's hostname, +and the client's ident reply (``unknown'' if none). +<p>It is expected to return a reply line where the first +word is either ``Y'' or ``N'' meaning `Yes Let them in'' or +``No don't let them in''. If the first word begins with +neither ``Y'' or ``N'' the default is to let the person on. +<tag/Format/ +<verb>R:<Target Host Name>:<Program>:<User>:::</verb> +<tag/R/This specifies a restrict record. +<tag/Target Host Name/ In this field you specify the +Hostname that the user is connecting from. If you wanted to +restrict connects to IRC from ``orion.cair.du.edu'' then you +would want to enter ``orion.cair.du.edu''. +<tag/Program/ This is the external program to run to know if +the user is allowed on your server. +<tag/User/ The Username of the user you want removed from +IRC. For example ``root''. +</descrip> + +<sect1>Excluded accounts +<p> +Remove an errant user from IRC on your site. +<descrip> +<tag/Introduction/ +Obviously it is hoped that you wouldn't have to use this +command. Unfortunately sometimes a user can become +unmanageable and this is your only recourse - the KILL USER +command. THIS COMMAND ONLY AFFECTS YOUR SERVER - If this +user can connect to another SERVER somewhere else in the +IRC-Network then you would have to talk to the administrator +on that site to disable his access from that IRCD Server as +well. +<tag/Format/<verb>K:<Host Name>:<time interval(s)|comment>:<User>:<port>:</verb> +<tag/Format/<verb>k:<Host Name>:<time interval(s)|comment>:<Auth>:<port>:</verb> +<tag/K/``K'' tells the IRCD that you are making a KILL USER +command entry. +<tag/Host Name/ In this field you specify the Hostname or +the IP address (Single IP, Wildcard notation or bitmask +notation) that the user is connecting from. If you wanted +to REMOVE connects to IRC from ``orion.cair.du.edu'' then +you would want to enter ``orion.cair.du.edu''. If you want +to REMOVE ALL HOSTS access you can use ``*'' (Wild Card +notation) and no matter what host the USERNAME (specified in +Field 4) connects from s/he will be denied access. Removing +all hosts isn't very smart thing to do though, why would you +run an ircd if you allow nobody to connect to it anyways ? +<p> +If you specify an IP address, IP mask, or an IP bitmask, +it will match clients connecting from the matching +addresses, no matter if they resolve or not. +<p> +You can prefix an IP address, an IP mask, or IP bitmask by +``='' in which case only non resolving matching hosts will +be banned. +<tag/time interval(s)|comment/ Either leave this field empty +or put a comment, then the line active continuously for the +specified user/host machine. You may also specify intervals +during the line should be active, see examples below. +<tag/User/ The USERNAME of the user you want removed from +IRC. For example ``root''. +<tag/Auth/ If the user's ident server replies with the OTHER +type (as opposed to the UNIX type), the reply is not used to +set the user's username. (lowercase) k lines can be used in +these case to reject users based on their ident reply. +<p> +This field will be matched against the ident server reply. +It is important to note that OTHER replies are prefixed with +a ``-'' by the ircd, while UNIX replies are not. +<tag/Port/ The port on which the Kill line will be +effective. 0 means all ports. +<tag/Examples/ K:orion.cair.du.edu::jtrim:0: +<p> +If user ``jtrim'' connects to IRC from host +``orion.cair.du.edu'' then IMMEDIATELY REMOVE HIM from my +IRCD. +<p> +k:*.stealth.net::-43589:0: +<p> +If a user connects from any host that has the suffix +``stealth.net'' and if that host ident server returns +``-43589'' - then IMMEDIATELY REMOVE THEM from my IRCD. +<p> +K:*.cair.du.edu::root:0: +<p> +If user ``root'' connects to IRC from any host that has the +suffix ``cair.du.edu'' - then IMMEDIATELY REMOVE THEM from +my IRCD. +<p> +K:*::vijay:0: +<p> +This line reads ``I don't care WHAT HOST user ``vijay'' is +on, I will NEVER allow username ``vijay'' to login to my +IRCD.'' +<p> +K:*.oulu.fi:0800-1200,1400-1900:*:0: +<p> +This disallows all users from hosts with enddomain +``oulu.fi'' access to your server between 8 and 12am, 2 and +7pm. Users get kicked off if they're already signed on when +the line becomes active (they'll get a warning 5 minutes +before). +<p> +K:192.11.35.*::*:0: +<p> +This line disallows all hosts whose IP address matches +``192.11.35.*'' to login to the ircd. +<p> +K:=192.11.35.*::*:0: +<p> +This line disallows all hosts whose IP address matches +``192.11.35.*'' and which didn't resolve to login to the +ircd. +</descrip> + +<sect1>Server connections +<p> +How to connect to other servers, How other servers can connect to you +<p> +<bf>WARNING:</bf> +The hostnames used as examples are really only examples and +not meant to be used (simply because they don't work) in +real life. +<p> +Now you must decide WHICH hosts you want to connect to and +WHAT ORDER you want to connect to them in. For my example +let us assume I am on the machine "rieska.oulu.fi" and I +want to connect to irc daemons on 3 other machines: +<itemize> +<item>``garfield.mit.edu'' - Tertiary Connection +<item>``irc.nada.kth.se'' - Secondary Connection +<item>``nic.funet.fi'' - Primary Connection +</itemize> +<p> +And I prefer to connect to them in that order, meaning I +first want to try connecting to ``nic.funet.fi'', then to +``irc.nada.kth.edu'', and finally to ``garfield.mit.edu''. +So if ``nic.funet.fi'' is down or unreachable, the program +will try to connect to ``irc.nada.kth.se''. If +irc.nada.kth.se is down it will try to connect to garfield +and so forth. +<p> +PLEASE limit the number of hosts you will attempt to connect +to down to 3. This is because of two main reasons: +<enum> +<item> to save your server from causing extra load and +delays to users +<item> to save internet from extra network traffic (remember +the old rwho program with traffic problems when the number +of machines increased). +</enum> +<p> +<descrip> +<tag/Format/ <verb>C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET PORT>:<Class></verb> +<p> +for example: +<p> +C:nic.funet.fi:passwd:nic.funet.fi:6667:1 +<p> + - or - +<p> +C:128.214.6.100:passwd:nic.funet.fi:6667:1 +<p> + - or - +<p> +C:root@nic.funet.fi:passwd:nic.funet.fi:6667:1 +<p> +Each field is separated with a ":" charcter: +<tag/C/ This field tells the IRC program which option is +being configured. "C" corresponds to a server Connect +option. +<tag/TARGET Host Addr/ Specifies the host name or IP address +of the machine to connect to. If ``user@'' prefixes the +actual hostname or IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. +<tag/Password/ The password of the other host. A password +must always be present for the line to be recognized. +<tag/TARGET Host NAME/ The full hostname of the target +machine. This is the name that the TARGET server will +identify itself with when you connect to it. If you were +connecting to nic.funet.fi you would receive +``nic.funet.fi'' and that is what you should place in this +field. +<tag/TARGET PORT/ The INTERNET Port that you want to connect +to on the TARGET machine. Most of the time this will be set +to ``6667''. If this field is left blank, then no +connections will be attempted to the TARGET host, and your +host will accept connections FROM the TARGET host instead. +The port field can contain 2 ports, separated by a . In this +case, the first port is used when auto-connecting, the +second port is used for the UDP pings to the targer server. +<tag/Class/ The class field should refer to an existing +class and determines the maximum number of simultaneous uses +of the C-line allowable through the max. links field in the +Y-line. +<tag/NEW!!!/ As of the 2.9.3 version of the server, server connections can be compressed with the zlib library. To define a compressed connection, you must have compiled the server with ZIP_LINKS defined (cf 2.h), and use a _lowercase_ C line. +</descrip> +<p> +Some examples: +<itemize> +<item>C:nic.funet.fi::nic.funet.fi:6667:1 +<p> +This reads: Connect to host ``nic.funet.fi'', with no +password and expect this server to identify itself to you as +``nic.funet.fi''. Your machine will connect to this host to +port 6667. +<item>C:18.72.0.252:Jeff:garfield.mit.edu:6667:1 +<p> +This reads: Connect to a host at address ``18.72.0.252'', +using a password of ``Jeff''. The TARGET server should +identify itself as ``garfield.mit.edu''. You will connect +to Internet Port 6667 on this host. +<item>C:irc.nada.kth.se::irc.nada.kth.se:1 +<p> +This reads: do not attempt to connect to +``irc.nada.kth.se'', if ``irc.nada.kth.se'' requests a +connection, allow it to connect. +</itemize> +<p> +Now back to our original problem, we wanted OUR server +CONNECT to 3 hosts, ``nic.funet.fi'', ``irc.nada.kth.se'' +and ``garfield.mit.edu'' in that order. So as we enter +these entries into the file they must be done in +<bf>reverse</bf> order of how we could want to connect to +them. +<p> +Here's how it would look if we connected ``nic.funet.fi'' first: +<p> +C:garfield.mit.edu::garfield.mit.edu:6667:1 +C:irc.nada.kth.se::irc.nada.kth.se:6667:1 +C:nic.funet.fi::nic.funet.fi:6667:1 +<p> +Ircd will attempt to connect to nic.funet.fi first, then to +irc.nada and finally to garfield. +<p> +<bf>Reciprocal entries:</bf> +Each ``C'' entry requires a corresponding ``N'' entry that +specifies connection priviliges to other hosts. The ``N'' +entry contains the password, if any, that you require other +hosts to have before they can connect to you. These entries +are of the same format as the ``C'' entries. +<p> +<descrip> +<tag/Format/ The format for the NOCONNECT entry in the ``ircd.conf'' is: +<verb>N:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<Domain Mask>:<Class></verb> +<p> +Let us assume that ``garfield.mit.edu'' connects to your +server and you want to place password authorization +authorization on garfield. The ``N'' entry would be: +<p> +N:garfield.mit.edu:golden:garfield.mit.edu:: +<p> +This line says: expect a connection from host +``garfield.mit.edu'', and expect a login password of +``golden'', and expect the host to identify itself as +``garfield.mit.edu''. +<p> +N:18.72.0.252::garfield.mit.edu:: +<p> +This line says: expect a Connection from host +``18.72.0.252'', and don't expect login password. The +connecting host should identify itself as +``garfield.mit.edu''. +<tag/N/ ``N'' corresponds to a server Noconnect option. +<tag/TARGET Host Addr/ Specifies the host name or IP address +of the machine to connect to. If ``user@'' prefixes the +actual hostname or IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. +<tag/Password/ The password of the other host. A password +must always be present for the line to be recognized. If +CRYPT_LINK_PASSWORD is defined in config.h, this password +must be crypted. +<tag/TARGET Host NAME/ The full hostname of the target +machine. This is the name that the TARGET server will +identify itself with when you connect to it. If you were +connecting to nic.funet.fi you would receive +``nic.funet.fi'' and that is what you should place in this +field. +<tag/Domain Mask/ Domain masking, see below. +<tag/Class/ The class field should refer to an existing class. +<tag/Wildcards domains/ To reduce the great amount of +servers in IRCnet wildcard DOMAINS were introduced in +2.6. To explain the usage of wildcard domains we take an +example of such: +<p> +*.de - a domain name matching all machines in Germany. +<p> +Wildcard domains are useful in that ALL SERVERS in Germany +(or any other domain area) can be shown as one to the rest +of the world. Imagine 100 servers in Germany, it would be +incredible waste of netwotk bandwidth to broadcast all of +them to all servers around the world. +<p> +So wildcard domains are a great help, but how to use them ? +<p> +They can be defined in the N-line for a given connection, in +place of ``Domain Mask'' you write a magic number called +wildcard count. +<p> +Wildcard count tells you HOW MANY PARTS of your server's +name should be replaced by a wildcard. For example, your +server's name is ``tolsun.oulu.fi'' and you want to +represent it as ``*.oulu.fi'' to ``nic.funet.fi''. In this +case the wildcard count is 1, because only one word (tolsun) +is replaced by a wildcard. +<p> +If the wildcard count would be 2, then the wildcard domain +would be ``*.fi''. Note that with wildcard name ``*.fi'' you +could NOT connect to ``nic.funet.fi'' because that would +result in a server name <bf>collision</bf> (*.fi matches +nic.funet.fi). +<p> +I advice you to not to use wildcard servers before you know +for sure how they are used, they are mostly beneficial for +backbones of countries and other large areas with common +domain. +</descrip> +<p> + +<sect1>Deny auto-connections +<p> +<descrip> +<tag/Introduction/ D lines were implemented to give server +administrators more control on how auto connections are +done. This will most likely only be useful for big networks +which have complex configurations. +<tag/Format/<verb>D:<Denied Server Mask>:Denied Class:<Server Name>:Server Class: +</verb> +<tag/Denied Server Mask/ This field is matched against all +servers currently present on the network. +<tag/Denied Class/ If this field contains a class number, +it will match if any server in that class is currently +present on the network. Note that this can be true for any +server, even the ones not directly connected. +<tag/Server Mask/ This field is matched against the server +name that the server wants to auto connect to. +<tag/Server Class/ This field is used to match against the +class to which belong the servers for which an autoconnect +is set. +<tag/Examples/D:*.edu::*.fi:: +<p> +Don't auto-connect to any ``*.fi'' server if any server +present on the network matches ``*.edu''. +<p> +D::2:eff.org:3: +<p> +Do now auto-connect to ``eff.org'', or any server in class +``3'' if a server defined to be in class ``2'' is currently +present on the network. +</descrip> + +<sect1>Hub connections +<p> +<descrip> +<tag/Introduction/ In direct contrast to L-lines, the server +also implements H-lines to determine which servers may act +as a hub and what they may ``hub for''. If a server is only +going to supply its own name (ie act as a solitary leaf) +then no H-line is required for, else a H-line must be added. +<tag/Format/<verb>H:<Server Mask>:*:<Server Name>:: +</verb> +<tag/Server Mask/ All servers that are allowed via this +H-line must match the mask given in this field. +<tag/Server Name/ This field is used to match exactly +against a server name, wildcards being treated as literal +characters. +<tag/Examples/H:*.edu::*.bu.edu:: +<p> +Allows a server named ``*.bu.edu'' to introduce only servers +that match the ``*.edu'' name mask. +<p> +H:*::eff.org:: +<p> +Allows ``eff.org'' to introduce (and act as a hub for) any +server. +<tag/Note/ It is possible to have and use multiple H-lines +(or L-lines) for the one server. eg: +<p> +<verb>H:*.edu:*:*.bu.edu:: +H:*.au:*:*.bu.edu:: +</verb> +<p> +is allowed as is +<p> +<verb>L:*.edu:*:*.au:: +L:*.com:*:*.au:: +</verb> +</descrip> + +<sect1>Leaf connections +<p> +<descrip> +<tag/Introduction/ To stop servers which should only act as +leaves from hubs becoming hubs accidently, the L line was +introduced so that hubs can be aware of which servers should +and shouldnt be treated as leaves. A leaf server is supposed +to remain a node for the entirity of its life whilst +connected to the IRC server network. It is quite easy, +however for a leaf server to be incorrectly setup and create +problems by becoming a node of 2 or more servers, ending its +life as a leaf. The L line enables the administrator of an +IRC ``Hub server'' to ``stop'' a server which is meant to +act as a leaf trying to make itself a hub. If, for example, +the leaf server connects to another server which doesnt have +an L-line for it, the one which does will drop the +connection, once again making the server a leaf. +<tag/Format/<verb>L:<Server Mask>:*:<Server Name>:<Max Depth>:</verb> +<tag/Server Mask/ Mask of which servers the leaf-like +attributes are used on when the server receives SERVER +messages. The wildcards * and ? may be used within this +field for matching purposes. If this field is empty, it +acts the same as if it were a single * (ie matches +everything). +<tag/Server Name/ The name of the server connected to you +that for which you want to enforce leaf-like attributes +upon. +<tag/Max Depth/ Maximum depth allowed on that leaf and if +not specified, a value of 1 is assumed. The depth is +checked each time a SERVER message is received by the +server, the hops to the server being the field checked +against this max depth and if greater, the connection to the +server that made its leaf too deep has its connection +dropped. For the L-line to come into effect, both fields, 2 +and 4, must match up with the new server being introduced +and the server which is responsible for introducing this new +server. +</descrip> + +<sect1>Version limitations +<p> +<descrip> +<tag/Introduction/ V-lines are used to restrict server +connecting to you based on their version and on compile time +options. +<tag/Format/<verb>V:<Version Mask>:<Flags>:<Server Mask>::</verb> +<tag/Version Mask/ The matching version number strings will be rejected. +<tag/Flags/ If any flag specified in this field is found in +the peer's flags string, it will be rejected. +<tag/Server Mask/ This field is used to match server names. +The V line will be used for servers matching the mask given +in this field. +<tag/Server Type/ Both the <bf>Version Mask</bf> and the +<bf>Flags</bf> should be prefixed with the server type +identification. This implementation uses the id +``<bf>IRC</bf>'' (starting with version 2.10). +<tag/Examples/V:IRC/021001*::*:: +<p> +Disallows any ``IRC'' server which version is 2.10.1* to connect. +<p> +V:IRC/021001*:IRC/D:*:: +<p> +Disallows any ``IRC'' server which version is 2.10.1* or +which has been compiled with DEBUGMODE defined to connect. +<p> +V:*/0209*:::: +<p> +Disallows any server using the 2.9 protocol to connect. +<tag/Note/ It is possible to have and use multiple V-lines +for the one server mask. +<p> +V:IRC/021001*::*:: +<p> +V:IRC/021002*::*:: +<p> +is allowed. +<tag/Protocol Version/ Only the 4 first digit of the +<bf>Version Number</bf> are standard: they define the +protocol version. The remaining of the string is +implementation dependant; matches on this part should be +used with particular identification. +<tag/Flags/ are not standard. Therefore, this field +<bf>should always</bf> contain a specific identification. +</descrip> + +<sect1>Excluded machines +<p> +Disallowing SERVERS in your irc net. +<descrip> +<tag/Introduction/ In some cases people run into +difficulties in net administration. For one reason or +another you do not want a certain server to be in your net +(for example because of the security holes it opens for +every server if it's not secured carefully). In that case +you should use Q-lines in your server. When you specify a +server name in Q-line, everytime some server link tries to +introduce you a server (remember, all server names are +broadcast around the net), that name is checked if it +matches the Q-lines in your server. If it matches, then +<bf>your server</bf> disconnects the link. Note that just +placing Q-lines to your server probably results in <bf>your +server</bf> being left alone, unless other servers have +agreed to have the same Q-line in their ircd configuration +files as well. +<tag/Example/Q::of the security holes:foo.bar.baz:: +<p> +This command excludes a server named ``foo.bar.baz'', the +reason is given to be security holes (you should give a +reason, it is polite). The first field is unused, so leave +it empty. +</descrip> + +<sect1>Service connections +<p> +<descrip> +<tag/Introduction/ The Service is a special kind of IRC +client. It does not have the full abilities of a normal user +but can behave in a more active manner than a normal +client. +<p> +Services are not intended for interactive usage, and are +better suited for automated clients. +<tag/Format/<verb>S:<TARGET Host Mask>:<Password>:<Service Name>:<Service Type>:<Class></verb> +<tag/TARGET Host Mask/ The host mask should be set to match +the host(s) from which the service will be connecting +from. This may be either an IP# or full name (prefered). +<tag/Password/ This is the password which must be passed in +the SERVICE command. +<tag/Service Name/ The name used by the service. Services +don't have nicknames, but a static name defined by the S +line. +<tag/Service Type/ The type of service. It defines the +priviledges given to the service. Be very careful in the +types you allow. The types can be found in +include/service.h +<tag/Class/ The class field should refer to an existing class. +<tag/Notes/ A service is not a very useful sort of client, +it cannot join channels or issue certain commands although +most are available to it. Services are rejected upon sending +an unknown or unallowed command. Services however, are not +affected by flood control and can be granted special +privileges. It is therefore <bf>wise to oversee the use of +S-lines with much care.</bf> +</descrip> + +<sect1>Bounce server +<p> +<descrip> +<tag/Introduction/ This provides you a way to bounce clients +to another server. This information is provided to clients +which are denied connection, either because their connection +class is full, or the server is full, or they are not +authorized to connect. +<tag/Format/<verb>B:<Class|Host Mask>::<Server Name>:<Port>:</verb> +<tag/B/ This specifies a Bounce record. +<tag/Class|Host Mask/ This field specifies to which client +this configuration line applies to. It can be either a +connection class number, a host mask to be matched against +the client's hostname, or an IP address/mask/bitmask to be +matched against the client's IP address. +<p> +When the server is completely full, it rejects clients with +the ``All connections in use'' message. In this case, the +server doesn't process the connections at all, and has no +knowledge of the client's host name, or class number. For +these cases, this field must be empty. +<tag/Server Name/ This specifies the IRC server hostname +that the client should use. +<tag/Port/ This specifies the IRC server port that the +client should connect to. +<tag/Example/B:2::irc.stealth.net:6660: +<p> +Rejected clients in class 2 are advised to use +``irc.stealth.net'' on port 6660. +<p> +B:*.fi::irc.funet.fi:6667: +<p> +Finnish client should use irc.funet.fi when they cannot be +taken anymore. +<p> +B:::irc2.stealth.net:6667: +<p> +When the server is completely full, clients should use the +secondary server. +</descrip> + +<sect1>Default local server (for local clients) <bf>*OBSOLETED*</bf> +<p> +<descrip> +<tag/Introduction/ This defines the default connection for +the irc client. If you are running an ircd server on the +same machine, you will want to define this command to +connect to your own host. If your site is not running a +server then this command should contain the TARGET host's +connection information and password (if any). +<tag/Format/<verb>U:<TARGET Host addr>:<Password>:<TARGET Host NAME>:<Internet Port></verb> +<tag/Examples/ +U:tolsun.oulu.fi::tolsun.oulu.fi:6667<p> +U:128.214.5.6::tolsun.oulu.fi:6667<p> +U:tolsun.oulu.fi::tolsun.oulu.fi +<p> +If the port number is omitted, irc will default to using 6667. +</descrip> + +<sect>Related resources +<p> +<descrip> +<tag/Mailing list/ A list is dedicated to the people using +ircd. If you have trouble running ircd, or wish to discuss +the future, you can subscribe by sending an email to +<htmlurl url="mailto:majordomo@irc.org" +name="majordomo@irc.org">, with ``<bf>subscribe +ircd-users</bf>'' in the body. +<p> +If you just have a question and don't want to subscribe to +the list, mail to <htmlurl url="mailto:ircd-users@irc.org" +name="ircd-users@irc.org">. Be sure to indicate which +version you are using. +<tag/Development/ Technical discussions and development are +carried on ircd-dev@irc.org. People interested in very +early testing, and/or working on the source code are +welcome. This is done by sending an email to <htmlurl +url="mailto:majordomo@irc.org" +name="majordomo@irc.org">, with ``<bf>subscribe +ircd-dev</bf>'' in the body. +<tag/FAQ/ It can be found on the WWW, at <url +url="http://www.stealth.net/~kalt/irc/faq.html">. +<tag/WWW 2.9/ Vesa Ruokonen has also put serveral pages +related to the 2.9 servers on the WWW: <url +url="http://www.irc.org/~irc/server/">. +</descrip> + +<sect>Reporting a bug +<p> +If you encounter a bug in the software, here is how and +where to report it. + +<sect1>How to report a bug +<p> +To save everyone time, make sure that your e-mail contains +all the information related to your problem. In particular, +we need to know: +<descrip> +<tag/Package version/ +The IRC software version you are using: please include the +output obtained by running ``irc -v'' for the client, and/or +``ircd -v'' for the server. +<p> +Also, let us know if you have applied any patch to the +package or if it is the vanilla version. +<tag/OS/ +Please, indicate which OS version you are running. +<tag/Configuration/ +If it is related to a configuration problem with the server, +include the relevant parts of the configuration file. +<tag/Backtrace/ +If the bug results in a crash, please include the +backtrace. (This can be done, for example, by running +``gdb'' on the core file, and typing ``where''). +<tag/Fix/ +If you have a fix, don't forget to include it. +</descrip> + +<sect1>Where to send a bug report +<p> +Reports should be sent to <htmlurl url="mailto:ircd-bugs@irc.org" +name="ircd-bugs@irc.org">. Your report will be reviewed +and forwarded to the appropriate mailing list. + +</article> |