philippelh/ircu2.9.32
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
Philippe L'Heureux
2023-12-26 16:40:53 -05:00
commit ab64084f63
93 changed files with 40857 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
doc/Advertisement Normal file
View File

@@ -0,0 +1,40 @@
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 other computer users in other parts of
the world? Well guess what? You can! The program 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 channels 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.

153
doc/Authors Normal file
View File

@@ -0,0 +1,153 @@
/************************************************************************
* IRC - Internet Relay Chat, doc/AUTHORS
* Copyright (C) 1990
*
* AUTHORS FILE:
* This file attempts to remember all contributors to the IRC
* developement. Names can be only added this file, no name
* should never be removed. This file must be included into all
* distributions of IRC and derived works.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 1, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
IRC was conceived of and written by Jarkko Oikarinen <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 and 2.8 releases were coordinated by Darren Reed.
Contributions for the 2.8 release from the following people:
Matthew Green <phone@coombs.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.
Jarle Lyngaas (nmijl@alf.uib.no) added Note functions to ircd.
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. :)
Thanks go to those persons not mentioned here who have added their advice,
opinions, and code to IRC.
Various modifications, bugreports, cleanups and testing by:
Hugo Calendar <hugo@ucscb.ucsc.edu>
Bo Adler <adler@csvax.cs.caltech.edu>
Michael Sandrof <ms5n+@andrew.cmu.edu>
Jon Solomon <jsol@cs.bu.edu>
Jan Peterson <jlp@hamblin.math.byu.edu>
Nathan Glasser <nathan@brokaw.lcs.mit.edu>
Helen Rose <hrose@eff.org>
Mike Pelletier <stealth@caen.engin.umich.edu>
Basalat Ali Raja <gwydion@tavi.rice.edu>
Eric P. Scott <eps@toaster.sfsu.edu>
Dan Goodwin <fornax@wpi.wpi.edu>
Noah Friedman <friedman@ai.mit.edu>
1991 - 1996 :
The Undernet version, starting off with 2.8.10, contains thousands of hours
of work by Run (carlo@runaway.xs4all.nl). The number of protocol enhancements,
changes and additions that have been added are too many to summarize.
Various additions and bugfixes have been contributed by:
SeKs <intru@step.polymtl.ca> - Review member coder-com
WildThang <dvmitche@antietam.nssl.uoknor.edu> - Review member coder-com
Kev <klmitch@mit.edu> - Secretary coder-com
Cym <cym@misha.net>
Xorath <vorac@wheel.dcn.davis.ca.us>
smg <smg@lm.com>
Chaos <simon@troll.elec.uow.edu.au>
Aaron <agifford@sci.dixie.edu>

126
doc/Crule.readme Normal file
View File

@@ -0,0 +1,126 @@
SmartRoute
Rule based connects
Draft 4 - Aug 19, 1994
by Tony Vencill
Rule based connects allow an admin to specify under what conditions
a connect should not be allowed. If no rules are specified for a
given C and/or N line it will be allowed under any condition.
A rule may consist of any legal combination of the following functions
and operators.
Functions
---------
connected(targetmask) - true if a server other than that processing
the rule is connected that matches the
target mask
directcon(targetmask) - true if a server other than that processing
the rule is directly connected that matches
the target mask
via(viamask, targetmask) - true if a server other than that processing
the rule matches the target mask and is
connected via a directly connected server
that matches the via mask
directop() - true if an oper is directly connected
Unary operators
---------------
! eg: !argument - true if the argument is false
Binary operartors
-----------------
&& eg: arg1&&arg2 - true if arg1 and arg2 are both true
|| eg: arg1||arg2 - true if arg1, arg2, or both are true
Parenthesis () are allowed for grouping arguments, but if no parenthesis
are included, && will take precedence over ||, ! will take precedence
over both && and ||, and the function will be evaluated from left to
right. White space in a rule is ignored. Invalid characters in a rule
will lead to the rule being ignored.
Examples
--------
A simple example of a connect rule might be:
connected(*eu.under*)
This might be used in a US undernet server for a Europe CN pair to
insure that a second Europe link is not allowed if one US-EU link
already exists. Note that on the undernet, US server names are
city.state.us.undernet.org and Europe server names are
city.country.eu.undernet.org.
A more interesting example might be:
connected(*eu.under*) &&
( !direct(*eu.under*) || via(manhat*, *eu.under*) )
Imagine the Boston undernet server uses this rule on its Europe CN
pairs. This says that if a Europe server is already connected, a
Boston-Europe connect will not be allowed. It also says that if a
Europe server does already exist and Boston is not directly connected
to one or more Europe servers or Manhattan is, the Boston-Europe
connect will not be allowed. This has the effect of allowing multiple
US-EU links but attempting to limit these links to one server (ie:
Boston will not initiate its first Europe link if another server is
already linking Europe). This rule will also prefer to let Manhattan
handle the US-EU link by disallowing Boston-Europe links if a Europe
server is already linked to Manhattan.
A example of the remaining function, directop(), is:
connected(*eu.under*) || directop()
If this line is used on Boston for the Paderborn CN pair, it will allow
connects to Paderborn only if another Europe server is not already
connected and there is not an oper on Boston. If this rule is
overrideable (ie: is applied only to autoconnects as described below),
then it will disallow Boston autoconnects to Paderborn while a Boston
oper is online, but allow oper-initiated connects to Paderborn under any
circumstance. This directop() function could be used to invoke less
prefered routes only when an oper is not present to handle routing, or
conversly to allow use of less preferable routes only when an oper is
present to monitor their performance.
ircd.conf entries
-----------------
A rule is listed in the ircd.conf file using a D or d line (which can
be thought of as a "disallow" line). D lines will apply to all oper
and server originated connects, while d lines will apply only to
autoconnects (ie: they are overrideable by opers). The formats are:
D:targetmask::rule
d:targetmask::rule
Remember that newlines are not allowed in conf lines. Two examples
(from above) are:
D:*eu.under*::connected(*eu.under*)
d:*eu.under*::connected(*eu.under*) || directop()
Connects originating from other servers will be checked against and
matching D lines, while matching d lines will be ignored as it will not
be clear whether or not the connection attempt is oper initiated.
Checking and viewing rules
--------------------------
The chkconf program that comes with the servers has been modified to
also check your connect rules. If running in debug mode, parsing errors
will show up at debug level 8. To view rules online, "/stats d" can be
used to see all rules and "/stats D" can be used to view those rules
which affect oper initiated connects and accepts.
Processing and storage
----------------------
The rules are parsed when the conf file is read and transformed into a
more efficiently computed form, then all applicable rules are
evaluated each time a connect command is given or an autoconnect is
due. If more than one applicable rule is given, only one need
evaluate to true for the connect to be allowed (ie: the rules are ored
together). Note that conditions that exist when the connect is
initiated might differ from conditions when the link is established.

84
doc/Etiquette Normal file
View File

@@ -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
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 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 'burbs', connections going
down because servers cannot handle the large amount of traffic any more.

63
doc/Europe/CoordEBIC Normal file
View File

@@ -0,0 +1,63 @@
############################################################################
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 *.ch *.de *.dk *.fi *.fr *.it *.nl *.no *.pl *.se *.uk
############################################################################
The following national coordinators have been choosen for 92/93:
############################################################################
*.at EASINET, ACONET
1. Tom Tom Kovar <Tom.Kovar@rcvie.co.at>
*.ch SWITCH, EUNET/CH
1. StarNet Karim Saouli <Karim.Saouli@epfl.ch>
2. Maxim Maxim Samo <samo@nessie.cs.id.ethz.ch>
*.de WIN, BelWue
1. YeggMan Volker Paulsen <Volker.Paulsen@gmd.de>
2. Haegar Thomas Thissen <tici@uni-paderborn.de>
*.dk DENET, DKNET
1. karthy Karsten Thygesen <karthy@iesd.auc.dk>
2. MAGNA Jens Fallesen <fallesen@login.dkuug.dk>
*.fi FUNET
1. Vesa Vesa Ruokonen <Vesa.Ruokonen@lut.fi>
2. Visti Hannu Visti <visti@sauna.cs.hut.fi>
*.fr EASINET/ROCAD, RENATER
1. Nono Arnaud Girsch <Arnaud.Girsch@insa-lyon.fr>
2. Le_Chat Laurent Montaron <irc@eurecom.fr>
*.it CILEA
1. Allanon Riccardo Facchetti <riccardo@cdc835.cdc.polimi.it>
2. mAu Maurizio Paoluzi <paoluzi@mercurio.dm.unirm1.it>
*.nl SURFNET/NLNET
1. scorpio Cor Bosman <bosman@gene.fwi.uva.nl>
2. Erwin Erwin Bolwidt <erwin@mars.let.uva.nl>
*.no UNINETT
1. Veggen Vegard Engen <vegard@bih.no>
*.pl POLIP
1. Artur Artur Jaroszek <artur@vulcan.mimuw.edu.pl>
*.se SUNET
1. Black Christer H. Jansson <svarten@solace.hsh.se>
2. Sorg Owe A Rasmussen <d1rasmus@dtek.chalmers.se>
*.uk JANET, JIPS
1. ScottM Scott A. McIntyre <scott@shrug.dur.ac.uk>

171
doc/Europe/IRCNO Normal file
View File

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

90
doc/Europe/RulesEBIC Normal file
View File

@@ -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 hierachy).
+ 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.
############################################################################

961
doc/INSTALL Normal file
View File

@@ -0,0 +1,961 @@
/************************************************************************
* 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) The config.h file
2) Editing the Makefile
3) Compiling IRC
4) The ircd.conf file
1) Edit the "config.h" file and make changes to the various #DEFINE's:
a) Copy the config.h.dist file to config.h before editing.
b) 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.
c) 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.
d) DPATH, SPATH, CPATH, MPATH, LPATH, PPATH
DPATH is provided so that the other pathnames (SPATH, CPATH, etc)
may be provided in just filename form. When the server starts, it
chdir's to DPATH before chroot or any other file operation, making
it the "current directory" for the server. This is where core files
will go if it core dumps.
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 "irc.conf" file.
This path is usually /usr/local/lib/irc.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.
e) 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 DPATH.
f) 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.
g) 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.
h) 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.
i) 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) Configure and compile the code.
Edit the root Makefile for the server, uncomment/comment the correct
CFLAGS/IRCDLIBS lines as appropriate for your system.
Change DESTDIR to be the same as the path for DPATH in config.h.
Type "make". This will compile the server, the client, and the services.
At the end of this step, the server directory will contain 'ircd',
and the client directory will contain 'irc'. To get the server installed,
type "make install" which will build a default m4 file for preprocessing,
copy example.conf and put the server all in DESTDIR. The irc client and
a copy of the server will also be placed in BINDIR and the modes set
accordingly.
4) The ircd.conf file.
After installing the ircd and irc programs, edit the irc.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 irc.conf file contains various records that specify configuration
options. The record types are as follows:
1. Server connections (C,N)
2. Machine information (M)
3. Client connections (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)
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 "irc.conf" is:
C:<TARGET Host Addr>:<Password>:<TARGET Host NAME>:<TARGET Host PORT>
Field: 1 2 3 4 5
for example:
C:nic.funet.fi:passwd:nic.funet.fi:6667
- or -
C:128.214.6.100:passwd:nic.funet.fi:6667
- or -
C:root@nic.funet.fi:passwd:nic.funet.fi:6667
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.
Some examples:
C:nic.funet.fi::nic.funet.fi:6667
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
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
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
C:irc.nada.kth.se::irc.nada.kth.se:6667
C:nic.funet.fi::nic.funet.fi:6667
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.
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".
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
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:<YOUR Host NAME>:xxx:<Geographic Location>:<Internet Port>
Field: 1 2 3 4 5
Explanation:
Field 1: "M" specifies a Machine description line
Field 2: The name of YOUR host adding any Internet DOMAINNAME that
might also be present.
Field 3: -- NOT USED --: Set to Value NULL (No spaces at ALL!).
Field 4: Geographic Location is used to say WHERE YOUR SEVRER 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: The Internet port your server will use. Should be set to
the same value as in the config.h file.
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". My ircd will use
Internet Port 6667.
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".
I have defined Internet Port number "6667" to be used
as my IRCD Socket Port.
3. CLIENT CONNECTIONS - How to let clients connect to your IRCD.
A client is a program that connects to the ircd daemon (ircd). Currently
there are clients written in C and in GNU Emacs Lisp. The "irc"
program is the C client. Each person that talks via IRC is running
their own client.
The irc.conf files contains entries that specify which clients are allowed
to connect to your irc daemon. Obviously you want to allow your cwn
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>:<Internet Port>
Field:1 2 3 4 5
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:128.214.5.6::tolsun.oulu.fi
or
I:tolsun.oulu.fi::tolsun.oulu.fi
If you wanted to let remote clients connect, you could add the
following lines:
I:*.du.edu::*.du.edu
Allow any clients from machines whose names end in "du.edu" to connect
with no password.
I:128.214.6.100::nic.funet.fi
Allow clients from a machine with that IP number and the name
nic.funet.fi to connect.
I:*.tut.fi:secret:*.tut.fi
Allow clients from machines matching *.tut.fi to connect
with the password 'secret'.
I:*::*
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).
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).
4. DEFAULT HOSTS (for local clients)
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
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 "irc.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 "irc.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
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
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.
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)>:<User>
Field: 1 2 3 4
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 (no spaces), then then lines
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'.
Some Examples:
K:orion.cair.du.edu::jtrim
If user 'jtrim' connects to IRC from host "orion.cair.du.edu"
then IMMEDIATELY REMOVE HIM from my IRCD.
K:*.cair.du.edu::root
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
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:*
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.
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.
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 irc.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 irc.conf file BEFORE it is used in any other way.
The format for the line is:
Y:<CLASS>:<PING FREQUENCY>:<CONNECT FREQUENCY>:<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 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: 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.
Field 5: This field defines the maximum number of links this class
will allow from automatic connections. Using /CONNECT overrides this
feature.
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)!!
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.
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 is a 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 is the the server connectted to you that for which you want to
enforce leaf-like attributes upon.
Field 5 is the 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 yet implemented)
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 as they stand now are not fully implemented.
The following line can be added to your ircd.conf file to enable a
service:
S:<TARGET Host Mask>:<password>:<service_name>
Field: 1 2 3 4
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 'service name' is only used for the purpose of finding the
right S-line from the ircd.conf file for password matching. The
actual service name used is that set by NICK commands prior to
SERVICE being sent.
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 similar to registering as a normal user
except that you must send NICK first and then SERVICE. The service
command should look something like this:
SERVICE secretpassword referencename :Service 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,
however, are not affected by flood control. It is therefore wise to
oversee the use of S-lines with some care.
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# Mask>:<*>:<*>:<PORT>
Field: 1 2 3 4 5
or
P:<Directory>:<*>:<*>:<PORT>
Field: 1 2 3 4 5
Explanation
Internet Ports
Field 1
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 isnt 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.
13. Hub Connections
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
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.

25
doc/Makefile Normal file
View File

@@ -0,0 +1,25 @@
#************************************************************************
#* 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.
#*/
MANDIR=/usr/local/man
all:
install: all
-../bsdinstall -c -m 644 ircd.8 ${MANDIR}/man8

255
doc/Manual Normal file
View File

@@ -0,0 +1,255 @@
/************************************************************************
* IRC - Internet Relay Chat, doc/MANUAL
* Copyright (C) 1990, Karl Kleinpaste
*
* 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.
*/
Date: 04 Apr 1989
Author: Karl Kleinpaste
karl@cis.ohio-state.edu
Last modification: 15 May 1992
by Mauri Haikola
mjh@stekt.oulu.fi
Modified for undernet: 7 Feb 1995
by Carlo Kid
carlo@runaway.xs4all.nl
INTERNET RELAY CHAT
a real-time conversational system
* 1: Irc - replacement for talk(1)
Irc is a functional replacement for and improvement to talk(1). Talk
is an old, primitive, atrocious, minimalist sort of keyboard/screen
conversation tool, using a grotesque, machine-dependent protocol.
Irc does everything talk does, but with a better protocol, allowing
more than 2 users to talk at once, with access across the aggregate
Internet, and providing a whole raft of other useful features.
* 2: Entering Internet Relay Chat
To enter Internet Relay Chat you need to run a client, which will start
connecting to its default server. The best clients are the clients
conforming to 'ircII' but those are all unix clients. More info on
clients can be achieved from ftp.undernet.org:/pub/irc/docs/underfaq.1
* 3: How much can be seen from here
The universe - seriously.
This is most formally called Internet Relay Chat. Server hosts are
connected via a tree structure. The various servers relay control and
message data among themselves to advertise the existence of other
servers, users, and the channels and other resources being occupied by
those users.
* 4: Structure
There is quite a lot of structure to the operation of irc, as
compared to crufty old talk(1). Since so little could be done with
talk(1), it needed little structure. But to keep track of people
spread literally around the world (the system was written by Jarkko
Oikarinen of Finland, usually seen on the system as `Wiz'), the
structure is useful so that one can speak to exactly those people with
whom one wishes to speak.
** 4.1: Nicknames
All users of irc are known to the system by a `nickname.' By
default, one's nickname is one's login name. Nickname clashes are not
allowed; this is enforced by the servers. If one's intended nickname
clashes with someone else as one enters chat, one will not be able to
complete entry to irc until one changes one's nickname to something
else.
** 4.2: Presence on a channel
Fundamental to the operation of irc is the concept of a channel. All
users are `on a channel' while inside irc. One enters the `null
channel' first. One cannot send any messages while not in any
chatting channel unless one has set up a private conversation in some
way. The number of channels is essentially unlimited - whatever will
fit in a string of some ungodly length, that must start with a # sign.
** 4.3: Main modes of channels
Public
This is the default mode for a channel. When one is on a public
channel, one can be seen by all other users (if one's own user mode
permits this). Anyone can notice users on a public channel and join
such a channel's conversation.
Private
This means that, although anyone can see that one is using chat, no
one can tell what channel one is using unless one is already on that
channel with oneself. Since the number of potential channels is in
the billions, this is quite some security - all one gives away is the
acknowledgement that one is using chat.
Secret
While one is on a secret channel, no one who is not on one's channel
with oneself can even see that one is there. One's name does not show
up in a list of active users. The only indication of one's presence
is that, when entering chat, all new users are told that there are "N
users on P servers." If one checks on all users and finds less than N
of them, one knows that others are hiding on secret channels. But a
secret channel user still cannot be found except by brute-force
checking through all channels, a hopeless proposition in the face of
the huge number of possible channel names. Security through obscurity
finally means something. Of course, making a channel like '#test' secret
gives a huge change to be discovered anyway.
Changing the mode
The mode of a channel (private, secret, invite-only, moderated,
topic-limited, person-number-limited, no-messages-to-channel, ban
someone from channel) is set by the channel operator, who is the
first person to join a channel, or someone who has had channel
operatorship bestowed on them by another channel operator.
*** 4.4: Conversations not using channels
It is possible to conduct conversations with others without using the
formalized channel structure. Doing so requires that two people set
themselves up for private conversation using special commands; see
User Commands below.
** 5: Getting help
Type "/help." Follow the instructions. Since this is a client feature
it might not work for you, in which case you'd have to consult your
local irc guru or someone on the net.
** 5.1: User commands
In most clients, commands must start with a '/' (for example: /join #test).
The most important commands supported by irc are:
help quit who whois
list topic join part
links msg invite silence
names stats nick away
info clear query ignore
mode
*** 5.1.1: /quit [comment]
/quit exits chat. Optional comment may be included; see above.
*** 5.1.2: /who [#channelname_mask | user@host.mask]
/who returns information on who is using chat. /who without arguments
prints info on all users that can be seen. Users of public channels
show up with their channel identified. Users of private channels
appear, but they are specified as being on a private, unspecified
channel. Users of secret channels and users whose user mode is +i
(invisible) do not appear at all.
Giving a channel name as an argument to /who returns only those users of the
specified channel. This still doesn't show users of secret channel or
invisible users one is actually on the same channel with them. Users
of private channels are shown, if an exact channel name is given.
*** 5.1.3: /whois <nickname>
This returns information about individual users. Type "/whois nickname"
to get information on the login name and host from which the nicknamed
user comes.
*** 5.1.4: /topic <some topic string>
Channels can be given off-the-cuff "topics." Saying "/topic some
string of text" will associate that topic with the current channel.
*** 5.1.5: /list [#channel.mask]
/list will give lists of active channels, the number of users of each,
and the topics therewith associated. Again, secret channels do not
appear and private channels only appear as Prv.
*** 5.1.6: /join <channel>
/join <#channel_name> is the means to enter a channel. Give the channel
name as an argument. If this is a secret or hidden channel, /who
commands will show oneself and any other users of one's channel.
One's arrival on a channel is announced to the rest of the users
already on that channel. Silent, anonymous "lurking" is not
supported.
*** 5.1.7: /msg <nick> <some text string>
A single message can be sent privately to a certain user with /msg.
Type /msg nickname and the text to be sent. It will be sent privately
to the indicated nickname.
*** 5.1.8: /invite <#channel> <nick>
If there is a user online to whom one wishes to speak, one may invite
that user to join oneself on a certain channel. One types "/invite
nickname" with an optional channel name. The receiving user gets a
one-line message indicating the sender and the invitation. The
receiving user is free to ignore the invitation, of course.
*** 5.1.9: /ignore <nick!user@host.mask>
If one wants to ignore messages sent by some other user or users, it
may be done with /ignore command. One can ignore someone by their
nickname, or by their user@host data. Wildcards may be used. /ignore
is only intended to ignore annoying public messages (messages sent to
a channel), to stop flooding (a huge number of messages per second)
you have to use banning for channel messages, and /silence for private
messages. /mode <your nick> +d stops all messages to ALL channels.
*** 5.1.12: /silence [nick!user@host.mask]
This command effectively stops private message flooding at the server
of the flooder. You can use "/silence nick" to get a list of the
silence masks of 'nick'. This command is undernet specific and therefor
not supported by all clients unless you add specifically a line to your
clients configuration file.
*** 5.1.11: /nick <new_nick>
One can change nicknames by issuing "/nick new-nickname." All users
on one's channel will be informed about the change. NOTE: If one enters
chat with a nickname clash (e.g., one's login name is the same as
someone else's, and the other user got there first), the system will
not let one enter until one issues a /nick command with a unique
nickname.
*** 5.1.12: /mode #channel <lots of parameters>
This command can be used for altering the various modes of a channel
(see the explanation of channel modes above). /mode command can only
be issued by channel operators. Please use /help, or the manual of
your client to find out about this command.
* 6: Questions, problems, troubles?
If you have problems, please get and read the FAQs from
ftp.undernet.org:/pub/irc/docs/underfaq.1 and underfaq.2.
You can also ask for help on some of the operator channels on irc,
for example #wasteland. They will be able to assist you in whatever
problems you are having with IRC.

331
doc/NOTE Normal file
View File

@@ -0,0 +1,331 @@
Usages:
NOTE [USER] [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg>
or [SEND|SPY|FIND|WAITFOR|NEWS|Channel|Wall|Wallops|Deny|Key]
NOTE [[x]LS|COUNT|[x]RM|LOG] [&pwd][+-flags] <nick!user@host> [date]
NOTE [FLAG] [&passwd] [+-flags] <nick!username@host> <+-flags>
NOTE [SENT] [NAME|COUNT|Users] <f.nick!f.name@host> <date> [RM]
NOTE [STATS] [MSM|MSW|MUM|MUW|MST|MSF|USED|Reset] [Value]
NOTE [SAVE]
The Note utility has following main functions:
a) Let opers create news-like #head.channels listed with /list.
b) Let you send messages to users which they will get when they sign on.
Example: /note send nickname Hi, this is a note to you.
c) Let you spy on people to see when they sign/off, change nick etc.
Example: /note spy +100 !foo (spy on user with login foo for 100 days)
You may fill in none or any of the arguments listed above, including
* or ? at any place, as nick@*.edu, !username, ni?k!username etc...
NOTE <server> <COMMAND> sends request to <server> instead of local.
Note was developed by Jarle Lyngaas (jarlel@ii.uib.no)
Usage: NOTE [USER] [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg>
With USER you can queue a message in the server, and when the recipient
signs on/off IRC, change nick or join any channel, note checks for
valid messages. This works even if the sender is not on IRC. Read
NOTE FLAGS for more info.
Password can be up to ten characters long. You may specify password
using the &, % or $ character. & is equal to to $, except working much
better cause client use $ for other things...
The % character works like &, except it makes the queueing silent. It
also makes sense to use this without any following password.
If any request queued is equal to any previous except time and maxtime,
only maxtime is changed as specified. You then get "Joined" instead of
"Queued".
Read NOTE FLAGS for info about flag settings. Username can be specified
without @host. Do not use wildcards in username if you know what it
is, even if it's possible. Max time before the server automatically
remove the message from the queue, is specified with hours with a
'-' character first, or days if a '+' character is specified, as
-5 hours, or +10 days. Default maxtime is 7 days.
The received message is *directly* displayed on the screen, without the
need for a read or remove request.
NOTE USER &secret +WN +10 !jarlel@ii.uib.no Howdy!
- is an example of a message sent only to the specified recipient if
this person is an operator, and after receiving the message, the server
sends a note message back to sender to tell about the delivery.
NOTE USER +XR -5 Anybody <ctrl-G>
- is an example which makes the server to tell when Anybody signs
on/off irc, change nick etc. This process repeats for 5 hours.
NOTE USER +FL @*.edu *account*
- is an example which makes the server send a message back if any real-
name of any user matches *account*. Message is sent back as note from
server, or directly as a notice if sender is on IRC at this time.
Usage: NOTE [COUNT] [&passwd] [+-flags] <nick!username@host>
Displays the number of messages sent from your nick and username. Read
NOTE LS for more info. Read NOTE FLAG for more info about flag setting.
Usage: NOTE [FIND] [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg>
FIND is an alias for USER +FLR (default max 1 day)
This command makes the server search for any matching recipient, and
send a note message back if this is found. If <msg> field is used, this
should specify the realname of the person to be searched for.
Example: FIND -4 foo*!username@host
FIND @host Internet*
FIND nicky Annie*
FIND +7 * Annie*
Usage: NOTE [FLAG] [&passwd] [+-flags] <nick!username@host> <+-flags>
You can add or delete as many flags as you wish with +/-<flag>.
+ switch the flag on, and - switch it off. Example: -S+RL
Following flags with its default set specified first are available:
-S > News flag for subscribing.
-M > Request is removed after you sign off.
-Q > Ignore request if recipient's first nick is equal to username.
-I > Ignore request if recipient is not on same server as request.
-W > Ignore request if recipient is not an operator.
-Y > Ignore request if sender is not on IRC.
-N > Let server send a note to you if message is delivered.
-R > Repeat processing the request until timeout.
-F > Let server send note info for matching recipient(s). Any message
part specify what to match with the realname of the recipient.
-L > Head channel flag.
-P > Password set for head channel.
-D > Z or L flag requests are queued on other servers for one week.
-C > Make sender's nicks be valid in all cases username@host is valid.
-V > Make sender's "nick*" be valid in all cases username@host is valid.
-X > Let server display if recipient signs on/off IRC or change
nickname. Any message specified is returned to sender.
-A > Show what server matching user is on using X flag.
-J > Show what channel matching user is on using X flag.
-U > Do not display nick-change using X flag.
-E > Ignore request if nick, name and host matches the message text
starting with any number of this format: 'nick!name@host nick!... '
-B > Send a message to every account who match the nick!user@host
This creates a received list with flag H set. (Read LS +h)
-T > Send a message not all nicks on same accounts too using B flag.
-K > Give keys to unlock privileged flags by setting that flags on.
The recipient does also get privileges to queue unlimited
numer of requests, list privileged flags and see all stats.
-Z > Make it impossible for recipient to join head chn, or queue notes.
Other flags which are only displayed but can't be set by user:
-O > Request is queued by an operator.
-G > Notice message is generated by server.
-B > Broadcasting message.
-H > Flag list for who's received Broadcast message (B flag).
Notice: Message is not sent to recip. using F, L, R, X, K, Z or H
flag (except if B flag is set for R). For this flags, no msg. needed.
Example: FLAG * +cj : Switch on c and j flag for all requests.
FLAG +x * +c : Switch on c flag for all req. which have x flag.
FLAG nick -c+j : Switch off c flag and which on j flag for nick
Usage: NOTE [LOG] [&passwd] [+-flags] <nick!username@host>
Displays how long time since matching person was on IRC. This works
only after use of NOTE SPY. The log is protected to be seen for other
users than the person who queued the SPY request. To get short
output, do not specify any arguments.
Example: LOG : Print short log of all
LOG * : Print long log including real names of all
LOG nick : Print long log for user nick.
Usage: NOTE [LS] [&passwd] [+-flags] <nick!username@host> [date]
Displays requests you have queued. No arguments would show you
all requests without the message field.
Use flags for matching all messages which have the specified flags set
on or off. Read NOTE FLAG for more info about flag settings. Time
can be specified on the form day.month.year or only day, or day/month,
and separated with one of the three '.,/' characters. You can also
specify -n for n days ago. Examples: 1.jan-90, 1/1.90, 3, 3/5, 3.may.
If only '-' and no number is specified max time is set to all days.
The time specified is always the local time on your system.
Example: LS !user would show you all requests to username@*
LS +x would show all your SPY requests.
LS 300 would show you only request numbered 300.
Usage: NOTE [XLS] [&passwd] [+-flags] <nick!username@host> [date]
Displays requests with channel flag L or deny flag Z set independent of
which person who queued the requests.
Usage: NOTE [NEWS] [&passwd] [+-flags] [+-maxtime] <group!username@host>
NEWS with no message is an alias for USER +RS (default max 60 days)
This command is for subscribing on a specified newsgroup from any
user(s) or host(s). Wildcards may be used anywhere.
Example: NEWS irc.talk : Subscribe on irc.talk
NEWS irc.talk@*.no Hello : Send Hello to group irc.talk, but only
for users at host *.no
NEWS admin.users@*.no Hi : Send Hi to all users using note in
your server located at host *.no.
Advanced users may use USER +RS <...> <filter> where filter is a
string which must matches with field in received news message.
Only opers may send to grups matching admin.* as admin.note.
To send news add message and use same format as subscribing, except
that username field must matches with subscribed group as alt.irc!*.irc -
everybody subscribing on a*.irc or *.irc or alt.irc... would get the news.
A speciall case is the group admin.users which everybody using NOTE in the
server are member of.
Usage: NOTE [RM] [&passwd] [+-flags] <nick!username@host>
Deletes any messages sent from your nick and username which matches
with nick and username@host. Use flags for matching all messages which
have the specified flags set on or off. Read NOTE FLAG for more info
about flag settings, and NOTE LS for info about time.
Usage: NOTE [XRM] [&passwd] [+-flags] <nick!username@host> [date]
Remove requests with channel flag L (except combination of G and P flag
if not oper on the server) or deny flag Z - independent of which person
who queued the requests. Be very careful using this! The owner of the
request you removed is notified if Z flag was set.
Usage: NOTE [SEND] [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg>
SEND is an alias for USER +N (default max 60 days)
This command is for sending a message to recipient, and let the server
send a note + a notice to sender if this is on IRC - if message is sent.
Example: SEND foobar Hello, this is a test.
SEND +7 !username@*.edu Hello again!
Usage: NOTE [CHANNEL] [&passwd][+-flags][+-maxtime] <#chn!username@host><topic>
CHANNEL is an alias for USER +LR (default max 365 days)
This command creates a head channel which must include at least one dot "."
Any user can join this or make their own tail channel: #head.chn-tail where
tail can be anything. Channels matching all users should ALWAYS have the
same name as a newsgroup with NO EXCEPTIONS.
If you add P flag, the server send password for all such channels in E-mail
if you try do /join #chn <E-mail@addy>. Then you can do /join #chn pwd.
If you don't get the Email, check out EPATH in config.h.
D flag makes the request to be distributed to all servers with name
matching @host in request. Be sure that topic is at least 10 characters.
The request on other server will live one week, and may get back to you
during this time if you remove the root request which is the first one
you queue. The principle is that if your server stop distributing
the request, some other server starts distributing it for you rest of
the week. On the other hand your server will distribute and update the
channel on other servers, so they won't reach the timeout limit.
Example: CHANNEL #comp.unix.misc Miscellaneous unix topics (open for all)
CHANNEL +p #comp.unix.misc Miscellaneous unix topics (password)
CHANNEL #no.norway@*.no Norwegians only!
CHANNEL +7 +p #no.unix@*.no Norwegian one week lasting protected.
CHANNEL +7 +p #no.unix@*.no Norwegian one week lasting protected.
CHANNEL +d #unix@*.edu Queued on all .edu servers for a week.
Usage: NOTE [SENT] [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM]
Displays host and time for messages which are queued without specifying
any password. If no option is specified SENT displays host/time for
messages sent from your nick and username.
NAME displays host/time for messages sent from your username
COUNT displays number of messages sent from your username
USERS Displays the number of messages in [], and names for all users
who have queued any message which matches with spec. nick/name/host.
RM means that the server removes the messages from the specified user.
Usage: NOTE [SPY] [&passwd] [+-flags] [+-maxtime] <nick!username@host> [msg]
SPY is an alias for USER +RX (default 1 max day)
SPY makes the server tell you if any matching recipient sign(s)
on/off IRC or change nick name. No message needs to be specified.
However, if a message is specified this is returned to sender including
with the message about recipient. Message could for example be one or
more Ctrl-G characters to activate the bell on senders machine.
As an alternative for using C flag, <msg> field could start with
any number of nicks on this format: %nick1 %nick2... %nickn, with
no space between % and the nick name you use. Spy messages would be
valid for any of the nicks specified.
SPY with no argument would tell you what users you have spy on who are
currently on IRC. The system logs last time the last matching person was
on IRC for each SPY request is queued in the server. Read NOTE LOG for this.
You may use flag +A to see what server matching user is on,
and/or +J flag to see what channel. (Read NOTE USER for more).
Example: SPY foobar!username@host <ctrl-G>
SPY +10 foobar
SPY +aj &secret * <ctrl-G>
SPY +365 +e !user nick!*@* <ctrl-G>
SPY % +7 foo!user
SPY +5 nicky %mynick %meenick
Usage: NOTE [STATS] [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value]
STATS with no option displays the values of the following variables:
MSM: Max number of server messages.
MSW: Max number of server messages with username-wildcards.
MUM: Max number of user messages.
MUW: Max number of user messages with username-wildcards.
MST: Max server time.
MSF: Note save frequency (checks for save only when an user register)
Only one of this variables are displayed if specified.
You can change any of the stats by specifying new value after it.
RESET sets the stats to the same values which is set when starting the
server daemon if no note file exist. Notice that this stats are saved
in same file as the other messages.
Usage: NOTE [WAITFOR [&pwd] [+-flags] [+-maxtime] <nick!username@host> [msg]
WAITFOR is an alias for USER +YD (default max 1 day)
Default message is; [Waiting]
This command is for telling the recipient if this appears on IRC that
you are waiting for him/her and notice that this got that message.
Example: WAITFOR foobar
WAITFOR -2 foobar!username@*
WAITFOR foobar Waiting for you until pm3:00..
Usage: NOTE [WALL] [&passwd] [+-flags] [+-maxtime] <nick!user@host> <msg>
WALL is an alias for USER +BR (default max 1 day)
This command is for sending a message once to every matching user
on IRC. Be careful using this command. WALL creates a list of
persons received the message (and should not have it once more time)
with H flag set. This list can be displayed using ls +h from the
nick and username@host which the WALL request is queued from.
Removing the headers (H) before WALL request is removed would cause
the message to be sent once more to what users specified in list.
WALL +7 @*.edu Do not do this! - Makes it clear for all users using
IRC on host @*.edu the next 7 days how stupid it is to send such WALL's ;)
Usage: NOTE [WALLOPS] [&passwd] [+-flags] [+-maxtime] <nick!user@host> <msg>
WALLOPS is an alias for USER +BRW (default max 1 day)
This command is same as WALL, except only opers could receive it.
Usage: NOTE [server] ANTIWALL
Switch off b flag for wall's which you have received on specified
server. The person who queued the wall is notified by the server
about the antiwall, and who requested this.
Usage: NOTE [DENY] [&passwd] [+-flags] [+-maxtime] <nick!user@host> <msg>
DENY is an alias for USER +RZ (default max 1 day)
This command makes it impossible for any matching recipient to
queue any Note requests until timeout. Read NOTE CHANNEL about D
flag settings. Warning: D flag distributes DENY to all other servers
independent of @host. If you use this flag, and want to remove it
again, you have to remove what you queued (the root), and wait a
week until it timeout on other servers, or you may try reach all
servers by doing NOTE *.* XRM nick!username@host
Usage: NOTE [KEY] [&passwd] [+-flags] [+-maxtime] <nick!user@host>
KEY is an alias for USER +KR (default max 1 day)
This command is for allowing no-opers to use oper-options by specifying
the flag to unlock. Be careful with this option!
Example: KEY +365 +s * would make it possible for everybody to use s flag.
Usage: NOTE SERVICE <nick> <note command>
Usefull in robots. Note will take the requests as if from <nick>
Usage: NOTE [SAVE]
SAVE saves all messages with the save flag set. Notice that the
messages are automatically saved (Read NOTE STATS). Each time server is
restarted, the save file is read and messages are restored. If no users
are connected to this server when saving, the ID number for each
message is renumbered.

242
doc/Operators Normal file
View File

@@ -0,0 +1,242 @@
Internet Relay Chat Operator Etiquette Guide
May, 1992
Welcome! You've either been selected to be an IRC Operator or you have set
up your server and thus have taken on the dual task of IRC Server
Administrator and IRC Operator. Your future days will be filled with hours
of fun chatting on IRC, and then wondering why everyone you talked to went
away, because the links had apparently broken.
Linking:
========
You will be assigned links from the IRC Routing Coordinators. Please
use these links and these links ONLY. The links have been designed to
maximize efficiency and make delays in chatting minimal. You will
usually be given two links, one to each regional backbone site.
Connect to the primary site first and then to the secondary site. You
should not need to connect to any other sites. You will be informed if
this policy changes.
Kills
=====
/kill is a special operator command. You should use it with
care, and only if absolutely needed. The format is as follows:
/kill NICKNAME comment. Comment can be a phrase of almost any length
(within reason) and should be used for specifying the reason of the kill.
Example: /kill Trillian She's a Ghost
IRC Ghosts are created after a net split has occured and the net has yet to
relink.
/wallops PHRASE This is used to talk to those users who have their
user mode set to +w. /wallops used to be a way for operators to talk
about important matters in linking etc., but it has little use
nowadays.
/TRACE command /TRACE is useful to know what servers are connected to
what. Sometimes /trace can be confusing, especially if you are using
it for the first time. Here is an example of a trace from
stekt1.oulu.fi to cdc835.cdc.polimi.it.
/TRACE cdc835.cdc.polimi.it
*** Link stekt1.oulu.fi<2.7.2> ==> cdc835.cdc.polimi.it
*** Link rieska.oulu.fi<2.7.1>e ==> cdc835.cdc.polimi.it
*** Link nic.funet.fi<2.7.1>e ==> cdc835.cdc.polimi.it
*** Link ircserver.et.tudelft.nl<2.7.1>e ==> cdc835.cdc.polimi.it
*** Link vesuv.unisg.ch<2.7.1>e ==> cdc835.cdc.polimi.it
*** Link apollo.di.unipi.it<2.7.1>e ==> cdc835.cdc.polimi.it
*** Oper Class[10] ==> Allanon[cdc835.cdc.polimi.it]
*** User Class[11] ==> Lupandy[plus2.usr.dsi.unimi.it]
*** Serv Class[3] ==> apollo.di.unipi.it[131.114.4.36] 132S 445C
*** User Class[11] ==> Punk[pluto.sm.dsi.unimi.it]
*** User Class[11] ==> TheEdge[pluto.sm.dsi.unimi.it]
*** User Class[10] ==> Mork[cdc835.cdc.polimi.it]
*** User Class[11] ==> Lollo[c700-2.sm.dsi.unimi.it]
*** User Class[11] ==> Attila[hp2.sm.dsi.unimi.it]
*** Class 0 Entries linked 1
*** Class 11 Entries linked 5
*** Class 10 Entries linked 2
*** Class 3 Entries linked 1
From this output you can see that the route goes first to
rieska.oulu.fi (running version 2.7.1e), then nic.funet.fi,
ircserver.et.tudelft.nl, vesuv.unisg.ch, and apollo.di.unipi.it, after
which cdc835 is the next server. Then we see the connections on
cdc835: One operator (Allanon) and 6 users are on line. The class of
each connection is given. There is only one server connected to cdc835
at the moment, and that server is apollo.di.unipi.it (cdc835 is said
to be a "leaf" server at the moment). The numbers 132S 445C in the end
of line tell us, that there are 132 servers and 445 clients connected
to the servers from apollo onwards. Finally we see a grand total of
connections in each connection class.
/SQUIT server {comment}
/squit isolates a specified server from the next closest server, when
you look at it along the trace path starting from your server.
This is usually used in conjunction with CONNECT (explained later) to
reroute traffic. This will be described in detail in the section
"routing", preceding CONNECT.
Usage (and examples):
/squit E
If the network looks like this initially (and you are on server A)
A <---> B <---> C <---> D
^
|
v
G <---> E <---> F <---> ... (rest of the net)
Then after issuing the previous /squit the network would look like this:
A <---> B <---> C <---> D
G <---> E <---> F <---> ...
/squit E {comment}
It usually helps to give a reason why you are sending a
SQUIT for a server. This can be accomplished by sending
the command "/squit server This link is making the US route
through Finland". The SQUIT will then be sent out, and the
server sending the squit will WALLOP sending the comment
so all operators can see it.
/CONNECT server {portnum server2}
/connect is used to establish a link between two servers. These
connections must be authorized by each server's ircd.conf file, but
any operator can issue a CONNECT between authorized servers. This
command is most often used in conjunction with SQUIT to reroute
traffic.
If only one argument is given, this command causes the server you
are on to attempt to connect to the server specified. For example,
"/connect B" (in the previous example) would cause your server (A) to
connect to B.
Suppose you wanted to reconnect server F to server E? You cannot
contact server F since it is no longer part of your network. However,
you can tell server E to connect to it. A remote CONNECT can be issued
to server E.
Examples (assume you are on server A):
/connect B
If the network initially looks like this:
A B <---> ... (rest of network)
Then afterwards (if the connection succeeds) the network will look
like this:
A <---> B <---> ...
In the example where you wanted to reconnect server E to F, the
following syntax would be appropriate (note: we are assuming that
F's irc socket port is 6667, which is the default)
/connect F 6667 E
If the network initially looks like this:
A <---> B <---> C <---> D
^
|
v
G <---> E F <---> ...
Then after your CONNECT request the network topology will look like this:
A <---> B <---> C <---> D
^
|
v
G <---> E <---> F <---> ...
Be careful when connecting servers that you know which command to
use! If you simply issued "/connect F" from your server, the
network would look like this:
... <---> F <---> A <---> B <---> C <---> D
^
|
v
G <---> E
which for various reasons (discussed below) might be very
undesirable.
Routing
=======
When and how should you do rerouting? This depends on where your
server is topologically located and whether you route traffic. If you
are a leaf node (i.e. only connect to one server at a time) then
chances are you won't need to do any routing at all. Your ircd.conf
file should be written to connect to the best possible servers first
before trying alternates. At the most, you may decide to squit an
alternate server and connect to your primary if/when it goes back up.
This only involves local squits, however.
If you are operating a backbone site, you may find yourself
rerouting things quite often. If the servers badger.ugcs.caltech.edu
(Pasadena, CA), irc.mit.edu (Boston, MA), minnie.cc.utexas.edu
(Austin, TX) and ucsu.colorado.edu (Boulder, CO) were routing traffic
in the following way:
... <---> minnie <---> badger <---> bucsd <---> ucsu <---> ...
It would make sense to either squit ucsu and reconnect it to minnie,
or disconnect minnie from badger and connect to ucsu, because
topologically (and geographically) ucsu and minnie are rather close.
There are occasions when US traffic for some reasons winds up being
routed through Australia. This is another case where traffic should
definitely be rerouted. However, there are sometimes occasions when
routing is going through "backdoor" methods. If you see something
totally outrageous (like the east coast and the west coast being
connected by eff.org) please ask for example on channel #twilight_zone
before you send any squits, because chances are, it's like that for a
reason.
Of course, any operator can remotely squit or connect servers, so
if you see a problem and you're sure you know how to fix it, it's a
good idea to do so. If the operator of a server which is is being
routed poorly is online, it's probably best to contact him/her first,
though.
Chances are that hub operators will be more familiar with the
general topology of the network and which servers connect to which
(which is why most of the manual routing is left to them), so if you
have any problems, talk to the other operators on operator channels
(#twilight_zone, #eu-opers etc.) That's what they are there for!
Also, be aware that servers will notify all the operators online of
remote SQUITs and CONNECTs via WALLOPS.
Please let us know if there should be any additions to this guide. Again,
this is not MANDATORY, this is just a GUIDE. Please conduct yourself as
an IRC Operator would...you are looked upon for assistance, both emotional
and mental.
Helen Rose Christopher Davis Noah Friedman
<hrose@cs.bu.edu> <ckd@cs.bu.edu> <friedman@ai.mit.edu>
January, 1991
Updated by
Mauri Haikola
<mjh@stekt.oulu.fi>
May, 1992

1901
doc/README.patches Normal file
View File

File diff suppressed because it is too large Load Diff

156
doc/US-Admin/Networking Normal file
View File

@@ -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

253
doc/US-Admin/Operators Normal file
View File

@@ -0,0 +1,253 @@
Internet Relay Chat Operator Etiquette Guide
January, 1991
Welcome! You've either been selected to be an IRC Operator or you have set
up your server and thus have taken on the dual task of IRC Server
Administrator and IRC Operator. Your future days will be filled with hours
of fun chatting on IRC, and then wondering why everyone you talked to went
away, because the links had apparently broken.
Linking:
========
You will be assigned links from the IRC Routing Coordinators. Please use
these links and these links ONLY. The links have been designed to maximize
efficiency and make delays in chatting minimal. You will be given two
links, one to each regional backbone site. Connect to the primary site
first and then to the secondary site. You should not need to connect to any
other sites. You will be informed if this policy changes.
Kills and Walls:
===============
/kill and /wall are special operator commands. You should use them with
care, and only if absolutely needed. The format are as follows:
/kill USERNAME comment. comment can be a phrase of almost any length
(within reason) and should be used for specifying the reason of the kill.
example: /kill Trillian She's a Ghost
IRC Ghosts are created after a net split has occured and the net has yet to
relink.
/wall PHRASE. This is used for an emergency command like the net is about
to split into little pieces, and everyone should reconfigure their links
as soon as possible. You will see a WALL when it happens, an operators
nickname will appear with # signs around it.
#Trillian# Server bucsd.bu.edu coming down for upgrade. Prepare to
reconfigure links.
/wallops PHRASE This is used to talk to ALL operators at once. It is not
often warranted, but is useful. Often, when there is an important IRC
situation that requires all the operators attention, /wallops is used. The
form for wallops is a nickname with ! signs around it.
!Trillian! Australia should leaf off of eris, not carry all the US traffic.
/TRACE command
/TRACE is useful to know what servers are connected to what. Sometimes
/trace can be confusing, especially you are using it for the first time.
Here is an example of a trace from bucsd.bu.edu to betwixt.cs.caltech.edu.
/TRACE betwixt.cs.caltech.edu
IRC log started Mon Aug 26 17:04
*** Link eff.org<2.6.1a> ==> h.ece.uiuc.edu
-bucsd.bu.edu- *** Link bucsd.bu.edu<2.6.1a> ==> h.ece.uiuc.edu
-h.ece.uiuc.edu- *** Serv Class[3] h.ece.uiuc.edu ==> ucsu.colorado.EDU
-h.ece.uiuc.edu- *** Serv Class[2] h.ece.uiuc.edu ==> bucsd.bu.edu
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> silver.ucs.indiana.edu
-h.ece.uiuc.edu- *** Serv Class[11] h.ece.uiuc.edu ==> monitor.ece.uiuc.edu[h.ece.uiuc.edu]
-h.ece.uiuc.edu- *** User Class[0] h.ece.uiuc.edu ==> Razorbone[uxa.cso.uiuc.edu]
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> MHD54.MOORHEAD.MSUS.EDU[134.29.97.1]
-h.ece.uiuc.edu- *** Serv Class[4] h.ece.uiuc.edu ==> *.umich.edu[mingin.engin.umich.edu]
-h.ece.uiuc.edu- *** User Class[0] h.ece.uiuc.edu ==> BooServ[sunc4.cs.uiuc.edu]
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> nic.stolaf.edu
-h.ece.uiuc.edu- *** Oper Class[0] h.ece.uiuc.edu ==> SodaPop[h.ece.uiuc.edu]
-h.ece.uiuc.edu- *** Serv Class[4] h.ece.uiuc.edu ==> oddjob.uchicago.edu
-h.ece.uiuc.edu- *** User Class[0] h.ece.uiuc.edu ==> Deviant[isca01.isca.uiowa.edu]
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> *.uc.edu[hilbert.che.uc.edu]
-h.ece.uiuc.edu- *** Class 0 Entries linked: 4
-h.ece.uiuc.edu- *** Class 11 Entries linked: 1
-h.ece.uiuc.edu- *** Class 10 Entries linked: 4
-h.ece.uiuc.edu- *** Class 4 Entries linked: 2
-h.ece.uiuc.edu- *** Class 3 Entries linked: 1
-h.ece.uiuc.edu- *** Class 2 Entries linked: 1
This shows that from eff.org (running version 2.6.1a to h.ece.uiuc.edu,
routing goes through bucsd.bu.edu before reaching h.ece.uiuc.edu.
"h" is connected to ucsu.colorado.edu, silver.ucs.indiana.edu,
monitor.ece.uiuc.edu (which resolves to [h.ece.uiuc.edu], hence the
square brackets), mhd54.moorhead.msus.edu, *.umich.edu (which resolves
to mingin.engin.umich.edu), nic.stolaf.edu, oddjob.uchicago.edu,
*.uc.edu (which resolves to hilbert.che.uc.edu), and bucsd.bu.edu, which
is known as its "uplink". It is quite normal for a server to have
several "uplinks" if it is busy. An uplink is the link towards the top
of the tree which carries alot of traffic. "h" also has several users on
it, RazorBone, BooServ, and Deviant. SodaPop is also an active operator
on h.ece.uiuc.edu. You can tell each host from what each person is
logged into by looking just past their nickname. For example, Deviant is
logged in from isca01.isca.uiowa.edu.
/SQUIT server {comment}
/squit isolates a specified link from the next closest uplink server.
This is usually used in conjunction with CONNECT (explained later) to
reroute traffic. This will be described in detail in the section
"routing", preceding CONNECT.
SQUIT can be used in one of two ways. It can be used on a local
server, which would cause the server name specified to be unlinked
relative to your path; or you can send a message to another server
instructing it to issue an SQUIT to that server, in which case the
break will be relative to the remote server.
Usage (and examples):
/squit E
If the network looks like this initially (and you are on server A)
A <---> B <---> C <---> D
^
|
v
G <---> E <---> F <---> ... (rest of the net)
Then after issuing the previous /squit the network would look like this:
A <---> B <---> C <---> D
G <---> E <---> F <---> ...
/squit E {comment}
It usually helps to give a reason why you are sending a
SQUIT for a server. This can be accomplished by sending
the command "/squit server This link is making the US route
through Finland". The SQUIT will then be sent out, and the
server sending the squit will WALLOP sending the comment
so all operators can see it.
/CONNECT server {portnum server2}
/connect is used to establish a link between two servers. These
connections must be authorized by each server's ircd.conf file, but
any operator can issue a CONNECT between authorized servers. This
command is most often used in conjunction with SQUIT to reroute
traffic.
If only one argument is given, this command causes the server you
are on to attempt to connect to the server specified. For example,
"/connect B" (in the previous example) would cause your server (A) to
connect to B.
Suppose you wanted to reconnect server F to server E? You cannot
contact server F since it is no longer part of your network. However,
you can tell server E to connect to it. A remote CONNECT can be issued
to server E.
Examples (assume you are on server A):
/connect B
If the network initially looks like this:
A B <---> ... (rest of network)
Then afterwards (if the connection succeeds) the network will look
like this:
A <---> B <---> ...
In the example where you wanted to reconnect server E to F, the
following syntax would be appropriate (note: we are assuming that
F's irc socket port is 6667, which is the default)
/connect F 6667 E
If the network initially looks like this:
A <---> B <---> C <---> D
^
|
v
G <---> E F <---> ...
Then after your CONNECT request the network topology will look like this:
A <---> B <---> C <---> D
^
|
v
G <---> E <---> F <---> ...
Be careful when connecting servers that you know which command to
use! If you simply issued "/connect F" from your server, the
network would look like this:
... <---> F <---> A <---> B <---> C <---> D
^
|
v
G <---> E
which for various reasons (discussed below) might be very
undesirable.
Routing
=======
When and how should you do rerouting? This depends on where your
server is topologically located and whether you route traffic. If you
are a leaf node (i.e. only connect to one server at a time) then
chances are you won't need to do any routing at all. Your ircd.conf
file should be written to connect to the best possible servers first
before trying alternates. At the most, you may decide to squit an
alternate server and connect to your primary if/when it goes back up.
This only involves local squits, however.
If you are operating a backbone site, you may find yourself
rerouting things quite often. If the EFnet servers (see the file
doc/networking) badger.ugcs.caltech.edu (Pasadena, CA),
irc.mit.edu (Boston, MA), minnie.cc.utexas.edu (Austin, TX) and
ucsu.colorado.edu (Boulder, CO) were routing traffic in the following way:
... <---> minnie <---> badger <---> bucsd <---> ucsu <---> ...
It would make sense to either squit ucsu and reconnect it to minnie,
or disconnect minnie from badger and connect to ucsu, because
topologically (and geographically) ucsu and minnie are rather close.
There are occasions when US traffic for some reasons winds up being
routed through Australia. This is another case where traffic should
definitely be rerouted. However, there are sometimes occasions when
routing is going through "backdoor" methods. If you see something
totally outrageous (like the east coast and the west coast being
connected by eff.org) please /WALLOPS and ask before you send any
squits, because chances are, it's like that for a reason.
Of course, any operator can remotely squit or connect servers, so
if you see a problem and you're sure you know how to fix it, it's a
good idea to do so. If the operator of a server which is is being
routed poorly is online, it's probably best to contact him/her first,
though.
Chances are that hub operators will be more familiar with the
general topology of the network and which servers connect to which
(which is why most of the manual routing is left to them), so if you
have any problems, talk to the other operators via /wallops. That's
what it's there for!
Also, be aware that servers will notify all the operators online of
remote SQUITs and CONNECTs via WALLOPS.
Please let us know if there should be any additions to this guide. Again,
this is not MANDATORY, this is just a GUIDE. Please conduct yourself as
an IRC Operator would...you are looked upon for assistance, both emotional
and mental.
Helen Rose Christopher Davis
<hrose@cs.bu.edu> <ckd@cs.bu.edu>
Noah Friedman
<friedman@ai.mit.edu>
January, 1991

332
doc/example.conf Normal file
View File

@@ -0,0 +1,332 @@
# IRC - Internet Relay Chat, doc/example.conf
# Copyright (C) 1994, Helen Rose
#
# 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
#
# 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.
#
# MANDATORY lines are absolute *musts*, that is, if you do not have this
# line then your server will not work properly. SUGGESTED lines are
# close-to-mandatory (that is, the server will run without it, but you are
# highly encouraged to use these lines).
#
# Note that "*" in a field indicates an "unused" field.
#
#
# ========================================================================
# 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 number. Fields, in order, are:
#
# M:hostname:*:Description Of Your Server:6667
#
M:csa.bu.edu:*: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.
#
# The A: line has no set information, in fact, you can put arbitrary text
# in there if you wish (it is encouraged that you put at *least* a contact
# address for a person responsible for the irc server, however)
#
A:Boston University CS Department:Main Client Server:Helen Rose <hrose@cs.bu.edu>
#
# Y: [SUGGESTED]. These lines define connection classes. Connection
# classes allow you to fine-tune your client and server connections. It is
# suggested that clients and servers be placed in seperate classes, 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.
#
# 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.
#
# The fields in order are: class number, ping frequency (in seconds),
# connect frequency (in seconds), maximum number of links (used for
# auto-connecting, and for limiting the number of clients in that class),
# and sendq (this overrides any value set in include/config.h for #define
# MAXSENDQLENGTH).
#
# Note that it is a good idea to have ping frequency the same at both ends
# of the link.
#
# in this case, connect-frequency is 0 indicating that this is a client
# class (servers never connect to clients, it is the other way around).
Y:1:90:0:20:100000
#
# this is a normal server connection (normal as of March, 1994)
Y:2:90:300:1:600000
#
Y:10:90:0:3:100000
#
# 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 permitted (clients can
# be configured to send passwords).
#
# Ident (for more information on this, see rfc1413) can also be used by
# placing a @ in the appropriate fields.
#
# Fields are as follows:
# I:IP-address-mask:optional password:domain-mask::connection class (opt)
#
# With a password..... This will allow anyone from anywhere to connect
# as long as they know the password ("foobar"). Note listing this I: line
# first, it will be read *last*, meaning it is the "fall-through". That
# is, anyone who doesn't match the I: lines listed below must know the
# password ("foobar") to connect.
#
I:*@*:foobar:*@*::1
# 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::1
#
# using ident
I:*@128.197.*::*@*.bu.edu::1
# and you can even specify just certain usernames running ident (as long
# as the client's site is running the ident daemon):
I:NOMATCH::hrose@csa.bu.edu::1
# putting NOMATCH in the first field will stop the ircd from matching
# automatically against the IP address and it will force the server to
# match against the hostname. (the "NOMATCH" string is not mandatory, you
# can use any arbitrary text in the first field).
#
#
# 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.
# The fields are as follows:
# O:hostname (ident "@" permitted):password:NickName
# 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 since Crypted Passwords are defined by default in
# include/config.h this text probably will not be plaintext. See
# ircd/crypt/README for more information.
#
O:*.bu.edu:Zaphod:Trillian::10
#
# and this line forces ident:
O:hrose@csa.bu.edu:Zaphod:Trillian::10
#
# This line is a "local operator", it is specified with a lower-case "o"
# -- it is the only lower-case type in the ircd.conf file.
#
# 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
#
# 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
# include/config.h
U:csa.bu.edu:foobar:csa.bu.edu
#
# C: [NETWORKED]. These lines define what servers your server tries to
# connect to.
# N: [NETWORKED]. These lines define what servers your server permits
# connections to be initiated from.
# C/N lines MUST be used in pairs. You cannot have one without the other.
#
# C: lines contain the following fields:
# C:remote server's hostname:passwd:remote server's name:port:conn class
# (connection class)
# N: lines contain the following fields:
# N:remote server's hostname:passwd:remote server's name:host mask:conn class
# (connection class)
# "host 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
#
# 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).
#
# the fields are defined as:
# K:hostmask:time field:username
# 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 ;-)
#
# This K: line bans the username "FSSPR" (the wildcards are used to make
# sure that any ident-checking character will match) on any machine from
# the University of Alaska.
K:*.alaska.edu::*FSSPR*
#
# 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):
K:acs*.bu.edu:0800-1200,1300-1700:*
# Note that 24 hour time is used (no "AM" or "PM").
#
# 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 include/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
#
# 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
#
# T: [OPTIONAL]. These lines allow you to specify different motd's for
# different types of clients. This could be used to give *.edu users
# some informational message, while giving *.cl users a pointer to a
# closer server.
#
# The fields are as follows:
# T:hostmask:pathname
# for example, to give *.edu users the MOTD file /usr/ircd/lib/edu.motd:
T:*.edu:/usr/ircd/lib/edu.motd
#
# P: [OPTIONAL]. This field allows the server to listen on various ports
# (other than 6667) for connections. Any internet domain port that is
# below 1024 means the ircd has to be run 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 include/config.h. If you are permitting connections to a
# seperate port, you can control access to that port by the host field.
#
# The fields are as follows::
# P:hostmask or UNIX socket file:*:*:port number
# for example, an internet domain socket on port 6665 for South African
# users:
P:*.za:*:*:6665
#
# This line is an example of a UNIX domain socket in /tmp
P:/tmp/.ircd:*:*:6666

478
doc/history/2.4.notes Normal file
View File

@@ -0,0 +1,478 @@
/************************************************************************
* IRC - Internet Relay Chat, 2.4.notes
* Copyright (C) 1990 Markku Savela
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 1, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
IRC 2.4 release notes 6 May 1990/msa (Markku.Savela@vtt.fi)
============================================================
This document explains the changes I have done up to this
point. Some additional changes and packaging has been made by
Chelsea (chelsea@earth.cchem.berkeley.edu). This is personal
view of the changes.
CHANGES TO LAST THE OFFICIAL RELEASE (2.2PL1)
This release of irc2.4 is based to 2.2PL1 release (see the
HISTORY chapter later in this document). Aside from fixing the
bugs, this version is in many ways different from the 2.2PL1.
The purpose of the most changes is to make it easier to run an
IRC server. Normal users benefit from these changes indirectly
by getting a better maintained server.
1. Changes visible to normal users
Even while mainly fixing bugs, some user visible changes have
crept in too.
1.1 General note on wildcards
Many commands accept now wildcard matching where applicable. All
compares are case insensitive (e.g. "a" == "A"). The wild cards are
? matches any single character
* matches any number of characters, also empty
string. [PL1 had a bug, which caused "*du*"
not match "....edu"].
1.2 Server supported wildcards for "/who mask" command.
Protocol message is "WHO mask", where mask can be
empty
0 List all users [No change from PL1]
* List all users on the same channel where the user is
(or all, if user is on 0) [No change from PL1].
number List all users on the specified channel [No change
from PL1]. Note, if the "mask" begings with a digit,
this form is assumed, and the remainder of mask is
ignored, e.g. "/who 12*.fi" gives all people from
channel 12 and ignores the "*.fi" part.
mask If the mask is any string, it will be compared
*separately* to each information field of the user
and if a match is found in any field, that user
is included into the list. The fields searched
are
nickname
loginname (account name)
real name (text shown in parenthesis)
hostname (users machine)
servername (server he/she is using)
Note: servername is not usually shown on WHO output,
but is included in anyway. Example: finding all users
somehow connected with Finnish sites, can be achieved
with mask "*.fi".
1.3 Changes to /whois command
As WHO, also /whois accepts wild cards as a parameters. WHOIS
returns information for all users whose nickname matches the specified
mask.
WHOIS automaticly calls WHOWAS [see below], if the attempted nickname
is not found.
1.4 Short term "WHOWAS" history
The server has a short in memory cache of the recent nickname changes
(the current default is set to 200 last changes). The design goal of
this is that it remembers changes in last few minutes, there is no
intention of this to be a long term history. That must be a separate
project, although it could use the hooks provided by this service.
"WHOWAS nickname" queries this cache and returns about the same
information that WHOIS would do, if the nickname is found. Wildcards
are not accepted here, this is a specifically designed feature. If
the name is not found, WHOWAS doesn't reply anything. This is because
the most useful use of WHOWAS is implicitly through "WHOIS".
This history is also implicitly utilized by KILL command.
1.5 New SERVER-SERVER/SERVER-CLIENT protocol message WALLOPS
The message ":source WALLOPS :Message" sends the message text
to all operators that are currently online. Any user can use this
command, it's not restricted. How this function is activated, depends
on the client, but if nothing else works, "/quote wallops text" should.
NOTE:This function will not be fully operational until *ALL*
servers have upgraded to version 2.4. Also, operators
must be using a client that recognizes this command.
This is really a hasty addition. But, done this way it follows
the general IRC message philosophy, where messages are sent only
to links where they are needed (e.g. WALLOPS goes only to servers
that have opers online--it's not broadcast to every server).
1.6 General use of wildcarding in server queries
All commands that previously took a servername as a parameter,
now accept also a wildcarded mask. The mask is replaced with
the first matching servername. The following user level commands
are affected
/admin server -- administrative info
/time server -- local time
/version server -- the server version
/motd server -- "the message of the day"
/info server -- info (usually same on same server version)
/stat f server -- statistics information
/users server -- users logged on server machine
Note: Remote capability is a new feature for "info" and "stat"
commands. Until all servers have upgraded, these commands may not
reach the intended target and may return the information from some
intermediate server.
1.7 Marking user AWAY
v2.2PL1 version and earlier showed the AWAY-state (G) only for
the local users of the same server. AWAY status could be queried
only by sending a message to a user. This release (or since msa.4)
broadcasts the away status to every server and the commands /WHO and
/WHOIS give this information reliably.
A side effect of this change is: when a user marks himself/herself
as AWAY, all pre-msa.4 servers that are reached will send back an
acknowlegde message. Until all servers are upgraged, use of AWAY
is somewhat inconvenient. If you get extra messages from AWAY,
they also contain the server information. Use /admin command and
send a *friendly* request for the admin to upgrage his/her server
to a working version, namely 2.4 :)
1.8 Servers don't restrict characters within messages
The parameter fields of the messages can now contain any characters
in range 1-255, except '\r', '\n' and '\0'. The client programs should
by default filter away the "dangerous" control characters, but intelligent
clients can utilize this change and allow exchanges with foreign
8-bit (or wider) charactersets. (The actual command parts must still be
represented with the ordinary 7-bit characters.)
2. Changes visible to the server administrator
2.1 Identifying servers
Servers/clients have now always two names (it was this way in
PL1, but I think this version makes the idea more clear):
Announced Name:
The official name of the server (the name you use in
/time, /quote connect, etc) or users nickname. Servers
name is usually the hostname, but can actually be almost
any string of characters resembling hostname. This one
is given in M-line of ircd.conf.
Socket hostname:
Socket hostname of the server or client. This is the hostname
of the connecting server/client and this is resolved from the
connection. If resolve cannot be done, ircd defaults to using
numeric IP-address. *ALL* access checks are based on this
name, especially noteworthy fact, if your resolver cannot find
hostnames by IP-address, you must allow the access by IP-numbers
in your ircd.conf.
In many places, where servers name is shown, actually both are
shown. The general format of the displayed name is
AnnouncedName[SocketHostName]
When a connection is yet unkown, there is no AnnouncedName, and if the
AnnouncedName is the same as SocketHostName, the "[..]"-part is omitted.
2.2 Many notices to local operators
If an oper is signed on the server, he/she will receive many
notices about exceptional conditions and servers actions. When
something goes wrong, it should be much easier to fix the problems.
Few often occurring, inportant error messages are
"Write error to SERVERNAME, closing link"
write() to socket returned with an error. Server is
closing the link. This means usually network problems
which you can do nothing about.
"Max buffering limit exceeded for SERVERNAME"
This is the situation where old server would have been
"frozen". The socket buffers in your OS have been filled and
even servers own predefined internal buffering MAX for a link
has been exceeded. Exceeding this limit most likely means
that the link is really dead, so the server closes the link
and scratches all queued output for it. If the limit is
set high ( > 20000 bytes), you won't usually see this, but
just "No responce from SERVERNAME, closing link" as the
server does not reply to PING as it should.
"Link SERVERNAME cancelled, server SERVERNAME already exits"
Two different servers from your net fragment attempted
to connect same other net fragment about the same time
and this collision is detected at your server. IRC routing
does not allow loops, the link causing the loop is closed.
(Which of the two links gets closed is mostly determined
by pure chance and timing--you may lose a better link this
way. Collisions should be rare in normal operation, if
the timers in "config.h" are not messed up too much...)
Of course, you get this too, if you try to connect to a
server that is already connected by some other route. In
that case your attempted connection is just safely cancelled.
The notices attempt to be self explaining.
2.3 Links statistics collecting
IRCD now counts the bytes and messages transmitted to each open
link. This information can be output with a command "/stats l"
("/stats" or "/stat m" will give the old message count statistics).
Sample output
Link SendQ SendM SendBytes RcveM RcveBytes Open since
oddjob.uchicago 0 203 8067 772 34321 Sun May 6 02:15:45 1990
cs.hut.fi[sauna 0 1916 79798 94 3082 Sun May 6 01:51:25 1990
otax.tky.hut.fi 0 3722 151511 426 22690 Sun May 6 00:25:54 1990
nada.kth.se 0 8775 355811 5333 223853 Sat May 5 14:11:49 1990
vehka.cs.uta.fi 0 23816 882000 901 41156 Fri May 4 22:50:23 1990
lut.fi 0 25145 943765 1068 35020 Fri May 4 22:34:16 1990
kreeta.helsinki 0 24286 899191 957 47085 Fri May 4 22:33:28 1990
naakka.tut.fi 0 27754 1067302 8288 362960 Fri May 4 22:33:14 1990
joyx.joensuu.fi 0 30003 1172949 2300 80053 Fri May 4 22:33:05 1990
tel4.tel.vtt.fi 04083771 167473890 863475 35022755 Mon Apr 23 00:15:17 1990
| | | | | |
| | | | | Link established
| | | | The number of bytes received
| | | The number protocol messages received
| | The number of bytes transmitted
| The number of protocol messages transmitted
The amount of queued data in bytes (if socket is hung)
The last row (with the local servername) contains the total
cumulative counts for all connections since the server was started.
One can query the statistics of a remote server by adding the servers
name to the command "/stat l servername". Of course, this only works,
if all intermediate servers have upgraged. The first "old" server
will stop the propagation and return the message counts by default.
2.4 Connecting servers
An oper can manually activate a connection phase to any server
defined in ircd.conf C-lines (to successfully complete the connection,
the N-line must be present too). The message achieving this is
CONNECT servername portnumber
where servername may be a mask string containing wildcards. This
name is matched against entries in ircd.conf (notice: the testing
is made in reverse order, e.g. the last C-line in ircd.conf is tested
first). If portnumber is omitted, the ircd uses the one given in the
found C-line. If the C-line does not have the portnumber, the compiled
default will be used (PORTNUM from config.h).
This release allows also for remote connecting. An oper can send
a connect request to remote server with
CONNECT servername portnumber remoteserver
This command is passed to the 'remoteserver' and it then tries to
execute it like it was given locally. (If there are opers online on
that server, they will get a notice about this happening.) Note, that
one can remotely connect only what is defined in ircd.conf. Usually
one needs and should use this only for immediate your neighbours. Nobody
should randomly go and give connect requests to distant servers, unless
one knows it's absolutely necessary and is very familiar about the
linking setup there.
2.4 Terminating connections
The SQUIT command in PL1 was not intended to be used manually and
was very dangerous to use (it also created so called "ghost servers").
Since msa.4, the SQUIT has been safer to use manually.
"SQUIT z" s a
\ /
\ /
------- x ------- y --| |-- z ------- b
/ ^ \
/ | \
p c
"SQUIT z" will break the link between "y" and "z" if injected
into system from "s". After that the net will be in two fragmets,
broken between "y" and "z". Server "z" never sees the actual
SQUIT, all it observers is that the link to "y" suddenly closes
(opers on z would see it as "Server y closed the connection"
notice. Opers on y would see it as "Received remote SQUIT from
x", note that the actual source "s" is not identified in the
current version--for reasons too complicated to be explained
here).
*WARNING* *WARNING* If the server "y" is still running pre-msa.4
(like PL1), don't *EVER* issue a SQUIT for its links (unless the
link is to a leaf node or verifiably a "ghost server").
Note, that when the link between "y" and "z" breaks, y will spit
out SQUIT's for "z", "a", "b" and "c" to "x". At same time "z"
is sending SQUIT's for "x", "s", "p", etc to "a", "b" and "c".
SQUIT is normally generated by servers automaticly, it's just
a later modification (msa.4) that allows an OPER to use this
same message to "simulate" a link break at certain point.
*IMPORTANT* If server "z" has configuration "C:y::y:6667", it
automaticly attempts to reconnect after a short delay (currently
10 seconds), but only *if* the connection has been up long enough
reliably (currently set to 10 minutes). If the thus formed link is
squit another time, it will not attempt to come back immeatedly.
This gives an oper time to reconfigure the links if that first
short delay is not enough.
As in all commands, also SQUIT accepts wildcards, but be careful to
give sufficient identification. SQUIT of wrong server is not nice...
2.5 KILL message
KILL will implicitly use the history database. If a KILL is
issued for a nick that has been changed to another, the server
will automaticly re-issue the kill with the new nickname, if
the change has happened recently (current value should be 90
seconds). If a "terrorist" is clearly distrupting channel by
bombarding it with garbage from negative channels and changing
nick all time, there is no need to consult the "WHOWAS" data
base, just use the nickname that was used to send the garbage
and ircd hunts the culprit down. When this change of target
happens, the oper issuing the kill is notified.
NOTE: With automatic, kill-proof-reconnecting clients, the
value of KILL is becoming insignificant...
2.6 Changing the server defaults from the command line
The servers activation command is now
ircd[ -f configfile][ -h servername][ -p portnumber][ -x debuglevel]
where parameters can be given in any order. If the "configfile"
is defined, it will override the default specified in the file
"config.h". If "servername" is defined, it will override the
one defined in the M-line on the configuration line. "portnumber"
will override the compiled default (from "config.h") or the
one from the M-line of the configuration file. The "debuglevel"
will determine the amout of logging the server does into a
log file that has been define in "config.h". The "debuglevel"
should never be defined for a server running normally, it can
quickly generate megabytes of trace. Usually needed only when
the server is incapable of starting properly at all, then one
run with "-x9" usually is enough to reveal the problem.
3. General cleaning up and commenting the code
This issue is controversial. My way of fixing bugs is not just
fix them, I also want to program defensively, make it difficult to
make new errors. Thus I have heavily reformatted and reorganized
those files that I have had to touch. Some functions have been
renamed intentionally to catch all uses of those functions [because
the functions semantics or calling sequences have been changed].
This release (2.4) will be the last IRC version I'm contributing
to. If you have any wishes or complains about the code or functioining
of IRC, use the source or ask whomever it happens to be the current
developer.
HISTORY
There have been many different versions of IRC and many of those
versions are still in use. The following attempt to bring some
clarification to the versions. This starts from 2.01.6, hopefully
no servers are running older versions...
...
...
2.01.6 A version from WiZ in summer 1989
...
2.01t6 A series of releases, which contained minor
2.01T6 adjustements and bug fixes to the base version.
2.01u6 Some of those fixes caused extra errors, of
2.01U6 this series versions 2.01U6 and 2.01v6 are at
2.01v6 least known to be rather stable.
2.1.0 Mike Bolotski created these versions from the sources
2.1.1 of 2.01U6, but unfortunale some devious bug crept in
and caused a lots of linking problems (the nasty "ghost
server problem" splintered the net constantly). These
versions must be deleted on sight :) [Autumn 1989]
2.2 This version is the 2.01v6 sources repackaged into
multiple directories by Mike again. Probably nobody
is running this base version, because is was promptly
followed by two patch releases [Autumn 1989]
2.2PL0 These two are the last major "official" releases
2.2PL1 and most of the servers upgraged to either of
these.
2.2msa Unfortunately 2.2PL1 version had a tendency to die
mysteriously very often. So, I started to look into the
code from March 1990 and that resulted a series of
patches to the 2.2PL1 server code, but finally
decided to release full server code releases of which
few have got wider distribution
2.2msa.4
Has most of the known PL1 bugs fixed and seems
to be very reliable. But once servers started
staying up, a new problem appeared: socket
buffers started getting full and servers tended
to freeze very often for long intervals.
2.3alpha
2.3 Is an attempt to make an official release from 2.2msa.4
code, but hassles with changed copyrights make this
version unacceptable. Besides, 2.3alpha or 2.2msa.4 are
now obsolete, old versions :)
2.2msa.x
To solve the freezing problems, the server code is changed
to use non-blocking sockets.
2.2msa.7
2.2msa.9
Are intermediate test versions, of which .9 seems
to have most of the problems solved.
2.2msa.10
Never released. This is slightly improved version
of msa.9, some new features.
2.4 Is a release which combines 2.2msa.10 and Chelsea's
modifications to the server. Also, this release has
once again reorganized the directories and makefiles.
-- msa (Markku.Savela@vtt.fi)

128
doc/history/2.7-New Normal file
View File

@@ -0,0 +1,128 @@
* WHOREPLY and NAMREPLY become numberics instead of strings.
* msa's patches to kick/mode to attempt to follow nick name changes
* spike's patches to get SUMMON to find last idle tty
* melazy's various DNS improvements.
* pjg's saber C check
* prefix changed for all server->client messages in which the origin
of the sender is a client to appear as follows:
nick!user@host
* TRACE output changed.
* # channel topics broadcast
* +-numeric channels removed from server
* numerics for TRACE output 201-209
* new switches for STATS: i,k,q,y
* numerics for stats output 211-219
* MODE changed to also operate on users
* deoper added as both mode and direct command. deoper sends out
":user OPER -" to other servers. (from Kaizzu)
* XTRA/VOICE/GRAPH removed.
* MODE +a scrapped.
* added custom ANSI-compatible ctype macros to ensure speed
* user modes i,w,s,o implemented as follows:
i - invisible. over rides any channel mode for those external
to your channel. you are invisible.
w - receive wallops
s - receive local service notices (errors, etc)
o - operator flag. (can not be set currently except using the
OPER command).
* MODE +b added to ban a user from a channel using "nick!user@host" as
the mask to match to the user. If the user matches the ban mask they
are not allowed in. MODE +b with no parameters returns the list of
ban masks currently in place. MODE +b <mask> and MODE -b <mask>
add/delete a ban mask respectively.
Thanks to HulkHogan (andy@lingua.cltr.uq.oz.au) for defining what
we needed here and the 'BlackBall' approach.
* Operator passwords may now be stored in the ircd.conf file as the
encrypted plaintext. Crypt(3) is used to generate the matching
plaintext from the OPER command. Thanks to the following people
for help with this:
Sean Batt (sean@coombs.anu.edu.au),
Andy. M. Jones (andy@lingua.cltr.uq.oz.au),
Nelson Minar (minar@reed.edu).
* Server now creates "ircd.pid" file when booted. Holds the current
pid of the server.
* Each O and I line in the ircd.conf file may be linked only a number
of times equal to or the max. links value for the class they belong
to.
* Server stores results of any successful DNS lookups for servers so
that future lookups are not needed. A rehash will wipe all previous
lookup results and cause the server to start over. The server will
attempt to lookup each hostname in a C/N line on booting. This may
cause a delay during starting the server.
* All functions should be of the form "function_name", macros of the
form "MacroName" and constants as CONSTANT.
* Services are now treated with some respect. A service is associated
with an S-line in the ircd.conf. A service must send a NICK/SERVICE
pair on connecting to achieve service status.
* JOIN/PART now accept a list of channels in the first parameter with
each separated by a ",". eg "JOIN #foo,#bar,#foobar"
* A hopcount for the distance to nicknames and servers has been
introduced (for better or worse). It is passed as the second
parameter to both NICK and SERVER.
WHO and LINKS both report the hopcount in the info field.
* Default for WALL and WALLOPS set "off"
* rearranged config.h
* ISON now returns nicknames with the actual case, i.e.
ISON wiz will answer WiZ
New into 2.7.1
* STATS u, r, z
u - uptime
r - CPU useage stats
z - counts and shows current memory useage
r & z are only available if DEBUGMODE is defined in config.h
* GETHOST which forces all reverse lookups of ip#'s to also match
when doing a forward lookup of the hostname returned.
* SENDQ_ALWAYS buffering policy for sending data over links.
(Server tries to buffer as much data as possible before attempting
a write).
New into 2.7.2
* NOTE (once again appears and in much better state)
* WHOWAS gives a list of known users of the nick in question
rather than just the most recent.
* Server can accept both server and client connections via a unix
domain socket. This provides greater security and reliability for
connections between the host and itself. (#define UNIXPORT)
* STATS C reports L-lines: New Numeric 241
* #define for showing all users the invisible count from LUSERS

71
doc/history/README-2.6 Normal file
View File

@@ -0,0 +1,71 @@
/************************************************************************
* IRC - Internet Relay Chat, README
* Copyright (C) 1990
*
* For the list of authors and their e-mail addresses, see
* file doc/AUTHORS
*
* 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.
*/
To install the new server, there is just a few changes to be made.
* General Comments
Tue Nov 13 12:43:46 1990 Armin Gruner <gruner@informatik.tu-muenchen.de>
(APOLLO: Be sure to have NEED_INET_NETOF, NEED_INET_ADDR and
NEED_INET_NTOA undefined.)
Mon Nov 26 20:10:37 1990 Armin Gruner <gruner@informatik.tu-muenchen.de>
Comment: I just found that compiling on our SUN SPARC with GCC produces
code that dumps core.. (that might not happen on your machine, try it,
we may have out-of-date libraries). See netnews gnu.gcc.bug for a dis-
cussion about the matter. It seems that gcc passes struct's in a
different manner.
* Server configuration
Edit the include/config.h to your hearts content, avoiding going
beyond the warning line, unless you are *absolute* sure you know
what you are doing.
If you happen to not take to this warning, you may end up with
a server that will not function properly and annoy not only you,
but users all around the world.
Old irc client can be found in this package and if you want to use it,
check Makefile in directory irc before compiling. There are other,
better irc clients in distribution and the client distributed with
this version is simply something to begin with if you don't happen
to have other clients available.
This version was brought to you by jto@tolsun.oulu.fi and send any
bug fixes and suggestions to me.
NOTE: This server does *NOT* have MAIL system installed by default.
The reason is that it doesn't work with many systems.
This version introduces you string channels, starting with
a plus (+) sign. The first person joining a string channel
claims it's ownership and after that is entitiled to use /mode
command. Ownerships can be given and taken away with
/mode <channel> +o <nickname> and /mode <channel> -o <nickname>
Other flags are: s - secret, p - private, l - limited, i - inviteonly.
m - moderated, n - no private messages to channel,
t - topic settable by operator only
New command /KICK <channel> <user> kicks a user off channel.
--Jarkko (jto@oulu.fi)

51
doc/history/history.pre24 Normal file
View File

@@ -0,0 +1,51 @@
/************************************************************************
* IRC - Internet Relay Chat, doc/HISTORY
* Copyright (C) 1990
*
* 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.
*/
HISTORY of Recent IRC Versions.
Previous version numbering schemes have caused some confusion, which this
document attempts to resolve.
The original test versions released by WiZ were numbered 2.01?6 where
the ? refers to a letter. The last known stable version was U6.
Version 2.1.0/1 was rewritten by Mike Bolotski from the U6 sources but
several bugs were introduced during the rewrite. After several weeks,
almost all servers backed up to U6. Version v6 contained comparatively
minor modifications from U6.
Version 2.2 consists of the v6 source repackaged into multiple directories,
and with modified documentation. From now on, the version number will
stay relatively constant. As minor changes and bug fixes are added, they
will be distributed in the form of context diffs, to be applied with the
'patch' command. Each bugfix will bump the patchlevel (PL) of the release
by 1. The PL is documented in the version.c file in the lib/misc directory.
Version 2.3 was unfortunate mistake containing copyright violations
so it was soon taken off distribution.
Version 2.4 contains *very* many bug fixes, enhancements, and "hooks" for
use in future releases. The source tree has been restructured, and the
Makefiles rewritten to be recursive and follow the new source tree layout.
Version 2.5 contains string channels and channel modes (as well as
channel operators). Also Wizible's MAIL system was included as an option.
Hopefully, whoever provides a fix will also update the respective
ChangeLogs to summarize the changes, as well as adding a description of
the bug to the BugList file.

82
doc/irc.1 Normal file
View File

@@ -0,0 +1,82 @@
.\" @(#)irc.1 2.6 7 Oct 90
.TH IRC 1 "7 October 1990"
.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>

140
doc/ircd.8 Normal file
View File

@@ -0,0 +1,140 @@
.\" @(#)ircd.8 2.0 (beta version) 29 Mar 1989
.TH IRCD 8 "29 March 1989"
.SH NAME
ircd \- The Internet Relay Chat Program Server
.SH SYNOPSIS
.hy 0
.IP \fBircd\fP
[-a] [-c] [-i] [-o] [-q] [-t] [-d directory]
[-f configfile] [-x debuglevel] [-h hostname] [-p portnum]
.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.
.SH OPTIONS
.TP
.B \-d directory
This option tells the server to change to that directory and use
that as a reference point when opening \fIircd.conf\fP and other startup
files.
.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 \-a
Instructs the server to automatically die off if it loses all it's clients.
.TP
.B \-t
Instructs the server to direct debugging output to standard output.
.TP
.B \-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
.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 \-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
.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 \-q
Using the -q 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 \-h hostname
Allows the user to manually set the server name at startup. The default
name is hostname.domainname.
.B \-p portname
Specifies the port where the daemon should start waiting for connections.
This overrides the default which is given at compile time.
.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 "ircs.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.
.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
"irc.conf"
.SH "SEE ALSO"
irc(1)
.SH BUGS
None... ;-) if somebody finds one, please inform author
.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.

47
doc/m4macros Normal file
View File

@@ -0,0 +1,47 @@
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.