diff options
Diffstat (limited to 'doc')
40 files changed, 12768 insertions, 0 deletions
diff --git a/doc/2.10-New b/doc/2.10-New new file mode 100644 index 0000000..8903783 --- /dev/null +++ b/doc/2.10-New @@ -0,0 +1,18 @@ + * +a (away) user mode + This user mode is used to propagate users' away status between + servers. + + * added channel mode +e (exceptions to bans). + * added channel mode +I (invitations). + * invites can now be used to override channel bans and limit. + * banned users cannot speak on channel without +o/+v. + * ! channels introduced (can't be collided); + A quite detailed technical description can be found on the web: + http://www.stealth.net/~kalt/irc/channel.html + + * NJOIN for 2.10 <-> 2.10 communication on connect bursts instead of + the combined JOIN/MODE introduced by 2.9 (and now deprecated) + + * a slave process is now used to authenticate incoming connections. + The slave's modular design makes it easy to add new authentication + modules. diff --git a/doc/2.9-New b/doc/2.9-New new file mode 100644 index 0000000..17d78e2 --- /dev/null +++ b/doc/2.9-New @@ -0,0 +1,60 @@ + * +a (anonymous) channel mode + + This channel mode is only allowed on &local channels. + + * +s user mode removed; + * &KILLS, &NOTICES, &ERRORS, &CHANNEL, &HASH, &NUMERICS, &SERVERS + channels created and used by the server for server notices + (comments on what goes where please) and dividing notices up this + way was better than using more user modes (they default to the + server being on them and +amnt); + + &KILLS : server and oper KILLS + &NOTICES : warnings and notices + &ERRORS : server errors + &LOCAL : notices concerning local clients. + &CHANNEL : fake modes + &HASH : hash tables growth + &NUMERICS : numerics received by the server + &SERVERS : servers joining and leaving the net + + * + channels reintroduced (can't have modes); + * Config doesn't prompt for cc/includes/libs; + * M-line doesn't define port, PORTNUM removed from config.h (must use + P-lines or use inetd); + * BIND 4.9.2 libresolv stuff included; + * USERHOST will return as many id's as requested. + * RECONNECT to pickup error'd sserver-server links (not activated) + * chooses next bigger prime for hash table sizes rather than + needing exact primes + * hash tables grow to suit rather than being static in size + * adaptive growth of sendq (suggested by msa) + * Server parameter in USER message tokenised betweem 2.9 servers + * whowas tables grow to suit rather than being static in size + * NICK+USER+UMODE combined into NICK for 2.9 <-> 2.9 communication + * MODE +ov and JOIN combined into JOIN for 2.9 <-> 2.9 communication + on connect bursts + * QUIT removed when possible for 2.9 <-> 2.9 communication on split + * autoconf'iscated ircd. + * userlog has single character appended to show cause of quit. + * i lines (user mode +r) + + i lined users have a restricted access: They are forbidden + MODE, KICK and TOPIC on #channels. They don't get channel + operator status when creating a #channel, and cannot + change their nickname once connected. + + * enhanced nick delay to prevent collisions + + The nickname of users splitting away is locked for 15 minutes, + and cannot be used by local clients. + + * channel history to prevent op riding + + A user with channel operator status on #foo splitting away + means that no local user can re-create the channel #foo during + the next 15 minutes. It doesn't stop users from using #foo as + as the channel is not empty. + +Some transition documentation from 2.8 to 2.9 version can be found in + http://www.irc.org/~irc/server/ diff --git a/doc/Authors b/doc/Authors new file mode 100644 index 0000000..07f8ee0 --- /dev/null +++ b/doc/Authors @@ -0,0 +1,180 @@ +/************************************************************************ + * IRC - Internet Relay Chat, doc/AUTHORS + * Copyright (C) 1990 + * + * AUTHORS FILE: + * This file attempts to remember all contributors to the IRC + * developement. Names can be only added this file, no name + * should ever be removed. This file must be included into all + * distributions of IRC and derived works. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +The email addresses listed in here may or may not be up to date. + +IRC was conceived of and written by Jarkko Oikarinen <jto@tolsun.oulu.fi>. +IRC was originally written in University of Oulu, Computing Center. +Jan 1991 - IRC 2.6 jto@tolsun.oulu.fi + - Multiple Channels and protocol changes + +Contributions were made by a cast of dozens, including the following: + +Markku Jarvinen <mta@tut.fi>: Emacs-like editing facility for the client + +Kimmo Suominen <kim@kannel.lut.fi>: HP-UX port + +Jeff Trim <jtrim@orion.cair.du.edu>: enhancements and advice + +Vijay Subramaniam <vijay@lll-winken.llnl.gov>: advice and ruthless publicity + +Karl Kleinpaste <karl@cis.ohio-state.edu>: user's manual + +Greg Lindahl <gl8f@virginia.edu>: AUTOMATON code, the Wumpus GM automaton, +myriad bug fixes + +Bill Wisner <wisner@hayes.fai.alaska.edu>: numerous bug fixes and code +enhancements + +Tom Davis <conslt16@zeus.unl.edu> and Tim Russell <russell@zeus.unl.edu>: +VMS modifications + +Markku Savela <msa@tel4.tel.vtt.fi>: advice, support, and being the +incentive to do some of our *own* coding. :) + +Tom Hopkins <hoppie@buengf.bu.edu>: bug fixes, quarantine lines, +consolidation of various patches. + +Christopher Davis <ckd@cs.bu.edu>: EFnet/Anet gateway coding, +many automata ;), documentation fixing. + +Helen Rose <hrose@cs.bu.edu>: documentation updating, and fixing. + +Tom Hinds <rocker@bucsf.bu.edu>: emacs client updating. + +Tim Miller <cerebus@bu-pub.bu.edu>: various server and client-breaking +features. + +Darren Reed <avalon@coombs.anu.edu.au>: various bug fixes and enhancements. +Introduced nickname and channelname hash tables into the server. + +The version 2.2 release was coordinated by Mike Bolotski +<mikeb@salmon.ee.ubc.ca>. + +The version 2.4 release was coordinated by Markku Savela and +Chelsea Ashley Dyerman + +The version 2.5.2 release was coordinated by Christopher Davis, Helen Rose, +and Tom Hopkins. + +The versions 2.6.2, 2.7, 2.8 and 2.9 releases were coordinated by Darren Reed. + +Contributions for the 2.8 release from the following people: +Matthew Green <phone@cairo.anu.edu.au> +Chuck Kane <ckane@ece.uiuc.edu> +Matt Lyle <matt@oc.com> +Vesa Ruokonen <ruokonen@lut.fi> + +Markku Savela <Markku.Savela@vtt.fi> / April 1990 +Fixed various bugs in 2.2PL1 release server (2.2msa.4) and changed +sockets to use non-blocking mode (2.2msa.9). [I have absolutely +nothing to do with clients :-] + +Chelsea Ashley Dyerman <chelsea@earth.cchem.berkeley.edu> / April 1990 +Rewrote the Makefiles, restructuring of source tree. Added libIrcd.a to +the Makefile macros, numerous reformatting of server text messages, and +added mkversion.sh to keep track of compilation statistics. Numerous +bug fixes and enhancements, and co-coordinator of the 2.4 release. + +jarlek@ifi.uio.no added mail functions to irc. + +Armin Gruner <gruner@informatik.tu-muenchen.de> / May, June 1990: +* Patched KILL-line feature for ircd.conf, works now. + Enhancement: Time intervals can be specified in passwd-field. + Result: KILL-Line is only active during these intervals +* Patched PRIVMSG handling, now OPER can specify masks for sending + private messages, advantage: msg to all at a specified server or host. +* Little tests on irc 2.5 alpha, fixed some little typos in client code. + Change: common/debug.c has been moved to ircd/s_debug.c, and a + irc/c_debug.c has been created, for the benefit that wrong server msg + are displayed if client does not recognize them. (strange, if a server + sends an 'unknown command', isn't it?) + +Tom Hopkins <hoppie@buengf.bu.edu> / September, October 1990: +* Patched msa's K lines for servers (Q lines). +* Consolidated several patches, including Stealth's logging patch. +* Fixed several minor bugs. +* Has done lots of other stuff that I can't seem to remember, but he + always works on code, so he has to have done alot more than three + lines worth. :) + +Various modifications, bugreports, cleanups and testing by: + +Hugo Calendar <hugo@ucscb.ucsc.edu> +Bo Adler <thumper@ugcs.caltech.edu> +Michael Sandrof <mike@uniteq.com> +Jon Solomon <jsol@cs.bu.edu> +Jan Peterson <jlp@hamblin.math.byu.edu> +Nathan Glasser <nathan@brokaw.lcs.mit.edu> +Helen Rose <hrose@kei.com> +Mike Pelletier <stealth@caen.engin.umich.edu> +Basalat Ali Raja <gwydion@gnu.ai.mit.edu> +Eric P. Scott <eps@toaster.sfsu.edu> +Dan Goodwin <fornax@wpi.wpi.edu> +Noah Friedman <friedman@ai.mit.edu> + +The 2.9 release brought many improvements to the protocol: adaptive growth +of sendq, hash tables, whowas table, extended NICK syntax, server tokens, +extended JOIN syntax, restricted usermode, nick and channel delay, +suppression of server-server QUITs during splits, suppression of usermode s.. + +Contributions for the 2.9 release from the following people: +Vesa Ruokonen <ruokonen@lut.fi>: V configuration lines, many bug fixes. +Christophe Kalt <kalt@stealth.net>: nick and channel delay, suppressed QUITs +during netsplits, many bug fixes. + +The versions 2.9.3, 2.9.4, 2.9.5 releases were coordinated by Christophe Kalt. + +Christophe Kalt <kalt@stealth.net>: server link compression using zlib, added +B configuration lines, extended IP bans and K lines to work on resolved hosts, +finished service code, virtual IP support. + +Various modifications, bugreports, cleanups and testing by: + +Chris Behrens <cbehrens@concentric.net> +Helmut Springer <delta@RUS.Uni-Stuttgart.DE> +Magnus Tjernstrom <d92-mtm@oook.campus.luth.se> +Olivier Galibert <Olivier.Galibert@mines.u-nancy.fr>: service code testing +Alain Nissen <Alain.Nissen@ulg.ac.be>: source tree restructuration, many +portability issues, new configure.in +Roar Thronęs <roart@nvg.ntnu.no> added IPv6 support + +The versions 2.10 releases were coordinated by Christophe Kalt. + +Christophe Kalt <kalt@stealth.net>: added channel modes e and I, designed and +implemented !channels, brought away status back to life, added NJOIN message, +made invitation override bans, wrote iauth. + +Various modifications, bugreports, cleanups and testing by: + +Helmut Springer <delta@RUS.Uni-Stuttgart.DE> +Michael 'Eumel' Neumayer <eumel@42.org> +Kurt Roeckx <Q@ping.be> cleaned up the compression code, among many things +Roar Thronęs <roart@nvg.ntnu.no> for more IPv6 work +Piotr Kucharski <chopin@sgh.waw.pl> for his work on the anti socks module +Michal Svoboda <svobodam@eva.vsp.cz> removed useless anUser linked list + +Thanks go to those persons not mentioned here who have added their advice, +opinions, and code to IRC. diff --git a/doc/BUGS b/doc/BUGS new file mode 100644 index 0000000..32e914f --- /dev/null +++ b/doc/BUGS @@ -0,0 +1,13 @@ +# @(#)$Id: BUGS,v 1.14 1999/03/07 22:59:31 kalt Exp $ + +The list is probably not as scary as it once was. +Anyone with some free time is welcome to fix those =) + +* The server still occasionnally crashes because of some bug + in the hash tables. (Vesa already fixed this bug several + times but it keeps crashing :^) + +* RECONNECT is still in some unknown state. (and deactivated + for various reasons) + +* The operator count showed by /LUSERS becomes incorrect (negative). diff --git a/doc/ChangeLog b/doc/ChangeLog new file mode 100644 index 0000000..9869542 --- /dev/null +++ b/doc/ChangeLog @@ -0,0 +1,1956 @@ +2.10.3 + +1999-08-13 Christophe Kalt + + * channel.c/match_modeid(): logic fix (reported by Michal Svoboda). + + * os.h: added YET ANOTHER KLUDGE for linux and poll(). + + * ircd.c: assume "-s" option in CYGWIN environment. + + * configure.in: update for CYGWIN environment. + +1999-08-13 Piotr Kucharski + + * mod_socks.c/socks_read(): allow more methods in socks5 check. + +1999-08-01 Piotr Kucharski + + * ircd.c/bad_command(): -d command line option no longer exists, + while -s was added. + +1999-07-28 Christophe Kalt + + * struct_def.h: IsChannelName() macro cannot use cid_ok() for the + client. + + * channel.c/m_njoin(): inverse condition prevented modes from + being sent to users and 2.9 servers. + +1999-07-27 Piotr Kucharski + + * s_id.c/cid_ok(): quite unfortunate typo which made joining + !channels impossible (from Michal Svoboda). + +1999-07-25 Christophe Kalt + + * channel.c: sanity checks to drop modes on +channels even when + received from servers (from Michal Svoboda). + + * struct_def.h, channel.c, s_id.c: added checks to ensure !name + validity (from Michal Svoboda). + +1999-07-23 Christophe Kalt + + * s_bsd.c/inetport(): fixed test for IPv6 (from KIKUCHI Takahiro). + + * ircd.c: + * better casting for sbrk() for OSF 4.0. + * setup_me(): fixed syntax for IPv6. + +1999-07-21 Piotr Kucharski + + * channel.c/set_mode(): send ERR_UNKNOWNMODE to 'mode O' issued + on non-!channels. + +1999-07-21 Christophe Kalt + + * s_misc.c/exit_one_client(): generate fake PARTs for users + quitting anonymous channels. + + * send.c/sendto_common_channels(): skip anonymous channels. + + * Makefile.in: ircdwatch needs clsupport.o which needs clmatch.o. + + * channel.c: added notices to warn users about +a channels. + +1999-07-20 Kurt Roeckx + + * channel.c: + * m_njoin: send +v for uniqops in the right case + * send_channel_members: send +v inside njoin for ops too + * m_invite: send back numerics if the channel doesn't exist + +1999-07-18 Piotr Kucharski + + * channel.c/set_mode(), m_kick(): send ERR_NOTONCHANNEL, not + ERR_CHANOPRIVSNEEDED, thus disable stealth secret channel probing; + furthermore, use rather sptr->name, not parv[0] in sending errors; + +1999-07-17 Christophe Kalt + + * ircd.c/setup_me(), s_bsd.c: fixed that really old bug about the + I line format to match connections received on the loopback + interface (from Eugene L. Vorokov). + + * configure.in: fixed previous changes about poll() (reported by + KIKUCHI Takahiro). + +1999-07-17 Kurt Roeckx + + * s_user.c/m_kill(): killer could end up < path + +1999-07-14 Christophe Kalt + + * configure.in, os.h: use ncurses.h (from KIKUCHI Takahiro). + + * configure.in: SunOS has poll(), but we don't want to use it + (reported by KIKUCHI Takahiro). + + * mod_lhex.c: replaced strtoul() with sscanf(). + +1999-07-11 Christophe Kalt + + * a_defines.h was missing support_def.h (from KIKUCHI Takahiro). + + * Makefile.in: ircdwatch.c uses strerror(), needs clsupport.o + (from KIKUCHI Takahiro). + + * config.h.dist, ircd.c, s_debug.c: renamed CONNECTTIMEOUT to + ACCEPTTIMEOUT, and changed from 30 to 90. + +1999-07-11 Piotr Kucharski + + * mod_socks.c: + * socks_write(): a typo made iauth allow open proxies and + caused a lot of BADPROTO warnings (from KIKUCHI Takahiro). + * socks_init(): buffer overflow with tmpbuf[] being too + small to hold too many iauth options (also from Takahiro). + +1999-07-09 Christophe Kalt + + * configure.in, os.h, s_bsd.c: IPv6 updates (from KIKUCHI Takahiro). + +1999-07-05 Christophe Kalt + + * s_bsd.c/read_message(): can't use iauth_options when USE_IAUTH + is undefined. + +1999-07-05 Piotr Kucharski + + * channel.c/m_invite(): invite to :-channels was sometimes + lost with no error. + +1999-07-04 Christophe Kalt + + * a_conf_def.h, a_conf.c, a_io.c: added the "timeout" option. + + * mod_socks.c: added PROXY_BADPROTO & OPT_PROTOCOL to + differentiate between unexpected and bad protocol. + + * s_id.c: fixed alphabet_id[] (noted by Michal Svoboda), and + rewrote some code. + +1999-07-04 Piotr Kucharski + + * s_user.c/m_nick(): fix performance bug introduced in code + preventing insidious collisions + + * mod_socks.c/socks_open_proxy(): now reports in logs versions + of open proxies found + +1999-07-02 Kurt Roeckx + + * configure.in, Makefile.in: Added -I for inet6. + +1999-07-02 Christophe Kalt + + * res.c/proc_answer(): portability fix from hybrid6. + + * send.c/sendto_match_butone(): finally looked closely at why this + was sending $*.mask to the wrong servers, fixed. + + * struct_def.h, send.c/sendto_match_butone(), list_ext.h, + list.c/make_client(), ircd.c/setup_me(), s_misc.c/exit_client(), + s_serv.c, s_service.c/m_service(), s_user.c/m_user(): removed old + code conditional to NO_USRTOP being undefined. + + * s_user.c: + * m_nick(): new delay on nicks to prevent insidious + collisions (from Piotr Kucharski). + * m_private(): dropped restrictions on mass msg/notices. + + * s_auth.c/read_authports(): can't call set_clean_username with + ->auth pointing to ->username (from Piotr Kucharski). + + * mod_socks.c: couple typos. + + * a_conf.c/conf_read(): ->popt wasn't initialized. + +1999-06-27 Christophe Kalt + + * s_misc.c/exit_one_client(): made BETTER_NDELAY a little more + friendly (from Piotr Kucharski). + + * a_io.c/sendto_ircd(): added error output in write error notice. + + * hash.c/hash_channel_name(): added shortname parameter to disable + guess and fix bug (From Q). + + * channel.c/m_join(): reject local user join for duplicates. + + * mod_socks.c: more options, less bugs (from Piotr Kucharski). + + * s_user.c: + * m_nick(): kill nicks introduced by server if parc != 8 + instead of simply sending a notice. + * register_user(): static variable wasn't declared as such. + + * ircd.c, s_serv.c: used mybasename(); + + * support_ext.h, support.c: added mybasename(); + +1999-06-20 Christophe Kalt + + * mod_socks.c: added code to allow checks for v5 as well as v4, + depending on configuration (from Piotr Kucharski). + + * configure.in, ircd.c/ircd_writetune(), s_serv.c/m_rehash(): use + basename, and check if it needs libgen. + + * channel.c/m_njoin(): simple optimization resulting from change + to sendto_match_servs_notv() below. + + * send_ext.h, send.c: sendto_serv_{not,}v and + sendto_match_servs_{not,}v now return an integer. + +1999-06-16 Christophe Kalt + + * iauth.c/main(): send version to ircd upon startup. + + * mod_rfc931.c/rfc931_work(): removed checks on weird chars, let + ircd deal with this. + + * s_auth.c: + * start_auth(): abort if getpeername() fails (problem + reported by Wolfgang Scherer). + * added set_clean_username(), used in read_iauth() and + read_authports(). + * read_iauth(): added o message (a->i). + * read_iauth(): added V message (a->i). + + * struct_def.h, s_serv.c: added SV_OLDSQUIT, and made m_squit() + smarter (ugh, it's a kludge). + +1999-06-07 Christophe Kalt + + * s_user.c: + * m_nick(): added notice to warn of NICK messages coming + from servers with parc != 8. + * register_user(): fixed unaccurate notices about iauth. + + * config.h.dist: increased HANGONRETRYDELAY & HANGONGOODLINK values. + +1999-06-06 Christophe Kalt + + * struct_def.h, send.c/sendto_match_butone(), list_ext.h, + list.c/make_client(), ircd.c/setup_me(), s_misc.c/exit_client(), + s_serv.c, s_service.c/m_service(), s_user.c/m_user(): added + reorder_client_list() and NO_USRTOP defines. This reduces memory + usage (Original code from Michal Svoboda). + + * channel.c/reop_channel(): desynched could be caused by server + reops (channel mode +r) (reported by Thomas Kuiper). + +1999-05-01 Christophe Kalt + + * s_conf_ext.h, s_conf.c, s_serv.c: added a new list for K/k lines + only as an easy way to improve overall performance. + + * service_def.h: updated SERVICE_MASK_ALL. + +1999-04-19 Christophe Kalt + + * channel.c/m_njoin(): need to use sendto_match_servs*(); duh! + + * send_ext.h, send.c: added sendto_match_servs_notv(). + + * s_serv.c/m_squit(): fixed logic in previous change. + + * packet.c/dopacket(): fixed uncompression code. + +1999-04-15 Christophe Kalt + + * service_def.h, channel.c/m_topic(), s_service.c/m_servset(): + added SERVICE_WANT_TOPIC. + + * s_serv.c/m_squit(): fixed serious and old bug that caused + servers to be removed from memory (but not dependants!!!) while + squit is going upstream. + + * s_debug.c/send_usage(): divide by zero bugfix (reported by Aaron + Campbell). + + * channel.c/m_njoin(): ignore channels with an invalid mask. + + * common/parse.c: extended MSG_NOU to include services. + +1999-04-10 Christophe Kalt + + * Makefile.in, a_conf_def.h, a_externs.h, a_conf.c, mod_lhex_ext.h, + mod_lhex.c: New module (from Andrew Snare). + + * s_debug.c: increased size of debugbuf[] to avoid overflows (from + Eugene L. Vorokov). + + * send.c/send_message(): catch more unlikely errors (from Eugene + L. Vorokov). + + * s_bsd.c/set_sock_opts(): silently ignore errors for SO_SNDLOWAT. + + * common/os.h: FreeBSD portability (from KIKUCHI Takahiro). + + * s_bsd.c/read_message(): + * debug notice format bugfix (from Q). + * INET6 fix (from KIKUCHI Takahiro). + + * s_conf.c: + * initconf(): allow service type to be in hex in the + configuration (from Thomas Kuiper). + * find_conf_flags(): case sensitivity fix (from Q). + +1999-03-19 Christophe Kalt + + * mod_socks.c/socks_work(): closed proxies would get rejected on + first attempt and accepted later as the "closed" status was in the + cache. + + * s_user.c/register_user(): fixed iauth failure notice timing bug. + +1999-03-13 Christophe Kalt + + * struct_def.h, ircd.c, s_auth.c, s_bsd.c, s_user_ext.h, s_user.c, + a_struct_def.h, iauth.c, a_conf.c, a_io.c: added XOPT_EARLYPARSE, + `P' message for iauth, `extinfo' option for iauth. + + * a_io.c/next_io(): if xxx_start() returns 1, count module as left. + +1999-03-11 Christophe Kalt + + * chkconf.c: + * finally shut off MyFree() redefinition warning. + * fixed undefined behaviour with ++ operator (effet de bord). + + * a_io.c/init_io(): bzero bugfix (reported by Tomas Edwardsson). + + * a_conf_def.h, a_conf.c: + * conf_err(): send conf errors to ircd as well. + * conf_match(): extended iauth.conf syntax for hostname + and IP matching. + * added conf_ipmask() to allow use of a.b.c.d/z format for IP. + + * configure.in: use "cc -Ae" on HPUX (reported by Jens Riecken). + + * ircd.c/main(): iauth's presence needs to be checked before + setting up the signal handlers. + +1999-03-09 Christophe Kalt + + * a_struct_def.h, a_conf_ext.h, a_conf_def.h, a_conf.c, a_io.c, + mod_pipe.c, mod_rfc931.c, mod_socks.c: rewrote next_io() and + conf_match() to use new more flexible logic. + + * os.h, a_conf.c, iauth.c, configure.in, Makefile.in, acconfig.h: + added DSM support. + +1999-03-08 Christophe Kalt + + * struct_def.h, a_conf.c, a_conf_ext.h, iauth.c, ircd.c, s_auth.c, + s_auth_ext.h, s_bsd.c, s_user.c, s_user_exit.c: added + XOPT_{REQUIRED,NOTIMEOUT,EXTWAIT}, added iauth_spawn counter; + removed iauth_required variable. + + * struct_def.h, s_auth.c, s_user.c: added FLAGS_DONEXAUTH to get + rid of the approximation from yesterday. + + * s_bsd.c/read_message(): use CLR_READ_EVENT() before modifying fd. + +1999-03-07 Christophe Kalt + + * res_comp.c: added missing prototypes. + + * struct_def.h, a_conf.c, a_conf_ext.h, iauth.c, s_auth_ext.h, + s_auth.c, s_user.c: added option to reject new user connections if + iauth is dead (approximate!). + + * struct_def.h, ircd.c, res.c, s_auth.c, s_bsd.c: removed all + references to {Set,Clear,Do}Access macros (unused for a LONG time). + + * ircd.c: + * check_pings(): fixed "immediate ping timeout" bug. + * main(): check for iauth's presence after changing [ug]id. + + * s_bsd.c/do_dns_async(): notify iauth when no PTR record is found. + + * Makefile.in: fix for M4 file path (Matthew Sullivan). + +1999-03-04 Christophe Kalt + + * ircd.c/io_loop(), s_bsd.c/start_iauth(): keep trying to restart + iauth (up to once every 90 seconds) to avoid being iauth-less. + + * struct_def.h, mod_socks.c, s_auth.c, s_user.c: added new message + type from iauth to ircd to allow denying connections without any + message sent to &AUTH; used by the socks module. + +1999-02-22 Christophe Kalt + + * s_err.c: RPL_TRACESERVICE changed to show values in hexadecimal + (from Thomas Kuiper). + + * s_service.c/m_service(): fixed error message. + +1999-02-20 Christophe Kalt + + * configure, configure.in, Makefile.in, config.h.dist, buildm4, + send.c, ircd.c, s_bsd.c, s_conf.c, s_misc.c, s_serv.c, s_user.c, + chkconf.c, a_conf.c, a_log.c: paths overhaul. + + * c_msg_ext.h, c_msg.c: fixed m_server() prototype. + +1999-02-19 Kurt Roeckx + + * packet.c/dopacket(), s_bsd.c/read_packet(): bugfix. + +1999-02-18 Christophe Kalt + + * res.c/proc_answer(): fixed T_PTR processing (problem reported by + Michal Svoboda). + + * channel.c: + * del_modeid(): bugfix when called with NULL. + * can_join(): readability (from Q). + + * s_serv.c/check_version(): + * removed code about 2.10.0[ab]*. + * never used NJOIN with 0209* servers (bugfix). + + * s_err.c: removed extraneous %s in RPL_UNIQOPIS. + +1999-02-09 Kurt Roeckx + + * hash.c/hash_find_channels(): cleanup. + + * ircd.c/main(), ircd_ext.h: various cleanups. + + * res_comp_ext.h: added prototype for ircd_getshort(). + + * s_bsd.c/read_message(): typo fix (=! -> !=). + + * s_conf.c/attach_conf(): stops detecting listen sockets as + clients from same IP address. + + * s_err.c: removed / from replies. + + * s_serv.c/m_links(): removed unused variable. + + * s_user.c/who_channel(): removed unused variables. + +1999-02-05 Christophe Kalt + + * match.c/match(): removed predictable if's (from Tero Jänkä). + + * s_serv.c/m_server_estab(): flush_connections() called once + during burst. + + * s_debug.c: updated. + + * ircd.c/io_loop(), s_bsd.c/read_message(), s_bsd_ext.h, config.h: + new logic inspired from irce, removed PREFER_SERVER. + + * s_bsd.c: + * added read_listeners(). + * set_sock_opts() now sets SO_SNDLOWAT. + * add_connection() now sends a message to client being + reject by the anti-clone crap. + + * send.c: added flush_fdary() function. + + * common_def.h, config.h, send.c: removed SENDQ_ALWAYS define, + simplified code for when it was undefined as it is only used by + the client now. + +2.10.2 + +1999-02-03 Christophe Kalt + + * mod_rfc931.c/rfc931_work(): get rid of any \n in replies. + + * a_io.c/parse_ircd(): when receiving a "DNS timeout" message, + inform ircd if we're already done (otherwise, it keeps waiting + until timeout). + + * s_bsd.c/completed_connection(): tell iauth not to wait for DNS + information for servers we connect to. + + * s_auth.c/read_iauth(): + * fixed "Garbage" notices to &AUTH. + * send E message to iauth when parsing garbage. + +1999-01-28 Christophe Kalt + + * s_serv.c/m_server_estab(): added notices to &DEBUG. + + * struct_def.h, s_auth.c: renamed MotdItem to LineItem and moved + around some defines. + + * s_bsd_ext.h: added missing ';' for utmp_open() definition. + + * channel.c/m_list(): !shortname now reports +p/+s channels (but + still hides member count and topic for +s channels). + + * match.c/match(): rearranged if test to suppress harmless read + overflow errors (reported by Insure++). + + * s_user.c/m_nick(): lp needs to be initialized (reported by Insure++). + + * hash.c/hash_find_channels(): bugfix (spottoed by Q). + + * mod_rfc931.c/rfc931_init(): fix for a silly bug (from Piotr). + +1999-01-19 Christophe Kalt + + * resolv_def.h, res_comp.c, res_init.c: updated (BIND 4.9.7-REL). + + * packet.c/dopacket(): don't call unzip_packet() without data at + beginning of connection only! (from Q). + + * numeric_def.h, s_err.c, channel.c: added numerics RPL_UNIQOPIS + (325), ERR_BANLISTFULL (478) and ERR_UNIQOPPRIVSNEEDED (485). + + * channel.c: + * m_njoin(): missing return value (reported by Insure++). + * m_mode(): use ERR_RESTRICTED for restricted clients. + * m_join(): it's now possible to create !!#foo if #foo exists. + * m_list(): now works for !shortname. + + * hash_ext.h, hash.c: added hash_find_channels(). + + * configure.in, os.h: + * update for autoconf 2.13. + * let's trust autoconf to decide to use poll() or not. + + * s_bsd.c: sendto_flags() doesn't exist, it's sendto_flag(). + + * mod_rfc931.c: + * stats weren't initialized. + * added undocumented "protocol" option (it's boring!). + + * mod_socks.c: + * fixed never occuring memory leak. + * improved stats (from Piotr Kucharski). + + * s_user_ext.h, s_user.c, s_service.c: added a parameter to + do_nick_name() [UID]. + +1999-01-12 Christophe Kalt + + * a_log_def.h, mod_pipe_ext.h, a_externs.h, mod_pipe.c, a_conf.c: + finally wrote the pipe module. + + * struct_def.h, a_conf_def.h, a_io_ext.h, iauth.c, mod_rfc931.c, + mod_socks.c, s_auth.c, s_auth_ext.h, s_misc.c: iauth now sends + statistics to ircd, shown by /stats t. + + * a_conf_def.h, a_conf.c, a_log_def.h, mod_socks.c: SOCKS module + overhaul: added caching, rewrote code to use v4 instead of v5, and + to be smarter (Based on work from Piotr Kucharski). + + * s_user.c: do_nick_name() now rejects "anonymous". + + * packet.c/dopacket(): don't call unzip_packet() without data. + + * channel.c: extension to del_modeid() from Kaspar Landsberg. + + * s_bsd.c: don't call dopacket() again for compressed links just + because the output buffer was filled up. + +1998-12-31 Christophe Kalt + + * ircd.c: removed extraneous flush_connections() call in io_loop(). + + * ircd.c, s_bsd.c, list.c, list_ext.h: removed unused 'active' code. + + * struct_def.h, parse.c: removed various unused aClient fields. + +1998-12-24 Christophe Kalt + + * s_service.c: using FLAGS_CBURST for services has too many + implications; reverted. + + * struct_def.h, s_bsd.c, s_zip.c: removed requirement for + inflate() to never fill up the uncompression output buffer, an + unlikely situation which is now dealt with. (mostly from Q). + +1998-12-21 Christophe Kalt + + + * s_user.c: + * [RFC] suppressed an error reply for notices in m_message(). + * server notices to +n channels were failing. (Reported by Q). + + * a_defines.h: INET6 fix for OSF (from Roar Thronęs). + + * os.h: INET6 fix for OSF (from Roar Thronęs). + + * channel.c: added check against 'duplicate joins' in m_njoin(). + +1998-12-14 Christophe Kalt + + * channel.c: + * yet another +a/+r fix in set_mode(). + * send_channel_modes() would occasionnally send duplicate + bans. (Reported by Robert Martin-Legene <robert@irc.ircnet.dk>) + + * iauth.c, a_io.c: added nonexistant INET6 code. + + * os.h, nameser_def.h, resolv_def.h: OSF portability fix from Roar + Thronęs. + + * s_auth.c: added missing INET6 code. (Roar Thronęs) + +1998-09-25 Christophe Kalt + + * configure.in: Check for IPv6 system type and update $LIBS (from + KIKUCHI Takahiro <kick@kyoto.wide.ad.jp>) + + * bsd.c, os.h, parse.c, struct_def.h, support.c, support_ext.h, + c_bsd.c, c_version.c, c_version_ext.h, irc.c, swear.c, channel.c, + chkconf.c, ircd.c, nameser_def.h, res.c, res_def.h, res_init.c, + resolv_def.h, s_auth.c, s_bsd.c, s_conf.c, s_debug.c, s_misc.c, + s_serv.c, s_user.c, acconfig.h, configure.in: merged 2.9.5+IPv6. + +1998-04-12 Christophe Kalt + + * configure.in, s_debug.c: vsyslog() isn't necessarely available + even if USE_STDARG is defined. (Digital Unix) + +1998-04-04 Christophe Kalt + + * c_version_ext.h, c_version.c, irc.c, swear.c: Digital Unix 4.0B + port (Roar Thronęs <roart@nvg.ntnu.no>) + +1998-12-12 Christophe Kalt + + * channel.c: +a/+r fix for !channels. + +1998-11-20 Christophe Kalt + + * irc.c: allocate me.info (fix by Helmut Franzke <hf@rp-online.de>). + +2.10.1 + +1998-11-12 Christophe Kalt + + * Doc references to @stealth.net changed to @irc.org. + + * s_serv.c: report_ping() now sends some extra info to &DEBUG. + + * s_bsd.c: send_ping() window set to 20 minutes (instead of 10), + and never close it. + +1998-11-03 Christophe Kalt + + * s_serv.c: changed m_trace() to only show unknowns to opers and + local clients. + + * a_io.c: fd remap processing bugfix (from Q@ping.be). + + * s_bsd.c: fixed ircd/iauth problem with servers ircd connects to. + +1998-10-31 Christophe Kalt + + * parse.c: reordered msgtab[]. + + * s_serv.c: added more restrictions to m_links(), m_stats() [t], + m_motd() and m_lusers() for remote clients. (*sigh*) + + * channel.c: fixed count_channels() not to count empty channels. + +1998-10-28 Christophe Kalt + + * s_user.c: optimized m_whois() (pointed out by several people). + + * s_user.c, channel.c: channel creator flag is now removed on -o. + + * channel.c: + * !channel creation is now done with !! rather than !#. + * fixed channel counters (affects /lusers & /stats z). + * m_njoin(): simple optimization. + +Sat Oct 10 18:55:38 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * a_io.c: don't TST_* if cldata[i].?fd <= 0 in loop_io(). + + * ircd.s, s_auth.c, s_bsd.c, s_bsd_ext.h: always attempt to + restart iauth in start_iauth() after receiving a SIGUSR1. + + * s_service.c: reverted part of last change. + + * s_user.c: last change introduced a bug. (typo, reported by N. Aust) + + * channel.c: fixed match_modeid() to handle remote clients + properly now that it's used from can_send(). + +Thu Oct 8 18:33:50 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * configure.in: always compile with -g flag, and never strip. + + * channel.c: + * renamed sub1_from_channel() to free_channel(). + * always send modes for empty channels during netjoin. + * fixed old (2.9.x) memory leak in collect_channel_garbage(). + + * s_id.c: + * linked list corruption bugfix in collect_chid(). + * added logic to avoid excessive caching in cache_chid(). + + * s_service.c: stdarg bugfix in check_service_butone (from O.G.). + +Sun Sep 27 15:12:53 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_user.c: prefix bugfix (reported by mrg). + +2.10.0p1 + +Fri Sep 25 22:21:06 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * channel.c: check for +r mode before calling reop_channel(). + +2.10.0 + +Wed Sep 23 19:55:14 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * configure.in, os.h: don't trust poll() to work if it exists. + + * channel.c: + * removed FULLV2_10 ifdef's + * don't send empty NJOIN in m_njoin() (Reported by Beeth). + + * channel.c, s_debug.c, config.h.dist: removed MIRC_KLUDGE. + + * chkconf.c: added warning about old V line format. + + * config.h.dist: OPER_DIE is now defined by default. + + * s_user.c: reverted last change, and hostnames are now truncated. + + * os.h: preprocessor syntax fix. + + * s_conf.c: stupid typo in match_ipmask(). + + * s_auth.c: added a new debugging notice. + + * s_debug.c: flags update. + + * ircd.c: + * added some debugging info in restart notice. + * changed strdup() in mystrdup() (from Andrew Snare). + +Sun Sep 20 15:22:25 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * os.h, configure.in: configure now checks for poll() existence to + decide if it should be used. + + * res_init.c, s_conf.c: strncpy() bugfixes (from Q). + + * s_auth.c, mod_rfc931.c: '[' is no longer allowed in ident replies. + + * channel.c: don't let chanops set +a on !channels. + + * a_io.c: (weirdbug)fix. + + * s_err.c: numeric 004 update. + + * s_user.c: connections rejected by iauth are now shown as K-lined + in &LOCAL. + + * s_bsd.c: new PASS syntax (Q). + +Sun Sep 13 20:32:08 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * config.h.dist, ircd.c: removed MYNAME. + + * Makefile.in, config.h.dist: SPATH/APATH cleanup. + + * parse.c: ABW fix (Leon Brouwers <leonb@sci.kun.nl> and purify). + +Sat Sep 12 18:53:39 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * ircd.c, s_bsd.c: SIGCHLD handling code to avoid zombies. + + * s_bsd.c: + * udpfd used in place of adfd in in read_message(). + * silently deal with linux accept() way of life. + + * a_io.c: loop_io() bugfix for select() systems. + + * ircd.c: + * me.info from ircd.conf was overridden in setup_me(). + * server_reboot() created a zombie. + + * s_user.c: allow servers to speak on channels (reported by Q). + + * channel.c: + * NJOIN bugfix related to unique ops (reported by Q). + * removed old core from msa. + + * various little cleanups. + + * res.c: buffer overflow fix. (thanks to Leon Brouwers + <leonb@sci.kun.nl> and purify) + +Tue Sep 8 21:23:27 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_user.c: user mode +a propagation bugfix. + + * ircd.c: die immediately if no listener exists after reading the conf. + + * send_ext.h, send.c, channel.c: backward compatibility fix for eI + channel modes (added sendto_match_servs_v()). + +Mon Sep 7 18:03:34 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_bsd.c: inversed test for -s in start_iauth(). + + * channel.c: + * keys starting with ':' don't propagate correctly. + * m_njoin() didn't send modes properly to clients. + + * s_serv.c: + * slightly changed the PASS syntax again. + * 2.10 alphas didn't recognize peers as such (reported by Q). + +Sun Aug 23 22:16:40 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * struct_def.h, ircd.c, list.c, list_ext.h, s_conf.c, s_serv.c, + s_service.c, s_user.c: aClient's info is now dynamically allocated + to overcome server handshake limitations. + +Sat Aug 22 15:20:10 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * channel.c: fixed ^G bug (only triggered in channel creation) + + * struct_def.h, channel.c, s_err.c, s_user.c: AWAY is back. + +Sun Aug 16 16:01:15 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * ircd.c:, s_bsd.c: added -s switch. + +Sat Aug 8 14:21:20 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_serv.c: Roger's diff broke compression. (reported by Andre Koopal) + + * Makefile.in: iauth didn't know where to find zlib.h (reported + by delta) + + * a_log.c: typos in parameter names (reported by delta). + +Fri Aug 7 23:54:10 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * mod_rfc931.c: added sanity check on replies. + +Fri Aug 7 00:03:45 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * mod_rfc931.c: read RFC 1413 and fixed the reply parser. + + * numeric_def.h, s_err.c, s_auth_ext.h, s_auth.c, s_serv.c: added + /stats a to show iauth's configuation. + + * s_auth.c, a_*.[ch], mod_*.c: + * SIGUSR2 will cause iauth to close and reopen log file(s). + * worked around delayed messages from the iauth caused by + ircd's fd remapping habit. + * reduced memory usage by dynamically allocating `inbuffer'. + * added G message (a->i). + * added E message (i->a) and cleaned up errors messages in + parse_ircd(). + * added a/A messages (a->i) to transmist configuration. + * revisited next_io() and hopefully fixed the logic. + + * ircd.c, res.c, s_auth.c, s_auth_ext.h, s_bsd.c, s_user.c: + * stdarg'ized sendto_iauth(). + * iauth is now automatically restarted. + * fixed bcopy() length in read_iauth(). + * added notices to track the "" username bug. + +Tue Aug 4 21:43:53 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * a_io.c: numerous bug fixes.. + + * mod_rfc931.c: fix to prevent crash when receiving data from + broken ident servers. + + * a_conf.c, a_conf_def.h, a_externs.h, a_log_def.h: added module + `socks'. (Based on a 2.9.5 diff from Jonathan Chapman) + + * a_log.c: added timestamps to `auth' log. + + * s_misc.c: EXITC_AREF is a special case like EXITC_REF. + + * parse.c: penalty bugfix. + + * ircd.c, s_auth.c, s_bsd.c, s_bsd_ext.h: + * cleaned up iauth startup procedure, added start_iauth() + which is called upon SIGUSR1. + * various fixes in read_iauth(). + +Sun Aug 2 18:34:20 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_mist_ext.h, s_misc.c, support_ext.h, support.c: moved + myctime() from s_misc.c to support.c. + + * s_bsd.c, a_io.c: added `R' message from ircd to iauth. + + * s_serv.c: updated check_version() not to use NJOIN with 2.9.5 links. + + * parse.c: restricted SQUERY to users. + + * channel.c: + * m_njoin(): conversion bugfix (Reported by Q). + * added FULLV2_10 #if's. + + * struct_def.h, channel.c, s_err.c, s_misc.c: added channel mode `r'. + + * send.c: reference to NULL pointer in sendto_match_servs() + (Reported by Core). + + * sys_def.c, chkconf.c: MyFree() redefinitions (from Core). + + * Makefile.in: "make install-server" path problems. + +Sun Jul 19 15:32:48 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_conf.c, ircd.c: unitialized K line comment in check_pings(). + + * channel.c: + * beI modes to multiple channels were corrupted. + * mode parameters starting with : don't propagate correctly. + * !channel creation propagation was broken (reported by Eumel). + + * send.c, struct_def.h, channel.s, res.c, ircd.c, s_auth.c, + s_auth_ext.h, s_bsd.c, s_bsd_ext.h, s_conf.c, s_user.c, + Makefile.in, config.h.dist: added iauth. + +Fri Jun 12 19:00:03 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * ircd.c: fix for inetd support (from Jonathan Chapman + <jonathan@clover.net>). + + * parse.c, s_debug.c: more LOCOP_* fixes (from Michael Neumayer). + + * s_user.c: oper counter bugfix (from Magnus Tjernstrom). + + * channel.c: + * fixed join #a,#b,.. desynch bug (reported by viha@vip.fi). + * fixed netjoin +p/+s desynch problem (same). + +Sun May 31 14:18:41 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * send.c, channel.c: '-' leftovers (Michael Neumayer <eumel@42.org>). + +Mon May 25 15:13:51 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * struct_def.h, channel.c, hash.c, s_misc.c: changed new channels + prefix to ! (instead of -). + + * parse.c: undefining LOCOP_* had no effect (reported by Eumel). + + * s_service.c: SERVICE_WANT_OPER burst fix (from Jonathan Chapman). + + * s_bsd.c: SO_LINGER patch (from Andrew Snare <ajs@pigpond.com>). + + * configure.in: better logic for --resconf. + + * channel.c: + * m_invite() fix for &channels. + * add_modeid() always used RPL_BANLIST. + * bIe modes coming from a server were rejected + add_modeid() if another mode with the same pattern existed. + + * c_debug_ext.h, c_debug.c, chkconf.c, s_misc.c, s_zip.c: fixes + for DEBUGMODE (from Andrew Snare <ajs@pigpond.com> & Magnus + Tjernstrom <d92-mtm@ludd.luth.se>) + + * hash.c: bigger_prime() useless optimization from Magnus :-) + +Tue May 5 19:26:25 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * config.h.dist, Makefile.in, struct_def.h, s_externs.h, send.c, + channel.c, hash.c, s_debug.c, s_err.c, s_misc.c, s_serv.c, + s_user.c: implemented new channels. + + * struct_def.h, parse.c, channel.c, ircd.c, s_debug.c, s_misc.c, + s_serv.c, s_user.c, whowas.c, config.h.dist: replaced BIG_NET #define. + +Fri Apr 24 20:30:21 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * irc.c: missing refresh() (from Dave Hill <ddhill@zk3.dec.com>). + + * s_conf.c, s_service.c: portability fixes from Avalon. + + * channel.c, s_user.c: adapted undernet's Bquiet. + +Sun Apr 5 17:50:08 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * configure, configure.in, config.h.dist: added --logdir option. + + * s_serv.c: + * moved user wallops from #wallops to +wallops. + * stricter m_server() check for unregistered users. + + * send.c: wallops were sent to services and unregistered clients. + +Sat Apr 4 19:05:26 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * struct_def.h, packet.c, s_bsd.c: (never triggered) link + compression bugfix (Roger Espel Llima <espel@llaic.u-clermont1.fr>). + + * config.h.dist, ircd.c, s_debug.c: added PREFER_SERVER #define. + + * s_user.c: + * m_oper() notice bug fix (Michael 'Eumel' Neumayer). + * completely disabled AWAY. + + * struct_def.h, parse.c, channel.c, ircd.c, s_debug.c, s_misc.c, + s_serv.c, s_user.c, whowas.c, config.h.dist: added BIG_NET #define. + + * s_misc.c; Y2K fix. + +Tue Mar 31 18:52:41 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * s_serv.c: removed now obsolete USE_NJOIN. + + * numeric_def.h, struct_def.h, channel.c, s_debug.c, s_err.c, + s_serv.c: added channel modes +e (EFnet's exceptions to bans) and + +I (invitations); raised MAXBANS (should be renamed) to 30. + + * support.c: extended make_version(). + + * channel.c: + * notify user when a ban is rejected because "redundant". + * /invite (from chanop) now overrides bans & limit. + + * s_debug.c, s_serv.c: /stats r no longer restricted to DEBUGMODE. + + * s_bsd.c: getrlimit()/setrlimit() is now used regardless of + poll() availibility. + +Sun Mar 22 14:01:24 1998 Christophe Kalt <kalt@millennium.stealth.net> + + * channel.c: MIRC_KLUDGE sent bogus modes on channel creation. + + * os.h, support.c, s_bsd.c: CYGWIN32 cleanup from Dave Miller. + + * s_user.c: hunt_server() cleanup. + + * s_conf.c: match_ipmask() choked on a.b.c.d/z (reported by Helmut + Springer <delta@RUS.Uni-Stuttgart.DE>). + +2.9.5 + +Tue Feb 17 21:25:02 1998 Christophe Kalt + + * s_bsd.c: w32 doesn't have a working fork(). + + * ircd.c: deal with "getpwuid(getuid())" returning NULL. + + * configure.in, os.h, support.c: use our own truncate() when + needed (CYGWIN32), and CYGWIN32 portability. (Thanks to Dave + Miller <yahoo@molalla.net>). + + * config.guess: update. + + * s_user.c: broadcast restriction wasn't right (Yegg). + + * send.c, ircd.c: removed noisy debugging notices. + +Sat Feb 7 09:21:52 1998 Christophe Kalt + + * s_user.c: + * oper log is now more verbose. + * broadcast messages/notices are now less restricted. + + * hash.c: nitpicking (from Magnus Tjernstrom). + + * configure.in: quoting cleanup (from Alain). + + * send_ext.h, s_debug.h: STDARG prototyping cleanup (from Alain). + +Fri Jan 23 17:39:17 1998 Christophe Kalt + + * os.h: linux 2.1 implements poll() but the header files are a + mess (what did you expect?), kludge to get it work (from Vesa). + + * channel.c: fixes related to MIRC_KLUDGE. + + * s_conf.c: + * find_kill() fix and cleanup (mostly from Vesa). + * find_bounce() stricter check and fix (from Vesa). + + * parse.c: m_njoin() is only used by the server. + +Fri Jan 23 17:38:36 1998 Christophe Kalt + + * channel.c: + * buffer overflow fix. + * bugfix from Avalon. + * join/invite were propagated for &channels. (reported by DLR) + * invite/kick were propagated beyond masks. (reported by DLR) + * multiple kicks could desynch channels. + + * s_user.c: stricter check on unregistered NICK changes (Avalon). + + * hash.c: hash_find_server() didn't handle z.stealth.net (1 + letter) masked by *.stealth.net (DLR). + + * msg_def.h, struct_def.h, channel_ext.h, parse.c, channel.c, + s_serv.c: added send_channel_members() and m_njoin(). + + * send_ext.h, send.c: added sendto_serv_notv(). + + * buidm4: yet another m4 booboo. (fix from Mario) + +Wed Jan 7 11:40:59 1998 Christophe Kalt + + * s_user.c: strncpy() lameness. + + * s_conf.c: added match_ipmask() (from Vesa). + + * configure.in, send_ext.h: "checking for working stdarg" always + failed because of a quoting problem. + +Thu Dec 18 21:48:18 1997 Christophe Kalt + + * channel.c: abusive usage of /names now forbidden. + + * class.c: imposed a minimum of 60 seconds for connect frequencies. + + * struct_def.h, s_misc.c, s_serv.c: check_link() tuning and statistics. + +Tue Dec 16 17:12:16 1997 Christophe Kalt + + * s_conf.c: finished D lines. + + * numeric_def.h, struct_def.h, list.c, s_err.c, s_serv.c: added + check_link() to prevent server links from being flooded by replies + to user requests. + + * s_bsd.c: try to prevent the server from flooding with UDP pings. + + * channel.c: #foo:*.tld modes were always sent during the burst. + +Wed Nov 12 21:02:15 1997 Christophe Kalt + + * struct_def.h, s_conf_ext.h, s_conf.c, ircd.c, chkconf.c, + numeric_def.h, s_err.c , s_serv.c: added D configuration + lines. (/stats h) + + * send.c, s_service.c: allocate more dbufs during a service burst + if needed. + + * channel.c: cosmetics, and fixed the use of MAXPENALTY in m_kick(). + + * s_debug.c: too many parameters in a call to sendto_one(). + +2.9.4 + +Sat Oct 18 09:37:33 1997 Christophe Kalt + + * setup.h.in, configure.in: (Alain Nissen) + * additional header files checked. + * non-blocking system test fixed. + + * os.h: curses/termcap stuff is now only used for the client (AN). + + * swear_ext.h, swear.c: portability issues (Alain Nissen). + + * c_bsd.c, s_bsd.c, os.h: SELECT_FDSET_TYPE (defined in os.h) used + as pointer type in select() calls; HPUX compilation problem + fixed. (Alain Nissen) + + * buildm4: typo & missing quote. (again!) + +Fri Oct 10 23:48:25 1997 Christophe Kalt + + * s_serv.c: improved m_die() and m_restart() in case a service is + used for user log. + + * os.h, acconfig.h, configure.in, res.c, s_bsd.c: (Alain Nissen) + * kludge to deal with broken hostent declaration in + netdb.h on some linux systems. + * test for sigaction & sigset functions added back; signal + implementation test fixed. + + * s_conf.c: + * more explicit K line message when reason specified in + ircd.conf. + * extended I lines syntax. + + * s_service_ext.h, s_service.c, s_misc.c: faster split handling is + possible now that 2.8.x protocol is history. + + * channel.c: + * m_join() was unefficient on net joins. + * MIRC_KLUDGE would never show +ov modes. + + * s_user.c: + * services can now send to channels (if the modes allow it). + * prefixes for restricted connections were gone. + + * buildm4: missing quote. + +2.9.4b + +Wed Oct 1 21:57:45 1997 Christophe Kalt + + * chkconf.c: added knowledge of B lines. + + * s_debug.c: more info on dbufs for better tuning. + + * channel.c: bans on IP are now matched against resolving clients. + + * s_conf.c: K lines on IP can now be matched against resolving clients. + + * buildm4: update for Y and K line macros, and added macros for + B,V,i and k lines (Mario Holbe). + + * s_conf.c: Y global limit per host didn't work. + +Wed Sep 24 18:25:45 1997 Christophe Kalt + + * acconfig.h, configure.in, setup.h.in, resolv_def.h, res_init.c: + added --resconf=FILE option to configure (Alain Nissen). + + * s_conf.c: fixed bug with Y limits. + +Tue Sep 23 11:36:30 1997 Christophe Kalt + + * common_def.h: added CHKCONF_COMPILE statement. + + * bsd_ext.h: incorrect declaration for writeb. + + * support_ext.h, support.c: dumpcore() was broken. + + * class_def.h, class_ext.h, class.c, s_conf.c, s_err.c: it's now + possible to combine a limit per host and per user@host for the + same class. + + * s_user.c: + * RPL_ENDOFWHO wasn't correct. + * who_find() / m_whois() didn't always respect +a mode. + * @ restriction in username could be bypassed. + * unlikely but nonetheless possible ghost generation. + + * ircd.c: setgid() was called after setuid() (reported by Nicole + Haywood <kole@mail.usyd.edu.au>) + + * parse.c: avoid a match() call if possible. + +Sun Sep 14 19:44:27 1997 Christophe Kalt + + * ircd.c: redundant/useless code commented out. + + * struct_def.h, parse.c, s_err.c, s_serv.c: `stats m' is more verbose. + + * os.h, Makefile.in: zlib.h was missing from includes. + + * s_user.c: 2 fixes (a NULL pointer, and a non reinitialized one). + +Thu Sep 11 21:43:20 1997 Christophe Kalt + + * class_def.h, class_ext.h, class.c, s_bsd.c, s_conf.c, s_err.c, + s_user.c: added 2 fields to Y lines and implemented [u@]h global + limits. + + * service_def.h, channel.c, s_service.c: added SERVICE_WANT_VCHANNEL. + + * channel.c: server channels now have a topic. + + * s_conf.c: negative class numbers are now forbidden. + + * s_conf_ext.h, s_conf.c, s_bsd.c: new B lines format. + +Sun Sep 7 20:02:50 1997 Christophe Kalt + + * s_conf.c: B lines now catch "unauthorized connections". + + * s_user.c: m_who() limit wasn't coded. fixed this and rewrote + m_who() because recursivity and penalty don't go together. + + * s_err.c: REPL_SERVLIST type field is now in hexa. + + * service_def.h, send.c, s_misc.c, s_user.c: extended services + capabilities so they can do logging. + + * s_serv.c, s_user.c: added MD5 support for crypt() (from Urvos Juvan). + + * res.c: hostnames containing * or ? are now rejected. + + * s_conf.c: service type field stripped from optional bits (in S + lines). + + * s_serv.c: server token wasn't sent to services in m_server_estab(). + + * s_service.c: SERVICE_WANT_PREFIX wasn't honored by m_squery(). + + * struct_def.h, parse.c, s_serv.c, s_user.c: + * added MyService() macro and updated several tests. + * next_client() was ignoring services. + +Tue Aug 19 08:38:54 1997 Christophe Kalt + + * channel.c: m_names() could still have a truncated reply. + + * more cleaning from Alain.Nissen@ulg.ac.be: + + * struct_def.h, bsd.c, s_bsd.c: removed references to "pyr". + * res_comp.c: removed res_getshort() [never used]. + * removed all references to VMS. + +Mon Aug 11 13:34:15 1997 Christophe Kalt + + * The following changes are from Alain.Nissen@ulg.ac.be + + * all files (in short): + * include/ was removed. + * all .c have a corresponding _ext.h to declare external + variables and functions. + * [sc]_externs.h are #includes *_ext.h. + * [sc]_defines.h are #includes *_def.h. + * all .c have the same list of #include. + * os.h has all system #includes and portability tests. + + * Also, several bug and portability fixes: + + * c_bsd.c: move renamed in tcap_move (portability). + * c_msg.c: + * added test on DOCURSES before including it. + * various casts. + * edit.c: + * return type of suspend_irc() changed to RETSIGTYPE. + * added int argument to suspend_irc(). + * use of signal(SIGTSTP,...) now depends on + whether the signal exists rather than the OS. + * help.c: helplist rewritten properly. + * irc.c: + * strdup() replaced with mystrdup(). + * do_log() takes 2 arguments. + * return type of quit_intr() changed to RETSIGTYPE. + * added int argument to quit_intr(). + * screen.c: such a mess + * LINES is only present under curses. + * idem for refresh(). + * clear_to_eol() is supposed to take 2 arguments, + but what are they? + * swear.c: added to clients targets + * channel.c: delch renamed in del_ch. + * chkconf.c, parse.c: newline renamed in irc_newline. + * ircd.c: s_monitor(), s_die(), s_rehash(), s_restart() + return type changed from VOIDSIG to RETSIGTYPE. + * res.c: now using SOCK_LEN_TYPE. + * res_comp.c, res_init.c: various portability changes. + * s_auth.c: now using SOCK_LEN_TYPE. + * s_bsd.c: now using SOCK_LEN_TYPE. + * s_conf.c: several portability fixes. + * s_err.c: local_replies[] and local_replies[] rewritten. + * s_service.c: changed test on USE_STDARG. + * bsd.c: + * return type for dummy() is now RETSIGTYPE. + * dummy() now takes one int argument. + * dbuf.c: removed unused DBUF_INIT. + * support.c: + * many changes concerning #if tests. + * added solaris_gethostbyname() to use instead of + Solaris 2.3 broken gethostbyname(). + * added irc_memcmp() to use if system's memcmp() + is broken. + * nameser.h: now using WORDS_BIGENDIAN. + * configure.in: + * simpler solaris 2.x detection when looking for zlib. + * added test for cursesX. + * added check for sys_errlist definition in sys/errno.h + * and more... + * Makefile.in: CFLAGS split in S_CFLAGS, C_CFLAGS and + CC_CFLAGS (ircd, irc, chkconf). + +Fri Aug 8 10:51:24 1997 Christophe Kalt + + * channel.c: m_names() behaviour wasn't consistent with m_who() + concerning +p channels (Michael 'Eumel' Neumayer). + + * configure.in: minor changes (Alain Nissen). + + * s_user.c: missing argument to err_str() (Kai Seidler). + + * config.h.dist, h.h, struct.h, common.c, channel.c, s_bsd.c, + s_debug.c, s_err.c, s_misc.c, s_serv.c, s_service.c, s_user.c: + removed support for 2.8 protocol. + + * config.h.dist, msg.h, channel.c, note.c, s_bsd.c, s_debug.c, + s_misd.c, s_user.c: removed NOTE. + + * s_bsd.c: wrong argument to bzero(). + + * Makefile.in, buildm4: rev.sh replaced by config.guess and + buildm4 wasn't ran by `make install-server'. + +2.9.3 + +Wed Jul 23 11:23:30 1997 Christophe Kalt + + * res.c: queries were never resent when reaching timeout (C. Behrens). + + * acconfig.h, configure.in: better sys_errlist test (A. Nissen). + + * version.c.SH.in: portability (A. Nissen). + + * acconfig.h, configure.in, common.h, config.h.dist: AIX cleanup + and optimization flags (A. Nissen). + + * configure.in: typo. + +Thu Jul 17 23:04:48 1997 Christophe Kalt + + * c_numeric.c, irc.c: fixes from Vesa. + + * send.c: buffer overflow fix. + + * h.h, res_init.c: portability fixes. + +Wed Jul 16 21:35:50 1997 Christophe Kalt + + * s_serv.c: m_die() referenced data after freeing it. + + * support.c, res.c: silly changes to make purify happier. + + * s_bsd.c: fixed memory corruption problem. + + * s_user.c: m_whois() voice flag changed back to + (from !). + + * h.h, support.c, configure.in: reverted back: use inet_* if + present, use our own inet* if not. Our functions must be + different to avoid some crazy clash when bind 8.x is on installed + the system. Should we teach configure.in about -lbind? + +Tue Jul 15 00:18:01 1997 Christophe Kalt + + * inet_addr.c moved to support.c, renamed functions (inet_addr, + inet_aton, inet_ntoa, inet_netof) to avoid clashes; always used + even if the system has it. + + * New configure and Makefile from Alain Nissen. (many many files + changed, removed, created, rewritten) + + * buildm4: update (Mario Holbe). + + * struct.h, s_bsd.c: fixed the P line rehash bug(?). + + * h.h, ircd.c: let's be nice to SunOS' cc. + +Mon Jun 30 21:41:11 1997 Christophe Kalt + + * dbuf.c, send.c: earlier changes broke the client. + + * config.h.dist, struct.h, dbuf.h, dbuf.c: new magic formula to + compute BUFFERPOOL. Added MAXSERVERS for this purpose. + + * s_serv.c: buffer overflow (Chris Behrens). + +Thu Jun 26 19:18:24 1997 Christophe Kalt + + * struct.h, channel.c, hash.c, parse.c, send.c, s_misc.c, + s_service.c: + * cleanup. + * added &SERVICES. + + * s_bsd.c: wrong buffer size given to getsockopt(). + +Thu Jun 19 18:35:37 1997 Christophe Kalt + + * h.h, struct.h, s_debug.c, send.c, dbuf.c: + * dbuf stats. + * send_message() #ifndef SENDQ_ALWAYS was not uptodate, + tried to bring it back up to date. + + * res.c: fixed possible buffer overflow. + + * h.h, s_debug.c, send.c: fixes for STDARG (Olivier Galibert) + + * ircd.c: server_reboot() would crash when called because of "out + of memory". + +Mon Jun 9 20:49:55 1997 Christophe Kalt + + * config.h.dist, h.h, struct.h, send.c, ircd.c, list.c, s_debug.c, + s_serv.c, s_user.c: removed #define KRYS, it is now always `defined'. + + * config.h.dist, h.h, common.h, service.h, sys.h, configure.in, + send.c, support.c, s_auth.c, s_service.c, s_debug.c, s_conf.c: + removed references to varargs, added support for stdargs. + It is controlled by #define USE_STDARG set by configure. (adapted + from Olivier Galibert) + + * ircd.c: CHROOT is really called CHROOTDIR. + + * s_user.c: + * extended m_message() to accept n!u@h as recipient. + * removed notice for bogus PONG. + + * s_serv.c: /SQUIT now requires 2 arguments from opers. + +Sun Jun 1 16:57:39 1997 Christophe Kalt + + * dbuf.h, dbuf.c: #define DBUF_TAIL is back. + + * s_conf.c: fixed B lines behaviour, port number is now mandatory. + + * send.c: missing arg to dead_link(). (Olivier Galibert) + + * s_serv.c, numeric.h, s_err.c: added /stats B to see B lines (and + fixed /stats V reply). + + * service.h, channel.c, s_misc.c, s_service.c, s_serv.c, s_user.c: + * numerous bugfixes related to local services (if + USE_SERVICES is defined). + * extended services option to allow 2.9 NICK syntax, and + let them see tokens if they want. (adapted from O.Galibert) + +Wed May 21 21:17:51 1997 Christophe Kalt + + * channel.c, s_service.c, service.h: finished service code (whee). + + * s_serv.c: services were incorrectly sent during burst. + + * s_bsd.c: ident MUST be done before anything else is read from a + client. + +Thu May 15 16:27:13 1997 Christophe Kalt + + * struct.h, s_conf.h, s_serv.c: created k: lines to be able to + deny access based on OTHER ident replies. + + * s_user.c: changed 001 reply to return n!u@h (more zen). + + * s_serv.c: + * if A: is bogus, trash it and complain instead of crashing. + * get_client_name() is non-reentrant. *sigh* + +Wed May 7 22:11:04 1997 Christophe Kalt + + * s_user.c: nick chasing kill bug fix. (Chris Behrens) + + * h.h, ircd.c, s_conf.c, s_user.c: K-lined users now exit + displaying the Kline comment, if any. + + * s_conf.c: fixed notice ERR_YOUWILLBEBANNED, and don't disconnect + then. + + * inet.h, nameser.h, resolv.h, inet_addr.c, portability.h, res.c, + res_comp.c, res_init.c, res_mkquery.c: updated. (BIND 4.9.5-P1) + + * channel.c: notice for service could use free'ed memory. + +Sun Apr 27 16:40:08 1997 Christophe Kalt + + * send.c: fixed couple buglets (added by Chris Behrens :^). + + * s_user.c: removed dummy m_note() which was unused and buggy, and + would let any oper _broadcast_ NOTE queries to the net. + + * m_note.c: Modified m_note() in note.c not to send any NOTE + commands to other servers. + + This is lame, someone help me and port note to be a service. + Then, I'll finally take it out of the server !! :-) + +Thu Apr 24 18:51:25 1997 Christophe Kalt + + * send.c: better (faster) sendto_common_channel() (from Chris Behrens). + + * s_serv.c: fixed connected burst for services with hostmasks. + + * s_user.c: fixed origin check in m_pong(). + + * res.c: added a check on hostnames. (From Darren Reed) + +Sun Apr 20 20:30:21 1997 Christophe Kalt + + * s_conf.c: find_bounce() had an inversed test. (how could it work + when I tested it??) + + * s_serv.c: SERVER message would occasionnally (and incorrectly) + be dropped. + + * s_misc.c: simple optimization in exit_client(). + + * s_service.c, s_serv.c: things looked wrong, SERVICE syntax + inchorent. Minor memory leak. + + * s_bsd.c, s_misc.c: various "typos" fixed. (UDP & non POLL) + + * send.c, h.h: removed sendto_all_butone(). (unused) + +Tue Apr 15 19:41:32 1997 Christophe Kalt + + * sock.h: added a check to make sure FD_SETSIZE is big enough. + + * s_bsd.c, struct.h, s_misc.c: added more UDP stats. + + * s_bsd.c: fixed udp_pfd/res_pfd mess, and cleaned the code. (whee) + + * h.h, struct.h, numeric.h, s_err.c, s_conf.c, s_bsd.c: added B lines. + + * channel.c: defining USE_SERVICE would cause buffer corruption + when propagating channel modes to servers. (Found by Michael Neumayer) + +Wed Apr 2 15:25:54 1997 Christophe Kalt + + * list.c, s_serv.c: added some error notices for users without server. + + * s_bsd.c: fixed UDP port binding when no IP is given. + + * configure.in: add -cckr to CFLAGS on SGI when using cc(1) + +Thu Mar 27 19:03:09 1997 Christophe Kalt + + * h.h, send.c, s_bsd.c, s_user.c, s_serv.c: amount of transferred + data added to file logs. + + * config.h.dist: define SVR4 if __svr4__ is there. + + * packet.c: drop server sending an unknown command. + + * s_user.c: changed m_who() for better performance (from Chris + Behrens), also put a limit on its number of arguments. + + * h.h, struct.h, list.c: better IsMember (from Chris Behrens). + + * s_serv.c: don't let a user introduce a new server. + +Fri Mar 21 19:53:36 1997 Christophe Kalt + + * h.h, struct.h, ircd.c, s_conf.c, s_misc.c, s_serv.c, + config.h.dist: server can now cache the MOTD in memory (from Chris + Behrens). See CACHED_MOTD #define. + + * service.h, channel.c, s_serv.c, s_service.c, s_user.c: additions + for services. + + * s_misc.c: added missing parameter for check_service_butone(). + + * INSTALL completed and converted to sgml + + * s_serv.c: MyRealloc(NULL, size) isn't portable. + +Tue Mar 18 17:59:26 1997 Christophe Kalt + + * 2.9.3b10 + + * channel.c, hash.c, res.c, s_serv.c, s_service.c, s_user.c, + whowas.c: penalties tuned again. (added Volker Paulsen's anti SPAM + hack). + + * s_err.c, s_serv.c: minor changes to RPL_STATS* + + * s_bsd.c: authclnts[] was not always initialized. + + * ircd.c: buffer in ircd_readtune() lacked initialization. + + * s_service.c: fixed buffer overflow. + + * send.c, support.c: # of arguments cleanup. + + * list.c, res.c, s_service.c: casts to suppress warnings. + + * h.h, dbuf.c: bufalloc, dbufblocks, poolsize now + unsigned. (some checks might be needed, poolsize can really get + big). + + * s_misc.c: removed duplicate code in exit_client(). + + * parse.c: + + * Added more notices when generating SQUITs for unknown + servers. + * removed bogus else. + +Fri Feb 28 09:34:36 1997 Christophe Kalt + + * s_err.c, s_serv.c: Added 2 more fields to RPL_TRACELINK. + +Thu Feb 27 14:50:37 1997 Christophe Kalt + + * s_serv.c: /connect by servername didn't work for c lines (from Eumel) + +Wed Feb 26 16:48:36 1997 Christophe Kalt + + * s_bsd.c: removed (old) redundant code concerning VIF. + + * config.h.dist: CLONE_MAX and CLONE_PERIOD could be undefined. + + * common.c: match() cleanup. + +Thu Feb 13 17:27:53 1997 Christophe Kalt + + * res.c, res_init.c, res_mkquery.c, ircd.c, s_bsd.c: renamed + res_init() to ircd_res_init() to avoid conflict (ULTRIX). + + * hash.c, struct.c: cleanup of hashing functions. + + * match.c, parse.c, send.c, common.h, channel.c, hash.c, s_bsd.c, + s_misc.c, s_serv.c, s_service.c, s_user.c, note.c, ignore.c: + + * _match() changed to match() and the check for maximum + "recursion" slightly changed. + * match() and matches() removed (stubs from when match + was recursive?). + * All occurrences of matches() changed to match(). + * this saves one function call per match. + + * send.c: Added 2 parameters to sendto_serv_butone(). + + * s_err.c, s_serv.c: Added one field to RPL_TRACELINK. + +Sun Jan 26 20:02:34 EET 1997 Vesa Ruokonen (ruokonen@aapo.it.lut.fi) + + * 2.9.3b8 + + * support.c, h.h, list.c: gcc -Wall cleanups. + * h.h, struct.h, chkconf.c, s_conf.c, s_serv.c: + created V:lines for checking connecting client parameters. + passed as PASS command parameters. A matching V:line. + refuses the connection (version number & compile flags). + * struct.h, channel.c, s_debug.c: + penalty threshold used for limiting KICK params. + * struct.h: initial QUEUELEN calculation tuned. (->BUFFERPOOL). + * c_msg.c: more verbose m_pong(). + * channel.c, s_serv.c, s_user.c, whowas.c: + penalties tuned for commands generating global bcast. + * hash.c: converted multiplication to hashtable lookup to speed. + up function calls. (from Core) + * ircd.c, s_bsd.c: added truncation for non-appended writes. (_root_) + * s_user.c: prefix for voice capability in channel list of WHOIS reply + changed from '+' to '!'. + * s_user.c: drop PONGs with bad origin. + store connection parameters from PASS temporarily to info + field in contstant locations. + * s_user.c: m_umode() fixed (from Core). + +Wed Jan 15 14:42:43 1997 Christophe Kalt + + * s_bsd.c: + + * mysk was initialized by empty password in M line. + +Tue Jan 14 24:62:34 EET 1997 Vesa Ruokonen (ruokonen@aapo.it.lut.fi) + + * parse.c, channel.c, s_user.c: cleanup of find_functions(), + _nickserv replaced by _service. + * h.h, : setup_ping() takes aConfItem pointer as parameter now. + * sys.h: #elif expanded to #else #if for compability + * s_bsd.c: inetport(P:line) changed to support VIFs better. + More info about listening ports into /stats l. + UDP ping is initialized from M:line, not anymore from P:line. + * s_numeric.c: cleanups in numeric processing. + * Makefile.in, Makefile.irc, Makefile.ircd: makedepend fix + * configure.in: zlib check moved to end, as it can interfere + other checks when libs aren't in default paths. + +Mon Jan 13 09:11:04 1997 Christophe Kalt + + * ircd.c: + + * made the display of version (flag -v) more verbose. + + * regenerated configure (with autoconf 2.12; thanks digital). + + * s_user.c: + + * fixed, and extended KILL reasons for `standard' + collisions. (both victims u@h are now shown). + + * send.c: + + * fixed the logic when sending mass message/notice to a + server mask. + + * configure.in, Makefile.in: + + * fixed detection & use of zlib using the environment + variable ZLIB_HOME (from Vesa). + +Thu Jan 9 13:09:36 1997 Christophe Kalt + + * struct.h, ircd.c: + + * added -b command line switch to let the server start + even if the ircd.tune file is corrupted (mostly from + Magnus Tjernstrom). + + * s_conf.c: + + * udp listen was setup even if port was defined to be 0. + +Wed Jan 8 12:35:03 1997 Christophe Kalt + + * h.h, s_bsd.c, s_conf.c: + + * port field in M configuration line is used again, now to + define on which port the server will listen for UDP pings. + + * hash.c: + + * restricted commands to opers (from Vesa). + + * send.c: + + * sendto_match_butone() had a broken behaviour, + brought back the old (2.8.21) behaviour. + + * s_bsd.c: + + * fixed negociation of compression for outgoing + connections. + + * moved the "rejected connection" notice to &LOCAL. + + * SLOW_ACCEPT #ifdef's changed to #ifndef's to get what + one should expect from the define name ! + + * made inetport() more readable, and added check on empty + string parameter (from Vesa). + + * highfd isn't defined when _DO_POLL_ is defined, so don't + use it in debug notices (from Vesa). + + * break changed to continue because ??? (from Vesa). + + * s_user.c: + + * fixed KILL notice sent on nick collision (was using + ident reply for remote clients). + + * allowed oper!user@host.foo to send global message/notice + to #*.foo + + * s_serv.c, s_user.c, s_bsd.c, s_debug.c: + + * changed the PASS command semantic (from Vesa). + +Fri Jan 3 14:47:52 1997 Christophe Kalt + + * s_bsd.c: + + * completed virtual hosts support (M line). + + * config.h.dist: + + * AIX has poll(), use it. + +Mon Dec 30 15:08:20 1996 Christophe Kalt + + * s_bsd.c, h.h: + + * added support for virtual hosts (P line). + +Wed Dec 18 12:08:29 1996 Christophe Kalt + + * bsd.c: + + * fixed read_message() bugs resulting from the merge. + + * channel.c: + + * limited the number of possible kicks to MAXMODEPARAMS. + +Mon Dec 16 09:36:54 1996 Christophe Kalt + + * list.c: + + * don't free serv->user too early. + + * removed duplicated(?) away memory count. + +Fri Dec 13 10:28:43 1996 Christophe Kalt - Hmm, Friday the 13th! + + * config.h.dist, s_auth.c, s_user.c, s_debug.c: + + * minor tuning. + +Thu Dec 12 10:34:47 1996 Christophe Kalt + + * struct.h, s_auth.c, s_debug.c: + + * added memory usage stats for ident replies. + + * send.c, s_auth.c, s_misc.c: + + * fixed boundaries problems with long ident replies. + +Wed Dec 11 17:42:29 1996 Christophe Kalt + + * struct.h, send.c, s_auth.c, s_bsd.c, list.c, s_conf.c, s_misc.c, + s_user.c: + + * added auth field to struct Client to eventually store + long `OTHER' ident replies. It is only used in logs, and + notices (not in matches against configuration lines). + + * config.h.dist: + + * added #define SLOW_ACCEPT (default). + + * added #define CLONE_CHECK (default). + + * s_bsd.c: + + * fixed config line reference counter. + + * added CLONE_CHECK code (check_clones() from + pgoncalves@mail.telepac.pt (Pedro Goncalves)). + + * added SLOW_ACCEPT (previous behaviour) code. + + * merged the 2 versions of read_message(), fixing some + (buggy) difference between them. + + * merged two for() in read_message(). + + +Mon Dec 2 11:02:54 1996 Christophe Kalt + + * s_user.c: + + * changed error notice + + * send.c: + + * #*.mask messages now propagated to other servers. + + * s_service.c: + + * added missing else. + + * config.h.dist, s_debug.c, channel.c: + + * removed all references to V28PlusOnly + * made NoV28Link defined by default + +Wed Nov 27 18:09:42 1996 Christophe Kalt + + * struct.h, class.c, ircd.c, s_bsd.c, s_conf.c, s_serv.c: + + * added lowercase c config line + +Tue Oct 1 22:29:31 1996 Christophe Kalt + + * added config.h to dependancies in Makefile.ircd + + * config.h.dist, h.h, struct.h, packet.c, send.c, ircd.c, s_bsd.c, + s_debug.c, s_serv.c, s_user.c, s_err.c, list.c, Makefile.ircd, + configure.in: + + * added #define ZIP_LINKS and s_zip.c. + * made configure look for the zlib (-lgz). + * implemented server-server zlib compression. diff --git a/doc/Etiquette b/doc/Etiquette new file mode 100644 index 0000000..b531954 --- /dev/null +++ b/doc/Etiquette @@ -0,0 +1,84 @@ +/************************************************************************ + * IRC - Internet Relay Chat, doc/etiquette + * Copyright (C) 1990, Lea Viljanen and Ari Husa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +HOW TO BEHAVE ON IRC + +Authors: Lea Viljanen (LadyBug) viljanen@kreeta.helsinki.fi + Ari Husa (luru) so-luru@tolsun.oulu.fi +Revised, March 1994: Helen Rose (Trillian) hrose@kei.com + +1) Language + + The most widely understood and spoken language on IRC is English. +However! As IRC is used in many different countries, English is by +no means the only language. If you want to speak some other language +than English (for example with your friends), go to a separate channel +and set the topic (with /topic) to indicate that. For example + /topic #channelname Finnish only! +would mean that this channel would be reserved for Finnish discussion. +On the other hand, you should check the topic (with /list command) +before you move to a channel to see if there are any restrictions about +language. + On a channel not restricted by /topic, please speak a language +everybody can understand. If you want to do otherwise, change channels +and set the topic accordingly. + + +2) Hello/Goodbye + + It's not necessary to greet everybody on a channel personally. +Usually one "Hello" or equivalent is enough. And don't expect everybody +to greet you back. On a channel with 20 people that would mean one +screenful of hellos. It's sensible not to greet, in order not to be rude +to the rest of the channel. If you must say hello, do it with a private /msg. +The same applies to goodbyes. + + +3) Discussion + + When you come to a new channel it's advised you to listen +for a while to get an impression of what's discussed. Please feel free +to join in, but do not try to force your topic into the discussion +if that doesn't come naturally. + + +4) {}|[]\ + + IRC has quite a lot of people from Scandinavian countries, +the above characters are letters in their alphabet. This +has been explained on IRC about a thousand and one times, so +read the following, do not ask it on IRC: + + { is an A with 2 dots over it + } is an A with a small circle above it + | is either an O with 2 dots over it or an O with a dash (/) through it + [, ], and \ are the preceding three letters in upper case. + + There are a lot of people from Japan as well, who use Kanji characters +which may look quite exotic as well. As I don't know Kanji I don't +even try to explain any of the characters. + +5) ATTENTION! + + Remember, people on IRC form their opinions about you only by +your actions, writings and comments on IRC. So think before you type. +Do not "dump" to a channel or user (send large amounts of unwanted +information). This is likely to get you /kicked off the channel or +/killed off from irc. Dumping causes network 'burps', connections going +down because servers cannot handle the large amount of traffic any more. diff --git a/doc/INSTALL.appendix b/doc/INSTALL.appendix new file mode 100644 index 0000000..beeb57a --- /dev/null +++ b/doc/INSTALL.appendix @@ -0,0 +1,86 @@ +Appendix A: Difference between IP addresses and hostnames + + + There are 2 different types of INTERNET addresses, NAME addresses and + NUMERIC addresses. NAME addresses look like ENGLISH words (and indeed + they are ENGLISH words that refer to a given host). A NAME address looks + like "tolsun.oulu.fi" - and that particular address refers to the machine + named TOLSUN in Finland. It is a UNIQUE address because no other machine + in the world has its NAME address the same as "tolsun.oulu.fi". Anytime + you say "telnet tolsun.oulu.fi" - you would always connect to TOLSUN in + Finland. NUMERIC addresses refer to those addresses that are made up of + NUMBERS for example "128.214.5.6" is the NUMERIC address for TOLSUN. This + address is also UNIQUE in that no other machine in the world will be use + those NUMERIC numbers. The NUMERIC address is usually more reliable than + the NAME address because not all sites can recognize and translate the + NAME address into it's numeric counterpart. NUMERIC always seems to work + best, but use a NAME address when you can because it is easier to tell + what host you are connected to. + + + Every Unix machine has a file called "/etc/hosts" on it. This file + contains NAME and NUMERIC addresses. When you supply IRC with a NAME + address it will at first try to find it in /etc/hosts, and then (if it's + really smart), use the local Domain Name Server (DNS) to find the NUMERIC + address for the host you want to connect to. Thus if you plan to use NAME + addresses keep in mind that on SOME sites the entry for the TARGET machine + must be found in /etc/hosts or the NAME address will fail. A typical + entry in /etc/hosts looks like this: + + 130.253.1.15 orion.cair.du.edu orion.du.edu orion # BSD 4.3 + + This particular example is the Host ORION at the University of Denver. + Notice that on the far left is the NUMERIC Address for orion. The + next few ENGLISH words are the NAME addresses that can be used for orion, + "orion.cair.du.edu", "orion.du.edu", "orion". ALL of these NAME addresses + will return the NUMERIC address "130.253.1.15" which IRC will use to + connect to the TARGET UNIX. (when I say TARGET UNIX I am refering to the + UNIX you want to connect to for IRC). Any futher questions about + /etc/hosts should be directed to "man hosts". + + +Appendix B: Enabling Summon Messages + + +-----------------------------------------------------------------------+ + | E N A B L I N G / S U M M O N M E S S A G E S | + +-----------------------------------------------------------------------+ + + *NOTE* You must have ROOT or special access to the GROUP tty ('/dev') + to do this. If you want to allow users around the world to summon + users at your site to irc, then you should make sure that summon works. + + The "IRCD" program needs access to the GROUP of '/dev'. This + directory is where user TTY's are stored (as UNIX treats each Terminal + as a FILE!) IRCD needs GROUP ACCESS to /dev so that users can be + SUMMONED to the program by others users that are *in* the program. + This allows people from other Universities around the world to SUMMON + your users to IRC so that they can chat with them. Berkeley, SUN, HP-UX + and most of the newer versions of UNIX check to see if a USER is + accepting MESSAGES via the GROUP access rights on their TTY listing + in the /dev directory. For example an entry in '/dev' looks like this: + + (Unix Path on BSD 4.3 UNIX is: /dev/ttyp0) + + crw------- 1 jtrim 20, 0 Apr 29 10:35 ttyp0 + + You will note that 'jtrim' OWNS this terminal and can READ/WRITE to this + terminal as well (which makes sense because I am ENTERING DATA and + RECEIVEING DATA back from the UNIX). I logged into this particular + UNIX on "April 29th" at "10:35am" and my TTY is "ttyp0". But further + of *note* is that I do not have my MESSAGES ON! (mesg n) -- This is + how my terminal would look with MESSAGES ON (mesg y): + + crw--w---- 1 jtrim 20, 0 Apr 29 10:35 ttyp0 + + With my MESSAGES ON (mesg y) I can receive TALK(1) requests, use the + UNIX WRITE(1) command and other commands that allow users to talk + to one another. In IRC this would also allow me to get IRC /SUMMON + messages. To set up the "IRCD" program to work with /SUMMON type + the following: (using ROOT or an account that has access to '/dev'). + + % chgrp tty ircd + % chmod 6111 ircd + + The above commands read: "Give IRCD access to GROUP tty (which is /dev) + and then when ANYONE runs the IRCD allow SETUID and SETGID priviliges + so that they can use the /SUMMON command. diff --git a/doc/INSTALL.info b/doc/INSTALL.info new file mode 100644 index 0000000..c74be27 --- /dev/null +++ b/doc/INSTALL.info @@ -0,0 +1,1759 @@ +This is Info file INSTALL.info, produced by Makeinfo-1.55 from the +input file /tmp/sgml2info3035tmp2. + + \input texinfo + + +File: INSTALL.info, Node: Top, Next: Installing IRC-, Prev: (DIR), Up: (DIR) + +Installing IRC - The Internet Relay Chat Program +************************************************ + + SGML version by Christophe Kalt + $Id: INSTALL.info,v 1.38 1999/08/13 17:22:12 kalt Exp $ + + This document describes how to install, and configure IRC 2.10.3. + +* Menu: + +* Installing IRC-:: +* The config-h file:: +* Editing the Makefile and compiling:: +* The ircd-conf file:: +* Related resources:: +* Reporting a bug:: + + +File: INSTALL.info, Node: Installing IRC-, Next: The config-h file, Prev: Top, Up: Top + +Installing IRC- +*************** + +* Menu: + +* The configure script:: +* Notes for Cygwin32 users:: +* Notes concerning IPv6 support:: + + +File: INSTALL.info, Node: The configure script, Next: Notes for Cygwin32 users, Up: Installing IRC- + +The configure script +==================== + + This package uses a GNU configure script for its configuration. You +simply need to untar the distribution and run the "configure" script. +This will run configure which will probe your system for any +peculiarities it has and setup the Makefile and a file of default +#define's ($arch/setup.h). + + There are a few options to "configure" to help it out, or change the +default behaviour: +`--prefix=DIR' + changes the default directory into which ircd will install using + "make install". This defaults to /usr/local + +`--sbindir=DIR' + changes the default directory where the system admin executable + files will go. It is important to set this properly. (default is + prefix/sbin) + +`--logdir=DIR' + changes the default directory where the irc log files will go. + (default is prefix/var/log/ircd) + +`--sysconfdir=DIR' + changes the default directory where the irc server configuration + files will go. (default is prefix/etc) + +`--localstatedir=DIR' + changes the default directory where the irc server state files + will go. (default is prefix/var/run) + +`--resconf=FILE' + defines the file to be used by ircd to initialize its resolver. + (default is /etc/resolv.conf) + +`--zlib-include=DIR' + specifies in which directory the include file from the zlib is + located. + +`--zlib-library=DIR' + specifies in which directory the zlib library is located. + +`--zlib-prefix=DIR' + specifies the prefix for zlib location. It overrides the 2 + previous options. (The include directory is supposed to be in + prefix/include, and the library in prefix/lib). + +`--with-zlib' + is the default. "configure" looks on your system to find the + zlib. If found, ircd will be linked using it. This does NOT mean + you can use server link compression, for this you also need to + define ZIP_LINKS (see section below). + +`--without-zlib' + tells "configure" not to look for the zlib. Defining this will + keep you from using server link compression. + +`--enable-ip6' + Enable IPv6 support (See notes below) + +`--enable-dsm' + Enable Dynamically Shared Modules support for iauth + + +File: INSTALL.info, Node: Notes for Cygwin32 users, Next: Notes concerning IPv6 support, Prev: The configure script, Up: Installing IRC- + +Notes for Cygwin32 users +======================== + + The daemon of 2.10.3 release compiles properly on W32 systems which +have the GNU-Win32 environment () setup. At the time of the release, +tests were made using the version b20.1 of the Cygwin32 library. + + When compiling on such system, you want to make sure that you have +carefully followed the Cygwin32 installation notes. In particular, you +will need to make sure that the following files exist: `/bin/cp.exe', +`/bin/mv.exe', `/bin/rm.exe' and `/bin/sh.exe'. + + Also, the IRC server needs a `resolv.conf' file in order to +initialize the resolver. This file can be anywhere (see configure +options), and is typically in `/etc' on UNIX systems. + + Finally, iauth is automatically disabled. Even though the iauth +program compiles properly, extra work is required to have a working +communication channel between the IRC server and the iauth program. + + +File: INSTALL.info, Node: Notes concerning IPv6 support, Prev: Notes for Cygwin32 users, Up: Installing IRC- + +Notes concerning IPv6 support +============================= + + The only part of the software that doesn't use IPv6 is the server +internal resolver. It relies on the name servers defined in +"/etc/resolv.conf" to be IPv4 addresses. + + This version was tested on the following IPv6 systems: BSD/OS+KAME, +Digital Unix, FreeBSD+KAME, Linux, NetBSD+INRIA. + + Because IPv6 numeric addresses contain ":" characters, `the +separator for the server configuration file was changed to "%"'. + + +File: INSTALL.info, Node: The config-h file, Next: Editing the Makefile and compiling, Prev: Installing IRC-, Up: Top + +The config-h file +***************** + + The second step consists of defining options before the compilation. +This is done by editing the "config.h" file and changing the various +#DEFINE's. + +* Menu: + +* Define what type of UNIX your machine uses-:: +* DEBUGMODE:: +* CPATH MPATH LPATH PPATH TPATH QPATH OPATH:: +* CACHED_MOTD:: +* CHROOTDIR:: +* ENABLE_SUMMON ENABLE_USERS:: +* SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE:: +* OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY:: +* ZIP_LINKS ZIP_LEVEL:: +* SLOW_ACCEPT:: +* CLONE_CHECK:: +* Other #define's:: + + +File: INSTALL.info, Node: Define what type of UNIX your machine uses-, Next: DEBUGMODE, Up: The config-h file + +Define what type of UNIX your machine uses- +=========================================== + + Pick the machine type which best describes your machine and change +the #undef to #define (if needed).Some flavours of Unix require no +#define and in such cases all others should be #undef'd. + + +File: INSTALL.info, Node: DEBUGMODE, Next: CPATH MPATH LPATH PPATH TPATH QPATH OPATH, Prev: Define what type of UNIX your machine uses-, Up: The config-h file + +DEBUGMODE +========= + + Define DEBUGMODE if you want to see the ircd debugging information +as the daemon is running. Normally this function will be undefined as +ircd produces a considerable amount of output. DEBUGMODE must be +defined for either of -t or -x command line options to work. Defining +this induces a large overhead for the server as it does a large amount +of self diagnostics whilst running. + + `This should only be defined for test purposes, and never used on a +production server.' + + +File: INSTALL.info, Node: CPATH MPATH LPATH PPATH TPATH QPATH OPATH, Next: CACHED_MOTD, Prev: DEBUGMODE, Up: The config-h file + +CPATH MPATH LPATH PPATH TPATH QPATH OPATH +========================================= + + Define CPATH to be the directory path to the "ircd.conf" file. This +path is usually /usr/local/lib/ircd/ircd.conf. The format of this file +will be discussed later. + + The LPATH #define should be set to "/dev/null" unless you plan to +debug the ircd program. Note that the logfile grows very quickly. + + Define MPATH to be the path to the "motd" (message of the day) file +for the server. Keep in mind this is automatically displayed whenever +anyone signs on to your server. + + The PPATH is optional, but if defined, should point to a file which +either doesn't exist (but is creatable) or a previously used PPATH +file. It is used for storing the server's PID so a ps(1) isn't +necessary. + + Define QPATH to be the directory path to the "iauth.conf" file. This +path is usually /usr/local/lib/ircd/iauth.conf. The format of this +file is described by a manual page. + + The OPATH #define should be set to "/dev/null" unless you plan to +debug the iauth program. Note that the logfile grows very quickly. + + +File: INSTALL.info, Node: CACHED_MOTD, Next: CHROOTDIR, Prev: CPATH MPATH LPATH PPATH TPATH QPATH OPATH, Up: The config-h file + +CACHED_MOTD +=========== + + The server sends the "motd" to every client connecting. Every time, +it reads it from the disk. This is quite intensive and can be +undesirable for busy servers. + + Defining CACHED_MOTD will make the server store the "motd" in +memory, and only read it again from the disk when rehashing if the file +has changed. + + +File: INSTALL.info, Node: CHROOTDIR, Next: ENABLE_SUMMON ENABLE_USERS, Prev: CACHED_MOTD, Up: The config-h file + +CHROOTDIR +========= + + To use the CHROOTDIR feature, make sure it is #define'd and that the +server is being run as root. The server will chroot to the directory +name provded by "IRCDDIR" (in Makefile). + + +File: INSTALL.info, Node: ENABLE_SUMMON ENABLE_USERS, Next: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE, Prev: CHROOTDIR, Up: The config-h file + +ENABLE_SUMMON ENABLE_USERS +========================== + + For security conscious server admins, they may wish to leave +ENABLE_USERS undefined, disabling the USERS command which can be used +to glean information the same as finger can. ENABLE_SUMMON toggles +whether the server will attempt to summon local users to irc by writing +a message similar to that from talk(1) to a user's tty. + + +File: INSTALL.info, Node: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE, Next: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY, Prev: ENABLE_SUMMON ENABLE_USERS, Up: The config-h file + +SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE +========================================== + + On large IRC networks, the number of invisible users is likely to be +large and reporting that number cause no pain. To aid and effect this, +SHOW_INVISIBLE_LUSERS is provided to cause the LUSERS command to report +the number of invisible users to all people and not just operators. The +NO_DEFAULT_INVISIBLE define is used to toggle whether clients are +automatically made invisible when they register. + + +File: INSTALL.info, Node: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY, Next: ZIP_LINKS ZIP_LEVEL, Prev: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE, Up: The config-h file + +OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY +================================================== + + The three operator only commands, KILL, REHASH and RESTART, may all +be disabled to ensure that an operator who does not have the correct +privilidges does not have the power to cause untoward things to occur. +To further curb the actions of guest operators, LOCAL_KILL_ONLY can be +defined to only allow locally connected clients to be KILLed. + + +File: INSTALL.info, Node: ZIP_LINKS ZIP_LEVEL, Next: SLOW_ACCEPT, Prev: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY, Up: The config-h file + +ZIP_LINKS ZIP_LEVEL +=================== + + As of the 2.9.3 version of the server, server-server connections may +be compressed using the zlib. In order to compile the server with this +feature, you MUST have the zlib package (version 1.0 or higher) already +compiled and define ZIP_LINKS in the config.h file. Compression use for +server-server connections is separately configured in the ircd.conf +file for each server-server link. ZIP_LEVEL allows you to control the +compression level that will be used. Values above 5 will noticeably +increase the CPU used by the server. + + The zlib package may be found at . The data format used by the zlib +library is described by RFCs (Request for Comments) 1950 to 1952 in the +files (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip +format). These documents are also available in other formats from + + +File: INSTALL.info, Node: SLOW_ACCEPT, Next: CLONE_CHECK, Prev: ZIP_LINKS ZIP_LEVEL, Up: The config-h file + +SLOW_ACCEPT +=========== + + This option is defined by default and is needed on some OSes. It +creates an artificial delay in processing incoming connections. On a +given port, no more than 1 connection per 2 seconds will be processed. + + Undefining this will let the server process connections as fast as +it can which can cause problems on some OSes (such as SunOS) and be +abused (fast massive join of clonebots..), for these reasons, if you +decide to undefine SLOW_ACCEPT you MUST define CLONE_CHECK. + + +File: INSTALL.info, Node: CLONE_CHECK, Next: Other #define's, Prev: SLOW_ACCEPT, Up: The config-h file + +CLONE_CHECK +=========== + + This option acts as a wrapper, by checking incoming connections +early before starting ident query. By default, the server will not +accept more than 2 connections from the same host within 10 seconds. + + +File: INSTALL.info, Node: Other #define's, Prev: CLONE_CHECK, Up: The config-h file + +Other #define's +=============== + + The rest of the user changable #define's should be pretty much self +explanatory in the config.h file. It is *NOT* recommended that any of +the file undef the line with "STOP STOP" in it be changed. + + +File: INSTALL.info, Node: Editing the Makefile and compiling, Next: The ircd-conf file, Prev: The config-h file, Up: Top + +Editing the Makefile and compiling +********************************** + + This package now uses GNU autoconf to probe your system and generate +the correct Makefile. However you need to edit it to specify specific +information, such as "prefix", "irc_mode", "ircd_mode" and "ircd_dir". + + Now to build the package, type "make all". If everything goes will, +you can then install it by typing "make install". + + If you have trouble compiling ircd, copy Makefile.in to Makefile and +edit Makefile as appropriate. + + +File: INSTALL.info, Node: The ircd-conf file, Next: Related resources, Prev: Editing the Makefile and compiling, Up: Top + +The ircd-conf file +****************** + + After installing the ircd and irc programs, edit the ircd.conf file +as per the instructions in this section and install it in the location +you specified in the config.h file. There is a sample conf file called +example.conf in the doc/ directory. + + Appendix A (See INSTALL.appendix) describes the differences between +IP addresses and host names. If you are unfamiliar with this, you +should probably scan through it before proceeding. + + The ircd.conf file contains various records that specify +configuration options. The record types are as follows: + 1. Machine information (M) + + 2. Administrative info (A) + + 3. Port connections (P) + + 4. Connection Classes (Y) + + 5. Client connections (I,i) + + 6. Operator privileges (O) + + 7. Restrict lines (R) + + 8. Excluded accounts (K,k) + + 9. Server connections (C,c,N) + + 10. Deny auto-connections (D) + + 11. Hub connections (H) + + 12. Leaf connections (L) + + 13. Version limitations (V) + + 14. Excluded machines (Q) + + 15. Service connections (S) + + 16. Bounce server (B) + + 17. Default local server (U) + + Except for types "M" and "A", you are allowed to have multiple +records of the same type. In some cases, you can have concurrent +records. `It is important to note that the last matching record will +be used'. This is especially useful when setting up I records (client +connections). + +* Menu: + +* Machine information:: +* Administrative info:: +* Port connections:: +* Connection Classes:: +* Client connections:: +* Operator priviliges:: +* Restrict connections:: +* Excluded accounts:: +* Server connections:: +* Deny auto-connections:: +* Hub connections:: +* Leaf connections:: +* Version limitations:: +* Excluded machines:: +* Service connections:: +* Bounce server:: +* Default local server (for local clients) `*OBSOLETED*':: + + +File: INSTALL.info, Node: Machine information, Next: Administrative info, Up: The ircd-conf file + +Machine information +=================== + +`Introduction' + IRC needs to know a few things about your UNIX site, and the "M" + command specifies this information for IRC. The fomat of this + command is: + +`Format' + M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port> + +`M' + "M" specifies a Machine description line + +`Server NAME' + The name of YOUR server adding any Internet DOMAINNAME that might + also be present. If this hostname can be resolved, the IP# found + will be used to for outgoing connections. Otherwise the default + interface address of the host is used. The server name may not be + FQDN of another host. (This means all outgoing connections will + be done from the same IP#, even if your host has several IP#). + +`YOUR Internet IP#' + If the machine on which you run the server has several IP + addresses, you can define which IP# to use for outgoing + connections. This overrides overrides the "Server NAME". + + See Also the "Port Connections" section. + +`Geographic Location' + Geographic Location is used to say WHERE YOUR SERVER is, and gives + people in other parts of the world a good idea of where you are! + If your server is in the USA, it is usually best to say: <CITY> + <STATE>, USA. Like for Denver I say: "Denver Colorado, USA". + Finnish sites (like tolsun.oulu.fi generally say something like + "Oulu, Finland". + +`Port' + Defines the port on which your server will listen for UDP pings + from other servers. This should be the port were other servers + are set to autoconnect. (Also see the port field description in + connect lines). + +`Example:' + M:tolsun.oulu.fi::Oulu, Finland:6667: + + This line reads: My Host's name is "tolsun.oulu.fi" and my site is + located in "Oulu, Finland". + + M:orion.cair.du.edu::Denver Colorado, USA:6667: + + This line reads: My Hosts name is "orion.cair.du.edu" and my site + is located in "Denver Colorado, USA". + + +File: INSTALL.info, Node: Administrative info, Next: Port connections, Prev: Machine information, Up: The ircd-conf file + +Administrative info +=================== + +`Introduction' + The "A" line is used for administrative information about a site. + The e-mail address of the person running the server should be + included here in case problems arise. + +`Format' + A:<Your Name/Location>:<Your Electronic Mailing Addr>:<other>:: + +`A' + This specifies an Admin record. + +`Your Name & Location' + Use this field to say tell your FULL NAME and where in the world + your machine is. Be sure to add your City, State/Province and + Country. + +`Your Electronix Mailing Addr' + Use this field to specify your Electronic Mailing Address + preferably your Internet Mailing Address. If you have a UUCP or + ARAPnet address - please add that as well. Be sure to add any + extra DOMAIN information that is needed, for example "mail + jtrim@orion" probably won't work as a mail address to me if you + happen to be in Alaska. But "mail jtrim@orion.cair.du.edu" would + work because you know that "orion" is part of the DOMAIN + "cair.du.edu". So be sure to add your DOMAINNAMES to your mailing + addresses. + +`Other' + This is really an OTHER field - you can add what you want here. + +`Example' + (the line is just one line in the confuration file, here it is cut + into two lines to make it clearer to read): + + A:Jeff Trim - Denver Colorado, USA:INET jtrim@orion.cair.du.edu + UUCP {hao,isis}!udenva!jtrim:Terve! Heippa! Have you said hello + in Finnish today?;):: + + Would look like this when printed out with the /admin command: + + Jeff Trim - Denver Colorado, USA INET jtrim@orion.cair.du.edu + UUCP {hao,isis}!udenva!jtrim Terve! Hei! Heippa! Have you said + hello in Finnish today? ;) + + Note that the A record cannot be split across multiple lines; it + will typically be longer than 80 characters and will therefore + wrap around the screen. + + +File: INSTALL.info, Node: Port connections, Next: Connection Classes, Prev: Administrative info, Up: The ircd-conf file + +Port connections +================ + +`Introduction' + The port line adds flexibility to the server's ability to accept + connections. By use of this line in the ircd.conf file, it is easy + to setup both Unix Domain ports for the server to accept + connections on as well as extra internet ports. + +`Format' + P:<Internet IP#>:<*>:<Internet IP Mask>:<Port>: + P:<Directory>:<*>:<*>:<Port>: + + * Internet Ports + `Internet IP#' + If the host on which the server runs has several IP + addresses, you can define for which IP address connections + will be accepted. If no is defined here, server will bind to + all interfaces (INADDR_ANY). See also MACHINE CONFIGURATION + section to properly configure outgoing connections. + + P:192.168.1.194:::6664: + + `Internet IP# Mask' + This defines where connections may come from and be accepted. + The IP mask uses either *'s or 0's as wildcards. The + following two lines are the same: + + P:::128.2.*:6664: P:::128.2.0.0:6664: + + The incoming isn't matched against the mask, rather the ip# + string is decoded and compared segment by segment. Thus + + P:::128.2*.1.2:6664: + + will not match 128.20.1.2. + + `Port' + The port number field tells the server which port number it + should listen on for incoming connections. + + * Unix Socket Ports. + `Directory' + The path set in this field should be the directory name in + which to create the unix socket for later listening to. The + server will attempt to create the directory before creating + the unix socket. + + `Port' + The port field when used in combination with a pathname in a + P-line is the filename created in the directory set in the + first field. + + `Example' + P:/tmp/.ircd:::6667: + + Creates a unix socket in the /tmp/.ircd directory called + "6667". The unix socket (file) must be a numerical. + +`Note' + You need at least one P line. + + +File: INSTALL.info, Node: Connection Classes, Next: Client connections, Prev: Port connections, Up: The ircd-conf file + +Connection Classes +================== + +`Introduction' + To enable more efficient use of MAXIMUM_LINKS, connection classes + were implemented. All clients belong to a connection class. + + Each line for a server should have the same number as the sixth + field. If it is absent, the server deaults it to 0, using the + defaults from the config.h file. + + To define a connection class, you need to include a Y: line in the + ircd.conf file. This enables you to define the ping frequency, + connection frequency (for servers) and maximum number of links + that class should have. + + Currently, the Y: line `MUST' appear in the ircd.conf file + `BEFORE' it is used in any other way. + +`Format' + Y:<Class>:<Ping Frequency>:<Connect freq>:<Max + Links>:<SendQ>:<Local Limit>:<Global Limit> + +`Y' + This specifies a Class record. + +`Class' + This is the class number which gains the following attributes and + should match that which is on the end of the C/c/N/I/O/S line. + +`Ping Frequency' + This field defines how long the server will let the connection + remain "silent" before sending a PING message to make sure it is + still alive. Unless you are sure of what you are doing, use the + default value which is in your config.h file. + +`Connect Frequency' + By changing this number, you change how often your server checks + to see if it can connect to this server. If you want to check very + occasionally, use a large value, but if it is an important + connection, you might want a smaller value so that you connect to + it as soon as possible. + +`Max Links' + This field defines the maximum number of links this class will + allow from automatic connections (C lines). Using /CONNECT + overrides this feature. Also defines the maximum number of users + in this class for I/O lines per I/O line. + +`SendQ' + This field defines the "SendQ" value for this class. If this + field is not present, the default (from config.h) is assigned. + +`Local limit' + This field is used to limit the number of local concurrent + connections. The format is <x>.<y> + * x: defines the maximum number of clients from the same host + (IP) will be allowed. + + * y: defines the maximum number of clients from the same + user@host (IP) will be allowed. Read note below. + + Only x or y may be set, any unset value defaults to zero. + +`Global limit' + This field has the same use as the "Local limit" field. But, the + connection counts are done for all clients present on the net + instead of only counting local clients. + +`Note' + leaving any of the fields (except SendQ) out means their value is + 0 (ZERO)!! The SendQ field default value is dynamically + determined. + +`Note' + If you plan to use the local user@host limit, please read the + following very carefully. The "user" value is the ident reply for + the connection. If no reply was given then it defaults to + "unknown" and thus the effective limit will be per host, not per + user@host. Also, some ident servers return encrypted data which + changes for every connection making the limit void. + +`Note' + Only the local limitation is accurate. + +`Note' + If you define a gobal limit, you should also define a local limit + (same or lower) as it won't take more CPU and will make the global + limit more accurate. + +`Note' + The local and global limits only affect users (I lines), not + servers nor services. + +`Example' + Y:23:120:300:5:100000:0:0: (server class) + + This defines class 23 to allow 5 auto-connections, which are + checked every 300 seconds. The connection is allowed to remain + silent for 120 seconds before a PING is sent. NOTE: fields 3 & 4 + are in seconds. The SendQ is set to 100000 bytes. + + Another feature of connection class is the ability to do automatic + routing by using the class as a "priority". If you are connected + to a server which has a class lower than one of the servers that + is "behind" it, the server will disconnect the lower class one and + schedule a "new" connection for the higher class server. + + Y:1:60:0:50:20000:2:5: (client class) + + In case of a client class, the fields are interpreted a bit + differently. This class (number 1) can be used by up to 50 users. + The connections are allowed to remain silent for 60 seconds + before a PING is set. The SendQ is set to 20000 bytes. A new + connection in this class will only be allowed if there aren't more + than 2 other local connections from the same IP address, or more + than 5 other connections on the net from the same hostname. + + Y:2:60:0:50:20000:2.1:5: (client class) + + In case of a client class, the fields are interpreted a bit + differently. This class (number 1) can be used by up to 50 users. + The connections are allowed to remain silent for 60 seconds + before a PING is set. The SendQ is set to 20000 bytes. A new + connection in this class will only be allowed if there aren't more + than 2 other local connections from the same IP address, 1 other + local connection from the same user from the same IP address, or + more than 5 other connections on the net from the same hostname. + + +File: INSTALL.info, Node: Client connections, Next: Operator priviliges, Prev: Connection Classes, Up: The ircd-conf file + +Client connections +================== + + How to let clients connect to your IRCD. +`Introduction' + A client is a program that connects to the ircd daemon (ircd). + There are clients written in C, GNU Emacs Lisp and many other + languages. The "irc" program is the C client. Each person that + talks via IRC is running their own client. + + The ircd.conf files contains entries that specify which clients + are allowed to connect to your irc daemon. Obviously you want to + allow your own machine's clients to connect. You may want to + allow clients from other sites to connect. These remote clients + will use your server as a connection point. All messages sent by + these clients will pass through your machine. + +`Format' + I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> + i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> + +`TARGET Host Addr' + Specifies the IP address(es) of the machine(s) that are allowed to + connect. If "user@" prefixes the actual IP address the server + will require that the remote username returned by the ident server + be the same as the one given before the "@". Wildcards are + permitted unless using a bitmask (e.g. 1.2.3.0/24). + +`Password' + The password that must be given by the client to be allowed on the + server. + +`TARGET Host NAME' + Specifies the host name(s) of the machines allowed to connect to + the server. If "user@" prefixes the actual IP address the server + will require that the remote username returned by the ident server + be the same as the one given before the "@". Wildcards are + permitted. + + This field can be empty, it then has a special meaning. See Below. + +`Port' + Specifies the port number for which this configuration line is + valid. An empty field, or "0" matches all ports. + +`Class' + This field should refer to an existing class. Connections classes + are usefull to limit the number of users allowed on the server. + +`Note' + The server first checks if the client hostname (or any aliases) + matches the `TARGET Host NAME' field. If a match is found, the + client is accepted. If not, the server checks if the IP address + of the client matches the `TARGET Host Addr' field. The matching + field is used to set the name of the client: for example, if the + client matches the `TARGET Host Addr' field, it will show on IRC + with a numerical address (even if this address is resolvable). If + the `TARGET Host NAME' field is empty, then the host name is + always used (when available). + +`Examples' + For example, if you were installing IRC on tolsun.oulu.fi and you + wanted to allow examples sake let us assume you were making this + file for tolsun and you wanted to let your own clients to connect + to your server, you would add this entry to the file: + + I:x::tolsun.oulu.fi::1 + + If you wanted to let remote clients connect, you could add the + following lines: + + I:x::*.du.edu::1 + + Allow any clients from machines whose names end in ".du.edu" to + connect with no password. + + I:128.214.6.100::nic.funet.fi::1 + + Allow clients from a machine with that IP number to connect. + Numeric match is enough, name is not required anymore. + + I:x:secret:*.tut.fi::1 + + Allow clients from machines matching "*.tut.fi" to connect with + the password "secret". + + I:*::*::1 + + Allow anyone from anywhere to connect your server. + + This is the easiest way, but it also allows people to for example + dump files to your server, or connect 1000 (or how many open + sockets per process your OS allows) clients to your machine and + take your network ports. Of course the same things can be done by + simply telnetting to your machine's SMTP port (for example). + + I:x::*.fi:6667:1 + + Allow clients from machines matching "*.fi" to connect on the port + 6667. + + I:135.11.35.*::*.net::1 + + Allows clients from machines which host name matches "*.net" or + which IP address matches "135.11.35.*" to connect to the server. + If the host name does not match "*.net" then the IP address is + used for these clients, even if the host name is known. + + I:135.11.35.*::::1 + + Allows clients from machines which IP address matches + "135.11.35.*" to connect to the server. If the host name is + known, is it used as address for these clients. + +`NEW!!!' + As of the 2.7.2d version of the server, the server is able to + accept connections on multiple ports. I-lines are required for + each P-line to allow connections to be accepted. For unix sockets, + this means either adding I:/path/port::/path/port or some variation + (wildcards are recognised here). For internet ports, there must be + an I-line which allows the host access as normal, but the port + field of the I-line must match that of the port of the socket + accepting the connectiion. A port number of 0 is a wildcard + (matches all ports). + +`NEW!!!' + As of the 2.9.1 version of the server, i lines are introduced. + They work the same way as I lines, but the clients matching an i + line will have a restricted connection. (no nick/mode change, no + kick). Such users will have their username prefixed by +, = or - + depending on the ident reply. + + +File: INSTALL.info, Node: Operator priviliges, Next: Restrict connections, Prev: Client connections, Up: The ircd-conf file + +Operator priviliges +=================== + + How to become the IRC administrator on your site +`Introduction' + To become an IRC Administrator, IRC must know who is authorized to + become an operator and what their "Nickname" and "Password" is. + +`Format' + O:<TARGET Host NAME>:<Password>:<Nickname>:<Port>:<Class> + +`O' + Speficies Operator record. If you use capital letter ("O") in it, + it specifies a global operator. Small letter ("o") specifies a + local operator. Local operator has basically the same rights + except global operator with some restrictions. + +`TARGET Host NAME' + Tells IRC which host you have the privileges FROM. This means + that you should be logged into this host when you ask for the + priviliges. If you specify "tolsun.oulu.fi" then IRC will expect + your CLIENT to be connected at "tolsun.oulu.fi" - when you ask for + OPERATOR privileges from "tolsun.oulu.fi". You cannot be logged in + at any other host and be able to use your OPERATOR privileges at + tolsun, only when you are connected at TOLSUN will this work - + this is a safeguard against unauthorized sites. + +`Password' + If your AUTHORIZATION Password - this is the password that let's + IRC know you are who you say you are! Never tell anyone your + password and always keep the "ircd.conf" file protected from all + of the other users. + +`Nickname' + The Nickname you usually go by - but you can make this what you + want. + +`Port' + Unused. + +`Class' + The class field should refer to an existing class (preferably + having a lower number than that for the relevant I-line) and + determines the maximum number of simultaneous uses of the O-line + allowable through the max. links field in the Y-line. + +`Example' + O:orion.cair.du.edu:pyunxc:Jeff::1 + + There is an OPERATOR at "orion.cair.du.edu" that can get Operator + priviliges if he specifies a password of "pyunxc" and uses a + NICKNAME of "Jeff". + + +File: INSTALL.info, Node: Restrict connections, Next: Excluded accounts, Prev: Operator priviliges, Up: The ircd-conf file + +Restrict connections +==================== + + Let an external program decide if a client should be allowed or not. +`Introduction' + R lines provide a convenient way to handle user access to the + server with an external program. The outside program given three + parameters: the client's username (set by the USER command), the + client's hostname, and the client's ident reply ("unknown" if + none). + + It is expected to return a reply line where the first word is + either "Y" or "N" meaning `Yes Let them in" or "No don't let them + in". If the first word begins with neither "Y" or "N" the default + is to let the person on. + +`Format' + R:<Target Host Name>:<Program>:<User>::: + +`R' + This specifies a restrict record. + +`Target Host Name' + In this field you specify the Hostname that the user is connecting + from. If you wanted to restrict connects to IRC from + "orion.cair.du.edu" then you would want to enter + "orion.cair.du.edu". + +`Program' + This is the external program to run to know if the user is allowed + on your server. + +`User' + The Username of the user you want removed from IRC. For example + "root". + + +File: INSTALL.info, Node: Excluded accounts, Next: Server connections, Prev: Restrict connections, Up: The ircd-conf file + +Excluded accounts +================= + + Remove an errant user from IRC on your site. +`Introduction' + Obviously it is hoped that you wouldn't have to use this command. + Unfortunately sometimes a user can become unmanageable and this is + your only recourse - the KILL USER command. THIS COMMAND ONLY + AFFECTS YOUR SERVER - If this user can connect to another SERVER + somewhere else in the IRC-Network then you would have to talk to + the administrator on that site to disable his access from that + IRCD Server as well. + +`Format' + K:<Host Name>:<time interval(s)|comment>:<User>:<port>: + +`Format' + k:<Host Name>:<time interval(s)|comment>:<Auth>:<port>: + +`K' + "K" tells the IRCD that you are making a KILL USER command entry. + +`Host Name' + In this field you specify the Hostname or the IP address (Single + IP, Wildcard notation or bitmask notation) that the user is + connecting from. If you wanted to REMOVE connects to IRC from + "orion.cair.du.edu" then you would want to enter + "orion.cair.du.edu". If you want to REMOVE ALL HOSTS access you + can use "*" (Wild Card notation) and no matter what host the + USERNAME (specified in Field 4) connects from s/he will be denied + access. Removing all hosts isn't very smart thing to do though, + why would you run an ircd if you allow nobody to connect to it + anyways ? + + If you specify an IP address, IP mask, or an IP bitmask, it will + match clients connecting from the matching addresses, no matter if + they resolve or not. + + You can prefix an IP address, an IP mask, or IP bitmask by "=" in + which case only non resolving matching hosts will be banned. + +`time interval(s)|comment' + Either leave this field empty or put a comment, then the line + active continuously for the specified user/host machine. You may + also specify intervals during the line should be active, see + examples below. + +`User' + The USERNAME of the user you want removed from IRC. For example + "root". + +`Auth' + If the user's ident server replies with the OTHER type (as opposed + to the UNIX type), the reply is not used to set the user's + username. (lowercase) k lines can be used in these case to reject + users based on their ident reply. + + This field will be matched against the ident server reply. It is + important to note that OTHER replies are prefixed with a "-" by + the ircd, while UNIX replies are not. + +`Port' + The port on which the Kill line will be effective. 0 means all + ports. + +`Examples' + K:orion.cair.du.edu::jtrim:0: + + If user "jtrim" connects to IRC from host "orion.cair.du.edu" then + IMMEDIATELY REMOVE HIM from my IRCD. + + k:*.stealth.net::-43589:0: + + If a user connects from any host that has the suffix "stealth.net" + and if that host ident server returns "-43589" - then IMMEDIATELY + REMOVE THEM from my IRCD. + + K:*.cair.du.edu::root:0: + + If user "root" connects to IRC from any host that has the suffix + "cair.du.edu" - then IMMEDIATELY REMOVE THEM from my IRCD. + + K:*::vijay:0: + + This line reads "I don't care WHAT HOST user "vijay" is on, I will + NEVER allow username "vijay" to login to my IRCD." + + K:*.oulu.fi:0800-1200,1400-1900:*:0: + + This disallows all users from hosts with enddomain "oulu.fi" + access to your server between 8 and 12am, 2 and 7pm. Users get + kicked off if they're already signed on when the line becomes + active (they'll get a warning 5 minutes before). + + K:192.11.35.*::*:0: + + This line disallows all hosts whose IP address matches + "192.11.35.*" to login to the ircd. + + K:=192.11.35.*::*:0: + + This line disallows all hosts whose IP address matches + "192.11.35.*" and which didn't resolve to login to the ircd. + + +File: INSTALL.info, Node: Server connections, Next: Deny auto-connections, Prev: Excluded accounts, Up: The ircd-conf file + +Server connections +================== + + How to connect to other servers, How other servers can connect to you + + `WARNING:' The hostnames used as examples are really only examples +and not meant to be used (simply because they don't work) in real life. + + Now you must decide WHICH hosts you want to connect to and WHAT +ORDER you want to connect to them in. For my example let us assume I +am on the machine "rieska.oulu.fi" and I want to connect to irc daemons +on 3 other machines: + * "garfield.mit.edu" - Tertiary Connection + + * "irc.nada.kth.se" - Secondary Connection + + * "nic.funet.fi" - Primary Connection + + And I prefer to connect to them in that order, meaning I first want +to try connecting to "nic.funet.fi", then to "irc.nada.kth.edu", and +finally to "garfield.mit.edu". So if "nic.funet.fi" is down or +unreachable, the program will try to connect to "irc.nada.kth.se". If +irc.nada.kth.se is down it will try to connect to garfield and so forth. + + PLEASE limit the number of hosts you will attempt to connect to down +to 3. This is because of two main reasons: + 1. to save your server from causing extra load and delays to users + + 2. to save internet from extra network traffic (remember the old + rwho program with traffic problems when the number of machines + increased). + +`Format' + C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET + PORT>:<Class> + + for example: + + C:nic.funet.fi:passwd:nic.funet.fi:6667:1 + + - or - + + C:128.214.6.100:passwd:nic.funet.fi:6667:1 + + - or - + + C:root@nic.funet.fi:passwd:nic.funet.fi:6667:1 + + Each field is separated with a ":" charcter: + +`C' + This field tells the IRC program which option is being configured. + "C" corresponds to a server Connect option. + +`TARGET Host Addr' + Specifies the host name or IP address of the machine to connect + to. If "user@" prefixes the actual hostname or IP address the + server will require that the remote username returned by the ident + server be the same as the one given before the "@". + +`Password' + The password of the other host. A password must always be present + for the line to be recognized. + +`TARGET Host NAME' + The full hostname of the target machine. This is the name that the + TARGET server will identify itself with when you connect to it. + If you were connecting to nic.funet.fi you would receive + "nic.funet.fi" and that is what you should place in this field. + +`TARGET PORT' + The INTERNET Port that you want to connect to on the TARGET + machine. Most of the time this will be set to "6667". If this + field is left blank, then no connections will be attempted to the + TARGET host, and your host will accept connections FROM the TARGET + host instead. The port field can contain 2 ports, separated by a + . In this case, the first port is used when auto-connecting, the + second port is used for the UDP pings to the targer server. + +`Class' + The class field should refer to an existing class and determines + the maximum number of simultaneous uses of the C-line allowable + through the max. links field in the Y-line. + +`NEW!!!' + As of the 2.9.3 version of the server, server connections can be + compressed with the zlib library. To define a compressed + connection, you must have compiled the server with ZIP_LINKS + defined (cf 2.h), and use a _lowercase_ C line. + + Some examples: + * C:nic.funet.fi::nic.funet.fi:6667:1 This reads: Connect to host + "nic.funet.fi", with no password and expect this server to + identify itself to you as "nic.funet.fi". Your machine will + connect to this host to port 6667. + + * C:18.72.0.252:Jeff:garfield.mit.edu:6667:1 This reads: Connect to + a host at address "18.72.0.252", using a password of "Jeff". The + TARGET server should identify itself as "garfield.mit.edu". You + will connect to Internet Port 6667 on this host. + + * C:irc.nada.kth.se::irc.nada.kth.se:1 This reads: do not attempt to + connect to "irc.nada.kth.se", if "irc.nada.kth.se" requests a + connection, allow it to connect. + + Now back to our original problem, we wanted OUR server CONNECT to 3 +hosts, "nic.funet.fi", "irc.nada.kth.se" and "garfield.mit.edu" in +that order. So as we enter these entries into the file they must be +done in `reverse' order of how we could want to connect to them. + + Here's how it would look if we connected "nic.funet.fi" first: + + C:garfield.mit.edu::garfield.mit.edu:6667:1 +C:irc.nada.kth.se::irc.nada.kth.se:6667:1 +C:nic.funet.fi::nic.funet.fi:6667:1 + + Ircd will attempt to connect to nic.funet.fi first, then to irc.nada +and finally to garfield. + + `Reciprocal entries:' Each "C" entry requires a corresponding "N" +entry that specifies connection priviliges to other hosts. The "N" +entry contains the password, if any, that you require other hosts to +have before they can connect to you. These entries are of the same +format as the "C" entries. + +`Format' + The format for the NOCONNECT entry in the "ircd.conf" is: + N:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<Domain + Mask>:<Class> + + Let us assume that "garfield.mit.edu" connects to your server and + you want to place password authorization authorization on + garfield. The "N" entry would be: + + N:garfield.mit.edu:golden:garfield.mit.edu:: + + This line says: expect a connection from host "garfield.mit.edu", + and expect a login password of "golden", and expect the host to + identify itself as "garfield.mit.edu". + + N:18.72.0.252::garfield.mit.edu:: + + This line says: expect a Connection from host "18.72.0.252", and + don't expect login password. The connecting host should identify + itself as "garfield.mit.edu". + +`N' + "N" corresponds to a server Noconnect option. + +`TARGET Host Addr' + Specifies the host name or IP address of the machine to connect + to. If "user@" prefixes the actual hostname or IP address the + server will require that the remote username returned by the ident + server be the same as the one given before the "@". + +`Password' + The password of the other host. A password must always be present + for the line to be recognized. If CRYPT_LINK_PASSWORD is defined + in config.h, this password must be crypted. + +`TARGET Host NAME' + The full hostname of the target machine. This is the name that the + TARGET server will identify itself with when you connect to it. + If you were connecting to nic.funet.fi you would receive + "nic.funet.fi" and that is what you should place in this field. + +`Domain Mask' + Domain masking, see below. + +`Class' + The class field should refer to an existing class. + +`Wildcards domains' + To reduce the great amount of servers in IRCnet wildcard DOMAINS + were introduced in 2.6. To explain the usage of wildcard domains + we take an example of such: + + *.de - a domain name matching all machines in Germany. + + Wildcard domains are useful in that ALL SERVERS in Germany (or any + other domain area) can be shown as one to the rest of the world. + Imagine 100 servers in Germany, it would be incredible waste of + netwotk bandwidth to broadcast all of them to all servers around + the world. + + So wildcard domains are a great help, but how to use them ? + + They can be defined in the N-line for a given connection, in place + of "Domain Mask" you write a magic number called wildcard count. + + Wildcard count tells you HOW MANY PARTS of your server's name + should be replaced by a wildcard. For example, your server's name + is "tolsun.oulu.fi" and you want to represent it as "*.oulu.fi" to + "nic.funet.fi". In this case the wildcard count is 1, because only + one word (tolsun) is replaced by a wildcard. + + If the wildcard count would be 2, then the wildcard domain would + be "*.fi". Note that with wildcard name "*.fi" you could NOT + connect to "nic.funet.fi" because that would result in a server + name `collision' (*.fi matches nic.funet.fi). + + I advice you to not to use wildcard servers before you know for + sure how they are used, they are mostly beneficial for backbones + of countries and other large areas with common domain. + + +File: INSTALL.info, Node: Deny auto-connections, Next: Hub connections, Prev: Server connections, Up: The ircd-conf file + +Deny auto-connections +===================== + +`Introduction' + D lines were implemented to give server administrators more + control on how auto connections are done. This will most likely + only be useful for big networks which have complex configurations. + +`Format' + D:<Denied Server Mask>:Denied Class:<Server Name>:Server Class: + +`Denied Server Mask' + This field is matched against all servers currently present on the + network. + +`Denied Class' + If this field contains a class number, it will match if any server + in that class is currently present on the network. Note that this + can be true for any server, even the ones not directly connected. + +`Server Mask' + This field is matched against the server name that the server + wants to auto connect to. + +`Server Class' + This field is used to match against the class to which belong the + servers for which an autoconnect is set. + +`Examples' + D:*.edu::*.fi:: + + Don't auto-connect to any "*.fi" server if any server present on + the network matches "*.edu". + + D::2:eff.org:3: + + Do now auto-connect to "eff.org", or any server in class "3" if a + server defined to be in class "2" is currently present on the + network. + + +File: INSTALL.info, Node: Hub connections, Next: Leaf connections, Prev: Deny auto-connections, Up: The ircd-conf file + +Hub connections +=============== + +`Introduction' + In direct contrast to L-lines, the server also implements H-lines + to determine which servers may act as a hub and what they may "hub + for". If a server is only going to supply its own name (ie act as + a solitary leaf) then no H-line is required for, else a H-line + must be added. + +`Format' + H:<Server Mask>:*:<Server Name>:: + +`Server Mask' + All servers that are allowed via this H-line must match the mask + given in this field. + +`Server Name' + This field is used to match exactly against a server name, + wildcards being treated as literal characters. + +`Examples' + H:*.edu::*.bu.edu:: + + Allows a server named "*.bu.edu" to introduce only servers that + match the "*.edu" name mask. + + H:*::eff.org:: + + Allows "eff.org" to introduce (and act as a hub for) any server. + +`Note' + It is possible to have and use multiple H-lines (or L-lines) for + the one server. eg: + + H:*.edu:*:*.bu.edu:: H:*.au:*:*.bu.edu:: + + is allowed as is + + L:*.edu:*:*.au:: L:*.com:*:*.au:: + + +File: INSTALL.info, Node: Leaf connections, Next: Version limitations, Prev: Hub connections, Up: The ircd-conf file + +Leaf connections +================ + +`Introduction' + To stop servers which should only act as leaves from hubs becoming + hubs accidently, the L line was introduced so that hubs can be + aware of which servers should and shouldnt be treated as leaves. A + leaf server is supposed to remain a node for the entirity of its + life whilst connected to the IRC server network. It is quite easy, + however for a leaf server to be incorrectly setup and create + problems by becoming a node of 2 or more servers, ending its life + as a leaf. The L line enables the administrator of an IRC "Hub + server" to "stop" a server which is meant to act as a leaf trying + to make itself a hub. If, for example, the leaf server connects + to another server which doesnt have an L-line for it, the one + which does will drop the connection, once again making the server + a leaf. + +`Format' + L:<Server Mask>:*:<Server Name>:<Max Depth>: + +`Server Mask' + Mask of which servers the leaf-like attributes are used on when + the server receives SERVER messages. The wildcards * and ? may be + used within this field for matching purposes. If this field is + empty, it acts the same as if it were a single * (ie matches + everything). + +`Server Name' + The name of the server connected to you that for which you want to + enforce leaf-like attributes upon. + +`Max Depth' + Maximum depth allowed on that leaf and if not specified, a value + of 1 is assumed. The depth is checked each time a SERVER message + is received by the server, the hops to the server being the field + checked against this max depth and if greater, the connection to + the server that made its leaf too deep has its connection dropped. + For the L-line to come into effect, both fields, 2 and 4, must + match up with the new server being introduced and the server which + is responsible for introducing this new server. + + +File: INSTALL.info, Node: Version limitations, Next: Excluded machines, Prev: Leaf connections, Up: The ircd-conf file + +Version limitations +=================== + +`Introduction' + V-lines are used to restrict server connecting to you based on + their version and on compile time options. + +`Format' + V:<Version Mask>:<Flags>:<Server Mask>:: + +`Version Mask' + The matching version number strings will be rejected. + +`Flags' + If any flag specified in this field is found in the peer's flags + string, it will be rejected. + +`Server Mask' + This field is used to match server names. The V line will be used + for servers matching the mask given in this field. + +`Server Type' + Both the `Version Mask' and the `Flags' should be prefixed with + the server type identification. This implementation uses the id + "`IRC"' (starting with version 2.10). + +`Examples' + V:IRC/021001*::*:: + + Disallows any "IRC" server which version is 2.10.1* to connect. + + V:IRC/021001*:IRC/D:*:: + + Disallows any "IRC" server which version is 2.10.1* or which has + been compiled with DEBUGMODE defined to connect. + + V:*/0209*:::: + + Disallows any server using the 2.9 protocol to connect. + +`Note' + It is possible to have and use multiple V-lines for the one server + mask. + + V:IRC/021001*::*:: + + V:IRC/021002*::*:: + + is allowed. + +`Protocol Version' + Only the 4 first digit of the `Version Number' are standard: they + define the protocol version. The remaining of the string is + implementation dependant; matches on this part should be used with + particular identification. + +`Flags' + are not standard. Therefore, this field `should always' contain a + specific identification. + + +File: INSTALL.info, Node: Excluded machines, Next: Service connections, Prev: Version limitations, Up: The ircd-conf file + +Excluded machines +================= + + Disallowing SERVERS in your irc net. +`Introduction' + In some cases people run into difficulties in net administration. + For one reason or another you do not want a certain server to be + in your net (for example because of the security holes it opens for + every server if it's not secured carefully). In that case you + should use Q-lines in your server. When you specify a server name + in Q-line, everytime some server link tries to introduce you a + server (remember, all server names are broadcast around the net), + that name is checked if it matches the Q-lines in your server. If + it matches, then `your server' disconnects the link. Note that just + placing Q-lines to your server probably results in `your server' + being left alone, unless other servers have agreed to have the + same Q-line in their ircd configuration files as well. + +`Example' + Q::of the security holes:foo.bar.baz:: + + This command excludes a server named "foo.bar.baz", the reason is + given to be security holes (you should give a reason, it is + polite). The first field is unused, so leave it empty. + + +File: INSTALL.info, Node: Service connections, Next: Bounce server, Prev: Excluded machines, Up: The ircd-conf file + +Service connections +=================== + +`Introduction' + The Service is a special kind of IRC client. It does not have the + full abilities of a normal user but can behave in a more active + manner than a normal client. + + Services are not intended for interactive usage, and are better + suited for automated clients. + +`Format' + S:<TARGET Host Mask>:<Password>:<Service Name>:<Service + Type>:<Class> + +`TARGET Host Mask' + The host mask should be set to match the host(s) from which the + service will be connecting from. This may be either an IP# or full + name (prefered). + +`Password' + This is the password which must be passed in the SERVICE command. + +`Service Name' + The name used by the service. Services don't have nicknames, but a + static name defined by the S line. + +`Service Type' + The type of service. It defines the priviledges given to the + service. Be very careful in the types you allow. The types can be + found in include/service.h + +`Class' + The class field should refer to an existing class. + +`Notes' + A service is not a very useful sort of client, it cannot join + channels or issue certain commands although most are available to + it. Services are rejected upon sending an unknown or unallowed + command. Services however, are not affected by flood control and + can be granted special privileges. It is therefore `wise to + oversee the use of S-lines with much care.' + + +File: INSTALL.info, Node: Bounce server, Next: Default local server (for local clients) `*OBSOLETED*', Prev: Service connections, Up: The ircd-conf file + +Bounce server +============= + +`Introduction' + This provides you a way to bounce clients to another server. This + information is provided to clients which are denied connection, + either because their connection class is full, or the server is + full, or they are not authorized to connect. + +`Format' + B:<Class|Host Mask>::<Server Name>:<Port>: + +`B' + This specifies a Bounce record. + +`Class|Host Mask' + This field specifies to which client this configuration line + applies to. It can be either a connection class number, a host + mask to be matched against the client's hostname, or an IP + address/mask/bitmask to be matched against the client's IP address. + + When the server is completely full, it rejects clients with the + "All connections in use" message. In this case, the server + doesn't process the connections at all, and has no knowledge of + the client's host name, or class number. For these cases, this + field must be empty. + +`Server Name' + This specifies the IRC server hostname that the client should use. + +`Port' + This specifies the IRC server port that the client should connect + to. + +`Example' + B:2::irc.stealth.net:6660: + + Rejected clients in class 2 are advised to use "irc.stealth.net" + on port 6660. + + B:*.fi::irc.funet.fi:6667: + + Finnish client should use irc.funet.fi when they cannot be taken + anymore. + + B:::irc2.stealth.net:6667: + + When the server is completely full, clients should use the + secondary server. + + +File: INSTALL.info, Node: Default local server (for local clients) `*OBSOLETED*', Prev: Bounce server, Up: The ircd-conf file + +Default local server (for local clients) `*OBSOLETED*' +====================================================== + +`Introduction' + This defines the default connection for the irc client. If you + are running an ircd server on the same machine, you will want to + define this command to connect to your own host. If your site is + not running a server then this command should contain the TARGET + host's connection information and password (if any). + +`Format' + U:<TARGET Host addr>:<Password>:<TARGET Host NAME>:<Internet Port> + +`Examples' + U:tolsun.oulu.fi::tolsun.oulu.fi:6667 + + U:128.214.5.6::tolsun.oulu.fi:6667 + + U:tolsun.oulu.fi::tolsun.oulu.fi + + If the port number is omitted, irc will default to using 6667. + + +File: INSTALL.info, Node: Related resources, Next: Reporting a bug, Prev: The ircd-conf file, Up: Top + +Related resources +***************** + +`Mailing list' + A list is dedicated to the people using ircd. If you have trouble + running ircd, or wish to discuss the future, you can subscribe by + sending an email to , with "`subscribe ircd-users"' in the body. + + If you just have a question and don't want to subscribe to the + list, mail to . Be sure to indicate which version you are using. + +`Development' + Technical discussions and development are carried on + ircd-dev@irc.org. People interested in very early testing, and/or + working on the source code are welcome. This is done by sending + an email to , with "`subscribe ircd-dev"' in the body. + +`FAQ' + It can be found on the WWW, at . + +`WWW 2.9' + Vesa Ruokonen has also put serveral pages related to the 2.9 + servers on the WWW: . + + +File: INSTALL.info, Node: Reporting a bug, Prev: Related resources, Up: Top + +Reporting a bug +*************** + + If you encounter a bug in the software, here is how and where to +report it. + +* Menu: + +* How to report a bug:: +* Where to send a bug report:: + + +File: INSTALL.info, Node: How to report a bug, Next: Where to send a bug report, Up: Reporting a bug + +How to report a bug +=================== + + To save everyone time, make sure that your e-mail contains all the +information related to your problem. In particular, we need to know: +`Package version' + The IRC software version you are using: please include the output + obtained by running "irc -v" for the client, and/or "ircd -v" for + the server. + + Also, let us know if you have applied any patch to the package or + if it is the vanilla version. + +`OS' + Please, indicate which OS version you are running. + +`Configuration' + If it is related to a configuration problem with the server, + include the relevant parts of the configuration file. + +`Backtrace' + If the bug results in a crash, please include the backtrace. + (This can be done, for example, by running "gdb" on the core file, + and typing "where"). + +`Fix' + If you have a fix, don't forget to include it. + + +File: INSTALL.info, Node: Where to send a bug report, Prev: How to report a bug, Up: Reporting a bug + +Where to send a bug report +========================== + + Reports should be sent to . Your report will be reviewed and +forwarded to the appropriate mailing list. + + + +Tag Table: +Node: Top122 +Node: Installing IRC-630 +Node: The configure script855 +Node: Notes for Cygwin32 users3143 +Node: Notes concerning IPv6 support4196 +Node: The config-h file4794 +Node: Define what type of UNIX your machine uses-5466 +Node: DEBUGMODE5866 +Node: CPATH MPATH LPATH PPATH TPATH QPATH OPATH6530 +Node: CACHED_MOTD7758 +Node: CHROOTDIR8234 +Node: ENABLE_SUMMON ENABLE_USERS8558 +Node: SHOW_INVISIBLE_LUSERS NO_DEFAULT_INVISIBLE9094 +Node: OPER_KILL OPER_REHASH OPER_RESTART LOCAL_KILL_ONLY9777 +Node: ZIP_LINKS ZIP_LEVEL10409 +Node: SLOW_ACCEPT11420 +Node: CLONE_CHECK12038 +Node: Other #define's12378 +Node: Editing the Makefile and compiling12703 +Node: The ircd-conf file13343 +Node: Machine information15375 +Node: Administrative info17471 +Node: Port connections19506 +Node: Connection Classes21716 +Node: Client connections27167 +Node: Operator priviliges32680 +Node: Restrict connections34800 +Node: Excluded accounts36115 +Node: Server connections40081 +Node: Deny auto-connections48520 +Node: Hub connections49893 +Node: Leaf connections51109 +Node: Version limitations53192 +Node: Excluded machines54949 +Node: Service connections56256 +Node: Bounce server57849 +Node: Default local server (for local clients) `*OBSOLETED*'59551 +Node: Related resources60434 +Node: Reporting a bug61372 +Node: How to report a bug61632 +Node: Where to send a bug report62645 + +End Tag Table diff --git a/doc/INSTALL.sgml b/doc/INSTALL.sgml new file mode 100644 index 0000000..b24e36f --- /dev/null +++ b/doc/INSTALL.sgml @@ -0,0 +1,1388 @@ +<!doctype linuxdoc system> + +<article> + +<title>Installing IRC - The Internet Relay Chat Program +<author>SGML version by Christophe Kalt +<date>$Id: INSTALL.sgml,v 1.38 1999/08/13 17:19:52 kalt Exp $ +<abstract> +This document describes how to install, and configure IRC 2.10.3. +</abstract> + +<sect>Installing IRC. +<sect1>The configure script +<p> +This package uses a GNU configure script for its configuration. +You simply need to untar the distribution and run the +``configure'' script. This will run configure which will probe +your system for any peculiarities it has and setup the Makefile +and a file of default #define's ($arch/setup.h). +<p> +There are a few options to ``configure'' to help it out, or +change the default behaviour: +<descrip> +<tag/--prefix=DIR/ changes the default directory into which +ircd will install using ``make install''. This defaults +to /usr/local +<tag/--sbindir=DIR/ changes the default directory where the +system admin executable files will go. It is important to +set this properly. (default is prefix/sbin) +<tag/--logdir=DIR/ changes the default directory where the +irc log files will go. (default is prefix/var/log/ircd) +<tag/--sysconfdir=DIR/ changes the default directory where +the irc server configuration files will go. (default is prefix/etc) +<tag/--localstatedir=DIR/ changes the default directory +where the irc server state files will go. (default is prefix/var/run) +<tag/--resconf=FILE/ defines the file to be used by ircd to +initialize its resolver. (default is /etc/resolv.conf) +<tag/--zlib-include=DIR/ specifies in which directory the +include file from the zlib is located. +<tag/--zlib-library=DIR/ specifies in which directory the +zlib library is located. +<tag/--zlib-prefix=DIR/ specifies the prefix for zlib +location. It overrides the 2 previous options. (The +include directory is supposed to be in prefix/include, and +the library in prefix/lib). +<tag/--with-zlib/ is the default. ``configure'' looks on your +system to find the zlib. If found, ircd will be linked using +it. This does NOT mean you can use server link compression, +for this you also need to define ZIP_LINKS (see section below). +<tag/--without-zlib/ tells ``configure'' not to look for the zlib. +Defining this will keep you from using server link compression. +<tag/--enable-ip6/ Enable IPv6 support (See notes below) +<tag/--enable-dsm/ Enable Dynamically Shared Modules support for iauth +</descrip> + +<sect1>Notes for Cygwin32 users +<p> +The daemon of 2.10.3 release compiles properly on W32 +systems which have the GNU-Win32 environment (<url +url="http://www.cygnus.com/misc/gnu-win32/">) setup. At the +time of the release, tests were made using the version b20.1 +of the Cygwin32 library. +<p> +When compiling on such system, you want to make sure that +you have carefully followed the Cygwin32 installation +notes. In particular, you will need to make sure that the +following files exist: <bf>/bin/cp.exe</bf>, +<bf>/bin/mv.exe</bf>, <bf>/bin/rm.exe</bf> and +<bf>/bin/sh.exe</bf>. +<p> +Also, the IRC server needs a <bf>resolv.conf</bf> file in +order to initialize the resolver. This file can be anywhere +(see configure options), and is typically in <bf>/etc</bf> +on UNIX systems. +<p> +Finally, iauth is automatically disabled. Even though the +iauth program compiles properly, extra work is required to +have a working communication channel between the IRC server +and the iauth program. + +<sect1>Notes concerning IPv6 support +<p> +The only part of the software that doesn't use IPv6 is the +server internal resolver. It relies on the name servers +defined in ``/etc/resolv.conf'' to be IPv4 addresses. +<p> +This version was tested on the following IPv6 systems: +BSD/OS+KAME, Digital Unix, FreeBSD+KAME, Linux, NetBSD+INRIA. +<p> +Because IPv6 numeric addresses contain ``:'' characters, +<bf>the separator for the server configuration file was +changed to ``%''</bf>. + +<sect>The config.h file +<p> +The second step consists of defining options before the +compilation. This is done by editing the ``config.h'' file +and changing the various #DEFINE's. + +<sect1>Define what type of UNIX your machine uses. +<p> +Pick the machine type which best describes your machine and +change the #undef to #define (if needed).Some +flavours of Unix require no #define and in such cases +all others should be #undef'd. + +<sect1>DEBUGMODE +<p> +Define DEBUGMODE if you want to see the ircd debugging +information as the daemon is running. Normally this function +will be undefined as ircd produces a considerable amount of +output. DEBUGMODE must be defined for either of -t or -x +command line options to work. Defining this induces a large +overhead for the server as it does a large amount of self +diagnostics whilst running. +<p> +<bf>This should only be defined for test purposes, and never +used on a production server.</bf> + +<sect1>CPATH, MPATH, LPATH, PPATH, TPATH, QPATH, OPATH +<p> +Define CPATH to be the directory path to the ``ircd.conf'' +file. This path is usually /usr/local/lib/ircd/ircd.conf. The +format of this file will be discussed later. +<p> +The LPATH #define should be set to ``/dev/null'' unless +you plan to debug the ircd program. Note that the logfile grows +very quickly. +<p> +Define MPATH to be the path to the ``motd'' (message of the +day) file for the server. Keep in mind this is +automatically displayed whenever anyone signs on to your +server. +<p> +The PPATH is optional, but if defined, should point to a +file which either doesn't exist (but is creatable) or a +previously used PPATH file. It is used for storing the +server's PID so a ps(1) isn't necessary. +<p> +Define QPATH to be the directory path to the ``iauth.conf'' +file. This path is usually /usr/local/lib/ircd/iauth.conf. +The format of this file is described by a manual page. +<p> +The OPATH #define should be set to ``/dev/null'' unless +you plan to debug the iauth program. Note that the logfile grows +very quickly. + +<sect1>CACHED_MOTD +<p> +The server sends the ``motd'' to every client connecting. +Every time, it reads it from the disk. This is quite +intensive and can be undesirable for busy servers. +<p> +Defining CACHED_MOTD will make the server store the ``motd'' +in memory, and only read it again from the disk when +rehashing if the file has changed. + +<sect1>CHROOTDIR +<p> +To use the CHROOTDIR feature, make sure it is #define'd +and that the server is being run as root. The server will +chroot to the directory name provded by ``IRCDDIR'' (in +Makefile). + +<sect1>ENABLE_SUMMON, ENABLE_USERS +<p>For security conscious server admins, they may wish to +leave ENABLE_USERS undefined, disabling the USERS command +which can be used to glean information the same as finger +can. ENABLE_SUMMON toggles whether the server will attempt +to summon local users to irc by writing a message similar to +that from talk(1) to a user's tty. + +<sect1>SHOW_INVISIBLE_LUSERS, NO_DEFAULT_INVISIBLE +<p> +On large IRC networks, the number of invisible users is +likely to be large and reporting that number cause no pain. +To aid and effect this, SHOW_INVISIBLE_LUSERS is provided to +cause the LUSERS command to report the number of invisible +users to all people and not just operators. The +NO_DEFAULT_INVISIBLE define is used to toggle whether +clients are automatically made invisible when they register. + +<sect1>OPER_KILL, OPER_REHASH, OPER_RESTART, LOCAL_KILL_ONLY +<p>The three operator only commands, KILL, REHASH and +RESTART, may all be disabled to ensure that an operator who +does not have the correct privilidges does not have the +power to cause untoward things to occur. To further curb the +actions of guest operators, LOCAL_KILL_ONLY can be defined +to only allow locally connected clients to be KILLed. + +<sect1>ZIP_LINKS, ZIP_LEVEL +<p> +As of the 2.9.3 version of the server, server-server +connections may be compressed using the zlib. In order to +compile the server with this feature, you MUST have the zlib +package (version 1.0 or higher) already compiled and define +ZIP_LINKS in the config.h file. Compression use for +server-server connections is separately configured in the +ircd.conf file for each server-server link. ZIP_LEVEL +allows you to control the compression level that will be +used. Values above 5 will noticeably increase the CPU used +by the server. +<p> +The zlib package may be found at <url +url="http://www.cdrom.com/pub/infozip/zlib/">. The data format used +by the zlib library is described by RFCs (Request for +Comments) 1950 to 1952 in the files <url +url="ftp://ds.internic.net/rfc/rfc1950.txt"> (zlib format), +rfc1951.txt (deflate format) and rfc1952.txt (gzip +format). These documents are also available in other formats +from <url url="ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html"> + +<sect1>SLOW_ACCEPT +<p> +This option is defined by default and is needed on some +OSes. It creates an artificial delay in processing incoming +connections. On a given port, no more than 1 connection per +2 seconds will be processed. +<p> +Undefining this will let the server process connections as +fast as it can which can cause problems on some OSes (such +as SunOS) and be abused (fast massive join of clonebots..), +for these reasons, if you decide to undefine SLOW_ACCEPT you +MUST define CLONE_CHECK. + +<sect1>CLONE_CHECK +<p> +This option acts as a wrapper, by checking incoming +connections early before starting ident query. By default, +the server will not accept more than 2 connections from the +same host within 10 seconds. + +<sect1>Other #define's +<p> +The rest of the user changable #define's should be +pretty much self explanatory in the config.h file. It is +*NOT* recommended that any of the file undef the line with +"STOP STOP" in it be changed. + +<sect>Editing the Makefile, and compiling +<p> +This package now uses GNU autoconf to probe your system and +generate the correct Makefile. However you need to edit it +to specify specific information, such as ``prefix'', +``irc_mode'', ``ircd_mode'' and ``ircd_dir''. +<p> +Now to build the package, type ``make all''. If everything +goes will, you can then install it by typing ``make install''. +<p> +If you have trouble compiling ircd, copy Makefile.in to +Makefile and edit Makefile as appropriate. + +<sect>The ircd.conf file +<p> +After installing the ircd and irc programs, edit the +ircd.conf file as per the instructions in this section and +install it in the location you specified in the config.h +file. There is a sample conf file called example.conf in +the doc/ directory. +<p> +Appendix A (See INSTALL.appendix) describes the differences +between IP addresses and host names. If you are unfamiliar +with this, you should probably scan through it before +proceeding. +<p> +The ircd.conf file contains various records that specify +configuration options. The record types are as follows: +<enum> +<item>Machine information (M) +<item>Administrative info (A) +<item>Port connections (P) +<item>Connection Classes (Y) +<item>Client connections (I,i) +<item>Operator privileges (O) +<item>Restrict lines (R) +<item>Excluded accounts (K,k) +<item>Server connections (C,c,N) +<item>Deny auto-connections (D) +<item>Hub connections (H) +<item>Leaf connections (L) +<item>Version limitations (V) +<item>Excluded machines (Q) +<item>Service connections (S) +<item>Bounce server (B) +<item>Default local server (U) +</enum> +<p> +Except for types ``M'' and ``A'', you are allowed to have +multiple records of the same type. In some cases, you can +have concurrent records. <bf>It is important to note that +the last matching record will be used</bf>. This is +especially useful when setting up I records (client +connections). + +<sect1>Machine information +<p> +<descrip> +<tag/Introduction/ +IRC needs to know a few things about your UNIX site, and the +``M'' command specifies this information for IRC. The fomat +of this command is: +<tag/Format/ +<verb>M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port></verb> +<tag/M/ +``M'' specifies a Machine description line +<tag/Server NAME/ +The name of YOUR server adding any Internet DOMAINNAME that +might also be present. If this hostname can be resolved, the +IP# found will be used to for outgoing connections. +Otherwise the default interface address of the host is used. +The server name may not be FQDN of another host. (This +means all outgoing connections will be done from the same +IP#, even if your host has several IP#). +<tag/YOUR Internet IP#/ +If the machine on which you run the server has several IP +addresses, you can define which IP# to use for outgoing +connections. This overrides overrides the ``Server NAME''. +<p>See Also the ``Port Connections'' section. +<tag/Geographic Location/ +Geographic Location is used to say WHERE YOUR SERVER is, and +gives people in other parts of the world a good idea of +where you are! If your server is in the USA, it is usually +best to say: <CITY> <STATE>, USA. Like for +Denver I say: ``Denver Colorado, USA''. Finnish sites (like +tolsun.oulu.fi generally say something like ``Oulu, +Finland''. +<tag/Port/ +Defines the port on which your server will listen for UDP +pings from other servers. This should be the port were +other servers are set to autoconnect. (Also see the port +field description in connect lines). +<tag/Example:/ +M:tolsun.oulu.fi::Oulu, Finland:6667: +<p> +This line reads: My Host's name is ``tolsun.oulu.fi'' and my +site is located in ``Oulu, Finland''. +<p> +M:orion.cair.du.edu::Denver Colorado, USA:6667: +<p> +This line reads: My Hosts name is ``orion.cair.du.edu'' and +my site is located in ``Denver Colorado, USA''. +</descrip> +<p> + +<sect1>Administrative info +<p> +<descrip> +<tag/Introduction/ The ``A'' line is used for administrative +information about a site. The e-mail address of the person +running the server should be included here in case problems +arise. +<tag/Format/<verb>A:<Your Name/Location>:<Your Electronic Mailing Addr>:<other>::</verb> +<tag/A/This specifies an Admin record. +<tag/Your Name & Location/ Use this field to say tell +your FULL NAME and where in the world your machine is. Be +sure to add your City, State/Province and Country. +<tag/Your Electronix Mailing Addr/ Use this field to specify +your Electronic Mailing Address preferably your Internet +Mailing Address. If you have a UUCP or ARAPnet address - +please add that as well. Be sure to add any extra DOMAIN +information that is needed, for example ``mail jtrim@orion'' +probably won't work as a mail address to me if you happen to +be in Alaska. But ``mail jtrim@orion.cair.du.edu'' would +work because you know that ``orion'' is part of the DOMAIN +``cair.du.edu''. So be sure to add your DOMAINNAMES to your +mailing addresses. +<tag/Other/ This is really an OTHER field - you can add what +you want here. +<tag/Example/ +(the line is just one line in the confuration file, here it +is cut into two lines to make it clearer to read): +<p> +A:Jeff Trim - Denver Colorado, USA:INET jtrim@orion.cair.du.edu UUCP {hao,isis}!udenva!jtrim:Terve! Heippa! Have you said hello in Finnish today?;):: +<p> +Would look like this when printed out with the /admin command: +<p> +Jeff Trim - Denver Colorado, USA +INET jtrim@orion.cair.du.edu UUCP {hao,isis}!udenva!jtrim +Terve! Hei! Heippa! Have you said hello in Finnish today? ;) +<p> +Note that the A record cannot be split across multiple +lines; it will typically be longer than 80 characters and +will therefore wrap around the screen. +</descrip> + +<Sect1>Port connections +<p> +<descrip> +<tag/Introduction/ The port line adds flexibility to the +server's ability to accept connections. By use of this line +in the ircd.conf file, it is easy to setup both Unix Domain +ports for the server to accept connections on as well as +extra internet ports. +<tag/Format/<verb>P:<Internet IP#>:<*>:<Internet IP Mask>:<Port>: +P:<Directory>:<*>:<*>:<Port>:</verb> +</descrip> +<itemize> +<item>Internet Ports +<descrip> +<tag/Internet IP#/ If the host on which the server runs has +several IP addresses, you can define for which IP address +connections will be accepted. If no is defined here, server +will bind to all interfaces (INADDR_ANY). See also MACHINE +CONFIGURATION section to properly configure outgoing +connections. +<p> +P:192.168.1.194:::6664: +<tag/Internet IP# Mask/ This defines where connections may +come from and be accepted. The IP mask uses either *'s or +0's as wildcards. The following two lines are the same: +<p> +<verb>P:::128.2.*:6664: +P:::128.2.0.0:6664: +</verb> +<p> +The incoming isn't matched against the mask, rather the ip# +string is decoded and compared segment by segment. Thus +<p> +P:::128.2*.1.2:6664: +<p> +will not match 128.20.1.2. +<tag/Port/ The port number field tells the server which port +number it should listen on for incoming connections. +</descrip> +<item> Unix Socket Ports. +<descrip> +<tag/Directory/ The path set in this field should be the +directory name in which to create the unix socket for later +listening to. The server will attempt to create the +directory before creating the unix socket. +<tag/Port/ The port field when used in combination with a +pathname in a P-line is the filename created in the +directory set in the first field. +<tag/Example/ P:/tmp/.ircd:::6667: +<p> +Creates a unix socket in the /tmp/.ircd directory called +``6667''. The unix socket (file) must be a numerical. +</descrip> +</itemize> +<descrip> +<tag/Note/ You need at least one P line. +</descrip> + +<sect1>Connection Classes +<p> +<descrip> +<tag/Introduction/ To enable more efficient use of +MAXIMUM_LINKS, connection classes were implemented. All +clients belong to a connection class. +<p>Each line for a server should have the same number as the +sixth field. If it is absent, the server deaults it to 0, +using the defaults from the config.h file. +<p>To define a connection class, you need to include a Y: +line in the ircd.conf file. This enables you to define the +ping frequency, connection frequency (for servers) and +maximum number of links that class should have. +<p>Currently, the Y: line <bf>MUST</bf> appear in the +ircd.conf file <bf>BEFORE</bf> it is used in any other way. +<tag/Format/<verb>Y:<Class>:<Ping Frequency>:<Connect freq>:<Max Links>:<SendQ>:<Local Limit>:<Global Limit></verb> +<tag/Y/ This specifies a Class record. +<tag/Class/ This is the class number which gains the following +attributes and should match that which is on the end of the +C/c/N/I/O/S line. +<tag/Ping Frequency/ This field defines how long the server will let +the connection remain ``silent'' before sending a PING message +to make sure it is still alive. Unless you are sure of what +you are doing, use the default value which is in your +config.h file. +<tag/Connect Frequency/ By changing this number, you change +how often your server checks to see if it can connect to +this server. If you want to check very occasionally, use a +large value, but if it is an important connection, you might +want a smaller value so that you connect to it as soon as +possible. +<tag/Max Links/ This field defines the maximum number of +links this class will allow from automatic connections (C +lines). Using /CONNECT overrides this feature. Also +defines the maximum number of users in this class for I/O +lines per I/O line. +<tag/SendQ/ This field defines the ``SendQ'' value for this +class. If this field is not present, the default (from +config.h) is assigned. +<tag/Local limit/ This field is used to limit the number +of local concurrent connections. The format is +<x>.<y> +<itemize> +<item> x: defines the maximum number of clients from the +same host (IP) will be allowed. +<item> y: defines the maximum number of clients from the +same user@host (IP) will be allowed. Read note below. +</itemize> +Only x or y may be set, any unset value defaults to zero. +<tag/Global limit/ This field has the same use as the +``Local limit'' field. But, the connection counts are done +for all clients present on the net instead of only counting +local clients. +<tag/Note/ leaving any of the fields (except SendQ) out +means their value is 0 (ZERO)!! The SendQ field default +value is dynamically determined. +<tag/Note/ If you plan to use the local user@host limit, +please read the following very carefully. The ``user'' +value is the ident reply for the connection. If no reply +was given then it defaults to ``unknown'' and thus the +effective limit will be per host, not per user@host. Also, +some ident servers return encrypted data which changes for +every connection making the limit void. +<tag/Note/ Only the local limitation is accurate. +<tag/Note/ If you define a gobal limit, you should also +define a local limit (same or lower) as it won't take more +CPU and will make the global limit more accurate. +<tag/Note/ The local and global limits only affect users (I +lines), not servers nor services. +<tag/Example/ Y:23:120:300:5:100000:0:0: (server class) +<p> +This defines class 23 to allow 5 auto-connections, which are +checked every 300 seconds. The connection is allowed to +remain silent for 120 seconds before a PING is sent. NOTE: +fields 3 & 4 are in seconds. The SendQ is set to 100000 +bytes. +<p> +Another feature of connection class is the ability to do +automatic routing by using the class as a ``priority''. If +you are connected to a server which has a class lower than +one of the servers that is ``behind'' it, the server will +disconnect the lower class one and schedule a ``new'' +connection for the higher class server. +<p> +Y:1:60:0:50:20000:2:5: (client class) +<p> +In case of a client class, the fields are interpreted a bit +differently. This class (number 1) can be used by up to 50 +users. The connections are allowed to remain silent for 60 +seconds before a PING is set. The SendQ is set to 20000 +bytes. A new connection in this class will only be allowed +if there aren't more than 2 other local connections from the +same IP address, or more than 5 other connections on the net +from the same hostname. +<p> +Y:2:60:0:50:20000:2.1:5: (client class) +<p> +In case of a client class, the fields are interpreted a bit +differently. This class (number 1) can be used by up to 50 +users. The connections are allowed to remain silent for 60 +seconds before a PING is set. The SendQ is set to 20000 +bytes. A new connection in this class will only be allowed +if there aren't more than 2 other local connections from the +same IP address, 1 other local connection from the same user +from the same IP address, or more than 5 other connections +on the net from the same hostname. +</descrip> + +<sect1>Client connections +<p> +How to let clients connect to your IRCD. +<descrip> +<tag/Introduction/ A client is a program that connects to +the ircd daemon (ircd). There are clients written in C, GNU +Emacs Lisp and many other languages. The ``irc'' program is +the C client. Each person that talks via IRC is running +their own client. +<p> +The ircd.conf files contains entries that specify which +clients are allowed to connect to your irc daemon. +Obviously you want to allow your own machine's clients to +connect. You may want to allow clients from other sites to +connect. These remote clients will use your server as a +connection point. All messages sent by these clients will +pass through your machine. +<tag/Format/ +<verb>I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> +i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class></verb> +<tag/TARGET Host Addr/Specifies the IP address(es) of the +machine(s) that are allowed to connect. If ``user@'' +prefixes the actual IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. Wildcards are permitted +unless using a bitmask (e.g. 1.2.3.0/24). +<tag/Password/The password that must be given by the client +to be allowed on the server. +<tag/TARGET Host NAME/Specifies the host name(s) of the +machines allowed to connect to the server. If ``user@'' +prefixes the actual IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. Wildcards are permitted. +<p> +This field can be empty, it then has a special meaning. See +Below. +<tag/Port/Specifies the port number for which this +configuration line is valid. An empty field, or ``0'' +matches all ports. +<tag/Class/This field should refer to an existing class. +Connections classes are usefull to limit the number of users +allowed on the server. +<tag/Note/The server first checks if the client hostname (or +any aliases) matches the <bf>TARGET Host NAME</bf> field. +If a match is found, the client is accepted. If not, the +server checks if the IP address of the client matches the +<bf>TARGET Host Addr</bf> field. The matching field is used +to set the name of the client: for example, if the client +matches the <bf>TARGET Host Addr</bf> field, it will show on +IRC with a numerical address (even if this address is +resolvable). If the <bf>TARGET Host NAME</bf> field is +empty, then the host name is always used (when available). +<tag/Examples/ +For example, if you were installing IRC on tolsun.oulu.fi +and you wanted to allow examples sake let us assume you were +making this file for tolsun and you wanted to let your own +clients to connect to your server, you would add this entry +to the file: +<p> +I:x::tolsun.oulu.fi::1 +<p> +If you wanted to let remote clients connect, you could add +the following lines: +<p> +I:x::*.du.edu::1 +<p> +Allow any clients from machines whose names end in +``.du.edu'' to connect with no password. +<p> +I:128.214.6.100::nic.funet.fi::1 +<p> +Allow clients from a machine with that IP number to +connect. Numeric match is enough, name is not required +anymore. +<p> +I:x:secret:*.tut.fi::1 +<p> +Allow clients from machines matching ``*.tut.fi'' to connect +with the password ``secret''. +<p> +I:*::*::1 +<p> +Allow anyone from anywhere to connect your server. +<p> +This is the easiest way, but it also allows people to for +example dump files to your server, or connect 1000 (or how +many open sockets per process your OS allows) clients to +your machine and take your network ports. Of course the same +things can be done by simply telnetting to your machine's +SMTP port (for example). +<p> +I:x::*.fi:6667:1 +<p> +Allow clients from machines matching ``*.fi'' to connect on +the port 6667. +<p> +I:135.11.35.*::*.net::1 +<p> +Allows clients from machines which host name matches +``*.net'' or which IP address matches ``135.11.35.*'' to +connect to the server. If the host name does not match +``*.net'' then the IP address is used for these clients, +even if the host name is known. +<p> +I:135.11.35.*::::1 +<p> +Allows clients from machines which IP address matches +``135.11.35.*'' to connect to the server. If the host name +is known, is it used as address for these clients. +<tag/NEW!!!/ As of the 2.7.2d version of the server, the +server is able to accept connections on multiple +ports. I-lines are required for each P-line to allow +connections to be accepted. For unix sockets, this means +either adding I:/path/port::/path/port or some variation +(wildcards are recognised here). For internet ports, there +must be an I-line which allows the host access as normal, +but the port field of the I-line must match that of the port +of the socket accepting the connectiion. A port number of 0 +is a wildcard (matches all ports). +<tag/NEW!!!/ As of the 2.9.1 version of the server, i lines +are introduced. They work the same way as I lines, but the +clients matching an i line will have a restricted +connection. (no nick/mode change, no kick). Such users will +have their username prefixed by +, = or - depending on the +ident reply. +</descrip> + +<sect1>Operator priviliges +<p> +How to become the IRC administrator on your site +<descrip> +<tag/Introduction/ To become an IRC Administrator, IRC must +know who is authorized to become an operator and what their +``Nickname'' and ``Password'' is. +<tag/Format/<verb>O:<TARGET Host NAME>:<Password>:<Nickname>:<Port>:<Class></verb> +<tag/O/ Speficies Operator record. If you use capital letter +(``O'') in it, it specifies a global operator. Small letter +(``o'') specifies a local operator. Local operator has +basically the same rights except global operator with some +restrictions. +<tag/TARGET Host NAME/ Tells IRC which host you have the +privileges FROM. This means that you should be logged into +this host when you ask for the priviliges. If you specify +``tolsun.oulu.fi'' then IRC will expect your CLIENT to be +connected at ``tolsun.oulu.fi'' - when you ask for OPERATOR +privileges from ``tolsun.oulu.fi''. You cannot be logged in +at any other host and be able to use your OPERATOR +privileges at tolsun, only when you are connected at TOLSUN +will this work - this is a safeguard against unauthorized +sites. +<tag/Password/ If your AUTHORIZATION Password - this is the +password that let's IRC know you are who you say you are! +Never tell anyone your password and always keep the +``ircd.conf'' file protected from all of the other users. +<tag/Nickname/ The Nickname you usually go by - but you can +make this what you want. +<tag/Port/ Unused. +<tag/Class/ The class field should refer to an existing +class (preferably having a lower number than that for the +relevant I-line) and determines the maximum number of +simultaneous uses of the O-line allowable through the +max. links field in the Y-line. +<tag/Example/ O:orion.cair.du.edu:pyunxc:Jeff::1 +<p> +There is an OPERATOR at ``orion.cair.du.edu'' that can get +Operator priviliges if he specifies a password of ``pyunxc'' +and uses a NICKNAME of ``Jeff''. +</descrip> + +<sect1>Restrict connections +<p> +Let an external program decide if a client should be allowed +or not. +<descrip> +<tag/Introduction/ R lines provide a convenient way to +handle user access to the server with an external program. +The outside program given three parameters: the client's +username (set by the USER command), the client's hostname, +and the client's ident reply (``unknown'' if none). +<p>It is expected to return a reply line where the first +word is either ``Y'' or ``N'' meaning `Yes Let them in'' or +``No don't let them in''. If the first word begins with +neither ``Y'' or ``N'' the default is to let the person on. +<tag/Format/ +<verb>R:<Target Host Name>:<Program>:<User>:::</verb> +<tag/R/This specifies a restrict record. +<tag/Target Host Name/ In this field you specify the +Hostname that the user is connecting from. If you wanted to +restrict connects to IRC from ``orion.cair.du.edu'' then you +would want to enter ``orion.cair.du.edu''. +<tag/Program/ This is the external program to run to know if +the user is allowed on your server. +<tag/User/ The Username of the user you want removed from +IRC. For example ``root''. +</descrip> + +<sect1>Excluded accounts +<p> +Remove an errant user from IRC on your site. +<descrip> +<tag/Introduction/ +Obviously it is hoped that you wouldn't have to use this +command. Unfortunately sometimes a user can become +unmanageable and this is your only recourse - the KILL USER +command. THIS COMMAND ONLY AFFECTS YOUR SERVER - If this +user can connect to another SERVER somewhere else in the +IRC-Network then you would have to talk to the administrator +on that site to disable his access from that IRCD Server as +well. +<tag/Format/<verb>K:<Host Name>:<time interval(s)|comment>:<User>:<port>:</verb> +<tag/Format/<verb>k:<Host Name>:<time interval(s)|comment>:<Auth>:<port>:</verb> +<tag/K/``K'' tells the IRCD that you are making a KILL USER +command entry. +<tag/Host Name/ In this field you specify the Hostname or +the IP address (Single IP, Wildcard notation or bitmask +notation) that the user is connecting from. If you wanted +to REMOVE connects to IRC from ``orion.cair.du.edu'' then +you would want to enter ``orion.cair.du.edu''. If you want +to REMOVE ALL HOSTS access you can use ``*'' (Wild Card +notation) and no matter what host the USERNAME (specified in +Field 4) connects from s/he will be denied access. Removing +all hosts isn't very smart thing to do though, why would you +run an ircd if you allow nobody to connect to it anyways ? +<p> +If you specify an IP address, IP mask, or an IP bitmask, +it will match clients connecting from the matching +addresses, no matter if they resolve or not. +<p> +You can prefix an IP address, an IP mask, or IP bitmask by +``='' in which case only non resolving matching hosts will +be banned. +<tag/time interval(s)|comment/ Either leave this field empty +or put a comment, then the line active continuously for the +specified user/host machine. You may also specify intervals +during the line should be active, see examples below. +<tag/User/ The USERNAME of the user you want removed from +IRC. For example ``root''. +<tag/Auth/ If the user's ident server replies with the OTHER +type (as opposed to the UNIX type), the reply is not used to +set the user's username. (lowercase) k lines can be used in +these case to reject users based on their ident reply. +<p> +This field will be matched against the ident server reply. +It is important to note that OTHER replies are prefixed with +a ``-'' by the ircd, while UNIX replies are not. +<tag/Port/ The port on which the Kill line will be +effective. 0 means all ports. +<tag/Examples/ K:orion.cair.du.edu::jtrim:0: +<p> +If user ``jtrim'' connects to IRC from host +``orion.cair.du.edu'' then IMMEDIATELY REMOVE HIM from my +IRCD. +<p> +k:*.stealth.net::-43589:0: +<p> +If a user connects from any host that has the suffix +``stealth.net'' and if that host ident server returns +``-43589'' - then IMMEDIATELY REMOVE THEM from my IRCD. +<p> +K:*.cair.du.edu::root:0: +<p> +If user ``root'' connects to IRC from any host that has the +suffix ``cair.du.edu'' - then IMMEDIATELY REMOVE THEM from +my IRCD. +<p> +K:*::vijay:0: +<p> +This line reads ``I don't care WHAT HOST user ``vijay'' is +on, I will NEVER allow username ``vijay'' to login to my +IRCD.'' +<p> +K:*.oulu.fi:0800-1200,1400-1900:*:0: +<p> +This disallows all users from hosts with enddomain +``oulu.fi'' access to your server between 8 and 12am, 2 and +7pm. Users get kicked off if they're already signed on when +the line becomes active (they'll get a warning 5 minutes +before). +<p> +K:192.11.35.*::*:0: +<p> +This line disallows all hosts whose IP address matches +``192.11.35.*'' to login to the ircd. +<p> +K:=192.11.35.*::*:0: +<p> +This line disallows all hosts whose IP address matches +``192.11.35.*'' and which didn't resolve to login to the +ircd. +</descrip> + +<sect1>Server connections +<p> +How to connect to other servers, How other servers can connect to you +<p> +<bf>WARNING:</bf> +The hostnames used as examples are really only examples and +not meant to be used (simply because they don't work) in +real life. +<p> +Now you must decide WHICH hosts you want to connect to and +WHAT ORDER you want to connect to them in. For my example +let us assume I am on the machine "rieska.oulu.fi" and I +want to connect to irc daemons on 3 other machines: +<itemize> +<item>``garfield.mit.edu'' - Tertiary Connection +<item>``irc.nada.kth.se'' - Secondary Connection +<item>``nic.funet.fi'' - Primary Connection +</itemize> +<p> +And I prefer to connect to them in that order, meaning I +first want to try connecting to ``nic.funet.fi'', then to +``irc.nada.kth.edu'', and finally to ``garfield.mit.edu''. +So if ``nic.funet.fi'' is down or unreachable, the program +will try to connect to ``irc.nada.kth.se''. If +irc.nada.kth.se is down it will try to connect to garfield +and so forth. +<p> +PLEASE limit the number of hosts you will attempt to connect +to down to 3. This is because of two main reasons: +<enum> +<item> to save your server from causing extra load and +delays to users +<item> to save internet from extra network traffic (remember +the old rwho program with traffic problems when the number +of machines increased). +</enum> +<p> +<descrip> +<tag/Format/ <verb>C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET PORT>:<Class></verb> +<p> +for example: +<p> +C:nic.funet.fi:passwd:nic.funet.fi:6667:1 +<p> + - or - +<p> +C:128.214.6.100:passwd:nic.funet.fi:6667:1 +<p> + - or - +<p> +C:root@nic.funet.fi:passwd:nic.funet.fi:6667:1 +<p> +Each field is separated with a ":" charcter: +<tag/C/ This field tells the IRC program which option is +being configured. "C" corresponds to a server Connect +option. +<tag/TARGET Host Addr/ Specifies the host name or IP address +of the machine to connect to. If ``user@'' prefixes the +actual hostname or IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. +<tag/Password/ The password of the other host. A password +must always be present for the line to be recognized. +<tag/TARGET Host NAME/ The full hostname of the target +machine. This is the name that the TARGET server will +identify itself with when you connect to it. If you were +connecting to nic.funet.fi you would receive +``nic.funet.fi'' and that is what you should place in this +field. +<tag/TARGET PORT/ The INTERNET Port that you want to connect +to on the TARGET machine. Most of the time this will be set +to ``6667''. If this field is left blank, then no +connections will be attempted to the TARGET host, and your +host will accept connections FROM the TARGET host instead. +The port field can contain 2 ports, separated by a . In this +case, the first port is used when auto-connecting, the +second port is used for the UDP pings to the targer server. +<tag/Class/ The class field should refer to an existing +class and determines the maximum number of simultaneous uses +of the C-line allowable through the max. links field in the +Y-line. +<tag/NEW!!!/ As of the 2.9.3 version of the server, server connections can be compressed with the zlib library. To define a compressed connection, you must have compiled the server with ZIP_LINKS defined (cf 2.h), and use a _lowercase_ C line. +</descrip> +<p> +Some examples: +<itemize> +<item>C:nic.funet.fi::nic.funet.fi:6667:1 +<p> +This reads: Connect to host ``nic.funet.fi'', with no +password and expect this server to identify itself to you as +``nic.funet.fi''. Your machine will connect to this host to +port 6667. +<item>C:18.72.0.252:Jeff:garfield.mit.edu:6667:1 +<p> +This reads: Connect to a host at address ``18.72.0.252'', +using a password of ``Jeff''. The TARGET server should +identify itself as ``garfield.mit.edu''. You will connect +to Internet Port 6667 on this host. +<item>C:irc.nada.kth.se::irc.nada.kth.se:1 +<p> +This reads: do not attempt to connect to +``irc.nada.kth.se'', if ``irc.nada.kth.se'' requests a +connection, allow it to connect. +</itemize> +<p> +Now back to our original problem, we wanted OUR server +CONNECT to 3 hosts, ``nic.funet.fi'', ``irc.nada.kth.se'' +and ``garfield.mit.edu'' in that order. So as we enter +these entries into the file they must be done in +<bf>reverse</bf> order of how we could want to connect to +them. +<p> +Here's how it would look if we connected ``nic.funet.fi'' first: +<p> +C:garfield.mit.edu::garfield.mit.edu:6667:1 +C:irc.nada.kth.se::irc.nada.kth.se:6667:1 +C:nic.funet.fi::nic.funet.fi:6667:1 +<p> +Ircd will attempt to connect to nic.funet.fi first, then to +irc.nada and finally to garfield. +<p> +<bf>Reciprocal entries:</bf> +Each ``C'' entry requires a corresponding ``N'' entry that +specifies connection priviliges to other hosts. The ``N'' +entry contains the password, if any, that you require other +hosts to have before they can connect to you. These entries +are of the same format as the ``C'' entries. +<p> +<descrip> +<tag/Format/ The format for the NOCONNECT entry in the ``ircd.conf'' is: +<verb>N:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<Domain Mask>:<Class></verb> +<p> +Let us assume that ``garfield.mit.edu'' connects to your +server and you want to place password authorization +authorization on garfield. The ``N'' entry would be: +<p> +N:garfield.mit.edu:golden:garfield.mit.edu:: +<p> +This line says: expect a connection from host +``garfield.mit.edu'', and expect a login password of +``golden'', and expect the host to identify itself as +``garfield.mit.edu''. +<p> +N:18.72.0.252::garfield.mit.edu:: +<p> +This line says: expect a Connection from host +``18.72.0.252'', and don't expect login password. The +connecting host should identify itself as +``garfield.mit.edu''. +<tag/N/ ``N'' corresponds to a server Noconnect option. +<tag/TARGET Host Addr/ Specifies the host name or IP address +of the machine to connect to. If ``user@'' prefixes the +actual hostname or IP address the server will require that +the remote username returned by the ident server be the same +as the one given before the ``@''. +<tag/Password/ The password of the other host. A password +must always be present for the line to be recognized. If +CRYPT_LINK_PASSWORD is defined in config.h, this password +must be crypted. +<tag/TARGET Host NAME/ The full hostname of the target +machine. This is the name that the TARGET server will +identify itself with when you connect to it. If you were +connecting to nic.funet.fi you would receive +``nic.funet.fi'' and that is what you should place in this +field. +<tag/Domain Mask/ Domain masking, see below. +<tag/Class/ The class field should refer to an existing class. +<tag/Wildcards domains/ To reduce the great amount of +servers in IRCnet wildcard DOMAINS were introduced in +2.6. To explain the usage of wildcard domains we take an +example of such: +<p> +*.de - a domain name matching all machines in Germany. +<p> +Wildcard domains are useful in that ALL SERVERS in Germany +(or any other domain area) can be shown as one to the rest +of the world. Imagine 100 servers in Germany, it would be +incredible waste of netwotk bandwidth to broadcast all of +them to all servers around the world. +<p> +So wildcard domains are a great help, but how to use them ? +<p> +They can be defined in the N-line for a given connection, in +place of ``Domain Mask'' you write a magic number called +wildcard count. +<p> +Wildcard count tells you HOW MANY PARTS of your server's +name should be replaced by a wildcard. For example, your +server's name is ``tolsun.oulu.fi'' and you want to +represent it as ``*.oulu.fi'' to ``nic.funet.fi''. In this +case the wildcard count is 1, because only one word (tolsun) +is replaced by a wildcard. +<p> +If the wildcard count would be 2, then the wildcard domain +would be ``*.fi''. Note that with wildcard name ``*.fi'' you +could NOT connect to ``nic.funet.fi'' because that would +result in a server name <bf>collision</bf> (*.fi matches +nic.funet.fi). +<p> +I advice you to not to use wildcard servers before you know +for sure how they are used, they are mostly beneficial for +backbones of countries and other large areas with common +domain. +</descrip> +<p> + +<sect1>Deny auto-connections +<p> +<descrip> +<tag/Introduction/ D lines were implemented to give server +administrators more control on how auto connections are +done. This will most likely only be useful for big networks +which have complex configurations. +<tag/Format/<verb>D:<Denied Server Mask>:Denied Class:<Server Name>:Server Class: +</verb> +<tag/Denied Server Mask/ This field is matched against all +servers currently present on the network. +<tag/Denied Class/ If this field contains a class number, +it will match if any server in that class is currently +present on the network. Note that this can be true for any +server, even the ones not directly connected. +<tag/Server Mask/ This field is matched against the server +name that the server wants to auto connect to. +<tag/Server Class/ This field is used to match against the +class to which belong the servers for which an autoconnect +is set. +<tag/Examples/D:*.edu::*.fi:: +<p> +Don't auto-connect to any ``*.fi'' server if any server +present on the network matches ``*.edu''. +<p> +D::2:eff.org:3: +<p> +Do now auto-connect to ``eff.org'', or any server in class +``3'' if a server defined to be in class ``2'' is currently +present on the network. +</descrip> + +<sect1>Hub connections +<p> +<descrip> +<tag/Introduction/ In direct contrast to L-lines, the server +also implements H-lines to determine which servers may act +as a hub and what they may ``hub for''. If a server is only +going to supply its own name (ie act as a solitary leaf) +then no H-line is required for, else a H-line must be added. +<tag/Format/<verb>H:<Server Mask>:*:<Server Name>:: +</verb> +<tag/Server Mask/ All servers that are allowed via this +H-line must match the mask given in this field. +<tag/Server Name/ This field is used to match exactly +against a server name, wildcards being treated as literal +characters. +<tag/Examples/H:*.edu::*.bu.edu:: +<p> +Allows a server named ``*.bu.edu'' to introduce only servers +that match the ``*.edu'' name mask. +<p> +H:*::eff.org:: +<p> +Allows ``eff.org'' to introduce (and act as a hub for) any +server. +<tag/Note/ It is possible to have and use multiple H-lines +(or L-lines) for the one server. eg: +<p> +<verb>H:*.edu:*:*.bu.edu:: +H:*.au:*:*.bu.edu:: +</verb> +<p> +is allowed as is +<p> +<verb>L:*.edu:*:*.au:: +L:*.com:*:*.au:: +</verb> +</descrip> + +<sect1>Leaf connections +<p> +<descrip> +<tag/Introduction/ To stop servers which should only act as +leaves from hubs becoming hubs accidently, the L line was +introduced so that hubs can be aware of which servers should +and shouldnt be treated as leaves. A leaf server is supposed +to remain a node for the entirity of its life whilst +connected to the IRC server network. It is quite easy, +however for a leaf server to be incorrectly setup and create +problems by becoming a node of 2 or more servers, ending its +life as a leaf. The L line enables the administrator of an +IRC ``Hub server'' to ``stop'' a server which is meant to +act as a leaf trying to make itself a hub. If, for example, +the leaf server connects to another server which doesnt have +an L-line for it, the one which does will drop the +connection, once again making the server a leaf. +<tag/Format/<verb>L:<Server Mask>:*:<Server Name>:<Max Depth>:</verb> +<tag/Server Mask/ Mask of which servers the leaf-like +attributes are used on when the server receives SERVER +messages. The wildcards * and ? may be used within this +field for matching purposes. If this field is empty, it +acts the same as if it were a single * (ie matches +everything). +<tag/Server Name/ The name of the server connected to you +that for which you want to enforce leaf-like attributes +upon. +<tag/Max Depth/ Maximum depth allowed on that leaf and if +not specified, a value of 1 is assumed. The depth is +checked each time a SERVER message is received by the +server, the hops to the server being the field checked +against this max depth and if greater, the connection to the +server that made its leaf too deep has its connection +dropped. For the L-line to come into effect, both fields, 2 +and 4, must match up with the new server being introduced +and the server which is responsible for introducing this new +server. +</descrip> + +<sect1>Version limitations +<p> +<descrip> +<tag/Introduction/ V-lines are used to restrict server +connecting to you based on their version and on compile time +options. +<tag/Format/<verb>V:<Version Mask>:<Flags>:<Server Mask>::</verb> +<tag/Version Mask/ The matching version number strings will be rejected. +<tag/Flags/ If any flag specified in this field is found in +the peer's flags string, it will be rejected. +<tag/Server Mask/ This field is used to match server names. +The V line will be used for servers matching the mask given +in this field. +<tag/Server Type/ Both the <bf>Version Mask</bf> and the +<bf>Flags</bf> should be prefixed with the server type +identification. This implementation uses the id +``<bf>IRC</bf>'' (starting with version 2.10). +<tag/Examples/V:IRC/021001*::*:: +<p> +Disallows any ``IRC'' server which version is 2.10.1* to connect. +<p> +V:IRC/021001*:IRC/D:*:: +<p> +Disallows any ``IRC'' server which version is 2.10.1* or +which has been compiled with DEBUGMODE defined to connect. +<p> +V:*/0209*:::: +<p> +Disallows any server using the 2.9 protocol to connect. +<tag/Note/ It is possible to have and use multiple V-lines +for the one server mask. +<p> +V:IRC/021001*::*:: +<p> +V:IRC/021002*::*:: +<p> +is allowed. +<tag/Protocol Version/ Only the 4 first digit of the +<bf>Version Number</bf> are standard: they define the +protocol version. The remaining of the string is +implementation dependant; matches on this part should be +used with particular identification. +<tag/Flags/ are not standard. Therefore, this field +<bf>should always</bf> contain a specific identification. +</descrip> + +<sect1>Excluded machines +<p> +Disallowing SERVERS in your irc net. +<descrip> +<tag/Introduction/ In some cases people run into +difficulties in net administration. For one reason or +another you do not want a certain server to be in your net +(for example because of the security holes it opens for +every server if it's not secured carefully). In that case +you should use Q-lines in your server. When you specify a +server name in Q-line, everytime some server link tries to +introduce you a server (remember, all server names are +broadcast around the net), that name is checked if it +matches the Q-lines in your server. If it matches, then +<bf>your server</bf> disconnects the link. Note that just +placing Q-lines to your server probably results in <bf>your +server</bf> being left alone, unless other servers have +agreed to have the same Q-line in their ircd configuration +files as well. +<tag/Example/Q::of the security holes:foo.bar.baz:: +<p> +This command excludes a server named ``foo.bar.baz'', the +reason is given to be security holes (you should give a +reason, it is polite). The first field is unused, so leave +it empty. +</descrip> + +<sect1>Service connections +<p> +<descrip> +<tag/Introduction/ The Service is a special kind of IRC +client. It does not have the full abilities of a normal user +but can behave in a more active manner than a normal +client. +<p> +Services are not intended for interactive usage, and are +better suited for automated clients. +<tag/Format/<verb>S:<TARGET Host Mask>:<Password>:<Service Name>:<Service Type>:<Class></verb> +<tag/TARGET Host Mask/ The host mask should be set to match +the host(s) from which the service will be connecting +from. This may be either an IP# or full name (prefered). +<tag/Password/ This is the password which must be passed in +the SERVICE command. +<tag/Service Name/ The name used by the service. Services +don't have nicknames, but a static name defined by the S +line. +<tag/Service Type/ The type of service. It defines the +priviledges given to the service. Be very careful in the +types you allow. The types can be found in +include/service.h +<tag/Class/ The class field should refer to an existing class. +<tag/Notes/ A service is not a very useful sort of client, +it cannot join channels or issue certain commands although +most are available to it. Services are rejected upon sending +an unknown or unallowed command. Services however, are not +affected by flood control and can be granted special +privileges. It is therefore <bf>wise to oversee the use of +S-lines with much care.</bf> +</descrip> + +<sect1>Bounce server +<p> +<descrip> +<tag/Introduction/ This provides you a way to bounce clients +to another server. This information is provided to clients +which are denied connection, either because their connection +class is full, or the server is full, or they are not +authorized to connect. +<tag/Format/<verb>B:<Class|Host Mask>::<Server Name>:<Port>:</verb> +<tag/B/ This specifies a Bounce record. +<tag/Class|Host Mask/ This field specifies to which client +this configuration line applies to. It can be either a +connection class number, a host mask to be matched against +the client's hostname, or an IP address/mask/bitmask to be +matched against the client's IP address. +<p> +When the server is completely full, it rejects clients with +the ``All connections in use'' message. In this case, the +server doesn't process the connections at all, and has no +knowledge of the client's host name, or class number. For +these cases, this field must be empty. +<tag/Server Name/ This specifies the IRC server hostname +that the client should use. +<tag/Port/ This specifies the IRC server port that the +client should connect to. +<tag/Example/B:2::irc.stealth.net:6660: +<p> +Rejected clients in class 2 are advised to use +``irc.stealth.net'' on port 6660. +<p> +B:*.fi::irc.funet.fi:6667: +<p> +Finnish client should use irc.funet.fi when they cannot be +taken anymore. +<p> +B:::irc2.stealth.net:6667: +<p> +When the server is completely full, clients should use the +secondary server. +</descrip> + +<sect1>Default local server (for local clients) <bf>*OBSOLETED*</bf> +<p> +<descrip> +<tag/Introduction/ This defines the default connection for +the irc client. If you are running an ircd server on the +same machine, you will want to define this command to +connect to your own host. If your site is not running a +server then this command should contain the TARGET host's +connection information and password (if any). +<tag/Format/<verb>U:<TARGET Host addr>:<Password>:<TARGET Host NAME>:<Internet Port></verb> +<tag/Examples/ +U:tolsun.oulu.fi::tolsun.oulu.fi:6667<p> +U:128.214.5.6::tolsun.oulu.fi:6667<p> +U:tolsun.oulu.fi::tolsun.oulu.fi +<p> +If the port number is omitted, irc will default to using 6667. +</descrip> + +<sect>Related resources +<p> +<descrip> +<tag/Mailing list/ A list is dedicated to the people using +ircd. If you have trouble running ircd, or wish to discuss +the future, you can subscribe by sending an email to +<htmlurl url="mailto:majordomo@irc.org" +name="majordomo@irc.org">, with ``<bf>subscribe +ircd-users</bf>'' in the body. +<p> +If you just have a question and don't want to subscribe to +the list, mail to <htmlurl url="mailto:ircd-users@irc.org" +name="ircd-users@irc.org">. Be sure to indicate which +version you are using. +<tag/Development/ Technical discussions and development are +carried on ircd-dev@irc.org. People interested in very +early testing, and/or working on the source code are +welcome. This is done by sending an email to <htmlurl +url="mailto:majordomo@irc.org" +name="majordomo@irc.org">, with ``<bf>subscribe +ircd-dev</bf>'' in the body. +<tag/FAQ/ It can be found on the WWW, at <url +url="http://www.stealth.net/~kalt/irc/faq.html">. +<tag/WWW 2.9/ Vesa Ruokonen has also put serveral pages +related to the 2.9 servers on the WWW: <url +url="http://www.irc.org/~irc/server/">. +</descrip> + +<sect>Reporting a bug +<p> +If you encounter a bug in the software, here is how and +where to report it. + +<sect1>How to report a bug +<p> +To save everyone time, make sure that your e-mail contains +all the information related to your problem. In particular, +we need to know: +<descrip> +<tag/Package version/ +The IRC software version you are using: please include the +output obtained by running ``irc -v'' for the client, and/or +``ircd -v'' for the server. +<p> +Also, let us know if you have applied any patch to the +package or if it is the vanilla version. +<tag/OS/ +Please, indicate which OS version you are running. +<tag/Configuration/ +If it is related to a configuration problem with the server, +include the relevant parts of the configuration file. +<tag/Backtrace/ +If the bug results in a crash, please include the +backtrace. (This can be done, for example, by running +``gdb'' on the core file, and typing ``where''). +<tag/Fix/ +If you have a fix, don't forget to include it. +</descrip> + +<sect1>Where to send a bug report +<p> +Reports should be sent to <htmlurl url="mailto:ircd-bugs@irc.org" +name="ircd-bugs@irc.org">. Your report will be reviewed +and forwarded to the appropriate mailing list. + +</article> diff --git a/doc/INSTALL.txt b/doc/INSTALL.txt new file mode 100644 index 0000000..b8dbc63 --- /dev/null +++ b/doc/INSTALL.txt @@ -0,0 +1,1716 @@ + Installing IRC - The Internet Relay Chat Program + SGML version by Christophe Kalt + $Id: INSTALL.txt,v 1.38 1999/08/13 17:22:12 kalt Exp $ + + This document describes how to install, and configure IRC 2.10.3. + + 11.. IInnssttaalllliinngg IIRRCC.. + + 11..11.. TThhee ccoonnffiigguurree ssccrriipptt + + This package uses a GNU configure script for its configuration. You + simply need to untar the distribution and run the ``configure'' + script. This will run configure which will probe your system for any + peculiarities it has and setup the Makefile and a file of default + #define's ($arch/setup.h). + + There are a few options to ``configure'' to help it out, or change the + default behaviour: + + ----pprreeffiixx==DDIIRR + changes the default directory into which ircd will install using + ``make install''. This defaults to /usr/local + + ----ssbbiinnddiirr==DDIIRR + changes the default directory where the system admin executable + files will go. It is important to set this properly. (default is + prefix/sbin) + + ----llooggddiirr==DDIIRR + changes the default directory where the irc log files will go. + (default is prefix/var/log/ircd) + + ----ssyyssccoonnffddiirr==DDIIRR + changes the default directory where the irc server configuration + files will go. (default is prefix/etc) + + ----llooccaallssttaatteeddiirr==DDIIRR + changes the default directory where the irc server state files + will go. (default is prefix/var/run) + + ----rreessccoonnff==FFIILLEE + defines the file to be used by ircd to initialize its resolver. + (default is /etc/resolv.conf) + + ----zzlliibb--iinncclluuddee==DDIIRR + specifies in which directory the include file from the zlib is + located. + + ----zzlliibb--lliibbrraarryy==DDIIRR + specifies in which directory the zlib library is located. + + ----zzlliibb--pprreeffiixx==DDIIRR + specifies the prefix for zlib location. It overrides the 2 + previous options. (The include directory is supposed to be in + prefix/include, and the library in prefix/lib). + + ----wwiitthh--zzlliibb + is the default. ``configure'' looks on your system to find the + zlib. If found, ircd will be linked using it. This does NOT + mean you can use server link compression, for this you also need + to define ZIP_LINKS (see section below). + + ----wwiitthhoouutt--zzlliibb + tells ``configure'' not to look for the zlib. Defining this + will keep you from using server link compression. + + ----eennaabbllee--iipp66 + Enable IPv6 support (See notes below) + + ----eennaabbllee--ddssmm + Enable Dynamically Shared Modules support for iauth + + + 11..22.. NNootteess ffoorr CCyyggwwiinn3322 uusseerrss + + The daemon of 2.10.3 release compiles properly on W32 systems which + have the GNU-Win32 environment ( <http://www.cygnus.com/misc/gnu- + win32/>) setup. At the time of the release, tests were made using the + version b20.1 of the Cygwin32 library. + + When compiling on such system, you want to make sure that you have + carefully followed the Cygwin32 installation notes. In particular, + you will need to make sure that the following files exist: + //bbiinn//ccpp..eexxee, //bbiinn//mmvv..eexxee, //bbiinn//rrmm..eexxee and //bbiinn//sshh..eexxee. + + Also, the IRC server needs a rreessoollvv..ccoonnff file in order to initialize + the resolver. This file can be anywhere (see configure options), and + is typically in //eettcc on UNIX systems. + + Finally, iauth is automatically disabled. Even though the iauth + program compiles properly, extra work is required to have a working + communication channel between the IRC server and the iauth program. + + + 11..33.. NNootteess ccoonncceerrnniinngg IIPPvv66 ssuuppppoorrtt + + The only part of the software that doesn't use IPv6 is the server + internal resolver. It relies on the name servers defined in + ``/etc/resolv.conf'' to be IPv4 addresses. + + This version was tested on the following IPv6 systems: BSD/OS+KAME, + Digital Unix, FreeBSD+KAME, Linux, NetBSD+INRIA. + + Because IPv6 numeric addresses contain ``:'' characters, tthhee sseeppaarraattoorr + ffoorr tthhee sseerrvveerr ccoonnffiigguurraattiioonn ffiillee wwaass cchhaannggeedd ttoo ````%%''''. + + + 22.. TThhee ccoonnffiigg..hh ffiillee + + The second step consists of defining options before the compilation. + This is done by editing the ``config.h'' file and changing the various + #DEFINE's. + + + 22..11.. DDeeffiinnee wwhhaatt ttyyppee ooff UUNNIIXX yyoouurr mmaacchhiinnee uusseess.. + + Pick the machine type which best describes your machine and change the + #undef to #define (if needed).Some flavours of Unix require no #define + and in such cases all others should be #undef'd. + + + 22..22.. DDEEBBUUGGMMOODDEE + + Define DEBUGMODE if you want to see the ircd debugging information as + the daemon is running. Normally this function will be undefined as + ircd produces a considerable amount of output. DEBUGMODE must be + defined for either of -t or -x command line options to work. Defining + this induces a large overhead for the server as it does a large amount + of self diagnostics whilst running. + + TThhiiss sshhoouulldd oonnllyy bbee ddeeffiinneedd ffoorr tteesstt ppuurrppoosseess,, aanndd nneevveerr uusseedd oonn aa + pprroodduuccttiioonn sseerrvveerr.. + 22..33.. CCPPAATTHH,, MMPPAATTHH,, LLPPAATTHH,, PPPPAATTHH,, TTPPAATTHH,, QQPPAATTHH,, OOPPAATTHH + + Define CPATH to be the directory path to the ``ircd.conf'' file. This + path is usually /usr/local/lib/ircd/ircd.conf. The format of this file + will be discussed later. + + The LPATH #define should be set to ``/dev/null'' unless you plan to + debug the ircd program. Note that the logfile grows very quickly. + + Define MPATH to be the path to the ``motd'' (message of the day) file + for the server. Keep in mind this is automatically displayed whenever + anyone signs on to your server. + + The PPATH is optional, but if defined, should point to a file which + either doesn't exist (but is creatable) or a previously used PPATH + file. It is used for storing the server's PID so a ps(1) isn't + necessary. + + Define QPATH to be the directory path to the ``iauth.conf'' file. This + path is usually /usr/local/lib/ircd/iauth.conf. The format of this + file is described by a manual page. + + The OPATH #define should be set to ``/dev/null'' unless you plan to + debug the iauth program. Note that the logfile grows very quickly. + + + 22..44.. CCAACCHHEEDD__MMOOTTDD + + The server sends the ``motd'' to every client connecting. Every time, + it reads it from the disk. This is quite intensive and can be + undesirable for busy servers. + + Defining CACHED_MOTD will make the server store the ``motd'' in + memory, and only read it again from the disk when rehashing if the + file has changed. + + + 22..55.. CCHHRROOOOTTDDIIRR + + To use the CHROOTDIR feature, make sure it is #define'd and that the + server is being run as root. The server will chroot to the directory + name provded by ``IRCDDIR'' (in Makefile). + + + 22..66.. EENNAABBLLEE__SSUUMMMMOONN,, EENNAABBLLEE__UUSSEERRSS + + For security conscious server admins, they may wish to leave + ENABLE_USERS undefined, disabling the USERS command which can be used + to glean information the same as finger can. ENABLE_SUMMON toggles + whether the server will attempt to summon local users to irc by + writing a message similar to that from talk(1) to a user's tty. + + + 22..77.. SSHHOOWW__IINNVVIISSIIBBLLEE__LLUUSSEERRSS,, NNOO__DDEEFFAAUULLTT__IINNVVIISSIIBBLLEE + + On large IRC networks, the number of invisible users is likely to be + large and reporting that number cause no pain. To aid and effect + this, SHOW_INVISIBLE_LUSERS is provided to cause the LUSERS command to + report the number of invisible users to all people and not just + operators. The NO_DEFAULT_INVISIBLE define is used to toggle whether + clients are automatically made invisible when they register. + + + + + + 22..88.. OOPPEERR__KKIILLLL,, OOPPEERR__RREEHHAASSHH,, OOPPEERR__RREESSTTAARRTT,, LLOOCCAALL__KKIILLLL__OONNLLYY + + The three operator only commands, KILL, REHASH and RESTART, may all be + disabled to ensure that an operator who does not have the correct + privilidges does not have the power to cause untoward things to occur. + To further curb the actions of guest operators, LOCAL_KILL_ONLY can be + defined to only allow locally connected clients to be KILLed. + + + 22..99.. ZZIIPP__LLIINNKKSS,, ZZIIPP__LLEEVVEELL + + As of the 2.9.3 version of the server, server-server connections may + be compressed using the zlib. In order to compile the server with + this feature, you MUST have the zlib package (version 1.0 or higher) + already compiled and define ZIP_LINKS in the config.h file. + Compression use for server-server connections is separately configured + in the ircd.conf file for each server-server link. ZIP_LEVEL allows + you to control the compression level that will be used. Values above + 5 will noticeably increase the CPU used by the server. + + The zlib package may be found at + <http://www.cdrom.com/pub/infozip/zlib/>. The data format used by the + zlib library is described by RFCs (Request for Comments) 1950 to 1952 + in the files <ftp://ds.internic.net/rfc/rfc1950.txt> (zlib format), + rfc1951.txt (deflate format) and rfc1952.txt (gzip format). These + documents are also available in other formats from + <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html> + + + 22..1100.. SSLLOOWW__AACCCCEEPPTT + + This option is defined by default and is needed on some OSes. It + creates an artificial delay in processing incoming connections. On a + given port, no more than 1 connection per 2 seconds will be processed. + + Undefining this will let the server process connections as fast as it + can which can cause problems on some OSes (such as SunOS) and be + abused (fast massive join of clonebots..), for these reasons, if you + decide to undefine SLOW_ACCEPT you MUST define CLONE_CHECK. + + + 22..1111.. CCLLOONNEE__CCHHEECCKK + + This option acts as a wrapper, by checking incoming connections early + before starting ident query. By default, the server will not accept + more than 2 connections from the same host within 10 seconds. + + + 22..1122.. OOtthheerr ##ddeeffiinnee''ss + + The rest of the user changable #define's should be pretty much self + explanatory in the config.h file. It is *NOT* recommended that any of + the file undef the line with "STOP STOP" in it be changed. + + + 33.. EEddiittiinngg tthhee MMaakkeeffiillee,, aanndd ccoommppiilliinngg + + This package now uses GNU autoconf to probe your system and generate + the correct Makefile. However you need to edit it to specify specific + information, such as ``prefix'', ``irc_mode'', ``ircd_mode'' and + ``ircd_dir''. + + Now to build the package, type ``make all''. If everything goes will, + you can then install it by typing ``make install''. + + + If you have trouble compiling ircd, copy Makefile.in to Makefile and + edit Makefile as appropriate. + + + 44.. TThhee iirrccdd..ccoonnff ffiillee + + After installing the ircd and irc programs, edit the ircd.conf file as + per the instructions in this section and install it in the location + you specified in the config.h file. There is a sample conf file + called example.conf in the doc/ directory. + + Appendix A (See INSTALL.appendix) describes the differences between IP + addresses and host names. If you are unfamiliar with this, you should + probably scan through it before proceeding. + + The ircd.conf file contains various records that specify configuration + options. The record types are as follows: + + 1. Machine information (M) + + 2. Administrative info (A) + + 3. Port connections (P) + + 4. Connection Classes (Y) + + 5. Client connections (I,i) + + 6. Operator privileges (O) + + 7. Restrict lines (R) + + 8. Excluded accounts (K,k) + + 9. Server connections (C,c,N) + + 10. + Deny auto-connections (D) + + 11. + Hub connections (H) + + 12. + Leaf connections (L) + + 13. + Version limitations (V) + + 14. + Excluded machines (Q) + + 15. + Service connections (S) + + 16. + Bounce server (B) + + 17. + Default local server (U) + + Except for types ``M'' and ``A'', you are allowed to have multiple + records of the same type. In some cases, you can have concurrent + records. IItt iiss iimmppoorrttaanntt ttoo nnoottee tthhaatt tthhee llaasstt mmaattcchhiinngg rreeccoorrdd wwiillll + bbee uusseedd. This is especially useful when setting up I records (client + connections). + + 44..11.. MMaacchhiinnee iinnffoorrmmaattiioonn + + + IInnttrroodduuccttiioonn + IRC needs to know a few things about your UNIX site, and the + ``M'' command specifies this information for IRC. The fomat of + this command is: + + FFoorrmmaatt + + M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port> + + + + MM ``M'' specifies a Machine description line + + SSeerrvveerr NNAAMMEE + The name of YOUR server adding any Internet DOMAINNAME that + might also be present. If this hostname can be resolved, the IP# + found will be used to for outgoing connections. Otherwise the + default interface address of the host is used. The server name + may not be FQDN of another host. (This means all outgoing + connections will be done from the same IP#, even if your host + has several IP#). + + YYOOUURR IInntteerrnneett IIPP## + If the machine on which you run the server has several IP + addresses, you can define which IP# to use for outgoing + connections. This overrides overrides the ``Server NAME''. + + See Also the ``Port Connections'' section. + + GGeeooggrraapphhiicc LLooccaattiioonn + Geographic Location is used to say WHERE YOUR SERVER is, and + gives people in other parts of the world a good idea of where + you are! If your server is in the USA, it is usually best to + say: <CITY> <STATE>, USA. Like for Denver I say: ``Denver + Colorado, USA''. Finnish sites (like tolsun.oulu.fi generally + say something like ``Oulu, Finland''. + + PPoorrtt + Defines the port on which your server will listen for UDP pings + from other servers. This should be the port were other servers + are set to autoconnect. (Also see the port field description in + connect lines). + + EExxaammppllee:: + M:tolsun.oulu.fi::Oulu, Finland:6667: + + This line reads: My Host's name is ``tolsun.oulu.fi'' and my + site is located in ``Oulu, Finland''. + + M:orion.cair.du.edu::Denver Colorado, USA:6667: + + This line reads: My Hosts name is ``orion.cair.du.edu'' and my + site is located in ``Denver Colorado, USA''. + + + + 44..22.. AAddmmiinniissttrraattiivvee iinnffoo + + + IInnttrroodduuccttiioonn + The ``A'' line is used for administrative information about a + site. The e-mail address of the person running the server should + be included here in case problems arise. + FFoorrmmaatt + + A:<Your Name/Location>:<Your Electronic Mailing Addr>:<other>:: + + + + AA This specifies an Admin record. + + YYoouurr NNaammee && LLooccaattiioonn + Use this field to say tell your FULL NAME and where in the world + your machine is. Be sure to add your City, State/Province and + Country. + + YYoouurr EElleeccttrroonniixx MMaaiilliinngg AAddddrr + Use this field to specify your Electronic Mailing Address + preferably your Internet Mailing Address. If you have a UUCP or + ARAPnet address - please add that as well. Be sure to add any + extra DOMAIN information that is needed, for example ``mail + jtrim@orion'' probably won't work as a mail address to me if you + happen to be in Alaska. But ``mail jtrim@orion.cair.du.edu'' + would work because you know that ``orion'' is part of the DOMAIN + ``cair.du.edu''. So be sure to add your DOMAINNAMES to your + mailing addresses. + + OOtthheerr + This is really an OTHER field - you can add what you want here. + + EExxaammppllee + (the line is just one line in the confuration file, here it is + cut into two lines to make it clearer to read): + + A:Jeff Trim - Denver Colorado, USA:INET jtrim@orion.cair.du.edu + UUCP {hao,isis}!udenva!jtrim:Terve! Heippa! Have you said hello + in Finnish today?;):: + + Would look like this when printed out with the /admin command: + + Jeff Trim - Denver Colorado, USA INET jtrim@orion.cair.du.edu + UUCP {hao,isis}!udenva!jtrim Terve! Hei! Heippa! Have you said + hello in Finnish today? ;) + + + Note that the A record cannot be split across multiple lines; it + will typically be longer than 80 characters and will therefore + wrap around the screen. + + + 44..33.. PPoorrtt ccoonnnneeccttiioonnss + + + IInnttrroodduuccttiioonn + The port line adds flexibility to the server's ability to accept + connections. By use of this line in the ircd.conf file, it is + easy to setup both Unix Domain ports for the server to accept + connections on as well as extra internet ports. + + FFoorrmmaatt + + P:<Internet IP#>:<*>:<Internet IP Mask>:<Port>: + P:<Directory>:<*>:<*>:<Port>: + + + + + +o Internet Ports + + IInntteerrnneett IIPP## + If the host on which the server runs has several IP addresses, + you can define for which IP address connections will be + accepted. If no is defined here, server will bind to all + interfaces (INADDR_ANY). See also MACHINE CONFIGURATION section + to properly configure outgoing connections. + + P:192.168.1.194:::6664: + + IInntteerrnneett IIPP## MMaasskk + This defines where connections may come from and be accepted. + The IP mask uses either *'s or 0's as wildcards. The following + two lines are the same: + + + P:::128.2.*:6664: + P:::128.2.0.0:6664: + + + + The incoming isn't matched against the mask, rather the ip# string + is decoded and compared segment by segment. Thus + + P:::128.2*.1.2:6664: + + will not match 128.20.1.2. + + PPoorrtt + The port number field tells the server which port number it + should listen on for incoming connections. + + +o Unix Socket Ports. + + DDiirreeccttoorryy + The path set in this field should be the directory name in which + to create the unix socket for later listening to. The server + will attempt to create the directory before creating the unix + socket. + + PPoorrtt + The port field when used in combination with a pathname in a P- + line is the filename created in the directory set in the first + field. + + EExxaammppllee + P:/tmp/.ircd:::6667: + + Creates a unix socket in the /tmp/.ircd directory called + ``6667''. The unix socket (file) must be a numerical. + + + NNoottee + You need at least one P line. + + + 44..44.. CCoonnnneeccttiioonn CCllaasssseess + + + IInnttrroodduuccttiioonn + To enable more efficient use of MAXIMUM_LINKS, connection + classes were implemented. All clients belong to a connection + class. + + Each line for a server should have the same number as the sixth + field. If it is absent, the server deaults it to 0, using the + defaults from the config.h file. + To define a connection class, you need to include a Y: line in + the ircd.conf file. This enables you to define the ping + frequency, connection frequency (for servers) and maximum number + of links that class should have. + + Currently, the Y: line MMUUSSTT appear in the ircd.conf file BBEEFFOORREE + it is used in any other way. + + FFoorrmmaatt + + Y:<Class>:<Ping Frequency>:<Connect freq>:<Max Links>:<SendQ>:<Local Limit>:<Global Limit> + + + + YY This specifies a Class record. + + CCllaassss + This is the class number which gains the following attributes + and should match that which is on the end of the C/c/N/I/O/S + line. + + PPiinngg FFrreeqquueennccyy + This field defines how long the server will let the connection + remain ``silent'' before sending a PING message to make sure it + is still alive. Unless you are sure of what you are doing, use + the default value which is in your config.h file. + + CCoonnnneecctt FFrreeqquueennccyy + By changing this number, you change how often your server checks + to see if it can connect to this server. If you want to check + very occasionally, use a large value, but if it is an important + connection, you might want a smaller value so that you connect + to it as soon as possible. + + MMaaxx LLiinnkkss + This field defines the maximum number of links this class will + allow from automatic connections (C lines). Using /CONNECT + overrides this feature. Also defines the maximum number of + users in this class for I/O lines per I/O line. + + SSeennddQQ + This field defines the ``SendQ'' value for this class. If this + field is not present, the default (from config.h) is assigned. + + LLooccaall lliimmiitt + This field is used to limit the number of local concurrent + connections. The format is <x>.<y> + + +o x: defines the maximum number of clients from the same host (IP) + will be allowed. + + +o y: defines the maximum number of clients from the same user@host + (IP) will be allowed. Read note below. + + Only x or y may be set, any unset value defaults to zero. + + GGlloobbaall lliimmiitt + This field has the same use as the ``Local limit'' field. But, + the connection counts are done for all clients present on the + net instead of only counting local clients. + + NNoottee + leaving any of the fields (except SendQ) out means their value + is 0 (ZERO)!! The SendQ field default value is dynamically + determined. + + NNoottee + If you plan to use the local user@host limit, please read the + following very carefully. The ``user'' value is the ident reply + for the connection. If no reply was given then it defaults to + ``unknown'' and thus the effective limit will be per host, not + per user@host. Also, some ident servers return encrypted data + which changes for every connection making the limit void. + + NNoottee + Only the local limitation is accurate. + + NNoottee + If you define a gobal limit, you should also define a local + limit (same or lower) as it won't take more CPU and will make + the global limit more accurate. + + NNoottee + The local and global limits only affect users (I lines), not + servers nor services. + + EExxaammppllee + Y:23:120:300:5:100000:0:0: (server class) + + This defines class 23 to allow 5 auto-connections, which are + checked every 300 seconds. The connection is allowed to remain + silent for 120 seconds before a PING is sent. NOTE: fields 3 & + 4 are in seconds. The SendQ is set to 100000 bytes. + + Another feature of connection class is the ability to do + automatic routing by using the class as a ``priority''. If you + are connected to a server which has a class lower than one of + the servers that is ``behind'' it, the server will disconnect + the lower class one and schedule a ``new'' connection for the + higher class server. + + Y:1:60:0:50:20000:2:5: (client class) + + In case of a client class, the fields are interpreted a bit + differently. This class (number 1) can be used by up to 50 + users. The connections are allowed to remain silent for 60 + seconds before a PING is set. The SendQ is set to 20000 bytes. + A new connection in this class will only be allowed if there + aren't more than 2 other local connections from the same IP + address, or more than 5 other connections on the net from the + same hostname. + + Y:2:60:0:50:20000:2.1:5: (client class) + + In case of a client class, the fields are interpreted a bit + differently. This class (number 1) can be used by up to 50 + users. The connections are allowed to remain silent for 60 + seconds before a PING is set. The SendQ is set to 20000 bytes. + A new connection in this class will only be allowed if there + aren't more than 2 other local connections from the same IP + address, 1 other local connection from the same user from the + same IP address, or more than 5 other connections on the net + from the same hostname. + + + 44..55.. CClliieenntt ccoonnnneeccttiioonnss + + How to let clients connect to your IRCD. + + IInnttrroodduuccttiioonn + A client is a program that connects to the ircd daemon (ircd). + There are clients written in C, GNU Emacs Lisp and many other + languages. The ``irc'' program is the C client. Each person + that talks via IRC is running their own client. + + The ircd.conf files contains entries that specify which clients + are allowed to connect to your irc daemon. Obviously you want + to allow your own machine's clients to connect. You may want to + allow clients from other sites to connect. These remote clients + will use your server as a connection point. All messages sent + by these clients will pass through your machine. + + FFoorrmmaatt + + I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> + i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> + + + + TTAARRGGEETT HHoosstt AAddddrr + Specifies the IP address(es) of the machine(s) that are allowed + to connect. If ``user@'' prefixes the actual IP address the + server will require that the remote username returned by the + ident server be the same as the one given before the ``@''. + Wildcards are permitted unless using a bitmask (e.g. + 1.2.3.0/24). + + PPaasssswwoorrdd + The password that must be given by the client to be allowed on + the server. + + TTAARRGGEETT HHoosstt NNAAMMEE + Specifies the host name(s) of the machines allowed to connect to + the server. If ``user@'' prefixes the actual IP address the + server will require that the remote username returned by the + ident server be the same as the one given before the ``@''. + Wildcards are permitted. + + This field can be empty, it then has a special meaning. See + Below. + + PPoorrtt + Specifies the port number for which this configuration line is + valid. An empty field, or ``0'' matches all ports. + + CCllaassss + This field should refer to an existing class. Connections + classes are usefull to limit the number of users allowed on the + server. + + NNoottee + The server first checks if the client hostname (or any aliases) + matches the TTAARRGGEETT HHoosstt NNAAMMEE field. If a match is found, the + client is accepted. If not, the server checks if the IP address + of the client matches the TTAARRGGEETT HHoosstt AAddddrr field. The matching + field is used to set the name of the client: for example, if the + client matches the TTAARRGGEETT HHoosstt AAddddrr field, it will show on IRC + with a numerical address (even if this address is resolvable). + If the TTAARRGGEETT HHoosstt NNAAMMEE field is empty, then the host name is + always used (when available). + + EExxaammpplleess + For example, if you were installing IRC on tolsun.oulu.fi and + you wanted to allow examples sake let us assume you were making + this file for tolsun and you wanted to let your own clients to + connect to your server, you would add this entry to the file: + + I:x::tolsun.oulu.fi::1 + If you wanted to let remote clients connect, you could add the + following lines: + + I:x::*.du.edu::1 + + Allow any clients from machines whose names end in ``.du.edu'' + to connect with no password. + + I:128.214.6.100::nic.funet.fi::1 + + Allow clients from a machine with that IP number to connect. + Numeric match is enough, name is not required anymore. + + I:x:secret:*.tut.fi::1 + + Allow clients from machines matching ``*.tut.fi'' to connect + with the password ``secret''. + + I:*::*::1 + + Allow anyone from anywhere to connect your server. + + This is the easiest way, but it also allows people to for + example dump files to your server, or connect 1000 (or how many + open sockets per process your OS allows) clients to your machine + and take your network ports. Of course the same things can be + done by simply telnetting to your machine's SMTP port (for + example). + + I:x::*.fi:6667:1 + + Allow clients from machines matching ``*.fi'' to connect on the + port 6667. + + I:135.11.35.*::*.net::1 + + Allows clients from machines which host name matches ``*.net'' + or which IP address matches ``135.11.35.*'' to connect to the + server. If the host name does not match ``*.net'' then the IP + address is used for these clients, even if the host name is + known. + + I:135.11.35.*::::1 + + Allows clients from machines which IP address matches + ``135.11.35.*'' to connect to the server. If the host name is + known, is it used as address for these clients. + + NNEEWW!!!!!! + As of the 2.7.2d version of the server, the server is able to + accept connections on multiple ports. I-lines are required for + each P-line to allow connections to be accepted. For unix + sockets, this means either adding I:/path/port::/path/port or + some variation (wildcards are recognised here). For internet + ports, there must be an I-line which allows the host access as + normal, but the port field of the I-line must match that of the + port of the socket accepting the connectiion. A port number of 0 + is a wildcard (matches all ports). + + NNEEWW!!!!!! + As of the 2.9.1 version of the server, i lines are introduced. + They work the same way as I lines, but the clients matching an i + line will have a restricted connection. (no nick/mode change, no + kick). Such users will have their username prefixed by +, = or - + depending on the ident reply. + + 44..66.. OOppeerraattoorr pprriivviilliiggeess + + How to become the IRC administrator on your site + + IInnttrroodduuccttiioonn + To become an IRC Administrator, IRC must know who is authorized + to become an operator and what their ``Nickname'' and + ``Password'' is. + + FFoorrmmaatt + + O:<TARGET Host NAME>:<Password>:<Nickname>:<Port>:<Class> + + + + OO Speficies Operator record. If you use capital letter (``O'') in + it, it specifies a global operator. Small letter (``o'') + specifies a local operator. Local operator has basically the + same rights except global operator with some restrictions. + + TTAARRGGEETT HHoosstt NNAAMMEE + Tells IRC which host you have the privileges FROM. This means + that you should be logged into this host when you ask for the + priviliges. If you specify ``tolsun.oulu.fi'' then IRC will + expect your CLIENT to be connected at ``tolsun.oulu.fi'' - when + you ask for OPERATOR privileges from ``tolsun.oulu.fi''. You + cannot be logged in at any other host and be able to use your + OPERATOR privileges at tolsun, only when you are connected at + TOLSUN will this work - this is a safeguard against unauthorized + sites. + + PPaasssswwoorrdd + If your AUTHORIZATION Password - this is the password that let's + IRC know you are who you say you are! Never tell anyone your + password and always keep the ``ircd.conf'' file protected from + all of the other users. + + NNiicckknnaammee + The Nickname you usually go by - but you can make this what you + want. + + PPoorrtt + Unused. + + CCllaassss + The class field should refer to an existing class (preferably + having a lower number than that for the relevant I-line) and + determines the maximum number of simultaneous uses of the O-line + allowable through the max. links field in the Y-line. + + EExxaammppllee + O:orion.cair.du.edu:pyunxc:Jeff::1 + + There is an OPERATOR at ``orion.cair.du.edu'' that can get + Operator priviliges if he specifies a password of ``pyunxc'' and + uses a NICKNAME of ``Jeff''. + + + 44..77.. RReessttrriicctt ccoonnnneeccttiioonnss + + Let an external program decide if a client should be allowed or not. + + IInnttrroodduuccttiioonn + R lines provide a convenient way to handle user access to the + server with an external program. The outside program given + three parameters: the client's username (set by the USER + command), the client's hostname, and the client's ident reply + (``unknown'' if none). + + It is expected to return a reply line where the first word is + either ``Y'' or ``N'' meaning `Yes Let them in'' or ``No don't + let them in''. If the first word begins with neither ``Y'' or + ``N'' the default is to let the person on. + + FFoorrmmaatt + + R:<Target Host Name>:<Program>:<User>::: + + + + RR This specifies a restrict record. + + TTaarrggeett HHoosstt NNaammee + In this field you specify the Hostname that the user is + connecting from. If you wanted to restrict connects to IRC from + ``orion.cair.du.edu'' then you would want to enter + ``orion.cair.du.edu''. + + PPrrooggrraamm + This is the external program to run to know if the user is + allowed on your server. + + UUsseerr + The Username of the user you want removed from IRC. For example + ``root''. + + + 44..88.. EExxcclluuddeedd aaccccoouunnttss + + Remove an errant user from IRC on your site. + + IInnttrroodduuccttiioonn + Obviously it is hoped that you wouldn't have to use this + command. Unfortunately sometimes a user can become unmanageable + and this is your only recourse - the KILL USER command. THIS + COMMAND ONLY AFFECTS YOUR SERVER - If this user can connect to + another SERVER somewhere else in the IRC-Network then you would + have to talk to the administrator on that site to disable his + access from that IRCD Server as well. + + FFoorrmmaatt + + K:<Host Name>:<time interval(s)|comment>:<User>:<port>: + + + + FFoorrmmaatt + + k:<Host Name>:<time interval(s)|comment>:<Auth>:<port>: + + + + KK ``K'' tells the IRCD that you are making a KILL USER command + entry. + + HHoosstt NNaammee + In this field you specify the Hostname or the IP address (Single + IP, Wildcard notation or bitmask notation) that the user is + connecting from. If you wanted to REMOVE connects to IRC from + ``orion.cair.du.edu'' then you would want to enter + ``orion.cair.du.edu''. If you want to REMOVE ALL HOSTS access + you can use ``*'' (Wild Card notation) and no matter what host + the USERNAME (specified in Field 4) connects from s/he will be + denied access. Removing all hosts isn't very smart thing to do + though, why would you run an ircd if you allow nobody to connect + to it anyways ? + + If you specify an IP address, IP mask, or an IP bitmask, it will + match clients connecting from the matching addresses, no matter + if they resolve or not. + + You can prefix an IP address, an IP mask, or IP bitmask by ``='' + in which case only non resolving matching hosts will be banned. + + ttiimmee iinntteerrvvaall((ss))||ccoommmmeenntt + Either leave this field empty or put a comment, then the line + active continuously for the specified user/host machine. You + may also specify intervals during the line should be active, see + examples below. + + UUsseerr + The USERNAME of the user you want removed from IRC. For example + ``root''. + + AAuutthh + If the user's ident server replies with the OTHER type (as + opposed to the UNIX type), the reply is not used to set the + user's username. (lowercase) k lines can be used in these case + to reject users based on their ident reply. + + This field will be matched against the ident server reply. It + is important to note that OTHER replies are prefixed with a + ``-'' by the ircd, while UNIX replies are not. + + PPoorrtt + The port on which the Kill line will be effective. 0 means all + ports. + + EExxaammpplleess + K:orion.cair.du.edu::jtrim:0: + + + If user ``jtrim'' connects to IRC from host + ``orion.cair.du.edu'' then IMMEDIATELY REMOVE HIM from my IRCD. + + k:*.stealth.net::-43589:0: + + If a user connects from any host that has the suffix + ``stealth.net'' and if that host ident server returns ``-43589'' + - then IMMEDIATELY REMOVE THEM from my IRCD. + + K:*.cair.du.edu::root:0: + + If user ``root'' connects to IRC from any host that has the + suffix ``cair.du.edu'' - then IMMEDIATELY REMOVE THEM from my + IRCD. + + K:*::vijay:0: + + This line reads ``I don't care WHAT HOST user ``vijay'' is on, I + will NEVER allow username ``vijay'' to login to my IRCD.'' + + K:*.oulu.fi:0800-1200,1400-1900:*:0: + + This disallows all users from hosts with enddomain ``oulu.fi'' + access to your server between 8 and 12am, 2 and 7pm. Users get + kicked off if they're already signed on when the line becomes + active (they'll get a warning 5 minutes before). + K:192.11.35.*::*:0: + + This line disallows all hosts whose IP address matches + ``192.11.35.*'' to login to the ircd. + + K:=192.11.35.*::*:0: + + This line disallows all hosts whose IP address matches + ``192.11.35.*'' and which didn't resolve to login to the ircd. + + + 44..99.. SSeerrvveerr ccoonnnneeccttiioonnss + + How to connect to other servers, How other servers can connect to you + + WWAARRNNIINNGG:: The hostnames used as examples are really only examples and + not meant to be used (simply because they don't work) in real life. + + + Now you must decide WHICH hosts you want to connect to and WHAT ORDER + you want to connect to them in. For my example let us assume I am on + the machine "rieska.oulu.fi" and I want to connect to irc daemons on 3 + other machines: + + +o ``garfield.mit.edu'' - Tertiary Connection + + +o ``irc.nada.kth.se'' - Secondary Connection + + +o ``nic.funet.fi'' - Primary Connection + + + And I prefer to connect to them in that order, meaning I first want to + try connecting to ``nic.funet.fi'', then to ``irc.nada.kth.edu'', and + finally to ``garfield.mit.edu''. So if ``nic.funet.fi'' is down or + unreachable, the program will try to connect to ``irc.nada.kth.se''. + If irc.nada.kth.se is down it will try to connect to garfield and so + forth. + + PLEASE limit the number of hosts you will attempt to connect to down + to 3. This is because of two main reasons: + + 1. to save your server from causing extra load and delays to users + + 2. to save internet from extra network traffic (remember the old rwho + program with traffic problems when the number of machines + increased). + + + FFoorrmmaatt + + C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET PORT>:<Class> + + + + for example: + + C:nic.funet.fi:passwd:nic.funet.fi:6667:1 + + - or - + + C:128.214.6.100:passwd:nic.funet.fi:6667:1 + + - or - + + C:root@nic.funet.fi:passwd:nic.funet.fi:6667:1 + + Each field is separated with a ":" charcter: + + CC This field tells the IRC program which option is being + configured. "C" corresponds to a server Connect option. + + TTAARRGGEETT HHoosstt AAddddrr + Specifies the host name or IP address of the machine to connect + to. If ``user@'' prefixes the actual hostname or IP address the + server will require that the remote username returned by the + ident server be the same as the one given before the ``@''. + + PPaasssswwoorrdd + The password of the other host. A password must always be + present for the line to be recognized. + + TTAARRGGEETT HHoosstt NNAAMMEE + The full hostname of the target machine. This is the name that + the TARGET server will identify itself with when you connect to + it. If you were connecting to nic.funet.fi you would receive + ``nic.funet.fi'' and that is what you should place in this + field. + + TTAARRGGEETT PPOORRTT + The INTERNET Port that you want to connect to on the TARGET + machine. Most of the time this will be set to ``6667''. If this + field is left blank, then no connections will be attempted to + the TARGET host, and your host will accept connections FROM the + TARGET host instead. The port field can contain 2 ports, + separated by a . In this case, the first port is used when auto- + connecting, the second port is used for the UDP pings to the + targer server. + + CCllaassss + The class field should refer to an existing class and determines + the maximum number of simultaneous uses of the C-line allowable + through the max. links field in the Y-line. + + NNEEWW!!!!!! + As of the 2.9.3 version of the server, server connections can be + compressed with the zlib library. To define a compressed + connection, you must have compiled the server with ZIP_LINKS + defined (cf 2.h), and use a _lowercase_ C line. + + Some examples: + + +o C:nic.funet.fi::nic.funet.fi:6667:1 + + This reads: Connect to host ``nic.funet.fi'', with no password and + expect this server to identify itself to you as ``nic.funet.fi''. + Your machine will connect to this host to port 6667. + + +o C:18.72.0.252:Jeff:garfield.mit.edu:6667:1 + + This reads: Connect to a host at address ``18.72.0.252'', using a + password of ``Jeff''. The TARGET server should identify itself as + ``garfield.mit.edu''. You will connect to Internet Port 6667 on + this host. + + +o C:irc.nada.kth.se::irc.nada.kth.se:1 + + This reads: do not attempt to connect to ``irc.nada.kth.se'', if + ``irc.nada.kth.se'' requests a connection, allow it to connect. + + Now back to our original problem, we wanted OUR server CONNECT to 3 + hosts, ``nic.funet.fi'', ``irc.nada.kth.se'' and ``garfield.mit.edu'' + in that order. So as we enter these entries into the file they must + be done in rreevveerrssee order of how we could want to connect to them. + + Here's how it would look if we connected ``nic.funet.fi'' first: + + C:garfield.mit.edu::garfield.mit.edu:6667:1 + C:irc.nada.kth.se::irc.nada.kth.se:6667:1 + C:nic.funet.fi::nic.funet.fi:6667:1 + + Ircd will attempt to connect to nic.funet.fi first, then to irc.nada + and finally to garfield. + + RReecciipprrooccaall eennttrriieess:: Each ``C'' entry requires a corresponding ``N'' + entry that specifies connection priviliges to other hosts. The ``N'' + entry contains the password, if any, that you require other hosts to + have before they can connect to you. These entries are of the same + format as the ``C'' entries. + + + + FFoorrmmaatt + The format for the NOCONNECT entry in the ``ircd.conf'' is: + + N:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<Domain Mask>:<Class> + + + + Let us assume that ``garfield.mit.edu'' connects to your server and + you want to place password authorization authorization on garfield. + The ``N'' entry would be: + + N:garfield.mit.edu:golden:garfield.mit.edu:: + + This line says: expect a connection from host ``garfield.mit.edu'', + and expect a login password of ``golden'', and expect the host to + identify itself as ``garfield.mit.edu''. + + N:18.72.0.252::garfield.mit.edu:: + + This line says: expect a Connection from host ``18.72.0.252'', and + don't expect login password. The connecting host should identify + itself as ``garfield.mit.edu''. + + NN ``N'' corresponds to a server Noconnect option. + + TTAARRGGEETT HHoosstt AAddddrr + Specifies the host name or IP address of the machine to connect + to. If ``user@'' prefixes the actual hostname or IP address the + server will require that the remote username returned by the + ident server be the same as the one given before the ``@''. + + PPaasssswwoorrdd + The password of the other host. A password must always be + present for the line to be recognized. If CRYPT_LINK_PASSWORD is + defined in config.h, this password must be crypted. + + TTAARRGGEETT HHoosstt NNAAMMEE + The full hostname of the target machine. This is the name that + the TARGET server will identify itself with when you connect to + it. If you were connecting to nic.funet.fi you would receive + ``nic.funet.fi'' and that is what you should place in this + field. + + DDoommaaiinn MMaasskk + Domain masking, see below. + + + CCllaassss + The class field should refer to an existing class. + + WWiillddccaarrddss ddoommaaiinnss + To reduce the great amount of servers in IRCnet wildcard DOMAINS + were introduced in 2.6. To explain the usage of wildcard domains + we take an example of such: + + *.de - a domain name matching all machines in Germany. + + Wildcard domains are useful in that ALL SERVERS in Germany (or + any other domain area) can be shown as one to the rest of the + world. Imagine 100 servers in Germany, it would be incredible + waste of netwotk bandwidth to broadcast all of them to all + servers around the world. + + So wildcard domains are a great help, but how to use them ? + + They can be defined in the N-line for a given connection, in + place of ``Domain Mask'' you write a magic number called + wildcard count. + + Wildcard count tells you HOW MANY PARTS of your server's name + should be replaced by a wildcard. For example, your server's + name is ``tolsun.oulu.fi'' and you want to represent it as + ``*.oulu.fi'' to ``nic.funet.fi''. In this case the wildcard + count is 1, because only one word (tolsun) is replaced by a + wildcard. + + If the wildcard count would be 2, then the wildcard domain would + be ``*.fi''. Note that with wildcard name ``*.fi'' you could NOT + connect to ``nic.funet.fi'' because that would result in a + server name ccoolllliissiioonn (*.fi matches nic.funet.fi). + + I advice you to not to use wildcard servers before you know for + sure how they are used, they are mostly beneficial for backbones + of countries and other large areas with common domain. + + + + 44..1100.. DDeennyy aauuttoo--ccoonnnneeccttiioonnss + + + IInnttrroodduuccttiioonn + D lines were implemented to give server administrators more + control on how auto connections are done. This will most likely + only be useful for big networks which have complex + configurations. + + FFoorrmmaatt + + D:<Denied Server Mask>:Denied Class:<Server Name>:Server Class: + + + + DDeenniieedd SSeerrvveerr MMaasskk + This field is matched against all servers currently present on + the network. + + DDeenniieedd CCllaassss + If this field contains a class number, it will match if any + server in that class is currently present on the network. Note + that this can be true for any server, even the ones not directly + connected. + + + SSeerrvveerr MMaasskk + This field is matched against the server name that the server + wants to auto connect to. + + SSeerrvveerr CCllaassss + This field is used to match against the class to which belong + the servers for which an autoconnect is set. + + EExxaammpplleess + D:*.edu::*.fi:: + + Don't auto-connect to any ``*.fi'' server if any server present + on the network matches ``*.edu''. + + D::2:eff.org:3: + + Do now auto-connect to ``eff.org'', or any server in class ``3'' + if a server defined to be in class ``2'' is currently present on + the network. + + + 44..1111.. HHuubb ccoonnnneeccttiioonnss + + + IInnttrroodduuccttiioonn + In direct contrast to L-lines, the server also implements H- + lines to determine which servers may act as a hub and what they + may ``hub for''. If a server is only going to supply its own + name (ie act as a solitary leaf) then no H-line is required for, + else a H-line must be added. + + FFoorrmmaatt + + H:<Server Mask>:*:<Server Name>:: + + + + SSeerrvveerr MMaasskk + All servers that are allowed via this H-line must match the mask + given in this field. + + SSeerrvveerr NNaammee + This field is used to match exactly against a server name, + wildcards being treated as literal characters. + + EExxaammpplleess + H:*.edu::*.bu.edu:: + + Allows a server named ``*.bu.edu'' to introduce only servers + that match the ``*.edu'' name mask. + + H:*::eff.org:: + + Allows ``eff.org'' to introduce (and act as a hub for) any + server. + + NNoottee + It is possible to have and use multiple H-lines (or L-lines) for + the one server. eg: + + + H:*.edu:*:*.bu.edu:: + H:*.au:*:*.bu.edu:: + + + + is allowed as is + + + L:*.edu:*:*.au:: + L:*.com:*:*.au:: + + + + + 44..1122.. LLeeaaff ccoonnnneeccttiioonnss + + + IInnttrroodduuccttiioonn + To stop servers which should only act as leaves from hubs + becoming hubs accidently, the L line was introduced so that hubs + can be aware of which servers should and shouldnt be treated as + leaves. A leaf server is supposed to remain a node for the + entirity of its life whilst connected to the IRC server network. + It is quite easy, however for a leaf server to be incorrectly + setup and create problems by becoming a node of 2 or more + servers, ending its life as a leaf. The L line enables the + administrator of an IRC ``Hub server'' to ``stop'' a server + which is meant to act as a leaf trying to make itself a hub. + If, for example, the leaf server connects to another server + which doesnt have an L-line for it, the one which does will drop + the connection, once again making the server a leaf. + + FFoorrmmaatt + + L:<Server Mask>:*:<Server Name>:<Max Depth>: + + + + SSeerrvveerr MMaasskk + Mask of which servers the leaf-like attributes are used on when + the server receives SERVER messages. The wildcards * and ? may + be used within this field for matching purposes. If this field + is empty, it acts the same as if it were a single * (ie matches + everything). + + SSeerrvveerr NNaammee + The name of the server connected to you that for which you want + to enforce leaf-like attributes upon. + + MMaaxx DDeepptthh + Maximum depth allowed on that leaf and if not specified, a value + of 1 is assumed. The depth is checked each time a SERVER + message is received by the server, the hops to the server being + the field checked against this max depth and if greater, the + connection to the server that made its leaf too deep has its + connection dropped. For the L-line to come into effect, both + fields, 2 and 4, must match up with the new server being + introduced and the server which is responsible for introducing + this new server. + + + 44..1133.. VVeerrssiioonn lliimmiittaattiioonnss + + + IInnttrroodduuccttiioonn + V-lines are used to restrict server connecting to you based on + their version and on compile time options. + + FFoorrmmaatt + + + V:<Version Mask>:<Flags>:<Server Mask>:: + + + + VVeerrssiioonn MMaasskk + The matching version number strings will be rejected. + + FFllaaggss + If any flag specified in this field is found in the peer's flags + string, it will be rejected. + + SSeerrvveerr MMaasskk + This field is used to match server names. The V line will be + used for servers matching the mask given in this field. + + SSeerrvveerr TTyyppee + Both the VVeerrssiioonn MMaasskk and the FFllaaggss should be prefixed with the + server type identification. This implementation uses the id + ``IIRRCC'' (starting with version 2.10). + + EExxaammpplleess + V:IRC/021001*::*:: + + Disallows any ``IRC'' server which version is 2.10.1* to + connect. + + V:IRC/021001*:IRC/D:*:: + + Disallows any ``IRC'' server which version is 2.10.1* or which + has been compiled with DEBUGMODE defined to connect. + + V:*/0209*:::: + + Disallows any server using the 2.9 protocol to connect. + + NNoottee + It is possible to have and use multiple V-lines for the one + server mask. + + V:IRC/021001*::*:: + + V:IRC/021002*::*:: + + is allowed. + + PPrroottooccooll VVeerrssiioonn + Only the 4 first digit of the VVeerrssiioonn NNuummbbeerr are standard: they + define the protocol version. The remaining of the string is + implementation dependant; matches on this part should be used + with particular identification. + + FFllaaggss + are not standard. Therefore, this field sshhoouulldd aallwwaayyss contain a + specific identification. + + + 44..1144.. EExxcclluuddeedd mmaacchhiinneess + + Disallowing SERVERS in your irc net. + + IInnttrroodduuccttiioonn + In some cases people run into difficulties in net + administration. For one reason or another you do not want a + certain server to be in your net (for example because of the + security holes it opens for every server if it's not secured + carefully). In that case you should use Q-lines in your server. + When you specify a server name in Q-line, everytime some server + link tries to introduce you a server (remember, all server names + are broadcast around the net), that name is checked if it + matches the Q-lines in your server. If it matches, then yyoouurr + sseerrvveerr disconnects the link. Note that just placing Q-lines to + your server probably results in yyoouurr sseerrvveerr being left alone, + unless other servers have agreed to have the same Q-line in + their ircd configuration files as well. + + EExxaammppllee + Q::of the security holes:foo.bar.baz:: + + This command excludes a server named ``foo.bar.baz'', the reason + is given to be security holes (you should give a reason, it is + polite). The first field is unused, so leave it empty. + + + 44..1155.. SSeerrvviiccee ccoonnnneeccttiioonnss + + + IInnttrroodduuccttiioonn + The Service is a special kind of IRC client. It does not have + the full abilities of a normal user but can behave in a more + active manner than a normal client. + + Services are not intended for interactive usage, and are better + suited for automated clients. + + FFoorrmmaatt + + S:<TARGET Host Mask>:<Password>:<Service Name>:<Service Type>:<Class> + + + + TTAARRGGEETT HHoosstt MMaasskk + The host mask should be set to match the host(s) from which the + service will be connecting from. This may be either an IP# or + full name (prefered). + + PPaasssswwoorrdd + This is the password which must be passed in the SERVICE + command. + + SSeerrvviiccee NNaammee + The name used by the service. Services don't have nicknames, but + a static name defined by the S line. + + SSeerrvviiccee TTyyppee + The type of service. It defines the priviledges given to the + service. Be very careful in the types you allow. The types can + be found in include/service.h + + CCllaassss + The class field should refer to an existing class. + + NNootteess + A service is not a very useful sort of client, it cannot join + channels or issue certain commands although most are available + to it. Services are rejected upon sending an unknown or + unallowed command. Services however, are not affected by flood + control and can be granted special privileges. It is therefore + wwiissee ttoo oovveerrsseeee tthhee uussee ooff SS--lliinneess wwiitthh mmuucchh ccaarree.. + + + + + 44..1166.. BBoouunnccee sseerrvveerr + + + IInnttrroodduuccttiioonn + This provides you a way to bounce clients to another server. + This information is provided to clients which are denied + connection, either because their connection class is full, or + the server is full, or they are not authorized to connect. + + FFoorrmmaatt + + B:<Class|Host Mask>::<Server Name>:<Port>: + + + + BB This specifies a Bounce record. + + CCllaassss||HHoosstt MMaasskk + This field specifies to which client this configuration line + applies to. It can be either a connection class number, a host + mask to be matched against the client's hostname, or an IP + address/mask/bitmask to be matched against the client's IP + address. + + When the server is completely full, it rejects clients with the + ``All connections in use'' message. In this case, the server + doesn't process the connections at all, and has no knowledge of + the client's host name, or class number. For these cases, this + field must be empty. + + SSeerrvveerr NNaammee + This specifies the IRC server hostname that the client should + use. + + PPoorrtt + This specifies the IRC server port that the client should + connect to. + + EExxaammppllee + B:2::irc.stealth.net:6660: + + Rejected clients in class 2 are advised to use + ``irc.stealth.net'' on port 6660. + + B:*.fi::irc.funet.fi:6667: + + Finnish client should use irc.funet.fi when they cannot be taken + anymore. + + B:::irc2.stealth.net:6667: + + When the server is completely full, clients should use the + secondary server. + + + 44..1177.. DDeeffaauulltt llooccaall sseerrvveerr ((ffoorr llooccaall cclliieennttss)) **OOBBSSOOLLEETTEEDD** + + + IInnttrroodduuccttiioonn + This defines the default connection for the irc client. If you + are running an ircd server on the same machine, you will want to + define this command to connect to your own host. If your site + is not running a server then this command should contain the + TARGET host's connection information and password (if any). + + + FFoorrmmaatt + + U:<TARGET Host addr>:<Password>:<TARGET Host NAME>:<Internet Port> + + + + EExxaammpplleess + U:tolsun.oulu.fi::tolsun.oulu.fi:6667 + + U:128.214.5.6::tolsun.oulu.fi:6667 + + U:tolsun.oulu.fi::tolsun.oulu.fi + + If the port number is omitted, irc will default to using 6667. + + + 55.. RReellaatteedd rreessoouurrcceess + + + MMaaiilliinngg lliisstt + A list is dedicated to the people using ircd. If you have + trouble running ircd, or wish to discuss the future, you can + subscribe by sending an email to majordomo@irc.org, with + ``ssuubbssccrriibbee iirrccdd--uusseerrss'' in the body. + + If you just have a question and don't want to subscribe to the + list, mail to ircd-users@irc.org. Be sure to indicate which + version you are using. + + DDeevveellooppmmeenntt + Technical discussions and development are carried on ircd- + dev@irc.org. People interested in very early testing, and/or + working on the source code are welcome. This is done by sending + an email to majordomo@irc.org, with ``ssuubbssccrriibbee iirrccdd--ddeevv'' in + the body. + + FFAAQQ + It can be found on the WWW, at + <http://www.stealth.net/~kalt/irc/faq.html>. + + WWWWWW 22..99 + Vesa Ruokonen has also put serveral pages related to the 2.9 + servers on the WWW: <http://www.irc.org/~irc/server/>. + + + 66.. RReeppoorrttiinngg aa bbuugg + + If you encounter a bug in the software, here is how and where to + report it. + + + 66..11.. HHooww ttoo rreeppoorrtt aa bbuugg + + To save everyone time, make sure that your e-mail contains all the + information related to your problem. In particular, we need to know: + + PPaacckkaaggee vveerrssiioonn + The IRC software version you are using: please include the + output obtained by running ``irc -v'' for the client, and/or + ``ircd -v'' for the server. + + Also, let us know if you have applied any patch to the package + or if it is the vanilla version. + + OOSS Please, indicate which OS version you are running. + + CCoonnffiigguurraattiioonn + If it is related to a configuration problem with the server, + include the relevant parts of the configuration file. + + BBaacckkttrraaccee + If the bug results in a crash, please include the backtrace. + (This can be done, for example, by running ``gdb'' on the core + file, and typing ``where''). + + FFiixx + If you have a fix, don't forget to include it. + + + 66..22.. WWhheerree ttoo sseenndd aa bbuugg rreeppoorrtt + + Reports should be sent to ircd-bugs@irc.org. Your report will be + reviewed and forwarded to the appropriate mailing list. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/Juped/Advertisement b/doc/Juped/Advertisement new file mode 100644 index 0000000..585c467 --- /dev/null +++ b/doc/Juped/Advertisement @@ -0,0 +1,39 @@ + The Internet Relay Chat Program - IRC + + Author: Jeff Trim, April '89 + Revised: Greg Lindahl, Oct '90 (gl8f@virginia.edu) + Re-Revised: Helen Rose, March '94 (hrose@kei.com) + +Have you ever wanted to talk with computer users in other parts of the +world? Well guess what? You can! The network is called IRC and it is +networked much over North America, Europe, and Asia, Oceania, and parts of +Africa. This program is a substitution for talk(1), ytalk(1) and many +other multiple talk programs you might have read about. When you are +talking in IRC, everything you type will instantly be transmitted around +the world to other users that might be watching their terminals at the +time - they can then type something and RESPOND to your messages - and +vise versa. I should warn you that the program can be very addictive once +you begin to make friends and contacts on IRC ;-) especially when you +learn how to cuss in 14 languages. + +Topics of discussion on IRC are varied, just like the topics of Usenet +newsgroups are varied. Technical and political discussions are popular, +especially when world events are in progress. IRC is also a way to expand +your horizons, as people from many countries and cultures are on, 24 hours +a day. Most conversations are in English, but there are always places to +chat in German, Japanese, and Finnish, and occasionally other languages. + + How To Get IRC (technical) + +IRC is a fully-distributed client-server system, much like +NNTP-Usenet, with several clients availble in C and elisp. You may ftp +documentation and clients from any of the following sites: + +many kinds of clients (C, elisp, X11, VMS, REXX for VM, MSDOS, Macintosh): +cs.bu.edu:/irc/clients +ftp.acsu.buffalo.edu:/pub/irc +ftp.funet.fi:/pub/unix/irc +coombs.anu.edu.au:/pub/irc + +If you have any questions about IRC installation, write to hrose@kei.com. + diff --git a/doc/Juped/ChangeLog.common b/doc/Juped/ChangeLog.common new file mode 100644 index 0000000..f6b10ae --- /dev/null +++ b/doc/Juped/ChangeLog.common @@ -0,0 +1,91 @@ +/************************************************************************ + * IRC - Internet Relay Chat, lib/ircd/ChangeLog + * Copyright (C) 1990 Mike Bolotski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +Mon Sep 02 17:08:43 1991 Darren Reed <avalon@coombs.anu.edu.au> + + * general comments: + + various files now have dependencies depending on whether it is the + client or server the files are being compiled for. + + * parse.c + + find_*() routines changed to use hash table lookup. + + * send.c + + changed to maximize presence of the local client array. + sendto_ops_butone() fixed back to not broadcast wallops. + +Sun Jun 30 23:21:50 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * parse.c + Changed from->name to sender; Maybe double search can be removed + + * send.c + LOOP detected!! + Fixed sendto_channel_butone() as suggested by msa. + send.c needs TOTAL cleanup. + + * bsd.c + Final fixes of inet_netof() and inet_nota() + + * send.c + Changed some SendMessage() into sendto_one() (code duplication ;)) + +Wed Jun 20 11:25:54 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + Added gruner's patches. + Patches to make string channels work done as well to some files. + +Sun Jun 17 21:29:04 1990 Armin Gruner (gruner@informatik.tu-muenchen.de) + + * parse.c + In case that a server sends an unknown command to a client (!!), + debug() is called, as client handles debug outputs now. + +Thu May 10 17:15:12 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * dbuf.c + Fixed memcpy and bcopy problems in different machines + +Sat Jan 6 15:14:14 1990 Mike Bolotski (mikeb at coho.ee.ubc.ca) + + * config.h + Added Poohbear's cleanup changes. + Added #undef SYSV if mips is defined (as per jlp@hamblin.byu.edu) + + +Sat Dec 16 16:06:17 1989 Mike Bolotski (mikeb at coho.ee.ubc.ca) + + * config.h + + Changed NOTTY to TTYON, and reversed the logic everywhere. + Now TTYON has to be explicitly defined in order to produce + tty output. + + +Thu Dec 14 12:50:36 1989 Mike Bolotski (mikeb at coho.ee.ubc.ca) + + * version.c + Added a version.c file to contain the version numbers and + prompt strings. Removed the old #ifdef MAIN style definition + + + diff --git a/doc/Juped/ChangeLog.doc b/doc/Juped/ChangeLog.doc new file mode 100644 index 0000000..538d791 --- /dev/null +++ b/doc/Juped/ChangeLog.doc @@ -0,0 +1,90 @@ +/************************************************************************ + * IRC - Internet Relay Chat, doc/ChangeLog + * Copyright (C) 1990, Mike Bolotski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + +Tue Mar 22 17:32:33 1994 Helen T. Rose Davis (hrose@rocza.kei.com) + + * Re-rewrite of documentation to coincide with 2.8.17 release. + +Mon Mar 29 01:26:16 1993 + + * INTSALL updated. + * m4macros added. + +Fri Jan 22 22:49:20 1993 + + * INTSALL updated. + +Thu Dec 17 19:41:19 1992 Darren Reed <avalon@coombs.anu.edu.au> + + * general Well, these docs were updated for 2.7, nobody + documented it - must be a general distaste for + documentation I'd say :) + + Work on 2.8 documentation slowly creaping along. + +Mon Sep 02 17:12:41 1991 Darren Reed <avalon@coombs.anu.edu.au> + + * Documentation brought upto date with new features to 2.6.2 + + +Mon Aug 26 16:51:01 1991 Helen Trillian Rose (hrose@eff.org) + + * Rewrite of documentation (again) to coincide with the 2.6.2 + release. + +Wed Oct 31 18:05:12 1990 Jarkko Oikarinen + + * Added hrose@cs.bu.edu's patches to irc2.6 + - Documentation rewrites... + - patches + +Fri Jun 29 18:54:40 1990 Armin Gruner (gruner@informatik.tu-muenchen.de) + + * NETWORKING + + Added some sites in Germany + +Sat Dec 16 15:56:41 1989 Mike Bolotski (mikeb at coho.ee.ubc.ca) + + * INSTALL + + Modified the installation document as per Valdis's nitpicking. + Improved the grammer and speling of a lot of dokumentation. + Removed lots and lots of informal wording, eh? and especially + the long run on sentences that try to say a lot but really don't + and are present only to show the author's superiority, especially + when quoting from a prestigious work like Webster's New Collegiate + Dictionary, gosh, specifically the 1979 version (ISBN + 0-87779-3580-1), which I guess I should run out and purchase + immediately, for otherwise I might be considered ignorant by + wise men who have written a great deal of code in VS/Pascal and + even IBM Assembler and still can't manage not to avoid including + .QUIT in every goddam mail message. + + + * HISTORY + + Added a recent history of the version numbers and the new + patchlevel mechanism. + + + * BugList + + Added a BugList file including the notation of bug numbers. diff --git a/doc/Juped/ChangeLog.include b/doc/Juped/ChangeLog.include new file mode 100644 index 0000000..481b39b --- /dev/null +++ b/doc/Juped/ChangeLog.include @@ -0,0 +1,85 @@ +/************************************************************************ + * IRC - Internet Relay Chat, ircd/ChangeLog + * Copyright (C) 1990 Jarkko Oikarinen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +Sat Jul 25 05:52:43 1992 + * common.h Dynix (sequent) doesnt have malloc.h but it appears + Dynix/PTX does. Blah. + +Fri Jul 24 18:43:35 1992 + * config.h, sys.h, common.h + Applied patches from Adrian Hall for compiling on + Dynix/PTX (email: csc260@central1.lancaster.ac.uk). + +Mon Sep 02 17:06:59 1991 Darren Reed <avalon@coombs.anu.edu.au> + + * config.h + added MAXCONNECTIONS (see config.h for details) + added NICKNAMEHISTORYLENGTH + + * hash.h + Added to support for ../ircd/hash.c + + * msg.h + Commands reordered in (hopefully) order of useage. + All commands now marked for flood protection. + +Tue Jul 02 11:10:26 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * config.h + changed MSG_MAIL to MSG_NOTE as requested by the author. + +Mon Jul 01 20:37:38 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * config.h + #define WALL a priori. WALL should be go away in future version. + + * numeric.h + ERR_TOOMANYTARGETS added. + +Mon Dec 03 13:56:36 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * config.h + Switches for NEED_* added. + +Mon Nov 26 10:33:43 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * sys.h[.SH] + declaration of dummy() and restart() depending on configuration + process. + +Sat Nov 10 18:00:44 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * New header file: common.h, should be included into all source + files. Created sys.h.SH, Makefile.SH, config.h.SH; these files + are extracted by running Configure. + + * Added some function declarations + Removed Makefile (do we need one here ?). + +Wed Jun 20 11:44:00 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * config.h + MAIL changes to config.h + * struct.h + Numerous changes to file to make string channels work + +Thu May 10 22:37:23 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * config.h + Added UPHOST into config.h (Who removed it ?) diff --git a/doc/Juped/ChangeLog.irc b/doc/Juped/ChangeLog.irc new file mode 100644 index 0000000..18a86b7 --- /dev/null +++ b/doc/Juped/ChangeLog.irc @@ -0,0 +1,77 @@ +/************************************************************************ + * IRC - Internet Relay Chat, irc/ChangeLog + * Copyright (C) 1990 Mike Bolotski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +Mon Dec 9 06:38:57 1991 Darren Reed <avalon@coombs.anu.edu.au> + * All files + Updated to work properly with 2.7. Its early and I'm cold. + +Sun Jun 30 14:45:59 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * irc.c + Removed MSG protocol command. Kludge to get channel msgs working. + * msg.c + Reformatted WHOERPLY output :) + +Wed Nov 28 20:45:42 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * c_msg.c + Fixed abuf[123] overflow. (by using mybuf and removing the buffers) + +Sat Nov 10 17:59:29 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * Added #include "common.h" into all source files, moved "common" + and regularly used declarations to include/common.h + +Wed Jun 20 11:45:30 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + String channel fixes to files, added some numerics. + +Sun Jun 17 17:12:14 1990 Armin Gruner (gruner@informatik.tu-muenchen.de) + + * c_debug.c + New created file, for the benefit of wrong server stuff output + if client does not recognize it. common/debug.c has been removed. + + * c_numeric.c + Changed output of YOUWILLBEBANNED and YOUREBANNEDCREEP, now only + the first digits (== minutes) of the msg will be inserted. + + * irc.c + Defined debuglevel to DEBUG_ERROR, now more error + conditions are displayed. + + +Sat Jan 6 14:48:34 1990 Mike Bolotski (mikeb at coho.ee.ubc.ca) + + * screen.c + + Changed insert = ~insert to be insert = !insert. + Gotta be careful about those bitwise operators, WiZ. + + * swear.c + + Changed scroll to scroll_ok. Changed extern/static definitions + of tgoto, getenv to work with ANSI C compilers. + + * edit.c + + Changed #if HPUX to #if HPUX || defined(mips) + + + diff --git a/doc/Juped/ChangeLog.ircd b/doc/Juped/ChangeLog.ircd new file mode 100644 index 0000000..228ce0d --- /dev/null +++ b/doc/Juped/ChangeLog.ircd @@ -0,0 +1,458 @@ +/************************************************************************ + * IRC - Internet Relay Chat, ircd/ChangeLog + * Copyright (C) 1990 Mike Bolotski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +Tue Sep 1 20:16:42 1992 + * s_bsd.c, s_bsd.c, s_serv.c + * TRACE/STATS now show logfiles if logging is enabled. + +Tue Sep 1 03:56:21 1992 + * channel.c * bug found in set_mode() - length of strings when + setting/clearing chanop was possibly incorrect. + * a few optimizations have hopefully been added as + well. + + * s_bsd.c, s_auth.c + * RFC913 (authd) / TAP code separated from s_bsd,c to + s_auth.c + + * s_misc.c, s_debug.c + * various code/routines removed from s_misc.c and put + in s_debug.c where it truely belongs. + +Tue Aug 25 16:07:01 1992 + * ircd.c * chroot(2) option from Seth added to work along + with SET_UID & SET_GID for servers running as + root. (seth@ctr.columbia.edu) + +Thu Aug 13 18:46:53 1992 + * channel.c * Bug in send_channel_modes() fixed which causes + trashed +b's to be sent on server rejoins. + +Thu Aug 13 17:40:47 1992 + * channel.c * Added channel passwords (keys). + +Tue Aug 11 14:05:12 1992 + * channel.c * JOIN bug giving chanop on wrong channels fixed. + Reported by Rogue_F. + +Tue Aug 4 04:38:23 1992 + * s_bsd.c, s_serv.c, s_conf.c + * Username authentication for servers completed. + Username now required in host portion of the + C/N lines for a connection to be completed. + +Tue Aug 4 03:45:54 1992 + * IDENT changes finally debugged. + +Tue Aug 4 02:16:42 1992 + * s_bsd.c, s_user.c, s_serv.c, ircd.c + * IDENT code now written such that it works in a + similar manner to the DNS async code and thus should + stop the server hanging (if at all). + + * authuser.c * Removed. (redundant). + +Fri Jul 31 01:05:57 1992 + * s_user.c * m_whois() changes to stop people abusing /whois * + and kiling other links to/from that server. + +Sat Jul 25 07:33:20 1992 + * s_user.c * m_oper() fixed so it doesnt core dump when it + calls send_umode(). send_umode_toservs() added. + +Sat Jul 25 05:51:01 1992 + * s_bsd.c * Patches for little endian systems (ie sequents :) + completed. (Fixing of RPL_MYPORTIS) + +Fri Jul 24 18:43:35 1992 + * s_bsd.c, s_conf.c, ircd.c, s_misc.c + * Applied patches from Adrian Hall for compiling on + Dynix/PTX (email: csc260@central1.lancaster.ac.uk). + +Fri Jul 24 00:07:41 1992 + Its been busy with other things so these comments + apply over a few days. + + * general Compiles cleanly under ultrix 4.2 and AIX 3.1 + + * s_user.c O-lines host field changed to user@host. + This change could sweep across to other lines yet. + + * s_serv.c L-lines host field made functional. + + * s_bsd.c I-lines also take user@host as the host now :) + +Tue Jul 14 03:51:04 1992 + * s_msg.c, s_serv.c, s_user.c + - THE BIG SPLIT occured! s_msg.c split into two files: + s_serv.c and s_user.c + +Mon Jul 13 03:08:03 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_conf.c, class.c + - added MAXSENDQ. field for classes. + +Sun Jul 12 10:41:48 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_msg.c - added m_close + +Sat Jul 11 01:01:09 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_err.c - Created, debuged and Added. + * general - Generic creation of ERR and RPL numerics from routines + in s_err.c. The use of these is optional. + * channel.c - Changed NAMES, LIST to be able to query remote + servers. + - NAMES, LIST, TOPIC all understand channel name lists + using a comma (,) as a name separator. + +Sat Jul 4 22:40:35 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_bsd.c, ircd.c, s_conf.c, s_msg.c + - Changed DIE/RESTART/REHASH to be signal activated or + optionally allow operators to issue REHASH/RESTART. + +Sat Jul 4 04:12:43 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_bsd.c, res.c + - fixed automatic lookup of hostnames returned by a + lookup of the IP#. + +Fri Jul 3 16:15:39 1992 Darren Reed <avalon@coombs.anu.edu.au> + * channel.c - added comments to the KICK command. + * s_msg.c - rewrote WHOIS, optimized sending of JOIN channels at + net splits. + * general - checked to make sure all replies had a ':' in the + reply to mark the last parameter being sent. + +Thu Jul 2 07:56:46 1992 Darren Reed <avalon@coombs.anu.edu.au> + * channel.c - imposed 256 character limit on channel names for + clients local to the server. + +Thu Jul 2 03:41:15 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_msg.c - changed numeric reply 200 from TRACE. Now shows next + server in the reply line (extra arg). + +Tue Jun 30 04:53:11 1992 Darren Reed <avalon@coombs.anu.edu.au> + * s_bsd.c - split up check_server() to accomodate the name lookup + in the middle of it for access checking. + * s_msg.c - split up m_server to work with the splitup of + check_server(). + +Mon Jun 29 23:46:32 1992 Darren Reed <avalon@coombs.anu.edu.au> + * whowas.c - added RPL_ENDOFWHOWAS to the whowas reply chain. + +Sun Jun 28 21:31:20 1992 Darren Reed <avalon@coombs.anu.edu.au> + * channel.c, send.c + - channel name masks using ":mask" completed along with + removal of # significance. '%' channel prefix is + local to server. + + + The removal of the # significance was temporary due to + too many problems with the nickname/channelname space + problems. + + * s_bsd.c, res.c, s_conf.c + - hostname and ip number lookup working asynchronously. + * s_bsd.c - udp port created. echo's any data sent to it. + +Sun Dec 1 Greg Lindahl <gl8f@virginia.edu> + * general - gee, avalon, you could at least try. as of pre16 + numerics restored to old values. MSG_NOTE code + removed, because it does not pass Saber C. + * support.c - ctype macros now give values for EOF. + * dbuf.c - test for bozo compilers + * example.conf- more documentation + * s_msg.c - pjg's patch to fix m_server + * ircd.c - print message when debugging off and debugtty set + * config.h - remove many dead crufty options. + +Sun Dec 1 13:41:11 1991 Darren Reed <avalon@coombs.anu.edu.au> + * all files - There have been so many changes and bug fixes going + into 2.7 that it would be impossible to list them all. + +Mon Nov 4 14:35:07 1991 Darren Reed <avalon@coombs.anu.edu.au> + * s_msg.c - installed msa's patch to m_nick + +Mon Nov 4 01:03:45 1991 Darren Reed <avalon@coombs.anu.edu.au> + * all files - changed all functions to have "function_name" style + names. All macros now MacroName. + * general - lots of various different work in preparation for 2.7 + +Thu Sep 19 14:55:24 1991 Darren Reed <avalon@coombs.anu.edu.au> + * s_msg.c, channel.c + - moved m_topic() and m_invite() from s_msg.c to + channel.c + - changed m_topic() to now process # channel topics + +Mon Sep 02 16:27:53 1991 Darren Reed <avalon@coombs.anu.edu.au> + (lost previous ChangeLog which had accurate dates of additions + for 2.6.2. Following is changes from 2.6.1 to 2.6.2). + + * s_conf.c - added L-line handling for Leaf Enforcement. + (Courtesy Wumpus (Greg Lindhal)) + - added det_I_lines_butfirst to make sure each client + connection only ever has (at most) 1 I-line attached + to it. + + * channel.c - fixed ghost ChanOp problem from earlier versions. + - painful ^G mode bug fixed for 2.6.1 + + * ircd.c - some problems with TryConnections fixed. + + * s_bsd.c, ircd.c, s_msg.c + - local clients are now stored and referenced with an + array of pointers. This has a fixed size :/ + + * s_msg.c, list.c + - client list is now a double linked list. + - moved some code to list.c to create addition/deletion + routines to add/delete client records from the list. + + * list.c - added NICKNAMEHISTORYLENGTH to replace the 'magic' 200. + + * s_msg.c - Added following commands: + USERHOST <nickname> [n.[n.[n.[n.]]]] + ISON <nickname> [nickname...] + + * hash.c, s_msg.c, channel.c + - (finally) added hash tables for nickname, server and + channel name lookup. Nicknames and servers share the + same table. + +Thu Jul 04 20:31:10 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_numeric.c + Changed sptr->name to parv[0]; use strtoken() for loop. + +Tue Jul 02 11:11:15 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * ircd.c, channel.c, s_msg.c + changed MSG_MAIL to MSG_NOTE as requested by the author + Fixed m_links(); remote LINKS should work now. + * mail.c + Removed mail.c, replaced by new version 1.3pre8, now note.c + +Mon Jul 01 20:35:40 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c + m_notice(), m_text(), m_privmsg() merged to one function. + m_wall() changed. Default is WALL. Should be eliminated + anyways in next version. + + * channel.c + Changed error msgs when parameters from 'l' are missing. + +Sun Jun 30 14:53:42 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c + Major cleanups; Server/host mask msgs moved to NOTICEs. + m_whois changed. For nonexistent nickname an error is created now. + +Sat Jun 29 15:46:35 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c + Fixed m_summon error bug + Applied msa'a patches. Fixes ExitOneClient(). + + * channel.c + Fixed join ctrl-g bug + +Sat Apr 6 19:47:00 1991 Jarkko Oikarinen <jto@tolsun.oulu.fi> + + * Added destination parameter to /links (a'la /whois) + +Thu Apr 4 16:01:16 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * ircd.c, s_bsd.c + Fix SIGHUP - SIGHUP to ircd causes a rehash() finally. + + * c_msg.c + Fix KILL from an OPER - pre19 with wildcard match didn't pro- + pagate the correct sender. Server kills behind *-domains are + still unsolved. + +Sun Mar 31 08:57:12 1991 Jarkko Oikarinen <jto@tolsun.oulu.fi> + + * WALL placed under #ifdef. Default is no WALL + * Fixed JOIN mode option to accept more parameters + like userlimit. + +Sun Mar 24 07:43:00 1991 Jarkko Oikarinen <jto@tolsun.oulu.fi> + + * A couple minor bug fixes. + * Channel name to ERR_CHANOPRIVSNEEDED and ERR_NOTONCHANNEL. + +Sun Mar 17 09:50:12 1991 Jarkko Oikarinen <jto@tolsun.oulu.fi> + + * m_who() numeric RPL_ENDOFWHO (315) for all queries + * RPL_ENDOFWHOIS (316) reply added + * RPL_ENDOFWHO (315) and RPL_ENDOFWHOIS (316) return + the query parameter now as well. + * RPL_WHOISIDLE (317) returns the idle time of a particular user. + * RPL_NOTOPIC (331), RPL_TOPIC (332) return channel name as a + paramater (this has been already added to RPL_CHANNELMODEIS (324)) + * Limited trace (won't show users on a server) available now for + all users + * Fix to HuntServer() to make sure loops do not happen. + * Added new numeric, ERR_CHANOPRIVSNEEDED (482) which replaces + *all* ERR_NOPRIVILEGES (481) messages where the missing privileges + were channel operator privileges. + * KICK to user not existant on irc now generates + ERR_NOTONCHANNEL (442) error reply. + * ERR_NOSUCHSERVER (402) returns the server name as a parameter. + * ERR_CANNOTSENDTOCHAN (404) now returns the channel name you couldn't + send to. + +Mon Feb 25 16:08:51 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c + 'Fixed' K:-line behaviour of m_user(). Now, the connection + is not closed; USER-msg is distributed with K:-line remark, and + user isn't introduced locally, so user gets 'You have not registered + as a user'. + + * ircd.c + SIGHUP generates rehash() now. + +Mon Feb 11 18:57:56 1991 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c + Fixed m_server(). The domain matching was done against the + return value of GetClientName(), but this never matches + if the servername differs from the host name, because + [real socketname] is added to 'inpath'. + +Fri Jan 12 12:34:21 1991 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * more ircd options at startup... + +Mon Dec 03 13:54:25 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * class.c, s_msg.c, s_bsd.c + Fixes from Avalon. Sigh. + +Wed Nov 28 14:07:11 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * class.c, s_bsd.c (CloseConnection) + Fixes from avalon (DEBUG stuff) + +Tue Nov 27 11:24:56 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c, s_bsd.c, ircd.c, class.c + Isolated the implementation of 'classes' to class.c (by using + macros for accessing the structure members) -- we should start + using this everywhere -- especially with this linear list of + clients!! + + * channel.h (new file) + prototyping, 'channel'-misc, try to isolate channel implemen- + tation to channel.h and channel.c + +Sun Nov 25 16:13:42 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * class.c, class.h + New files for class-handling. Applied Avalon's patches. + Change some code into more readable one (MIN). + +Tue Nov 13 11:44:28 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * s_msg.c + Fixed Invite bug. + + * s_bsd.c + Fixed overhead of check_access. + New function to get qualified (local) domain name: AddLocalDomain() + +Mon Nov 12 20:42:44 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * channel.c + Fixed 2.6 MODE_NOPRIVMSG bug + + * Added mkversion.sh into self configuration extraction, + now version.c.SH + +Sat Nov 10 19:10:33 1990 Armin Gruner <gruner@informatik.tu-muenchen.de> + + * Removed getlongtime() everywhere. + + * s_bsd.c + Removed some ULTRIX sidesteps. + + * s_conf.c + Changed the return values of find_kill(). + + * ircd.c + Avalon's cleanup's. + Change close() to shutdown() (restart()). + +Wed Oct 31 18:20:00 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * 2.6: + - multichannels + - wildcard servers + - more fun stuff I don't remember anymore but which should + be in documentation... + +Sun Oct 21 18:53:02 1990 Christopher Davis (ckd at bucsd) + + * Makefile + - Added IRCDLIBS and IRCDMODE variables + +Wed Jun 20 11:53:00 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + numerous files changed and functions moved around to make + string channels work... + +Sun Jun 17 16:52:39 1990 Armin Gruner (gruner@informatik.tu-muenchen.de) + + * s_debug.c + New created file, common/debug.c has been moved to it because + now we handle also debug outputs in client code + + * s_conf.c + Added the prefix character into all reply-strings. + MSGs never appeared on client site because parse() didn't + recognize it as a prefix (numeric) message + Changed the test of time-interval, now a specified interval + that begins before midnight and ends after should also work + + * s_bsd.c + Added setdtablesize() for sequents OS Dynix, + default was 20; allows more socket connections. + +Sat May 12 22:50:13 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * s_msg.c + Added newline removal from the end of string ctime() + returns (m_info() and m_stats()) + * s_whowas.c + Added newline removal from the end of string ctime() + returns (m_whowas()) + * s_conf.f + Added close() into init_conf() + Was obviously forgotten from there + +Thu May 10 17:17:13 1990 Jarkko Oikarinen (jto@tolsun.oulu.fi) + + * whowas.c + Fixed memcpy and bcopy problems + +Sat Jan 6 17:36:28 1990 Mike Bolotski (mikeb at coho.ee.ubc.ca) + + * date.c + + Added HPUX-specific code since it lacks the timezone() function. + + diff --git a/doc/Juped/INSTALL b/doc/Juped/INSTALL new file mode 100644 index 0000000..8ec35ff --- /dev/null +++ b/doc/Juped/INSTALL @@ -0,0 +1,1167 @@ +/************************************************************************ + * IRC - Internet Relay Chat, doc/INSTALL + * Copyright (C) 1990,1991,1992, Jeff Trim, Mike Bolotski, + * Jarkko Oikarinen and Darren Reed. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + Installing IRC - The Internet Relay Chat Program + + +Overview of this document: + + 1) Installing IRC + 2) The config.h file + 3) Editing the Makefile, and compiling + 4) The ircd.conf file + 5) Mailing list + +1) So that ircd/irc will compile and work correctly with your version of + Unix, it is necessary that you run "make" first. This will run + configure which will probe your system for any peculiarities it has + and setup the Makefile and a file of default #define's ($arch/setup.h). + To change the default directory into which ircd will install using + "make install", invoke "make" using the "CONFIGARGS=--prefix=/dir" + command line option. + +2) Edit the "config.h" file and make changes to the various #DEFINE's: + + a) Define what type of UNIX your machine uses. + + Pick the machine type which best describes your machine and change + the #undef to #define (if needed). Some flavours of Unix require no + #define and in such cases all others should be #undef'd. + + b) DEBUGMODE + + Define DEBUGMODE if you want to see the ircd debugging information + as the daemon is running. Normally this function will be undefined + as ircd produces a considerable amount of output. DEBUGMODE must be + defined for either of -t or -x command line options to work. Defining + this induces a large overhead for the server as it does a large amount + of self diagnostics whilst running. + + c) SPATH, CPATH, MPATH, LPATH, PPATH, TPATH + + Define SPATH to be the directory path to ircd. This is usually + /usr/local/bin/ircd, unless you don't have installation permission + there. + + Define CPATH to be the directory path to the "ircd.conf" file. + This path is usually /usr/local/lib/ircd.conf. The format of this file + will be discussed later. + + The LPATH #define should be set to "/dev/null" unless you plan to + debug the program. Note that the logfile grows very quickly. + + Define MPATH to be the path to the 'motd' (message of the day) file + for the server. Keep in mind this is displayed whenever anyone + signs on to your server. + + The PPATH is optional, but if defined, should point to a file which + either doesn't exist (but is creatable) or a previously used PPATH + file. It is used for storing the server's PID so a ps(1) isn't + necessary. + + Define TPATH to be the directory path to the "ircd.tune" file. + This path is usually /usr/local/lib/ircd.tune. This file is used + by the server to optimize memory use. + + d) CHROOTDIR + + To use the CHROOTDIR feature, make sure it is #define'd and that + the server is being run as root. The server will chroot to the + directory name provded by IRCDDIR (in Makefile). + + e) ENABLE_SUMMON, ENABLE_USERS + + For security conscious server admins, they may wish to leave + ENABLE_USERS undefined, disabling the USERS command which can be used + to glean information the same as finger can. ENABLE_SUMMON toggles + whether the server will attempt to summon local users to irc by + writing a message similar to that from talk(1) to a user's tty. + + f) SHOW_INVISIBLE_LUSERS, NO_DEFAULT_INVISIBLE + + On large IRC networks, the number of invisible users is likely to + be large and reporting that number cause no pain. To aid and effect + this, SHOW_INVISIBLE_LUSERS is provided to cause the LUSERS command + to report the number of invisible users to all people and not just + operators. The NO_DEFAULT_INVISIBLE define is used to toggle whether + clients are automatically made invisible when they register. + + g) OPER_KILL, OPER_REHASH, OPER_RESTART, LOCAL_KILL_ONLY + + The three operator only commands, KILL, REHASH and RESTART, may all + be disabled to ensure that an operator who does not have the correct + privilidges does not have the power to cause untoward things to occur. + To further curb the actions of guest operators, LOCAL_KILL_ONLY can + be defined to only allow locally connected clients to be KILLed. + + h) ZIP_LINKS, ZIP_LEVEL + + As of the 2.9.3 version of the server, server-server connections + may be compressed using the zlib. In order to compile the server + with this feature, you MUST have the zlib package (version 1.0 or higher) + already compiled and define ZIP_LINKS in the config.h file. Compression + use for server-server connections is separately configured in the + ircd.conf file for each server-server link. ZIP_LEVEL allows you to + control the compression level that will be used. Values above 5 will + noticeably increase the CPU used by the server. + + The zlib package may be found at http://quest.jpl.nasa.gov/zlib/ + The data format used by the zlib library is described by RFCs (Request + for Comments) 1950 to 1952 in the files + ftp://ds.internic.net/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate + format) and rfc1952.txt (gzip format). These documents are also + available in other formats from + ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html + + i) SLOW_ACCEPT + + This option is defined by default and is needed on some OSes. It + creates an artificial delay in processing incoming connections. On a + given port, no more than 1 connection per 2 seconds will be processed. + + Undefining this will let the server process connections as fast as + it can which can cause problems on some OSes (such as SunOS) and be + abused (fast massive join of clonebots..), for these reasons, if you + decide to undefine SLOW_ACCEPT you MUST define CLONE_CHECK. + + j) CLONE_CHECK + + This option acts as a wrapper, by checking incoming connections + early before starting ident query. By default, the server will not + accept more than 2 connections from the same host within 10 seconds. + + k) The rest of the user changable #define's should be pretty much self + explanatory in the config.h file. It is *NOT* recommended that any + of the file undef the line with "STOP STOP" in it be changed. + +3) Editting Makefile and compilation. + + Once configure has been run, it is safe to edit the Makefile. You + will most likely need to uncomment the correct IRCDLIBS, IRCLIBS and + IRCDDIR lines. + + To now build and install the server, type "make && make install". + + If you have trouble compiling ircd, copy Makefile.in to Makefile and + edit Makefile as appropriate. + +4) The ircd.conf file. + + After installing the ircd and irc programs, edit the ircd.conf file + as per the instructions in this section and install it in the + location you specified in the config.h file. There is a sample + conf file called example.conf in the /doc directory. + + Appendix A describes the differences between IP addresses and host + names. If you are unfamiliar with this, you should probably scan + through it before proceeding. + + The ircd.conf file contains various records that specify configuration + options. The record types are as follows: + + 1. Server connections (C,c,N) + 2. Machine information (M) + 3. Client connections (I,i) + 4. Default local server (U) + 5. Operator priviliges (O) + 6. Administrative info (A) + 7. Excluded accounts (K) + 8. Excluded machines (Q) + 9. Connection Classes (Y) + 10. Leaf connections (L) + 11. Service connections (S) + 12. Port connections (P) + 13. Hub connections (H) + 14. Version limitations (V) + + + 1. SERVER CONNECTIONS: How to connect to other servers + How other servers can connect to you + + WARNING: + The hostnames used as examples are really only examples and + not meant to be used (simply because they don't work) in real life. + + Now you must decide WHICH hosts you want to connect to and WHAT ORDER you + want to connect to them in. For my example let us assume I am on the + machine "rieska.oulu.fi" and I want to connect to irc daemons on 3 other + machines: + + "garfield.mit.edu" - Tertiary Connection + "irc.nada.kth.se" - Secondary Connection + "nic.funet.fi" - Primary Connection + + And I prefer to connect to them in that order, meaning I first want to + try connecting to "nic.funet.fi", then to "irc.nada.kth.edu", and + finally to "garfield.mit.edu". So if "nic.funet.fi" is down or + unreachable, the program will try to connect to "irc.nada.kth.se". + If irc.nada.kth.se is down it will try to connect to garfield and so forth. + PLEASE limit the number of hosts you will attempt to connect to down to 3. + This is because of two main reasons: + a) to save your server from causing extra load and delays + to users + b) to save internet from extra network traffic + (remember the old rwho program with traffic problems when + the number of machines increased). + + The format for the CONNECT entry in the "ircd.conf" is: + + C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET PORT>:<Class> +Field: 1 2 3 4 5 6 + + for example: + + C:nic.funet.fi:passwd:nic.funet.fi:6667:1 + + - or - + + C:128.214.6.100:passwd:nic.funet.fi:6667:1 + + - or - + + C:root@nic.funet.fi:passwd:nic.funet.fi:6667:1 + + + Explanation: + + Each field is separated with a ":" charcter: + + Field 1: Field 1 tells the IRC program which option is being configured. + "C" corresponds to a server Connect option. + + Field 2: Specifies the host name or IP address of the machine to connect + to. If "user@" prefixes the actual hostname or IP address + the server will require that the remote username returned by + the ident server be the same as the one given before the "@". + + Field 3: The password of the other host. A password must always be + present for the line to be recognized. + + Field 4: The full hostname of the target machine. This is the name that + the TARGET server will identify itself with when you connect + to it. If you were connecting to nic.funet.fi you would receive + "nic.funet.fi" and that is what you should place in + this field. + + Field 5: The INTERNET Port that you want to connect to on the TARGET + machine. Most of the time this will be set to "6667". + If this field is left blank, then no connections will + be attempted to the TARGET host, and your host will accept + connections FROM the TARGET host instead. + The port field can contain 2 ports, separated by a . + In this case, the first port is used when auto-connecting, + the second port is used for the UDP pings to the targer + server. + + Field 6: The class field should refer to an existing class and + determines the maximum number of simultaneous uses of the + C-line allowable through the max. links field in the Y-line. + + NEW!!! + As of the 2.9.3 version of the server, server connections can be + compressed with the zlib library. To define a compressed connection, + you must have compiled the server with ZIP_LINKS defined (cf 2.h), and + use a _lowercase_ C line. + + Some examples: + + C:nic.funet.fi::nic.funet.fi:6667:1 + + This reads: Connect to host "nic.funet.fi", with no password + and expect this server to identify itself to you as + "nic.funet.fi". Your machine will connect to this host to + PORT 6667. + + C:18.72.0.252:Jeff:garfield.mit.edu:6667:1 + + This reads: Connect to a host at address "18.72.0.252", using a + password of "Jeff". The TARGET server should identify + itself as "garfield.mit.edu". You will connect to Internet + Port 6667 on this host. + + C:irc.nada.kth.se::irc.nada.kth.se:1 + + This reads: do not attempt to connect to "irc.nada.kth.se", + but if "irc.nada.kth.se" requests a connection, + allow it to connect. + + Now back to our original problem, we wanted OUR server CONNECT to 3 + hosts, "nic.funet.fi", "irc.nada.kth.se" and "garfield.mit.edu" in + that order. So as we enter these entries into the file they must be + done in REVERSE order of how we could want to connect to them. + + Here's how it would look if we connected "nic.funet.fi" first: + + C:garfield.mit.edu::garfield.mit.edu:6667:1 + C:irc.nada.kth.se::irc.nada.kth.se:6667:1 + C:nic.funet.fi::nic.funet.fi:6667:1 + + Ircd will attempt to connect to nic.funet.fi first, then to irc.nada + and finally to garfield. + + Reciprocal entries: + + Each "C" entry requires a corresponding 'N' entry that specifies + connection priviliges to other hosts. The 'N' entry contains + the password, if any, that you require other hosts to have before + they can connect to you. These entries are of the same format as + the "C" entries. + + The format for the NOCONNECT entry in the "ircd.conf" is: + + N:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<Domain Mask>:<Class> +Field: 1 2 3 4 5 6 + + Let us assume that "garfield.mit.edu" connects to your server + and you want to place password authorization authorization on garfield. + The "N" entry would be: + + N:garfield.mit.edu:golden:garfield.mit.edu:: + + This line says: expect a connection from host "garfield.mit.edu", + and expect a login password of "golden" + and expect the host to identify itself as "garfield.mit.edu". + + N:18.72.0.252::garfield.mit.edu:: + + This line says: expect a Connection from host "18.72.0.252", and + don't expect login password. The connecting host should identify itself + as "garfield.mit.edu". + + Explanation: + + Each field is separated with a ":" charcter: + + Field 1: "N" corresponds to a server Noconnect option. + + Field 2: Specifies the host name or IP address of the machine to connect + to. If "user@" prefixes the actual hostname or IP address + the server will require that the remote username returned by + the ident server be the same as the one given before the "@". + + Field 3: The password of the other host. A password must always be + present for the line to be recognized. If CRYPT_LINK_PASSWORD + is defined in config.h, this password must be crypted. + + Field 4: The full hostname of the target machine. This is the name that + the TARGET server will identify itself with when you connect + to it. If you were connecting to nic.funet.fi you would receive + "nic.funet.fi" and that is what you should place in + this field. + + Field 5: Domain masking, see below. + + Field 6: The class field should refer to an existing class. + + Wildcards domains: + To reduce the great amount of servers in IRCnet wildcard + DOMAINS were introduced in 2.6. To explain the usage of + wildcard domains we take an example of such: + *.de - a domain name matching all machines + in Germany. + Wildcard domains are useful in that ALL SERVERS in Germany + (or any other domain area) can be shown as one to the + rest of the world. Imagine 100 servers in Germany, it + would be incredible waste of netwotk bandwidth to broadcast + all of them to all servers around the world. + + So wildcard domains are a great help, but how to use them ? + They can be defined in the N-line for a given connection, + in place of port number you write a magic number called + wildcard count. + + Wildcard count tells you HOW MANY PARTS of your server's name + should be replaced by a wildcard. For example, your server's + name is "tolsun.oulu.fi" and you want to represent it as + "*.oulu.fi" to "nic.funet.fi". In this case the wildcard count + is 1, because only one word (tolsun) is replaced by a wildcard. + If the wildcard count would be 2, then the wildcard domain would + be "*.fi". Note that with wildcard name "*.fi" you could NOT + connect to "nic.funet.fi", because that would result in a server + name COLLISION (*.fi matches nic.funet.fi). + + I advice you to not to use wildcard servers before you know + for sure how they are used, they are mostly beneficial for + backbones of countries and other large areas with common domain. + + + 2. MACHINE INFORMATION + + Introduction. + IRC needs to know a few things about your UNIX site, and the "M" command + specifies this information for IRC. The fomat of this command is: + + M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port> + Field: 1 2 3 4 5 + + Explanation: + + Field 1: "M" specifies a Machine description line + + Field 2: The name of YOUR server adding any Internet DOMAINNAME that + might also be present. If this hostname can be resolved, + the IP# found will be used to for outgoing connections. + Otherwise the default interface address of the host is used. + The server name may not be FQDN of another host. + (This means all outgoing connections will be done from the + same IP#, even if your host has several IP#). + + Field 3: If the machine on which you run the server has several IP + addresses, you can define which IP# to use for outgoing + connections. This overrides field 2. + See Also the "Port Connections" section. + + Field 4: Geographic Location is used to say WHERE YOUR SERVER is, + and gives people in other parts of the world a good + idea of where you are! If your server is in the USA, it is + usually best to say: <CITY> <STATE>, USA. Like for Denver + I say: "Denver Colorado, USA". Finnish sites (like + tolsun.oulu.fi generally say something like "Oulu, Finland". + + Field 5: Defines the port on which your server will listen for udp + pings from other servers. This should be the port were other + servers are set to autoconnect. (Also see the port field + description in connect lines). + + Example: + M:tolsun.oulu.fi::Oulu, Finland:6667: + + This line reads: My Host's name is "tolsun.oulu.fi" and + my site is located in "Oulu, Finland". + + M:orion.cair.du.edu::Denver Colorado, USA:6667: + + This line reads: My Hosts name is "orion.cair.du.edu" + and my site is located in "Denver Colorado, USA". + + 3. CLIENT CONNECTIONS - How to let clients connect to your IRCD. + + Introduction. + A client is a program that connects to the ircd daemon (ircd). + There are clients written in C, GNU Emacs Lisp and many other languages. + The "irc" program is the C client. Each person that talks via IRC is + running their own client. + + The ircd.conf files contains entries that specify which clients are + allowed to connect to your irc daemon. Obviously you want to allow your + own machine's clients to connect. You may want to allow clients from + other sites to connect. These remote clients will use your server + as a connection point. All messages sent by these clients will pass + through your machine. + + The format of this entry in the conf file is: + + I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> + Field:1 2 3 4 5 6 + i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> + + + For example, if you were installing IRC on tolsun.oulu.fi and you wanted + to allow examples sake let us assume you were making this file for + tolsun and you wanted to let your own clients to connect to your + server, you would add this entry to the file: + + I:x::tolsun.oulu.fi::1 + + If you wanted to let remote clients connect, you could add the + following lines: + + I:x::*.du.edu::1 + + Allow any clients from machines whose names end in "du.edu" to connect + with no password. + + I:128.214.6.100::nic.funet.fi::1 + + Allow clients from a machine with that IP number to connect. + Numeric match is enough, name is not required anymore. + + I:x:secret:*.tut.fi::1 + + Allow clients from machines matching *.tut.fi to connect + with the password 'secret'. + + I:*::*::1 + + Allow anyone from anywhere to connect your server. + This is the easiest way, but it also allows people to for example + dump files to your server, or connect 1000 (or how many open + sockets per process your OS allows) clients to your machine + and take your network ports. Of course the same things can be + done by simply telnetting to your machine's SMTP port (for example). + + I:x::*.fi:6667:1 + + Allow clients from machines matching *.fi to connect on the port + 6667. + + I:*@*::*@*::1 + + Allow clients from anywhere to connect your server. + If the client machine does not reply to your server ident query, + the client's username will be prefixed by ~ + + NEW!!! + As of the 2.7.2d version of the server, the server is able to accept + connections on multiple ports. I-lines are required for each P-line + to allow connections to be accepted. For unix sockets, this means + either adding I:/path/port::/path/port or some variation (wildcards + are recognised here). For internet ports, there must be an I-line + which allows the host access as normal, but the port field of the + I-line must match that of the port of the socket accepting the + connectiion. A port number of 0 is a wildcard (matches all ports). + + NEW!!! + As of the 2.9.1 version of the server, i lines are introduced. They + work the same way as I lines, but the clients matching an i line + will have a restricted connection. (no nick/mode change, no kick) + Such users will have their username prefixed by +, = or - depending + on the ident reply. + + 4. DEFAULT HOSTS (for local clients) *obsoleted* + + Introduction. + This defines the default connection for the irc client. If you are + running an ircd server on the same machine, you will want to define + this command to connect to your own host. If your site is not running + a server then this command should contain the TARGET host's connection + information and password (if any). The format for this command is: + + U:<TARGET Host addr>:<Password>:<TARGET Host NAME>:<Internet Port> + Field: 1 2 3 4 5 + + + For example: + + U:tolsun.oulu.fi::tolsun.oulu.fi:6667 + U:128.214.5.6::tolsun.oulu.fi:6667 + U:tolsun.oulu.fi::tolsun.oulu.fi + + If the port number is omitted, irc will default to using 6667. + + 5. OPERATOR Privileges: How to become the IRC administrator on your site + + Introduction. + To become an IRC Administrator, IRC must know who is authorized to + become an operator and what their "Nickname" and "Password" is. To add + this information, EDIT your "ircd.conf" file and add the following command + line to it: + + O:<TARGET Host NAME>:<password>:<nickname>:<port>:<class> + Field: 1 2 3 4 5 6 + + Explanation: + + Field 1: Speficies Operator record. If you use capital letter ('O') + in it, it specifies a global operator. Small letter ('o') + specifies a local operator. Local operator has basically the + same rights except global operator with some restrictions. + + Field 2: Tells IRC which host you have the privileges FROM. This + means that you should be logged into this host when you + ask for the priviliges. If you specify "tolsun.oulu.fi" + then IRC will expect your CLIENT to be connected at + "tolsun.oulu.fi" - when you ask for OPERATOR privileges + from "tolsun.oulu.fi". You cannot be logged in at any + other host and be able to use your OPERATOR privileges + at tolsun, only when you are connected at TOLSUN will this + work - this is a safeguard against unauthorized sites. + + + Field 3: If your AUTHORIZATION Password - this is the password that + let's IRC know you are who you say you are! Never tell anyone + your password and always keep the "ircd.conf" file protected + from all of the other users. + + Field 4: The Nickname you usually go by - but you can make this what + you want. It is better to make this a NICKNAME that no one + else knows, but anything will do. I usually use my own + loginname. + + Field 5: Unused. + + Field 6: The class field should refer to an existing class (preferably + having a lower number than that for the relevant I-line) and + determines the maximum number of simultaneous uses of the + O-line allowable through the max. links field in the Y-line. + + Example: + O:orion.cair.du.edu:pyunxc:Jeff::1 + + There is an OPERATOR at "orion.cair.du.edu" that can get + Operator priviliges if he specifies a password of "pyunxc" + and uses a NICKNAME of "Jeff". + + + + 6. ADMINISTRATIVE INFORMATION + + Introduction. + The "A" command is used for administrative information about a site. + The e-mail address of the person running the server should be included + here in case problems arise. + + + A:<Your Name/Location>:<Your Electronic Mailing Addr>:<other>:: + Field: 1 2 3 4 + + Explanation: + + Field 1: "A" specifies an Admin record. + + + Field 2: Use this field to say tell your FULL NAME and where in the + world your machine is. Be sure to add your City, + State/Province and Country. + + + Field 3: Use this field to specify your Electronic Mailing Address + preferably your Internet Mailing Address. If you have + a UUCP or ARAPnet address - please add that as well. Be + sure to add any extra DOMAIN information that is needed, + for example "mail jtrim@orion" probably won't work as a + mail address to me if you happen to be in Alaska. But + "mail jtrim@orion.cair.du.edu" would work because you + know that "orion" is part of the DOMAIN "cair.du.edu". + So be sure to add your DOMAINNAMES to your mailing addresses. + + Field 4: Is really an OTHER field - you can add what you want here, + + + Examples (the line is just one line in the confuration file, here it + is cut into two lines to make it clearer to read): + +A:Jeff Trim - Denver Colorado, USA:INET jtrim@orion.cair.du.edu UUCP {hao, +isis}!udenva!jtrim:Terve! Heippa! Have you said hello in Finnish today?;):: + + Would look like this when printed out with the /admin command: + + Jeff Trim - Denver Colorado, USA + INET jtrim@orion.cair.du.edu UUCP {hao,isis}!udenva!jtrim + Terve! Hei! Heippa! Have you said hello in Finnish today? ;) + + + Note that the A record cannot be split across multiple lines; it will + typically be longer than 80 characters and will therefore wrap around + the screen. + + + 7. REMOVING A USER FROM IRC Remove an errant user from IRC on your site. + + Introduction. + Obviously it is hoped that you wouldn't have to use this command. + Unfortunately sometimes a user can become unmanageable and this is your + only recourse - the KILL USER command. THIS COMMAND ONLY AFFECTS YOUR + SERVER - If this user can connect to another SERVER somewhere else in + the IRC-Network then you would have to talk to the administrator on that + site to disable his access from that IRCD Server as well. + + The format of this command is: + + K:<Host Name>:<time interval(s)|comment>:<User>:<port>: + Field: 1 2 3 4 5 + + Explanation: + + Field 1: "K" tells the IRCD that you are making a KILL USER command + entry. + + Field 2: In this field you specify the Hostname that the user is + connecting from. If you wanted to REMOVE connects + to IRC from "orion.cair.du.edu" then you would want to enter + "orion.cair.du.edu". If you want to REMOVE ALL HOSTS + access you can use '*' (Wild Card notation) and no matter + what host the USERNAME (specified in Field 4) connects from + s/he will be denied access. Removing all hosts isn't + very smart thing to do though, why would you run an ircd + if you allow nobody to connect to it anyways ? + + Field 3: Either leave this field empty or put a comment, then the line + is active continuously for the specified user/host machine. + You may also specify intervals during the line should be + active, see examples above. + + Field 4: The USERNAME of the user you want removed from IRC. For + example 'root'. + + Field 5: The port on which the Kill line will be effective. + 0 means all ports. + + + Some Examples: + K:orion.cair.du.edu::jtrim:0: + + If user 'jtrim' connects to IRC from host "orion.cair.du.edu" + then IMMEDIATELY REMOVE HIM from my IRCD. + + K:*.cair.du.edu::root:0: + + If user 'root' connects to IRC from any host that has the + suffix "cair.du.edu" - then IMMEDIATELY REMOVE THEM from + my IRCD. + + K:*::vijay:0: + + This line reads "I don't care WHAT HOST user 'vijay' is on, + I will NEVER allow username 'vijay' to login to my IRCD. + + K:*.oulu.fi:0800-1200,1400-1900:*:0: + + This disallows all users from hosts with enddomain 'oulu.fi' + access to your server between 8 and 12am, 2 and 7pm. + Users get kicked off if they're already signed on when the + line becomes active (they'll get a warning 5 minutes ago). + + 8. Disallowing SERVERS in your irc net. + + Introduction. + In some cases people run into difficulties in net administration. + For one reason or another you do not want a certain server to be + in your net (for example because of the security holes it opens + for every server if it's not secured carefully). In that case + you should use Q-lines in your server. When you specify a server + name in Q-line, everytime some server link tries to introduce you + a server (remember, all server names are broadcast around the net), + that name is checked if it matches the Q-lines in your server. + If it matches, then your server disconnects the link. Note that + just placing Q-lines to your server probably results in your server + being left alone, unless other servers have agreed to have the + same Q-line in their ircd configuration files as well. + + Example: + Q::of the security holes:foo.bar.baz:: + + This command excludes a server named "foo.bar.baz", the reason + is given to be security holes (you should give a reason, it is + polite). The first field is unused, so leave it empty. + + 9. Connection Classes. + + Introduction. + To enable more efficient use of MAXIMUM_LINKS, connection classes + were implemented. To give a connection a class, add another field + (a sixth) to the C/N lines for a particular server. + Each line for a server should have the same number as the sixth + field. If it is absent, the server deaults it to 0, using the + defaults from the config.h file. To define a connection class, + you need to include a Y: line in the ircd.conf file. This enables + you to define the ping frequency, connection frequency and maximum + number of links that class should have. Currently, the Y: line MUST + appear in the ircd.conf file BEFORE it is used in any other way. + + The format for the line is: + + Y:<CLASS>:<PING FREQUENCY>:<CONNECT FREQ|MAX IP>:<MAX LINKS>:<SENDQ> +Field: 1 2 3 4 5 6 + + Field 2: This is the class number which gains the following attributes + and should match that which is on the end of the C/N/I/O line. + + Field 3: This field defines how long the server will let the connection + remain "silent" before sending a PING message to make sure it + is still alive. Unless you are sure of what you are doing, + use the default value which is in your config.h file. + + Field 4: This field has a different meaning depending on the use of the + Y line: + For servers: By changing this number, you change how often your + server checks to see if it can connect to this + server. If you want to check very occasionally, use + a large value, but if it is an important connection, + you might want a smaller value so that you connect + to it as soon as possible. + For clients: Positive value: defines the maximum number of + clients from the same host (IP) + will be allowed. + Negative value: defines the maximum number of + clients from the same user@host (IP) + will be allowed. Read note below. + + Field 5: This field defines the maximum number of links this class + will allow from automatic connections (C lines). Using /CONNECT + overrides this feature. Also defines the maximum number of + users in this class (I/O lines). + + Field 6: This field defines the 'sendq' value for this class. If this + field is not present, the default (from config.h) is assigned. + + NOTE: leaving any of the fields out means their value is 0 (ZERO)!! + + NOTE: If you plan to use the user@host limit, please read the following + very carefully. The `user' value is the ident reply for the + connection. If no reply was given then it defaults to "unknown" + and thus the effective limit will be per host, not per user@host. + Also, some ident servers return encrypted data which changes for + every connection making the limit void. + + Example: + + Y:23:120:300:5: + + define class 23 to allow 5 auto-connections, which are checked every + 300 seconds. The connection is allowed to remain silent for 120 + seconds before a PING is sent. NOTE: fields 3 & 4 are in seconds. + + You may also give I lines a class (again the sixth field to define + which class). This is only usefull (currently) for redefining the + ping frequency. It can also be useful as a diagnostic to see how + much each I line is used when combined with the TRACE output. + + Another feature of connection class is the ability to do automatic + routing by using the class as a 'priority'. If you are connected + to a server which has a class lower than one of the servers that is + 'behind' it, the server will disconnect the lower class one and + schedule a 'new' connection for the higher class server. + + 10. Leaf Connections. + + Introduction. + To stop servers which should only act as leaves from hubs becoming + hubs accidently, the L line was introduced so that hubs can be aware + of which servers should and shouldnt be treated as leaves. A leaf + server is supposed to remain a node for the entirity of its life + whilst connected to the IRC server network. It is quite easy, however + for a leaf server to be incorrectly setup and create problems by + becoming a node of 2 or more servers, ending its life as a leaf. The + L line enables the administrator of an IRC 'Hub server' to 'stop' a + server which is meant to act as a leaf trying to make itself a hub. + If, for example, the leaf server connects to another server which doesnt + have an L-line for it, the one which does will drop the connection, once + again making the server a leaf. + + L:<SERVER MASK>:*:<SERVER NAME>:<MAX DEPTH>: +Field: 1 2 3 4 5 + + Field 2: mask of which servers the leaf-like attributes are used on + when the server receives SERVER messages. The wildcards * + and ? may be used within this field for matching purposes. + If this field is empty, it acts the same as if it were a + single * (ie matches everything). + + Field 4: the name of the server connected to you that for which you + want to enforce leaf-like attributes upon. + + Field 5: maximum depth allowed on that leaf and if not specified, + a value of 1 is assumed. The depth is checked each time a + SERVER message is received by the server, the hops to the + server being the field checked against this max depth and + if greater, the connection to the server that made its leaf + too deep has its connection dropped. For the L-line to come + into effect, both fields, 2 and 4, must match up with the new + server being introduced and the server which is responsible + for introducing this new server. + + 11. Service Connections (Not Fully Implemented Yet) + + Introduction. + The Service is a special kind of IRC client. It does not have the full + abilities of a normal user but can behave in a more active manner than + a normal client. The following line can be added to your ircd.conf file + to enable a service: + + S:<TARGET Host Mask>:<password>:<service_name>:<service type>:<class> + Field: 1 2 3 4 5 6 + + Explanation: + + Field 2: The host mask should be set to match the hosts(s) from which + the service will be connecting from. This may be either an + IP# or full name (prefered). + + Field 3: This is the password which must be passed in the SERVICE command. + + Field 4: The name used by the service. Services don't have nicknames, but + a static name defined by the S line. + + Field 5: The type of service. It defines the priviledges given to the + service. Be very careful in the types you allow. + The types can be found in include/service.h + + Field 6: The class field should refer to an existing class. + + To connect a service to your server, you must first create an S-line + entry in your ircd.conf file and get your server to read this in (ie + rehash or reboot). Once your server has updated itself, you can then + attempt to register your connection as a service. + Registering as a service is done by sending a SERVICE command to the + server: + + SERVICE servicename servername distribution servicetype 0 :Information + + A successfull registering of a service at the server will result in + a RPL_YOURESERVICE (383) being sent back to you. Any other reply as + a result of sending service indicates an error has occured. + + A service is not a very useful sort of client, it cannot join channels + or issue certain commands although most are available to it. Services + are rejected upon sending an unknown or unallowed command. Services + however, are not affected by flood control and can be granted special + priviledges. It is therefore wise to oversee the use of S-lines with + much care. + + Services can be listed using the SERVLIST command, and can be sent + messages using the SQUERY command. + + 12. Port Connections + + Introduction. + The port line adds flexibility to the server's ability to accept + connections. By use of this line in the ircd.conf file, it is easy + to setup both Unix Domain ports for the server to accept connections + on as well as extra internet ports. + + P:<Internet IP#>:<*>:<Internet IP Mask>:<PORT>: +Field: 1 2 3 4 5 + +or + + P:<Directory>:<*>:<*>:<PORT>: +Field: 1 2 3 4 5 + + Explanation: + Internet Ports + Field 2 + If the host on which the server runs has several IP addresses, you can + define for which IP address connections will be accepted. If no + is defined here, server will bind to all interfaces (INADDR_ANY). + See also MACHINE CONFIGURATION section to properly configure outgoing + connections. + + P:192.168.1.194:::6664: + + Field 4 + The internet IP# mask defines where connections may come from and + be accepted. The IP mask uses either *'s or 0's as wildcards. The + following two lines are the same: + + P:::128.2.*:6664: + P:::128.2.0.0:6664: + + The incoming isn't matched against the mask, rather the ip# string + is decoded and compared segment by segment. Thus + P:128.2*.1.2:::6664: + will not match 128.20.1.2. + + Field 5 + The port number field tells the server which port number it should + listen on for incoming connections. + + Unix Socket Ports. + Field 1 + The path set in field 1 should be the directory name in which to + create the unix socket for later listening to. The server will + attempt to create the directory before creating the unix socket. + + Field 5 + The port field when used in combination with a pathname in a P-line + is the filename created in the directory set in Field 1. + + Example: + P:/tmp/.ircd:::6667: + + Creates a unix socket in the /tmp/.ircd directory called "6667". + The unix socket (file) must be a numerical. + + NOTE: You need at least one P line. + + 13. Hub Connections + + Introduction. + In direct contrast to L-lines, the server also implements H-lines to + determine which servers may act as a hub and what they may 'hub for'. + If a server is only going to supply its own name (ie act as a solitary + leaf) then no H-line is required for, else a H-line must be added as + follows: + + H:<SERVER MASK>:*:<SERVER NAME>:: +Field: 1 2 3 4 + + Explanation: + Field 2 + All servers that are allowed via this H-line must match the mask + given in this field. + + Field 4 + This field is used to match exactly against a server name, wildcards + being treated as literal characters. + + Examples: + + H:*.edu::*.bu.edu:: + + Allows a server named "*.bu.edu" to introduce only servers that + match the "*.edu" name mask. + + H:*::eff.org:: + + Allow "eff.org" to introduce (and act as a hub for) any server. + + Note: It is possible to have and use multiple H-lines (or L-lines) for + the one server. eg: + + H:*.edu:*:*.bu.edu:: + H:*.au:*:*.bu.edu:: + + is allowed as is + + L:*.edu:*:*.au:: + L:*.com:*:*.au:: + + 14. Version limitations + + Introduction. + In direct contrast to L-lines, the server also implements H-lines to + determine which servers may act as a hub and what they may 'hub for'. + If a server is only going to supply its own name (ie act as a solitary + leaf) then no H-line is required for, else a H-line must be added as + follows: + + V:<VERSION MASK>:<FLAGS>:<SERVER NAME>:: +Field: 1 2 3 4 + + Explanation: + Field 2 + Server is not allowed to connect if its version string matches the mask + given in this field. + + Field 3 + This field should contained flags as defined in ircd/s_debug.c + This flags show up in RPL_VERSION. + If any of the flags present in this field are found in the RPL_VERSION + of a server, this server will be denied connection. + This must be used with care. + + Field 4: + This field is used to match server names. The V line will be used + for servers matching the mask given in this field. + + Examples: + + V:020901*::*:: + + Disallows any server which version is 2.9.1* to connect. + + V:020901*:D:*:: + + Disallows any server which version is 2.9.1* or which has been + compiled with DEBUGMODE defined to connect. + + Note: It is possible to have and use multiple V-lines for the one server + mask. + + H:020901:*:*:: + V:020902:*:*:: + + is allowed. + + +Appendix A: Difference between IP addresses and hostnames + + + There are 2 different types of INTERNET addresses, NAME addresses and + NUMERIC addresses. NAME addresses look like ENGLISH words (and indeed + they are ENGLISH words that refer to a given host). A NAME address looks + like "tolsun.oulu.fi" - and that particular address refers to the machine + named TOLSUN in Finland. It is a UNIQUE address because no other machine + in the world has its NAME address the same as "tolsun.oulu.fi". Anytime + you say "telnet tolsun.oulu.fi" - you would always connect to TOLSUN in + Finland. NUMERIC addresses refer to those addresses that are made up of + NUMBERS for example "128.214.5.6" is the NUMERIC address for TOLSUN. This + address is also UNIQUE in that no other machine in the world will be use + those NUMERIC numbers. The NUMERIC address is usually more reliable than + the NAME address because not all sites can recognize and translate the + NAME address into it's numeric counterpart. NUMERIC always seems to work + best, but use a NAME address when you can because it is easier to tell + what host you are connected to. + + + Every Unix machine has a file called "/etc/hosts" on it. This file + contains NAME and NUMERIC addresses. When you supply IRC with a NAME + address it will at first try to find it in /etc/hosts, and then (if it's + really smart), use the local Domain Name Server (DNS) to find the NUMERIC + address for the host you want to connect to. Thus if you plan to use NAME + addresses keep in mind that on SOME sites the entry for the TARGET machine + must be found in /etc/hosts or the NAME address will fail. A typical + entry in /etc/hosts looks like this: + + 130.253.1.15 orion.cair.du.edu orion.du.edu orion # BSD 4.3 + + This particular example is the Host ORION at the University of Denver. + Notice that on the far left is the NUMERIC Address for orion. The + next few ENGLISH words are the NAME addresses that can be used for orion, + "orion.cair.du.edu", "orion.du.edu", "orion". ALL of these NAME addresses + will return the NUMERIC address "130.253.1.15" which IRC will use to + connect to the TARGET UNIX. (when I say TARGET UNIX I am refering to the + UNIX you want to connect to for IRC). Any futher questions about + /etc/hosts should be directed to "man hosts". + + +Appendix B: Enabling Summon Messages + + +-----------------------------------------------------------------------+ + | E N A B L I N G / S U M M O N M E S S A G E S | + +-----------------------------------------------------------------------+ + + *NOTE* You must have ROOT or special access to the GROUP tty ('/dev') + to do this. If you want to allow users around the world to summon + users at your site to irc, then you should make sure that summon works. + + The "IRCD" program needs access to the GROUP of '/dev'. This + directory is where user TTY's are stored (as UNIX treats each Terminal + as a FILE!) IRCD needs GROUP ACCESS to /dev so that users can be + SUMMONED to the program by others users that are *in* the program. + This allows people from other Universities around the world to SUMMON + your users to IRC so that they can chat with them. Berkeley, SUN, HP-UX + and most of the newer versions of UNIX check to see if a USER is + accepting MESSAGES via the GROUP access rights on their TTY listing + in the /dev directory. For example an entry in '/dev' looks like this: + + (Unix Path on BSD 4.3 UNIX is: /dev/ttyp0) + + crw------- 1 jtrim 20, 0 Apr 29 10:35 ttyp0 + + You will note that 'jtrim' OWNS this terminal and can READ/WRITE to this + terminal as well (which makes sense because I am ENTERING DATA and + RECEIVEING DATA back from the UNIX). I logged into this particular + UNIX on "April 29th" at "10:35am" and my TTY is "ttyp0". But further + of *note* is that I do not have my MESSAGES ON! (mesg n) -- This is + how my terminal would look with MESSAGES ON (mesg y): + + crw--w---- 1 jtrim 20, 0 Apr 29 10:35 ttyp0 + + With my MESSAGES ON (mesg y) I can receive TALK(1) requests, use the + UNIX WRITE(1) command and other commands that allow users to talk + to one another. In IRC this would also allow me to get IRC /SUMMON + messages. To set up the "IRCD" program to work with /SUMMON type + the following: (using ROOT or an account that has access to '/dev'). + + % chgrp tty ircd + % chmod 6111 ircd + + The above commands read: "Give IRCD access to GROUP tty (which is /dev) + and then when ANYONE runs the IRCD allow SETUID and SETGID priviliges + so that they can use the /SUMMON command. + + +6) ircd-users + +A mailing list is dedicated to the people using ircd. If you have trouble +running ircd, or wish to discuss the future, you can subscribe by sending +an email to majordomo@stealth.net, with "subscribe ircd-users" in the body. diff --git a/doc/Juped/US-Admin/Networking b/doc/Juped/US-Admin/Networking new file mode 100644 index 0000000..e8dc186 --- /dev/null +++ b/doc/Juped/US-Admin/Networking @@ -0,0 +1,156 @@ +/************************************************************************ + * IRC - Internet Relay Chat, doc/NETWORKING + * Copyright (C) 1994, Helen Rose <hrose@kei.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 1, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + Author: Helen Rose + hrose@kei.com + Date: 3 March, 1994 + +*** Please read this before doing any connecting or writing to ask for +connections. The information contained in this section is crucial to the +way IRC is run. + +Note that any old documentation referring to ANet vs EFnet is out of date +and no longer applies. ANet died so long ago that nobody can remember +*when* it died. + + +To qualify for a link on the irc network, several criteria must be +met. These criteria include (but are not limited to): + +* A well established local irc userbase. A total of 100-150 local irc + users. An average of 15-20 irc users over a 24 hour period is also + acceptable. Note, these user counts are *unique, local* users. So + one person running fifteen clients doesn't count, and one local + person plus fifteen offsite people doesn't count. These are not + arbitrary numbers, it takes at least this many users to equate the + traffic of adding another server to the irc network. + +* A userbase that uses irc *all the time* (15 users on at once but + just for a 3 hour period per day is not sufficient). + +* A good, fast, internet link. Absolutely *NO* SLIP lines. 56k lines + are marginal, they usually cause more trouble than they are worth, + so we recommend a T1 or better. + +It is well established that having a local irc server does not attract +local irc users. Often, your best bet is to set up a local client that is +accessible by everyone at your site, connect it to a nearby offsite +server, and then see if the usage level goes up. (See appendix for list of +open-client servers). + +To see how many users you have, on irc do /m x@monitor.us show site.name +where site.name is your two-part domain name (eg "kei.com" or "bu.edu" or +"mit.edu"). monitor will tell you how many users you have. Once this +number gets over 125 or so, put the level it has reached in your note to +operlist-request@kei.com. + +If you are in the United States and need a link, please mail to +"operlist-request@kei.com" supplying the information listed below. + +(1) Find out if your system has /etc/ping (sometimes /usr/etc/ping) and + ping the following hosts: + + server/machine name IP address Geographical Location + csa.bu.edu 129.197.10.3 Boston, MA + irc-2.mit.edu 18.180.0.2 Cambridge, MA + polaris.ctr.columbia.edu 128.59.68.10 New York, NY + poe.acc.virginia.edu 128.143.83.132 Charlottesville, VA + irc.iastate.edu 129.186.150.1 Ames, IA + dewey.cc.utexas.edu 128.83.135.3 Austin, TX + irc.netsys.com 198.175.9.8 Palo Alto, CA + w6yx.stanford.edu 36.55.0.50 Stanford, CA + goren.u.washington.edu 140.142.63.1 Seattle, WA + +These are results of the typical /etc/ping command: + +(note that the machine I am running this from runs SunOS so I have to use +ping -s ): + +3:59pm hrose@csa : ~ % ping -s polaris.ctr.columbia.edu +PING polaris.ctr.columbia.edu: 56 data bytes +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=0. time=137. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=1. time=163. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=2. time=110. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=3. time=111. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=4. time=78. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=5. time=82. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=7. time=83. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=8. time=91. ms +64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=9. time=159. ms +[...] +^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^ ^^^^^^^ +Size of packet hostname IP address packet number trip time + + +----polaris.ctr.columbia.edu PING Statistics---- +25 packets transmitted, 25 packets received, 0% packet loss +round-trip (ms) min/avg/max = 78/136/327 + + +When you send pings to operlist-request, please only send the results +(the above three lines)--we *don't* need each packet's time. + + +Guidelines: + +Avg Time Connection is +======== ============= +0-20ms Optimal +20-40ms Excellent +40-70ms Very Good +70-90ms Average +90-110ms Acceptable +110ms-150ms Below Average +150ms-200ms Bad +200ms-300ms You're on a very slow link and it is unlikely you will be + able to support a server successfully. + + +** *** WHERE TO FIND HELP!!! *** +** +** If you have any other questions about connecting to an irc server, please +** mail to operlist-request@kei.com. If you have problems mailing there, +** try mailing hrose@kei.com. +** +** *** WHERE TO FIND HELP!!! *** + +Appendix +======== + +Open client servers. + +USA: + csa.bu.edu + irc.colorado.edu + irc.uiuc.edu + +Canada: + ug.cs.dal.ca + +Europe: + irc.funet.fi + cismhp.univ-lyon1.fr + disuns2.epfl.ch + irc.nada.kth.se + sokrates.informatik.uni-kl.de + bim.itc.univie.ac.at + +Australia: + jello.qabc.uq.oz.au + diff --git a/doc/LICENSE b/doc/LICENSE new file mode 100644 index 0000000..9a17037 --- /dev/null +++ b/doc/LICENSE @@ -0,0 +1,249 @@ + + GNU GENERAL PUBLIC LICENSE + Version 1, February 1989 + + Copyright (C) 1989 Free Software Foundation, Inc. + 675 Mass Ave, Cambridge, MA 02139, USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The license agreements of most software companies try to keep users +at the mercy of those companies. By contrast, our General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. The +General Public License applies to the Free Software Foundation's +software and to any other program whose authors commit to using it. +You can use it for your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Specifically, the General Public License is designed to make +sure that you have the freedom to give away or sell copies of free +software, that you receive source code or can get it if you want it, +that you can change the software or use pieces of it in new free +programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of a such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must tell them their rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License Agreement applies to any program or other work which +contains a notice placed by the copyright holder saying it may be +distributed under the terms of this General Public License. The +"Program", below, refers to any such program or work, and a "work based +on the Program" means either the Program or any work containing the +Program or a portion of it, either verbatim or with modifications. Each +licensee is addressed as "you". + + 1. You may copy and distribute verbatim copies of the Program's source +code as you receive it, in any medium, provided that you conspicuously and +appropriately publish on each copy an appropriate copyright notice and +disclaimer of warranty; keep intact all the notices that refer to this +General Public License and to the absence of any warranty; and give any +other recipients of the Program a copy of this General Public License +along with the Program. You may charge a fee for the physical act of +transferring a copy. + + 2. You may modify your copy or copies of the Program or any portion of +it, and copy and distribute such modifications under the terms of Paragraph +1 above, provided that you also do the following: + + a) cause the modified files to carry prominent notices stating that + you changed the files and the date of any change; and + + b) cause the whole of any work that you distribute or publish, that + in whole or in part contains the Program or any part thereof, either + with or without modifications, to be licensed at no charge to all + third parties under the terms of this General Public License (except + that you may choose to grant warranty protection to some or all + third parties, at your option). + + c) If the modified program normally reads commands interactively when + run, you must cause it, when started running for such interactive use + in the simplest and most usual way, to print or display an + announcement including an appropriate copyright notice and a notice + that there is no warranty (or else, saying that you provide a + warranty) and that users may redistribute the program under these + conditions, and telling the user how to view a copy of this General + Public License. + + d) You may charge a fee for the physical act of transferring a + copy, and you may at your option offer warranty protection in + exchange for a fee. + +Mere aggregation of another independent work with the Program (or its +derivative) on a volume of a storage or distribution medium does not bring +the other work under the scope of these terms. + + 3. You may copy and distribute the Program (or a portion or derivative of +it, under Paragraph 2) in object code or executable form under the terms of +Paragraphs 1 and 2 above provided that you also do one of the following: + + a) accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of + Paragraphs 1 and 2 above; or, + + b) accompany it with a written offer, valid for at least three + years, to give any third party free (except for a nominal charge + for the cost of distribution) a complete machine-readable copy of the + corresponding source code, to be distributed under the terms of + Paragraphs 1 and 2 above; or, + + c) accompany it with the information you received as to where the + corresponding source code may be obtained. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form alone.) + +Source code for a work means the preferred form of the work for making +modifications to it. For an executable file, complete source code means +all the source code for all modules it contains; but, as a special +exception, it need not include source code for modules which are standard +libraries that accompany the operating system on which the executable +file runs, or for standard header files or definitions files that +accompany that operating system. + + 4. You may not copy, modify, sublicense, distribute or transfer the +Program except as expressly provided under this General Public License. +Any attempt otherwise to copy, modify, sublicense, distribute or transfer +the Program is void, and will automatically terminate your rights to use +the Program under this License. However, parties who have received +copies, or rights to use copies, from you under this General Public +License will not have their licenses terminated so long as such parties +remain in full compliance. + + 5. By copying, distributing or modifying the Program (or any work based +on the Program) you indicate your acceptance of this license to do so, +and all its terms and conditions. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the original +licensor to copy, distribute or modify the Program subject to these +terms and conditions. You may not impose any further restrictions on the +recipients' exercise of the rights granted herein. + + 7. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of the license which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +the license, you may choose any version ever published by the Free Software +Foundation. + + 8. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 9. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 10. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + Appendix: How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to humanity, the best way to achieve this is to make it +free software which everyone can redistribute and change under these +terms. + + To do so, attach the following notices to the program. It is safest to +attach them to the start of each source file to most effectively convey +the exclusion of warranty; and each file should have at least the +"copyright" line and a pointer to where the full notice is found. + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) 19yy <name of author> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 1, or (at your option) + any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) 19xx name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the +appropriate parts of the General Public License. Of course, the +commands you use may be called something other than `show w' and `show +c'; they could even be mouse-clicks or menu items--whatever suits your +program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the + program `Gnomovision' (a program to direct compilers to make passes + at assemblers) written by James Hacker. + + <signature of Ty Coon>, 1 April 1989 + Ty Coon, President of Vice + +That's all there is to it! diff --git a/doc/Makefile b/doc/Makefile new file mode 100644 index 0000000..20b82e4 --- /dev/null +++ b/doc/Makefile @@ -0,0 +1,39 @@ +#************************************************************************ +#* IRC - Internet Relay Chat, Makefile +#* Copyright (C) 1990, Jarkko Oikarinen +#* +#* This program is free software; you can redistribute it and/or modify +#* it under the terms of the GNU General Public License as published by +#* the Free Software Foundation; either version 1, or (at your option) +#* any later version. +#* +#* This program is distributed in the hope that it will be useful, +#* but WITHOUT ANY WARRANTY; without even the implied warranty of +#* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +#* GNU General Public License for more details. +#* +#* You should have received a copy of the GNU General Public License +#* along with this program; if not, write to the Free Software +#* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +#* +#* $Id: Makefile,v 1.3 1997/08/08 14:44:13 kalt Exp $ +#* +#*/ + +MANDIR=/usr/local/man + +all: + +sgml: service doc + +doc: INSTALL.sgml + sgml2txt INSTALL.sgml + sgml2info INSTALL.sgml + +service: SERVICE.sgml + sgml2txt SERVICE.sgml + +install: all + -${INSTALL} -c -m 644 ircd.8 ${MANDIR}/man8 + -${INSTALL} -c -m 644 irc.1 ${MANDIR}/man1 + diff --git a/doc/Nets/Europe/CoordEBIC b/doc/Nets/Europe/CoordEBIC new file mode 100644 index 0000000..80ee042 --- /dev/null +++ b/doc/Nets/Europe/CoordEBIC @@ -0,0 +1,86 @@ +############################################################################ +list updated the 8.11.1996 +############################################################################ + + If you like in future to establish a link inside the EBIC area, + please contact the coordinator of the affected toplevel domain. + This coordinator will discuss the link with affected local server + admins and inform other EBIC members about new links. Also a good + idea is to join #EU-Opers and discuss the new link there. + +############################################################################ + These toplevel domains are currently participating EBIC: +############################################################################ + + at be ch zc de dk fi fr hr hu is it nl no pl ru(/su) se si sk uk + +############################################################################ + The following national coordinators have been choosen for '95: +############################################################################ + +*.at EASINET, ACONET + 1. Fingwe, Bernhard Lorenz <Bernhard.Lorenz@wu-wien.ac.at> + +*.be BELNET + 1. Frans Francis Vanhemmens <vanhemme@ulb.ac.be> + 2. mro Marc Roger <Marc.Roger@belnet.be> + +*.ch SWITCH, EUNET/CH + 1. ksa Karim Saouli <Karim.Saouli@span.ch> + +*.cz CESNET, PASNET + 1. Kratz Tomas Kraus <xkraus@sun.felk.cvut.cz> + +*.de WIN, BelWue <irc-oper@leo.org> + 1. YeggMan Volker Paulsen <Volker.Paulsen@gmd.de> + 2. Haegar Thomas Thissen <tici@uni-paderborn.de> + +*.dk DENET, DKNET + 1. karthy Karsten Thygesen <karthy@sunsite.auc.dk> + +*.fi FUNET + 1. Vesa Vesa Ruokonen <Vesa.Ruokonen@lut.fi> + +*.fr EASINET/ROCAD, RENATER <irc-fr@ifens01.insa-lyon.fr> + 1. Nono Arnaud Girsch <Arnaud.Girsch@insa-lyon.fr> + 2. Dumpty Marie-Laure Bruneton <brunetom@poly.polytechnique.fr> + +*.hr CARNET + 1. Mozz Mario Mikocevic <mozgy@smile.srce.hr> + +*.hu HUNGARNET + 1. keksz Revoly Andras <cakes@sch.bme.hu> + +*.is ISnet + 1. ra Richard Allen <ra@rhi.hi.is> + +*.it CILEA <ebic-it@ccii.unipi.it> + 1. Francesco Francesco Messineo <frank@nowhere.ccii.unipi.it> + 2. Coccy Cosimo Riglietti <pez0004@cdc715_3.cdc.polimi.it> + +*.nl SURFNET/NLNET + 1. cor Cor Bosman <cor@xs4all.nl> + 2. Steven Steven Hessing <steven@nijenrode.nl> + +*.no UNINETT + 1. Veggen Vegard Engen <Vegard.Engen@uninett.no> + +*.pl POLIP + 1. Krzysio Krzysztof Mlynarski <krzysio@hydra.mimuw.edu.pl> + +*.ru (*.su) DEMOS + 1. mishania Mikhail Alekseevitch Sokolov <mishania@demos.net> + +*.se SUNET + 1. Ace95 Adam Rappner <ace@LoneStar.rsn.hk-r.se> + +*.sk UAKOM + 1. Koleso Tibor Weis <tibor@uvt.tuzvo.sk> + +*.si + 1. Iztok Iztok Umek <Iztok.Umek@uni-lj.si> + +*.uk JANET, JIPS + 1. jim_bob James R. Grinter <jrg@doc.ic.ac.uk> + + diff --git a/doc/Nets/Europe/IRCNO b/doc/Nets/Europe/IRCNO new file mode 100644 index 0000000..6fafd8d --- /dev/null +++ b/doc/Nets/Europe/IRCNO @@ -0,0 +1,171 @@ + European Board of IRC Coordinators - Norway + +Email: op-no@nvg.unit.no +Versjon: 1.01-001 +Dokument: IRCNO-ORRO 06.07.93 - 03:51 +File: flode.nvg.unit.no:/pub/irc/ircno/english + +-------------------------------------------------------------------------------- + + IRCNO in English. + +IRCNO is the Norwegian name for EBIC - Norway. + +Introduction +~~~~~~~~~~~ +The purpose of IRCNO is to make IRC in Norway as effective as +possible. To achieve this, it has to seperate components, an +administrative and a techincal. + +The administrative component enforces compliance with the IRC rules in +Norway. The purpose of the rules is not to make operators net-police, +but action must nonetheless be taken when rules are not complied with. +Furthermore, we create national statistics on servers and users +connection time. (This info is however only available to the operators). +We also document IRC in Norway, and keep information files updated. +Finally, we give heavy user-support. All documentation, information +files, and user-support files are in the Norwegian language. +The technical component consist mainly of ensuring the proper and +reliable functioning of Norwegian servers and links, so that IRC in +Norway is compatible with the rest of the EBIC IRC Net. + +IRCNO also has its own email adress for any inquiries: op-no@nvg.unit.no + +IRCNO has official support from the Norwegian academic network provider +- UNINETT. + + +IRCNO tasks +~~~~~~~~~~ +Here is a list that defines IRCNO's tasks. + +1) Take care of the Norwegian IRC servers. +2) Enforce the rules for IRC use in Norway. +3) Be responsible toward UNINETT. +4) Make statistics. +5) Document IRC in Norway. +6) User support. + + +Rules of IRC use in Norway +~~~~~~~~~~~~~~~~~~~~~~~~~ +We have 3 kinds of rules, user-bot, operator and server-admin. +Here is a short translation of the rules + +USER-RULES - The following is not allowed: + 1) Fake userids, or trying to hide the real user-id. + 2) Being intentionally offensive to another user. + 3) Dumping a lot of text to a public channel. + 4) Constant beeping on a channel. + 5) Anything that will reduce the techincal functionality of IRC. + 6) Harrasement defined by Norwegian Civil Law. + 7) Using offencive words in channel topics on public channels. + 8) Destroys the integrity of information. + 9) Compromise private communication. + + +BOT-RULES - The following guidelines must be followed: + 1) Bots must not have fake userid unless given permission. + 2) Bots must not send a message to a user not activating it. + 3) Bots must be invisible unless they perform a good "irc-deed". + 4) Bots must only answer to PRIVMSG by using NOTICE. + +Dispensation from some of the bot-rules may be given under certain +circumstances. + + +OPERATOR RULES + This guide gives guidelines on what is not good and what is good. + + Stuff that is not allowed: + - Using SQUIT / CONNECT to gain channel-operator-status. + - Mindless use of KILL. + - Using TRACE to find invisible users. + + Stuff that is allowed: + - Using SQUIT / CONNECT to "fix" the net. This is normally not + allowed and should be used with care. The IRCNO tries to make + efficient use of automatic routing. + - KILL should only be used when a user ask to be killed. KILL can + also be used if it's based in a certain paragraph of the USER + rule file. + + +SERVER RULES + Following is the EBIC-Rules conserning linking. For domestic + linking we have our own rules. + + 1) To get a server connect to the Norwegian IRC-net: + a. New servers must only be leafs. + b. New servers must have one primary- and one secondary link. + c. New servers should only have one active link at a time. + d. The new server must have enough users. + 2) New server connections should be discussed among the existing oper/admins. + 3) Any link should follow the physical net-topology. + 4) A server that is not close to a regional UNINETT net center should not + perform as a HUB server. + 5) Every server in Norway takes part in the national user-staistic. + 6) If hostmasking is to be used, every server behind a mask must be able + to connect to the up-host. + + +ADMIN RULES + 1) An irc-admin must be available by email, unless he/she notifies IRCNO + about any longer planned absence. + 2) A server-admin's duty is to have his/her server perform well for + the end-users and other servers on the irc-net. + 3) An irc-admin must upgrade his/her server and tune it according to + something suitable as soon as a server-release is known to be + relatively stable. + 4) An irc-admin that is not following these rules can loose his/her links + if 100% of IRCNO agrees. + + + +Persons in IRCNO +~~~~~~~~~~~~~~~ +We do not have any leader or jobs, but we do preform certain tasks. +Every decision is taken by discussion and voting. We do not have any +problem with this, and no nasty disagreements occur. This we belive +is because of our Norwegian Nature :-) +Who is Who is documentet in the file called irc-no. Norwegian titles +in paranthesis. + +IRCNO secretary (IRCNO sekret{r) + Keeps track and system of all docs that are produced within IRCNO. + The updating of the various documents is left to the one who has + the administrative job with the document. + +Filearchive (Filarkiv) + Keeps the anonymous FTP archie at flode.nvg.unit.no up-to date. + The archive is also accessible by FSP. The archive consist of + IRCNO docs, IRC docs in general, and IRC software. + This person also administrate the two mailinglists that exist (IRCNO + and a IRC-user list) + +Statistics: (Statistikk) + Does the monthly stats of IRC-use in Norway. + +EBIC contact (EBIC kontakt) + This task is defined in the EBIC-rules. + +Link master (Link ansvarlig) + Job is to find the best links for Norwegian servers, and how they + should connect to each other. In link-matters this person often + has the last word. The link master write a link-report from time + to time (found on the archive as "links"). This report is the only + english document beside this one. This person must have good + knowlege on net-structure in Norway and how the server-linking works. + +UNINETT contact (UNINETT kontakt) + UNINETT want one contact person. This person will likely aslo be + known as the one who is "responsible for IRC in Norway". + + +Other stuff +~~~~~~~~~~~ +For a list of servers and their associated persons, see the file irc-no +under "servere in IRCNO". + +This document is proof-read by Espen Anneling (anneling@uiowa.edu) + diff --git a/doc/Nets/Europe/InfoEBIC b/doc/Nets/Europe/InfoEBIC new file mode 100644 index 0000000..1956910 --- /dev/null +++ b/doc/Nets/Europe/InfoEBIC @@ -0,0 +1,48 @@ +InfoEBIC - General information about European IRC //941115 + +Online information sources in Europe +==================================== +- By IRC +#EU-Opers is an adminstrative channel for European IRC networking. + +- Help automatons in the IRC net (based on ircII help pages) +Help_EU, Help_UK Send PRIVMSG, receive NOTICE +Help_IT Requires DCC Chat + +- By WWW +http://www.funet.fi/~irc/ +http://irc.pages.de/ +http://www.nvg.unit.no/irc/IRCNO-page.html + +Public IRC servers in Europe +============================ +- Open for all domains +irc.funet.fi Finland +irc.Univ-Lyon1.FR France + +- Open for national and some neighbouring domains +irc.cdc.polimi.it Italy +irc.span.ch Switzerland +irc.ludd.luth.se Sweden +irc.nvg.unit.no Norway +irc.sci.kun.nl Netherlands +irc.uni-stuttgart.de Germany +stork.doc.ic.ac.uk United Kingdom + +Anonymous FTP archives with IRC software in Europe +================================================== +ftp.funet.fi:/pub/unix/irc +ftp.informatik.tu-muenchen.de:/pub/comp/networking/irc +hplyot.obspm.fr:/irc +src.doc.ic.ac.uk:/packages/irc + +Mailing list +============ +There is administrative mailing list for european IRC networking. +The list address is irc-eu@ifens01.insa-lyon.fr. This list is run by +an automated mailing-list manager tool, so all requests concerning +the list should be mailed to listserv@ifens01.insa-lyon.fr. To get help, +send "help" in mail message to the listserv address, and you will +get help file in reply. + + diff --git a/doc/Nets/Europe/RulesEBIC b/doc/Nets/Europe/RulesEBIC new file mode 100644 index 0000000..8e693ff --- /dev/null +++ b/doc/Nets/Europe/RulesEBIC @@ -0,0 +1,90 @@ + ######################################################################## + ##### RULES FOR ESTABLISHING NEW IRC SERVERS IN EUROPE (v1.1) ##### + ######################################################################## + + + 1.) Establishing a new server and inner domain linking should be + a local toplevel domain (country) decision. + + Guidelines: + + + New servers should be leafed until their admin(s) + have sufficient experience to handle their server + responsibly. (This avoids routing disasters). + + + Only a link for ONE server should be given to the new + server site, that means the new site shouldn't be able to + connect test-servers to other than its own server. + (This avoids confusion about linking hierarchy). + + + Be sure that if a toplevel domain hostmask link is given, + all hubs of that domain can connect the masked server! + (this should avoid disagreement between serveral hub + admins in one domain). + + + 2.) All other links between toplevel domains (countries) should be + dicussed between the major link coordinators of each toplevel + domain (country). These coordinators are called European Board + of IRC Coordinators (EBIC). + + Guidelines: + + + Major link coordinators of each toplevel domain (country) + should be published with the server sourcecode in + directory ./doc/Europe + + + Each toplevel domain (country) participating in the + European IRC net must have a coordinator, who is + responsible for country-internal connections AND + represents the country in contacts with the rest of the + world. This person(s) is (are) chosen by their domain, + but must be approved by the EBIC. + + + The EBIC is the only executive in charge of European + interconnections and of connections from Europe to the + rest of the world. They will decide linking issues + WITH the affected local admins. + + + For establishing new links between several toplevel + domains the affected EBIC coordinators should be + consulted. If further coordination is needed it should + be discussed within the EBIC. + + + Additional note: International links should also take + care of the network topology, so even if several national + opers agree on a same international link, they might be + wrong and use unecessary network ressources. The EBIC + should avoid such linking. + + + Any major linking change should be announced in the + european mailing list: + IRC-Operators Europe <irc-eu@grasp.insa-lyon.fr> + + + 3.) Cracked servers are the concern of EBIC, overiding all local + interests. + + Guidelines: + + + In a server with non-standard source code which breaks + the current irc protocol (especially the incorrect + manipulation of channel modes and user/hostname authen- + tication) EBIC will take action. + + + The recommended action is permanent withdrawl of the + server from the IRC-net by removal from all its uplinks + configuration files. + + + 4.) A prerequisite for getting a NEW server connection within + Europe is an understanding of and compliance to the above + rules. + + Guideline: + + + All new admins should get a copy of these rules. + + +############################################################################ + diff --git a/doc/Nets/Europe/links.eu b/doc/Nets/Europe/links.eu new file mode 100644 index 0000000..0d77ac7 --- /dev/null +++ b/doc/Nets/Europe/links.eu @@ -0,0 +1,70 @@ +Written by Per Persson <pp@pfawww.pp.se>, last update: 1996-06-18 + +1) Europe should always be a separate net from the other parts of + (what was formerly known as) "EFNet". For example; Netherlands + with leafs and Sweden/Finland (with leafs) should always be + connected to eachother. There are a few times when that wont work + though... NORDUnet might have fuckups from time to time and in + those few cases we have to use more then one link to USA. + +2) Europe "should" be connected this way; + + * irc.nada.kth.se is the primary HUB for northern Europe as well + as some southern European servers (.at). irc.nada.kth.se is + also the primary European HUB for connections to US. + * warszawa.irc.pl is the primary .pl HUB, primary uplink for .pl + is .se with .fi/.at as secondary + (.pl is almost never connected to "EFNet" right now) + * ircd.funet.fi is the primary .fi HUB and irc.cs.hut.fi is the + backup. + * irc.pvv.unit.no is the primary .no HUB and irc.ifi.uio.no is + the backup, primary uplink for .no is .se with .fi as secondary. + * irc.ru is the primary .ru HUB, primary uplink is .fi with .se as + secondary. + * irc.isnet.is's primary uplink is .fi, irc.ludd.luth.se is secondary + * sunsite.auc.dk's primary uplink is irc.nada.kth.se + * irc.ccii.unipi.it is the primary HUB for Italy, primary uplink is + .se with .nl/.uk as secondary. + * irc.felk.cvut.cz is the primary .cz HUB, primary uplink is .se. + * irc.sanet.sk's primary uplink is .cz. + + * irc.nijnerode.nl is the primary HUB for sourthern Europe and .uk. + Primary uplink is irc.ludd.luth.se(irc.nada.kth.se) with .fi as + secondary + * irc.univ-lyon1.fr is the primary .fr HUB and + sil.polytechnique.fr is the backup. primary uplink for .fr is + irc.ludd.luth.se and secondary uplink for .fr is irc.cerf.net. + * stork.doc.ic.ac.uk is the primary .uk HUB and serv.eng.abdn.ac.uk + is the backup. Primary uplink is .nl with .se/.fi as secondary. + (.uk also has a .net server, as well as a netcom.net.uk server which + uses a bit different uplinks--the rest of the .uk servers are + connected to those on occasions as well) + * irc.belnet.be is the primary .be HUB, primary uplink for .be is + .uk with .fr/.nl as secondary. + * irc.wu-wien.ac.at is the primary .at HUB, primary uplink for + .at is .fr with .se as secondary. + * irc.uni-paderborn.de is the primary .de HUB, primary uplink for + .de is .nl with .fi as secondary. + (.de isn't often connected, as they have sloooow links) + * irc.arnes.si's primary uplink is .nl, secondary uplink is .se. + + * The primary link for Europe to USA is; .se - USA + backups are; .fi/.nl - USA + (USA can be one of the following; cs-pub.bu.edu, ircd.stealth.net + eff.org, bazooka.rutgers.edu or irc.cerf.net. irc.cerf.net + is the prefered one nowadays with ircd.stealth.net as secondary) + +3) The ASCII map of all this, to make things "easier to comprehend". + + + (.no .dk .pl .it) __ .se __ .fi __ (.is .ru) + /|\ + .uk __ .nl __/ | \__ .cz __ (.sk) + | | | + (.be) | .fr __ (.at) + | + (.si .ch .de) + + ()'s marks leafs +\ _ /'s marks links + diff --git a/doc/Nets/Europe/rules b/doc/Nets/Europe/rules new file mode 100644 index 0000000..4ad34dc --- /dev/null +++ b/doc/Nets/Europe/rules @@ -0,0 +1,55 @@ +Rules for IRC networking - Ratified July 6th 1994 + +1.) The establishment of new servers and intra-domain linking should + be a local toplevel domain (IE: country) decision. + + Guidelines: + + + Only a link for ONE server should be given to the new + server site, that means the new site shouldn't be able to + connect test-servers to other than its own server. + (This avoids confusion about linking hierachy). + + + If a toplevel domain hostmask link is given, ensure that all + hubs of that domain have connect access to the masked server + (this should avoid disagreements between hub admins within a + domain). + +2.) Hacked or cracked servers (and the machines they run on) are the + concern of all Admins, and override all local interests. + + Guidelines: + + + In a server with non-standard source code which breaks + the current irc protocol (especially the incorrect + manipulation of channel modes and user/hostname authen- + tication) Admins will take action, this includes the + testing of these patches. + + + The recommended action is permanent withdrawl of the + server from the IRC-net by removal from all its uplinks + configuration files. + +3.) The Admins are responsible for all operator access. + IRC Administrators should therefore be approved by the + machine and network admins for the site in question. + +4.) Operator power may be used only on server and network + maintenance purposes. KILL may be used only when other + methods to fix a problem don't exist. + +Infringement of the rules as outlined above should lead to +operator and/or admin changes on the offending server. +Responsibility for these changes is primarily that of the uplink +server administrators. + +In the event of continued transgression, further action may be +taken by remote IRC Administrators 24 hours after the problem +has been identified and all responsible parties have been +notified. + +All intended additions to this document must be announced to IRC +Administrators for at least one week prior to ratification. + +-- +Edited June 29th by #EU-Opers diff --git a/doc/Nets/IRCNet b/doc/Nets/IRCNet new file mode 100644 index 0000000..eaa7396 --- /dev/null +++ b/doc/Nets/IRCNet @@ -0,0 +1,17 @@ +The IRC Net Mailing List + +The IRC Net Mailing List is meant for discussion about issues concerning the +IRC Net network. It is currently an open mailing list and you can subscribe +by typing the following in a shell: + + echo subscribe ircnet | mail majordodo@modeemi.cs.tut.fi + +And to see who is on the mailing list you just need to type the following: + + echo who ircnet | mail majordodo@modeemi.cs.tut.fi + +All messages to the mailing list itself are to be sent to: + + ircnet@modeemi.cs.tut.fi + +http://www.irc.at/bic/ diff --git a/doc/README b/doc/README new file mode 100644 index 0000000..0567db9 --- /dev/null +++ b/doc/README @@ -0,0 +1,40 @@ +# @(#)$Id: README,v 1.5 1999/03/08 17:31:42 kalt Exp $ + +This directory contains the documentation related to this package. + + + +The files relevant to the software compilation and configuration are: + +RELEASE_NOTES - useful information for people upgrading from a previous + version +INSTALL.txt - detailed information about compilation and configuration +example.conf - server configuration example file (useful complement to + INSTALL) + + + +Other files of interest: + +LICENSE - license agreement +ChangeLog - log of source changes +BUGS - list of known bugs +2.10-New - transition documentation from 2.9 to 2.10 version +Etiquette - IRC Etiquette +irc.1 - man page for the client +ircd.8 - man page for the server +iauth.8 - man page for iauth +iauth.conf.5 - man page for the iauth.conf file +Authors - irc contributors +Nets/ - documentation about various IRC networks +Juped/ - old/obsolete documentation files +alt-irc-faq - alt.irc faq +m4macros - note on m4 macros for the server configuration file +2.9-New - old transition documentation from 2.8 to 2.9 version + + + +related documents on the World Wide Web: + + http://www.stealth.net/~kalt/irc/faq.html + http://www.irc.org/~irc/server/ diff --git a/doc/RELEASE_LOG b/doc/RELEASE_LOG new file mode 100644 index 0000000..f3b20c6 --- /dev/null +++ b/doc/RELEASE_LOG @@ -0,0 +1,23 @@ +# @(#)$Id: RELEASE_LOG,v 1.6 1999/08/13 19:53:11 kalt Exp $ + +990813 2.10.3 +990203 2.10.2 +981112 2.10.1 +980927 2.10.0 +980613 2.9.5+IPv6 +980218 2.9.5 +971020 2.9.4 +970724 2.9.3 +961109 2.9.2 +960707 2.9.1 +941203 2.8.21 +940610 2.8.20 +931109 2.8.16 +930914 2.8.14 +930807 2.8.12 +930626 2.8.10 +930405 2.7.2h +920811 2.7.2g +920514 2.7.2 +920114 2.7.1 +910906 2.6.2 diff --git a/doc/RELEASE_NOTES b/doc/RELEASE_NOTES new file mode 100644 index 0000000..ee6b2e3 --- /dev/null +++ b/doc/RELEASE_NOTES @@ -0,0 +1,120 @@ +# @(#)$Id: RELEASE_NOTES,v 1.34 1999/08/13 17:55:01 kalt Exp $ + +This is version 2.10.3 of the IRC software. + +=============================================================================== + +New features in 2.10.3: + * new options for iauth.conf to better control iauth behaviour + * iauth now supports dynamically shared modules. + * socks module now checks for both v4 and v5 of the SOCKS protocol. + * iauth has a new module: LHEx, see ftp://ftp.irc.org/irc/server/LHEx + +Important changes in 2.10.3 (since 2.10.2): + * default PATHs have changed, see INSTALL file and Makefile. + * V line code was fixed, and format slightly changed again. + +------ + +Because of the many changes concerning iauth, it is recommended that this new +version of the iauth program not be used with older version of the IRC daemon. + +=============================================================================== + +Version 2.10.2 of the software adds support for IPv6. + +Important changes in 2.10.2 (since 2.10.1): + * iauth's socks module now uses an internal cache. + * iauth's socks module now checks for SOCKSv4 (rather than v5) proxies. + +=============================================================================== + +2.10 uses a new (server-server) protocol. + +New features in 2.10.0: + + * slave process handles authentication (ident lookups, ..). + * creation of a collision proof type of channels (prefix !). + * opless !channels may be reoped by the server (mode +r). + * added channel mode +e (EFnet's exceptions to bans). + * added channel mode +I (invitations). + * /invite can now be used to override channel bans & limit. + * away status is propagated again. (away messages are not). + * users need +o (or +v) to speak on a channel where they're banned. + +Important configuration changes between 2.9.x and 2.10.x: + + * The V line format has changed! + +------ + +If the irc daemon is unable to bind any socket to listen to for incoming +connections, it will die rather than stay alive. + +=============================================================================== + +New feature in 2.9.5: + * D lines created. + +------ + +2.9.5 is taking steps to suppress the usage of the 2.9 JOIN +format (:nickname JOIN #channel^Gov). Future versions will +not generate such joins anymore. In order to make the +transition smooth, it is imperative that all servers on the +IRC network be upgraded to 2.9.5 when the JOIN syntax is +abandonned. Not doing so will result in a considerable +increase of the amount of bandwidth used during netjoins. + +As a result, MIRC_KLUDGE is now defined by default in config.h + +------ + +2.9.5 can be compiled on a W32 system using the Cygwin32 +library (http://www.cygnus.com/misc/gnu-win32/). + +=============================================================================== + +2.9.4 doesn't support 2.8 links anymore. A 2.8.x server cannot +be directly linked to a 2.9.4 server. They can however coexist +on the same IRC network. + +------ + +Configuration changes between 2.9.3 and 2.9.4: + + * The format for I lines was extended. + * The format for B lines has slightly changed. + * The format for Y lines has changed ([user@]host limits). + * K lines on IP addresses now match resolving hosts by default. + +------ + +As announced with the 2.9.3 release, the NOTE feature has been removed. +A replacement has been written as an independant package, and can be found +at the following location: ftp://ftp.cs.tu-berlin.de/pub/net/irc/noteserv/ + +=============================================================================== + +2.9.3 doesn't support 2.7 protocol anymore. Don't run 2.9.3 +and 2.7 servers on the same IRC network. + +------ + +New features in 2.9.3: + + * compression of server links. + * virtual IP support. + * B lines created. (client redirection) + * k lines created. (OTHER ident) + * V lines created. (restrict peers' compile time options) + * new type of client: services. + +------ + +Important configuration changes between 2.9.2 and 2.9.3: + + * M and P lines format has changed since 2.9.2, it is important + to update your ircd.conf ! + * kill lines are now case sensitive (K: and k: are different) + diff --git a/doc/SERVICE.sgml b/doc/SERVICE.sgml new file mode 100644 index 0000000..ad72843 --- /dev/null +++ b/doc/SERVICE.sgml @@ -0,0 +1,285 @@ +<!doctype linuxdoc system> + +<article> + +<title>IRC Services +<author>Christophe Kalt +<date>$Id: SERVICE.sgml,v 1.6 1999/04/15 21:55:52 kalt Exp $ +<abstract> +The IRC protocol described in RFC 1459 defines two types of +connections (client, and server). A third type was +introduced with version 2.9 of the IRC software: service +connections. This document describes what services are, and +how to use them. +</abstract> + +<sect>A new type of connection +<p> +A service connection is something between a client and a +server connection. It is not closer from any, as a matter +of fact, the scope is pretty broad. +<sect1>A bit client +<p> +services are similar to clients because they cannot: +<itemize> +<item> introduce other clients, services, or servers. +<item> change the global state of the net. (kill, squit..) +</itemize> +<sect1>A bit server +<p> +services are similar to servers because: +<itemize> +<item> they cannot join channels. +<item> they are not limited by flood control or penalty. +<item> they can see all users, servers, services. +<item> they can see all channel names. +<item> they cannot freely connect to a server. +<item> they may optionally receive a connection burst. +</itemize> +<sect1>Really unique +<p> +services are unique because: +<itemize> +<item> they are not subject to collisions. +<item> they can be local to one, or more servers, or global. +<item> they can only send notices, not private messages. +<item> they can only be contacted by the use of SQUERY. +</itemize> +<p> +Services are not meant to be used interactively, but provide +adequate support for automatons, statistic gathering, +monitoring. + +<sect>What users see +<p> +This section covers the aspects visible to the users. +<sect1>&SERVICES +<p> +This is a special channel, similar to &SERVERS, on which +are sent notices when a service connects to or quit the net. +<sect1>SERVLIST +<p> +This new command gives the list of services currently +present on the IRC network. It can take two arguments. +<enum> +<item> a mask to limit the output to the services which +names matches the mask. +<item> a type to list only services of a specific type. +</enum> +It returns a list of servers using numeric 234, the +different fields are: +<itemize> +<item> The service name. +<item> The name of the server which introduced it on the +net. +<item> The <ref id="dist" name="distribution"> mask. +<item> The service <ref id="type" name="type">. +<item> The hop count between you and the service. +<item> A comment. +</itemize> +<sect1>SQUERY +<p> +This new command stands for ``Service Query''. The first +argument is the service name, and the second the text to be +sent to the service. + +<sect>How to set up a service +<sect1>Compile time option for the server +<p> +First of all, it is important to note that in order to be +able to connect a service to a server, this server must have +been compiled with ``<bf>USE_SERVICES</bf>'' defined in the +config.h file. To know if your server has been compiled +with this option, check the version: +<p> +351 Server irc.stealth.net: 2.9.3. AaCeEFiIkMu$_V1 +<p> +351 Server irc.pvv.unit.no: 2.9.3. AaeEFHiKMp<bf>s</bf>tuYZ_V1 +<p> +Here, only ``irc.pvv.unit.no'' was compiled with the +``USE_SERVICES'' defined as the lowercase ``s'' shows in the +version string. +<p> +As they are special clients, services need to be allowed +access to the server in the configuration file. Each +service needs its own access to be setup. This is gone by +adding an S: line to the configuration file. This lines +defines the name of the service, as well as the type. +<sect1>Glossary +<p> +Services have two main characteristics: +<descrip> +<label id="type"> +<tag/Type/ This is a misleading name. The type is actually +a bit mask which defines what information the service can +see. The server configuration file limits the type allowed +for a service. The meaning of the bits is defined in the +service.h file coming with the IRC software: +<verb> +SERVICE_WANT_SERVICE 0x00000001 /* other services signing on/off */ +SERVICE_WANT_OPER 0x00000002 /* operators, included in umodes too */ +SERVICE_WANT_UMODE 0x00000004 /* user modes, iow + local modes */ +SERVICE_WANT_AWAY 0x00000008 /* away isn't propaged anymore.. */ +SERVICE_WANT_KILL 0x00000010 /* KILLs */ +SERVICE_WANT_NICK 0x00000020 /* all NICKs (new user, change) */ +SERVICE_WANT_USER 0x00000040 /* USER signing on */ +SERVICE_WANT_QUIT 0x00000080 /* all QUITs (users signing off) */ +SERVICE_WANT_SERVER 0x00000100 /* servers signing on */ +SERVICE_WANT_WALLOP 0x00000200 /* wallops */ +SERVICE_WANT_SQUIT 0x00000400 /* servers signing off */ +SERVICE_WANT_RQUIT 0x00000800 /* regular user QUITs (these which + are also sent between servers) */ +SERVICE_WANT_MODE 0x00001000 /* channel modes (not +ov) */ +SERVICE_WANT_CHANNEL 0x00002000 /* channel creations/destructions */ +SERVICE_WANT_VCHANNEL 0x00004000 /* channel joins/parts */ +SERVICE_WANT_TOPIC 0x00008000 /* channel topics */ + +SERVICE_WANT_ERRORS 0x01000000 /* &ERRORS */ +SERVICE_WANT_NOTICES 0x02000000 /* &NOTICES */ +SERVICE_WANT_LOCAL 0x04000000 /* &LOCAL */ +SERVICE_WANT_NUMERICS 0x08000000 /* &NUMERICS */ + +SERVICE_WANT_USERLOG 0x10000000 /* FNAME_USERLOG */ +SERVICE_WANT_CONNLOG 0x20000000 /* FNAME_CONNLOG */ +</verb> +<label id="dist"> +<tag/Distribution/ This controls the propagation of the +service. The distribution is checked against server names, +the service will only be on servers which names matches the +distribution. +<p> +It also eventually limits the information received by the +service (depending on the service type). A service will not +have any information concerning users or services connected +to a server which name does not match the distribution. +<p> +Examples: +<descrip> +<tag/irc.funet.fi/Using a server name as distribution makes +the service local to the particular server. +<tag/*.fr/This would match any server in the toplevel ``fr''. +<tag/*/This is the distribution to be used to make the +service global. +</descrip> +<p> +It is important to note that the path between the service +and a server <bf>must</bf> be composed of servers which have +matching names: +<verb> +trondheim.irc.no <----> ircd.funet.fi <-----> oslo.irc.no + ^ ^ + | | + | +------> bergen.irc.no + | + +-------[MyService - Distribution *.no] +</verb> +As shown above, if two ``*.no'' servers have a non ``*.no'' +(for example here a ``*.fi'') server connected between them, +in this case the information related to ``MyService'' will +not propagate to ``oslo.irc.no''. +<p> +This means that the service will see information concerning +the ``3 *.no'' servers, but ``oslo.irc.no'' will have no +knowledge of the presence of ``MyService''. Also, the +service is unable to send anything thru ``ircd.funet.fi''. +</descrip> +<sect1>Signing on as a service +<p> +Once the S: line setup on the server, the service connects +by sending the password (PASS command), and then issuing a +``SERVICE'' command: +<p> +SERVICE servicename servername distribution servicetype 0 :Information +<descrip> +<tag/servicename/ This is the name of the service as configured +by the S line. +<tag/servername/ This is ignored by the server. +<tag/distribution/ This is the distribution mask for this +connection. +<tag/servicetype/ This is the service type as configured by +the S line. (It must match) +<tag/Information/ This is any information. It will be sent +in ``SERVLIST'' replies and should be a short description of +the service. +</descrip> +<p> +A successfull registering of a service at the server will +result in a RPL_YOURESERVICE (383) being sent back to +the service. Any other reply as a result of sending service +indicates an error has occured. +<sect1>Requesting data from the server +<p> +Once the connection is established, the service needs to +issue a ``SERVSET'' command to receive the data it wants: +<p> +SERVSET mask1 mask2 +<descrip> +<tag/mask1/ It is a subset of the service type. It defines +what the kind of information the service wants to receive +for this particular connection. +<p> +This mask can also have the following bits set, regardless +of what the S line setting is: +<verb> +SERVICE_WANT_PREFIX 0x10000 /* to receive n!u@h instead of n */ +SERVICE_WANT_TOKEN 0x20000 /* use server token instead of name */ +SERVICE_WANT_EXTNICK 0x40000 /* user extended NICK syntax */ +</verb> +<tag/mask2/ It is optional. It is a subset of mask1 that +defines which information the service wants to receive in a +``connection burst''. The information is similar to a +server ``connection burst'', it describe the current set of +the network. The service can therefore store the +information in memory and update it. +<tag/Note/The ``SERVSET'' command can only be issued once. +</descrip> + +<sect>General notes for server and service administrators +<sect1>User privacy +<p> +Services can see almost as much information as a server. +This means that granting a service connection should be +considered with as much care as granting a server +connection. In particular, the service type should be +limited to the strict minimum needed for the service to be +operational. In most cases, a service type of 0 is enough. +<p> +A great care should be taken to make sure that a service +cannot be (ab)used to obtain information not normally +accessible to users (such as showing invisible +users). <bf>Administrators must remember that the privacy of +the users is at stake</bf>. +<sect1>Guidelines +<p> +To avoid confusion, it is a good idea to obey the following +simple rules: +<descrip> +<tag/Name/The name should be descriptive, and if possible +unique on the network. +<tag/Information/The service ``information'' should be short +and descriptive. +<tag/Mandatory queries/The service must reply to at least 2 +queries: +<descrip> +<tag/ADMIN/Name and e-mail address of the administrator. +<tag/HELP/List of queries understood by the service. Each +query should also have an help. +</descrip> +<tag/Basic queries/These queries should also be understood +by the service: +<descrip> +<tag/INFO/This should be a short text explaining what the +service and its purpose are. +<tag/VERSION/The version of the running code. +</descrip> +</descrip> +<sect1>Flood control +<p> +Also, since services are not affected by flood control, they +can easily flood the IRC network with information. They +should be conceived so this does not happen. +<p> +Services should implement their own flood control (for +outgoing traffic) to be safe. + +</article> diff --git a/doc/SERVICE.txt b/doc/SERVICE.txt new file mode 100644 index 0000000..fa07c3a --- /dev/null +++ b/doc/SERVICE.txt @@ -0,0 +1,330 @@ + IRC Services + Christophe Kalt + $Id: SERVICE.txt,v 1.7 1999/04/15 21:56:53 kalt Exp $ + + The IRC protocol described in RFC 1459 defines two types of connec- + tions (client, and server). A third type was introduced with version + 2.9 of the IRC software: service connections. This document describes + what services are, and how to use them. + + 11.. AA nneeww ttyyppee ooff ccoonnnneeccttiioonn + + A service connection is something between a client and a server + connection. It is not closer from any, as a matter of fact, the scope + is pretty broad. + + 11..11.. AA bbiitt cclliieenntt + + services are similar to clients because they cannot: + + +o introduce other clients, services, or servers. + + +o change the global state of the net. (kill, squit..) + + 11..22.. AA bbiitt sseerrvveerr + + services are similar to servers because: + + +o they cannot join channels. + + +o they are not limited by flood control or penalty. + + +o they can see all users, servers, services. + + +o they can see all channel names. + + +o they cannot freely connect to a server. + + +o they may optionally receive a connection burst. + + 11..33.. RReeaallllyy uunniiqquuee + + services are unique because: + + +o they are not subject to collisions. + + +o they can be local to one, or more servers, or global. + + +o they can only send notices, not private messages. + + +o they can only be contacted by the use of SQUERY. + + Services are not meant to be used interactively, but provide adequate + support for automatons, statistic gathering, monitoring. + + + 22.. WWhhaatt uusseerrss sseeee + + This section covers the aspects visible to the users. + + 22..11.. &&SSEERRVVIICCEESS + + This is a special channel, similar to &SERVERS, on which are sent + notices when a service connects to or quit the net. + + + + 22..22.. SSEERRVVLLIISSTT + + This new command gives the list of services currently present on the + IRC network. It can take two arguments. + + 1. a mask to limit the output to the services which names matches the + mask. + + 2. a type to list only services of a specific type. + + It returns a list of servers using numeric 234, the different + fields are: + + +o The service name. + + +o The name of the server which introduced it on the net. + + +o The ``distribution'' mask. + + +o The service ``type''. + + +o The hop count between you and the service. + + +o A comment. + + 22..33.. SSQQUUEERRYY + + This new command stands for ``Service Query''. The first argument is + the service name, and the second the text to be sent to the service. + + + 33.. HHooww ttoo sseett uupp aa sseerrvviiccee + + 33..11.. CCoommppiillee ttiimmee ooppttiioonn ffoorr tthhee sseerrvveerr + + First of all, it is important to note that in order to be able to + connect a service to a server, this server must have been compiled + with ``UUSSEE__SSEERRVVIICCEESS'' defined in the config.h file. To know if your + server has been compiled with this option, check the version: + + 351 Server irc.stealth.net: 2.9.3. AaCeEFiIkMu$_V1 + + 351 Server irc.pvv.unit.no: 2.9.3. AaeEFHiKMpsstuYZ_V1 + + Here, only ``irc.pvv.unit.no'' was compiled with the ``USE_SERVICES'' + defined as the lowercase ``s'' shows in the version string. + + As they are special clients, services need to be allowed access to the + server in the configuration file. Each service needs its own access + to be setup. This is gone by adding an S: line to the configuration + file. This lines defines the name of the service, as well as the + type. + + 33..22.. GGlloossssaarryy + + Services have two main characteristics: + + + TTyyppee + This is a misleading name. The type is actually a bit mask + which defines what information the service can see. The server + configuration file limits the type allowed for a service. The + meaning of the bits is defined in the service.h file coming with + the IRC software: + + + SERVICE_WANT_SERVICE 0x00000001 /* other services signing on/off */ + SERVICE_WANT_OPER 0x00000002 /* operators, included in umodes too */ + SERVICE_WANT_UMODE 0x00000004 /* user modes, iow + local modes */ + SERVICE_WANT_AWAY 0x00000008 /* away isn't propaged anymore.. */ + SERVICE_WANT_KILL 0x00000010 /* KILLs */ + SERVICE_WANT_NICK 0x00000020 /* all NICKs (new user, change) */ + SERVICE_WANT_USER 0x00000040 /* USER signing on */ + SERVICE_WANT_QUIT 0x00000080 /* all QUITs (users signing off) */ + SERVICE_WANT_SERVER 0x00000100 /* servers signing on */ + SERVICE_WANT_WALLOP 0x00000200 /* wallops */ + SERVICE_WANT_SQUIT 0x00000400 /* servers signing off */ + SERVICE_WANT_RQUIT 0x00000800 /* regular user QUITs (these which + are also sent between servers) */ + SERVICE_WANT_MODE 0x00001000 /* channel modes (not +ov) */ + SERVICE_WANT_CHANNEL 0x00002000 /* channel creations/destructions */ + SERVICE_WANT_VCHANNEL 0x00004000 /* channel joins/parts */ + SERVICE_WANT_TOPIC 0x00008000 /* channel topics */ + + SERVICE_WANT_ERRORS 0x01000000 /* &ERRORS */ + SERVICE_WANT_NOTICES 0x02000000 /* &NOTICES */ + SERVICE_WANT_LOCAL 0x04000000 /* &LOCAL */ + SERVICE_WANT_NUMERICS 0x08000000 /* &NUMERICS */ + + SERVICE_WANT_USERLOG 0x10000000 /* FNAME_USERLOG */ + SERVICE_WANT_CONNLOG 0x20000000 /* FNAME_CONNLOG */ + + + + DDiissttrriibbuuttiioonn + This controls the propagation of the service. The distribution + is checked against server names, the service will only be on + servers which names matches the distribution. + + It also eventually limits the information received by the + service (depending on the service type). A service will not + have any information concerning users or services connected to a + server which name does not match the distribution. + + Examples: + + iirrcc..ffuunneett..ffii + Using a server name as distribution makes the service local + to the particular server. + + **..ffrr + This would match any server in the toplevel ``fr''. + + ** This is the distribution to be used to make the service + global. + + It is important to note that the path between the service and a + server mmuusstt be composed of servers which have matching names: + + trondheim.irc.no <----> ircd.funet.fi <-----> oslo.irc.no + ^ ^ + | | + | +------> bergen.irc.no + | + +-------[MyService - Distribution *.no] + + + As shown above, if two ``*.no'' servers have a non ``*.no'' (for + example here a ``*.fi'') server connected between them, in this + case the information related to ``MyService'' will not propagate to + ``oslo.irc.no''. + + This means that the service will see information concerning the ``3 + *.no'' servers, but ``oslo.irc.no'' will have no knowledge of the + presence of ``MyService''. Also, the service is unable to send + anything thru ``ircd.funet.fi''. + + 33..33.. SSiiggnniinngg oonn aass aa sseerrvviiccee + + Once the S: line setup on the server, the service connects by sending + the password (PASS command), and then issuing a ``SERVICE'' command: + + SERVICE servicename servername distribution servicetype 0 :Information + + sseerrvviicceennaammee + This is the name of the service as configured by the S line. + + sseerrvveerrnnaammee + This is ignored by the server. + + ddiissttrriibbuuttiioonn + This is the distribution mask for this connection. + + sseerrvviicceettyyppee + This is the service type as configured by the S line. (It must + match) + + IInnffoorrmmaattiioonn + This is any information. It will be sent in ``SERVLIST'' + replies and should be a short description of the service. + + A successfull registering of a service at the server will result in a + RPL_YOURESERVICE (383) being sent back to the service. Any other reply + as a result of sending service indicates an error has occured. + + 33..44.. RReeqquueessttiinngg ddaattaa ffrroomm tthhee sseerrvveerr + + Once the connection is established, the service needs to issue a + ``SERVSET'' command to receive the data it wants: + + SERVSET mask1 mask2 + + mmaasskk11 + It is a subset of the service type. It defines what the kind of + information the service wants to receive for this particular + connection. + + This mask can also have the following bits set, regardless of + what the S line setting is: + + SERVICE_WANT_PREFIX 0x10000 /* to receive n!u@h instead of n */ + SERVICE_WANT_TOKEN 0x20000 /* use server token instead of name */ + SERVICE_WANT_EXTNICK 0x40000 /* user extended NICK syntax */ + + + + mmaasskk22 + It is optional. It is a subset of mask1 that defines which + information the service wants to receive in a ``connection + burst''. The information is similar to a server ``connection + burst'', it describe the current set of the network. The + service can therefore store the information in memory and update + it. + + NNoottee + The ``SERVSET'' command can only be issued once. + + + 44.. GGeenneerraall nnootteess ffoorr sseerrvveerr aanndd sseerrvviiccee aaddmmiinniissttrraattoorrss + + 44..11.. UUsseerr pprriivvaaccyy + + Services can see almost as much information as a server. This means + that granting a service connection should be considered with as much + care as granting a server connection. In particular, the service type + should be limited to the strict minimum needed for the service to be + operational. In most cases, a service type of 0 is enough. + + A great care should be taken to make sure that a service cannot be + (ab)used to obtain information not normally accessible to users (such + as showing invisible users). AAddmmiinniissttrraattoorrss mmuusstt rreemmeemmbbeerr tthhaatt tthhee + pprriivvaaccyy ooff tthhee uusseerrss iiss aatt ssttaakkee. + + 44..22.. GGuuiiddeelliinneess + + To avoid confusion, it is a good idea to obey the following simple + rules: + + NNaammee + The name should be descriptive, and if possible unique on the + network. + + IInnffoorrmmaattiioonn + The service ``information'' should be short and descriptive. + + MMaannddaattoorryy qquueerriieess + The service must reply to at least 2 queries: + + AADDMMIINN + Name and e-mail address of the administrator. + + HHEELLPP + List of queries understood by the service. Each query should + also have an help. + + BBaassiicc qquueerriieess + These queries should also be understood by the service: + + IINNFFOO + This should be a short text explaining what the service and + its purpose are. + + VVEERRSSIIOONN + The version of the running code. + + 44..33.. FFlloooodd ccoonnttrrooll + + Also, since services are not affected by flood control, they can + easily flood the IRC network with information. They should be + conceived so this does not happen. + + Services should implement their own flood control (for outgoing + traffic) to be safe. + + + + + + + + + + + diff --git a/doc/alt-irc-faq b/doc/alt-irc-faq new file mode 100644 index 0000000..3a5bdb5 --- /dev/null +++ b/doc/alt-irc-faq @@ -0,0 +1,293 @@ +(1) What is IRC? + + IRC stands for "Internet Relay Chat". It was originally +written by Jarkko Oikarinen (jto@tolsun.oulu.fi) in 1988. Since starting +in Finland, it has been used in over 60 countries around the world. It +was designed as a replacement for the "talk" program but has become much +much more than that. IRC is a multi-user chat system, where people convene +on "channels" (a virtual place, usually with a topic of conversation) to +talk in groups, or privately. IRC is constantly evolving, so the way +things to work one week may not be the way they work the next. Read the +MOTD (message of the day) every time you use IRC to keep up on any new +happenings or server updates. + + IRC gained international fame during the 1991 Persian Gulf War, +where updates from around the world came accross the wire, and most irc +users who were online at the time gathered on a single channel to hear +these reports. IRC had similar uses during the coup against Boris Yeltsin +in September 1993, where IRC users from Moscow were giving live reports +about the unstable situation there. + +(2) How is IRC set up? + + The user runs a "client" program (usually called 'irc') which +connects to the IRC network via another program called a "server". +Servers exist to pass messages from user to user over the IRC network. + +(3) How do I use a client? + + First, check to see if irc is installed on your system. Type +"irc" from your prompt. If this doesn't work, ask your local systems +people if irc is already installed. This will save you the work of +installing it yourself. + + If an IRC client isn't already on your system, you either +compile the source yourself, have someone else on your machine compile +the source for you, or use the TELNET client. +"telnet ircclient.itc.univie.ac.at 6668". Please only use the latter when +you have no other way of reaching IRC, as this resource is quite +limited, slow, and *very* unreliable. + +(4) Where can I get source for an IRC client? + + You can anonymous ftp to any of the following sites (use the +one closest to you): *** If you don't know what anonymous ftp is, ask +your local systems people to show you *** + +UNIX client-> cs.bu.edu /irc/clients + ftp.acsu.buffalo.edu /pub/irc + ftp.funet.fi /pub/unix/irc + coombs.anu.edu.au /pub/irc + (NB. if there is something related to IRC and it can't + be found under coombs.anu.edu.au:/pub/irc then it isn't + worth having). + ftp.informatik.tu-muenchen.de /pub/comp/networking/irc/clients + slopoke.mlb.semi.harris.com /pub/irc + there is also a client avaliable with the server code. +EMACS elisp-> cs.bu.edu /irc/clients/elisp + ftp.funet.fi /pub/unix/irc/Emacs + ftp.informatik.tu-muenchen.de /pub/comp/networking/irc/clients + slopoke.mlb.semi.harris.com /pub/irc/emacs + cs.hut.fi /pub/irchat +X11 client-> catless.ncl.ac.uk /pub + harbor.ecn.purdue.edu /pub/tcl/code +VMS -> cs.bu.edu /irc/clients/vms + coombs.anu.edu.au /pub/irc/vms + ftp.funet.fi /pub/unix/irc/vms + ftp.informatik.tu-muenchen.de /pub/net/irc +REXX client for VM-> cs.bu.edu /irc/clients/rxirc + ftp.informatik.uni-oldenburg.de /pub/irc/rxirc + ftp.informatik.tu-muenchen.de /pub/net/irc/VM + coombs.anu.edu.au /pub/irc/rxirc + ftp.funet.fi /pub/unix/irc/rxirc +MSDOS-> cs.bu.edu /irc/clients/msdos + ftp.funet.fi /pub/unix/irc/msdos +Macintosh-> cs.bu.edu /irc/clients/macintosh + sumex-aim.stanford.edu /info-mac/comm + ftp.funet.fi /pub/unix/irc/mac + ftp.ira.uka.de /pub/systems/mac + +(5) Which server do I connect to? + + It's usually best to try and connect to one geographically +close, even though that may not be the best. You can always ask when you +get on IRC. Here's a list of servers avaliable for connection: + +USA: + cs-pub.bu.edu + irc.colorado.edu + irc-2.mit.edu + +Canada: + ug.cs.dal.ca + +Europe: + irc.funet.fi + cismhp.univ-lyon1.fr + disuns2.epfl.ch + irc.nada.kth.se + sokrates.informatik.uni-kl.de + bim.itc.univie.ac.at + +Australia: + jello.qabc.uq.oz.au + + +This is, by no means, a comprehensive list, but merely a start. Connect +to the closest of these servers and join the channel #Twilight_Zone +When you get there, immediately ask what you want. Don't say "I have a +question" because then hardly anyone will talk. + +(6) OK, I've got a client and I'm connected to a server, now what? + + It's probably best to take a look around and see what you want +to do first. All IRC commands start with a "/", and most are one word. +Typing /help will get you help information. /names will get you a list +of names, etc. + +The output of /names is typically something like this-> + +Pub: #hack zorgo eiji Patrick fup htoaster +Pub: #Nippon @jircc @miyu_d +Pub: #nicole MountainD +Pub: #hottub omar liron beer Deadog moh pfloyd Dode greywolf SAMANTHA + +(Note there are LOTS more channels than this, this is just sample +output -- one way to stop /names from being too large is doing /names +-min 20 which will only list channels with 20 or more people on it, +but you can only do this with the ircII client). + +"Pub" means public (or "visible") channel. "hack" is the channel name. +"#" is the prefix. A "@" before someone's nickname indicates he/she is the +"Channel operator" (see #7) of that channel. A Channel Operator is someone +who has control over a specific channel. It can be shared or not as the +first Channel Operator sees fit. The first person to join the channel +automatically receives Channel Operator status, and can share it with +anyone he/she chooses (or not). Another thing you might see is "Prv" +which means private. You will only see this if you are on that private +channel. No one can see Private channels except those who are on that +particular private channel. + +(7) What is a channel operator? What is an IRC operator? + + A channel operator is someone with a "@" by their nickname in +a /names list, or a "@" by the channel name in /whois output. Channel +operators are kings/queens of their channel. This means they can kick +you out of their channel for no reason. If you don't like this, you +can start your own channel and become a channel operator there. + + An IRC operator is someone who maintains the IRC network. They +cannot fix channel problems. They cannot kick someone out of a channel +for you. They cannot /kill (kick someone out of IRC temporarily) +someone just because you gave the offender channel operator privileges +and said offender kicked *you* off. + +(8) What is a "bot"? + + "bot" is short for "robot". It is a script run from an ircII +client or a separate program (in perl, C, and sometimes more obscure +languages). StarOwl@uiuc.edu (Michael Adams) defined bots very well: "A +bot is a vile creation of /lusers to make up for lack of penis length". +IRC bots are generally not needed. See (10) below about "ownership" of +nicknames and channels. + + It should be noted that many servers (especially in the USA) have +started to ban ALL bots. Some ban bots so much that if you run a bot on +their server, you will be banned from using that server (see segment below +on K: lines). + +(9) What are good channels to try while using IRC? + + #hottub and #initgame are almost always teeming with people. +#hottub is meant to simulate a hot tub, and #initgame is a non-stop game +of "inits" (initials). Just join and find out! + + To get a list of channels with their names and topics, do +/list -min 20 (on ircII) which will show you channels with 20 or more +members. You can also do this for smaller numbers. + + Many IRC operators are in #Twilight_Zone ... so if you join +that channel be prepared for a lot of senseless dribble, more like what +you find on the other channels listed above (#hottub). What was once a +place of people who could help you has turned into just another place +for those who have nothing better to do with themselves than just be +there. If you find other documents saying go there to ask questions, +ignore them. They should be considered to be out of date. + +(10) Someone is using my nickname, can anyone do anything about it? + Someone is using my channel, can anyone do anything about it? + + There are not enough nicknames to have nickname ownership. If +someone takes your nickname while you are not on IRC, you can ask for +them to give it back, but you can not *demand* it, nor will IRC operators +/kill for nickname ownership. If you goto #Twilight_zone, you will find +a bunch of people who will refuse to do this for you, yet they will do it +for themselves or their friends or use /kill for even less reasonable uses. + + There are, literally, millions of possible channel names, so if +someone is on your usual channel, just go to another. You can /msg them +and ask for them to leave, but you can't *force* them to leave. + +(11) There aren't any channel operators on my channel, now what? + + Channel operators are the owner(s) of their respective channels. +Keep this in mind when giving out channel operator powers (make sure to +give them to enough people so that all of the channel operators don't +unexpectedly leave and the channel is stuck without a channel operator). + + On the other hand, do not give out channel operator to +*everyone*. This causes the possibility of mass-kicking, where the +channel would be stuck without any channel operators. + + You have one option. You can ask everyone to leave and rejoin +the channel. This is a good way to get channel operator back. It +doesn't work on large channels or ones with bots, for obvious reasons. + +(12) What if someone tells me to type something cryptic? + + Never type anything anyone tells you to without knowing what it +is. There is a problem with typing certain commands with the ircII +client that give anyone immediate control of your client (and thus can +gain access to your account). + +(13) What does "*** Ghosts are not allowed on IRC." mean? + + On IRC, you cannot be banned from every single server. +Server-banning exists only on a per-server basis (being banned on one +server does not mean you are automatically banned from another). "Ghosts +are not allowed on IRC" means that you are banned from using that server. +The banning is in one of three forms: + + * You are banned specifically, you yourself. Only you can be responsible + for this (if you are using a shared account, this obviously does not + apply). Thus the responsibility lies completely with you and you have + noone to complain to. + + * Your machine is banned. Chances are it wasn't you who committed the + wrongdoing. Try using another machine on campus and seeing if you can + use that particular irc server then. + + * Your whole site is banned (where "site" == "school", "company", + "country"). This almost certainly wasn't your fault. And chances are + you won't be able to get the server-ban lifted. Try using another + server. + + The most general answer is "use another server", but if it bothers +you, try writing to the irc administrator of that site --> +/admin server.name.here -- plead your case. It might even get somewhere! + +(14) Where can I find GIF archives of IRC people? + + GIF archives of IRC people are available: + + ftp.funet.fi:/pub/pics/people/misc/irc (NORDUnet only) + ftp.informatik.tu-muenchen.de /pub/comp/networking/irc/RP + +(15) Where can I learn more? + + The best, basic, IRC user's manual is the IRC Primer, +available in plain text, PostScript, and LaTeX from +cs-pub.bu.edu:/irc/support ... Another good place to start might be +downloading the IRC tutorials. They're avaliable via anonymous ftp +from cs-pub.bu.edu in /irc/support/tutorial.* + + You can also join various IRC related mailing lists: + + * "operlist" is a list that discusses current (and past) server code, + routing, and protocol. *WARNING* this mailling list has a *LOT* of + flame traffic from those who think they know everything but in reality + have no better idea than you. You can join by mailing + operlist-request@kei.com. + + * "irchat" is an elisp client. You can join the irchat mailing list by + mailing irchat-request@cc.tut.fi. + + * "ircd-three" is a list that exists to discuss protocol revisions + for the 3.0 release of the ircd (irc server), currently in + planning. Mail ircd-three-request@kei.com to be added. + + * "vmsirc" is a list for the questions, problems, and discussions + related to the vms IRC clients. Mail vmsirc-request@vax1.elon.edu + (with "subscribe" in the message body). + +NOTE! These are not "Help me, where can I get started?" lists. For +that information, read the IRCprimer noted above. + + Those looking for more technical information can get the IRC +RFC (rfc1459) available at all RFC ftp sites, as well as +cs-pub.bu.edu:/irc/support/rfc1459.txt + +(16) What do I do if I'm still confused or have additions to this document? + + email hrose@kei.com or avalon@coombs.anu.edu.au + diff --git a/doc/example.conf b/doc/example.conf new file mode 100644 index 0000000..afcc9c2 --- /dev/null +++ b/doc/example.conf @@ -0,0 +1,531 @@ +# IRC - Internet Relay Chat, doc/example.conf +# Copyright (C) 1994, Helen Rose +# +# $Id: example.conf,v 1.11 1999/07/14 16:17:23 kalt Exp $ +# +# some changes for 295 and cleaning, delta, Sat Jun 13 01:09:25 MES 1998 +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 1, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +# +# This is an example configuration file for the IRC server. +# It's highly suggested that you also read INSTALL.* in doc/ and talk with +# your uplinks if linking to an already existent IRC network. +# +# You only need an ircd.conf (IRC server configuration file) if you are +# running an IRC server. If you are running a standalone client this file +# is not necessary. +# +# This file will explain the various lines in the IRC server +# configuration file. Not all lines are mandatory. You can check to make +# sure that your configuration file is correct by using the program +# "chkconf", provided in the server distribution (and when you do "make +# install" this program will be installed in the same directory as the irc +# server). +# +# The options for whether a line is needed or not are: +# MANDATORY: you absolutely MUST have this line +# NETWORKED: you must have this line if you are connecting this irc +# server to any other server (servers can run standalone). +# SUGGESTED: it is HIGHLY suggested that you use this line +# OPTIONAL: it's completely up to you whether to define this or not +# DISCOURAGED: you really really should not use this line if at all +# possible. +# NOT NECESSARY: an old or out of date line that isn't needed. +# +# +# ======================================================================== +# NOTE! this entire configuration file is read UPSIDE-DOWN! So if you have +# to put something in a specific order (for example, client-connection +# lines), put them in reverse order! +# ======================================================================== +# +# +############################ +# M: [MANDATORY]. This line sets your server's name, description and port +# the server listens for UDP pings (used to determine the fastest link in a +# class when autoconnecting) +# +# M:<Server NAME>:<YOUR Internet IP#>:<Geographic Location>:<Port> +# +# Note that 'server name' refers to the name of the irc-server which needs +# not to be the same as the hostname of the machine it's running on. +# +# this let's ircd use the primary ip of your host to establish connections +M:csa.bu.edu::Boston University Computer Science Department:6667 +# +# this let's ircd use the ip 128.197.13.20 to establish connections, useful +# if you're running virtual interfaces +#M:csa.bu.edu:128.197.13.20:Boston University Computer Science Department:6667 +# +# +############################ +# A: [MANDATORY]. This line lists your administrative information +# (contact address, etc). To view this information, /admin (server) will +# show it to you. +# +# A:<Your Name/Location>:<Your Electronic Mailing Addr>:<other information>:: +# +A:Boston University CS Department:Helen Rose <hrose@cs.bu.edu>:Client Server:: +# +# +############################ +# P: [MANDATORY]. This field allows the server to listen on various ports +# for connections. Any internet domain port that is below 1024 means the +# ircd has to be run as root, or from inetd. The server can listen to ports +# in the UNIX domain or the internet domain. If you wish to create a port +# in the UNIX domain you must compile with UNIXPORT defined in config.h. +# +# P:<YOUR Internet IP#>:<*>:<Internet IP Mask>:<Port>: +# P:<Directory>:<*>:<*>:<Port>: +# +# Note that it's a good idea to open some more ports than 6667 for +# server-server connections and local clients in case some running wild +# client blocks the default 6667. +# +# the default, an internet domain socket on port 6667 listening on all +# ip addresses of the machine running ircd +P::::6667: +# +# an internet domain socket listening on port 6668 on address 206.252.192.20 +# (again useful if you're running virtual interfaces) +P:206.252.192.20:::6668: +# +# an internet domain socket listening on port 6669 for connections from +# addresses matching 147.210.18.* : +P:::147.210.18.*:6669: +# +# This line is an example of a UNIX domain socket in /tmp +P:/tmp/.ircd:*:*:6666: +# +# +############################ +# Y: [SUGGESTED]. These lines define connection classes. Connection +# classes allow you to fine-tune your client and server connections. +# Since the fields have different meanings for server and client classes +# you shouldn't mix them, and if you have lots of server connections (if +# you do have lots of servers you shouldn't be reading this file :-) each +# set of servers (defined arbitrarily by you) should have its own class. +# If you have clients coming in from lots of different sites, you may want +# to seperate them out into classes. For instance, you may want to put +# local users in one class, with remote users in another class. You may also +# want to put limits on some client classes (one client only for indials +# for example). In any larger network you definitely want to do this. +# +# For SERVER CLASSES, the fields are: +# Y:<Class>:<Ping Frequency>:<Connect freq>:<Max Links>:<SendQ>:: +# 1 2 3 4 5 67 +# 1 class number +# 2 ping frequency (in seconds) +# 3 connect frequency (in seconds) +# 4 maximum number of automatically initiated links in this class +# 5 sendq (this overrides any MAXSENDQLENGTH set in config.h) +# 6 unused for server classes +# 7 unused for server classes +# +# The class numbers are not arbitrary. In auto-connecting servers -- that is, +# servers that you have a port number (e.g. 6667) on the end of the C: line +# (see below) the higher the number the higher the priority in auto-connecting. +# +# Note that it is a good idea to have ping frequency the same at both ends +# of the link. +# +# this is a normal server connection (normal as of October, 1997) +# Y:<Class>:<Ping Frequencys>:<Connect freq>:<Max Links>:<SendQ>:: +Y:2:90:300:1:4000000 +# +# +# For CLIENT CLASSES, the fields are: +# Y:<Class>:<Ping Frequency>::<Max Links>:<SendQ>:<Local Limit>:<Global Limit> +# 1 2 3 4 5 6 7 +# 1 class number +# 2 ping frequency (in seconds) +# 3 unused for client classes +# 4 maximum number of links in this class (per I line) +# 5 sendQ for each client +# 6 maximum number of links from this [user@]host on the server +# 7 maximum number of links from this [user@]host on the net +# +# local and global limits have the format <x>.<y> where x defines the maximum +# number of clients from the same host (IP) whereas y defines the maximum +# number of clients from the same user@host (IP) allowed to connect. the +# latter uses the identd replies to identify a user, falling back to an +# @host limit if no identd runs on the client and fails for identds generating +# dynamical answers. +# +# Note that any unset values default to zero which means 'unlimited'. +# +# Y:<Class>:<Ping Frequency>::<Max Links>:<SendQ>:<Local Limit>:<Global Limit> +# this is a class for multiuser systems allowing 10 local clients per host +Y:10:90::100:512000:10:32 +# +# this is a class for multiuser systems running a trustworthy identd +Y:11:90::100:512000:0.1:0.2 +# +# this is a class for single user systems (PCs, most indials, ...) +Y:12:90::100:512000:1:3 +# +# this is a class for remote systems you want to allow as fallback only +# (if you run an open server in a net you might really want this) +Y:13:90::100:512000:1:1 +# +# +############################ +# i/I: [MANDATORY]. The I: lines are client-authorization lines. Without +# these lines, no clients will be able to connect to your server. +# Wildcards ("*") are permitted. Passwords are also possible (clients can +# be configured to send passwords) but optional. 'I' allows full access, +# 'i' sets restricted mode which forbids nick changes and channel op status. +# +# I:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> +# i:<TARGET Host Addr>:<Password>:<TARGET Hosts NAME>:<Port>:<Class> +# +# NOTE that ircd matches on the *right-most* match and doesn't stop matching +# after the <TARGET Hosts NAME> didn't match (see also examples below). +# +# Not that if <TARGET Hosts NAME> is empty ircd will show clients matching +# the <TARGET Host Addr> and do resolve as user@host. if an I:-line has both +# NAME and Addr defined and a client matches only the Addr part it will be +# shown as user@ip-address regardless if it does resolv or not. +# +# this would allow access for any client reaching this line which doesn't +# already have at least one connection to the net. if you run an open server +# in a net this might be the right choice, talk to your uplinks first anyway. +# resolving clients matching this line would be shown as user@host since +# the field <TARGET Hosts NAME> is empty. +# Note listing this i: line first, it will be read *last*, meaning it is +# the "fall-through". +#i:*@*::::13 +# With the password 'foobar' +#i:*@*:foobar:::13 +# Note that I:*::*.bu.edu:10 would also allow _all_ clients regardless +# if they're from *.bu.edu or not since ircd doesn't stop matching after the +# <TARGET Hosts NAME> didn't match. +# +# this would allow access for any client coming from *.net, *.org, *.com or +# other 3 char TLD +#i:::*@*.???:13 +# +# this allows access for any client from the ip block 192.168.0.0/16 +# regardless of its domain. if it's resolvable it will be shown as +# user@host since the field <TARGET Hosts NAME> is empty (useful to +# allow whole provider's blocks). +I:*@192.168.*::::12 +# +# This is a standard vanilla I: line which will permit anyone with an IP +# address starting with 128.197 OR with a hostname ending in .bu.edu to +# connect to the server. NOTE, the ircd matches on the *right-most* match, +# so if I connect as hrose@csa.bu.edu (which is hrose@128.197.10.3) I will +# show up on irc as hrose@csa.bu.edu since that is the first match it +# found. (Even though the second match is valid). +I:*@128.197.*::*@*.bu.edu::10 +# +# and you can even specify just certain usernames as long as the client's +# site is running a trustworthy ident daemon: +I:::hrose@csa.bu.edu::10 +# +# this will limit access for indials to one client per host +I:::*@ppp*.bu.edu::12 +I:::*@indial*.bu.edu::12 +# +# +############################ +# O: [OPTIONAL]. These lines define operator access. You do not need to +# have an operator to run a server. A well configured leaf site should not +# need an operator online, if it's connections are well defined, the irc +# administrator can use 'kill -HUP' on the ircd to reload the configuration +# file. +# +# O:<TARGET Host NAME>:<Password>:<Nickname>:<Port>:<Class> +# +# If the person in "Nickname" is not coming from the hostname defined in +# the first field then the person will get the error message "No O: lines +# for your host". +# +# Note that you don't need to use 'Nickname' to become operator, if you're +# using some other nick at that moment '/op Nickname' will do also. +# +O:*.bu.edu:Zaphod:Trillian::10 +# +# and this line forces ident match: +O:hrose@csa.bu.edu:Zaphod:Trillian::10 +# +# This line is a "local operator", it is specified with a lower-case "o" +# +# this line permits the nickname "jhs" with the password of "ITBites" to +# be a local operator only (be able to issue commands locally -- can /kill +# and /squit and /connect -- but *only* locally) +# +o:*.bu.edu:ITBites:jhs::10 +# +# a crypted password line (NOTE that if you have crypted passwords, *all* +# of you passwords must be crypted! In fact, if you are getting an error +# "Incorrect Password" it may well be because crypted passwords are +# defined and you have used plaintext. So my example of plaintext and +# crypted strings in the same IRC server configuration file is an +# impossibility (but it is just theoretical, which is why I explained both). +# +O:rocker@csa.bu.edu:T0eiVgHrqeKTQ:Rocker::10 +# +# +############################ +# c/C: [NETWORKED]. These lines define what servers your server tries to +# connect to. 'c' means your server will support compression for this link +# if you've compiled with zlib, 'C' will enforce an uncompressed link. +# N: [NETWORKED]. These lines define what servers your server permits +# to connect. +# +# c/N lines MUST be used in pairs. You cannot have one without the other. +# +# C:<TARGET Host Addr>:<Password>:<TARGET Server NAME>:<TARGET PORT>:<Class> +# c:<TARGET Host Addr>:<Password>:<TARGET Server NAME>:<TARGET PORT>:<Class> +# +# if the target server listens on different ports you can use for <TARGET PORT> +# <port_to_connect_to>.<port_target_server_listens_for_udp_pings>. +# <TARGET Host Addr> can be also an ip address or CNAME. +# +# N:<TARGET Host Addr>:<Password>:<TARGET Server NAME>:<Domain Mask>:<Class> +# +# "domain mask" is the number of parts in *your* hostname to mask to. For +# instance, with my servername being "csa.bu.edu", if I wanted to present +# my servername to be "*.bu.edu" I would have a host-mask portion of "1". +# +# it is *strongly* advised that your c/N line passwords be different for +# security's sake. +# +# ident is allowed in the server's hostname part of the field. +# these lines tell the server to automatically (note the port number, that +# means automatic connection) connect to cs-ftp.bu.edu: +C:hrose@cs-ftp.bu.edu:bigspark:cs-ftp.bu.edu:6667:2 +N:hrose@cs-ftp.bu.edu:bigalpha:cs-ftp.bu.edu::2 +# +# This server's connection lines are more vanilla, masking the host to +# *.bu.edu (as described above): +C:irc-2.mit.edu:camelsrk00l:irc-2.mit.edu::2 +N:irc-2.mit.edu:andsoarellamas:irc-2.mit.edu:1:2 +# +# If you have defined ZIP_LINKS and wish the connection to irc-2.mit.edu to +# be compressed, you need to use a lowercase c. If the other server refuses +# or doesn't support compression it will fall back to an uncompressed link. +c:irc-2.mit.edu:camelsrk00l:irc-2.mit.edu::2 +N:irc-2.mit.edu:andsoarellamas:irc-2.mit.edu:1:2 +# +# +############################ +# K: [OPTIONAL]. These lines define user@host patterns to be banned from +# this particular server (with an optional time field). Note that K: lines +# are *not* global, and if you ban a user they can still use any other IRC +# server (unless they have specifically been banned there as well). +# 'K' uses the the type unix reply from the client's identd if available or +# the USER information supplied by the client if not. 'k' uses the reply from +# the client's identd also if it's type other (it's prefixed with '-' then). +# +# K:<Host Name or IP>:<time interval(s)|comment>:<User>:<port>: +# k:<Host Name or IP>:<time interval(s)|comment>:<Auth>:<port>: +# +# wildcards are permitted in any one of the fields, in other words, you can +# K:*::* if you wanted (but your server wouldn't be used much ;-) +# +# Note that if you specify an IP address, or IP mask, it will match clients +# connecting from the matching addresses, no matter if they resolve or not. +# You can prefix an IP address or IP mask by '=' in which case only non +# resolving matching hosts will be banned. +# +# This k: line bans the username "FSSPR" (the wildcard is used to make +# sure that any ident-checking character will match) on any machine from +# the University of Alaska. +k:*.alaska.edu::*FSSPR:0 +# +# This K: line bans any users from acs*.bu.edu between the hours of 8am +# and 12pm and 1pm and 5pm (the time is always the server's local time): +# Note that 24 hour time is used (no "AM" or "PM"). +K:acs*.bu.edu:0800-1200,1300-1700:*:0 +# +# This K: line bans any users from *foo.edu sending them the notice +# "Use server irc.bar" instead of the default notice +# "You are not welcome to this server" +K:*foo.edu:Use server irc.bar:*:0 +# +# This K: line bans any users from *toto.fr from using the port 6667, +# and tells them to use port 6666 instead. +K:*toto.fr:Use port 6666:*:6667: +# +# This K: line bans any user from 129.69.0.0/16 as long the host doesn't run +# identd (no matter if it replies type unix or other) from all ports. +k:129.69.*:identd (rfc1413) required:unknown:: +# +# This does the same but only for unresolvable clients +k:=129.69.*:identd (rfc1413) required:unknown:: +# +# +############################ +# L: [OPTIONAL]. These lines "Leaf" specified servers. They are only +# useful if you are a non-leaf site yourself. There are two ways you can +# use L: lines. The first will limit one particular site to a particular +# tree depth (including 0, which would mean the server has to connect with +# no servers linked behind it otherwise the connection will fail). The +# second will allow you to be selective about which other servers you wish +# the connecting server to behave as a leaf towards. +# +# The fields are as follows: +# L:disallow connections to this hostmask::server name:depth +# For example, this will force kaja.gi.alaska.edu to connect only as a +# leaf (if it is not a leaf, the link will be dropped): +L:::kaja.gi.alaska.edu:: +# This line will force cm5.eng.umd.edu to have a depth of only 1 below it +# (that is, it is allowed to have only leaves connected to it): +L:::cm5.eng.umd.edu:1: +# +# This line will prohibit anything matching *.edu to be connected behind +# any server matching *.au: +L:*.edu::*.au:: +# +# +############################ +# H: [OPTIONAL]. These lines define who you permit to act as a "hub" to +# you (that is, who you permit to connect non-leafed servers to you). +# +# the first field may use wildcards, the third field *must* be an exact +# match for a server's name (NOT a server's hostname, if they differ, the +# server's name must be used). If the servername is a wildcard (e.g. *.au) +# that is an acceptable name for the third field. +# +# The fields are as follows: +# H:servers which are permitted entry::hub server +# +# Example, permit cs-ftp.bu.edu to allow any servers behind it to connect: +H:*::cs-ftp.bu.edu:: +# +# Example, permit irc-2.mit.edu to allow any MIT servers behind it to +# connect: +H:*.mit.edu::irc-2.mit.edu:: +# +# +############################ +# D: [OPTIONAL]. Control how auto connections are done. This will be mostly +# useful for networks with complex configurations. +# +# D:<Denied Server Mask>:<Denied Class>:<Server Mask>:<Server Class>: +# 1 2 3 4 +# +# If a server matching <Denied Server Mask> or a server in <Denied Class> +# is present ircd won't auto connect to any server matching <Server Mask> +# or being in <Server Class> although auto connect for those is active. +# +# Example, don't auto connect to *.fi if some server of *.edu is already +# linked +D:*.edu::*.fi:: +# +# Example, don't auto connect to *.fi or any server in class '3' if a +# server from our class '2' is already present +D::2:*.fi:3: +# +# +############################ +# V: [OPTIONAL]. These lines define restrictions on servers connecting to +# you. +# +# The first and third fields accept wildcards. The fields are as follow: +# V:<Version Mask>:<Flags>:<Server Mask>:: +# +# Example, you believe 2.9.1 is a really old version, and you want your +# peers to upgrade: +V:020901*::*:: +# +# If you are running a production network, you most likely don't want to +# allow servers compiled in DEBUGMODE which is a threat for the net +# as well as for the privacy of the users: +V:*:D:*:: +# +# Finally, you don't want *.edu servers to be version 2.9.2 *OR* to be +# compiled with remote oper kills enabled: +V:020902*:K:*.edu:: +# +# +############################ +# B: [SUGGESTED]. These lines define the alternate servers that the users +# will be redirected to if your server is full. +# +# The fiels are as follow: +# B:<Class|Host Mask>::<Server Name>:<Port>: +# +# For example, if you want to redirect your users to irc.stealth.net on port +# 6667 when your server is full, use: +B:-1::irc.stealth.net:6667: +# +# To redirect *.fi users when your server cannot accept any new user with +# a hostname matching *.fi, use: +B:*.fi::irc.funet.fi:6667: +# +# +############################ +# S: [OPTIONAL]. These lines define services allowed to connect to your +# server. Each service needs a separate line which only allows him to +# connect once. Remember to compile the ircd with #define USE_SERVICES +# in config.h, otherwise you can't use services. +# +# The fields are as follow: +# S:<TARGET Host Mask>:<Password>:<Service Name>:<Service Type>:<Class> +# +# Example, you want to allow a local information service: +S:eep.local.net:thisisapassword:EepInfo:0:1 +# +# Another example, ircd versions since 04/10/1999 support also a hex +# mask. This is a temporary kline service (tkserv) as you can find it in +# contrib/tkserv : +S:eep.local.net:thisisapassword:TkEep:0x2000000:1 +# +# +############################ +# U: [NOT NECESSARY]. This line defines the default server for the IRC +# client that ships with the server -- the default client is in irc/irc +# You should not use U: lines but instead use the UPHOST definition in +# config.h +U:csa.bu.edu:foobar:csa.bu.edu +# +# +############################ +# R: [DISCOURAGED]. These lines restrict user access based on a more +# stringent checking system than is available in the K: line. It looks for +# a match (based on hostname and username) and then runs an outside +# program (which MUST be specified using a full pathname). The output of +# the program should be a string in the form "Y <message>" (which permits +# access for the user) or "N <message>" (which denies access for the +# user). If "Y <message>" is received by the server, the server ignores +# the message and permits access for the user. If "N <message>" is +# returned, the server tells the user that he/she is not permitted to +# access that irc server, and gives the reason. +# +# Again, like K: lines, R: lines are local and thus not very effective in +# blocking certain machines from having IRC access. +# +# Use of R: requires that you have defined R_LINES in config.h +# +# The fields are as follows: +# R:hostmask:/full/path/to/program:username +# you can use wildcards in either the hostmask or username portion +# +R:csl.bu.edu:/home/hrose/bin.sun3/sun3access:*:: +# +# +############################ +# Q: [DISCOURAGED]. These lines "quarantine" specified servers. Because +# of the way they operates, the same Q: lines MUST be installed by +# everyone or the net will keep breaking. I CANNOT EMPHASIZE THIS ENOUGH. +# Do NOT use Q: lines lightly! +# +# The fields are as follows: +# Q:*:reason why quarantine is in place:servername +# +Q::this server is too slow and lags the net:cm5.eng.umd.edu:: diff --git a/doc/iauth-internals.txt b/doc/iauth-internals.txt new file mode 100644 index 0000000..ccfa8e8 --- /dev/null +++ b/doc/iauth-internals.txt @@ -0,0 +1,350 @@ + Internal IAUTH Workings + ======================= + + Andrew Snare + +Introduction +------------ + +The iauth daemon was written to offload some aspects of authenticating +incoming ircd connections. Using a modular design, the original +modules provides for identd lookup of incoming connections as well as +checking for open socks proxies. + +When the ircd starts up, the iauth process is started as a slave +process. The ircd communicates with the iauth daemon about new +connections, and the iauth slave communicates information back as it +becomes available. + +Communication Protocol +---------------------- + +IRCD Messages:- + +The communication protocol used to communicate from ircd to iauth is +line-based and has the following form: + + <id> <category> <information> + + * <id> is used to identify the connection the information + concerns, and consists of the ircd's file-descriptor for the + connection. + + * <category> is a single letter used to denote the type of + information being sent. + + * <information> is the rest of the line ("\n"-terminated), + whose format depends on the category of information. + +Categories: + + - "C" + + Denotes a new connection to start on. The information has the + form of <remote-ip> <remote-port> <local-ip> <local-port>. Eg: + + 2 C 192.168.2.10 13578 192.168.1.1 6667 + + This indicates a connection has been received on port 6667 + with local IP-address of 192.167.1.1. The remote IP-address + was 192.168.2.10 (port 13578). + + - "O" + + Denotes an update to information about an existing + connection. The format of this is identical to a C-message (as + described above). + + - "D" + + Denotes a client has disconnected. No extra information is + provided. Eg: + + 2 D + + - "R" + + This denotes a change of identifier for a client. The reason + for this currently is that sometimes ircd can re-map + file-descriptors (used as the identifier). The format of the + information is <new identifier>. Eg: + + 2 R 1 + + This indicates the client that was on file-descriptor 2 is now + on file-descriptor 1 (unlikely, I'm sure!:). + + - "N" + + This denotes information has been received about the hostname + of a client. Format of the information is <hostname>. Eg: + + 2 N host.example.com + + This indicates the hostname of that client is + host.example.com. + + - "d" + + This denotes a DNS lookup for the client has timed out or + failed. This message has no other information. Eg: + + 2 d + + - "A" * + + This denotes a host alias for the connection. Currently this + message is ignored by iauth and any information discarded. + + - "U" + + This denotes the username information provided by a + client. This information cannot be trusted, and is only used + by ircd when an identd lookup has failed. Format of the + information is <username>. Eg: + + 2 U earthpig + + This indicates the client supplied "earthpig" as the username + in the USER line during client handshaking with ircd. + + - "P" + + This denotes password information supplied by the client. Eg: + + 2 P uhuh + + This indicates the user supplied a password of "uhuh" during + client handshaking with ircd. A "U" message will always + immediately follow this message. + + - "T" + + This denotes the ircd is registering a client, which will + usually only occur if iauth has taken too long to get back + to ircd with a response. This message has no other + information. Eg: + + 2 T + + - "E" * + + This denotes an error message from ircd. The information + provided has the form of <error message>. Eg: + + 2 E I am a teapot. + +IAUTH Messages: + +The communication protocol used to communicate from iauth to ircd is +line-based and has the following form: + + <category> <information> + + * <category> is a single letter used to denote the type of + information being sent. + + * <information> is the rest of the line ("\n"-terminated), + whose format depends on the category of information. + + - ">" + + This is used to by iauth to send messages to &AUTH. + + - "G" + + This is used by iauth to set up debugging feedback from + ircd. Eg: + + G 1 + + - "O" + + This is used by iauth to tell ircd of some global iauth + policy decisions. Valid <information> includes the letters + "R", "T", "A" and "W" only. Eg: + + O RTA + + Valid policy types are: + R -- All clients _must_ be authenticated by iauth + to be allowed through; + T -- The IRC server should not accept new user + connections if iauth hasn't finished its work; + A -- The IRC server should send additional information + to iauth, such as a client-supplied password; + W -- Extra time should be allowed for requests + (usually to allow for hostname information to + become available). + + - "a" + + This indicates that iauth is reading a new configuration + file. Eg: + + a + + - "A" * + + This is used to describe the iauth configuration as it is + read. The information consists of <hosts?> <module name> + <options>. Eg: + + A * rfc931 + + This means that the rfc931 (identd) module is invoked for + every connection, and no options were given. + + - "s" * + + This is used to denote that any recorded statistics on iauth + should be reset. Eg: + + s + + - "S" + + This is used to send iauth statistics. The information has the + form of <module name> <module-specific information>. Eg: + + S rfc931 connected 0 unix 0 other 0 bad 0 out of 0 + + This indicates some statistics from the rfc931 module. + + - "U" * + + This is used to send username information (returned by identd) + to the ircd. This corresponds to information that has been + deemed usable to ircd by iauth. The information has the form + of <identifier> <remote IP> <remote port> <username>. Eg: + + U 2 192.168.2.10 13578 earthpig + + - "u" * + + This is used to send username information (returned by identd) + to the ircd. This corresponds to information that has been not + deemed usable to ircd by iauth, usually due to the type of + reply received from identd. The information has the form of + <identifier> <remote IP> <remote port> <username>. Eg: + + u 2 192.168.2.10 13578 earthpig + + - "K" + + This is used to indicate a client should be killed. The + information provided is of the form <identifier> <remote IP> + <remote port>. Eg: + + K 2 203.36.167.162 13578 + + - "k" + + This is used to indicate a client should be killed. The + information provided is the same as for the above "K" message + with the exception that this version is "quieter". ie, The + ircd won't be as verbose about the client being rejected. + + - "D" + + This is used to indicate that iauth's processing of a client + has finished. The information provided is of the form <id> + <remote IP> <remote port>. Eg: + + D 2 203.36.167.162 13578 + + - "r" * + + This is used by iauth to indicate it is shutting down. No + extra information is provided. Eg: + + r + +Items marked with a * may be incorrect or contain uncertain +information. + +Module Processing +----------------- + +Module processing is done in a linear manner, one module at a +time. When one module indicates it is finished with the client, iauth +starts the next module on it. However, the matter is complicated +slightly in that multiple passes can be made through the list of +modules. By default each module is given 15 seconds to complete its +work on a given client, before it gets timed-out. + +The first pass commences immediately when ircd notifies iauth of a +client to check. A new pass commences: + +1) When DNS information about the client's hostname is finalised. + +2) When the USER information supplied by the client becomes available. + +Earlier versions of iauth did not commence a subsequent pass if DNS +information was not available, but the current version starts one +regardless. + +All modules are by default included in the first pass, with unused +modules being included in the second pass if it commences prior to +them being invoked. Modules are deferred to the second pass if they +were configured using the "host = " directive (unless a "ip = " option +was also specified and matched). There is a special case of "host = *" +which forces a module to be delayed until hostname information is +known, where it will always be invoked. + +Module Interface +---------------- + +The default modules are statically linked into the iauth +daemon. However, there are now provisions for dynamically-loadable +modules, as described by the iauth.conf man-page. Regardless of how +they are linked/loaded, modules are currently expected to export the +following functions (and array): + +char *name_init(AnInstance *self); +void name_release(AnInstance *self); +void name_stats(AnInstance *self); +int name_start(u_int client); +int name_work(u_int client); +int name_timeout(u_int client); + +aModule Module_name = + { "name", name_init, name_release, name_stats, + name_start, name_work, name_timeout, name_clean }; + +By convention the exported symbols use the form "name_symbol" where +"name" is replaced by the module's name. For modules that are linked +statically, a reference to Module_name must be added to the MList +array near the start of conf_read() in a_conf.c + +For examples of what the exported functions are expected to do, please +refer to the (internally documented) modules included in iauth. + +Limitations +----------- + +Currently iauth suffers from several limitations. It is hoped that in +the future these will be fixed. Patches are welcome. :) These +limitations (in rough order of importance) are: + +1) After ircd has registered a client, iauth cannot reject or kill a +connection. It is strongly desired that this be fixed. + +2) There is no way for a module to specify the "reason" a client +connection was rejected (for display or other purposes). + +3) The current module design assumes a separate TCP/IP connection is +required for each client check (or at least separate file-descriptors +for each client can be watched for activity). While it's possible +tricks could be used to work around this assumption, it has not been +successfully done yet. + +Document Availability and Maintainence +-------------------------------------- + +This document was originally written by Andrew Snare and may contain +errors and/or omissions. Please send any corrections to +ajs@pigpond.com for inclusion in future versions. An up-to-date +version of this document is available on the web at: + + http://www.pigpond.com/~earthpig/iauth-internals.txt diff --git a/doc/iauth.8 b/doc/iauth.8 new file mode 100644 index 0000000..14a415a --- /dev/null +++ b/doc/iauth.8 @@ -0,0 +1,54 @@ +.\" @(#)$Id: iauth.8,v 1.4 1998/11/09 20:07:12 kalt Exp $ +.TH IAUTH 8 "$Date: 1998/11/09 20:07:12 $" +.SH NAME +iauth \- The Internet Relay Chat Authentication Program +.SH SYNOPSIS +.hy 0 +.IP \fBiauth\fP +[ +.B -v +| +.BI \-c " configfile" +] +.SH DESCRIPTION +.LP +\fIiauth\fP is a slave process used by the \fIircd\fP program to perform +the authentication of incoming connections. The \fIircd\fP program starts +\fIiauth\fP upon startup. + +\fIiauth\fP will close and reopen the log file whenever it receives a user +signal 2, SIGUSR2. This is useful to rotate the log file. +.SH OPTIONS +.TP +.BI \-c " filename" +When this flag is given, the program will read the configuration file +specify and validate it. This is useful to check for errors in the setup. +.TP +.B \-v +This option dumps information about the version. +.SH EXAMPLE +.RS +.nf +millennium% \fBiauth -c iauth.conf\fP +iauth 2.10 + +Reading "iauth.conf" + +Module(s) loaded: + rfc931 +.fi +.RE +.SH COPYRIGHT +(c) 1998 Christophe Kalt +.LP +For full COPYRIGHT see LICENSE file with IRC package. +.LP +.RE +.SH FILES + "iauth.conf" +.SH "SEE ALSO" +iauth.conf(5) ircd(8) +.SH BUGS +None... ;-) if somebody finds one, please send mail to ircd-bugs@irc.org +.SH AUTHOR +Christophe Kalt. diff --git a/doc/iauth.conf.5 b/doc/iauth.conf.5 new file mode 100644 index 0000000..832d9a8 --- /dev/null +++ b/doc/iauth.conf.5 @@ -0,0 +1,159 @@ +.\" @(#)$Id: iauth.conf.5,v 1.16 1999/07/04 22:09:09 kalt Exp $ +.TH IAUTH.CONF 5 "$Date: 1999/07/04 22:09:09 $" +.SH NAME +iauth.conf \- The Internet Relay Chat Authentication Configuration File +.SH DESCRIPTION +.LP +The \fIiauth.conf\fP file is read by the \fIiauth\fP program upon startup, +it contains the list of modules that should be used to authenticate a +particular connection. The list is ordered, which means that the first +module to successfully authenticate a connection will be the last to be +tried. + +The file is divided in sections, the first section is used for iauth +options, each subsequent section specifies a module with eventual options +using the following format: + +.RS +.nf +module\ \fImodule-name\fP +[TAB]option = \fIstring\fP +[TAB]host = \fIhost-name\fP +[TAB]ip = \fIip-address\fP +[TAB]timeout = \fIvalue\fP + +.fi +.RE +The section ends with an empty line. The \fImodule-name\fP defines which +module the section applies to. A particular module may be used in several +sections. A \fIstring\fP of undefined format may be specified, it will +then be passed to the module upon initialization, see the MODULES section +to find out if a module accepts any option. + +If \fIhost-name\fP and \fIip-address\fP fields are specified, then the +module will only be used for connections matching one of the fields given +in the configuration. An entry prefixed with the character ! indicates a +negative match. IP addresses are checked first. + +If no host nor ip entry is specified, then the module will always be used. + +When writing a configuration file, one should \fBalways\fP verify the +syntax using the \fIiauth\fP program to avoid later problems. +.SH IAUTH OPTIONS +.TP +.B timeout = <seconds> +This allows to specify how much time each module has to complete its work +for each connection. This option can also be specified individually for +each module. The default is 30 seconds. +.TP +.B required +By specifying this keyword, the IRC server is told not to accept new user +connections unless the authentication is handled by \fIiauth\fP. This does +NOT mean that the server will wait forever to get the data from iauth, see +the \fInotimeout\fP option. +.TP +.B notimeout +By specifying this keyword, the IRC server is told not to accept new user +connections if \fIiauth\fP hasn't finished its work in time. +.TP +.B extinfo +This keyword allows extra information (user supplied username, and +eventually password) to be received by \fIiauth\fP from the server. This +is only useful is a module using this information is loaded. +.TP +.B shared <name> <mod_name.so> +If iauth was compiled with Dynamically Shared Module support, it can be +told to dynamically load a module using this option. The module can then +be loaded. +.SH MODULES +.TP +.B pipe +This module is provided as a replacement to the (now obsolete) R +configuration lines supported by the IRC daemon. It runs an external +program with the client IP and port as arguments. The program should +output either 'Y' (Yes, let the client in), or 'N' (No, don't let them +in). + +Note that this module is quite expensive as it forks a separate process for +each connection received by the IRC daemon. + +This module requires the following option: +.B prog=/path/to/external/program +.TP +.B socks +This module performs a basic check to verify that the host where the +connection originated from doesn't run a SOCKS v4 or v5 proxy server on +port 1080 that is open to the world. It is useful to reject abusive +clients using a relay to evade kill lines and bans. + +This module understands seven options: +.B reject +to reject connections originating from a host where an open proxy +was detected, +.B log +to log hostnames where an open proxy is detected. +.B paranoid +to consider proxies which deny the request because of a userid/ident +mismatch to be OPEN proxies. +.B cache[=value] +to set the cache lifetime in minutes. By default, caching is enabled for +30 minutes. A value of 0 disables caching. +.B careful +to make sure socks v5 is properly configured with IP rulesets. Without +this parameter, module will not send additional query and assume first +positive answer as valid. +.B v4only +to check only socks v4. +.B v5only +to check only socks v5. +.TP +.B rfc931 +This module is for authentication TCP connections using the protocol +defined in RFC 1413 (which obsoletes RFC 931). It is always loaded, and +does not recognize the \fIhost\fP nor \fIip\fP fields. +.TP +.B lhex +This module acts as a proxy, communicating with a LHEx server to perform +authentication of client connections. It takes a single (mandatory) +option, which is the IP-address of the LHEx server to use. +.SH EXAMPLE +The following file will cause the IRC daemon to reject all connections +originating from a system where an open proxy is running for hosts within +*.fr and *.enserb.u-bordeaux.fr but not for other hosts matching +*.u-bordeaux.fr. For all connections, an ident lookup (RFC 1413) will be +performed. In addition, every connection is authenticated with the LHEx +server at IP-address 127.0.0.1. + +.RS +.nf +module socks + option = reject,paranoid + host = *.enserb.u-bordeaux.fr + host = !*.u-bordeaux.fr + host = *.fr + +module rfc931 + +module lhex + option = 127.0.0.1 +.fi +.RE +.SH CAVEATS +When the option +.B extinfo +is set, connections registering as a server or a service with the IRC +server are not guaranteed to receive the "user" authentication provided by +modules (such as the rfc931 module). +.RE +.SH COPYRIGHT +(c) 1998,1999 Christophe Kalt +.LP +For full COPYRIGHT see LICENSE file with IRC package. +.LP +.RE +.SH FILES +"iauth.conf" +.SH "SEE ALSO" +iauth(8) +.SH AUTHOR +Christophe Kalt. diff --git a/doc/irc.1 b/doc/irc.1 new file mode 100644 index 0000000..d8dd677 --- /dev/null +++ b/doc/irc.1 @@ -0,0 +1,85 @@ +.\" @(#)$Id: irc.1,v 1.5 1998/12/13 00:02:34 kalt Exp $ +.TH IRC 1 "$Date: 1998/12/13 00:02:34 $" +======= +.\" @(#)$Id: irc.1,v 1.5 1998/12/13 00:02:34 kalt Exp $ +.TH IRC 1 "$Date: 1998/12/13 00:02:34 $" +.SH NAME +irc \- User Interface to Internet Relay Chat Protocol +.SH SYNOPSIS +\fBirc\fP [\fB-p\fP \fIportnum\fP] [\fB-c\fP \fIchannel\fP] [ \fInickname\fP [ \fIserver\fP ]] +.SH DESCRIPTION +.LP +\fBIrc\fP is a user interface to the Internet Relay Chat, a CB-like +interactive discussion environment. It is structured into \fIchannels\fP, +which are public discussion forums, and also allows for private intercommunication. +Each participant has a \fInickname\fP, which is the one specified in the command +line or else his login name. +.LP +Once invoked, \fBirc\fP connects as a client to the specified server, +\fIserver\fP or to the default one (see below). The screen splits into a dialogue +window (the major part +of the screen) and a command line, from which messages can be sent and +commands given to control irc. +.SH COMMAND SYNTAX +The syntax of irc commands is of the form \fB/COMMAND\fP. The most notable +ones are listed below. For an uptodate list, use the \fBHELP\fP command +of \fBirc\fP. Case is ignored. +.IP "\fB/ADMIN\fR [\fIserver\fP]" +Prints administrative information about an IRC \fIserver\fP. +.IP "\fB/AWAY\fP [\fImessage\fP]" +Mark yourself as being away (with an automatic reply \fImessage\fP +if specified) +.IP "\fB/BYE\fR, \fB/EXIT\fR, \fB/QUIT\fR" +Terminate the session +.IP "\fB/CHANNEL\fR [\fIchannel\fP]" +Join another \fIchannel\fP +.IP "\fB/CLEAR\fR" +Clear the screen +.IP "\fB/HELP\fR [\fIcommand\fP]" +Display a brief description of the \fIcommand\fP (or list all commands, if none +specified). +.IP "\fB/SUMMON\fR \fIuser\fP" +Allows to summon a \fIuser\fP specified as a full Internet address, i.e., +\fIlogin@host.domain\fP, to an IRC dialogue session (in much the same +way as the talk(1) command). It is usable ONLY if the irc daemon runs on +the target machine (host.domain). +.IP "\fB/TOPIC\fR \fItopic\fP" +Sets the \fItopic\fP for the current channel +.IP "\fB/WHO\fR [\fIchannel\fP|*]" +Lists all users of IRC if no argument, of the specified \fIchannel\fP or of the +current channel (*). +.SH ARGUMENTS +.IP "\fB-p\fP \fIportnum\fP" +TCP/IP "port number. Default is 6667 and this option should seldom if ever" +be used. +.IP "\fB-c\fP \fIchannel\fP" +\fIChannel\fP number to join upon beginning of the session. Default is no channel. +.IP "\fInickname\fP" +\fINickname\fP used in the session (can be changed with the \fB/NICK\fP command). +Default is user login name. +.IP "\fIserver\fP" +\fIServer\fP to connect to. Default is specified in the irc system configuration +file, and can be superseded with the environment variable IRCSERVER. +.SH EXAMPLE +.RS +.nf +tolmoon% \fBirc -p6667 Wizard tolsun\fP +.fi +.RE +.LP +connects you to irc server in host tolsun (port 6667) with nickname Wizard +.SH COPYRIGHT +Copyright (c) 1988 University of Oulu, Computing Center, Finland. +.nf +Copyright (c) 1988,1989,1990 Jarkko Oikarinen +.nf +All rights reserved. +For full COPYRIGHT see LICENSE file with IRC package. +.SH "SEE ALSO" +ircd(8) +.SH BUGS +What bugs ? +.SH AUTHOR +Jarkko Oikarinen <jto@tolsun.oulu.fi> +.nf +Manual page updated by Michel Fingerhut <Michel.Fingerhut@ircam.fr> diff --git a/doc/ircd.8 b/doc/ircd.8 new file mode 100644 index 0000000..2727815 --- /dev/null +++ b/doc/ircd.8 @@ -0,0 +1,202 @@ +.\" @(#)$Id ircd.8 2.0 (beta version) 29 Mar 1989 $ +.TH IRCD 8 "$Date: 1999/04/08 22:12:19 $" +.SH NAME +ircd \- The Internet Relay Chat Program Server +.SH SYNOPSIS +.hy 0 +.IP \fBircd\fP +[ +.B \-abcioqst +] [ +.BI \-f " configfile" +] [ +.BI \-x " debuglevel" +] [ +.BI \-h " hostname" +] [ +.BI \-T " tunefile" +] [ +.BI \-p " mode" +] +.IP \fBircd\fP +.B \-v +.SH DESCRIPTION +.LP +\fIircd\fP is the server (daemon) program for the Internet Relay Chat +Program. The \fIircd\fP is a server in that its function is to "serve" +the client program \fIirc(1)\fP with messages and commands. All commands +and user messages are passed directly to the \fIircd\fP for processing +and relaying to other ircd sites. The \fIirc(1)\fP program depends upon +there being an \fIircd\fP server running somewhere (either on your local +UNIX site or a remote ircd site) so that it will have somewhere to connect +to and thus allow the user to begin talking to other users. + +\fIircd\fP will reread its configuration file whenever it received a hangup +signal, SIGHUP. + +Sending an interrupt signal to \fIircd\fP process will cause it to restart. + +.SH OPTIONS +.TP +.B \-a +Instructs the server to automatically die off if it loses all it's clients. +.TP +.B \-b +If the ircd.tune file is corrupted, by default the server +will not start. This option will make the server start +anyways, with the default values (ignoring the corrupted +file). +.TP +.B \-c +This flag must be given if you are running ircd from \fI/dev/console\fP or +any other situation where fd 0 isnt a tty and you want the server to fork +off and run in the background. This needs to be given if you are starting +\fIircd\fP from an \fIrc\fP (such as \fI/etc/rc.local\fP) file. +.TP +.B \-i +The server was started by inetd and it should start accepting connections +from standard input. The following inetd.conf-line could be used to start +up ircd automatically when needed: +.TP +.B +ircd stream tcp wait irc /etc/ircd ircd \-i + +allows inetd to start up ircd on request. +.TP +.B \-o +Starts up a local ircdaemon. Standard input can be used to send IRC +commands to the daemon. The user logging in from standard input will +be given operator privileges on this local ircd. If ircd is a setuid program, +it will call setuid(getuid()) before going to local mode. This option +can be used in inetd.conf to allow users to open their own irc clients +by simply connecting their clients to the correct ports. For example: +.TP +.B +irc stream tcp nowait irc /etc/ircd ircd \\-f/etc/ircd.conf \\-o + +allows users connecting to irc port (specified in /etc/services) to start +up their own ircdaemon. The configuration file should be used to check from +which hosts these connections are allowed from. This option also turns +on the autodie option -a. +.TP +.B \-q +Using this option stops the server from doing DNS lookups on all the +servers in your \fIircd.conf\fP file when it boots. This can take a lengthy +amount of time if you have a large number of servers and they are not all +close by. +.TP +.B \-s +When this option is specified, \fIiauth\fP will not be +started. This means that the IRC daemon will perform "ident +lookups" (RFC 1413) internally to attempt to authenticate +incoming connections. No other authentication mechanism +will be used. +.TP +.B \-t +Instructs the server to direct debugging output to standard output. +.TP +.BI \-f " filename" +Specifies the ircd.conf file to be used for this ircdaemon. The option +is used to override the default ircd.conf given at compile time. +.TP +.BI \-x " #" +Defines the debuglevel for ircd. The higher the debuglevel, the more stuff +gets directed to debugging file (or standard output if -t option was used +as well). +.TP +.BI \-h " hostname" +Allows the user to manually set the server name at startup. The default +name is hostname.domainname. +.TP +.BI \-p " mode" +Specify whether the server should enable built-in +protections against various type of user abuse that is +commonly found on big public networks. Possible modes are +.BR strict " (default)," +.BR on " and" +.BR off . +The +.B strict +option enables the protections, and refuses to establish a +link to a server not running with this option. This is +useful to force all servers on an IRC network to enable +them. +.TP +.BI \-T " tunefile" +Specifies the ircd.tune file to be used for this ircdaemon. The option +is used to override the default ircd.tune given at compile +time. +.TP +.B \-v +This option prevents the server from starting, and dumps +some information about the version instead. +.TP +.SH +If you plan to connect your \fIircd\fP server to an existing Irc-Network, +you will need to alter your local IRC CONFIGURATION FILE (typically named +"ircd.conf") so that it will accept and make connections to other \fIircd\fP +servers. This file contains the hostnames, Network Addresses, and sometimes +passwords for connections to other ircds around the world. Because +description of the actual file format of the "ircd.conf" file is beyond the +scope of this document, please refer to the file INSTALL in the IRC source +files documentation directory. +.LP +BOOTING THE SERVER: The \fIircd\fP server can be started as part of the +UNIX boot procedure or just by placing the server into Unix Background. +Keep in mind that if it is *not* part of your UNIXES Boot-up procedure +then you will have to manually start the \fIircd\fP server each time your +UNIX is rebooted. This means if your UNIX is prone to crashing +or going for for repairs a lot it would make sense to start the \fIircd\fP +server as part of your UNIX bootup procedure. In some cases the \fIirc(1)\fP +will automatically attempt to boot the \fIircd\fP server if the user is +on the SAME UNIX that the \fIircd\fP is supposed to be running on. If the +\fIirc(1)\fP cannot connect to the \fIircd\fP server it will try to start +the server on it's own and will then try to reconnect to the newly booted +\fIircd\fP server. +.SH EXAMPLE +.RS +.nf +tolsun% \fBircd\fP +.fi +.RE +.LP +Places \fIircd\fP into UNIX Background and starts up the server for use. +Note: You do not have to add the "&" to this command, the program will +automatically detach itself from tty. +.LP +.RS +.nf +tolsun% \fBircd \-v\fP +ircd 2.9.3 AaCDEfFHiIkMsu_V1 + zlib not used + Tue Apr 1 1997 at 20:17:50 EDT #1 +.fi +.RE +.LP +This indicates that this binary is the version 2.9.3 of the +software. AaCDEfFHiIkMsu_V1 are the compile time options +which were used. This binary does not support compression +of server\-server links (does not use zlib) and was compiled +on April the 1st. +.SH COPYRIGHT +(c) 1988,1989 University of Oulu, Computing Center, Finland, +.LP +(c) 1988,1989 Department of Information Processing Science, +University of Oulu, Finland +.LP +(c) 1988,1989,1990,1991 Jarkko Oikarinen +.LP +For full COPYRIGHT see LICENSE file with IRC package. +.LP +.RE +.SH FILES + /etc/utmp + "ircd.conf" +.SH "SEE ALSO" +iauth(8) irc(1) ircdwatch(8) +.SH BUGS +None... ;-) if somebody finds one, please send mail to ircd-bugs@irc.org +.SH AUTHOR +Jarkko Oikarinen, currently jto@tolsun.oulu.fi, +manual page written by Jeff Trim, jtrim@orion.cair.du.edu, +later modified by jto@tolsun.oulu.fi. diff --git a/doc/m4macros b/doc/m4macros new file mode 100644 index 0000000..2cc17d3 --- /dev/null +++ b/doc/m4macros @@ -0,0 +1,48 @@ +# @(#)$Id: m4macros,v 1.2 1997/04/21 13:50:04 kalt Exp $ + +The following macros are included in "ircd.m4" for use with the m4 text +preprocessor. "ircd.m4" is parsed before the IRC server conf file so they +are all available for use with that. + +NOTE: The "ircd.m4" file is *ONLY* created by a "make install". + +VERSION - current version string as in patchlevel.h +DEBUGMODE - if DEBUGMODE is define in config.h, is also defined for m4. +HOSTNAME - taken from hostname(1) +USER - username of person doing the "make install" +PORT - default port number as in config.h +PFREQ - default ping frequency as in config.h +CFREQ - default connect frequency as in config.h +MAXSENDQ - default max sendq as in config.h +CL - use this to wrap a class number +HOST - use this to wrap a hostname +HOSTM - use this to wrap the hostmask number in N-lines +ID - when wrapping the host field in an I-line, causes ident string return + to be used instead of user supplised username. +PASS - use this to wrap passwords in C/N/I/O lines +PING - use this to wrap the ping value in Y-lines +APORT - use this to wrap the port number in I-lines +CPORT - use this to wrap the port number in C-lines +SERV - use this to wrap server names + +You might use some of these as +C:foo.bar.edu:PASS(boo):foo.bar.edu:APORT(6667) +I:ID(128.250.*)::ID(*.mu.oz.au):CPORT(6667) + +In addition to these (rather weak macros), some more complete ones are +defined which already perform the above. + +ADMIN - provide fields to it as you would an A-line +ALLOW - provide fields to it as you would an N-line +BAN - provide fields to it as you would an K-line +CLASS - provide fields to it as you would an Y-line +CLIENT - provide fields to it as you would an I-line +CONNECT - provide fields to it as you would an C-line +ME - provide fields to it as you would an M-line +HUB - first parameter is server you want to hub, second is optional and is + a mask against which other servers introduced must match against. +LEAF - works like HUB, except that the mask is matched against server names + to check if the link should be dropped. +SERVER - uses 6 fields, the first 4 as are found in an N-line, the last two + should be as you would use in a C-line. It expands out to provide + both a C and N line. |