I know the chex standard ircd is not 100% compatible with the dalnet IRCD, but this page conatins a lot of good basic information contains a lot of good info on programming the ircd.conf file that is appropriate for us to use.

-- ircd.conf Programming -- (written for DALnet release ircd) v1.01 by Roddy Vagg -- <roddy@dal.net>  (Modified by Capt for chex.co.uk).

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

1) Introduction:

If you are running, or planning on running an IRC server, you will need to setup an ircd.conf, your ircd.conf must meet certain requirements of the server you are linking to.   This means it must contain all the standard lines (at a minimum H, U & Q), which you will be given.

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

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 recommended that you keep it in the same directory 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 useful 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 don't 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 preference 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 recommended 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 recommended. 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 recommended 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 incoming 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!).  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 connection 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 amount 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 until 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 accommodate 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 `queue' 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 each other, 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 don't 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 isn't 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 coming 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::*@*::1I:NOMATCH::*@*.fr::2I:NOMATCH::*@*.de::3I:NOMATCH::*@*.se::4I:NOMATCH::*@*.au::5I: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 harrassed etc by troublemakers. 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. 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.

o:*@*:GiJ.E\hGyjhaW:Anyone::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 each other 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 incoming 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:classN: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 incoming 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 incoming 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 incoming 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:35N: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 receives 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:35N:143.53.233.32:yourpass:somewhere.fr.dal.net::35C:ircd@176.43.652.31:apass:elsewhere.jp.dal.net:7235:35N: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. 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 disallow operators on certain servers to use commands such as remote /kill's, and remote /connects, this will effectively restrict the operators on the server to local operator privileges. 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 disallow 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 effectively 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.netL:*.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.

NOTE: on chex its very important to put your IP as the first parameter i.e.  P:216.74.72.100:::7000  (use the IP assigned to your account)

Extra lines used by Chex servers

B:hostmask:::#     This is the clone detector.

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

3.14) Summary:

Well, that's 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 experimenting with lines on a network of servers, you will become well versed in ircd.conf programming.

Good luck!