/************************************************************************
* IRC - Internet Relay Chat, doc/INSTALL
* Copyright (C) 1990,1991,1992, Jeff Trim, Mike Bolotski,
* Jarkko Oikarinen and Darren Reed.
*
* 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 IRC - The Internet Relay Chat Program
Overview of this document:
1) Installing IRC
2) The config.h file
3) Editing the Makefile, and compiling
4) The ircd.conf file
5) Mailing list
1) So that ircd/irc will compile and work correctly with your version of
Unix, it is necessary that you run "make" first. 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).
To change the default directory into which ircd will install using
"make install", invoke "make" using the "CONFIGARGS=--prefix=/dir"
command line option.
2) Edit the "config.h" file and make changes to the various #DEFINE's:
a) 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.
b) 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.
c) SPATH, CPATH, MPATH, LPATH, PPATH, TPATH
Define SPATH to be the directory path to ircd. This is usually
/usr/local/bin/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.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 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.tune. This file is used
by the server to optimize memory use.
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 provded by IRCDDIR (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) 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.
g) 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.
h) 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 http://quest.jpl.nasa.gov/zlib/
The data format used by the zlib library is described by RFCs (Request
for Comments) 1950 to 1952 in the files
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
ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html
i) 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.
j) 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.
k) 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.
3) Editting Makefile and compilation.
Once configure has been run, it is safe to edit the Makefile. You
will most likely need to uncomment the correct IRCDLIBS, IRCLIBS and
IRCDDIR lines.
To now build and install the server, type "make && make install".
If you have trouble compiling ircd, copy Makefile.in to Makefile and
edit Makefile as appropriate.
4) 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 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. Server connections (C,c,N)
2. Machine information (M)
3. Client connections (I,i)
4. Default local server (U)
5. Operator priviliges (O)
6. Administrative info (A)
7. Excluded accounts (K)
8. Excluded machines (Q)
9. Connection Classes (Y)
10. Leaf connections (L)
11. Service connections (S)
12. Port connections (P)
13. Hub connections (H)
14. Version limitations (V)
1. 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 PORT>:<Class>
Field: 1 2 3 4 5 6
for example:
C:nic.funet.fi:passwd:nic.funet.fi:6667:1
- or -
C:128.214.6.100:passwd:nic.funet.fi:6667:1
- or -
C:root@nic.funet.fi:passwd:nic.funet.fi:6667:1
Explanation:
Each field is separated with a ":" charcter:
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.
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.
Field 6: 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.
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.
Some examples:
C:nic.funet.fi::nic.funet.fi:6667:1
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:1
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:1
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:1
C:irc.nada.kth.se::irc.nada.kth.se:6667:1
C:nic.funet.fi::nic.funet.fi:6667:1
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.
The format for the NOCONNECT entry in the "ircd.conf" is:
N:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<Domain Mask>:<Class>
Field: 1 2 3 4 5 6
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".
Explanation:
Each field is separated with a ":" charcter:
Field 1: "N" corresponds to a server Noconnect 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. If CRYPT_LINK_PASSWORD
is defined in config.h, this password must be crypted.
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: Domain masking, see below.
Field 6: The class field should refer to an existing class.
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.
2. 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:
M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port>
Field: 1 2 3 4 5
Explanation:
Field 1: "M" specifies a Machine description line
Field 2: 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#).
Field 3: 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 field 2.
See Also the "Port Connections" section.
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".
Field 5: 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".
3. 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.
The format of this entry in the conf file is:
I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class>
Field:1 2 3 4 5 6
i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class>
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:*@*::*@*::1
Allow clients from anywhere to connect your server.
If the client machine does not reply to your server ident query,
the client's username will be prefixed by ~
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.
4. DEFAULT HOSTS (for local clients) *obsoleted*
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). The format for this command is:
U:<TARGET Host addr>:<Password>:<TARGET Host NAME>:<Internet Port>
Field: 1 2 3 4 5
For example:
U:tolsun.oulu.fi::tolsun.oulu.fi:6667
U:128.214.5.6::tolsun.oulu.fi:6667
U:tolsun.oulu.fi::tolsun.oulu.fi
If the port number is omitted, irc will default to using 6667.
5. OPERATOR Privileges: 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. To add
this information, EDIT your "ircd.conf" file and add the following command
line to it:
O:<TARGET Host NAME>:<password>:<nickname>:<port>:<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::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".
6. ADMINISTRATIVE INFORMATION
Introduction.
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/Location>:<Your Electronic Mailing Addr>:<other>::
Field: 1 2 3 4
Explanation:
Field 1: "A" specifies an Admin record.
Field 2: 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.
Field 3: 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.
Field 4: Is really an OTHER field - you can add what you want here,
Examples (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.
7. REMOVING A USER FROM IRC 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.
The format of this command is:
K:<Host Name>:<time interval(s)|comment>:<User>:<port>:
Field: 1 2 3 4 5
Explanation:
Field 1: "K" tells the IRCD that you are making 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
very smart thing to do though, why would you run an ircd
if you allow nobody to connect to it anyways ?
Field 3: Either leave this field empty or put a comment, then the line
is active continuously for the specified user/host machine.
You may also specify intervals during the line should be
active, see examples above.
Field 4: The USERNAME of the user you want removed from IRC. For
example 'root'.
Field 5: The port on which the Kill line will be effective.
0 means all ports.
Some Examples:
K:orion.cair.du.edu::jtrim:0:
If user 'jtrim' connects to IRC from host "orion.cair.du.edu"
then IMMEDIATELY REMOVE HIM from my IRCD.
K:*.cair.du.edu::root:0:
If user 'root' connects to IRC from any host that has the
suffix "cair.du.edu" - then IMMEDIATELY REMOVE THEM from
my IRCD.
K:*::vijay:0:
This line reads "I don't care WHAT HOST user 'vijay' is on,
I will NEVER allow username 'vijay' to login to my IRCD.
K:*.oulu.fi:0800-1200,1400-1900:*:0:
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 ago).
8. Disallowing SERVERS in your irc net.
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 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.
Introduction.
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 FREQUENCY>:<CONNECT FREQ|MAX IP>:<MAX LINKS>:<SENDQ>
Field: 1 2 3 4 5 6
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/I/O 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: This field has a different meaning depending on the use of the
Y line:
For servers: 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.
For clients: Positive value: defines the maximum number of
clients from the same host (IP)
will be allowed.
Negative value: defines the maximum number of
clients from the same user@host (IP)
will be allowed. Read note below.
Field 5: 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 (I/O lines).
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)!!
NOTE: If you plan to use the 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.
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.
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.
L:<SERVER MASK>:*:<SERVER NAME>:<MAX DEPTH>:
Field: 1 2 3 4 5
Field 2: 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: the name of the server connected to you that for which you
want to enforce leaf-like attributes upon.
Field 5: 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. Service Connections (Not Fully Implemented Yet)
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. The following line can be added to your ircd.conf file
to enable a service:
S:<TARGET Host Mask>:<password>:<service_name>:<service type>:<class>
Field: 1 2 3 4 5 6
Explanation:
Field 2: The host mask should be set to match the hosts(s) from which
the service will be connecting from. This may be either an
IP# or full name (prefered).
Field 3: This is the password which must be passed in the SERVICE command.
Field 4: The name used by the service. Services don't have nicknames, but
a static name defined by the S line.
Field 5: 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
Field 6: The class field should refer to an existing class.
To connect a service to your server, you must first create an S-line
entry in your ircd.conf file and get your server to read this in (ie
rehash or reboot). Once your server has updated itself, you can then
attempt to register your connection as a service.
Registering as a service is done by sending a SERVICE command to the
server:
SERVICE servicename servername distribution servicetype 0 :Information
A successfull registering of a service at the server will result in
a RPL_YOURESERVICE (383) being sent back to you. Any other reply as
a result of sending service indicates an error has occured.
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
priviledges. It is therefore wise to oversee the use of S-lines with
much care.
Services can be listed using the SERVLIST command, and can be sent
messages using the SQUERY command.
12. 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.
P:<Internet IP#>:<*>:<Internet IP Mask>:<PORT>:
Field: 1 2 3 4 5
or
P:<Directory>:<*>:<*>:<PORT>:
Field: 1 2 3 4 5
Explanation:
Internet Ports
Field 2
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:
Field 4
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 5
The port number field tells the server which port number it should
listen on for incoming connections.
Unix Socket Ports.
Field 1
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 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.
NOTE: You need at least one P line.
13. Hub Connections
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 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::
14. Version limitations
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 as
follows:
V:<VERSION MASK>:<FLAGS>:<SERVER NAME>::
Field: 1 2 3 4
Explanation:
Field 2
Server is not allowed to connect if its version string matches the mask
given in this field.
Field 3
This field should contained flags as defined in ircd/s_debug.c
This flags show up in RPL_VERSION.
If any of the flags present in this field are found in the RPL_VERSION
of a server, this server will be denied connection.
This must be used with care.
Field 4:
This field is used to match server names. The V line will be used
for servers matching the mask given in this field.
Examples:
V:020901*::*::
Disallows any server which version is 2.9.1* to connect.
V:020901*:D:*::
Disallows any server which version is 2.9.1* or which has been
compiled with DEBUGMODE defined to connect.
Note: It is possible to have and use multiple V-lines for the one server
mask.
H:020901:*:*::
V:020902:*:*::
is allowed.
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.
6) ircd-users
A mailing 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 majordomo@irc.org, with "subscribe ircd-users" in the body.
