ircu2.9.32/doc/example.conf

# IRC - Internet Relay Chat, doc/example.conf
# Copyright (C) 1994, Helen Rose
#
#   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.
#
# This is an example configuration file for the IRC server
# 
# You only need an ircd.conf (IRC server configuration file) if you are
# running an IRC server. If you are running a standalone client this file
# is not necessary.
#
# This file will explain the various lines in the IRC server
# configuration file. Not all lines are mandatory. You can check to make
# sure that your configuration file is correct by using the program
# "chkconf", provided in the server distribution (and when you do "make
# install" this program will be installed in the same directory as the irc
# server). 
# 
# The options for whether a line is needed or not are: 
# MANDATORY: you absolutely MUST have this line
# NETWORKED: you must have this line if you are connecting this irc
#            server to any other server (servers can run standalone).
# 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. 
# NOT NECESSARY: an old or out of date line that isn't needed.
#
# MANDATORY lines are absolute *musts*, that is, if you do not have this
# line then your server will not work properly. SUGGESTED lines are
# close-to-mandatory (that is, the server will run without it, but you are
# highly encouraged to use these lines).
#
# Note that "*" in a field indicates an "unused" field.
#
#
# ========================================================================
# NOTE! this entire configuration file is read UPSIDE-DOWN! So if you have
# to put something in a specific order (for example, client-connection
# lines), put them in reverse order!
# ========================================================================
#
#
# M: [MANDATORY]. This line sets your server's name, description, and
# port number. Fields, in order, are: 
#
# M:hostname:*:Description Of Your Server:6667
#
M:csa.bu.edu:*:Boston University Computer Science Department:6667
#
# A: [MANDATORY]. This line lists your administrative information
# (contact address, etc). To view this information, /admin (server) will
# show it to you.
#
# The A: line has no set information, in fact, you can put arbitrary text
# in there if you wish (it is encouraged that you put at *least* a contact
# address for a person responsible for the irc server, however)
#
A:Boston University CS Department:Main Client Server:Helen Rose <hrose@cs.bu.edu>
#
# Y: [SUGGESTED]. These lines define connection classes. Connection
# classes allow you to fine-tune your client and server connections. It is
# suggested that clients and servers be placed in seperate classes, and if
# you have lots of server connections (if you do have lots of servers you
# shouldn't be reading this file :-) each set of servers (defined
# arbitrarily by you) should have its own class. If you have clients
# coming in from lots of different sites, you may want to seperate them
# out into classes. For instance, you may want to put local users in one
# class, with remote users in another class.
#
# The class numbers are not arbitrary. In auto-connecting servers -- that
# is, servers that you have a port number (e.g. 6667) on the end of the C:
# line (see below) the higher the number the higher the priority in
# auto-connecting.
#
# The fields in order are: class number, ping frequency (in seconds),
# connect frequency (in seconds), maximum number of links (used for
# auto-connecting, and for limiting the number of clients in that class),
# and sendq (this overrides any value set in include/config.h for #define
# MAXSENDQLENGTH).
#
# Note that it is a good idea to have ping frequency the same at both ends
# of the link.
# 
# 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).
Y:1:90:0:20:100000
#
# this is a normal server connection (normal as of March, 1994)
Y:2:90:300:1:600000
#
Y:10:90:0:3:100000
#
# I: [MANDATORY]. The I: lines are client-authorization lines. Without
# these lines, no clients will be able to connect to your server.
# Wildcards ("*") are permitted. Passwords are also permitted (clients can
# be configured to send passwords).
# 
# Ident (for more information on this, see rfc1413) can also be used by
# placing a @ in the appropriate fields.
#
# Fields are as follows:
# I:IP-address-mask:optional password:domain-mask::connection class (opt)
#
# With a password..... This will allow anyone from anywhere to connect
# as long as they know the password ("foobar"). Note listing this I: line
# first, it will be read *last*, meaning it is the "fall-through". That
# is, anyone who doesn't match the I: lines listed below must know the
# password ("foobar") to connect.
#
I:*@*:foobar:*@*::1
# This is a standard vanilla I: line which will permit anyone with an IP
# address starting with 128.197 OR with a hostname ending in .bu.edu to
# connect to the server. NOTE, the ircd matches on the *right-most* match,
# so if I connect as hrose@csa.bu.edu (which is hrose@128.197.10.3) I will
# show up on irc as hrose@csa.bu.edu since that is the first match it
# found. (Even though the second match is valid).
I:128.197.*::*.bu.edu::1
# 
# using ident
I:*@128.197.*::*@*.bu.edu::1
# and you can even specify just certain usernames running ident (as long
# as the client's site is running the ident daemon):
I:NOMATCH::hrose@csa.bu.edu::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).
# 
#
# O: [OPTIONAL]. These lines define operator access. You do not need to
# have an operator to run a server. A well configured leaf site should not
# need an operator online, if it's connections are well defined, the irc
# administrator can use kill -HUP on the ircd to reload the configuration
# file. 
# The fields are as follows:
# O:hostname (ident "@" permitted):password:NickName
# if the person in "NickName" is not coming from the hostname defined in
# the first field then the person will get the error message "No O: lines
# for your host". 
# NOTE that since Crypted Passwords are defined by default in
# include/config.h this text probably will not be plaintext. See
# ircd/crypt/README for more information.
#
O:*.bu.edu:Zaphod:Trillian::10
#
# and this line forces ident:
O:hrose@csa.bu.edu:Zaphod:Trillian::10
# 
# This line is a "local operator", it is specified with a lower-case "o"
# -- it is the only lower-case type in the ircd.conf file.
#
# this line permits the nickname "jhs" with the password of "ITBites" to
# be a local operator only (be able to issue commands locally -- can /kill
# and /squit and /connect -- but *only* locally)
#
o:*.bu.edu:ITBites:jhs::10
#
# a crypted password line (NOTE that if you have crypted passwords, *all*
# of you passwords must be crypted! In fact, if you are getting an error
# "Incorrect Password" it may well be because crypted passwords are
# defined and you have used plaintext.  So my example of plaintext and
# crypted strings in the same IRC server configuration file is an
# impossibility (but it is just theoretical, which is why I explained both).
#
O:rocker@csa.bu.edu:T0eiVgHrqeKTQ:Rocker::10
#
# U: [NOT NECESSARY]. This line defines the default server for the IRC
# client that ships with the server -- the default client is in irc/irc
# You should not use U: lines but instead use the UPHOST definition in
# include/config.h 
U:csa.bu.edu:foobar:csa.bu.edu
#
# C: [NETWORKED]. These lines define what servers your server tries to
# connect to. 
# N: [NETWORKED]. These lines define what servers your server permits
# connections to be initiated from. 
# C/N lines MUST be used in pairs. You cannot have one without the other. 
#
# C: lines contain the following fields:
# C:remote server's hostname:passwd:remote server's name:port:conn class
# (connection class)
# N: lines contain the following fields:
# N:remote server's hostname:passwd:remote server's name:host mask:conn class
# (connection class)
# "host mask" is the number of parts in *your* hostname to mask to. For
# instance, with my servername being "csa.bu.edu", if I wanted to present
# my servername to be "*.bu.edu" I would have a host-mask portion of "1". 
#
# it is *strongly* advised that your C/N line passwords be different for
# security's sake.
#
# ident is allowed in the server's hostname part of the field.
# these lines tell the server to automatically (note the port number, that
# means automatic connection) connect to cs-ftp.bu.edu:
C:hrose@cs-ftp.bu.edu:bigspark:cs-ftp.bu.edu:6667:2
N:hrose@cs-ftp.bu.edu:bigalpha:cs-ftp.bu.edu::2
#
# This server's connection lines are more vanilla, masking the host to
# *.bu.edu (as described above):
C:irc-2.mit.edu:camelsrk00l:irc-2.mit.edu::2
N:irc-2.mit.edu:andsoarellamas:irc-2.mit.edu:1:2
#
# K: [OPTIONAL]. These lines define user@host patterns to be banned from
# this particular server (with an optional time field). Note that K: lines
# are *not* global, and if you ban a user they can still use any other IRC
# server (unless they have specifically been banned there as well).
# 
# the fields are defined as:
# K:hostmask:time field:username
# wildcards are permitted in any one of the fields, in other words, you can
# K:*::* if you wanted (but your server wouldn't be used much ;-)
#
# This K: line bans the username "FSSPR" (the wildcards are used to make
# sure that any ident-checking character will match) on any machine from
# the University of Alaska.
K:*.alaska.edu::*FSSPR*
#
# This K: line bans any users from acs*.bu.edu between the hours of 8am
# and 12pm and 1pm and 5pm (the time is always the server's local time):
K:acs*.bu.edu:0800-1200,1300-1700:*
# Note that 24 hour time is used (no "AM" or "PM").
#
# R: [DISCOURAGED]. These lines restrict user access based on a more
# stringent checking system than is available in the K: line. It looks for
# a match (based on hostname and username) and then runs an outside
# program (which MUST be specified using a full pathname). The output of
# the program should be a string in the form "Y <message>" (which permits
# access for the user) or "N <message>" (which denies access for the
# user). If "Y <message>" is received by the server, the server ignores
# the message and permits access for the user. If "N <message>" is
# returned, the server tells the user that he/she is not permitted to
# access that irc server, and gives the reason.
#
# Again, like K: lines, R: lines are local and thus not very effective in
# blocking certain machines from having IRC access.
#
# Use of R: requires that you have defined R_LINES in include/config.h
#
# The fields are as follows:
# R:hostmask:/full/path/to/program:username
# you can use wildcards in either the hostmask or username portion
#
R:csl.bu.edu:/home/hrose/bin.sun3/sun3access:*
#
# Q: [DISCOURAGED]. These lines "quarantine" specified servers.  Because
# of the way they operates, the same Q: lines MUST be installed by
# everyone or the net will keep breaking. I CANNOT EMPHASIZE THIS ENOUGH.
# Do NOT use Q: lines lightly!
#
# The fields are as follows:
# Q:*:reason why quarantine is in place:servername
#
Q::this server is too slow and lags the net:cm5.eng.umd.edu
#
# L: [OPTIONAL]. These lines "Leaf" specified servers. They are only
# useful if you are a non-leaf site yourself. There are two ways you can
# use L: lines. The first will limit one particular site to a particular
# tree depth (including 0, which would mean the server has to connect with
# no servers linked behind it otherwise the connection will fail). The
# second will allow you to be selective about which other servers you wish
# the connecting server to behave as a leaf towards.
#
# The fields are as follows:
# L:disallow connections to this hostmask::server name:depth
# For example, this will force kaja.gi.alaska.edu to connect only as a
# leaf (if it is not a leaf, the link will be dropped):
L:::kaja.gi.alaska.edu
# This line will force cm5.eng.umd.edu to have a depth of only 1 below it
# (that is, it is allowed to have only leaves connected to it):
L:::cm5.eng.umd.edu:1
#
# This line will prohibit anything matching *.edu to be connected behind
# any server matching *.au:
L:*.edu::*.au
#
# H: [OPTIONAL]. These lines define who you permit to act as a "hub" to
# you (that is, who you permit to connect non-leafed servers to you).
#
# the first field may use wildcards, the third field *must* be an exact
# match for a server's name (NOT a server's hostname, if they differ, the
# server's name must be used). If the servername is a wildcard (e.g. *.au)
# that is an acceptable name for the third field. 
#
# The fields are as follows:
# H:servers which are permitted entry::hub server
#
# Example, permit cs-ftp.bu.edu to allow any servers behind it to connect:
H:*::cs-ftp.bu.edu
#
# Example, permit irc-2.mit.edu to allow any MIT servers behind it to
# connect: 
H:*.mit.edu::irc-2.mit.edu
#
# T: [OPTIONAL]. These lines allow you to specify different motd's for
# different types of clients. This could be used to give *.edu users 
# some informational message, while giving *.cl users a pointer to a
# closer server. 
#
# The fields are as follows:
# T:hostmask:pathname
# for example, to give *.edu users the MOTD file /usr/ircd/lib/edu.motd:
T:*.edu:/usr/ircd/lib/edu.motd
#
# P: [OPTIONAL]. This field allows the server to listen on various ports
# (other than 6667) for connections. Any internet domain port that is
# below 1024 means the ircd has to be run from inetd. The server can
# listen to ports in the UNIX domain or the internet domain. If you wish
# to create a port in the UNIX domain you must compile with UNIXPORT
# defined in include/config.h. If you are permitting connections to a
# seperate port, you can control access to that port by the host field.
#
# The fields are as follows::
# P:hostmask or UNIX socket file:*:*:port number
# for example, an internet domain socket on port 6665 for South African
# users: 
P:*.za:*:*:6665
#
# This line is an example of a UNIX domain socket in /tmp
P:/tmp/.ircd:*:*:6666