# 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' (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).
  If you are unsure, or if you want to change a previously entered
  configuration, specify 'y'.

Which compiler do 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 compile 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 -O will optimize the code - it also makes debugging harder.
  If you are not running a production server you should remove the -O.
  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 calling
  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).

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.
  The following Operating Systems use select():
  linux-2.0.x.
  If unsure specify 'n'.

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

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
  it 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" 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
  is 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 to accidentally
  connect 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 server are
  linked as leafs during their test phase, and should specify 'n' here.

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

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 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.  Note that this file
  must exist, it won't be created.  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.  Note that this file
  must exist, it won't be created.  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 amount of internal send buffering (bytes)
MAXSENDQLENGTH
  This is the default value of the "max. sendq length" of Y: line classes
  (see doc/example.conf for details on Y: lines).  You will probably
  always override this value in your "ircd.conf" with the Y: lines.
  However, it is this value that is used to determine the total amount
  of RAM that the server will allocate for buffering send queues.
  Therefore it is best if you specify here a value that is about the
  the maximum size of a sendQ that you expect, which will be depended
  on the size of the IRC net work (total number of clients).
  A good guess is:
  For HUBs : 150 bytes per client (20,000 clients -> 3,000,000 bytes)
  For Leafs: 150 bytes per local client (2,000 clients -> 600,000 bytes)

Max size of the total of all sendqs (multiply factor for MAXSENDQLENGTH)
INT_BUFFERPOOL
  This specifies the maximum amount of RAM that your server will allocate
  in RAM for buffering sendQ's.  Leafs can use a value as little as 3, while
  large HUBs need to specify a value as high as 6.  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/or install more RAM if appropriate).

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.

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

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 your not sure, just
  select 'y'.

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
  which needs to exist and will be written to clients that match that
  K: line.

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.

Check for clones (mandatory on Undernet)
CHECK_CLONE

Check clone limit (2!)
CHECK_CLONE_LIMIT

Check clone period (20!)
CHECK_CLONE_PERIOD

Check clone delay (600!)
CHECK_CLONE_DELAY

Max auto connects per class (1!)
MAXIMUM_LINKS

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.

Class 0 ping frequency (120)
PINGFREQUENCY
  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 is overridden by
  a Y:line in "ircd.conf" if the connections I/C/N: line in "ircd.conf" assigns
  a specific class to the connection (recommended).

Class 0 connect frequency (600)
CONNECTFREQUENCY
  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 Y:line in ircd.conf if the C/N:lines in ircd.conf
  assigns a specific class to the connection (recommended).

Min time before a link is good (300)
HANGONGOODLINK
  Often the net breaks for a short time and its useful 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.

Wait before reconnecting to good link (10!)
HANGONRETRYDELAY
  When attempting to quickly reestablish a connection to a good link, we
  give the net a few seconds to steady. This time must be long enough for
  the other end to notice it broke too. The recommended value is 10 seconds.

connect(2) timeout (90!)
CONNECTTIMEOUT
  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 you don't 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.

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 this unless you really need to.

Max number of channels per user (recommended: 5)
MAXCHANNELSPERUSER
  This is the maximum number of channels a user can be in at a time.
  The "mandatory" value on Undernet 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 now-a-days '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.

Max number of silence masks (15!)
MAXSILES
  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 your not sure, don't change this.

Expected average banmask length (40!)
AVBANLEN
  This is the expected average banmask length.  Leave it at 40.

Use .config of THIS source tree as your upgrade default
CONFIG_NEW
  Each source tree keeps its *own* config/.config file with the default
  values for all questions (those that you gave the last time you did a
  'make config').  Whenever you do 'make config' again in this source tree,
  you will get these defaults.
  However, when you *upgrade* to a new version (and get a NEW source tree),
  it doesn't have a .config yet and will (try to) use a .config of one of
  your previous source trees.
  If you specify 'y' here, then the last defaults of THIS source tree will
  be used in your next upgrade.  Note that any changes you make later to
  config/.config (by running 'make config' again) will also take effect
  on this later upgrade.
  You can always change this by making a new hard link from .config ->
  ircu2.10.xx/config/.config in the directory where you keep the source
  trees.
  If unsure, and you are not currently installing a test source tree,
  specify 'y'.  If this is a second source tree that you will only be
  experimenting with, specify 'n'.