diff options
| author |  Jonas Gunz <himself@jonasgunz.de>
| 2020-05-25 20:09:04 +0200 |
|---|---|---|
| committer | Jonas Gunz <himself@jonasgunz.de>
| 2020-05-25 20:09:04 +0200 |
| commit | 4440a86cfa359b8e40a484a2cd46d33db5455d8a (patch) | |
| tree | f5c0c59aebf0058ae97e7ef8b5fb8017f459a05a /doc/Juped | |
| download | ircd-4440a86cfa359b8e40a484a2cd46d33db5455d8a.tar.gz | |
Initial
Diffstat (limited to 'doc/Juped')
| -rw-r--r-- | doc/Juped/Advertisement | 39 | ||||
| -rw-r--r-- | doc/Juped/ChangeLog.common | 91 | ||||
| -rw-r--r-- | doc/Juped/ChangeLog.doc | 90 | ||||
| -rw-r--r-- | doc/Juped/ChangeLog.include | 85 | ||||
| -rw-r--r-- | doc/Juped/ChangeLog.irc | 77 | ||||
| -rw-r--r-- | doc/Juped/ChangeLog.ircd | 458 | ||||
| -rw-r--r-- | doc/Juped/INSTALL | 1167 | ||||
| -rw-r--r-- | doc/Juped/US-Admin/Networking | 156 |
8 files changed, 2163 insertions, 0 deletions
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 + |