+++ /dev/null
-/************************************************************************
- * 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) The config.h file
- 2) Editing the Makefile
- 3) Compiling IRC
- 4) The ircd.conf file
-
-
-1) Edit the "config.h" file and make changes to the various #DEFINE's:
-
- a) Copy the config.h.dist file to config.h before editing.
-
- b) 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.
-
- c) 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.
-
- d) DPATH, SPATH, CPATH, MPATH, LPATH, PPATH
-
- DPATH is provided so that the other pathnames (SPATH, CPATH, etc)
- may be provided in just filename form. When the server starts, it
- chdir's to DPATH before chroot or any other file operation, making
- it the "current directory" for the server. This is where core files
- will go if it core dumps.
-
- 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 "irc.conf" file.
- This path is usually /usr/local/lib/irc.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.
-
- e) 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 DPATH.
-
- f) 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.
-
- g) 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.
-
- h) 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.
-
- i) 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) Configure and compile the code.
-
- Edit the root Makefile for the server, uncomment/comment the correct
- CFLAGS/IRCDLIBS lines as appropriate for your system.
- Change DESTDIR to be the same as the path for DPATH in config.h.
- Type "make". This will compile the server, the client, and the services.
- At the end of this step, the server directory will contain 'ircd',
- and the client directory will contain 'irc'. To get the server installed,
- type "make install" which will build a default m4 file for preprocessing,
- copy example.conf and put the server all in DESTDIR. The irc client and
- a copy of the server will also be placed in BINDIR and the modes set
- accordingly.
-
-4) The ircd.conf file.
-
- After installing the ircd and irc programs, edit the irc.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 irc.conf file contains various records that specify configuration
- options. The record types are as follows:
-
- 1. Server connections (C,N)
- 2. Machine information (M)
- 3. Client connections (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)
-
-
- 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 "irc.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:
-
- 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.
-
- 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.
-
-
- 2. MACHINE INFORMATION
-
- 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:<YOUR Host NAME>:xxx:<Geographic Location>:<Internet Port>
- Field: 1 2 3 4 5
-
- Explanation:
-
- Field 1: "M" specifies a Machine description line
-
- Field 2: The name of YOUR host adding any Internet DOMAINNAME that
- might also be present.
-
- Field 3: -- NOT USED --: Set to Value NULL (No spaces at ALL!).
-
- Field 4: Geographic Location is used to say WHERE YOUR SEVRER 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: The Internet port your server will use. Should be set to
- the same value as in the config.h file.
-
-
- 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". My ircd will use
- Internet Port 6667.
-
-
- 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".
- I have defined Internet Port number "6667" to be used
- as my IRCD Socket Port.
-
-
- 3. CLIENT CONNECTIONS - How to let clients connect to your IRCD.
-
- A client is a program that connects to the ircd daemon (ircd). Currently
- there are clients written in C and in GNU Emacs Lisp. The "irc"
- program is the C client. Each person that talks via IRC is running
- their own client.
-
- The irc.conf files contains entries that specify which clients are allowed
- to connect to your irc daemon. Obviously you want to allow your cwn
- 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>:<Internet Port>
- Field:1 2 3 4 5
-
-
- 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:128.214.5.6::tolsun.oulu.fi
- or
- I:tolsun.oulu.fi::tolsun.oulu.fi
-
- If you wanted to let remote clients connect, you could add the
- following lines:
-
- I:*.du.edu::*.du.edu
-
- Allow any clients from machines whose names end in "du.edu" to connect
- with no password.
-
- I:128.214.6.100::nic.funet.fi
-
- Allow clients from a machine with that IP number and the name
- nic.funet.fi to connect.
-
- I:*.tut.fi:secret:*.tut.fi
-
- Allow clients from machines matching *.tut.fi to connect
- with the password 'secret'.
-
- I:*::*
-
- 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).
-
- 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).
-
- 4. DEFAULT HOSTS (for local clients)
-
- 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
-
- 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 "irc.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 "irc.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. 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/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.
-
- 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)>:<User>
- Field: 1 2 3 4
-
- 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 (no spaces), then then lines
- 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'.
-
-
- Some 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:*::vijay
-
- 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:*
-
- 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.
-
- 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 irc.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 irc.conf file BEFORE it is used in any other way.
-
- The format for the line is:
-
- Y:<CLASS>:<PING FREQUENCY>:<CONNECT FREQUENCY>:<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 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: 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.
-
- 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. Service Connections (Not yet implemented)
-
- 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. Services as they stand now are not fully implemented.
- The following line can be added to your ircd.conf file to enable a
- service:
-
- S:<TARGET Host Mask>:<password>:<service_name>
- Field: 1 2 3 4
-
- 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 'service name' is only used for the purpose of finding the
- right S-line from the ircd.conf file for password matching. The
- actual service name used is that set by NICK commands prior to
- SERVICE being sent.
-
- 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 similar to registering as a normal user
- except that you must send NICK first and then SERVICE. The service
- command should look something like this:
-
- SERVICE secretpassword referencename :Service 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,
- however, are not affected by flood control. It is therefore wise to
- oversee the use of S-lines with some care.
-
- 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# Mask>:<*>:<*>:<PORT>
-Field: 1 2 3 4 5
-
-or
-
- P:<Directory>:<*>:<*>:<PORT>
-Field: 1 2 3 4 5
-
- Explanation
- Internet Ports
- Field 1
- 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 isnt 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.
-
-13. 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.
-
+++ /dev/null
- -- ircd.conf Programming --
- (written for DALnet release ircd) v1.01 by Roddy Vagg -- <roddy@dal.net>
- (Updated for StarIRCD 5.26 by Remmy)
- --------------------
-
- 1) ............................. Introduction
- 2) ............................. ircd.conf Basics
- 3) ............................. ircd.conf Lines
- 3.1) .......................... M Lines
- 3.2) .......................... A Lines
- 3.3) .......................... Y Lines
- 3.4) .......................... I Lines
- 3.5) .......................... O Lines
- 3.6) .......................... U Lines
- 3.7) .......................... C and N Lines
- 3.8) .......................... K Lines
- 3.9) .......................... Q Lines (server form)
- 3.10) ......................... Q Lines (nickname form)
- 3.11) ......................... H Lines
- 3.12) ......................... P Lines
- 3.13) ......................... X lines
- 3.14) ......................... Summary
-
- --------------------
-
-1) Introduction:
-
- If you are running, or planning on running an IRC server for DALnet,
- you will need to setup an ircd.conf, your ircd.conf must meet the
- requirements of a linked DALnet server which means it must contain all
- the standard DALnet lines, these will be listed at the bottom of this
- document.
-
- --------------------
-
-2) ircd.conf Basics:
-
- When you compile your server, you must specify the correct paths to
- where you plan on keeping your ircd.conf, for simplicity it is recomended
- that you keep it in the same diretory as your ircd binary and other ircd
- files.
- note: You need only supply full pathnames for DPATH and SPATH, the
- other defines will only point to files under these directories so you
- need not put full path names.
- For security reasons, your ircd.conf should have permissions set to 600,
- if other users on your system gain access to view the file they may be
- able to breach the security of your server and compromise the whole
- network.
- When you have made your ircd.conf you may check it with the program
- `chkconf', this program is supplied with the source code release and will
- be installed into your ircd directory when you run `make install',
- `chkconf' will check your ircd.conf for errors so is a usefull tool for
- beginners to ircd.conf.
- Your ircd.conf will be made up of a series of lines, each line is used
- for a different purpose in the running of your server, some lines are
- mandatory for ircd, so you must enter these lines or your server will not
- start, these lines are listed below.
- You may enter comments in your ircd.conf with the use of a hash mark (#)
- at the beginning of a line, it is recommended that you make full use of
- this to add comments to everything you put in your ircd.conf so you dont
- have any problems later.
- eg: Put a contact email address and the name/nick of the server admin
- above each C/N line pair.
- When ircd reads the ircd.conf file, it does it upside down, so lines with
- higher prefrence should go lower in the file, this will be explained later.
-
- --------------------
-
-3) ircd.conf Lines:
-
- Each type of line in this section will be given a rating of how needed
- it is in the running of the server, the ratings are:
-
- MANDATORY: you absolutely MUST have this line
- NETWORKED: you must have this line if plan on connecting your server
- to other servers. (note: you can run ircd stand alone)
- SUGGESTED: it is highly suggested that you use this line
- OPTIONAL: it's completely up to you whether to define this or not
- DISCOURAGED: you really really should not use this line if at all
- possible.
-
- Note that "*" in a field indicates an "unused" field.
-
- --------------------
-
-3.1) M Lines: [MANDATORY]
-
- This line sets your server's name, description, and port number.
- If you are to be a part of DALnet you will be assigned 2 different
- DNS entries for your ircd machine, the 1st is for general public use
- and involves: <servername>.DAL.net
- The second is for use between servers for identification, these take
- the form of: <servername>.[<state>].<country>.DAL.net
- If your server is located in the US or Australia, you will be given
- a `state' field in your server's real name, otherwise your `state', or
- `area' will not be included.
- Most IRC networks default to port 6667 for their client connection's,
- but DALnet uses port 7000 as its standard, you should compile ircd with
- port 7000, not 6667, but you may open up port 6667 (it is recomended
- that you do) with a P line (see later). Your M line's port number
- should be the same as the number you defined in your config.h at compile
- time.
-
- Syntax:
-M:hostname:*:Description Of Your Server:7000
- The 1st field should be the `real' name of your server, not the short
- name.
- The 2nd field is unused at the moment and should be left blank.
- The 3rd field is your server's description, it is up to you what you
- put in this field, but a short description of its geographic location
- is recomended.
- The 4th field is the port number you compiled ircd with. This should be
- 7000 for DALnet.
-
- Example:
-M:disney.us.dal.net::Walt's DALnet Server:7000
-
- --------------------
-
-3.2) A Lines: [MANDATORY]
-
- This line sets your server's administrative information.
- Whenever a user types /admin on your server (or /admin <servername>)
- they will recieve the information you put here.
- This line has no set information, so you may put arbitrary text if you
- like, but it is recomended that you at least put your nick and email
- address so users may contact you if need be.
-
- Syntax:
-A:A little info about your server:Admin's nick/real name:contact address
- There is no fixed standard, so you may put whatever you like in each
- field, but you should put enough information for users to contact someone
- responsible for the server.
-
- Example:
-A:Disney's DALnet IRC Server:Admin - Walt Disney:walt@RIP.org
-
- --------------------
-
-3.3) Y Lines: [SUGGESTED]
-
- These lines define connection classes. They allow you to fine-tune
- your incomming and outgoing connections, both server and client types.
- These classes are for use with C, N, I and O lines, more on this in later
- sections. DALnet has a set of Y lines that each server must use for their
- server connections, these are listed below and again at the bottom of this
- document. Client connection classes are your responsibility, you must
- make up your own set of Y lines for client connections based on your own
- situation (netwise location, machine, etc).
- Connection classes define a number of parameters for connections, these
- include:
- o Ping frequency of a silent connection.
- o Connect frequency (for server connections only!).
- o Maximum number of links allowed on the specific connection class.
- o Maximum sendq allowed for the connection before it is dropped.
- Your Y line numbers are not arbitraty. For server connection classes, the
- higher the class number, the higher the priority the connection's are given
- when auto-connecting, (see C/N lines below).
- - Ping frequency: When a connection is silent for this period of time
- the server will send a PING to the connection, if the client/server
- on the connection does not reply after a set period of time, the
- connection will be dropped. A value in this field will override the
- ping frequency defined at compile time in your config.h. For server
- connection classes, you should have the same ping frequency on both ends
- of the link, so you should stick with the standard DALnet classes.
- - Connect frequency: Since clients connect to servers and NOT the other
- way around, only server connection classes need to have a connect
- frequency. Client classes should have this field set to 0. When a server
- listed in the server's ircd.conf (see C/N lines) is missing and belongs
- on a conenction class that is holding less connections that defined by
- the max links field, the server will keep on trying to connect to
- the missing server. The ammount time between connection attempts is what
- you define in this field.
- example:
- server1 and server2 are listed in server0's ircd.conf but the only
- visible server to server0 is server1, both server1 and server2 are
- in server0's ircd.conf on the same connection class that allows for `2'
- links, server0 will go looking for server2 and try to connect to
- it each `connect frequency' seconds until the server becomes visible
- again, either by direct connection to server0, or by connection to server1
- - Maximum number of links: Each Y line should have a restriction on the number
- of connections allowed on the class. For client connections, when the limit
- is reached on a particular class, connecting clients trying to connect
- through this class are rejected. A server connecting on a `full' connection
- class will be allowed as this number on server connection classes is used for
- auto-connect purposes. As shown in the above example, when a missing server
- is listed for a particular connection class, and the class is not `full',
- your server will try and connect to this server untill it becomes visible
- again. Servers being connected manually on a `full' connection class via the
- /connect command will be allowed as long as you compiled with MAXIMUM_LINKS
- high enough to accomidate all of your server connections. (you must compile
- as a HUB if you wish to hold more than one server connection, also see H
- lines later in this document).
- - Maximum sendq: SendQ defines the `que' of data waiting to be sent to the
- client/server on the other end of the connection. SendQ's will build up if
- the client requests more data than the link can handle, say if they issue the
- /list command on a network with a lot of channels and they are only on a
- 14.4K link, their sendq on the server will build up as all the data cannot
- be sent at once, the sendq size will decrease as the data is sent, and
- increase as more data is requested. Clients will normally sit with a sendq of
- 0, it is `abnormal' for a sendq to be high for a client for a long period
- of time. When 2 servers connect, they must send their own data to
- eachother, this data includes: all the users on the server and already
- connected servers, channels, user modes, channel modes, topics (DALnet only)
- etc. When there are many clients on a particular side of the connection, a
- sendq will build up, especially if the link is slow, or already congested
- (example: the link from Australia to the US). When the sendq built up reaches
- the max sendq defined in the connection class for the particular
- client/server, the connection will be dropped. If max sendq's are
- particularly high, it will allow clients/server to take up excess memory on
- the ircd machine so a limit should be placed, especially on client connection
- classes. (IMPORTANT!) If any value of max sendq defined in a connection
- class exceeds the value defined at compile time in your config.h, the sendq
- value will default back to the compile time sendq. If your sendq field in
- a Y line is empty, the class will use the default defined in your config.h
- SendQ's for all connections on your server can be viewed with the
- /stats l <servername>
- command, this will show information for all your server's current links.
- You should have a set of standard server connection classes, at least one
- client connection class, and an Operator class. (see relevant parts of this
- document for notes on each of these)
-
- Syntax:
-Y:Class #:Ping frequency:Connect frequency:Max links:Max sendq
-
- Examples:
-Y:1:90:0:20:10000
- In this case, connect-frequency is 0 indicating that this is a client
- class (servers never connect to clients, it is the other way around).
- Clients may only idle for 90 seconds before being pinged by the server.
- The number of clients allowed to use this class is 20.
- Clients may only build up a sendq on the server of 10000 bits.
-
- These are the standard server Y lines used on DALnet:
-
-# Connecting a hub to a hub
-Y:20:10:300:1:3000000
-# Connecting a US hub to a US leaf
-Y:30:45:0:0:2000000
-# Connecting a US leaf to a US hub
-Y:35:45:20:1:2000000
-# Connecting a US hub to an EU leaf
-Y:40:60:0:0:2200000
-# Connecting an EU leaf to a US hub
-Y:45:60:20:1:2200000
-# Connecting a US hub to an AU leaf
-Y:42:240:0:0:2200000
-# Connecting an AU leaf to a US hub
-Y:43:240:60:1:2200000
-
- --------------------
-
-3.4) I Lines: [MANDATORY]
-
- These lines are the ones initially responsible for letting clients connect
- to your server. So called `client-authorization' lines, they define who
- may connect, and which connection class they will connect through.
- I lines, like C, N and O lines refer back to Y lines, as they allow
- connections, and each connection to ircd needs to be assigned to a
- connection class. If you dont provide a connection class, the connection
- will be governed by the defaults set at compile time in your config.h.
- When a client connects to the server, it gives its own information,
- this information includes username, nick and can include a password, the
- server then goes through its client-authorization rules (I lines) to see
- if the client fits any of the connection criteria.
- The rules for connection on the I lines are read from right to left, so
- if a connection is made, it is made on the right most rule it matches on
- the line. Also, since the ircd.conf is read upside down, the server will
- put the client on the lowest I line matching the client information. This
- means that if the 1st rule the client can connect on matches a connection
- class (Y line) that is `full' (see above), the client will be rejected,
- even if there is a line further up in the file that the client matches on
- that uses a connection class that has room for more clients. This means
- that I lines may be used in much the same fashion as K lines (see later)
- to block certain clients. It also means that you may place certain clients
- on many different connection classes. (examples later)
-
- Syntax:
-I:IP-address-mask:optional password:host/domain-mask::connection class (opt)
- Wildcards (`*') may be used in the mask fields (1 and 3) to allow for
- very broad connection rules. Ident (for more information on this, see
- rfc1413) can also be used by placing an `@' in the mask fields in the
- appropriate positions. If you don't want to use ident, only give the
- host/IP part of the connecting addresses, if you add a @ (usually used
- as *@), ircd will try and use ident to check the real username of the
- client, any connecting clients on host's that are running ident that
- give usernames that dont match those found by ircd will be rejected by
- the server. If the host is not running ident, a `~' will be placed in
- front of the username of the connecting client to show that the its
- host isnt running ident.
-
- Examples:
-
-I:*@*:foobar:*@*::1
- This line will allow anyone from any host that uses the password
- "foobar" to connect through connection class 1 (Y line 1), the server
- will also try and use ident to verify the username of the client.
- Placed at the top of the I lines in your ircd.conf, this line may serve
- as a fall-through for connecting clients, any client that does not match
- any other I line but gives the password "foobar" will be able to connect
- through this line (If Y line 1 has space).
-
-I:205.133.*::*.toledolink.com::1
- This is a standard vanilla I: line which will permit anyone with an IP
- address starting with 205.133 OR with a hostname ending in
- .toledolink.com to connect to the server. remember, ircd uses the
- right-most match, so if I connect as rmiller@glass.toledolink.com
- (which is rmiller@205.133.127.8) I will show up on irc as
- rmiller@glass.toledolink.com since that is the first match it found.
- (Even though the second match is valid). Any clients comming through
- on this line will use connection class 1.
-
-I:*@205.133.*::*@*.toledolink.com::1
- Same as above, but the server will use ident. You may even specify
- certain usernames with ident I lines, but they will only match if their
- host is running ident.
-
-I:NOMATCH::rmiller@glass.toledolink.com::1
- Putting NOMATCH in the first field will stop the ircd from matching
- automatically against the IP address and it will force the server to
- match against the hostname. (the "NOMATCH" string is not mandatory, you
- can use any arbitrary text in the first field).
-
- Bulk example:
-I:NOMATCH::*@*::1
-I:NOMATCH::*@*.fr::2
-I:NOMATCH::*@*.de::3
-I:NOMATCH::*@*.se::4
-I:NOMATCH::*@*.au::5
-I:129.180.*::*.une.edu.au::6
- In this example, conencting clients will 1st be matched against the mask
- *.une.edu.au, if they match they will be placed on connection class 6
- (note: if 6 is full, they will be rejected, they wont be passed on to the
- next I line), then tried against the IP 129.180.*, if they match, they will
- be placed on class 6. If the client dosen't match either of these masks, they
- will be tried against the mask *.au, so if they are from Australia, but are
- not from *.une.edu.au they will be placed on class 5. This goes on through
- the other lines, being placed on the various connection classes if they match
- any of the indicated host masks, if the client is not from the IP 129.180.*,
- Australia, Sweden, Germany or France, they will be connected through the
- final (top) I line as it serves as a fall-through, so these clients will be
- put on class 1.
-
- --------------------
-
-3.5) O Lines: [OPTIONAL]
-
- These lines provide rules as to who may gain Operator status on your server.
- O lines are much like I lines in their operation and syntax.
- Servers need not have any Operators as ircd, given well defined connection's
- can perform all of its functions automatically. Server admins have the
- ability to `kill -HUP' the server's PID to rehash the config file, removing
- the need to use the /rehash command. However, a well running network such as
- DALnet needs operators to oversee the users of the server, and make sure
- users actually enjoy their time on IRC without being continually harrased
- etc by troublematers.
- O lines come in two forms, normal `O' lines, and Local Operator `o' lines.
- Normal O lines give users power over the whole network, to use commands
- such as /kill, local Operators only have power on their local server, that
- is, the server where they can use the /oper command to make themselves +o.
- Abilities of Operators and Local Operators can be defined in your config.h.
- When a user issues the /oper command to the server, the server will search
- through all listed O lines for a match of the user's mask, much the same way
- as I lines. As with I lines, you may specify the use of ident by placing an
- `@' in the appropriate positions.
-
- DALnet's O:lines have an added field, the "operflag" field. Whereas before,
- you simply had control over whether an oper was global or local, now it is
- possible to specify almost all the access an oper has, specifically, by
- choosing the operflags in their O:line. For more information, read the
- example.conf located in this directory.
-
- Syntax:
-
-O:hostname:password:nickname:operflags:class
- See I lines for rules about the hostname and using ident.
- If you use ident, a client matching the hostname must have ident running on
- their host to be able to +o themselves.
- If you compiled defining oper passwords to be crypted, you must 1st crypt
- the plaintext using mkpasswd, a program supplied with the ircd distribution.
- See src/crypt/README for more information on this.
- The nickname is the nickname they must pass with the /oper command
- ie:
- /oper <nickname> <password>
- The class is the connection class to be used when the user /oper's using
- the O line, they connect using the standard I -- Y lines, but when they
- /oper succusfully they are passed across to the new Y line.
-
- Examples:
-
-O:RIP.org:waltspass:Walt:O:10
- This line will allow anyone on the host RIP.org (running ident or not) to
- issue the command `/oper Walt waltspass', at which point they will be moved
- over to class 10 and be made usermode +o.
-
-o:*@*:GiJ.E\hGyjhaW:Anyone:o:10
- This line allows anyone who is running ident to issue the command:
- `/oper Anyone <password>'
- This line comes from an ircd that uses encrypted passwords, so the user must
- have the plaintext password.
- When this line is used with success, the user will be a Local Operator since
- the line only has a small `o'.
-
- --------------------
-
-3.6) U Lines: [OPTIONAL]
-
- These lines define which server(s) on the network your server is connected
- to will be able to `hack' channel modes.
- On DALnet, services.dal.net is given this power, this allows the server
- to change modes on channels without being a channel operator, the
- commonly used form is ChanServ changing channel modes while not in the
- channels.
- If you are connected to a network such as DALnet that requires you to have
- certain U lines and you don't have them, your server will cause problems
- to the other servers when the server(s) that require U lines attempt to
- change channel modes.
- U lined servers also have the capability to add Akill's to your server,
- Akill's are much the same as the /kline command except that they show up
- as A: lines on /stats k.
-
- Syntax:
-U:servername:*:*
- The last 2 fields are currently unused so you only need to give the U
- lined server's name.
-
- Example:
-U:services.dal.net::
-U:services2.dal.net::
- Both these lines are required on all DALnet server's, they allow servers
- with the name's `services.dal.net' and `services2.dal.net' to hack channel
- modes.
-
- --------------------
-
-3.7) C and N Lines [NETWORKED]
-
- These lines are always used in pairs, one will not work without the other.
- C lines define who your server may connect to, while N lines define what
- servers may connect to you.
- When two servers connect, they both send eachother the `SERVER' command,
- this command contains the server name and server info (set by M lines)
- along with this command is sent a password with the PASS command, C and N
- lines provide a set of rules governing the connection between servers
- given the details of the server and pass command's.
- When one a server initiates the connection, the other server will check
- the details of the incomming server against its N lines, if a match is
- found, the server will return the server and pass command's to the
- initiating server, which will also check its N lines for a match.
- For a server to initiate a connection, it must have a C line. C lines
- tell the server where to go to make the connection and what to send for
- the pass command.
- What this all means is that for two servers to make a complete connection,
- they must have both C and N lines to refer to for the other server.
-
- Syntax:
-C:remote server's hostname/IP:password:remote server's name:port:class
-N:remote server's hostname/IP:password:remote server's name:host mask:class
- The remote server's hostname/IP should be the location on the internet that
- the server can be found. IP addresses are prefered as they are more secure,
- and can be a little quicker for the server. As with I and O lines, ident
- can be used with this 1st field to specify the username the ircd on the
- remote server is running from (if the remote server is running ident), to
- use ident with C/N lines, place the username with an @ before the hostname.
- The password should be crypted if you compile ircd specifying that link
- passwords should be crypted. Your link passwords should be very secure, as
- they provide more power, if hacked, than Operator passwords do. However
- crypted link passwords can be very akward to keep track of.
- Your C line password is the password used in the pass command, while your
- N line password will be used to check against the pass command used by
- incomming servers. So, your C line password should match the listed
- server's N line password, and your N line password should match their C
- line password.
- If you compile your ircd specifying crypted link passwords, you only need
- to crypt your N line passwords, use the same method as with O line
- passwords. If you crypt your C line passwords, your link will not work!
- Crypted passwords are a one sided affair, because one server crypts its
- N line passwords does not mean the connecting servers must crypt their
- C line passwords for that server.
- For the 3rd field, the remote servers `name' should be used, this name is
- the one given in that servers M line (see above). This name will be sent
- with the SERVER command, so it must match the one given. The C and N line
- pair should have the same name for this field.
- The 4th field of C lines may contain the remote servers connection port.
- Even though DALnet runs all its servers with a standard port 7000 open,
- server -- server connections should be taken place through port 7325. It is
- not mandatory that you place a port number in this field. If you don't give
- a port number, the server will not try and autoconnect to the listed
- server. If you do give a port number, the server will only try and
- autoconnect to the listed server if there is enough room on the connection
- class listed at the end of the C line (connection classes are covered in
- more detail above, under Y lines), and the listed server is not visible
- (ie: it is not connected to the network). If you don't give a port number,
- any /connect commands for this C line will use the default port specified
- in your config.h unless a port is given with the command. If you do put a
- port number, any /connect command's will use this port unless another port
- number is given with the command.
- The 4th field of N lines is called the `host mask', this defined how many
- parts of your hostname the incomming server will mask to. So, if your
- server's name is disney.us.dal.net, and you want the connecting server to
- see you as *.us.dal.net you will give a host mask of 1 in your N line. This
- field should normally be left blank.
- The 5th (last) field of both C and N lines gives the connection class to
- place the connection on. If your C line has a 42 in this field, and your
- server initiates a connection through this line, the connection will be
- placed on class 42, however, if You have a 42 in your C line and a 43 in
- your N line and an incomming server initiates a connection via this N
- line, the server connection will be placed on class 43.
-
- Examples:
-C:143.53.233.32:mypass:somewhere.fr.dal.net:7325:35
-N:143.53.233.32:yourpass:somewhere.fr.dal.net::35
- This set will allow a server named somewhere.fr.dal.net to connect to your
- server if it has the IP address of 143.53.233.32 and gives a password of
- `yourpass'. This connection will be governed by connection class 35.
- If your server recieves the command /connect somewhere.*, it will try and
- connect to the IP 143.53.233.32 through port 7325 and give the password
- `mypass'.
-
-C:143.53.233.32:mypass:somewhere.fr.dal.net:7325:35
-N:143.53.233.32:yourpass:somewhere.fr.dal.net::35
-C:ircd@176.43.652.31:apass:elsewhere.jp.dal.net:7235:35
-N:ircd@176.43.652.31:THEpass:elsewhere.jp.dal.net::33
- Both these set's will work as explained above, but if your Y line defining
- class 35 has `max links' set to 1, and one of these servers is connected to
- your server, your server will not try and autoconnect to the other since
- the Y line is `full', but it will accept any incomming connections from the
- other server and any /connect commands given for this server. If your Y
- line allows for more connections but your C lines do not have port numbers,
- your server will not try and autoconnect.
- Since the second set in this example has a username, ident will be used to
- authenticate any connections made to this server. If the listed server does
- not run ident, or the incomming connection comes from another username, the
- connection will be rejected.
- If a connection is made via the second set by your server, the connection
- will be ruled by connection class 35, if the other server initiates the
- connection, the connection will use class 33.
- Autoconnect C/N line pairs can be given prefrence over other pairs by placing
- them lower in your ircd.conf, the lower the line, the higher the priority
- when autoconnecting.
- Connection classes and C/N line set's allow you to refine your autoconnects
- to a very high degree, with practice you can have your server running so
- it does not need any help.
-
- --------------------
-
-3.8) K Lines [OPTIONAL]
-
- These lines restric access to certain users to your server based on
- user@host matches and time of the day.
- K lines can come in 3 forms, only one of which you can specify in your
- ircd.conf, this type will show up as K on /stats k, the other other types
- are `AutoKill' which will show up as A on /stats k, and `kline' which will
- show up as k on /stats k. AutoKill's are set by U lined servers (see
- above), they act in the same way as K lines except that they are set
- remotly and are usually set on all servers, they dissapear when you
- /rehash or restart your server. klines are set via the /kline command,
- they operate more like AutoKill's than K lines because they also dissapear
- when you /rehash, or restart the server. The /kline command can be used on
- nicknames that appear on IRC, or you can use a user@host mask. If the
- /kline is done on an existing nickname, a kline will be set with that users
- mask and they will be killed off the server.
-
- Syntax:
-K:hostmask:time/comment:username
- The hostmask is the host that the user will have on IRC, this may be an
- IP address or a standard host name. The time/comment field may either
- contain nothing, a set of times, or a comment. This field should not
- contain spaces, if you place a comment in the field, you should try and
- be creative in your avoidance of spaces. The stntax of time specification
- is:
- from-to[,from-to[,from-to]]....
- Again, you should not use spaces in this field, but you may specify as
- many time periods as you want/need. 24 hour time should be used, AM and PM
- will not work.
- The username will be the username that shows up on IRC.
- Wildcards (`*', `?') may be used with K lines in both the hostmask and
- username fields.
-
- Examples:
-K:RIP.org::walt
- This will reject any user who appears as `walt@RIP.org'.
-
-K:*.edu:0800-1200,1300-1700:*
- This will reject any user from any host with a top level `edu', In other
- words, anyone appearing as *@*.edu are banned from the server.
- This ban is only present during the hours of 8AM to 12AM, and again from
- 1PM to 5PM, at times other than this, the K line will not be active.
-
-K:*::*rad
- This K line will reject anyone with the username `rad', or anything ending
- in `rad'. This ban will dissalow anyone using `rad' running ident or not.
- You must always take into account the ident character (`~') that is placed
- infront of usernames when their host is not running ident. If you place a
- K line on a username `rad' the user will be banned only if they are running
- ident, but if this user can turn off ident they can appear as ~rad, this
- will allow them to bypass any ban of username `rad'. So, wildcards should
- be used with usernames to take into account the ability to turn ident on
- and off. (The ability to change usernames can only be tackled with a `*'
- in the username field)
-
- --------------------
-
-3.9) Q Lines (server form) [DISCOURAGED]
-
- Server form Q lines on DALnet servers are used to dissalow operators on
- certain servers to use commands such as remote /kill's, and remote
- /connect's, this will effectivly restrict the operators on the server to
- local operator priveleges. These lines are usually only used for `test'
- server situations. If a server isn't officially part of DALnet, they may
- be temporarily linked and Q lined, this means the server can be tested
- while not posing a threat to the rest of DALnet. Q lines need only be
- placed on the hub connecting the `test' server.
-
- Syntax:
-Q:*:*:servername
- The 1st 2 fields are currently unused. A Q line placed on a hub connected
- to the named server will dissalow operators on the server to affect other
- DALnet users/servers.
-
- Example:
-Q:::test-server.my.dal.net
- Q line a server with the name `test-server.my.dal.net'.
-
- --------------------
-
-3.10) Q lines (nickname form) [OPTIONAL]
-
- Nickname form Q lines have the ability to deny certain nicknames to users.
- If a nickname is Q lined, the only people allowed to use those nicknames
- are Operators. Q lines, like most other things in your ircd.conf, are local
- only, for a nickname to be Q lined on a whole network all servers must have
- a Q line for that nick. Q lines may also contain comments, these comments
- are given to the user when they attempt to use the nickname and are asked
- to choose another.
-
- Syntax:
-Q:*:reason why nick is quarantined:nickname
- The 1st field is currently unused. The 2nd field is the comment sent to any
- user attempting to use the nickname. Unlike K lines, you may use spaces.
- The last field is the nickname to be quarantined, this nickname may contain
- wildcards.
-
- Examples:
-Q::No nicknames on MY server!:*
- This Q line will dissalow any nicknames on the server giving the reason:
- No nicknames on MY server!
- Only Operators will be allowed to use any nicknames, but since you must be
- a user before you can be +o, you will effectivly ban everyone from your
- server.
-
-Q::Do not use the Lords name in vain!:God
- Anyone attempting to use the nickname `God' on your server will be told
- that they must find a new nickname and will be given the reason:
- Do not use the Lords name in vain!
-
- DALnet has a set of standard Q lines that should be in place on all
- server's. They are as follows:
-
-Q::Reserved for services:*Chan*S*rv*
-Q::Reserved for services:*Nick*S*rv*
-Q::Reserved for services:*Memo*S*rv
-Q::Reserved for services:*Oper*S*rv*
-Q::Reserved for services:*Help*S*rv*
-Q::Reserved for operators:DALnet
-Q::Reserved for operators:IRC*op*
-Q::Causes problems with mIRC:Status
-
- --------------------
-
-3.11) H Lines [OPTIONAL/NETWORKED]
-
- These lines are similar to L lines, except that they define what servers
- may act as a hub while connected to you. That is, which servers may
- introduce other servers behind them.
- You may limit what servers may be connected behind the H lined server.
-
- Syntax:
-H:servers which are allowed behind the hub:*:hub servername
- The 1st field defines what servernames the H lined server is allowed to
- introduce. Wildcards are allowed.
- The 2nd field is currently unused and should be left blank.
- The 3rd field should be the exact name of the server allowed to be a hub
- while connected to you. You may not use wildcards with this field unless
- the server's name includes a `*' (See N lines for host masking).
-
- Examples:
-H:*::dal-hub.us.dal.net
- This line will allow the server with the name `dal-hub.us.dal.net' to act
- as a hub server while you are connected to it, there are no restrictions
- on the names of the servers it may introduce.
-
-H:*.us.dal.net::usa-hub.us.dal.net
- This line will allow the server named `usa-hub.us.dal.net' to act as a hub
- while your server is connected to it, but it is limited to introducing
- servers with names matching `*.us.dal.net', so any servers trying to
- connect to `usa-hub.us.dal.net' with a name such as `bad-link.nz.dal.net'
- will be rejected by your server.
-
- --------------------
-
-3.12) P lines [OPTIONAL]
-
- These lines will open up ports other than the port you specified in your
- config.h when you compiled your ircd.
- Using internet domain ports below 1024 mean that you must run ircd from
- inetd. ircd can listen to ports in the UNIX domain as well as the internet
- domain. With UNIX domain ports you must give a unix socket file, you must
- also compile ircd with UNIXPORT defined in your config.h.
- You may limit usage of ports in the internet domain to certain hostmasks.
- You do not need to provide a P line for the default port you defined in
- your config.h, only extra ports you wish to open. You should compile ircd
- to run from port 7000, but it is recomended that you add a P line for port
- 6667 as most IRC clients default to this port when connecting. If you are
- connected to DALnet, you should have a P line for port 7325, this is the
- standard server connection port for all DALnet servers.
-
- Syntax:
-P:hostmask or UNIX socket file:*:*:port number
- The 1st field should either specify a path to a UNIX socket file, or give
- a hostmask to match against connecting clients on this port. Clients not
- matching this mask will be rejected.
- The 2nd and 3rd field's are currently unused, and should be left blank.
- The last field is the port number to open up and listen to for connections.
-
- Examples:
-P:*:::7325
- This will open up the DALnet server connection port and wait for
- connections. This line is mandatory if you run a server connected to DALnet
-
-P:*.net:::6665
- This line will open up port 6665 and wait for connections, connections from
- hosts not matching `*.net' will be rejected.
-
-P:/tmp/.ircd:*:*:6666
- This line will open up the port 6666 in the UNIX domain, with a socket file
- of: /tmp/.ircd.
-
- --------------------
-
-3.13) X lines [SUGGESTED]
-
- The /die and /restart commands can occasionally be misused or accidentally
- typed, causing a lot of trouble as hundreds of users are immediately
- disconnected and the server is thrown into chaos, sometimes unrestartable
- for hours. Furthermore, it can be maliciously used (in the case of O:line
- hacking, it's just about as much damage as you can cause). The X line tries
- to reduce the risk of this happening by providing passwords for the /die &
- /restart commands. The format of the X:line is simply:
-
- Syntax:
-X:password_for_die:password_for_restart
-
- Example:
-X:foo:bar
-
- --------------------
-
-3.14) Summary:
-
- Well, thats it for the lines you may use in your ircd.conf. Remember that
-ircd.conf is an art, just like any other type of programming. Some parts
-are particularly easy, but other's, like Y lines, can take a while to get
-used to. Given a little time experementing with lines on a network of
-servers, you will become well versed in ircd.conf programming.
-
-Good luck!
- --------------------
-
-[ Some text stolen from original example.conf modified for DALnet ]
-
- -- Roddy Vagg / <roddy@dal.net>
-
projects / serene-ircd.git / commitdiff