This is Info file INSTALL.info, produced by Makeinfo-1.55 from the input file /tmp/sgml2info13260tmp2. \input texinfo  File: INSTALL.info, Node: Top, Next: Installing IRC-, Prev: (DIR), Up: (DIR) Installing IRC - The Internet Relay Chat Program ************************************************ SGML version by Christophe Kalt $Id: INSTALL.info,v 1.23 1998/02/18 21:47:53 kalt Exp $ This document describes how to install, and configure IRC 2.9.5. * Menu: * Installing IRC-:: * The config-h file:: * Editing the Makefile and compiling:: * The ircd-conf file:: * Related resources::  File: INSTALL.info, Node: Installing IRC-, Next: The config-h file, Prev: Top, Up: Top Installing IRC- *************** * Menu: * The configure script:: * Notes for Cygwin32 users::  File: INSTALL.info, Node: The configure script, Next: Notes for Cygwin32 users, Up: Installing IRC- The configure script ==================== 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). There are a few options to "configure" to help it out, or change the default behaviour: `--prefix=DIR' changes the default directory into which ircd will install using "make install". This defaults to /usr/local `--libdir=DIR' changes the default directory where most irc files will go. (default is prefix/lib/ircd) `--resconf=FILE' defines the file to be used by ircd to initialize its resolver. (default is /etc/resolv.conf) `--zlib-include=DIR' specifies in which directory the include file from the zlib is located. `--zlib-library=DIR' specifies in which directory the zlib library is located. `--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). `--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). `--without-zlib' tells "configure" not to look for the zlib. Defining this will keep you from using server link compression.  File: INSTALL.info, Node: Notes for Cygwin32 users, Prev: The configure script, Up: Installing IRC- Notes for Cygwin32 users ======================== The 2.9.5 release compiles properly on W32 systems which have the GNU-Win32 environment () setup. At the time of the release, tests were made using the version b18 of the Cygwin32 library with the "coolview" patch from Sergey Okhapkin. (This patch should be rolled in the next beta) 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: `/bin/cp.exe', `/bin/mv.exe', `/bin/rm.exe' and `/bin/sh.exe'. Also, the IRC server needs a `resolv.conf' file in order to initialize the resolver. This file can be anywhere (see configure options), and is typically in `/etc' on UNIX systems.  File: INSTALL.info, Node: The config-h file, Next: Editing the Makefile and compiling, Prev: Installing IRC-, Up: Top The config-h file ***************** 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. * Menu: * Define what type of UNIX your machine uses-:: * DEBUGMODE:: * SPATH CPATH MPATH LPATH PPATH TPATH:: * CACHED_MOTD:: * CHROOTDIR:: * ENABLE_SUMMON ENABLE_USERS:: * SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE:: * OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY:: * ZIP_LINKS ZIP_LEVEL:: * SLOW_ACCEPT:: * CLONE_CHECK:: * Other #define's::  File: INSTALL.info, Node: Define what type of UNIX your machine uses-, Next: DEBUGMODE, Up: The config-h file Define what type of UNIX your machine uses- =========================================== 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.  File: INSTALL.info, Node: DEBUGMODE, Next: SPATH CPATH MPATH LPATH PPATH TPATH, Prev: Define what type of UNIX your machine uses-, Up: The config-h file DEBUGMODE ========= 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. `This should only be defined for test purposes, and never used on a production server.'  File: INSTALL.info, Node: SPATH CPATH MPATH LPATH PPATH TPATH, Next: CACHED_MOTD, Prev: DEBUGMODE, Up: The config-h file SPATH CPATH MPATH LPATH PPATH TPATH =================================== Define SPATH to be the directory path to ircd. This is usually /usr/local/sbin/ircd, unless you don't have installation permission there. 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. The LPATH #define should be set to "/dev/null" unless you plan to debug the program. Note that the logfile grows very quickly. 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. 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. Define TPATH to be the directory path to the "ircd.tune" file. This path is usually /usr/local/lib/ircd/ircd.tune. This file is used by the server to optimize memory use.  File: INSTALL.info, Node: CACHED_MOTD, Next: CHROOTDIR, Prev: SPATH CPATH MPATH LPATH PPATH TPATH, Up: The config-h file CACHED_MOTD =========== 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. 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.  File: INSTALL.info, Node: CHROOTDIR, Next: ENABLE_SUMMON ENABLE_USERS, Prev: CACHED_MOTD, Up: The config-h file CHROOTDIR ========= 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).  File: INSTALL.info, Node: ENABLE_SUMMON ENABLE_USERS, Next: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE, Prev: CHROOTDIR, Up: The config-h file ENABLE_SUMMON ENABLE_USERS ========================== 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.  File: INSTALL.info, Node: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE, Next: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY, Prev: ENABLE_SUMMON ENABLE_USERS, Up: The config-h file SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE ========================================== 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.  File: INSTALL.info, Node: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY, Next: ZIP_LINKS ZIP_LEVEL, Prev: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE, Up: The config-h file OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY ================================================== 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.  File: INSTALL.info, Node: ZIP_LINKS ZIP_LEVEL, Next: SLOW_ACCEPT, Prev: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY, Up: The config-h file ZIP_LINKS ZIP_LEVEL =================== 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. The zlib package may be found at . The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 in the files (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format). These documents are also available in other formats from  File: INSTALL.info, Node: SLOW_ACCEPT, Next: CLONE_CHECK, Prev: ZIP_LINKS ZIP_LEVEL, Up: The config-h file SLOW_ACCEPT =========== 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. 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.  File: INSTALL.info, Node: CLONE_CHECK, Next: Other #define's, Prev: SLOW_ACCEPT, Up: The config-h file CLONE_CHECK =========== 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.  File: INSTALL.info, Node: Other #define's, Prev: CLONE_CHECK, Up: The config-h file Other #define's =============== 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.  File: INSTALL.info, Node: Editing the Makefile and compiling, Next: The ircd-conf file, Prev: The config-h file, Up: Top Editing the Makefile and compiling ********************************** 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". Now to build the package, type "make". If everything goes will, you can then install it by typing "make install". If you have trouble compiling ircd, copy Makefile.in to Makefile and edit Makefile as appropriate.  File: INSTALL.info, Node: The ircd-conf file, Next: Related resources, Prev: Editing the Makefile and compiling, Up: Top The ircd-conf file ****************** 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. 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. The ircd.conf file contains various records that specify configuration options. The record types are as follows: 1. Machine information (M) 2. Administrative info (A) 3. Port connections (P) 4. Connection Classes (Y) 5. Client connections (I,i) 6. Operator privileges (O) 7. Restrict lines (R) 8. Excluded accounts (K,k) 9. Server connections (C,c,N) 10. Deny auto-connections (D) 11. Hub connections (H) 12. Leaf connections (L) 13. Version limitations (V) 14. Excluded machines (Q) 15. Service connections (S) 16. Bounce server (B) 17. Default local server (U) 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. `It is important to note that the last matching record will be used'. This is especially useful when setting up I records (client connections). * Menu: * Machine information:: * Administrative info:: * Port connections:: * Connection Classes:: * Client connections:: * Operator priviliges:: * Restrict connections:: * Excluded accounts:: * Server connections:: * Deny auto-connections:: * Hub connections:: * Leaf connections:: * Version limitations:: * Excluded machines:: * Service connections:: * Bounce server:: * Default local server (for local clients) `*OBSOLETED*'::  File: INSTALL.info, Node: Machine information, Next: Administrative info, Up: The ircd-conf file Machine information =================== `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: `Format' M:::: `M' "M" specifies a Machine description line `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#). `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". See Also the "Port Connections" section. `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: , USA. Like for Denver I say: "Denver Colorado, USA". Finnish sites (like tolsun.oulu.fi generally say something like "Oulu, Finland". `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). `Example:' M:tolsun.oulu.fi::Oulu, Finland:6667: This line reads: My Host's name is "tolsun.oulu.fi" and my site is located in "Oulu, Finland". M:orion.cair.du.edu::Denver Colorado, USA:6667: This line reads: My Hosts name is "orion.cair.du.edu" and my site is located in "Denver Colorado, USA".  File: INSTALL.info, Node: Administrative info, Next: Port connections, Prev: Machine information, Up: The ircd-conf file Administrative info =================== `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. `Format' A::::: `A' This specifies an Admin record. `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. `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. `Other' This is really an OTHER field - you can add what you want here. `Example' (the line is just one line in the confuration file, here it is cut into two lines to make it clearer to read): 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?;):: Would look like this when printed out with the /admin command: 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? ;) 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.  File: INSTALL.info, Node: Port connections, Next: Connection Classes, Prev: Administrative info, Up: The ircd-conf file Port connections ================ `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. `Format' P::<*>::: P::<*>:<*>:: * Internet Ports `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:192.168.1.194:::6664: `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:::128.2.*:6664: P:::128.2.0.0:6664: The incoming isn't matched against the mask, rather the ip# string is decoded and compared segment by segment. Thus P:::128.2*.1.2:6664: will not match 128.20.1.2. `Port' The port number field tells the server which port number it should listen on for incoming connections. * Unix Socket Ports. `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. `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. `Example' P:/tmp/.ircd:::6667: Creates a unix socket in the /tmp/.ircd directory called "6667". The unix socket (file) must be a numerical. `Note' You need at least one P line.  File: INSTALL.info, Node: Connection Classes, Next: Client connections, Prev: Port connections, Up: The ircd-conf file Connection Classes ================== `Introduction' To enable more efficient use of MAXIMUM_LINKS, connection classes were implemented. All clients belong to a connection class. 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. 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. Currently, the Y: line `MUST' appear in the ircd.conf file `BEFORE' it is used in any other way. `Format' Y::::::: `Y' This specifies a Class record. `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. `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. `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. `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. `SendQ' This field defines the "SendQ" value for this class. If this field is not present, the default (from config.h) is assigned. `Local limit' This field is used to limit the number of local concurrent connections. The format is . * x: defines the maximum number of clients from the same host (IP) will be allowed. * y: defines the maximum number of clients from the same user@host (IP) will be allowed. Read note below. Only x or y may be set, any unset value defaults to zero. `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. `Note' leaving any of the fields (except SendQ) out means their value is 0 (ZERO)!! The SendQ field default value is dynamically determined. `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. `Note' Only the local limitation is accurate. `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. `Note' The local and global limits only affect users (I lines), not servers nor services. `Example' Y:23:120:300:5:100000:0:0: (server class) 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. 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. Y:1:60:0:50:20000:2:5: (client class) 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. Y:2:60:0:50:20000:2.1:5: (client class) 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.  File: INSTALL.info, Node: Client connections, Next: Operator priviliges, Prev: Connection Classes, Up: The ircd-conf file Client connections ================== How to let clients connect to your IRCD. `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. 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. `Format' I::::: i::::: `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). `Password' The password that must be given by the client to be allowed on the server. `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. This field can be empty, it then has a special meaning. See Below. `Port' Specifies the port number for which this configuration line is valid. An empty field, or "0" matches all ports. `Class' This field should refer to an existing class. Connections classes are usefull to limit the number of users allowed on the server. `Note' The server first checks if the client hostname (or any aliases) matches the `TARGET Host NAME' field. If a match is found, the client is accepted. If not, the server checks if the IP address of the client matches the `TARGET Host Addr' field. The matching field is used to set the name of the client: for example, if the client matches the `TARGET Host Addr' field, it will show on IRC with a numerical address (even if this address is resolvable). If the `TARGET Host NAME' field is empty, then the host name is always used (when available). `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: I:x::tolsun.oulu.fi::1 If you wanted to let remote clients connect, you could add the following lines: I:x::*.du.edu::1 Allow any clients from machines whose names end in ".du.edu" to connect with no password. I:128.214.6.100::nic.funet.fi::1 Allow clients from a machine with that IP number to connect. Numeric match is enough, name is not required anymore. I:x:secret:*.tut.fi::1 Allow clients from machines matching "*.tut.fi" to connect with the password "secret". I:*::*::1 Allow anyone from anywhere to connect your server. 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). I:x::*.fi:6667:1 Allow clients from machines matching "*.fi" to connect on the port 6667. I:135.11.35.*::*.net::1 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. I:135.11.35.*::::1 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. `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). `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.  File: INSTALL.info, Node: Operator priviliges, Next: Restrict connections, Prev: Client connections, Up: The ircd-conf file Operator priviliges =================== How to become the IRC administrator on your site `Introduction' To become an IRC Administrator, IRC must know who is authorized to become an operator and what their "Nickname" and "Password" is. `Format' O::::: `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. `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. `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. `Nickname' The Nickname you usually go by - but you can make this what you want. `Port' Unused. `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. `Example' O:orion.cair.du.edu:pyunxc:Jeff::1 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".  File: INSTALL.info, Node: Restrict connections, Next: Excluded accounts, Prev: Operator priviliges, Up: The ircd-conf file Restrict connections ==================== Let an external program decide if a client should be allowed or not. `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). 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. `Format' R:::::: `R' This specifies a restrict record. `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". `Program' This is the external program to run to know if the user is allowed on your server. `User' The Username of the user you want removed from IRC. For example "root".  File: INSTALL.info, Node: Excluded accounts, Next: Server connections, Prev: Restrict connections, Up: The ircd-conf file Excluded accounts ================= Remove an errant user from IRC on your site. `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. `Format' K::