[IRC-Dev CVS] [CVS] Module ircdh: Change committed
Brought to you by:
zolty
Menu
▾
▴
[IRC-Dev CVS] [CVS] Module ircdh: Change committed
|
From: Toni G. <zo...@us...> - 2003-01-18 23:25:09
|
CVSROOT : /cvsroot/irc-dev
Module : ircdh
Commit time: 2003-01-18 23:25:08 UTC
Removed files:
doc/Authors doc/Configure.help doc/irc.1 doc/ircd.8
doc/readme.crules doc/readme.indent doc/readme.who doc/readme.www
Log message:
Documentacion
---------------------- diff included ----------------------
Index: ircdh/doc/Authors
diff -u ircdh/doc/Authors:1.1.1.1 ircdh/doc/Authors:removed
--- ircdh/doc/Authors:1.1.1.1 Fri Jul 26 14:58:23 2002
+++ ircdh/doc/Authors Sat Jan 18 15:25:08 2003
@@ -1,171 +0,0 @@
-/************************************************************************
- * IRC - Internet Relay Chat, doc/AUTHORS
- * Copyright (C) 1990
- *
- * AUTHORS FILE:
- * This file attempts to remember all contributors to the IRC
- * developement. Names can be only added this file, no name
- * should never be removed. This file must be included into all
- * distributions of IRC and derived works.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 1, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-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
-
-Contributions were made by a cast of dozens, including the following:
-
-Markku Jarvinen <mt...@tu...>: Emacs-like editing facility for the client
-
-Kimmo Suominen <ki...@ka...>: HP-UX port
-
-Jeff Trim <jt...@or...>: enhancements and advice
-
-Vijay Subramaniam <vi...@ll...>: advice and ruthless publicity
-
-Karl Kleinpaste <ka...@ci...>: user's manual
-
-Greg Lindahl <gl...@vi...>: AUTOMATON code, the Wumpus GM automaton,
-myriad bug fixes
-
-Bill Wisner <wi...@ha...>: numerous bug fixes and code
-enhancements
-
-Tom Davis <con...@ze...> and Tim Russell <ru...@ze...>:
-VMS modifications
-
-Markku Savela <ms...@te...>: advice, support, and being the
-incentive to do some of our *own* coding. :)
-
-Tom Hopkins <ho...@bu...>: bug fixes, quarantine lines,
-consolidation of various patches.
-
-Christopher Davis <ck...@cs...>: EFnet/Anet gateway coding,
-many automata ;), documentation fixing.
-
-Helen Rose <hr...@cs...>: documentation updating, and fixing.
-
-Tom Hinds <ro...@bu...>: emacs client updating.
-
-Tim Miller <ce...@bu...>: various server and client-breaking
-features.
-
-Darren Reed <av...@co...>: various bug fixes and enhancements.
-Introduced nickname and channelname hash tables into the server.
-
-The version 2.2 release was coordinated by Mike Bolotski
-<mi...@sa...>.
-
-The version 2.4 release was coordinated by Markku Savela and
-Chelsea Ashley Dyerman
-
-The version 2.5.2 release was coordinated by Christopher Davis, Helen Rose,
-and Tom Hopkins.
-
-The versions 2.6.2, 2.7 and 2.8 releases were coordinated by Darren Reed.
-
-Contributions for the 2.8 release from the following people:
-Matthew Green <ph...@co...>
-Chuck Kane <ck...@ec...>
-Matt Lyle <ma...@oc...>
-Vesa Ruokonen <ruo...@lu...>
-
-Markku Savela <Mar...@vt...> / April 1990
-Fixed various bugs in 2.2PL1 release server (2.2msa.4) and changed
-sockets to use non-blocking mode (2.2msa.9). [I have absolutely
-nothing to do with clients :-]
-
-Chelsea Ashley Dyerman <ch...@ea...> / April 1990
-Rewrote the Makefiles, restructuring of source tree. Added libIrcd.a to
-the Makefile macros, numerous reformatting of server text messages, and
-added mkversion.sh to keep track of compilation statistics. Numerous
-bug fixes and enhancements, and co-coordinator of the 2.4 release.
-
-Jarle Lyngaas (nm...@al...) added Note functions to ircd.
-
-Armin Gruner <gr...@in...> / May, June 1990:
-* Patched KILL-line feature for ircd.conf, works now.
- Enhancement: Time intervals can be specified in passwd-field.
- Result: KILL-Line is only active during these intervals
-* Patched PRIVMSG handling, now OPER can specify masks for sending
- private messages, advantage: msg to all at a specified server or host.
-* Little tests on irc 2.5 alpha, fixed some little typos in client code.
- Change: common/debug.c has been moved to ircd/s_debug.c, and a
- irc/c_debug.c has been created, for the benefit that wrong server msg
- are displayed if client does not recognize them. (strange, if a server
- sends an 'unknown command', isn't it?)
-
-Tom Hopkins <ho...@bu...> / September, October 1990:
-* Patched msa's K lines for servers (Q lines).
-* Consolidated several patches, including Stealth's logging patch.
-* Fixed several minor bugs.
-* Has done lots of other stuff that I can't seem to remember, but he
- always works on code, so he has to have done alot more than three
- lines worth. :)
-
-Thanks go to those persons not mentioned here who have added their advice,
-opinions, and code to IRC.
-
-Various modifications, bugreports, cleanups and testing by:
-
-Hugo Calendar <hu...@uc...>
-Bo Adler <ad...@cs...>
-Michael Sandrof <ms...@an...>
-Jon Solomon <js...@cs...>
-Jan Peterson <jl...@ha...>
-Nathan Glasser <na...@br...>
-Helen Rose <hr...@ef...>
-Mike Pelletier <st...@ca...>
-Basalat Ali Raja <gw...@ta...>
-Eric P. Scott <ep...@to...>
-Dan Goodwin <fo...@wp...>
-Noah Friedman <fri...@ai...>
-
-
-UNDERNET (1991 - 1999)
---------
-
-The Undernet versions (TSpre8, u2.9 and u2.10) are based on ircd-2.8.10 and
-contain thousands of hours of work by Carlo Wood <ca...@ru...>
-(Run on IRC). The number of protocol enhancements, changes and additions that
-have been added are too many to summarize. All patches are kept in the patch
-repository at http://www.xs4all.nl/~carlo17/ircd-dev/
-
-Various additions and bugfixes have been contributed by:
-
-Aaron <agi...@sc...>
-CapVideo <ma...@pu...>
-Chaos <si...@tr...>
-Cym <cy...@ac...>
-Derrick <di...@se...>
-Ensor <dh...@ra...>
-flux <cml...@uc...>
-Ghostwolf <fo...@wo...>
-Jamey <wo...@du...>
-Jarle <ja...@II...>
-Kev <kl...@mi...>
-Nemesi <co...@ti...>
-Niels <ni...@ho...>
-record <jeg...@cl...>
-smg <sm...@lm...>
-SeKs <in...@st...>
-Simon- <si...@pe...>
-Starfox <st...@qu...>
-Trio <tr...@b6...>
-WildThang <dvm...@an...>
-Xorath <vo...@wh...>
Index: ircdh/doc/Configure.help
diff -u ircdh/doc/Configure.help:1.2 ircdh/doc/Configure.help:removed
--- ircdh/doc/Configure.help:1.2 Sat Jul 27 02:55:54 2002
+++ ircdh/doc/Configure.help Sat Jan 18 15:25:08 2003
@@ -1,1230 +0,0 @@
-# Format of this file: description<nl>variable<nl>helptext<nl><nl>.
-# If the question being documented is of type "choice", we list
-# only the first occurring config variable. The help texts
-# must not contain empty lines. No variable should occur twice; if it
-# does, only the first occurrence will be used by Configure. The lines
-# in a help text should be indented two positions. Lines starting with
-# `#' are ignored. Limit your lines to 78 characters.
-#
-# If you add a help text to this file, please try to be as gentle as
-# possible. Don't use unexplained acronyms and generally write for the
-# hypothetical admin who has just downloaded ircu for the first time.
-# Tell them what to do if they're unsure. Technical information
-# should go in a README in the Documentation directory. Mention all
-# the relevant READMEs and HOWTOs in the help text.
-#
-# All this was shamelessly stolen from several different sources. Many
-# thanks to all the contributors. The texts are copyrighted # (c) 1997
-# by Carlo Wood and governed by the GNU Public License.
-#
-
-Do you want to change your previous configuration
-CHANGE_CONFIG
- You will be presented a series of questions that you have to answer
- in order to configure the IRC daemon, prior to compilation.
- If you went through this before, then your choices have been stored
- in a file '.config'. If you want to use the same stored configuration
- now, specify 'n'; this will quickly skip through all questions that
- you already answered previously, only prompting you for NEW questions.
- Note that NEW questions only can occur when you just upgraded to a
- new version. Note also that if you abort by pressing ^C (control-C)
- anywhere, then all answers are lost; you must finish it before the
- answers are stored.
- Pressing a 'c' or 'C' (followed by a return) on any question will
- Continue the script in "use_defaults mode", that means that it will
- take all default values unless it finds a NEW question (like when you
- specify a 'n' here). 'C' will finish everything, but a 'c' will
- only finish the current paragraph.
- If you are unsure, or if you want to change a previously entered
- configuration, specify 'y'.
-
-Which compiler do you want to use
-CC
- Here you need to specify the C compiler you want to use.
- Using 'gcc' is highly recommended, you might even want to install it
- on your machine first. Note that you can specify the full path if you
- are not sure if the compiler is in your PATH (or whether or not the right
- compiler will be used). An example is: "/usr/ucb/cc".
- The package needs an ANSI compiler. Some compilers need an extra option
- to compile ANSI C. In those cases you can add these options also here.
- For example, on a HPUX-8.x you would use (if you don't have gcc):
- "cc -Aa -D_HPUX_SOURCE".
- Note that you should not use quotes.
-
-What flags should I pass to $CC
-CFLAGS
- These are the compiler flags, used for CC when compiling.
- If you are not using gcc, it might be possible that your compiler is not
- supporting -g and -O at the same time. The -g option is necessary to be
- able to debug the daemon in the case it contains a bug that makes the
- ircd core dump. Unless you use a version that is proven to be VERY stable,
- it is highly recommended to use this option. All Undernet production servers
- are expected to use it in order to help coder-com to track down bugs.
- The -O3 will optimize the code - it also makes debugging harder.
- If you have plenty of cpu cycles then you can use -O2 instead of -O3:
- it will disable inlining which makes it easier to debug or core dump,
- the daemon will use a few percent more cpu however.
- If you are not running a production server you should remove the -Ox.
- Ircd developers can optionally use more options to turn on extra warnings.
- Developers (which are using gcc of course ;), should use:
- "-g -Wall -pedantic -DGODMODE"
- Note that you should not use quotes.
- Note that the server uses several non-ANSI (though POSIX.1) function calls.
-
-Do you need extra include directories
-EXTRA_INCLUDEDIRS
- If your compiler needs extra include directories, you can specify them
- here as a space separated list of directories. Do not use quotes and do
- not specify the '-I' prefix. Usually you don't have to specify any
- extra include directory, in that case you should specify "none" here.
- If unsure, try "none" (without quotes) and see if all the '#include'
- header files are found during compilation.
-
-Which linker flags do you need
-LDFLAGS
- Here you can specify extra flags that will be passed to the linker.
- Usually you will not need to pass any flags and you can therefore
- specify "none" here (without the quotes).
- SunOS users may want to add "-Bstatic" (but only if you need it).
- You can also specify any "-L..." flags here if you need those for
- extra libraries.
-
-Which extra libraries do you need
-IRCDLIBS
- Some Operating Systems need linking with extra libraries for some of the
- functions used by the daemon. In some cases, it is not known which
- libraries are needed, even when the Operating System is known. This is
- for instance the case with SunOS, some need -lresolv, while others don't.
- If you forget to add a library then this will result in 'undefined variables'
- during linking. If you do not know which library to add, it might be
- helpful to use the unix command `nm', which lists the variables of a
- library. For instance, if you get "unknown variable '_res_mkquery'", and you
- wonder if this is in /usr/lib/libresolv.so, you can do:
- nm /usr/lib/libresolv.so | grep res_mkquery
- Do not use the leading '_' in the grep, this underscore is added by the
- assembler but is not part of the original variable name and does not show
- up in the output of nm.
- Most libraries are in /lib or /usr/lib, which are scanned by default. In
- some cases you will need to tell the linker where to search for a library.
- You can do this by adding an -L... option to IRCDLIBS. For instance:
- "-L/usr/ucblib -lucb" will look for 'libucb.so' in /usr/ucblib too.
- Here is a list of what you MAYBE need to specify depending on your
- Operating System:
- OS Specify here
- NeXT != 2.0 -lsys_s
- Dynix/ptx -lsocket -linet -lnsl -lseq
- Dell SVR4 -lsocket -lnsl -lucb
- All others Default provided by autoconf
- If unsure use the default provided by autoconf.
-
-Where should I install the ircd binary
-BINDIR
- After compilation (by typing 'make'), you can install the server with
- the command 'make install'. This will install the ircd in the directory
- you specify here. The package tries to use a meaningful name by naming
- the binary "ircd.<tag>", where <tag> is the name of the last patch that
- was applied by the maintainer. A symbolic link (to be specified next)
- will be used to point to this binary. This allows a /RESTART to
- immediately start the new version, while keeping the old binary.
- Note that you need to have write permissions in this directory during
- the install. Please re-check the permissions/owner and group after
- installation.
-
-What should the name of the installed symbolic link to the executable be
-SYMLINK
- 'make install' installs the binary with an unique name, however it makes
- a symbolic link to this newly installed executable which always has the
- same name, so you can use /RESTART and/or use this name in scripts that
- automatically restart the ircd after a reboot or crash.
- Here you can specify the name of that symbolic link. Note that it may
- not contain a '/'; it is just the name if the symbolic link and will be
- installed in BINDIR.
-
-Which permissions do you want the binary to have
-IRCDMODE
- Here you need to specify the octal file mode of the ircd binary.
- Recommended is 711 - but you might need setuid or something.
- Note that using a setuid and starting the daemon as another user
- does prohibit the daemon from core dumping in case of a crash on some
- Operating Systems.
-
-Which owner do you want the binary to have
-IRCDOWN
-This will be the owner of the ircd binary after installation.
-
-Which group do you want the binary to have
-IRCDGRP
-This will be the group of the ircd binary after installation.
-
-Where should I install the man page
-MANDIR
- This is the base directory where the manual page of the ircd is installed.
- If you are not root on your system, you can change it to your personal
- manpath directory (which of course should be in your MANPATH environment
- variable then).
-
-Use inlining for a few crucial functions
-FORCEINLINE
- This will increases the size of the executable with 7 kb, but it also
- speeds up execution a bit :). Your compiler needs to understand the
- keyword __inline__ (GNU gcc and egcs do).
- If unsure, try if `y' compiles. If it doesn't, you can try using a
- C++ compiler (ie, configure CC to be 'g++' instead 'gcc').
-
-You have poll(), but do you want to use it
-USE_POLL
- Some Operating Systems implement select() by calling poll(), others
- implement poll() by calling select(). The best performance will be
- achieved by calling the lowest (sys)call ourselves of course.
- The Undernet Daemon allows you to use select() or poll().
- If you specify 'y' here, the daemon will use poll() directly, otherwise
- it will use select(). If you don't know what your Operating System
- uses as syscall, you can compile the server with USE_POLL and detach
- the running process with 'strace -p <pid>', 'truss -p <pid>' or
- 'trace -p <pid>' depending on your Operating System, these UNIX commands
- will show you the syscalls and therefore show if you use poll() or select().
- The advantage of using poll() is that you are not bothered by the limits
- of select() and fd_set size (ie, the number of clients that connect).
- The following Operating Systems seem to use poll():
- Solaris 2.x, SunOS 4.x, AIX, Digital UNIX, and NetBSD.
- linux-2.2.x use poll(), but only of your glibc was compiled with that
- kernel (and it won't unless you compile it yourself).
- The following Operating Systems use select():
- linux-2.0.x.
- If unsure, test it (a ./configure check will be added in ircu2.10.06).
-
-What is the domain name of your network
-DOMAINNAME
- This define 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
- specifically the client load from your own domain, 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 (ie, 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.
-
-What is the network name of your network
-NETWORK_NAME
- Especifica el nombre de la red, lo muestra en los raws 001 y 005.
-
-Please give a random seed of eight characters
-RANDOM_SEED
- You should specify exactly eight characters (0-9A-Za-z) here. Do not use
- quotes or any other special characters. This value is used to initialize
- the random generator of the server which is used to generate PING/PONG
- cookies in order to stop spoofing IP-numbers (a PING with a random number is
- sent to this IP-number and if the client doesn't respond with the
- exact same number, access is denied). In order to make the random
- number impossible to guess, it is important that you use your own random
- seed here.
-
-Does your host have a reliable clock
-RELIABLE_CLOCK
- You should really ONLY specify 'y' 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 Undernet. Otherwise leave
- your clock alone and specify 'n' here.
- If unsure specify 'n' !
-
-Change root (/) after start of daemon
-CHROOTDIR
- If you are a security freak and you want to the daemon to run in
- its own environment, then you can specify 'y' here. The daemon will
- change '/' to 'DPATH' (which you will have to specify later).
- If this confuses you or if you are uncertain, specify 'n'.
-
-Do you want the daemon set its own uid/gid
-CONFIG_SETUGID
- If you specify 'y' here, then the daemon will attempt to set its
- User ID (uid) and Group ID (gid) to the numeric values that you will
- have to specify next. This only makes sense if you (have to) start
- the server as root. The most secure operation of the server is to
- not use setuid stuff (here or by means of setting the file mode)
- and to run the server as a special user only (ie 'irc'). Of course
- this user must have access to all log and configuration files.
- Note that using a setuid and starting the daemon as another user
- does prohibit the daemon from core dumping in case of a crash on some
- Operating Systems.
- This option is actually only necessary when you use the Change Root
- option, because otherwise you can use the file mode to set the uid
- and gid. Note that the server refuses to run as root.
- If unsure, specify 'n'.
-
-UID of irc daemon
-IRC_UID
- Ok, if you insist on using this option: Here you must specify the
- numeric value of the uid that you want the server to run as.
- Note that you need to look in the right /etc/passwd file, which isn't
- the same file when you used the Change Root option.
-
-GID of irc daemon
-IRC_GID
- Ok, if you insist on using this option: Here you must specify the
- numeric value of the gid that you want the server to run as.
- Note that you need to look in the right /etc/group file, which isn't
- the same file when you used the Change Root option.
-
-Allow to specify configuration file on command line
-CMDLINE_CONFIG
- If you specify 'y' here, you will be allowed to specify the ircd.conf
- path (the ircd daemon configuration file) on the command line when
- starting the daemon (with the -f <ircd.conf file> option).
- Note that defining this and installing ircd SUID or SGID is a MAJOR
- security problem - they can use the '-f' option to read any files
- that the 'new' access lets them. Note also that defining this is
- a major security hole if other users have accounts on the same machine;
- when your ircd goes down and some other user starts up the server with
- a new conf file that has some extra O-lines. So don't use this unless
- you're debugging.
-
-Set up a Unix domain socket to connect clients/servers
-UNIXPORT
- If there are lots of users having an account on the same machine
- (which is very unlikely because the server needs all cpu ;), then
- using a UNIX domain socket to connect these clients to is more
- efficient then letting them connect via TCP/IP. A UNIX domain
- socket is a special device that will be created in your File System.
- Your client must also support connecting to a UNIX domain socket.
- The name of the special device must be specified in the "ircd.conf"
- file by means of an extra 'P: line', see doc/example.conf for the
- syntax.
- If you don't have many IRC-ing users on the same host as the server,
- or when your local IRC client doesn't support UNIX domain sockets,
- specify 'n' here. Otherwise specify 'y'.
-
-Do you need virtual hosting
-VIRTUAL_HOST
- This is only needed when you want to run two or more servers on the
- same machine and on the same port (but different devices).
- In general you will only need this if you have at least two ethernet
- cards in your machine with a different IP-number.
- If you specify 'y' here, then you can "bind" a server to one of your
- interfaces. You should use the command line option '-w' to tell the
- server to which interface to bind to. No error is reported if this
- fails, the server will simply not run.
- If no '-w' option is given then the server name specified in the
- 'M: line' of the "ircd.conf" file of the server is used, provided it
- resolves to an IP-number of one of your interfaces. Note that
- normally the name does not have to resolve, but when you define this,
- it MUST resolve or you must use the -w command line option, or the
- "bind" will fail.
- If you are unsure, specify 'n'.
-
-Will you connect to more then one server at a time
-HUB
- All servers of one 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 then
- one other server are called HUBs.
- If you specify 'n' here then your server will prevent itself from acciden-
- tally connecting to two servers at once, which is good because this is
- generally bad for servers in "leaf" positions (they are net.wise located
- too bad to route traffic). Note that on Undernet all newly linked servers
- are linked as leafs during their test phase, and should specify 'n' here.
-
-Do you want support for the old I:*:ONE:*:: construct
-USEONE
- Server versions prior to ircu2.10.05 used to use the string "ONE"
- as password in an I: line to indicate that only one connection was
- allowed for any given IP number that matched that I: line.
- This method only counted the *local* connections though.
- As of ircu2.10.05 you can specifiy a single(!) digit as password
- which then will allow that many connections from the same IP number.
- However, now the IP numbers of ALL clients are counted, also those
- that are connected to other servers.
- If you do not use the depricated "ONE" password in your ircd.conf,
- specify 'n' here. Note that if you you DO use the "ONE" password
- and you specify 'n' here, then you should change all occurances of
- "ONE" to "1" (this is the recommended procedure).
- If you are lazy and you don't want to change the "ONE" passwords
- into a "1", then specify 'y' here.
-
-Send a short message instead of the MOTD to connecting clients
-NODEFAULTMOTD
- Every time a client connects to your server, the full Message Of
- The Day (as specified in its file MPATH) is sent to the client.
- Even while many clients allow the user to ignore the message of
- the day: the server still sends it. Many users never read the
- message of the day anyway, making it a huge waste of bandwidth.
- If you specify 'y' here than the server won't send the MOTD by
- default to the client, but rather tell the client when the MOTD
- was last changed and how to receive the MOTD by typing /MOTD.
- If unsure specify 'n'.
-
-Do you want to enable debugging output
-DEBUGMODE
- Sometimes things just don't work. This doesn't have to be a crash,
- but it is also possible that your server just doesn't want to start
- at all, or disallows clients to connect at all, etc.
- With all such drastic and REPRODUCIBLE problems, it makes sense to
- recompile the server with this option set and then running the
- ircd (irc daemon) with the (extra) command line options: -t -x9
- This will make the server run in the foreground and write debug output
- to the terminal; in a lot of cases this can give a clue on what is
- wrong (although more often it doesn't).
- Because defining DEBUGMODE uses a LOT of cpu and is never useful
- unless you are debugging a reproducible test case, you should never
- specify 'y' here except for the reason just mentioned.
- You should certainly NEVER specify 'y' for a server that runs on a
- production net.
-
-Do you want memory- allocation and/or leak checking
-DEBUGMALLOC
- If you specify 'y' here, then the server will start to do book keeping
- on the allocated memory blocks. This uses extra cpu and memory,
- so normally you do not want this - unless you are debugging.
- This option uses 8 bytes extra per allocated memory block.
- The main purpose of this option is to check if a call to free(2) is done
- with a valid pointer - if the pointer was not previously returned by
- malloc(2), calloc(2) or realloc(2), the server will core dump in a place
- that allows the maintainer to get an idea of what went wrong - but only
- when the server was compiled with the -g flag of course.
- You also need to specify 'y' here if you want to search for memory leaks.
- On a production server, specify 'n' - unless you have lots of cpu to
- spare and you volunteer to search for memory leaks - contact the
- maintainer in this case.
- If unsure, specify 'n'.
-
-Do you want to have boundary checking
-MEMMAGICNUMS
- One of the most nasty bugs are those where buffer overruns are involved.
- In an attempt to catch those in an early stage, this option will add
- so called "magic numbers" to the beginning and end of each allocated
- memory block. When a block is freed or reallocated, the magic numbers
- are checked and the server core dumps when they were corrupted.
- This option uses 12 bytes extra per allocated memory block.
- It doesn't really use much extra cpu compared to defining DEBUGMALLOC, so
- you might as well specify 'y' here, just in case. It only makes sense
- though if you compiled the server with compiler option '-g'.
- If unsure, specify 'n'.
-
-Do you want memory leak testing (stats M)
-MEMLEAKSTATS
- If you specify 'y' here then the server will start to do extra book keeping
- on the allocated memory blocks, counting the number of currently allocated
- blocks per source code location (file and line number). You will be able
- to retrieve these statistics with the command /stats M.
- When there is a memory leak, then allocated memory blocks that were allocated
- under certain conditions are never freed (however the contents of those
- memory blocks are never used anymore); this would result in a (slow?)
- increase of the count of allocated memory blocks. This option allows to
- find where these blocks were allocated which might give a clue on the memory
- leak problem.
- This option uses 4 bytes extra per allocated memory block.
- If you want to look for memory leaks, specify 'y' - otherwise specify 'n'.
-
-Do you want extra info on allocated sizes
-MEMSIZESTATS
- If you specify 'y' here then the server will start to do extra book keeping
- on the sizes of the allocated memory blocks. /stats M will not only return
- the number of allocated blocks, but also the total number of allocated
- bytes involved. If you defined MEMLEAKSTATS to look for memory leaks, it
- will give the total number of allocated memory per source code location
- (file and line number).
- This option uses 4 bytes extra per allocated memory block, unless you already
- specified 'y' for MEMMAGICNUMS (boundary checking), because in that case
- it was already included (and it doesn't matter what you specify here).
- I think you should specify 'y' here, its more fun to see the sizes :).
-
-Do you want support for a time interval with /stats M
-MEMTIMESTATS
- If you specify 'y' here then the server will start to do extra book keeping
- on the allocated memory blocks, storing the time at which the memory block
- was allocated. This especially slows down /stats M (but unless you use
- that command frequently, it shouldn't really matter) and uses again 4 bytes
- of extra memory per allocated memory block.
- This option is especially useful if you are looking for memory leaks
- because it allows you to specify a time window with /stats M for which
- counted blocks must be returned. This allows to ignore recently allocated
- blocks and permanently allocated blocks (since the start of the server).
-
-Are you testing on a host without DNS
-NODNS
- 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 resolv
- the name given on the M:line (which usually isn't given in /etc/hosts) and
- for each connecting client.
- If you specify 'y' here, then a call to gethostbyname() will be done only
- for the real hostname, and the server will not try to resolv clients that
- connect to `localhost'.
- Note that other calls to gethostbyname() are still done anyway if you
- use VIRTUAL_HOST and that the server still tries to resolv clients
- that connect to the real IP-number of the server.
-
-Directory where all ircd stuff sits
-DPATH
- DPATH is provided so that the other path names may be provided in just
- filename form. It is the Default PATH. When the server starts, it
- chdir's to DPATH before chroot or any other file operation, making
- it the "current directory" for the server. This is where core files
- will go if the server core dumps.
- Note that you should not include quotes here.
- Note also that the command line option "-d <dir>" overrides the DPATH
- you give here, except for the chroot (if you use that).
-
-Server configuration file
-CPATH
- This is the IRC daemon Configuration filename, mostly called "ircd.conf".
- If you just specify the filename, the server will read its configuration
- file from the Default Path "DPATH", which you specified above. However,
- you are also allowed to specify a full path.
- Note that you should not include quotes here.
-
-Server MOTD file
-MPATH
- MPATH is the filename, relative to DPATH, or the full path, of the
- "Message Of The Day" file; mostly called "ircd.motd". The contents
- of this file will be sent to every client that connects to the server,
- after registration.
- Note that you should not include quotes here.
-
-Server remote MOTD file (3 lines max)
-RPATH
- RPATH is the filename, relative to DPATH, or the full path, of the
- "Remote Message Of The Day" file; mostly called "remote.motd". 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 it that short ;).
- Note that you should not include quotes here.
-
-File for server pid
-PPATH
- PPATH is the filename, relative to DPATH, or the full path, of the
- "PID file", mostly called "ircd.pid". It is used for storing the
- server's PID so a ps(1) isn't necessary.
- Note that you should not include quotes here.
-
-Do you want to log the use of /WHO x% (recommended)
-CONFIG_LOG_WHOX
- Specify 'y' here if you want to log the use of /WHO ... x%... by your
- Opers (see doc/readme.who). This is highly recommended since it will
- reduce the abuse of this `spy' function. Note: You can disable this
- spy function completely below, in which case you can give 'n' here.
- If unsure specify 'y'.
-
-Give the path and(or) filename of this log file
-WPATH
- WPATH is the filename, relative to DPATH, or the full path, of the
- log file where the use of /WHO ... x% ... by your Opers will be logged
- (see doc/readme.who), mostly called "whox.log".
- Note that you should not include quotes here.
-
-Do you want to log G-lines to a separate file
-CONFIG_LOG_GLINES
- Specify 'y' here if you want to log G-lines (Global access bans)
- to a local file.
-
-Give the path and(or) filename of this log file
-GPATH
- GPATH is the filename, relative to DPATH, or the full path, of the
- log file where the G-lines will be stored, mostly called "gline.log".
- Note that you should not include quotes here.
-
-Do you want to log connecting users to a separate file
-CONFIG_LOG_USERS
- Specify 'y' here if you want to log who is connecting to your server.
- This file can grow VERY fast on a large net work, so you probably
- want to specify 'n' here.
-
-Give the path and(or) filename of this log file
-FNAME_USERLOG
- Here you need to specify the name of the log file where the server
- should write the data about connecting users to. You can also specify
- a full path. Note that you should not include quotes here.
-
-Do you want to log Opers to a separate file
-CONFIG_LOG_OPERS
- Specify 'y' here if you want to log who is successfully becoming an
- IRC Operator on your server.
-
-Give the path and(or) filename of this log file
-FNAME_OPERLOG
- Here you need to specify the name of the log file where the server
- should write the data about Opering users. You can also specify a
- full path. Note that you should not include quotes here.
-
-Do you want to use syslog
-USE_SYSLOG
- If you are the sys admin of this machine, or if you have permission
- of the sys admin to do so, you can let the server write data about
- certain events to the syslog. You will be prompted for the events
- that you want to log being one or more of: KILL's, SQUIT's, CONNECT's,
- OPERing, Connecting Users and finally the log facility.
- If you are unsure, specify 'n'. It is probably not a good idea to use
- this on a large IRC net work.
-
-Log all operator kills to syslog
-SYSLOG_KILL
- Specify 'y' here if you want all KILLs to be written to syslog.
- Note that on a large IRC net work this is a LOT of data.
-
-Log all remote squits for all servers to syslog
-SYSLOG_SQUIT
- Specify 'y' here if you want all SQUITs to be written to syslog.
- Note that on a large IRC net work this is a LOT of data.
-
-Log remote connect messages for other all servers
-SYSLOG_CONNECT
- Specify 'y' here if you want all CONNECTs to be written to syslog.
- Note that on a large IRC net work this is a LOT of data.
-
-Log all users who successfully become an Oper
-SYSLOG_OPER
- Specify 'y' here if you want all OPERs to be written to syslog.
- Note that on a large IRC net work this is a LOT of data.
-
-Send userlog stuff to syslog
-SYSLOG_USERS
- Specify 'y' here if you want all connecting users to be written to syslog.
- Note that on a large IRC net work this is EXTREMELY MUCH data.
- You really want to specify 'n' here.
-
-Log facility (daemon, user, local0-7)
-CONFIG_DAEMON
- Well if you got this far and still need help, then I think you should
- go back and specify 'n' at the question "Do you want to use syslog".
-
-Which local facility (0-7)
-INT_LOCAL
- Well if you got this far and still need help, then I think you should
- go back and specify 'n' at the question "Do you want to use syslog".
-
-Use m4 as a preprocessor on CPATH
-M4_PREPROC
- If you use m4 macro's in your "ircd.conf" file, then you need to specify 'y',
- which will enable m4 preprocessing of the "ircd.conf" file.
- If you are unsure specify 'n'. Note using m4 macros has often lead to
- problems (passwords or server names that match a macro name for instance),
- while the benefits of using m4 are highly doubtful. Unless you are
- already a m4 wizard and insist on using it I recommend to specify 'n' here.
-
-Use crypted passwords for N: lines
-CRYPT_LINK_PASSWORD
- In order to allow other servers to connect to you, you need to specify
- two configuration lines in the "ircd.conf" configuration file (CPATH).
- Each of these lines contains a password; the C: line is used for connecting
- to a remote server and contains the password that is sent to the remote
- server for authentication, thus this password must be in plain text.
- The other is the N: line and contains the password that the remote server
- is sending to you. For security reasons it is advised to store this
- password in DES encrypted form. If you specify 'y' here, you will be
- allowed to use the DES encrypted password in the password field of the
- N: line, see doc/example.conf for more details. Note that you should
- use *different* passwords in the C: and N: lines respectively for obvious
- reasons.
-
-Use crypted passwords for operators
-CRYPT_OPER_PASSWORD
- In order to allow certain users to become IRC OPERators, they must
- authenticate themselves with a password. This password is matched
- against an 'O: line' in the "ircd.conf" configuration file, see
- doc/example.conf for more details. If you specify 'y' here, you are
- allowed to use the DES encrypted form of these passwords in your
- "ircd.conf" file (even more, your Opers don't have to tell you their
- real password, they can provide the DES encrypted form themselves).
- Since it has happened often in the past that the "ircd.conf" file
- was compromised somehow, you are highly encouraged to specify 'y' here
- and use the DES encrypted form. You can find a program 'mkpasswd' in
- the ircd/crypt directory that will allow you to generate the encrypted
- form.
-
-Max size of the total of of all sendqs (bytes)
-BUFFERPOOL
- This specifies the maximum amount of RAM that your server will allocate
- for buffering sendQ's. 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 up 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_ rather want to drop servers and clients
- then allocate more memory; this will be the case when there is the
- danger to run out memory for other allocations.
- Even if you run the daemon on a dedicated machine, then specifying the
- maximum of the RAM you have is a Bad Thing because really running out
- of memory is a lot worse then dropping clients in a controlled way:
- if possible you should have memory left for all the internal structures
- (channels, clients, banlists, 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 ammount that can be allocated for sendQs is the
- number of connected clients times whatever you specified as maximum
- sendQ in your Y: lines in the ircd.conf file. Likely, that value will
- be larger then the ammount 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 till 5 for HUB's. The 'size of net.burst' is about 125 bytes
- per online client (on the total network).
- For large HUBs with 4000 clients on undernet (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.
- Don't forget to specify this value in bytes.
-
-Max receive queue for clients (bytes)
-CLIENT_FLOOD
- 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.
-
-Maximum number of network connections (23 - (FD_SETSIZE-4))
-MAXCONNECTIONS
- This specifies the maximum number of network connections the server
- will use. You also need some non-network connects (log files etc), so
- the maximum value is "FD_SETSIZE-4". The minimum value is 23.
- The only benefit of using a small value is that your server uses less
- memory - but *only* when you really have a small (client) load.
- Routing server that hardly take clients can use 128 here for instance.
- Servers that are always full should just specify the maximum amount
- that still works (which might be less then FD_SETSIZE-4, some OS need
- kernel hacking to allow more then 1024 fds per process). The only max.
- value that is guaranteed to work is 252 ;). Note that if the value of
- FD_SETSIZE is for instance 1024, then that doesn't mean you can't
- connect MORE clients - but in this case you certainly need kernel
- hacking. Find an experienced admin with the same Operating System and
- ask him what the maximum is and how to achieve it.
-
-Default client listen port
-PORTNUM
- This is the default listen port. You can specify more listen ports
- in the "ircd.conf" file with 'P: lines'; see doc/example.conf for more
- details on P: lines. Note that /stats p currently only shows P: lines,
- which might be a reason for you to use a less often used value here.
- Note that there is actually no difference between client and server
- listen ports, but it is good practice to separate them for statistical
- purpose (bandwidth usage statistics).
-
-Nickname history length
-NICKNAMEHISTORYLENGTH
- This value specifies the length of the nick name history list, which
- is only used for /WHOWAS. It uses about 300 to 400 bytes per entry.
- Note that at a net.break so many client disappear that the whole
- "whowas" list refreshed a few times (unless you make it as big as
- 20,000 of course - but you shouldn't because thats a waste of ram
- and cpu). A reasonable value is 'total number of clients' / 25.
-
-Allow Opers to see (dis)connects of local clients
-ALLOW_SNO_CONNEXIT
- If you specify 'y' here, you will be allowed to see all client connects and
- disconnects as a server notice. The historical reason for adding this
- option was to detect clone bots that connected to your server. However,
- on a large IRC network like Undernet, the number of clients that connect
- are so huge that it is not possible to keep an eye on this and everyone
- has been filtering these notices out anyway. Next to that it turned out
- to use no less then 10% of the total cpu usage last time I measured it
- (this has been improved after that, but still).
- Unless you insist on seeing those notices you should specify 'n' here.
- Note that in the meantime Undernet has a LOT of other (semi- and fully-
- automated) ways to detect clone bots, which work a LOT better for this
- purpose.
-
-Show IP address in client connection notices
-SNO_CONNEXIT_IP
- Usually when showing a client connection, a nick, userid and hostname are
- displayed. Selecting 'y' here will also display the numeric IP and connection
- class of the connecting client. This can be useful for detecting spoofed DNS and
- virtual hosted clones. This does use extra CPU though and is generally not needed,
- however if a connection monitor bot is the only client that looks at these
- notices, it is more efficient than sending USERIP for every connection. This
- option makes the server compatible with Hybrid tcm bots.
-
-Do you want to use R: lines in your configuration file
-R_LINES
- If you specify 'y' here you will be allowed to use R:lines in the "ircd.conf".
- This allows more freedom in restricting connections to your server by
- calling an external program to determine whether to allow the connection.
- It also uses a lot of overhead however, and can bog things down, so you should
- consider whether you really need them, and if you can handle the extra load.
- If unsure, specify 'n'.
-
-Process R: lines every rehash
-R_LINES_REHASH
- You may not want to have the R: lines checks everywhere since this can
- cost a lot of time and delays. If you specify 'y' here, then R: lines are
- checked whenever the "ircd.conf" file is reloaded (when the REHASH command
- is used, or a signal SIGHUP is received by the daemon). This shouldn't be
- too much of a drain on the system if the R:lines programs are short.
-
-Process R: lines always
-R_LINES_OFTEN
- If you specify 'y' here then R: lines will be checked as often as K: lines.
- Note that this is -very- likely to cause a severe drain on your resources.
- Use at your own risk, specify 'n' unless your really sure.
-
-Allow (local) Opers to see all local invisible users
-SHOW_INVISIBLE_USERS
- If you specify 'y' here, then your (local) IRC Operators will be able to
- see all local invisible users (clients connected to your own server).
- The reason for this is to hunt for clone bots, make sure your Operators do
- not use this "feature" for spying on individuals and respect the user that
- wishes to be invisible (mostly meaning that they don't want to be found when
- on certain channels).
- Note: If you answer 'n' here, then you will also not be able to see remote
- invisible users (if you specify 'y' you will also get a configuration
- question that asks you to specify whether or not you want your Opers to see
- remote invisible users or not).
-
-Allow Opers to see all invisible users
-SHOW_ALL_INVISIBLE_USERS
- If you specify 'y' here, then your global IRC Operators (O:) will be able
- to see ALL invisible users. The reason for this is to hunt for clone bots,
- make sure your Operators do not use this "feature" for spying on individuals
- and respect the user that wishes to be invisible (mostly meaning that they
- don't want to be found when on certain channels).
-
-Allow HELPERS to see all invisible users'
-WHOX_HELPERS
- If you specify 'y', any HELPER will be able to see ALL invisible users.
- The reason for this is to hunt for clone bots,
- make sure your Operators do not use this "feature" for spying on individuals
- and respect the user that wishes to be invisible (mostly meaning that they
- don't want to be found when on certain channels).
-
-Allow global Opers (O:) to see inside secret channels
-OPERS_SEE_IN_SECRET_CHANNELS
- If you specify 'y' here, then your global IRC Operators (O:) will be able
- to see who is on a specified, secret channel, without joining themselfs.
- This can be needed to make a reasonable judgement in the case of a "channel
- takeover" being reported, while the channel is set invite only.
- See doc/readme.who for more details.
-
-Allow local Opers (o:) to see inside secret channels
-LOCOP_SEE_IN_SECRET_CHANNELS
- If you specify 'y' here, then your local IRC Operators (o:) will be able
- to see who is on a specified, secret channel, without joining themselfs.
- This can be needed to make a reasonable judgement in the case of a "channel
- takeover" being reported, while the channel is set invite only.
- See doc/readme.who for more details.
- If unsure, specify 'n'.
-
-Don't truncate obnoxiously long /who output for opers
-UNLIMIT_OPER_QUERY
- A /who command can sometimes return several hundred lines of info. To
- reduce flooding and sending too much, the output is truncated. By
- answering 'y' to this, when an IRC Operator uses /who, the output will
- not be truncated, no matter how much data is returned.
-
-Allow Opers to use the KILL command
-OPER_KILL
- You can select 'n' if you don't think operators should be able
- to use the KILL command, and wish to prevent your operators from
- using it. This will not, however, prevent operators on other
- servers from issuing KILLs to your clients. You probably want to
- select 'y' for this unless you really really don't think KILL
- should -ever- be used by an operator.
-
-Allow Opers to use the REHASH command
-OPER_REHASH
- Allows operators to use the REHASH command to reload the servers
- configuration file (ircd.conf) if you select 'n', you can still
- reload the configuration file with a unix command,
- kill -HUP `cat ircd.pid`. If unsure, select 'y'.
-
-Allow Opers to use the RESTART command
-OPER_RESTART
- Allows an operator to use the RESTART command to cause the server
- to restart, using the ircd executable in SPATH. If unsure, select 'y'.
-
-Allow Opers to use the DIE command
-OPER_DIE
- Allows an operator to use the DIE command to shutdown the server
- online. If you select 'n' you will need to send the server a kill
- signal to shutdown the server. If unsure, select 'y'.
-
-Allow Opers to add local G-lines
-OPER_LGLINE
- Allows operators to add local G-lines with the GLINE command. This is
- like a *local* KILL, except that the user being killed can't immediately
- reconnect: He will have to wait for the G-line to expire.
- The reason for adding this is that a KILL is rather useless for removing
- (or 'warning') abusers (it is still THE command to remove ghosts and
- a-like, the reason KILL was added in the first place). However, adding
- G-lines for a dynamic IP with expire times larger then 10 minutes is highly
- discouraged: The user will already have dialed in via another IP or account
- and the G-line would only harm other, innocent, users.
-
-Allow Opers to connect from a remote site
-OPER_REMOTE
- If you select 'n' for this, clients must be on the 'same network' as
- the server in order to gain oper privledges. If you're not sure, just
- select 'y'.
-
-Allow Opers to join channels using a master key - ESNET
-OPER_JOIN_GOD_ESNET
- If you choose "yes", an OPER can join any channel writing
- a master key "GOD". She can join through keys, invite, bans, and so on.
- Useful to run local Channel Services.
-
-Allow Opers to join channels using a master key - ESNET
-OPER_CHANNEL_SERVICE_ESNET
- If you choose "yes", an OPER can set mode "+k" on himself. That is,
- nobody will can kick or deop him. Useful to run local Channel Services.
-
-Local Channel Services has no Flood Control - ESNET
-CS_NO_FLOOD_ESNET
- If you choose "yes", a local channel service (user with mode +k) won't
- have flood control. Useful if you are running local bots as ChServ.
-
-Allow Opers to bypass UWorld mode changes - ESNET
-OPER_XMODE_ESNET
- If you choose "yes", an oper can make channel mode changes
- without being OP in that channel. He only need to include
- the "extended mode" (flag "x") in his mode command.
-
-ESNET Distributed DataBase Support
-BDD
- If you choose "yes", your server will can manage
- Distributed DataBases. A "database" directory will be
- created into IRCd home directory to support nick
- and channel registration, etc.
-
-Directory where distributed database resides - ESNET
-DBPATH
- Path to the Distributed Database directory. This path can be
- absolute, or relative to the configuration directory (DPATH).
-
-Distributed Clone Control support - ESNET
-BDD_CLONES
- Control clones locally using ESNET Distributed DataBases.
-
-Dinamic Negotiation link-by-link - ESNET
-ESNET_NEG
- The server<->server links negotiates nonstandard
- features, like compression or encryption.
-
-ZLIB compression between servers - ESNET
-ZLIB_ESNET
- Compress the server<->server links.
-
-Allow local opers to use the REHASH command
-LOCOP_REHASH
- Allows a local operator (defined by a lowercase o:line in ircd.conf)
- to cause the server to reload its configuration file (ircd.conf) with
- the REHASH command. If unsure, select 'n'.
-
-Allow local opers to use the RESTART command
-LOCOP_RESTART
- Allows a local operator (defined by a lowercase o:line in ircd.conf)
- to use the RESTART command. If unsure, select 'n'.
-
-Allow local opers to use the DIE command
-LOCOP_DIE
- Allows a local operator (defined by a lowercase o:line in ircd.conf)
- to use the DIE command. If unsure, select 'n'.
-
-Allow local opers to add local G-lines
-LOCOP_LGLINE
- Allows a local operator (defined by a lowercase o:line in ircd.conf)
- to add local G-lines with the GLINE command. This is like a *local* KILL,
- except that the user being killed can't immediately reconnect: He will
- have to wait for the G-line to expire.
-
-Do you want to have a default LIST parameter
-CONFIG_LIST
- Pre-Undernet, the LIST command could either be given with one channel
- name, or without any parameter. In the last case it would simply list
- all channels. In time the IRC networks grew big, until the output of
- the LIST command always filled up the sendQ of the client (and dis-
- connected it). This was fixed by Carlo Wood (Run@IRC) on request of a
- Dutch ISP whose users complained about this: The LIST output is now
- generated in small chunks, generating more each time when there is room
- in the clients sendQ. However, then it turned out that LIST (now it
- worked) used 50% of all cpu (not even mentioning the bandwidth)...
- This was unacceptable and the mentioned patch was disabled. On the
- other hand we wanted LIST to work at least partly, so a few new
- parameters have been added to LIST: <,>,C<,C>,T<,T> each followed by
- a number they filter respectively the number of users on the channel,
- the creation time of the channel (or age, depended on the value of
- the number) and the topic set time.
- If you specify 'y' here, then each time a "/LIST" (without parameter)
- is issued by a client, a default parameter is used. Note that when
- a parameter is used, the client can still max. sendq out - the send
- flood control only works without any parameter.
- If you specify 'n' here then a "/LIST" without parameters will list
- all channels (and work), but as just said: it uses a LOT of cpu and
- bandwidth on a large net.work.
- If you specify 'y' you will be prompted for the default parameter.
-
-Give default LIST parameter
-DEFAULT_LIST
- Here you need to specify the default LIST parameter which is used
- when the server receives a LIST without any parameter.
- You should use something that limits the output to a maximum of a
- few hundred channels; for instance "T<10" (topic is set less then
- 10 seconds ago) or ">10" (more then 10 users on the channel) or even
- a combination of this. Note that you should not include quotes here.
-
-K: line comments treated as a file
-COMMENT_IS_FILE
- If you specify 'y' here, then K: line comments (see doc/example.conf
- for more details on the K: line syntax) will be treated as a filename
- by default. The file needs to exist and will be written to clients
- that match that K: line.
- If you specify 'n' here, then K: line comments will be treated as
- a comments by default.
- In both cases you can override the default by prepending a filename
- with a '!' or enclose a comment between double quotes.
- If unsure, use the default.
-
-Only nullify idle-time on PRIVMSG
-IDLE_FROM_MSG
- The IRC command WHOIS gives an idle time for clients. If you want that
- this idle time is set to zero only when the clients send a PRIVMSG,
- then you should specify a 'y' here.
- If you specify a 'n' then the idle time will be nullified on all messages
- except the server PING/PONG.
-
-XMODE Networking - ESNET
-XMODE_ESNET
- This mode allows the use of "extended modes" in the network.
- Extended modes can change channel modes without UWorld intervention.
-
-Check clone limit (2!)
-CHECK_CLONE_LIMIT
- Set this to 2.
-
-Check clone period (20!)
-CHECK_CLONE_PERIOD
- Set this to 20.
-
-Check clone delay (600!)
-CHECK_CLONE_DELAY
- Set this to 600.
-
-Max auto connects per class (1!)
-MAXIMUM_LINKS
- Set this to 1.
-
-Enable message logging
-MSGLOG_ENABLED
- Define this if you want the server to log received messages in static memory
- at parsing time. -This is for debugging purposes only-. You might want to
- redefine LOG_MASK_TYPE in s_debug.h and LOG_MASK_LEVEL in s_debug.c too.
- The default is to log all messages that change some status in server's data
- structures. Select 'n' unless you are debugging the server code.
- DO NOT SELECT THIS ON PRODUCTION SERVERS!
-
-Message log size
-MSGLOG_SIZE
- Number of messages to log. Keep this low as raising it to 1024 will use 800k
- of _static_ memory! Recommended value is 128. You must include this even if
- you selected 'n' for MSGLOG_ENABLED.
-
-Only allow KILLs of local clients
-LOCAL_KILL_ONLY
- This only allows operators of this server to KILL clients directly connected
- to this server. Operators will not be able to issue KILLs for clients on
- other servers. Some networks (not Undernet) require that this be defined
- for newly linking servers, but if you haven't been told to do otherwise,
- specify 'n' here.
-
-Max server idle time (60)
-TIMESEC
- This is the maximum idle time for the server. If no messages are received
- in TIMSEC seconds, PINGFREQUENCY and CONNECTFREQUENCY are checked.
- Recommended value is 60 seconds.
-
-KILL nick chase time limit (30)
-KILLCHASETIMELIMIT
- This is the maximum amount of time a KILL command will automatically change
- to the current nick of a user that has just changed nicks from the one given
- with the original KILL. Don't change th...
[truncated message content] |
