/************************************************************************
 *   IRC - Internet Relay Chat, INSTALL
 *   Copyright (C) 1990,1991,1992, Jeff Trim, Mike Bolotski,
 *   Jarkko Oikarinen and Darren Reed.
 *   Portions Copyright (C) 1998 Ari Heikkinen
 *
 *   This program is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 1, or (at your option)
 *   any later version.
 *
 *   This program is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *   GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with this program; if not, write to the Free Software
 *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */

        Installing IRCE - The Internet Relay Chat Enhanced Program

Overview of this document:

  1) Configuring IRCE for your system
  2) The default Makefile
  3) The default config.h file
  4) The default setup.h file
  5) Compiling and installing IRCE
  6) The ircd.conf file


1) Configuring IRCE for your system

   At first, you need to run the configuration script called "config-irce"
   supplied with the package. It does not use any parameters, just run it
   by "./config-irce" from shell and wait for it to finish. This script
   will create an object directory in which you'll find the following
   files created: Makefile, config.h, setup.h and ircd.conf.

   You'll be asked to cd to the object directory when the configuration
   script is done. All further steps need to be done in this directory.

2) The default Makefile

   Makefile is used by the "make" utility which allows a programmer to
   maintain, update and regenerate groups of computer programs.

   There are some macros that can be customized, however, you probably
   don't need to touch any others than DEST which is the destination
   directory where all the IRCE stuff will be installed.

   a) CC

      This defines the compiler used for building the package. This value
      is guessed by the configuration script and should work on standard
      systems. However, if you have multiple compilers and would like to
      use a custom one you may need to change this.

   b) DEST

      This is the destination directory where all the irce stuff will be
      installed. By default, this is set to $HOME/ircd but any directory
      your account can write will do. Note that if you want to relocate
      the ircd directory in the future you need to recompile IRCE.

   c) IRCD

      Name of the ircd executable, ircd by default. This value is used
      when restarting the server by IRC operator and will also be the
      name of the ircd binary to be compiled.

   d) CHKCNF

      Name of the chkconf executable, chkconf by default. This command
      is used for checking ircd.conf for any errors before rehashing
      the config to server's memory.

   e) CONF

      Name of the server's runtime configuration file, ircd.conf by default.
      This is the name of the main runtime configuration file used by IRCE.

   f) MOTD

      Name of the server's Message Of The Day file, ircd.motd by default.
      This file is generally used for displaying rules on the server for
      clients. This file is shown to all clients entering server.

   g) STATE

      Name of the server's state file, ircd.state by default. IRCE keeps
      the state of the server in this file for optimizing CPU/memory usage
      on the next restart. Sizes of hash tables, whowas history and use of
      dynamic buffer blocks are stored in this file.

   h) PID

      Name of the server's pid file, ircd.pid by default. This file contains
      the Process Id Number (PID) of the running server.

   i) USERS

      Name of the server's userlog file, users by default. A client signing
      of the server with login/signoff times will be added to this file.

   j) OPERS

      Name of the server's operlog file, opers by default. Successfull /oper
      commands will be logged into this file.

   k) FLAGS

      OS dependant compiler flags, guessed by the configurator script.
      This might need manual tuning on some exotic platforms, and you
      may also want to "man cc" on your system for checking for any
      useful compiler flags that might speed up or improve the code
      generated.

   l) LIBS

      Libraries needed for linking object files. These are guessed by
      the configuration script and should be right for most systems.
      However, you may need to add a library on some exotic platforms
      where the linking phase at the end of compiling reports for any
      unknown system calls. (this propably indicates a missing library
      in which case you should be able to find the library needed by
      doing "man" on the unknown command and try compiling again)

   m) LOG

      Debug file, if DEBUGMODE. DEBUGMODE is unsupported, this value
      is unused on normal operation.

3) The default config.h file

   a) Type of host.

      Most flavours of Unix require no #define and in such cases all of
      these should be left #undef'd.

   b) USE_VARARGS (currently unsupported, not guaranteed to work if defined)

      If your host supports varargs and has vsprintf(), vprintf() and vscanf()
      C calls in its library, then you can define USE_VARARGS to use varargs
      instead of imitation variable arg passing.

   c) DEBUGMODE (currently unsupported, not guaranteed to work if defined)

      Define DEBUGMODE if you want to see the running server's debugging
      information that was used in the development of the code IRCE is
      based on. Normally this function will be undefined as ircd produces
      a considerable amount of output. DEBUGMODE must be defined for either
      -t or -x command line options to work.

   d) 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 provided by DEST macro in Makefile.

   e) 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.

   f) ENABLE_RECURSIVE_WHO

      When defined, it's possible for users to do many /who commands at
      once go by using a comma separated list of expressions.

      NOTE: it's possible to abuse this feature on big networks by flooding
            with wildcards, extensively increasing CPU usage on slow machines.

   g) SHOW_INVISIBLE_LUSERS, NO_DEFAULT_INVISIBLE, NO_DEFAULT_SECRET

      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.

      NO_DEFAULT_SECRET define is used for toggling whether new channels
      are automatically made secret (mode +s) when created.

   h) NO_FORGED_USERNAMES

      This causes usernames from clients to be compared to ident reply
      before registering. If username doesn't match the ident reply it's
      considered faked and user is not allowed in.

   i) 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.

   j) MAXIMUM_LINKS, MAXSENDQLENGTH, PINGFREQUENCY and CONNECTFREQUENCY

      These are used only if you don't have server classes defined,
      or if a server is in class 0. (the default class if none is set)

   k) HUB

      Define this if you want your server be able to HUB. A HUB Server
      has many servers connected to it at the same as opposed to a leaf
      which just has 1 server. (a HUB is typically the uplink)

      NOTE: there's no point undefining this unless you really don't
            want your server to ever HUB anything.

   l) 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 under the line with "STOP STOP" in it be changed.

4) The default setup.h file

   This file is generated by the configuration script and contains general
   information needed for compiling IRCE such as available header files,
   system calls and binary types needed.

   NOTE: you should *NOT* manually edit this file!

5) Compiling and installing IRCE

   At this point, after checking Makefile and config.h you can run "make"
   to compile IRCE. This will take anything from 10 seconds to few minutes
   depending on the speed of your system and disks. After the compilation
   is successfully completed you can install everything into the DEST
   directory defined in Makefile by "make install".

6) The ircd.conf file

   After installing IRCE, you may edit the ircd.conf file that was installed
   in the location you specified in the Makefile before compiling as per the
   instructions in this section.

   Appendix A 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.  Client connections	(I,i)
   5.  Operator priviliges	(O)
   6.  Excluded accounts	(K)
   7.  Server connections   	(C,N)
   8.  Excluded machines        (Q)
   9.  Connection Classes       (Y)
  10.  Leaf connections         (L)
  11.  Hub connections		(H)


  1. MACHINE INFORMATION

  IRC needs to know a few things about your UNIX site, and the "M" command
  specifies this information for IRC.  The format of this command is:

         M:<YOUR Host NAME>:*:<Geographic Location>
  Field: 1        2         3           4

  Explanation:

    Field 1
	"M" specifies a "MACHINE INFORMATION" line.

    Field 2
	The name of YOUR host adding any Internet DOMAINNAME that 
	might also be present.  

    Field 3
	Unused.

    Field 4
	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".

  Examples:
	M:tolsun.oulu.fi::Oulu, Finland

	This line reads: My Hostname is "tolsun.oulu.fi" and my
	site is located in "Oulu, Finland".

	M:orion.cair.du.edu:*:Denver Colorado, USA

	This line reads: My Hostname is "orion.cair.du.edu"
	and my site is located in "Denver Colorado, USA".



  2. ADMINISTRATIVE INFORMATION

  The "A" command 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.

         A:<Your Name>:<Your Location>:<Your Electronic Mailing Addr>
  Field: 1      2             3                      4

  Explanation:

    Field 1
	"A" specifies an Admin record.

    Field 2
	This field can be used to tell your full name.

    Field 3
	This field can be used to tell your location.

    Field 4
	This field can be used to tell 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.

  Examples:
	A:Jeff Trim:Denver Colorado, USA:jtrim@orion.cair.du.edu

  Would look like this when printed out with the /admin command:

	Jeff Trim
	Denver Colorado, USA
	jtrim@orion.cair.du.edu

  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.



  3. PORT CONNECTIONS

  The "P" command adds a listening port on your server. By use of this
  line in the ircd.conf file, it is easy to setup both UNIX and INET
  domain ports for the server to accept connections on.

  NOTE: If none of the ports were successfully created on startup
        the server will die (terminate) silently.

  INTERNET PORTS

         P:<Internet IP# Mask>:<Virtual IP>:*:<PORT>
  Field: 1         2                 3      4     5

  Explanation:

    Field 1
	"P" specifies a listening port line.

    Field 2
	The internet IP mask 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.

     Field 3
	IP address of virtual network interface. Anything not in
	a.b.c.d format will cause the standard network interface
	(INADDR_ANY) to be used.

	Any of these would accept clients coming from 128.* on port 6664
	on standard network interface:

		P:128.*:NOMATCH::6664
		P:128.*:*::6664
		P:128.*:::6664

	This will accept clients coming from 128.* on port 6664 at virtual
	network interface of address 128.1.1.1:

		P:128.*:128.1.1.1::6664

     Field 4
	Unused.

     Field 5
	The port number field tells the server which port number it should
	listen on for incoming connections.

  UNIX DOMAIN PORTS

         P:<Directory>:*:*:<PORT>
  Field: 1      2      3 4    5

  Explanation:

    Field 1
	"P" specifies a listening port line.

    Field 2
	The path set in field 1 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.

    Field 3
	Unused.

    Field 4
	Unused.

    Field 5
	The port field when used in combination with a pathname in a P-line
	is the filename created in the directory set in Field 1.

  Example:
	P:/tmp/.ircd:::6667

	Creates a unix socket in the /tmp/.ircd directory called "6667".
	The unix socket (file) must be a numerical.



  4. CLIENT CONNECTIONS (how to let clients connect to your server)

  A client is a program that connects to the ircd daemon. (ircd)
  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 also 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.

  The format of this entry in the conf file is:

         I:<IP-mask>:<Password/global limit>:<Hostname-mask>:<PORT>:<CLASS>
  Field: 1     2                3                   4           5      6

  Explanation:

    Field 1
	Speficies "CLIENT CONNECTION" record. If you use capital letter ('I')
	in it, it specifies a normal client connection. Small letter ('i')
	specifies a restricted client connection. Restricted clients have
	basically the same rights than normal clients except they cannot
	change nicks once connected and don't get channel operator status
	when creating new channels. (however, they can still use channel
	ops when given by already opped people on the channel)

    Field 2
	Target ident@ip-address match pattern. (ident is optional)

    Field 3
	Password, or if this field can be successfully converted as
	an integer it's taken as a global limit. A negative number
	means user@host limit, a positive number means host (IP) limit.

    Field 4
	Target ident@hostname match pattern. (ident is optional)

	NOTE: if this field contains any of '*', '.' or '~' chars unresolved
	      hosts (without hostname) don't match this I-line!

    Field 5
	Port number. (0 or no port is a wildcard which matches all ports!)

    Field 6
	The class field should refer to an existing class which determines
	the maximum number of simultaneous uses of the I-line allowable
	through the max. links field in the Y-line.

  Examples:

	(note that connection class 10 is used on all the examples below)

	Allow clients from machine names matching *.oulu.fi or IP-addresses
	matching 130.* with any hostname (must resolve):

		I:130.*::*.oulu.fi::10

	Allow clients from machine names matching *.du.edu:

		I:NOMATCH::*.du.edu::10
		or
		I:*.du.edu::*.du.edu::10

	Allow clients from *.tut.fi to connect with password "secret"
	on port 6668:

		I:NOMATCH:secret:*.tut.fi:6668:10

	Allow clients from IP-addresses matching 130.* (no need to resolve)
	with global IP limit of 5:

		I:130.*:5:NOMATCH::10

	Allow clients from machines matching *.tut.fi or IP-addresses
	matching 130.* (must resolve) with global user@host limit of 2:

		I:130.*:-2:*.tut.fi::10

	Allow anyone from anywhere to connect to your server if they resolve:

		I:*::*::10
		or
		I:*::~::10
		or
		I:*@*::*@*::10
		or
		I:NOMATCH::*::10

	Allow anyone from anywhere to connect to your server even if they
	don't resolve (don't have hostname):

		I:*@*::NOMATCH::10
		or
		I:*::x::10

	I-lines are required for P-lines to allow connections to be
	accepted. 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 0 or no port is a wildcard which matches all ports)

	For unix sockets, this means either adding "I:/path/port::/path/port"
	or some variation. (wildcards are recognised here too)



  5. OPERATOR PRIVILEGES (how to become the IRC administrator on your site)

  To become an IRC operator, IRC must know who is authorized to become
  an operator and what their "Nickname" and "Password" is.  To add this
  information, EDIT your "ircd.conf" file and add the following command
  line to it:

          O:<TARGET Host NAME>:<password>:<nickname>:*:<class>
  Field:  1          2             3          4      5    6

  Explanation:

    Field 1
	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.

    Field 2
	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.

    Field 3
	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.

    Field 4
	The Nickname you usually go by - but you can make this what
	you want.  It is better to make this a NICKNAME that no one
	else knows, but anything will do.  I usually use my own
	loginname.

    Field 5
	Unused.

    Field 6
	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

	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".



  6. EXCLUDED ACCOUNTS (remove an errant user from IRC on your site)

  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.

  The format of this command is:

         K:<Host Name>:<message to be sent to user>:<User Name>
  Field: 1      2                    3                   4

  Explanation:

    Field 1
	"K" tells the IRCD that this is a KILL USER command entry.

    Field 2
	In this field you specify the Hostname 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 a
	very smart thing to do though, why would you run an ircd
	if you allow nobody to connect to it anyways ?

    Field 3
	A short message (reason) send to client telling why it's
	not welcome on this server. Can be left empty.

    Field 4
	The USERNAME of the user you want removed from IRC.  For
	example 'root'.

  Examples:

		K:orion.cair.du.edu::jtrim

	If user 'jtrim' connects to IRC from host "orion.cair.du.edu"
	then IMMEDIATELY REMOVE HIM from my IRCD.

		K:*.cair.du.edu::root

	If user 'root' connects to IRC from any host that has the 
	suffix "cair.du.edu" - then IMMEDIATELY REMOVE THEM from
	my IRCD.

		K:*:root denied:root

	This line reads "I don't care WHAT HOST user 'root' is on,
	I will NEVER allow username 'root' to login to my IRCD, and
	will send "root denied" message to this user.



  7. SERVER CONNECTIONS (how to connect to other servers /
                         how other servers can connect to you)

  WARNING:
	The hostnames used as examples are really only examples and not
	meant to be used (simply because they don't work) in real life.

  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:

         "garfield.mit.edu"        - Tertiary Connection
         "irc.nada.kth.se"         - Secondary Connection
         "nic.funet.fi"            - Primary Connection

  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.
  PLEASE limit the number of hosts you will attempt to connect to down to 3.
  This is because of two main reasons:

     a) to save your server from causing extra load and delays
        to users
     b) to save internet from extra network traffic
        (remember the old rwho program with traffic problems when
        the number of machines increased).

  The format for the CONNECT entry in the "ircd.conf" is:

         C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET Host PORT>
  Field: 1        2                3              4                  5

  For example:

    C:nic.funet.fi:passwd:nic.funet.fi:6667

          - or -

    C:128.214.6.100:passwd:nic.funet.fi:6667

          - or -

    C:root@nic.funet.fi:passwd:nic.funet.fi:6667

  Explanation:

    Field 1
	Field 1 tells the IRC program which option is being configured.
	"C" corresponds to a server Connect option.

    Field 2
	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 "@".

    Field 3
	The password of the other host.  A password must always be
	present for the line to be recognized.

    Field 4
	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.

    Field 5
	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.

  Some examples:

            C:nic.funet.fi::nic.funet.fi:6667
 
            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.

            C:18.72.0.252:Jeff:garfield.mit.edu:6667

            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.

            C:irc.nada.kth.se::irc.nada.kth.se

            This reads: do not attempt to connect to "irc.nada.kth.se",
			but if "irc.nada.kth.se" requests a connection,
			allow it to connect.

  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 REVERSE order of how we could want to connect to them.

  Here's how it would look if we connected "nic.funet.fi" first:

	C:garfield.mit.edu::garfield.mit.edu:6667
	C:irc.nada.kth.se::irc.nada.kth.se:6667
	C:nic.funet.fi::nic.funet.fi:6667

  Ircd will attempt to connect to nic.funet.fi first, then to irc.nada
  and finally to garfield.

  Reciprocal entries:

  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.
    
  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:

	N:garfield.mit.edu:golden:garfield.mit.edu

  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".

	N:18.72.0.252::garfield.mit.edu

  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".

  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:
		*.de  - a domain name matching all machines
                        in Germany.
        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.

	So wildcard domains are a great help, but how to use them ?
	They can be defined in the N-line for a given connection,
	in place of port number you write a magic number called
	wildcard count.

	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.
	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 COLLISION (*.fi matches nic.funet.fi).

	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.



  8. EXCLUDED MACHINES (disallowing SERVERS in your IRC network)

  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 your server disconnects the link. Note that
  just placing Q-lines to your server probably results in your server
  being left alone, unless other servers have agreed to have the
  same Q-line in their ircd configuration files as well.

  Example:
	Q::of the security holes:foo.bar.baz

  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.



  9. CONNECTION CLASSES

  To enable more efficient use of MAXIMUM_LINKS, connection classes
  were implemented. To give a connection a class, add another field
  (a sixth) to the C/N lines for a particular server.
  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 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.

  The format for the line is:

         Y:<CLASS>:<PING FREQ>:<CONNECT FREQ/LOCAL LIMIT>:<MAX LINKS>:<SENDQ>
  Field: 1    2         3                   4                  5         6

  Explanation:
    Field 2
	This is the class number which gains the following attributes
	and should match that which is on the end of the C/N line.

    Field 3
	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.

    Field 4:
      SERVERS - CONNECT FREQUENCY
	By changing this number, you change how often your server
	checks to see if it can connect to servers. (C-lines)
	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.

      CLIENTS - LOCAL LIMIT
	This number defines how many local client connections are allowed
	for I-lines using this class. A negative value means user@host
	limit and a positive value means IP limit. A value of 0 means
	no limit.

    Field 5
	This field defines the maximum number of links this class will
	allow from automatic connections. Using /CONNECT overrides this
	feature.

    Field 6
	This field defines the 'sendq' value for this class.  If this
	field is not present, the default (from config.h) is assigned.

    NOTE: leaving any of the fields out means their value is 0 (ZERO)!!

  Example:

   Y:23:120:300:5

   define 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.

   You may also give I lines a class (again the sixth field to define
   which class).  This is only usefull (currently) for redefining the
   ping frequency.  It can also be useful as a diagnostic to see how
   much each I line is used when combined with the TRACE output.

   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.



 10. LEAF CONNECTIONS

   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.

       L:<SERVER MASK>:*:<SERVER NAME>:<MAX DEPTH>
Field: 1       2       3       4            5

   Field 2 is a 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).

   Field 4 is the the server connectted to you that for which you want to
   enforce leaf-like attributes upon.

   Field 5 is the 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.



 11.  HUB CONNECTIONS

   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 as
   follows:

         H:<SERVER MASK>:*:<SERVER NAME>
  Field: 1       2       3       4

  Explanation:
    Field 2
	All servers that are allowed via this H-line must match the mask
	given in this field.

    Field 4
	This field is used to match exactly against a server name, wildcards
	being treated as literal characters.

  Examples:
		H:*.edu:*:*.bu.edu

	Allows a server named "*.bu.edu" to introduce only servers that
 	match the "*.edu" name mask.

		H:*:*:eff.org

	Allow "eff.org" to introduce (and act as a hub for) any server.

  NOTE:
	It is possible to have and use multiple H-lines (or L-lines) for
	the one server.  eg:

		H:*.edu:*:*.bu.edu
		H:*.au:*:*.bu.edu

	is allowed as is

		L:*.edu:*:*.au
		L:*.com:*:*.au



Appendix A: Difference between IP addresses and hostnames

   There are 2 different types of INTERNET addresses, NAME addresses and
   NUMERIC addresses.  NAME addresses look like ENGLISH words (and indeed
   they are ENGLISH words that refer to a given host).  A NAME address looks
   like "tolsun.oulu.fi" - and that particular address refers to the machine 
   named TOLSUN in Finland.  It is a UNIQUE address because no other machine
   in the world has its NAME address the same as "tolsun.oulu.fi".  Anytime
   you say "telnet tolsun.oulu.fi" - you would always connect to TOLSUN in
   Finland.  NUMERIC addresses refer to those addresses that are made up of
   NUMBERS for example "128.214.5.6" is the NUMERIC address for TOLSUN.  This
   address is also UNIQUE in that no other machine in the world will be use 
   those NUMERIC numbers.  The NUMERIC address is usually more reliable than
   the NAME address because not all sites can recognize and translate the
   NAME address into it's numeric counterpart.  NUMERIC always seems to work
   best, but use a NAME address when you can because it is easier to tell
   what host you are connected to.

   Every Unix machine has a file called "/etc/hosts" on it.  This file 
   contains NAME and NUMERIC addresses.  When you supply IRC with a NAME 
   address it will at first try to find it in /etc/hosts, and then (if it's 
   really smart), use the local Domain Name Server (DNS) to find the NUMERIC
   address for the host you want to connect to.  Thus if you plan to use NAME
   addresses keep in mind that on SOME sites the entry for the TARGET machine
   must be found in /etc/hosts or the NAME address will fail.  A typical 
   entry in /etc/hosts looks like this:

   130.253.1.15    orion.cair.du.edu orion.du.edu orion    # BSD 4.3

   This particular example is the Host ORION at the University of Denver. 
   Notice that on the far left is the NUMERIC Address for orion.  The
   next few ENGLISH words are the NAME addresses that can be used for orion,
   "orion.cair.du.edu", "orion.du.edu", "orion".  ALL of these NAME addresses
   will return the NUMERIC address "130.253.1.15" which IRC will use to
   connect to the TARGET UNIX. (when I say TARGET UNIX I am refering to the
   UNIX you want to connect to for IRC). Any futher questions about
   /etc/hosts should be directed to "man hosts".



Appendix B: Enabling Summon Messages

   +-----------------------------------------------------------------------+
   |            E N A B L I N G    / S U M M O N    M E S S A G E S        |
   +-----------------------------------------------------------------------+

   *NOTE* You must have ROOT or special access to the GROUP tty ('/dev')
   to do this. If you want to allow users around the world to summon
   users at your site to irc, then you should make sure that summon works.

   The "IRCD" program needs access to the GROUP of '/dev'.   This
   directory is where user TTY's are stored (as UNIX treats each Terminal
   as a FILE!)   IRCD needs GROUP ACCESS to /dev so that users can be
   SUMMONED to the program by others users that are *in* the program.
   This allows people from other Universities around the world to SUMMON
   your users to IRC so that they can chat with them.  Berkeley, SUN, HP-UX
   and most of the newer versions of UNIX check to see if a USER is
   accepting MESSAGES via the GROUP access rights on their TTY listing
   in the /dev directory. For example an entry in '/dev' looks like this:

  (Unix Path on BSD 4.3 UNIX is:  /dev/ttyp0)

        crw------- 1 jtrim     20,     0 Apr 29 10:35 ttyp0

   You will note that 'jtrim' OWNS this terminal and can READ/WRITE to this
   terminal as well (which makes sense because I am ENTERING DATA and
   RECEIVEING DATA back from the UNIX).  I logged into this particular
   UNIX on "April 29th" at "10:35am" and my TTY is "ttyp0".  But further
   of *note* is that I do not have my MESSAGES ON! (mesg n)  -- This is
   how my terminal would look with MESSAGES ON (mesg y):

        crw--w---- 1 jtrim     20,     0 Apr 29 10:35 ttyp0

   With my MESSAGES ON (mesg y) I can receive TALK(1) requests, use the 
   UNIX WRITE(1) command and other commands that allow users to talk
   to one another.  In IRC this would also allow me to get IRC /SUMMON
   messages.  To set up the "IRCD" program to work with /SUMMON type
   the following:  (using ROOT or an account that has access to '/dev').

       % chgrp tty ircd
       % chmod 6111 ircd 

   The above commands read: "Give IRCD access to GROUP tty (which is /dev)
   and then when ANYONE runs the IRCD allow SETUID and SETGID priviliges
   so that they can use the /SUMMON command.
