1 # Format of this file: description<nl>variable<nl>helptext<nl><nl>.
2 # If the question being documented is of type "choice", we list
3 # only the first occurring config variable. The help texts
4 # must not contain empty lines. No variable should occur twice; if it
5 # does, only the first occurrence will be used by Configure. The lines
6 # in a help text should be indented two positions. Lines starting with
7 # `#' are ignored. Limit your lines to 78 characters.
9 # If you add a help text to this file, please try to be as gentle as
10 # possible. Don't use unexplained acronyms and generally write for the
11 # hypothetical admin who has just downloaded ircu for the first time.
12 # Tell them what to do if they're unsure. Technical information
13 # should go in a README in the Documentation directory. Mention all
14 # the relevant READMEs and HOWTOs in the help text.
16 # All this was shamelessly stolen from several different sources. Many
17 # thanks to all the contributors. The texts are copyrighted # (c) 1997
18 # by Carlo Wood and governed by the GNU Public License.
21 Do you want to change your previous configuration
23 You will be presented a series of questions that you have to answer
24 in order to configure the IRC daemon, prior to compilation.
25 If you went through this before, then your choices have been stored
26 in a file '.config'. If you want to use the same stored configuration
27 now, specify 'n'; this will quickly skip through all questions that
28 you already answered previously, only prompting you for NEW questions.
29 Note that NEW questions only can occur when you just upgraded to a
30 new version. Note also that if you abort by pressing ^C (control-C)
31 anywhere, then all answers are lost; you must finish it before the
33 Pressing a 'c' or 'C' (followed by a return) on any question will
34 Continue the script in "use_defaults mode", that means that it will
35 take all default values unless it finds a NEW question (like when you
36 specify a 'n' here). 'C' will finish everything, but a 'c' will
37 only finish the current paragraph.
38 If you are unsure, or if you want to change a previously entered
39 configuration, specify 'y'.
41 Which compiler do you want to use
43 Here you need to specify the C compiler you want to use.
44 Using 'gcc' is highly recommended, you might even want to install it
45 on your machine first. Note that you can specify the full path if you
46 are not sure if the compiler is in your PATH (or whether or not the right
47 compiler will be used). An example is: "/usr/ucb/cc".
48 The package needs an ANSI compiler. Some compilers need an extra option
49 to compile ANSI C. In those cases you can add these options also here.
50 For example, on a HPUX-8.x you would use (if you don't have gcc):
51 "cc -Aa -D_HPUX_SOURCE".
52 Note that you should not use quotes.
54 What flags should I pass to $CC
56 These are the compiler flags, used for CC when compiling.
57 If you are not using gcc, it might be possible that your compiler is not
58 supporting -g and -O at the same time. The -g option is necessary to be
59 able to debug the daemon in the case it contains a bug that makes the
60 ircd core dump. Unless you use a version that is proven to be VERY stable,
61 it is highly recommended to use this option. All Undernet production servers
62 are expected to use it in order to help coder-com to track down bugs.
63 The -O3 will optimize the code - it also makes debugging harder.
64 If you have plenty of cpu cycles then you can use -O2 instead of -O3:
65 it will disable inlining which makes it easier to debug or core dump,
66 the daemon will use a few percent more cpu however.
67 If you are not running a production server you should remove the -Ox.
68 Ircd developers can optionally use more options to turn on extra warnings.
69 Developers (which are using gcc of course ;), should use:
70 "-g -Wall -pedantic -DGODMODE"
71 Note that you should not use quotes.
72 Note that the server uses several non-ANSI (though POSIX.1) function calls.
74 Do you need extra include directories
76 If your compiler needs extra include directories, you can specify them
77 here as a space separated list of directories. Do not use quotes and do
78 not specify the '-I' prefix. Usually you don't have to specify any
79 extra include directory, in that case you should specify "none" here.
80 If unsure, try "none" (without quotes) and see if all the '#include'
81 header files are found during compilation.
83 Which linker flags do you need
85 Here you can specify extra flags that will be passed to the linker.
86 Usually you will not need to pass any flags and you can therefore
87 specify "none" here (without the quotes).
88 SunOS users may want to add "-Bstatic" (but only if you need it).
89 You can also specify any "-L..." flags here if you need those for
92 Which extra libraries do you need
94 Some Operating Systems need linking with extra libraries for some of the
95 functions used by the daemon. In some cases, it is not known which
96 libraries are needed, even when the Operating System is known. This is
97 for instance the case with SunOS, some need -lresolv, while others don't.
98 If you forget to add a library then this will result in 'undefined variables'
99 during linking. If you do not know which library to add, it might be
100 helpful to use the unix command `nm', which lists the variables of a
101 library. For instance, if you get "unknown variable '_res_mkquery'", and you
102 wonder if this is in /usr/lib/libresolv.so, you can do:
103 nm /usr/lib/libresolv.so | grep res_mkquery
104 Do not use the leading '_' in the grep, this underscore is added by the
105 assembler but is not part of the original variable name and does not show
106 up in the output of nm.
107 Most libraries are in /lib or /usr/lib, which are scanned by default. In
108 some cases you will need to tell the linker where to search for a library.
109 You can do this by adding an -L... option to IRCDLIBS. For instance:
110 "-L/usr/ucblib -lucb" will look for 'libucb.so' in /usr/ucblib too.
111 Here is a list of what you MAYBE need to specify depending on your
115 Dynix/ptx -lsocket -linet -lnsl -lseq
116 Dell SVR4 -lsocket -lnsl -lucb
117 All others Default provided by autoconf
118 If unsure use the default provided by autoconf.
120 Where should I install the ircd binary
122 After compilation (by typing 'make'), you can install the server with
123 the command 'make install'. This will install the ircd in the directory
124 you specify here. The package tries to use a meaningful name by naming
125 the binary "ircd.<tag>", where <tag> is the name of the last patch that
126 was applied by the maintainer. A symbolic link (to be specified next)
127 will be used to point to this binary. This allows a /RESTART to
128 immediately start the new version, while keeping the old binary.
129 Note that you need to have write permissions in this directory during
130 the install. Please re-check the permissions/owner and group after
133 What should the name of the installed symbolic link to the executable be
135 'make install' installs the binary with an unique name, however it makes
136 a symbolic link to this newly installed executable which always has the
137 same name, so you can use /RESTART and/or use this name in scripts that
138 automatically restart the ircd after a reboot or crash.
139 Here you can specify the name of that symbolic link. Note that it may
140 not contain a '/'; it is just the name if the symbolic link and will be
143 Which permissions do you want the binary to have
145 Here you need to specify the octal file mode of the ircd binary.
146 Recommended is 711 - but you might need setuid or something.
147 Note that using a setuid and starting the daemon as another user
148 does prohibit the daemon from core dumping in case of a crash on some
151 Which owner do you want the binary to have
153 This will be the owner of the ircd binary after installation.
155 Which group do you want the binary to have
157 This will be the group of the ircd binary after installation.
159 Where should I install the man page
161 This is the base directory where the manual page of the ircd is installed.
162 If you are not root on your system, you can change it to your personal
163 manpath directory (which of course should be in your MANPATH environment
166 Use inlining for a few crucial functions
168 This will increases the size of the executable with 7 kb, but it also
169 speeds up execution a bit :). Your compiler needs to understand the
170 keyword __inline__ (GNU gcc and egcs do).
171 If unsure, try if `y' compiles. If it doesn't, you can try using a
172 C++ compiler (ie, configure CC to be 'g++' instead 'gcc').
174 You have poll(), but do you want to use it
176 Some Operating Systems implement select() by calling poll(), others
177 implement poll() by calling select(). The best performance will be
178 achieved by calling the lowest (sys)call ourselves of course.
179 The Undernet Daemon allows you to use select() or poll().
180 If you specify 'y' here, the daemon will use poll() directly, otherwise
181 it will use select(). If you don't know what your Operating System
182 uses as syscall, you can compile the server with USE_POLL and detach
183 the running process with 'strace -p <pid>', 'truss -p <pid>' or
184 'trace -p <pid>' depending on your Operating System, these UNIX commands
185 will show you the syscalls and therefore show if you use poll() or select().
186 The advantage of using poll() is that you are not bothered by the limits
187 of select() and fd_set size (ie, the number of clients that connect).
188 The following Operating Systems seem to use poll():
189 Solaris 2.x, SunOS 4.x, AIX, Digital UNIX, and NetBSD.
190 linux-2.2.x use poll(), but only of your glibc was compiled with that
191 kernel (and it won't unless you compile it yourself).
192 The following Operating Systems use select():
194 If unsure, test it (a ./configure check will be added in ircu2.10.06).
196 What is the domain name of your network
198 This define allows you to specify what you consider to be 'local'.
199 It is only used for statistics. When you issue the IRC command /stats w,
200 the server will respond with statistics of how many clients have been
201 connecting to your server in the last minute, hour and day. It will
202 give these statistics for all connections (including the servers), all
203 clients (from anywhere) and also for clients whose hostname ends on
204 the domain you specify here. So if you are an ISP and you want to know
205 specifically the client load from your own domain, specify that domain
206 here. If you are unsure what to do, then it isn't really important what
207 you give here, just don't give an empty string. A good guess is the last
208 two parts of your own hostname (ie, if your hostname is foo.bar.nowhere.org,
209 specify 'nowhere.org'). Note that the string you give should NOT start
210 with a '.' and you should not use quotes.
212 Please give a random seed of eight characters
214 You should specify exactly eight characters (0-9A-Za-z) here. Do not use
215 quotes or any other special characters. This value is used to initialize
216 the random generator of the server which is used to generate PING/PONG
217 cookies in order to stop spoofing IP-numbers (a PING with a random number is
218 sent to this IP-number and if the client doesn't respond with the
219 exact same number, access is denied). In order to make the random
220 number impossible to guess, it is important that you use your own random
223 Does your host have a reliable clock
225 You should really ONLY specify 'y' here when your system clock is
226 stable and accurate at all times (within a few seconds).
227 If you are running ntpdate on a regular basis, or an equivalent
228 like xntpd, to keep your system clock synchronized over the network,
229 then you might have an accurate clock. However, this is not guaranteed,
230 for example, it is known that xntpd gives unstable results on linux
231 in some cases. Note that an unstable clock is worse then an clock that
232 has a constant offset, because the servers attempt to correct for a
233 constant offset, but do not correct jumps of your system clock !
234 In general you SHOULD be running ntpdate or equivalent AND make sure it
235 works when you run a production server on Undernet. Otherwise leave
236 your clock alone and specify 'n' here.
237 If unsure specify 'n' !
239 Change root (/) after start of daemon
241 If you are a security freak and you want to the daemon to run in
242 its own environment, then you can specify 'y' here. The daemon will
243 change '/' to 'DPATH' (which you will have to specify later).
244 If this confuses you or if you are uncertain, specify 'n'.
246 Do you want the daemon set its own uid/gid
248 If you specify 'y' here, then the daemon will attempt to set its
249 User ID (uid) and Group ID (gid) to the numeric values that you will
250 have to specify next. This only makes sense if you (have to) start
251 the server as root. The most secure operation of the server is to
252 not use setuid stuff (here or by means of setting the file mode)
253 and to run the server as a special user only (ie 'irc'). Of course
254 this user must have access to all log and configuration files.
255 Note that using a setuid and starting the daemon as another user
256 does prohibit the daemon from core dumping in case of a crash on some
258 This option is actually only necessary when you use the Change Root
259 option, because otherwise you can use the file mode to set the uid
260 and gid. Note that the server refuses to run as root.
261 If unsure, specify 'n'.
265 Ok, if you insist on using this option: Here you must specify the
266 numeric value of the uid that you want the server to run as.
267 Note that you need to look in the right /etc/passwd file, which isn't
268 the same file when you used the Change Root option.
272 Ok, if you insist on using this option: Here you must specify the
273 numeric value of the gid that you want the server to run as.
274 Note that you need to look in the right /etc/group file, which isn't
275 the same file when you used the Change Root option.
277 Allow to specify configuration file on command line
279 If you specify 'y' here, you will be allowed to specify the ircd.conf
280 path (the ircd daemon configuration file) on the command line when
281 starting the daemon (with the -f <ircd.conf file> option).
282 Note that defining this and installing ircd SUID or SGID is a MAJOR
283 security problem - they can use the '-f' option to read any files
284 that the 'new' access lets them. Note also that defining this is
285 a major security hole if other users have accounts on the same machine;
286 when your ircd goes down and some other user starts up the server with
287 a new conf file that has some extra O-lines. So don't use this unless
290 Set up a Unix domain socket to connect clients/servers
292 If there are lots of users having an account on the same machine
293 (which is very unlikely because the server needs all cpu ;), then
294 using a UNIX domain socket to connect these clients to is more
295 efficient then letting them connect via TCP/IP. A UNIX domain
296 socket is a special device that will be created in your File System.
297 Your client must also support connecting to a UNIX domain socket.
298 The name of the special device must be specified in the "ircd.conf"
299 file by means of an extra 'P: line', see doc/example.conf for the
301 If you don't have many IRC-ing users on the same host as the server,
302 or when your local IRC client doesn't support UNIX domain sockets,
303 specify 'n' here. Otherwise specify 'y'.
305 Do you need virtual hosting
307 This is only needed when you want to run two or more servers on the
308 same machine and on the same port (but different devices).
309 In general you will only need this if you have at least two ethernet
310 cards in your machine with a different IP-number.
311 If you specify 'y' here, then you can "bind" a server to one of your
312 interfaces. You should use the command line option '-w' to tell the
313 server to which interface to bind to. No error is reported if this
314 fails, the server will simply not run.
315 If no '-w' option is given then the server name specified in the
316 'M: line' of the "ircd.conf" file of the server is used, provided it
317 resolves to an IP-number of one of your interfaces. Note that
318 normally the name does not have to resolve, but when you define this,
319 it MUST resolve or you must use the -w command line option, or the
321 If you are unsure, specify 'n'.
323 Will you connect to more then one server at a time
325 All servers of one IRC "network" are connected in a "tree" (no loops).
326 Servers that are only connected to one other server (called the
327 'uplink') are called "leafs", servers that are connected to more then
328 one other server are called HUBs.
329 If you specify 'n' here then your server will prevent itself from acciden-
330 tally connecting to two servers at once, which is good because this is
331 generally bad for servers in "leaf" positions (they are net.wise located
332 too bad to route traffic). Note that on Undernet all newly linked servers
333 are linked as leafs during their test phase, and should specify 'n' here.
335 Do you want support for the old I:*:ONE:*:: construct
337 Server versions prior to ircu2.10.05 used to use the string "ONE"
338 as password in an I: line to indicate that only one connection was
339 allowed for any given IP number that matched that I: line.
340 This method only counted the *local* connections though.
341 As of ircu2.10.05 you can specifiy a single(!) digit as password
342 which then will allow that many connections from the same IP number.
343 However, now the IP numbers of ALL clients are counted, also those
344 that are connected to other servers.
345 If you do not use the depricated "ONE" password in your ircd.conf,
346 specify 'n' here. Note that if you you DO use the "ONE" password
347 and you specify 'n' here, then you should change all occurances of
348 "ONE" to "1" (this is the recommended procedure).
349 If you are lazy and you don't want to change the "ONE" passwords
350 into a "1", then specify 'y' here.
352 Send a short message instead of the MOTD to connecting clients
354 Every time a client connects to your server, the full Message Of
355 The Day (as specified in its file MPATH) is sent to the client.
356 Even while many clients allow the user to ignore the message of
357 the day: the server still sends it. Many users never read the
358 message of the day anyway, making it a huge waste of bandwidth.
359 If you specify 'y' here than the server won't send the MOTD by
360 default to the client, but rather tell the client when the MOTD
361 was last changed and how to receive the MOTD by typing /MOTD.
362 If unsure specify 'n'.
364 Do you want to enable debugging output
366 Sometimes things just don't work. This doesn't have to be a crash,
367 but it is also possible that your server just doesn't want to start
368 at all, or disallows clients to connect at all, etc.
369 With all such drastic and REPRODUCIBLE problems, it makes sense to
370 recompile the server with this option set and then running the
371 ircd (irc daemon) with the (extra) command line options: -t -x9
372 This will make the server run in the foreground and write debug output
373 to the terminal; in a lot of cases this can give a clue on what is
374 wrong (although more often it doesn't).
375 Because defining DEBUGMODE uses a LOT of cpu and is never useful
376 unless you are debugging a reproducible test case, you should never
377 specify 'y' here except for the reason just mentioned.
378 You should certainly NEVER specify 'y' for a server that runs on a
381 Do you want memory- allocation and/or leak checking
383 If you specify 'y' here, then the server will start to do book keeping
384 on the allocated memory blocks. This uses extra cpu and memory,
385 so normally you do not want this - unless you are debugging.
386 This option uses 8 bytes extra per allocated memory block.
387 The main purpose of this option is to check if a call to free(2) is done
388 with a valid pointer - if the pointer was not previously returned by
389 malloc(2), calloc(2) or realloc(2), the server will core dump in a place
390 that allows the maintainer to get an idea of what went wrong - but only
391 when the server was compiled with the -g flag of course.
392 You also need to specify 'y' here if you want to search for memory leaks.
393 On a production server, specify 'n' - unless you have lots of cpu to
394 spare and you volunteer to search for memory leaks - contact the
395 maintainer in this case.
396 If unsure, specify 'n'.
398 Do you want to have boundary checking
400 One of the most nasty bugs are those where buffer overruns are involved.
401 In an attempt to catch those in an early stage, this option will add
402 so called "magic numbers" to the beginning and end of each allocated
403 memory block. When a block is freed or reallocated, the magic numbers
404 are checked and the server core dumps when they were corrupted.
405 This option uses 12 bytes extra per allocated memory block.
406 It doesn't really use much extra cpu compared to defining DEBUGMALLOC, so
407 you might as well specify 'y' here, just in case. It only makes sense
408 though if you compiled the server with compiler option '-g'.
409 If unsure, specify 'n'.
411 Do you want memory leak testing (stats M)
413 If you specify 'y' here then the server will start to do extra book keeping
414 on the allocated memory blocks, counting the number of currently allocated
415 blocks per source code location (file and line number). You will be able
416 to retrieve these statistics with the command /stats M.
417 When there is a memory leak, then allocated memory blocks that were allocated
418 under certain conditions are never freed (however the contents of those
419 memory blocks are never used anymore); this would result in a (slow?)
420 increase of the count of allocated memory blocks. This option allows to
421 find where these blocks were allocated which might give a clue on the memory
423 This option uses 4 bytes extra per allocated memory block.
424 If you want to look for memory leaks, specify 'y' - otherwise specify 'n'.
426 Do you want extra info on allocated sizes
428 If you specify 'y' here then the server will start to do extra book keeping
429 on the sizes of the allocated memory blocks. /stats M will not only return
430 the number of allocated blocks, but also the total number of allocated
431 bytes involved. If you defined MEMLEAKSTATS to look for memory leaks, it
432 will give the total number of allocated memory per source code location
433 (file and line number).
434 This option uses 4 bytes extra per allocated memory block, unless you already
435 specified 'y' for MEMMAGICNUMS (boundary checking), because in that case
436 it was already included (and it doesn't matter what you specify here).
437 I think you should specify 'y' here, its more fun to see the sizes :).
439 Do you want support for a time interval with /stats M
441 If you specify 'y' here then the server will start to do extra book keeping
442 on the allocated memory blocks, storing the time at which the memory block
443 was allocated. This especially slows down /stats M (but unless you use
444 that command frequently, it shouldn't really matter) and uses again 4 bytes
445 of extra memory per allocated memory block.
446 This option is especially useful if you are looking for memory leaks
447 because it allows you to specify a time window with /stats M for which
448 counted blocks must be returned. This allows to ignore recently allocated
449 blocks and permanently allocated blocks (since the start of the server).
451 Are you testing on a host without DNS
453 If you are playing with the server off-line, and no DNS is available, then
454 long delays occur before the server starts up because it tries to resolv
455 the name given on the M:line (which usually isn't given in /etc/hosts) and
456 for each connecting client.
457 If you specify 'y' here, then a call to gethostbyname() will be done only
458 for the real hostname, and the server will not try to resolv clients that
459 connect to `localhost'.
460 Note that other calls to gethostbyname() are still done anyway if you
461 use VIRTUAL_HOST and that the server still tries to resolv clients
462 that connect to the real IP-number of the server.
464 Directory where all ircd stuff sits
466 DPATH is provided so that the other path names may be provided in just
467 filename form. It is the Default PATH. When the server starts, it
468 chdir's to DPATH before chroot or any other file operation, making
469 it the "current directory" for the server. This is where core files
470 will go if the server core dumps.
471 Note that you should not include quotes here.
472 Note also that the command line option "-d <dir>" overrides the DPATH
473 you give here, except for the chroot (if you use that).
475 Server configuration file
477 This is the IRC daemon Configuration filename, mostly called "ircd.conf".
478 If you just specify the filename, the server will read its configuration
479 file from the Default Path "DPATH", which you specified above. However,
480 you are also allowed to specify a full path.
481 Note that you should not include quotes here.
485 MPATH is the filename, relative to DPATH, or the full path, of the
486 "Message Of The Day" file; mostly called "ircd.motd". The contents
487 of this file will be sent to every client that connects to the server,
489 Note that you should not include quotes here.
491 Server remote MOTD file (3 lines max)
493 RPATH is the filename, relative to DPATH, or the full path, of the
494 "Remote Message Of The Day" file; mostly called "remote.motd". The
495 contents of this file will be sent to every remote client that issues
496 a /MOTD <your server name>. Only the first three lines are sent, so
497 you might want to keep it that short ;).
498 Note that you should not include quotes here.
502 PPATH is the filename, relative to DPATH, or the full path, of the
503 "PID file", mostly called "ircd.pid". It is used for storing the
504 server's PID so a ps(1) isn't necessary.
505 Note that you should not include quotes here.
507 Do you want to log the use of /WHO x% (recommended)
509 Specify 'y' here if you want to log the use of /WHO ... x%... by your
510 Opers (see doc/readme.who). This is highly recommended since it will
511 reduce the abuse of this `spy' function. Note: You can disable this
512 spy function completely below, in which case you can give 'n' here.
513 If unsure specify 'y'.
515 Give the path and(or) filename of this log file
517 WPATH is the filename, relative to DPATH, or the full path, of the
518 log file where the use of /WHO ... x% ... by your Opers will be logged
519 (see doc/readme.who), mostly called "whox.log".
520 Note that you should not include quotes here.
522 Do you want to log G-lines to a separate file
524 Specify 'y' here if you want to log G-lines (Global access bans)
527 Give the path and(or) filename of this log file
529 GPATH is the filename, relative to DPATH, or the full path, of the
530 log file where the G-lines will be stored, mostly called "gline.log".
531 Note that you should not include quotes here.
533 Do you want to log JUPEs to a separate file
535 Specify 'y' here if you want to log JUPEs (Jupiters) to a local file.
537 Give the path and(or) filename of this log file
539 JPATH is the filename, relative to DPATH, or the full path, of the
540 log file where the logs of JUPEs will be stored; it is usually called
541 "jupe.log". Note that you should not include quotes here.
543 Do you want to log connecting users to a separate file
545 Specify 'y' here if you want to log who is connecting to your server.
546 This file can grow VERY fast on a large net work, so you probably
547 want to specify 'n' here.
549 Give the path and(or) filename of this log file
551 Here you need to specify the name of the log file where the server
552 should write the data about connecting users to. You can also specify
553 a full path. Note that you should not include quotes here.
555 Do you want to log Opers to a separate file
557 Specify 'y' here if you want to log who is successfully becoming an
558 IRC Operator on your server.
560 Give the path and(or) filename of this log file
562 Here you need to specify the name of the log file where the server
563 should write the data about Opering users. You can also specify a
564 full path. Note that you should not include quotes here.
566 Do you want to use syslog
568 If you are the sys admin of this machine, or if you have permission
569 of the sys admin to do so, you can let the server write data about
570 certain events to the syslog. You will be prompted for the events
571 that you want to log being one or more of: KILL's, SQUIT's, CONNECT's,
572 OPERing, Connecting Users and finally the log facility.
573 If you are unsure, specify 'n'. It is probably not a good idea to use
574 this on a large IRC net work.
576 Log all operator kills to syslog
578 Specify 'y' here if you want all KILLs to be written to syslog.
579 Note that on a large IRC net work this is a LOT of data.
581 Log all remote squits for all servers to syslog
583 Specify 'y' here if you want all SQUITs to be written to syslog.
584 Note that on a large IRC net work this is a LOT of data.
586 Log remote connect messages for other all servers
588 Specify 'y' here if you want all CONNECTs to be written to syslog.
589 Note that on a large IRC net work this is a LOT of data.
591 Log all users who successfully become an Oper
593 Specify 'y' here if you want all OPERs to be written to syslog.
594 Note that on a large IRC net work this is a LOT of data.
596 Send userlog stuff to syslog
598 Specify 'y' here if you want all connecting users to be written to syslog.
599 Note that on a large IRC net work this is EXTREMELY MUCH data.
600 You really want to specify 'n' here.
602 Log facility (daemon, user, local0-7)
604 Well if you got this far and still need help, then I think you should
605 go back and specify 'n' at the question "Do you want to use syslog".
607 Which local facility (0-7)
609 Well if you got this far and still need help, then I think you should
610 go back and specify 'n' at the question "Do you want to use syslog".
612 Use m4 as a preprocessor on CPATH
614 If you use m4 macro's in your "ircd.conf" file, then you need to specify 'y',
615 which will enable m4 preprocessing of the "ircd.conf" file.
616 If you are unsure specify 'n'. Note using m4 macros has often lead to
617 problems (passwords or server names that match a macro name for instance),
618 while the benefits of using m4 are highly doubtful. Unless you are
619 already a m4 wizard and insist on using it I recommend to specify 'n' here.
621 Use crypted passwords for N: lines
623 In order to allow other servers to connect to you, you need to specify
624 two configuration lines in the "ircd.conf" configuration file (CPATH).
625 Each of these lines contains a password; the C: line is used for connecting
626 to a remote server and contains the password that is sent to the remote
627 server for authentication, thus this password must be in plain text.
628 The other is the N: line and contains the password that the remote server
629 is sending to you. For security reasons it is advised to store this
630 password in DES encrypted form. If you specify 'y' here, you will be
631 allowed to use the DES encrypted password in the password field of the
632 N: line, see doc/example.conf for more details. Note that you should
633 use *different* passwords in the C: and N: lines respectively for obvious
636 Use crypted passwords for operators
638 In order to allow certain users to become IRC OPERators, they must
639 authenticate themselves with a password. This password is matched
640 against an 'O: line' in the "ircd.conf" configuration file, see
641 doc/example.conf for more details. If you specify 'y' here, you are
642 allowed to use the DES encrypted form of these passwords in your
643 "ircd.conf" file (even more, your Opers don't have to tell you their
644 real password, they can provide the DES encrypted form themselves).
645 Since it has happened often in the past that the "ircd.conf" file
646 was compromised somehow, you are highly encouraged to specify 'y' here
647 and use the DES encrypted form. You can find a program 'mkpasswd' in
648 the ircd/crypt directory that will allow you to generate the encrypted
651 Max size of the total of of all sendqs (bytes)
653 This specifies the maximum amount of RAM that your server will allocate
654 for buffering sendQ's. Small leafs can use a value as little as 1000000,
655 while large HUBs need to specify a value as high as 20000000.
656 If you run out of memory, clients and/or servers are dropped with the
657 error "Buffer allocation error". Then you will have to up this number
658 (and install more RAM if appropriate).
659 If you want a more educated guess for this value then realize that any
660 value is good if you _really_ rather want to drop servers and clients
661 then allocate more memory; this will be the case when there is the
662 danger to run out memory for other allocations.
663 Even if you run the daemon on a dedicated machine, then specifying the
664 maximum of the RAM you have is a Bad Thing because really running out
665 of memory is a lot worse then dropping clients in a controlled way:
666 if possible you should have memory left for all the internal structures
667 (channels, clients, banlists, receive buffers) at all times.
668 On average, clients seem to use 150 bytes of sendQ, but at peak moments
669 this can easily increase to 2032 bytes per client (sendQs are allocated
670 in chunks of 2032 bytes).
671 The maximum possible ammount that can be allocated for sendQs is the
672 number of connected clients times whatever you specified as maximum
673 sendQ in your Y: lines in the ircd.conf file. Likely, that value will
674 be larger then the ammount of RAM you have.
675 The educated guess I talked about earlier would be 'number of clients'
676 times * 2048 bytes + 'size of net.burst' * n, where `n' is 1 for leafs
677 and up till 5 for HUB's. The 'size of net.burst' is about 125 bytes
678 per online client (on the total network).
679 For large HUBs with 4000 clients on undernet (30,000 users), this results
680 in 27 Mb. Leafs could use 12 Mb. Of course you can use less when you
681 have less than 4000 local clients.
682 Don't forget to specify this value in bytes.
684 Max receive queue for clients (bytes)
686 Currently, everything that a client sends to a server is read by the server
687 and stored in a buffer (the clients receive queue). The server will
688 process messages from this queue one by one (running over all clients
689 each time). When a client sends new messages faster they get processed,
690 and the size of its receive buffer reaches this value, the client is
691 dropped with the error "Excess flood". A reasonable value is 1024 bytes.
692 The maximum size is 8000 bytes.
694 Maximum number of network connections (23 - (FD_SETSIZE-4))
696 This specifies the maximum number of network connections the server
697 will use. You also need some non-network connects (log files etc), so
698 the maximum value is "FD_SETSIZE-4". The minimum value is 23.
699 The only benefit of using a small value is that your server uses less
700 memory - but *only* when you really have a small (client) load.
701 Routing server that hardly take clients can use 128 here for instance.
702 Servers that are always full should just specify the maximum amount
703 that still works (which might be less then FD_SETSIZE-4, some OS need
704 kernel hacking to allow more then 1024 fds per process). The only max.
705 value that is guaranteed to work is 252 ;). Note that if the value of
706 FD_SETSIZE is for instance 1024, then that doesn't mean you can't
707 connect MORE clients - but in this case you certainly need kernel
708 hacking. Find an experienced admin with the same Operating System and
709 ask him what the maximum is and how to achieve it.
711 Default client listen port
713 This is the default listen port. You can specify more listen ports
714 in the "ircd.conf" file with 'P: lines'; see doc/example.conf for more
715 details on P: lines. Note that /stats p currently only shows P: lines,
716 which might be a reason for you to use a less often used value here.
717 Note that there is actually no difference between client and server
718 listen ports, but it is good practice to separate them for statistical
719 purpose (bandwidth usage statistics).
721 Nickname history length
722 NICKNAMEHISTORYLENGTH
723 This value specifies the length of the nick name history list, which
724 is only used for /WHOWAS. It uses about 300 to 400 bytes per entry.
725 Note that at a net.break so many client disappear that the whole
726 "whowas" list refreshed a few times (unless you make it as big as
727 20,000 of course - but you shouldn't because thats a waste of ram
728 and cpu). A reasonable value is 'total number of clients' / 25.
730 Allow Opers to see (dis)connects of local clients
732 If you specify 'y' here, you will be allowed to see all client connects and
733 disconnects as a server notice. The historical reason for adding this
734 option was to detect clone bots that connected to your server. However,
735 on a large IRC network like Undernet, the number of clients that connect
736 are so huge that it is not possible to keep an eye on this and everyone
737 has been filtering these notices out anyway. Next to that it turned out
738 to use no less then 10% of the total cpu usage last time I measured it
739 (this has been improved after that, but still).
740 Unless you insist on seeing those notices you should specify 'n' here.
741 Note that in the meantime Undernet has a LOT of other (semi- and fully-
742 automated) ways to detect clone bots, which work a LOT better for this
745 Show IP address in client connection notices
747 Usually when showing a client connection, a nick, userid and hostname are
748 displayed. Selecting 'y' here will also display the numeric IP and connection
749 class of the connecting client. This can be useful for detecting spoofed DNS and
750 virtual hosted clones. This does use extra CPU though and is generally not needed,
751 however if a connection monitor bot is the only client that looks at these
752 notices, it is more efficient than sending USERIP for every connection. This
753 option makes the server compatible with Hybrid tcm bots.
755 Do you want to use R: lines in your configuration file
757 If you specify 'y' here you will be allowed to use R:lines in the "ircd.conf".
758 This allows more freedom in restricting connections to your server by
759 calling an external program to determine whether to allow the connection.
760 It also uses a lot of overhead however, and can bog things down, so you should
761 consider whether you really need them, and if you can handle the extra load.
762 If unsure, specify 'n'.
764 Process R: lines every rehash
766 You may not want to have the R: lines checks everywhere since this can
767 cost a lot of time and delays. If you specify 'y' here, then R: lines are
768 checked whenever the "ircd.conf" file is reloaded (when the REHASH command
769 is used, or a signal SIGHUP is received by the daemon). This shouldn't be
770 too much of a drain on the system if the R:lines programs are short.
772 Process R: lines always
774 If you specify 'y' here then R: lines will be checked as often as K: lines.
775 Note that this is -very- likely to cause a severe drain on your resources.
776 Use at your own risk, specify 'n' unless your really sure.
778 Allow (local) Opers to see all local invisible users
780 If you specify 'y' here, then your (local) IRC Operators will be able to
781 see all local invisible users (clients connected to your own server).
782 The reason for this is to hunt for clone bots, make sure your Operators do
783 not use this "feature" for spying on individuals and respect the user that
784 wishes to be invisible (mostly meaning that they don't want to be found when
785 on certain channels).
786 Note: If you answer 'n' here, then you will also not be able to see remote
787 invisible users (if you specify 'y' you will also get a configuration
788 question that asks you to specify whether or not you want your Opers to see
789 remote invisible users or not).
791 Allow Opers to see all invisible users
792 SHOW_ALL_INVISIBLE_USERS
793 If you specify 'y' here, then your global IRC Operators (O:) will be able
794 to see ALL invisible users. The reason for this is to hunt for clone bots,
795 make sure your Operators do not use this "feature" for spying on individuals
796 and respect the user that wishes to be invisible (mostly meaning that they
797 don't want to be found when on certain channels).
799 Allow global Opers (O:) to see inside secret channels
800 OPERS_SEE_IN_SECRET_CHANNELS
801 If you specify 'y' here, then your global IRC Operators (O:) will be able
802 to see who is on a specified, secret channel, without joining themselfs.
803 This can be needed to make a reasonable judgement in the case of a "channel
804 takeover" being reported, while the channel is set invite only.
805 See doc/readme.who for more details.
807 Allow local Opers (o:) to see inside secret channels
808 LOCOP_SEE_IN_SECRET_CHANNELS
809 If you specify 'y' here, then your local IRC Operators (o:) will be able
810 to see who is on a specified, secret channel, without joining themselfs.
811 This can be needed to make a reasonable judgement in the case of a "channel
812 takeover" being reported, while the channel is set invite only.
813 See doc/readme.who for more details.
814 If unsure, specify 'n'.
816 Don't truncate obnoxiously long /who output for opers
818 A /who command can sometimes return several hundred lines of info. To
819 reduce flooding and sending too much, the output is truncated. By
820 answering 'y' to this, when an IRC Operator uses /who, the output will
821 not be truncated, no matter how much data is returned.
823 Allow Opers to use the KILL command
825 You can select 'n' if you don't think operators should be able
826 to use the KILL command, and wish to prevent your operators from
827 using it. This will not, however, prevent operators on other
828 servers from issuing KILLs to your clients. You probably want to
829 select 'y' for this unless you really really don't think KILL
830 should -ever- be used by an operator.
832 Allow Opers to use the REHASH command
834 Allows operators to use the REHASH command to reload the servers
835 configuration file (ircd.conf) if you select 'n', you can still
836 reload the configuration file with a unix command,
837 kill -HUP `cat ircd.pid`. If unsure, select 'y'.
839 Allow Opers to use the RESTART command
841 Allows an operator to use the RESTART command to cause the server
842 to restart, using the ircd executable in SPATH. If unsure, select 'y'.
844 Allow Opers to use the DIE command
846 Allows an operator to use the DIE command to shutdown the server
847 online. If you select 'n' you will need to send the server a kill
848 signal to shutdown the server. If unsure, select 'y'.
850 Allow Opers to add local G-lines
852 Allows operators to add local G-lines with the GLINE command. This is
853 like a *local* KILL, except that the user being killed can't immediately
854 reconnect: He will have to wait for the G-line to expire.
855 The reason for adding this is that a KILL is rather useless for removing
856 (or 'warning') abusers (it is still THE command to remove ghosts and
857 a-like, the reason KILL was added in the first place). However, adding
858 G-lines for a dynamic IP with expire times larger then 10 minutes is highly
859 discouraged: The user will already have dialed in via another IP or account
860 and the G-line would only harm other, innocent, users.
862 Allow Opers to connect from a remote site
864 If you select 'n' for this, clients must be on the 'same network' as
865 the server in order to gain oper privledges. If you're not sure, just
868 Allow local opers to use the REHASH command
870 Allows a local operator (defined by a lowercase o:line in ircd.conf)
871 to cause the server to reload its configuration file (ircd.conf) with
872 the REHASH command. If unsure, select 'n'.
874 Allow local opers to use the RESTART command
876 Allows a local operator (defined by a lowercase o:line in ircd.conf)
877 to use the RESTART command. If unsure, select 'n'.
879 Allow local opers to use the DIE command
881 Allows a local operator (defined by a lowercase o:line in ircd.conf)
882 to use the DIE command. If unsure, select 'n'.
884 Allow local opers to add local G-lines
886 Allows a local operator (defined by a lowercase o:line in ircd.conf)
887 to add local G-lines with the GLINE command. This is like a *local* KILL,
888 except that the user being killed can't immediately reconnect: He will
889 have to wait for the G-line to expire.
891 Do you want to have a default LIST parameter
893 Pre-Undernet, the LIST command could either be given with one channel
894 name, or without any parameter. In the last case it would simply list
895 all channels. In time the IRC networks grew big, until the output of
896 the LIST command always filled up the sendQ of the client (and dis-
897 connected it). This was fixed by Carlo Wood (Run@IRC) on request of a
898 Dutch ISP whose users complained about this: The LIST output is now
899 generated in small chunks, generating more each time when there is room
900 in the clients sendQ. However, then it turned out that LIST (now it
901 worked) used 50% of all cpu (not even mentioning the bandwidth)...
902 This was unacceptable and the mentioned patch was disabled. On the
903 other hand we wanted LIST to work at least partly, so a few new
904 parameters have been added to LIST: <,>,C<,C>,T<,T> each followed by
905 a number they filter respectively the number of users on the channel,
906 the creation time of the channel (or age, depended on the value of
907 the number) and the topic set time.
908 If you specify 'y' here, then each time a "/LIST" (without parameter)
909 is issued by a client, a default parameter is used. Note that when
910 a parameter is used, the client can still max. sendq out - the send
911 flood control only works without any parameter.
912 If you specify 'n' here then a "/LIST" without parameters will list
913 all channels (and work), but as just said: it uses a LOT of cpu and
914 bandwidth on a large net.work.
915 If you specify 'y' you will be prompted for the default parameter.
917 Give default LIST parameter
919 Here you need to specify the default LIST parameter which is used
920 when the server receives a LIST without any parameter.
921 You should use something that limits the output to a maximum of a
922 few hundred channels; for instance "T<10" (topic is set less then
923 10 seconds ago) or ">10" (more then 10 users on the channel) or even
924 a combination of this. Note that you should not include quotes here.
926 K: line comments treated as a file
928 If you specify 'y' here, then K: line comments (see doc/example.conf
929 for more details on the K: line syntax) will be treated as a filename
930 by default. The file needs to exist and will be written to clients
931 that match that K: line.
932 If you specify 'n' here, then K: line comments will be treated as
933 a comments by default.
934 In both cases you can override the default by prepending a filename
935 with a '!' or enclose a comment between double quotes.
936 If unsure, use the default.
938 Only nullify idle-time on PRIVMSG
940 The IRC command WHOIS gives an idle time for clients. If you want that
941 this idle time is set to zero only when the clients send a PRIVMSG,
942 then you should specify a 'y' here.
943 If you specify a 'n' then the idle time will be nullified on all messages
944 except the server PING/PONG.
946 Check clone limit (2!)
950 Check clone period (20!)
954 Check clone delay (600!)
958 Max auto connects per class (1!)
962 Enable message logging
964 Define this if you want the server to log received messages in static memory
965 at parsing time. -This is for debugging purposes only-. You might want to
966 redefine LOG_MASK_TYPE in s_debug.h and LOG_MASK_LEVEL in s_debug.c too.
967 The default is to log all messages that change some status in server's data
968 structures. Select 'n' unless you are debugging the server code.
969 DO NOT SELECT THIS ON PRODUCTION SERVERS!
973 Number of messages to log. Keep this low as raising it to 1024 will use 800k
974 of _static_ memory! Recommended value is 128. You must include this even if
975 you selected 'n' for MSGLOG_ENABLED.
977 Only allow KILLs of local clients
979 This only allows operators of this server to KILL clients directly connected
980 to this server. Operators will not be able to issue KILLs for clients on
981 other servers. Some networks (not Undernet) require that this be defined
982 for newly linking servers, but if you haven't been told to do otherwise,
985 Max server idle time (60)
987 This is the maximum idle time for the server. If no messages are received
988 in TIMSEC seconds, PINGFREQUENCY and CONNECTFREQUENCY are checked.
989 Recommended value is 60 seconds.
991 KILL nick chase time limit (30)
993 This is the maximum amount of time a KILL command will automatically change
994 to the current nick of a user that has just changed nicks from the one given
995 with the original KILL. Don't change this unless you really need to.
997 Max number of channels per user (recommended: 5)
999 This is the maximum number of channels a user can be in at a time.
1000 The "mandatory" value on Undernet is currently 10. Since it only
1001 influences the local server when you decrease it, its up to you to decide
1002 if you want to use a smaller value. Do not use a larger value however,
1003 because it DOES cost more memory and bandwidth on all other servers
1004 when you allow users to join more channels simultaneously.
1005 One of the most important reasons to choose a smaller value is the fact
1006 that the now-a-days 'GUI' clients tend to stay on every channel they
1007 join (they aren't bothered by flooding in other channels). It DOES take
1008 your bandwidth however to send all those messages for 10 different
1009 channels to all your users.
1011 Max number of silence masks (15!)
1013 This is the maximum number of masks a user can silence at a time.
1014 The silence command allows users to filter messages directed at them
1015 from certain users or domains, at the source server. Increasing this
1016 number allows users to use up more memory with inefficient use of the
1017 command. If your not sure, don't change this.
1019 Expected average banmask length (40!)
1021 This is the expected average banmask length. Leave it at 40.
1023 Use .config of THIS source tree as your upgrade default
1025 Each source tree keeps its *own* config/.config file with the default
1026 values for all questions (those that you gave the last time you did a
1027 'make config'). Whenever you do 'make config' again in this source tree,
1028 you will get these defaults.
1029 However, when you *upgrade* to a new version (and get a NEW source tree),
1030 it doesn't have a .config yet and will (try to) use a .config of one of
1031 your previous source trees.
1032 If you specify 'y' here, then the last defaults of THIS source tree will
1033 be used in your next upgrade. Note that any changes you make later to
1034 config/.config (by running 'make config' again) will also take effect
1035 on this later upgrade.
1036 You can always change this by making a new hard link from .config ->
1037 ircu2.10.xx/config/.config in the directory where you keep the source
1039 If unsure, and you are not currently installing a test source tree,
1040 specify 'y'. If this is a second source tree that you will only be
1041 experimenting with, specify 'n'.
1043 Class 0 ping frequency (120)
1045 If the daemon doesn't receive anything from any of its links within
1046 PINGFREQUENCY seconds, then the it will attempt to check for an active link
1047 with a PING message. If no reply is received within (PINGFREQUENCY * 2)
1048 seconds, then the connection will be closed. This value is overridden by
1049 a Y:line in "ircd.conf" if the connections I/C/N: line in "ircd.conf" assigns
1050 a specific class to the connection (recommended).
1052 Class 0 connect frequency (600)
1054 This is the default frequency that the server attempts to reconnect with
1055 its uplink server if it is set to auto connect to it. Note that this value
1056 is overridden by a Y:line in ircd.conf if the C/N:lines in ircd.conf
1057 assigns a specific class to the connection (recommended).
1059 Min time before a link is good (300)
1061 Often the net breaks for a short time and its useful to reestablish the
1062 same connection faster than CONNECTFREQUENCY would allow, but to keep
1063 from trying again on a bad connection, we require that the connection be
1064 open for a certain minimum time. The recommended value is 300 seconds.
1066 Wait before reconnecting to good link (10!)
1068 When attempting to quickly reestablish a connection to a good link, we
1069 give the net a few seconds to steady. This time must be long enough for
1070 the other end to notice it broke too. The recommended value is 10 seconds.
1072 connect(2) timeout (90!)
1074 Number of seconds to wait for a connect(2) call to complete. NOTE: this
1075 must be at *LEAST* 10. When a client connects, it has CONNECTTIMEOUT - 10
1076 seconds for its host to respond to an ident lookup query and for a DNS
1077 lookup to complete. It is recommended you don't change this value, but if
1078 you do, consider the fact that users whose clients do not support NOSPOOF
1079 will have to type /QUOTE PING <big number> before registration.
1081 Max send queue (40000)
1082 DEFAULTMAXSENDQLENGTH
1083 This is the default value of the "max. sendq length" of Y: line classes
1084 (see doc/example.conf for details on Y: lines). You will probably
1085 always override this value in your "ircd.conf" with the Y: lines.
1086 The given value used to be an often used value for client sendqs.