Magazyn Amiga 14/MA_Cover_14.iso/internet/unreal/doc/conf.doc

Text File | 2000-02-13 | 64.6 KB | 1,538 lines

esOriginally by Roddy Vagg -- [e-mail]
modified for UnrealIRCD3.0

--------------------

    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) ......................... L Lines
     3.12) ......................... H Lines
     3.13) ......................... P Lines
     3.14) ......................... T Lines
     3.15) ......................... E Lines
     3.16) ......................... e Lines
     3.17) ......................... Summary
    4) ............................. dccdeny.conf
     4.1) .......................... deny Lines
    5) ............................. chrestrict.conf
     5.1) .......................... msg Lines
     5.2) .......................... allow Lines
    6) ............................. vhost.conf
     6.1) .......................... vhost Lines
    7) ............................. unrealircd.conf
     7.1) .......................... Include Line
     7.2) .......................... Set KLINE_ADDRESS Line
     7.3) .......................... Set MODE_X Line
     7.4) .......................... Set TRUEHUB Line
     7.5) .......................... Set CONFIG_FILE_STOP Line
     7.6) .......................... Set SHOWOPERS Line
     7.7) .......................... Set KILLDIFF Line
     7.8) .......................... Set SHOWOPERMOTD Line
    8) ............................. network files
     8.1) .......................... Network Line
     8.2) .......................... Set ircnetwork Line
     8.3) .......................... Set defserver Line
     8.4) .......................... Set SERVICES_NAME Line
     8.5) .......................... Set oper_host Line
     8.6) .......................... Set admin_host Line
     8.7) .......................... Set locop_host Line
     8.8) .......................... Set sadmin_host Line
     8.9) .......................... Set netadmin_host Line
     8.10) ......................... Set coadmin_host Line
     8.11) ......................... Set techadmin_host Line
     8.12) ......................... Set hidden_host Line
     8.13) ......................... Set netdomain Line
     8.14) ......................... Set helpchan Line
     8.15) ......................... Set STATS_SERVER Line
     8.16) ......................... Set HUB Line
     8.17) ......................... Set iHAN Line
     8.18) ......................... Set net_quit Line

--------------------

1) Introduction:

  If you are running, or planning on running an IRC server for a network,
 you will need to setup an ircd.conf, your ircd.conf must meet the
 requirements of a linked network server which means it must contain all
 the standard network lines, these will be listed at the bottom of this
 document. (If you make your own network you may customize them yourself)

--------------------

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:IP:Description Of Your Server:7000
 The 1st field should be the `real' name of your server, not the short
 name.
 The 2nd field is the IP the server should bind to - "*" if all interfaces
     on the server
 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.irc.net::Walt's IRC 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 IRC Server:Admin - Walt Disney:[e-mail]

--------------------

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 [e-mail]
 (which is rmiller@205.133.127.8) I will show up on irc as
 [e-mail] 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::[e-mail]::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).

I:*@*:ONE:*@*.com::1
 Putting ONE is the second field says that only one user may connect through the
 use of this I:line. Once that one user is connected this I:line is ignored by
 other users.

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

 Syntax:

O:hostname:password:nickname::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::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.

--------------------

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 syntax 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.
 You may also specify a filename as a reason. To do so use |kc.reason as the
 reason. Replace reason with the reason for the ban. Note, all files must be in
 the format of kc.* to ensure no important configuration files are sent to the
 user.
 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 `[e-mail]'.

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:*.lamer.org:|kc.spamming:*
 This will reject all users from *.lamer.org and play the file kc.spamming as
 the reason.

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) L Lines [OPTIONAL/NETWORKED]

 These lines specify which servers are to behave as leaves, that is,
 servers that may not have any other servers connected to them.
 They will only be usefull if your server is a non-leaf (hub) server.
 Not only can you limit servers to leaves, but you can also specify
 what tree depth may appear after certain servers. If a server connects
 but tells your server that it has a larger tree depth behind it than is
 allowed via your L line for the server, the server will be rejected.
 A limit of `0' will mean the server may only be a leaf. A limit of `1'
 will mean that only leaf servers may be connected to the L lined server
 when it is connected to your server.
 You may also use L lines to restrict what servers may connect to certain
 servers while they are connected to your server.

 Syntax:
L:hostmask of disallowed servers:*:server name:depth
 The 1st field defines the limitations on servers allowed to connect to
 the L lined server by hostmask. If any server connects to the L lined
 server while it is connected to your server, and it's name matches the
 hostmask given here, it will be rejected. Wildcards are allowed. You do not
 need to put a value in this field.
 The 2nd field is currently unused and should be left blank.
 The 3rd field is the name of the server to be L lined, when this server
 connects to your server, the restrictions defined by the L line are placed
 on this server. Wildcards are allowed.
 The 4th field defines the depth of servers allowed to be connected behind
 the L lined server.

 Examples:
L:::leaf.de.dal.net
 This line will allow a server named `leaf.de.dal.net' to connect only as
 a leaf. So this server may not connect any other servers behind it.

L:::semi-hub.sg.dal.net:1
 This line will force the server named `semi-hub.sg.dal.net' to allow only
 leaf servers to connect behind it. ie: to have a tree depth of 1.

L:*.us.dal.net::*.au.dal.net
L:*.eu.dal.net::*.au.dal.net
 These lines will make sure that any server with a name matching
 *.au.dal.net will not introduce any servers matching *.us.dal.net or
 *.eu.dal.net. This can be usefull for stopping certain hubs from letting
 its autoconnects route the network badly.

--------------------

3.12) 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.13) 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.14) T lines [OPTIONAL]

 These lines allow you to have multiple MOTD and RULES files in the same IRCd.
 The idea of this is to allow you to have MOTD and RULES files in different
 languages for your users all over the world. The way this works is you can
 match a MOTD and RULES file to a certain part of a users host.  For example
 *.fr  (France) now you can make it so all *.fr users see a French MOTD and
 RULES where  as everyone else still sees the default.

 Syntax:
T:hostmask:motd file:rules file
 The first field is where you specify the hostmask to match. This should be a
 TLD (Top Level Domain) but doesn't have to be. The second is the location of
 the MOTD file to display, this should be relative to DPATH. The last field is
 the path to the RULES file, again this should also be relative to DPATH.  The
 best way to keep your T:lines MOTD/RULES files in order is to make a motds/ and
 rules/ then make files such as spanish.motd and spanish.rules etc.

 Examples:
T:bngr216-37-173ppp107.epix.net:motds/epix.motd:rules/epix.rules
 This T:line uses a matches a specific host. When a user with the host bngr216-
 37-173ppp107.epix.net requests a /MOTD they will see the file motds/epix.motd
 and when they request a /RULES they will see the file rules/epix.rules.

T:*.epix.net:motds/epix.motd:rules/epix.rules
 This T:line matches based on ISP. When a user from *.epix.net requests a /MOTD
 or /RULES the specified files are played.

T:*.dk:motds/danish.motd:rules/danish.rules
 This T:line matches based on TLD. This is probably the most efficient method to
 use. When a user from the .dk TLD requests a /MOTD the Danish MOTD is played
 when they request a /RULES the Danish RULES file is played.

--------------------

3.15) E Lines [OPTIONAL]

 These lines allow you to exclude certain people from a K:line, or to prevent
 certain people from receiving a K:line. E:lines can be used with a more strict
 host than a K:line so for example if you K:line *.net and then E:line
 splitrock.net only users from splitrock.net may connect. These lines are also
 often used to prevent the server's staff from being K:lined from that server.

 Syntax:
E:hostmask:reason:ident
 The first field is where you enter the hostmask that the E:line will apply to.
 The reason parameter allows you to specify why that hostmask is E:lined. The
 third field is optional. To E:line all idents just specify this field as an *.

 Examples:
E:*.epix.net:Admin's ISP:*
 This E:line affects all *.epix.net users with reason 'Admin's ISP'. The * in
 the ident field says that it applies to all *.epix.net users.

E:*.epix.net:Server Admin:n64master
 This E:line affects any *.epix.net user using the n64master ident, with reason 'Server Admin'. This is probably the best way to go if you are making the E:line
 to protect server staff.

--------------------

3.16) e Lines [OPTIONAL]

 These lines allow you to specify which hosts will not be scaned by the proxy
 scanner. This will allow you to make certain proxys to connect while the rest
 are still killed. Note, if you want to allow all proxys, don't e:line *, just
 disable it at compile time.

 Syntax:
e:IP address:*:*
 This line requires only one field, the first field is the IP address of the
 host to be e lined. Make sure you use an IP and not a hostname or this will not
 work.

 Examples:
e:234.45.32.1:*:*
 This will prevent any user who's host resolves to 234.45.32.1 from being
 scanned for an open wingate/proxy by the proxy scanner when they connect.

--------------------

3.17) 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!

--------------------

4) dccdeny.conf:

 The dccdeny.conf allows you to specify files which may not be sent through the
 use of DCC (Direct Client Connection). This is mainly to keep the speading of
 virii at a minimum on your network. It is strongly suggested that you set up a
 dccdeny.conf as it will help you provide a safe enviromnet for your users.

4.1) deny Lines:

 As with the ircd.conf, dccdeny.conf supports comments in the form of # comment.
 It is suggested that you place comments above each dccdeny for easy reference.

 Syntax:
deny filename reason
 The first field is required to be deny, this tells the server that this line
 specifies a file which should be denied. The second field is where you specify
 what file should be denied. The last field is where you specify a reason. It is
 recommended you place a web address such as http://www.nohack.net in the reason
 so if the user is infected with a virus, they can learn how to remove it.

deny dmsetup.exe You may be infected with DMSetup, visit http://www.nohack.net
 This line will deny users to send the file dmsetup.exe.  If they attempt to
 send this file the server will display the reason which is 'You may be infected
 with DMSetup, visit http://www.nohack.net.

deny *.jpg.bat You may be infected with a virus, visit http://www.nohack.net
 This line will deny sends matching *.jpg.bat and display the reason 'You may be infected with a virus, visit http://www.nohack.net' when a send is attempted.

--------------------

5) chrestrict.conf:

 The chrestrict.conf allows you to limit what channels users may join. This is
 strongly discouraged for most networks. This is just provided for the networks
 that wish to have one open channel on a specific topic.

--------------------

5.1) msg Lines:

 The msg line allows you to specify a message that will be played when a user
 attempts to join a channel that is not allowed.

 Syntax:
msg message
 The first field tells the server that this is a message line. The second field
 is where you specify the message that will be displayed when a user attempts to
 join a denied channel.

 Examples:
msg Sorry, the channel you attempted to join is not allowed on this network
 This line will display 'Sorry, the channel you attempted to join is not allowed
 on this network' when a user trys to enter a channel that is denied.

--------------------

5.2) allow Lines:

 The allow lines say which channels users are allowed to join. Any channel not
 in an allow line will be denied to the user.

 Syntax:
allow channel
 The first field tells the server this is an allow line. The second is where you
 specify the channel which users are allowed to join.

 Examples:
allow #help
 This line will allow users to join #help and deny them from joining all other
 channels.

--------------------

6) vhost.conf:

 The vhost.conf file allows you to integrate a BNC type program into your ircd.
 This command works through use of the SETHOST command. You must be set +x in
 order for you to be able to keep your vhost, setting -x will return you to your
 normal host.

6.1) vhost Lines:

 vhost lines are the lines that allow you to create specific vhosts for certain
 users. These lines are used along with the /VHOST login password command.

 Syntax:
vhost virtualhost username password hostmask
 The first field tells the server this is a vhost command. The second field is
 where you specify what the users host will be changed to once they use the
 /VHOST command. The third field is the username field and forth is password, a
 user must use the correct username and password in order to use the vhost. The
 last field is the hostmask. This allows you to specify which users can use that
 vhost based on host, to allow all users use *@*.

 Examples:
vhost i.work.at.the.foobar.net john21 asdf1234 *@*
 This line will grant the user the hostname i.work.at.the.foobar.net, if they
 supply the username john21 and the password asdf1234. This line allows any
 hostmask to use the line since it has *@*.

vhost i.am.a.lamer.org codemastr jnh32 n64master@*.epix.net
 This line will give the user the hostname i.am.a.lamer.org, if they supply the
 username codemastr and the password jnh32, but only if they match the hostmask
 n64master@*.epix.net.

--------------------

7) unrealircd.conf

 The unrealircd.conf allows you to change certain settings in your IRCd that
 used to be set at compile time. This feature is especially beneficial to
 Windows users since they use a precompiled version. The unrealircd.conf works
 along with your network file (explained in section 8) to provide a completely
 customized IRCd.

--------------------

7.1) Include Line:

 The include line allows you to tell the unrealircd.conf where your network file
 is located. This path must be relative to DPATH in order for your IRCd to work.

 Syntax:
Include .................: filename
 This line will say that the network file is located in the field filename,
 again the path to the file must be relative to DPATH.

 Examples:
Include .................: networks/roxnet.network
 This line says that you will be using the roxnet.network file, which is located
 in the networks directory. The networks/yourfile.network is most likely the
 format you will use if you keep the standard DPATH.

Include .................: roxnet.network
 This line says you will use the file roxnet.network which is located in the
 same directory as DPATH. This is valid although it is not the default.

--------------------

7.2) Set KLINE_ADDRESS Line:

 This line allows you to tell the IRCd what email should be displayed to a user
 when they are klined. It is strongly encouraged that you set this to a valid
 email address of someone on the server staff.

 Syntax:
Set KLINE_ADDRESS .......: emailaddress
 This line tells the server that the K:Line email address is located in the
 field emailaddress. Note, the emailaddress is not checked to see if it is valid
 so it is up to you to set it right.

 Examples:
Set KLINE_ADDRESS .......: [e-mail]
 This tells the server that the K:Line email address is [e-mail] and
 when a user gets klined this will be the email address shown to them.

--------------------

7.3) Set MODE_X Line:


 This line lets you tell the server whether or not to set a user +x when they
 connect to the server. Set it to 1 for yes, or 0 for no. It is encouraged that
 you set this to 1 as it will help prevent users against nukes and other
 malicious attacks.

 Syntax:
Set MODE_X ..............: 1/0
 If this line is set to 1 then the server will set users +x when they connect to
 the server. If it is set to 0 they will not be set +x on connect.

 Examples:
Set MODE_X ..............: 1
 This line has auto +x on connect enabled, this is the recommended setting for
 security purposes.

Set MODE_X ..............: 0
 This line has auto +x disabled. This is discouraged, but it is not required
 that auto +x be enabled.

--------------------

7.4) Set TRUEHUB Line:

 The Set TRUEHUB line allows you to tell the server the server you are a Hub and
 not a HalfHub. For most networks it is recommended that you set this to 1 to
 enable your server as a Hub. Note, if you compiled your server as a leaf and
 set this to 1 it will give an error. Only set this to 1 if you compiled your
 server as a hub.

 Syntax:
Set TRUEHUB .............: 1/0
 If this line is set to 1 then TRUEHUB is enabled. If it is set to 0 it is
 disabled. Again it is recommended for most networks that this is set to 1, and
 may only be used if you compiled as a Hub.

 Examples:
Set TRUEHUB .............: 1
 This line has TRUEHUB enabled, the server will send a GLOBOPS when it links.

Set TRUEHUB .............: 0
 This line has TRUEHUB disabled. The server will not send a GLOBOPS when it
 links, and it will link as a half hub.

--------------------

7.5) Set CONFIG_FILE_STOP Line:

 The Set CONFIG_FILE_STOP line must be set to 0 in order for your IRCd to work.
 If this is set to 1 your IRCd will give an error and won't start. This line is
 there just to makesure you take the time to read over your unrealircd.conf and
 configure it correctly.

 Syntax:
Set CONFIG_FILE_STOP ....: 1/0
 If this line is set to 1 then your IRCd will not start and will give you an
 error. It must be set to 0 in order to work. If set to 0 your IRCd will load
 normally.

 Examples:
Set CONFIG_FILE_STOP ....: 1
 In this line, the IRCd will die and give an error when it attempts to load the
 unrealircd.conf.

Set CONFIG_FILE_STOP ....: 0
 This line will allow the IRCd to load and run fine without giving any errors.

--------------------

7.6) Set SHOWOPERS line:

 This line sets whether non opers will be allowed to user /stats O to see a list
 of IRCOps on the server. This line may be set to whatever you want, although it
 is recommended you set this to 0 you may set it to 1.

 Syntax:
Set SHOWOPERS ...........: 1/0
 If this line is set to 1, then all users will be able to see a list of O:lines,
 note a non oper will not see the host allowed by this line for security
 reasons. If this line is set to 0 then only opers may request a /stats O.

 Examples:
Set SHOWOPERS ...........: 1
 This line allows all users to view a list of all the opers on a server. Again
 they will not be able to see the O:lines hosts or flags for security reasons.

Set SHOWOPERS ...........: 0
 This line only allows opers to request a /stats O, if a user requests it, it
 will return no information.

--------------------

7.7) Set KILLDIFF Line:

 This line allows you to set whether the new /kill format should be used. Then
 new format includes the server from which the /kill came from, the old format
 does not.

 Syntax:
Set KILLDIFF ............: 1/0
 If this line is set to 1 the new format will be used. If it is set to 0 then
 the standard format will be used. Note, if you set this to 1 then some users
 scripts may not function correctly, so if you want backwards compatibility set
 this to 0.

 Examples:
Set KILLDIFF ............: 1
 This line will make the server use the new /kill format, and the server name
 will be displayed.

Set KILLDIFF ............: 0
 This line will disable the new /kill format and the standard format will be
 displayed to the user. This is recommended for backwards compatibility.

--------------------

7.8) Set SHOWOPERMOTD Line:

 This line allows you to set whether or not the OperMOTD will be displayed to a
 user when they /oper. This is completely up to you as to what it shoul be set
 to, although it is recommended that if you do not have an OperMOTD you set this
 to 0 to avoid the error message from being displayed.

 Syntax:
Set SHOWOPERMOTD ........: 1/0
 If this line is set to 1 then the OperMOTD is displayed when the user /oper's.
 If it is set to 0 then the user must /OperMOTD to see the OperMOTD.

Set SHOWOPERMOTD ........: 1
 This line will make the server display the OperMOTD to the user when the /oper
 up.

Set SHOWOPERMOTD ........: 0
 This line will not make the server display the OperMOTD, and instead make the
 user have to type /OperMOTD to view the OperMOTD.

--------------------

8) network files:

 The networks files allow you to specify some information specific about your
 network you may use a current network file, or you can create your own. To
 create your own network file edit the template.network file to suit your needs,
 then add that file to your unrealircd.conf (See section 7.1). To use an
 existing network file just add the file to your unrealircd.conf (See section
 7.1).

--------------------

8.1) Network line:

 The Network line tells the server what the name of your IRC network is. You can
 set this line to anything you want, although it may not be left empty.

 Syntax:
Network >..........: yournetwork
 This line tells the server that your networks name is located in the field
 yournetwork. Note, yournetwork should be the same on all servers to let users
 know what network they are on.

 Examples:
Network >..........: NeoHorizon
 This tells the server that your network is called NeoHorizon and will display
 this to the user when it is requested.

--------------------

8.2) Set ircnetwork Line:

 This line does the same thing as the Network line, but it is required that Set
 ircnetwork be the exact same as the Network line or your IRCd will not work. So
 if your Network line has Bunker7 then your Set ircnetwork line must also have
 Bunker7.

 Syntax:
Set ircnetwork ....: yournetwork
 This tells the server that your network's name is found in the file called
 yournetwork.

 Examples:
Set ircnetwork ....: Bunker7
 This defines your IRC networks name as Bunker7, again if this was your line you
 must also have Bunker7 in your Network line.

--------------------

8.3) Set defserver Line:

 This line defines the server that the IRCd will tell users to go to when the
 IRCd is full. It is recommended that you point this to a random server pool if
 one is available.

 Syntax:
Set defserver .......: servername
 This tells the server to tell the user to go to the contents of the field names
 servername with the server is full.

 Examples:
Set defserver .......: irc.dragonwings.org
 This will display the server irc.dragonwings.org in the server is full message
 when a user attempts to connect to a full server.

--------------------

8.4) Set SERVICES_NAME Line:

 This line is very important. It must be set correctly for commands such as
 /nickserv, /chanserv, /memoserv, /operserv, etc. to work. If this is not set
 correctly you must use /msg servicesname to use services.

 Syntax:
Set SERVICES_NAME .: servicesserver
 This line tells the IRCd to redirect /nickserv, /chanserv etc to servicesserver
 and find the correct client.

 Examples:
Set SERVICES_NAME .: services.realchat.org
 This tells the server to redirect the services commands to
 services.realchat.org.

--------------------

8.5) Set oper_host Line:

 This allows you to specify a host that Global IRCOps will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set oper_host .....: operhost
 This tells the server to switch the host of the user to operhost when they
 /oper.

 Examples:
Set oper_host .....: opers.nevernet.net
 This will make a Global Oper's host change to opers.nevernet.net when they
 /oper up if iNAH is enabled.

--------------------

8.6) Set admin_host Line:

 This allows you to specify a host that Admins will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set admin_host ....: adminhost
 This tells the server to switch the host of the admin to adminhost when they
 /oper.

 Examples:
Set admin_host ....: admins.nevernet.net
 This will make a Admin's host change to admins.nevernet.net when they /oper up
 if iNAH is enabled.

--------------------

8.7) Set locop_host Line:

 This allows you to specify a host that Local IRCOps will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set locop_host ....: locophost
 This tells the server to switch the host of the Local Oper to locophost when
 they /oper.

 Examples:
Set locop_host ....: locop.nhn.net
 This will make a Local Oper's host change to locop.nhn.net when they /oper up
 if iNAH is enabled.

--------------------

8.8) Set sadmin_host Line:

 This allows you to specify a host that Services Admins will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set sadmin_host ...: sadminhost
 This tells the server to switch the host of the Services Admin to sadminhost
 when they /oper.

 Examples:
Set sadmin_host ...: sops.spynet.org
 This will make a Services Admin's host change to sops.spynet.org when they
 /oper up if iNAH is enabled.

--------------------

8.9) Set netadmin_host Line:

 This allows you to specify a host that NetAdmins will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set netadmin_host .: netadminhost
 This tells the server to switch the host of the NetAdmin to netadminhost when
 they /oper.

 Examples:
Set netadmin_host .: netadmin.spynet.org
 This will make a NetAdmin's host change to netadmin.spynet.org when they /oper
 up if iNAH is enabled.

--------------------

8.10) Set coadmin_host Line:

 This allows you to specify a host that CoAdmins will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set coadmin_host ..: coadminhost
 This tells the server to switch the host of the CoAdmin to coadminhost when
 they /oper.

 Examples:
Set coadmin_host ..: coadmin.starspace.net
 This will make a CoAdmin's host change to coadmin.starspace.net when they /oper
 up if iNAH is enabled.

--------------------

8.11) Set techadmin_host Line:

 This allows you to specify a host that TechAdmins will receive when they
 /oper, this only works if iNAH (See section 8.17) is enabled. If this is left
 blank it can cause some problems in your IRCd so it is recommended that you
 fill in a value.

 Syntax:
Set techadmin_host : techadminhost
 This tells the server to switch the host of the TechAdmin to techadminhost when
 they /oper.

 Examples:
Set techadmin_host : techadmin.starspace.net
 This will make a TechAdmin's host change to techadmin.starspace.net when they
 /oper up if iNAH is enabled.

--------------------

8.12) Set hidden_host Line:

 The Set hidden_host line allows you to specify what the masked part of a users
 host will look like when they set +x. Most networks tend to use a part of their
 network's name, for example MegaIRC uses mega for their hidden host. Note, if
 you leave this blank it may cause some problems in your IRCd.

 Syntax:
Set hidden_host ...: hiddenhost
 This tells the server to use the contents of hiddenhost as the masked part of a
 users host when they set +x.

 Examples:
Set hidden_host ...: neo
 This will use the word neo as the masked part of a users host.

--------------------

8.13) Set netdomain Line:

 This is used to specify the domain name of your IRC network. It is used to give
 the user your www address and ftp address in the /info reply. If you leave this
 blank, users may find difficulty getting help with a specific topic.

 Syntax:
Set netdomain .....: networkdomain
 This tells the server to use the field networkdomain for your networks domain.

 Examples:
Set netdomain .....: Infinity-IRC.org
 This will make the server set your domain as Infinity-IRC.org, and display the
 www and ftp as www.Infinity-IRC.org and ftp.Infinity-IRC.org in the /info
 reply.

--------------------

8.14) Set helpchan Line:

 This line specifies a channel which the user can go to for help, this is also
 used as a reply in the /info command. Again, leaving this blank may cause users
 to have problems when seeking help.

 Syntax:
Set helpchan ......: channel
 This will make the server use the field channel as your Official Help Channel
 in the /info reply.

 Examples:
Set helpchan ......: #help
 This will tell the user that the server's help channel is #help when they
 request a /info.

--------------------

8.15) Set STATS_SERVER Line:

 This line is used to tell the IRCd where your StatServ is located for use in
 the /StatServ command.

 Syntax:
Set STATS_SERVER ..: statserver
 This tells the server to send all /StatServ's to the field statserver.

 Examples:
Set STATS_SERVER ..: stats.tspre.org
 This tells the server to forward all /StatServ commands to stats.tspre.org.

--------------------

8.16) Set HUB Line:

 This line is obsolete and no longer in use. It is provided only for backwards
 compatibility.

--------------------

8.17) Set iNAH Line:

 This line allows you to specify whether or not oper's hosts should be changed
 when they send a /oper command. Most networks set this on, but there are some
 that do not like the host masking feature.

 Syntax:
Set iNAH ..........: 1/0
 Set this line to 1 to enable the oper host masking, or set it to 0 to disable
 the host masking.

 Examples:
Set iNAH ..........: 1
 This line tells the server to mask an oper's host when they issue a /oper
 command.

Set iNAH ..........: 0
 This tells the server not to mask an oper's host when they send a /oper
 command.

--------------------

8.18) Set net_quit Line:

 This line is no longer in use and is only provided for compatibility with older
 versions of Unreal.

--------------------

[ $Id: conf.doc,v 1.5 2000/02/11 00:43:07 codemastr Exp $ ]