[IRC-Dev CVS] [CVS] Module ircd-ircdev: Change committed
Brought to you by:
zolty
Menu
▾
▴
[IRC-Dev CVS] [CVS] Module ircd-ircdev: Change committed
|
From: Toni G. <zo...@us...> - 2005-01-05 18:01:27
|
CVSROOT : /cvsroot/irc-dev
Module : ircd-ircdev
Commit time: 2005-01-05 18:00:45 UTC
Modified files:
doc/en/Authors
Added files:
doc/en/asll.txt doc/en/chroot.txt doc/en/crules.txt
doc/en/cvs.txt doc/en/features.txt doc/en/freebsd.txt
doc/en/gline.txt doc/en/iauth.txt doc/en/indent.txt
doc/en/jupe.txt doc/en/log.txt doc/en/snomask.txt
doc/en/string.txt doc/en/who.txt doc/en/www.txt
Log message:
Documentación en doc/en (inglés)
---------------------- diff included ----------------------
Index: ircd-ircdev/doc/en/Authors
diff -u ircd-ircdev/doc/en/Authors:1.1 ircd-ircdev/doc/en/Authors:1.2
--- ircd-ircdev/doc/en/Authors:1.1 Tue Dec 28 03:15:44 2004
+++ ircd-ircdev/doc/en/Authors Wed Jan 5 10:00:32 2005
@@ -1,5 +1,6 @@
IRC was conceived of and written by Jarkko Oikarinen <jt...@to...>.
IRC was originally written in University of Oulu, Computing Center.
+
Jan 1991 - IRC 2.6 jt...@to...
- Multiple Channels and protocol changes
Index: ircd-ircdev/doc/en/asll.txt
diff -u /dev/null ircd-ircdev/doc/en/asll.txt:1.1
--- /dev/null Wed Jan 5 10:00:47 2005
+++ ircd-ircdev/doc/en/asll.txt Wed Jan 5 10:00:33 2005
@@ -0,0 +1,27 @@
+$Id: asll.txt,v 1.1 2005/01/05 18:00:33 zolty Exp $
+
+AsLL preliminary documentation, last updated 13 Jun 2002
+
+Server-to-server ping format:
+
+<prefix> G !<local-ts> <target> <local-ts>
+
+prefix = origin server numeric
+local-ts = local timestamp, as "seconds.miliseconds"
+target = target server numeric
+
+The local-ts is also sent instead of the origin field,
+so RTT information can be collected from non-AsLL servers,
+while preserving backward compatibility.
+
+
+Server-to-server pong format:
+
+<prefix> Z <origin> <target> <remote-ts> <diff> <local-ts>
+
+prefix = origin server numeric
+origin = origin server numeric
+target = target server numeric
+remote-ts = remote timestamp as received from an AsLL PING
+diff = difference between local-ts and remote-ts in miliseconds (integer)
+local-ts = local timestamp, as "seconds.miliseconds"
Index: ircd-ircdev/doc/en/chroot.txt
diff -u /dev/null ircd-ircdev/doc/en/chroot.txt:1.1
--- /dev/null Wed Jan 5 10:00:48 2005
+++ ircd-ircdev/doc/en/chroot.txt Wed Jan 5 10:00:33 2005
@@ -0,0 +1,93 @@
+$Id: chroot.txt,v 1.1 2005/01/05 18:00:33 zolty Exp $
+
+Using Chroot With IRCD
+
+Introduction
+
+Many system administrators like to run certain daemons within a
+"jail," a secure area of the file system that the daemon supposedly
+cannot break out of. That way, if the daemon is compromised somehow,
+the attacker cannot get out and affect the rest of the system in any
+way. There are problems with this--the standard UNIX way of doing
+this is with the chroot() call, which has been deprecated by the
+UNIX98 standard. Moreover, if an attacker has root within the jail,
+it is trivial to get *out* of the jail in most circumstances.
+Nevertheless, it is still often a good idea, and some systems can use
+more secure jails than other systems.
+
+Older versions of ircd supported chroot() operation within the server
+itself, but these were fraught with problems--chroot() can only be
+called by a process running as root, so ircd had to be started as
+root, typically by making it setuid, and would then have to drop those
+privileges after calling chroot(). Moreover, the design of the server
+would require that the server binary be in DPATH, or the /RESTART
+command would not work. In fact, /RESTART still wouldn't work,
+because the server would then attempt to change directories to a DPATH
+relative to the current root directory--and of course, the root
+directory often would not contain the shared libraries necessary for
+the ircd to even start.
+
+Configuring the Server For Use With Chroot
+
+In the versions of ircd starting with u2.10.11, all the setuid and
+chroot() code has been removed from the server. It is still possible
+to cause the daemon to run in a chroot() jail, however, through the
+use of a wrapper script. This requires making all paths compiled in
+to the server be relative to the new root directory; fortunately, this
+can be done by giving the configure script the --with-chroot=<dir>
+option. The <dir> argument specifies to configure where the root
+directory will be, and the server restart path, data path,
+configuration file, and debug log files will all be modified to be
+relative to this root directory. If the data path or configuration
+files cannot be made relative to the specified root directory,
+configure will issue an error message and exit; if the server restart
+path is not relative to the specified root directory, configure will
+issue a warning.
+
+The various paths are made relative to the root directory through the
+use of simple edits to their string representation. As an example,
+assume that we will be using the root directory "/home/ircd"; if the
+data path is "/home/ircd/lib," the data path that will be compiled
+into the server will be simply "/lib"; if, on the other hand, the
+specified data path were "/usr/local/lib/ircd," configure would issue
+an error, since there is no way to make the data path relative to the
+specified root directory.
+
+Preparing the Root Directory
+
+Most modern operating systems use shared libraries. When using
+chroot(), these libraries are searched for relative to the new root
+directory, and they must be present in order for a program to
+execute. The root directory must be prepared, therefore, by coping
+these libraries into the correct place. A script for this purpose has
+been provided in tools/mkchroot. This script relies on the command
+"ldd," which is used to report which shared libraries are used by a
+particular program; it also relies on ldd printing out the full path
+to those libraries. If either of these conditions is not met, it will
+be necessary to track down the libraries by hand and place them into
+the appropriate locations. The tools/mkchroot script takes as its
+first argument the path to the directory to be prepared as a root
+directory; following this argument should be a list of programs that
+will be running with that directory as the root directory.
+
+Using the Wrapper
+
+Also provided in the tools subdirectory are the sources for a simple
+wrapper program that can be used to start ircd. The program can be
+compiled by executing "cc -o wrapper tools/wrapper.c"; it must be run
+as root, but do not install it as root, since that would be a major
+security risk. This tool can be used to set the hard limit on file
+descriptors, as well as a root directory, and so may be useful to the
+administrator even if chroot() operation is not desired. A summary of
+the command line options for the wrapper tool can be obtained with the
+"-h" option. To set the file descriptor limit, use the "-l" option
+followed by the desired number of file descriptors; to select an
+alternative root directory, use "-c" followed by the desired root
+directory. You must use the "-u" option to specify a user name (or
+user ID) that the command should be run as; otherwise, the command
+will be run as root, which is not what you want (and why you should
+never install this program setuid root). Follow the command line
+arguments with "--" and the full path to the command that you wish to
+run, along with arguments to that command. The "--" tells the wrapper
+program to stop interpreting options, and is very important if you
+must give the command any options.
Index: ircd-ircdev/doc/en/crules.txt
diff -u /dev/null ircd-ircdev/doc/en/crules.txt:1.1
--- /dev/null Wed Jan 5 10:00:49 2005
+++ ircd-ircdev/doc/en/crules.txt Wed Jan 5 10:00:33 2005
@@ -0,0 +1,128 @@
+$Id: crules.txt,v 1.1 2005/01/05 18:00:33 zolty Exp $
+
+SmartRoute
+Rule based connects
+Draft 4 - Aug 19, 1994
+by Tony Vencill
+
+Rule based connects allow an admin to specify under what conditions
+a connect should not be allowed. If no rules are specified for a
+given "Connect" block it will be allowed under any condition.
+
+A rule may consist of any legal combination of the following functions
+and operators.
+
+Functions
+---------
+connected(targetmask) - true if a server other than that processing
+ the rule is connected that matches the
+ target mask
+directcon(targetmask) - true if a server other than that processing
+ the rule is directly connected that matches
+ the target mask
+via(viamask, targetmask) - true if a server other than that processing
+ the rule matches the target mask and is
+ connected via a directly connected server
+ that matches the via mask
+directop() - true if an oper is directly connected
+
+Unary operators
+---------------
+! eg: !argument - true if the argument is false
+
+Binary operartors
+-----------------
+&& eg: arg1&&arg2 - true if arg1 and arg2 are both true
+|| eg: arg1||arg2 - true if arg1, arg2, or both are true
+
+Parenthesis () are allowed for grouping arguments, but if no parenthesis
+are included, && will take precedence over ||, ! will take precedence
+over both && and ||, and the function will be evaluated from left to
+right. White space in a rule is ignored. Invalid characters in a rule
+will lead to the rule being ignored.
+
+Examples
+--------
+
+A simple example of a connect rule might be:
+
+connected(*eu.irc-dev*)
+
+This might be used in a US IRC-Dev server for a Europe CN pair to
+insure that a second Europe link is not allowed if one US-EU link
+already exists. Note that on the IRC-Dev, US server names are
+city.state.us.irc-dev.net and Europe server names are
+city.country.eu.irc-dev.net.
+
+A more interesting example might be:
+
+connected(*eu.irc-dev*) &&
+ ( !direct(*eu.irc-dev*) || via(manhat*, *eu.irc-dev*) )
+
+Imagine the Boston IRC-Dev server uses this rule on its Europe CN
+pairs. This says that if a Europe server is already connected, a
+Boston-Europe connect will not be allowed. It also says that if a
+Europe server does already exist and Boston is not directly connected
+to one or more Europe servers or Manhattan is, the Boston-Europe
+connect will not be allowed. This has the effect of allowing multiple
+US-EU links but attempting to limit these links to one server (ie:
+Boston will not initiate its first Europe link if another server is
+already linking Europe). This rule will also prefer to let Manhattan
+handle the US-EU link by disallowing Boston-Europe links if a Europe
+server is already linked to Manhattan.
+
+A example of the remaining function, directop(), is:
+
+connected(*eu.irc-dev*) || directop()
+
+If this line is used on Boston for the Paderborn CN pair, it will allow
+connects to Paderborn only if another Europe server is not already
+connected and there is not an oper on Boston. If this rule is
+overrideable (ie: is applied only to autoconnects as described below),
+then it will disallow Boston autoconnects to Paderborn while a Boston
+oper is online, but allow oper-initiated connects to Paderborn under any
+circumstance. This directop() function could be used to invoke less
+prefered routes only when an oper is not present to handle routing, or
+conversly to allow use of less preferable routes only when an oper is
+present to monitor their performance.
+
+ircd.conf entries
+-----------------
+
+A rule is listed in the ircd.conf file using a D or d line (which can
+be thought of as a "disallow" line). D lines will apply to all oper
+and server originated connects, while d lines will apply only to
+autoconnects (ie: they are overrideable by opers). The formats are:
+
+D:targetmask::rule
+d:targetmask::rule
+
+Remember that newlines are not allowed in conf lines. Two examples
+(from above) are:
+
+D:*eu.irc-dev*::connected(*eu.irc-dev*)
+d:*eu.irc-dev*::connected(*eu.irc-dev*) || directop()
+
+Connects originating from other servers will be checked against and
+matching D lines, while matching d lines will be ignored as it will not
+be clear whether or not the connection attempt is oper initiated.
+
+Checking and viewing rules
+--------------------------
+
+The chkconf program that comes with the servers has been modified to
+also check your connect rules. If running in debug mode, parsing errors
+will show up at debug level 8. To view rules online, "/stats d" can be
+used to see all rules and "/stats D" can be used to view those rules
+which affect oper initiated connects and accepts.
+
+Processing and storage
+----------------------
+
+The rules are parsed when the conf file is read and transformed into a
+more efficiently computed form, then all applicable rules are
+evaluated each time a connect command is given or an autoconnect is
+due. If more than one applicable rule is given, only one need
+evaluate to true for the connect to be allowed (ie: the rules are ored
+together). Note that conditions that exist when the connect is
+initiated might differ from conditions when the link is established.
Index: ircd-ircdev/doc/en/cvs.txt
diff -u /dev/null ircd-ircdev/doc/en/cvs.txt:1.1
--- /dev/null Wed Jan 5 10:00:50 2005
+++ ircd-ircdev/doc/en/cvs.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,89 @@
+$Id: cvs.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+Notes on checking out from the IRC-DevCVS archive and maintenance.
+
+General Strategy:
+The main trunk of the tree will be used for ongoing development only
+(alpha) this code is not intended to be used on the production network.
+When development has reached a point of relative stability a tag will be
+applied to the development branch and a beta tag will be applied to that
+branch. For beta test servers only the tagged branches will be used.
+When a tag is applied we will also produce a snapshot tarball of the
+tag. Once a beta tagged release has been proven stable any fixes will be
+merged into the main tagged version and the code will be voted on for
+release. Fixes after release will be tagged with a patchlevel tag.
+
+You check out a tagged release by specifying the -r tag option to cvs.
+This is the command to check out the most recent tagged version of
+IRC-Dev1.0.1:
+cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -r 1_0_1 -P ircd-ircdev
+
+Developers doing maintenance and bug fixes should only check out the
+current tagged patchlevel for the affected version. Once the fix has
+proven stable, it will be merged into the tree the fix is relative to.
+
+We will not merge the changes that have been made to IRC-Dev1.0 since
+it's release into the development branch, the IRC-Dev1.0 branch is a
+maintenance only branch.
+
+If you have any questions on how to check out tagged versions check out
+the IRC-Dev web page http://www.irc-dev.net or the cvs
+manual page. If you're really stumped feel free to ask in #irc-dev.
+
+We will put out new tarballs for every tagged release which will be
+available on the IRC-Dev web page.
+
+Naming Conventions:
+
+Tag Names:
+Major release - 1
+Beta release - 1_0_0
+Production patch - 1_0_0
+
+The tree currently looks like this:
+
+Trunk: development only
+------------------------------------------------
+ \ \
+ \----- u2_10_07 \---- u2_10_10 --- release ---------
+ \ \ \
+ \--- u2_10_07_pl9 \--- u2_10_10_beta06 \ u2_10_10_pl01
+
+Patches will be rolled into the tagged branch and eventually rolled into
+the development branch. All new development should be relative to the
+trunk, only bugfixes and maintenance coding should be applied to any
+tagged version. Developers doing maintenance should only check out the
+latest pl or beta tag and apply the changes relative to that tag. These
+changes will be committed to the tag they were checked out from and once
+proven stable they will be merged into the main tagged trunk by the
+maintainer.
+
+Where to get CVS:
+http://www.cvshome.org
+
+Checking out:
+First you need to login to cvs:
+cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev login
+
+It will prompt you for a password. There is no password so hit enter.
+
+To check out the recommended patchlevel for ircu2.10.07 use:
+cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -r u2_10_07_pl6 -P ircd-ircdev
+
+For the ircu2.10.10 beta archive use:
+cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -r u2_10_10_beta06 -P ircd-ircdev
+
+To check out the current development archive use:
+cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -P ircd-ircdev
+
+When you want to update your source tree later to the latest version, use
+cvs update -P
+
+inside ircd-ircdev/, the directory ircd-ircdev was checked out to.
+
+How to find the most current available release:
+We will announce the most current release tag when we make it available, in general
+you will check out the main branch of any given tree, if you want the current production
+release use the "u2_10_07" tag, for patched versions use a patchlevel tag "u2_10_07_pl6".
+You can always find the most recent tag for any version by looking at the IRC-Dev CVS
+archive: http://cvs.irc-dev.net/viewcvs.py/irc-dev/
Index: ircd-ircdev/doc/en/features.txt
diff -u /dev/null ircd-ircdev/doc/en/features.txt:1.1
--- /dev/null Wed Jan 5 10:00:50 2005
+++ ircd-ircdev/doc/en/features.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,975 @@
+$Id: features.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+Many of the old compile-time options are now configured through the
+server configuration file, ircd.conf. This file is intended to
+document each of these features. Logging, although also configured
+through the use of "Features" Block, is documented in doc/*/log.txt.
+NOTE THAT THESE NAMES ARE CASE SENSITIVE! Values are not case sensitive
+unless stated otherwise in the documentation for that feature.
+
+DOMAINNAME
+ * Type: string
+ * Default: picked by ./configure from /etc/resolv.conf
+
+This option allows you to specify what you consider to be "local." It
+is only used for statistics. When you issue the IRC command /STATS w,
+the server will respond with statistics of how many clients have been
+connecting to your server in the last minute, hour and day. It will
+give these statistics for all connections (including the servers), all
+clients (from anywhere) and also for clients whose hostname ends on
+the domain you specify here. So if you are an ISP and you want to
+know what the client load from your own domain is, specify that domain
+here. If you are unsure what to do, then it isn't really important
+what you give here, just don't give an empty string. A good guess is
+the last two parts of your own hostname (i.e., if your hostname is
+foo.bar.nowhere.org, specify "nowhere.org"). Note that the string you
+give should NOT start with a "." and you should not use quotes.
+
+
+RELIABLE_CLOCK
+ * Type: boolean
+ * Default: FALSE
+
+You should really ONLY specify "TRUE" here when your system clock is
+stable and accurate at all times (within a few seconds). If you are
+running ntpdate on a regular basis, or an equivalent like xntpd, to
+keep your system clock synchronized over the network, then you might
+have an accurate clock. However, this is not guaranteed; for example,
+it is known that xntpd gives unstable results on Linux in some cases.
+Note that an unstable clock is worse then an clock that has a constant
+offset, because the servers attempt to correct for a constant offset,
+but do not correct jumps of your system clock! In general you SHOULD
+be running ntpdate or equivalent AND make sure it works when you run a
+production server on IRC Network. Otherwise leave your clock alone and
+specify "FALSE" here. If unsure specify "FALSE"!
+
+
+BUFFERPOOL
+ * Type: integer
+ * Default: 27000000
+
+This specifies the maximum amount of RAM that your server will
+allocate for buffering sendQs. Small leafs can use a value as little
+as 1000000, while large HUBs need to specify a value as high as
+20000000. If you run out of memory, clients and/or servers are
+dropped with the error "Buffer allocation error"; then you will have
+to increase this number (and install more RAM if appropriate). If you
+want a more educated guess for this value then realize that any value
+is good if you _really_ would rather drop servers and clients than
+allocate more memory; this will be the case when there is the danger
+you may run out of memory for other allocations. Even if you run the
+daemon on a dedicated machine, specifying all of the RAM you have is a
+bad thing, because running out of memory is a lot worse than dropping
+clients in a controlled way; if possible you should have memory left
+for all the internal structures (channels, clients, ban lists, receive
+buffers) at all times. On average, clients seem to use 150 bytes of
+sendQ, but at peak moments this can easily increase to 2032 bytes per
+client (sendQs are allocated in chunks of 2032 bytes). The maximum
+possible amount that can be allocated for sendQs is the number of
+connected clients times whatever you specified as the maximum sendQ in
+your "Class" blocks in the ircd.conf file. That value will likely be larger
+then the amount of RAM you have. The educated guess I talked about
+earlier would be "number of clients" times * 2048 bytes + "size of
+net.burst" * n, where "n" is 1 for leafs and up to 5 for HUBs. The
+"size of net.burst" is about 125 bytes per online client (on the whole
+network). For large HUBs with 4000 clients on a network with 30,000
+users, this results in 27 Mb. Leafs could use 12 Mb. Of course you
+can use less when you have less than 4000 local clients. This value
+is in bytes.
+
+
+HAS_FERGUSON_FLUSHER
+ * Type: boolean
+ * Default: FALSE
+
+If you have a server with a lot of resources available, this option
+will cause the server to attempt to flush its internal buffers before
+dropping clients during a net break. Don't define this if you don't
+know for certain; if you're not careful this can end up rebooting
+FreeBSD boxes. For more information, refer to freebsd.txt, also in
+this directory.
+
+
+CLIENT_FLOOD
+ * Type: integer
+ * Default: 2048
+
+Currently, everything that a client sends to a server is read by the
+server and stored in a buffer (the clients receive queue). The server
+will process messages from this queue one by one (running over all
+clients each time). When a client sends new messages faster they get
+processed, and the size of its receive buffer reaches this value, the
+client is dropped with the error "Excess flood." A reasonable value
+is 1024 bytes. The maximum size is 8000 bytes.
+
+
+SERVER_PORT
+ * Type: integer
+ * Default: 4400
+
+When an IRC operator attempts a connect to another server, he or she
+may not know which port the connect should go to. In this server
+version, that operator may use the special port 0, in which case the
+server will take the port from the "Connect" block. If no port is
+specified in the "Connect" block, however, the port specified by this
+option will be used instead.
+
+
+NODEFAULTMOTD
+ * Type: boolean
+ * Default: TRUE
+
+Every time a client connects to your server, the full Message of the
+Day (as specified by the "Motd" block or by the file specified by the MPATH
+option) is sent to the client. The server sends the Message of the
+Day even though many clients permit the user to ignore it. Many users
+never read the message of the day anyway, making it a huge waste of
+bandwidth. If you specify "TRUE" here, then the server won't send the
+MOTD to the client by default; instead, it will only tell the client
+when the MOTD was last changed, and give instructions on how to obtain
+it by typing /MOTD.
+
+
+MOTD_BANNER
+ * Type: string
+ * Default: NULL
+
+If you enable NODEFAULTMOTD, this specifies a one-line banner to be sent
+to the client in addition to the instructions mentioned above.
+
+
+PROVIDER
+ * Type: string
+ * Default: NULL
+
+This string as added to the 001 numeric prefixed with "via" before the nick.
+It's used for providing promotional space to providers.
+
+
+KILL_IPMISMATCH
+ * Type: boolean
+ * Default: FALSE
+
+When a client connects to your server, the IP address of the client is
+reverse-resolved to obtain a hostname. Then that hostname is resolved
+to an IP address and compared with the IP address of the client. If
+they don't match, the client will appear with the IP address instead
+of the hostname, unless KILL_IPMISMATCH is "TRUE," in which case the
+client is simply disconnected.
+
+
+IDLE_FROM_MSG
+ * Type: boolean
+ * Default: TRUE
+
+The IRC command WHOIS gives an idle time for clients. If you want
+this idle time to be set to zero only when the client sends a PRIVMSG,
+then you should specify "TRUE" here. If you specify "FALSE," then the
+idle time will be nullified on all messages except the server
+PING/PONG.
+
+
+HUB
+ * Type: boolean
+ * Default: FALSE
+
+All servers of an IRC "network" are connected in a "tree" (no loops).
+Servers that are only connected to one other server (called the
+"uplink") are called "leafs"; servers that are connected to more than
+one other server are called HUBs. If you specify "FALSE" here then
+your server will prevent itself from accidentally connecting to two
+servers at once, thus keeping servers in poor network locations from
+routing traffic. Note that on Undernet, all newly linked servers are
+linked as leafs during their test phase, and should specify "FALSE"
+here.
+
+
+WALLOPS_OPER_ONLY
+ * Type: boolean
+ * Default: FALSE
+
+Setting this option removes the ability for clients that are not IRC
+operators to see wallops messages.
+
+
+NODNS
+ * Type: boolean
+ * Default: FALSE
+
+If you are playing with the server off-line, and no DNS is available,
+then long delays occur before the server starts up because it tries to
+resolve the name given in the General block (which usually isn't given
+in /etc/hosts) and for each connecting client. If you specify "TRUE"
+here, then a DNS lookup will be done only for the real hostname, and
+the server will not try to resolve clients that connect to
+"localhost." Note that other DNS lookups are still done for outbound
+connections.
+
+
+RANDOM_SEED
+ * Type: string
+ * Default: none
+
+When a client connects, the server sends the client a "cookie,"
+consisting of a random number. The client must return the cookie to
+the server verbatim. This is done to prevent IP spoofing. The cookie
+is generated by a pseudorandom number generator included in ircd.
+This generator must be seeded with a phrase that is kept secret, to
+ensure that the numbers it generates are not easily guessed. The
+value given to RANDOM_SEED may be a string of any length. It should
+not contain any characters that are considered special by the
+configuration file system, such as ":" or "#"; the string should be at
+least 8 characters long, but longer strings are better. The
+RANDOM_SEED may not be retrieved online.
+
+
+DEFAULT_LIST_PARAM
+ * Type: string
+ * Default: none
+
+The LIST command takes a single optional argument. If given, that
+argument is either a channel or a filter. If that argument is not
+given, then by default, /LIST will list all channels on the network.
+Needless to say, this can generate a large amount of data on large
+networks with many channels, as well as chewing up a lot of CPU time.
+Server administrators can therefore set a default filter to be applied
+to the channel list if the optional argument to LIST is omitted.
+
+
+NICKNAMEHISTORYLENGTH
+ * Type: integer
+ * Default: 800
+
+This value specifies the length of the nick name history list, which
+is used for /WHOWAS and some nickname chasing in /KILL and /KICK. It
+uses about 300 to 400 bytes per entry. Note that at a net break, so
+many client disappear that the whole "whowas" list is refreshed a few
+times (unless you make it rather large). A reasonable value is "total
+number of clients" / 25.
+
+
+HOST_HIDING
+ * Type: boolean
+ * Default: TRUE
+
+This selects whether local users can set umode +x, thus allowing them
+to hide their hostname if they have also registered with a channel
+service (i.e. they have the ACCOUNT flag set).
+
+
+HIDDEN_HOST
+ * Type: string
+ * Default: users.irc-dev.net
+
+This selects the suffix for the hidden hostmask (see HOST_HIDING).
+
+
+HIDDEN_IP
+ * Type: string
+ * Default: 127.0.0.1
+
+This selects a fake IP to be shown on /USERIP and /WHO %i when the
+target has a hidden host (see HOST_HIDING).
+
+
+CONNEXIT_NOTICES
+ * Type: boolean
+ * Default: FALSE
+
+This feature controls the generation of server notices when a user
+connects to or disconnects from the server. Enabling this feature may
+have a performance impact.
+
+
+OPLEVELS
+ * Type: boolean
+ * Default: TRUE
+
+Bla.
+
+
+LOCAL_CHANNELS
+ * Type: boolean
+ * Default: TRUE
+
+Bla.
+
+TOPIC_BURST
+ * Type: boolean
+ * Default: FALSE
+
+Bla.
+
+
+KILLCHASETIMELIMIT
+ * Type: integer
+ * Default: 30
+
+If a user changes his or her nickname just before an operator issues a
+/KILL, the /KILL will be changed to follow the user the operator
+intended to get. This option specifies the time limit, in seconds,
+for this nickname change; if the user changed his or her nickname more
+than this many seconds ago, the /KILL will not be changed. Don't
+change this unless you really need to.
+
+
+MAXCHANNELSPERUSER
+ * Type: integer
+ * Default: 10
+
+This is the maximum number of channels a user can be in at a time.
+The recommend value on IRC Network is currently 10. Since it only
+influences the local server when you decrease it, its up to you to
+decide if you want to use a smaller value. Do not use a larger value
+however, because it DOES cost more memory and bandwidth on all other
+servers when you allow users to join more channels simultaneously.
+One of the most important reasons to choose a smaller value is the
+fact that the "GUI" clients tend to stay on every channel they join
+(they aren't bothered by flooding in other channels). It DOES take
+your bandwidth however to send all those messages for 10 different
+channels to all your users.
+
+
+NICKLEN
+ * Type: integer
+ * Default: 12
+
+This is the allowed length of the nickname length. It may not be
+larger than the NICKLEN #define, and should usually be the same
+length. The real purpose of this feature is to permit easy increases
+in nickname length for a network.
+
+
+AVBANLEN
+ * Type: integer
+ * Default: 40
+
+This is the expected average ban mask length. Leave it at 40.
+
+
+MAXBANS
+ * Type: integer
+ * Default: 45
+
+This is the maximum number of bans a user may set on a given channel.
+
+
+MAXSILES
+ * Type: integer
+ * Default: 15
+
+This is the maximum number of masks a user can silence at a time. The
+silence command allows users to filter messages directed at them from
+certain users or domains, at the source server. Increasing this
+number allows users to use up more memory with inefficient use of the
+command. If you're not sure, don't change this.
+
+
+MAXWATCHS
+ * Type: integer
+ * Default: 128
+
+This is the maximum number of watchs a user can watch at a time. The
+watch command allows users to watch users. Increasing this
+number allows users to use up more memory with inefficient use of the
+command. If you're not sure, don't change this.
+
+
+HANGONGOODLINK
+ * Type: integer
+ * Default: 300
+
+Often the net breaks for a short time and it is useful to try to
+reestablish the same connection faster than CONNECTFREQUENCY would
+allow, but to keep from trying again on a bad connection, we require
+that the connection be open for a certain minimum time. The
+recommended value is 300 seconds.
+
+
+HANGONRETRYDELAY
+ * Type: integer
+ * Default: 10
+
+When attempting to quickly reestablish a connection to a good link, we
+give the net a few seconds to calm down. This time must be long enough
+for the other end to also notice that the connection is broken. The
+recommended value is 10 seconds.
+
+
+CONNECTTIMEOUT
+ * Type: integer
+ * Default: 90
+
+Number of seconds to wait for a connect(2) call to complete. NOTE:
+this must be at *LEAST* 10. When a client connects, it has
+CONNECTTIMEOUT - 10 seconds for its host to respond to an ident lookup
+query and for a DNS lookup to complete. It is recommended that you not
+change this value, but if you do, consider the fact that users whose
+clients do not support NOSPOOF will have to type /QUOTE PING <big
+number> before registration.
+
+
+MAXIMUM_LINKS
+ * Type: integer
+ * Default: 1
+
+This is the maximum number of links for the built-in client class 0.
+Leave this value at 1.
+
+
+PINGFREQUENCY
+ * Type: integer
+ * Default: 120
+
+If the daemon doesn't receive anything from any of its links within
+PINGFREQUENCY seconds, then the it will attempt to check for an active
+link with a PING message. If no reply is received within
+(PINGFREQUENCY * 2) seconds, then the connection will be closed. This
+value may be overridden by a "Class" block in "ircd.conf" if the
+connection's "Client" or "Connect" block in "ircd.conf" assigns a specific
+class to the connection (recommended).
+
+
+CONNECTFREQUENCY
+ * Type: integer
+ * Default: 600
+
+This is the default frequency that the server attempts to reconnect
+with its uplink server if it is set to auto connect to it. Note that
+this value is overridden by a "Class" block in ircd.conf if the "Connect"
+block in ircd.conf assign a specific class to the connection (recommended).
+
+
+DEFAULTMAXSENDQLENGTH
+ * Type: integer
+ * Default: 40000
+
+This is the default value of the maximum sendQ length of connection
+classes (see doc/ircd.sample-*.conf for details on "Class" blocks). You will
+probably always override this value in your "ircd.conf" with the
+"Class" block. The given value used to be an often used value for client
+sendQs.
+
+
+GLINEMAXUSERCOUNT
+ * Type: integer
+ * Default: 20
+
+G-lines that affect too many users have to be set with a special
+command, to prevent accidental G-lines of large blocks of users. This
+feature sets that particular threshold.
+
+
+SOCKSENDBUF
+ * Type: integer
+ * Default: 61440
+
+The send window size used for connections to other servers.
+
+
+SOCKRECVBUF
+ * Type: integer
+ * Default: 61440
+
+The receive window size used for connections to other servers.
+
+
+IPCHECK_CLONE_LIMIT
+ * Type: integer
+ * Default: 4
+
+The number of times you are allowed to connect within IPCHECK_CLONE_PERIOD
+seconds before you are considered abusing the server and throttled.
+
+
+IPCHECK_CLONE_PERIOD
+ * Type: integer
+ * Default: 40
+
+The number of seconds you are allowed to connect IPCHECK_CLONE_LIMIT times
+within before you are considered abusing the server and throttled.
+For instance if you set IPCHECK_CLONE_LIMIT to 1, and IPCHECK_CLONE_PERIOD
+to 10, then a user is only allowed to connect once in 10s, if they connect
+again within 10s, then they are considered to be connecting too fast and
+they are throttled.
+
+
+IPCHECK_CLONE_DELAY
+ * Type: integer
+ * Default: 600
+
+The number of seconds grace after restarting the server before the throttle
+code kicks in. Even if a user connects repetitively during this period,
+they will never get throttled. This is so after a restart users on a
+multiuser box can all connect to a server simultaniously without being
+considered an attack.
+
+
+MPATH
+ * Type: string
+ * Default: "ircd.motd"
+
+MPATH is the filename (relative to DPATH) or the full path of the
+"Message of the Day" file. The contents of this file will be sent to
+every client that connects to the server, after registration.
+
+
+RPATH
+ * Type: string
+ * Default: "remote.motd"
+
+RPATH is the filename (relative to DPATH) or the full path of the
+"Remote Message of the Day" file. The contents of this file will be
+sent to every remote client that issues a /MOTD <your server name>.
+Only the first three lines are sent, so you might want to keep that in
+mind while writing the file.
+
+
+PPATH
+ * Type: string
+ * Default: "ircd.pid"
+
+PPATH is the filename (relative to DPATH) or the full path of the
+"PID" file. It is used for storing the server's process ID so that a
+ps(1) isn't necessary.
+
+
+TOS_SERVER
+ * Type: integer
+ * Default: 0x08
+
+This option is used to specify the type of service that will be
+requested for connections to other servers. The value may be given as
+a hexadecimal integer.
+
+
+TOS_CLIENT
+ * Type: integer
+ * Default: 0x08
+
+This option is used to specify the type of service that will be
+requested for connections to users. The value may be given as a
+hexadecimal integer.
+
+
+POLLS_PER_LOOP
+ * Type: integer
+ * Default: 200
+
+Some of the engines used by the event interface get a number of events
+from the kernel at once. Since the number retrieved can impact
+performance, it can be tuned by modifying this value. The engines
+enforce a lower limit of 20.
+
+
+IRCD_RES_RETRIES
+ * Type: integer
+ * Default: 2
+
+This is the number of attempts the irc daemon's resolver will have at
+trying to solicit a response from the DNS server.
+
+
+IRCD_RES_TIMEOUT
+ * Type: integer
+ * Default: 4
+
+When a DNS query is sent, the irc daemon's resolver will wait this many
+seconds for a reply. After this timeout has expired, it will retry again,
+for as many retries as IRCD_RES_RETRIES allows. This can be cut short by
+AUTH_TIMEOUT expiring.
+NOTE: Has no effect when using the adns resolver.
+
+
+AUTH_TIMEOUT
+ * Type: integer
+ * Default: 9
+
+This is the maximum number of seconds to wait for the ident lookup and
+the DNS query to succeed. On older servers this was hard coded to 60 seconds.
+
+
+ANNOUNCE_INVITES
+ * Type: boolean
+ * Default: FALSE
+
+If set, send RPL_ISSUEDINVITE (345) to a channel's operators to
+announce when someone is invited to the channel.
+
+
+CONFIG_OPERCMDS
+ * Type: boolean
+ * Default: FALSE
+
+For u2.10.11, several new oper-only features have been added that
+involve changes to the server<->server protocol. Until the entire
+network is running the new version, these features cannot be enabled.
+This configuration option provides a single switch to prevent the use
+of these features until the entire network has been upgraded. It is
+not required that all servers set this to "TRUE" in order for the
+features to be used.
+
+
+HIS_SNOTICES
+ * Type: boolean
+ * Default: TRUE
+
+This removes server notices from users.
+
+
+HIS_SNOTICES_OPER_ONLY
+ * Type: boolean
+ * Default: TRUE
+
+This removes server notices from users.
+
+
+HIS_DEBUG_OPER_ONLY
+ * Type: boolean
+ * Default: TRUE
+
+This removes server wallops from users.
+
+
+HIS_WALLOPS
+ * Type: boolean
+ * Default: TRUE
+
+This removes operator wallops from users.
+
+
+HIS_MAP
+ * Type: boolean
+ * Default: TRUE
+
+This removes /MAP from users.
+
+
+HIS_LINKS
+ * Type: boolean
+ * Default: TRUE
+
+This removes /LINKS from users.
+
+
+HIS_TRACE
+ * Type: boolean
+ * Default: TRUE
+
+This removes /TRACE from users.
+
+
+HIS_STATS_a
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS a from users.
+
+
+HIS_STATS_c
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS c from users.
+
+
+HIS_STATS_d
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS d from users.
+
+
+HIS_STATS_e
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS e from users.
+
+
+HIS_STATS_f
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS f from users.
+
+
+HIS_STATS_g
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS g from users.
+
+
+HIS_STATS_h
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS h from users.
+
+
+HIS_STATS_i
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS i from users.
+
+
+HIS_STATS_j
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS j from users.
+
+
+HIS_STATS_k
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS k from users.
+
+
+HIS_STATS_k
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS k from users.
+
+
+HIS_STATS_l
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS l from users.
+
+
+HIS_STATS_L
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS L from users.
+
+
+HIS_STATS_m
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS m from users.
+
+
+HIS_STATS_M
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS M from users.
+
+
+HIS_STATS_o
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS o from users.
+
+
+HIS_STATS_p
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS p from users.
+
+
+HIS_STATS_q
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS q from users.
+
+
+HIS_STATS_r
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS r from users.
+
+
+HIS_STATS_R
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS R from users.
+
+
+HIS_STATS_t
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS t from users.
+
+
+HIS_STATS_T
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS T from users.
+
+
+HIS_STATS_u
+ * Type: boolean
+ * Default: FALSE
+
+This removes /STATS u from users.
+
+
+HIS_STATS_U
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS U from users.
+
+
+HIS_STATS_v
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS v from users.
+
+
+HIS_STATS_w
+ * Type: boolean
+ * Default: FALSE
+
+This removes /STATS w from users.
+
+
+HIS_STATS_x
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS x from users.
+
+
+HIS_STATS_y
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS y from users.
+
+
+HIS_STATS_z
+ * Type: boolean
+ * Default: TRUE
+
+This removes /STATS z from users.
+
+
+HIS_WHOIS_SERVERNAME
+ * Type: boolean
+ * Default: TRUE
+
+This removes server names in replies to /WHOIS.
+
+
+HIS_WHOIS_IDLETIME
+ * Type: boolean
+ * Default: TRUE
+
+This removes idle time in replies to /WHOIS.
+
+
+HIS_WHOIS_LOCALCHAN
+ * Type: boolean
+ * Default: TRUE
+
+This removes local channels in replies to /WHOIS.
+
+
+HIS_WHO_SERVERNAME
+ * Type: boolean
+ * Default: TRUE
+
+This removes server names in replies to /WHO.
+
+
+HIS_WHO_HOPCOUNT
+ * Type: boolean
+ * Default: TRUE
+
+This replaces hopcount to a static 3 in replies to /WHO.
+
+
+HIS_BANWHO
+ * Type: boolean
+ * Default: TRUE
+
+This doesn't show which server set a ban.
+
+
+HIS_KILLWHO
+ * Type: boolean
+ * Default: TRUE
+
+This doesn't show which server or oper performed a kill.
+
+
+HIS_REWRITE
+ * Type: boolean
+ * Default: TRUE
+
+This remaps remote numerics to come from the local server.
+
+
+HIS_REMOTE
+ * Type: integer
+ * Default: 1
+
+This disallows remote queries. (*sob!*)
+
+
+HIS_NETSPLIT
+ * Type: boolean
+ * Default: TRUE
+
+This removes server names in net break sign-offs.
+
+
+HIS_WHOIS_LOCALCHAN
+ * Type: boolean
+ * Default: TRUE
+
+This removes local channels in replies to /WHOIS.
+
+
+HIS_SERVERNAME
+ * Type: string
+ * Default: "*.irc-dev.net"
+
+This is the "name" of the server shown to users on a /WHOIS of another user.
+
+
+HIS_SERVERINFO
+ * Type: string
+ * Default: "IRC-Dev, Desarrollo de IRC / IRC Development"
+
+This is the "info" of the server shown to users on a /WHOIS of another user.
+
+
+HIS_URLSERVERS
+ * Type: string
+ * Default: "http://www.irc-dev.net/servers.php"
+
+This is the URL shown to users when they do a /MAP or /LINKS.
+
+
+NETWORK
+ * Type: string
+ * Default: "IRC-Dev"
+
+This defines the network name as reported in the 005 "supported features"
+numeric, and as used by the "Failed to deliver" message.
+
+
+URL_CLIENTS
+ * Type: string
+ * Default: "ftp://ftp.irc.org/pub/irc/clients"
+
+This defines a URL that users may visit to find compatible IRC clients.
Index: ircd-ircdev/doc/en/freebsd.txt
diff -u /dev/null ircd-ircdev/doc/en/freebsd.txt:1.1
--- /dev/null Wed Jan 5 10:00:51 2005
+++ ircd-ircdev/doc/en/freebsd.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,30 @@
+$Id: freebsd.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+This document pertains to kernel panics with FreeBSD involving mbufs.
+
+ This is a well documented problem with programs such as ircu, and inn that
+ involve a lot of clients, the solution is generally to set the option 'NMBCLUSTERS'
+ to a reasonably higher number the default is 1024, you should first try increasing
+ this *10 (10240) and continue checking mbuf usage with netstat -m.
+
+ It has been recommended that this be increased as far as *50 (51200) (although more
+ won't hurt, it uses more memory, so don't go too far overboard) it's been stated
+ over and over that the default is very low, but then, you're supposed to know how
+ to configure your OS for what you're doing right? =)
+
+ There is a note in the configuration for this:
+
+ # Note that you will probably want to bump up NMBCLUSTERS a lot to use
+ options NMBCLUSTERS=1024
+ Merely change the 1024 to the number that best suites your system.
+
+
+ -poptix po...@po...
+
+
+
+
+
+
+
+ April 17, 2000 Matthew S. Hallacy
Index: ircd-ircdev/doc/en/gline.txt
diff -u /dev/null ircd-ircdev/doc/en/gline.txt:1.1
--- /dev/null Wed Jan 5 10:00:51 2005
+++ ircd-ircdev/doc/en/gline.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,77 @@
+$Id: gline.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+GLINE documentation, last updated on 18 Mar 2000
+
+For an ordinary user, the syntax is:
+
+ GLINE [<mask>]
+
+If <mask> is given, and if a G-line for that server exists, all the
+information about that G-line is displayed. If <mask> is not given,
+an error is returned.
+
+For an operator, the syntax is:
+
+ GLINE [[!][+|-]<mask> [[<target>] <expiration> :<reason>]]
+
+If <mask> is not given, or if it is not prefixed by "+" or "-", the
+operation is exactly the same as if it were issued by an ordinary
+user, except that a list of all G-lines may be returned. If the "+"
+or "-" prefixes are used, the arguments <target>, <expiration>, and
+<reason> must be given, even if the G-line already exists. If
+<target> is "*" and the currently existing G-line is a local G-line,
+the local G-line will be erased and recreated with the parameters
+given, as described below. Otherwise, if the G-line currently exists,
+a prefix of "+" will cause an inactive G-line to be activated, whereas
+a prefix of "-" will cause an active G-line to be deactivated. If an
+attempt is made to modify a G-line set by a U-lined service such as
+Uworld, the change will be forced to be local. If the mask would not
+be permitted due to it being too wide or affecting too many users
+(governed by the GLINEMAXUSERCOUNT feature), the "!" prefix may be
+used to force the G-line to be set anyway.
+
+If the G-line does not already exist, it is created. The <target>
+parameter is used to select whether the G-line is only to apply to a
+single server (which need not be the local server) or to the whole
+network; if <target> is not given, it is assumed to be the local
+server. This could be useful if a single particular link is having
+problems, for instance. The <expiration> parameter is a number of
+seconds, not to exceed 7 days, for the G-line to exist. The <reason>
+argument is mandatory and should describe why this particular G-line
+was placed. The <mask> parameter must be a user@host mask; the host
+component must contain at least 2 non-wildcarded subdomains or, if it
+is an IP address, at least 16 bits. Normally, the host component may
+not contain *any* wildcards, but that can be overridden with the "!"
+prefix, as indicated above, if the operator has the WIDE_GLINE
+privilege.
+
+For a server, the syntax is:
+
+ <prefix> GL <target> (+|-)<mask> <expiration> <lastmod> :<reason>
+
+The <target> may be a server numeric or the character "*", for a
+globally scoped G-line. The <mask> argument is a server name, and
+must be prefixed by one of "+" (to indicate an active G-line) or "-"
+(to indicate an inactive G-line). The parameter <expiration> is a
+total number of seconds the G-line is to live for, and <lastmod> is
+used for versioning. Since GLINEs are propagated during netbursts,
+there must be some way of resolving conflicting states, which is the
+reason for this argument, and is also the reason G-lines cannot be
+deleted, only deactivated. The <reason> parameter indicates the
+reason the G-line was placed.
+
+If a GLINE is received with a <target> of "*", any G-lines with local
+scope are deleted, in preference for the globally scoped version. If
+the G-line already exists, the values of <lastmod> are compared; if
+the received <lastmod> is less than the stored <lastmod>, the existing
+G-line is resent to the server from which the GLINE message was
+received; otherwise, the G-line is activated or deactivated, depending
+on the <mask> prefix. If the G-line does not currently exist, it is
+created with the parameters given.
+
+For a U-lined server, this syntax should be used:
+
+ <prefix> GL <target> +<mask> <expiration> :<reason>
+ <prefix> GL <target> -<mask>
+
+The <lastmod> parameter will be assumed to be 0.
Index: ircd-ircdev/doc/en/iauth.txt
diff -u /dev/null ircd-ircdev/doc/en/iauth.txt:1.1
--- /dev/null Wed Jan 5 10:00:52 2005
+++ ircd-ircdev/doc/en/iauth.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,84 @@
+$Id: iauth.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+OVERVIEW
+========
+
+The IAUTH protocol used here is based on the one in ircd-hybrid 7.0,
+with minor changes to support login-on-connect and true IAUTH-side
+connection classes. (Several networks use central authorities to vary
+per-netblock connection limits; for example, users from one ISP may
+only be allowed one connection per IP, or one shell provider's
+netblock may be limited to 50 total connections.) IAUTH-side
+connection classes are controlled by a configuration option; if that
+is enabled, this document will say ICLASS is enabled.
+
+As in IRC, lines sent between the IRC and IAUTH servers are limited to
+512 characters, including the terminating <CR> <LF> sequence. As in
+IRC, the final argument on a line may be prefixed with :, and must be
+prefixed with : if it contains a space (decimal 32) character. Tokens
+are separated by single space characters, and each line is a separate
+command. The first token on a line is a case-insensitive command
+name; unrecognized commands must be ignored.
+
+GREETING
+========
+
+The IRC server connects and sends the Server greeting:
+ Server <servername> [password]
+If ICLASS is enabled, it sends a list of currently connected users:
+ MyUsers <uid>:<username>@<hostname>:<ip> ...
+The IRC server may send several MyUsers lines. When it has sent all
+MyUsers lines, it sends an EndUsers line:
+ EndUsers
+If ICLASS is disabled, EndUsers is sent immediately after Server.
+
+LOGIN REQUESTS
+==============
+
+When users connect, the IRC server sends a DoAuth request:
+ FullAuth <uid> <nickname> <username> <hostname> <ip> <account> <password> <realname>
+<uid> is a text string up to 20 characters long that identifies the
+client, and is unique a BadAuth response is received or until an
+ExitUser command is sent with the same uid (see below for details on
+those messages). <uid> may not contain a colon character. <nickname>
+is the client's initially requested nickname. <username> is the
+username returned by the ident server (RFC 1413), or a tilde-prefixed
+username supplied by the user. <hostname> is a text hostname,
+possibly in the form of a dotted quad or IPv6 address, or the
+character '?'. <ip> is a dotted quad IPv4 address or an IPv6 hex
+address. <account> and <password> are optional, and are used when the
+client attempts login-on-connect. <realname> is the realname
+specified by the client's USER message, and may contain spaces.
+
+If the client is accepted, the IAUTH server responds:
+ DoneAuth <uid> <username> <hostname> <class> [account]
+<username> is a replacement username, and <hostname> is a replacement
+hostname. If the <hostname> from DoAuth was ?, <hostname> is the
+result of a DNS lookup for the client. <class> is the name of a
+connection class for the client. <account> is optional and is
+provided if the user's login was successful.
+
+If the client is rejected, the IAUTH server responds:
+ BadAuth <uid> :<reason>
+<reason> may include spaces, and should have a leading ':' sentinel.
+
+DISCONNECTS
+===========
+
+If ICLASS is enabled, the IRC server sends ExitUser when a client
+disconnects:
+ ExitUser <uid>
+
+DIFFERENCES FROM IRCD-HYBRID
+============================
+
+The ircd-hybrid IAUTH code is slightly bitrotted and disabled in 7.0
+(through at least 7.0.1). This code added the following items:
+ MyUsers, EndUsers and ExitUser commands
+ Server passwords may contain whitespace and be prefixed by :
+ DoneAuth may include an account name
+ FullAuth command replaces DoAuth command and adds account, password,
+ realname parameters
+The Class command is present in ircd-hybrid's code but not used here.
+IP addresses in ircd-hybrid are "in unsigned int format," which is
+limited to IPv4, and so it is not used here.
Index: ircd-ircdev/doc/en/indent.txt
diff -u /dev/null ircd-ircdev/doc/en/indent.txt:1.1
--- /dev/null Wed Jan 5 10:00:52 2005
+++ ircd-ircdev/doc/en/indent.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,11 @@
+$Id: indent.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+If you want to indent this source file, in order to convert
+the source tree to the used programming style, you should use
+`make indent' in the base directory.
+
+For this to work you need to have `indent' version 2.2.9 or higher
+in your PATH. GNU indent 2.2.9 is available from all GNU sites,
+its main ftp site is ftp://ftp.gnu.org/gnu/indent/. Or you can
+download it directly from the webpage of its maintainer at
+http://www.xs4all.nl/~carlo17/indent/
Index: ircd-ircdev/doc/en/jupe.txt
diff -u /dev/null ircd-ircdev/doc/en/jupe.txt:1.1
--- /dev/null Wed Jan 5 10:00:53 2005
+++ ircd-ircdev/doc/en/jupe.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,59 @@
+$Id: jupe.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+JUPE documentation, last updated on 18 Mar 2000
+
+For an ordinary user, the syntax is:
+
+ JUPE [<server>]
+
+If <server> is given, and if a jupe for that server exists, all the
+information about that jupe is displayed. If <server> is not given,
+all un-expired jupes are displayed.
+
+For an operator, the syntax is:
+
+ JUPE [[+|-]<server> [[<target>] <expiration> :<reason>]]
+
+If <server> is not given, or if it is not prefixed by "+" or "-", the
+operation is exactly the same as if it were issued by an ordinary
+user. If the "+" or "-" prefixes are used, the arguments <target>,
+<expiration>, and <reason> must be given, even if the jupe already
+exists. If <target> is "*" and the currently existing jupe is a local
+jupe, the local jupe will be erased and recreated with the parameters
+given, as described below. Otherwise, if the jupe currently exists, a
+prefix of "+" will cause an inactive jupe to be activated, whereas a
+prefix of "-" will cause an active jupe to be deactivated.
+
+If the jupe does not already exist, it is created. The <target>
+parameter is used to select whether the jupe is only to apply to a
+single server (which need not be the local server) or to the whole
+network; if <target> is not given, it is assumed to be the local
+server. This could be useful if a single particular link is having
+problems, for instance. The <expiration> parameter is a number of
+seconds, not to exceed 7 days, for the jupe to exist. The <reason>
+argument is mandatory and should describe why this particular jupe was
+placed.
+
+For a server, the syntax is:
+
+ <prefix> JU <target> (+|-)<server> <expiration> <lastmod> :<reason>
+
+The <target> may be a server numeric or the character "*", for a
+globally scoped jupe. The <server> argument is a server name, and
+must be prefixed by one of "+" (to indicate an active jupe) or "-" (to
+indicate an inactive jupe). The parameter <expiration> is a total
+number of seconds the jupe is to live for, and <lastmod> is used for
+versioning. Since JUPEs are propagated during netbursts, there must
+be some way of resolving conflicting states, which is the reason for
+this argument, and is also the reason jupes cannot be deleted, only
+deactivated. The <reason> parameter indicates the reason the jupe was
+placed.
+
+If a JUPE is received with a <target> of "*", any jupes with local
+scope are deleted, in preference for the globally scoped version. If
+the jupe already exists, the values of <lastmod> are compared; if the
+received <lastmod> is less than the stored <lastmod>, the existing
+jupe is resent to the server from which the JUPE message was received;
+otherwise, the jupe is activated or deactivated, depending on the
+<server> prefix. If the jupe does not currently exist, it is created
+with the parameters given.
Index: ircd-ircdev/doc/en/log.txt
diff -u /dev/null ircd-ircdev/doc/en/log.txt:1.1
--- /dev/null Wed Jan 5 10:00:53 2005
+++ ircd-ircdev/doc/en/log.txt Wed Jan 5 10:00:34 2005
@@ -0,0 +1,195 @@
+$Id: log.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+
+Older versions of ircd had no consistent way of logging various
+actions. Some things, such as G-lines, were written out to log files
+with names compiled into the server. Others could only be logged
+through syslog. Some required that their log files exist beforehand.
+For u2.10.11, this situation has changed dramatically.
+
+All logging in the server is now unified through a single logging
+subsystem. Unfortunately, the server still does not generate all the
+logs that it could, and some more tuning is in store for the next
+major release of ircd. Nevertheless, the logs that are generated are
+far more consistent, and those log messages may be sent to a given
+file, to syslog, or even to online operators--or any combination of
+these three methods. This file is intended to describe configuration
+of the logging subsystem.
+
+All logs are classified by a "subsystem" and a "level." The subsystem
+is a major classification; each subsystem may be configured
+individually. The level classification is used to indicate how
+important the message is; subsystems may be configured to omit log
+messages with less than a certain importance--not unlike syslog.
+
+Levels
+
+Levels are used to classify the importance of various log messages.
+The most important level is the "CRIT" level; the least important is
+the "DEBUG" level. Each of the levels is also mapped to a
+corresponding syslog level, and some may even force generation of
+certain types of server notices. Each importance level is described
+below.
+
+ * CRIT - Used for very critical notifications, such as server
+ termination. This is mapped to the corresponding "CRIT" syslog
+ priority. This will also generate server notices to the "OLDSNO"
+ server notice mask.
+
+ * ERROR - Used to report important error conditions. This is mapped
+ to the corresponding "ERR" syslog priority.
+
+ * WARNING - Used to warn about certain conditions. This is mapped to
+ the corresponding "WARNING" syslog priority.
+
+ * NOTICE - Used for reporting important information. This is mapped
+ to the corresponding "NOTICE" syslog priority.
+
+ * TRACE - Used to tracing operation of the server. This is mapped to
+ the corresponding "INFO" syslog priority.
+
+ * INFO - Used for reporting unimportant but potentially useful
+ information. This is mapped to the corresponding "INFO" syslog
+ priority.
+
+ * DEBUG - Used for reporting debugging information. This is mapped
+ to the corresponding "DEBUG" syslog priority. This will also
+ generate server notices to the "DEBUG" server notice mask.
+
+Subsystems
+
+All of the subsystems are described below, along with their default
+logging configuration. There are no default log files to log to, and
+the default logging level is INFO (unless the server is compiled with
+debugging enabled)--this means that only notices of importance INFO or
+higher will be logged.
+
+ * SYSTEM - Used to report information that affects the server as a
+ whole. By default, log messages to this subsystem go nowhere.
+
+ * CONFIG - Used to report information concerning the configuration
+ file. By default, log messages to this subsystem go to the default
+ syslog facility, which defaults to "USER," and to the "OLDSNO"
+ server notice mask.
+
+ * OPERMODE - Used to report usage of /OPMODE and /CLEARMODE. By
+ default, log messages to this subsystem go to the "HACK4" server
+ notice mask.
+
+ * GLINE - Used to report usage of /GLINE, particularly BADCHANs. By
+ default, log messages to this subsystem ...
[truncated message content] |
