9pfs/solanum-vs-hackint-and-charybdis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Ginormous docs cleanup.

Browse source 
Purge a lot of really old and obsolete documents, and merge some together
where possible. Lots of efnet docs and the old ircd-ratbox manpage (lol)
was purged.

Reorganise everything nice and neatly as possible. Things describing
features can be found in features/, and some more technical documents
were moved to techinical/.

Old credits file was consolidated into credits-past.txt, and a reference
was added to it in the credits.
This commit is contained in:
Elizabeth Myers 2016-03-05 22:37:42 -06:00
parent 4dbb75ee84
commit a5c46d31e4
42 changed files with 215 additions and 2439 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
CREDITS
View file

@ -16,7 +16,7 @@ in nick-alphabetical order:
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
anfl, Lee Hardy <lee -at- leeh.co.uk>
beu, Elfyn McBratney <elfyn.mcbratney -at- gmail.com>
Elizacat, Elizabeth Myers <elizabeth -at- interlinked.me>
Elizafox, Elizabeth Myers <elizabeth -at- interlinked.me>
Entrope, Michael Poole <mdpoole -at- trolius.org>
gxti, Michael Tharp <gxti -at- partiallystapled.com>
jdhore, JD Horelick <jdhore1 -at- gmail.com>
@ -25,6 +25,9 @@ ThaPrince, Jon Christopherson <jon -at- vile.com>
twincest, River Tarnell <river -at- attenuate.org>
viatsko, Valerii Iatsko <dwr -at- codingbox.io>
w00t, Robin Burchell <surreal.w00t -at- gmail.com>
For a list of contributors to ircd-ratbox, ircd-hyrbid, and ircd2.8 (the
predecessors to Charybdis), see the doc/credits-past.txt file.
Visit the Charybdis website at: http://www.charybdis.io
Visit us on IRC at: irc.freenode.net #charybdis

316
doc/CIDR.txt
View file

@ -1,316 +0,0 @@
$Id: CIDR.txt 6 2005-09-10 01:02:21Z nenolod $
CIDR Information
----------------
Presently, we all use IPv4. The format of IPv4 is the following:
A.B.C.D
Where letters 'A' through 'D' are 8-bit values. In English, this
means each digit can have a value of 0 to 255. Example:
129.56.4.234
Digits are called octets. Oct meaning 8, hence 8-bit values. An
octet cannot be greater than 255, and cannot be less than 0 (eg. a
negative number).
CIDR stands for "classless inter domain routing", details covered
in RFC's 1518 and 1519. It was introduced mainly due to waste within
A and B classes space. The goal was to make it possible to use
smaller nets than it would seem from (above) IP classes, for instance
by dividing one B class into 256 "C like" classes. The other goal was
to allow aggregation of routing information, so that routers could use
one aggregated route (like 194.145.96.0/20) instead of
advertising 16 C classes.
Class A are all these addresses which first bit is "0",
bitmap: 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh (n=net, h=host)
IP range is 0.0.0.0 - 127.255.255.255
Class B are all these addresses which first two bits are "10",
bitmap: 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh (n=net, h=host)
IP range is 128.0.0.0 - 191.255.255.255
Class C are all these addresses which first three bits are "110",
bitmap: 110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh (n=net, h=host)
IP range is 192.0.0.0 - 223.255.255.255
Class D are all these addresses which first four bits are "1110",
this is multicast class and net/host bitmap doesn't apply here
IP range is 224.0.0.0 - 239.255.255.255
I bet they will never IRC, unless someone creates multicast IRC :)
Class E are all these addresses which first five bits are "11110",
this class is reserved for future use
IP range is 240.0.0.0 - 247.255.255.255
So, here is how CIDR notation comes into play.
For those of you who have real basic exposure to how networks are
set up, you should be aware of the term "netmask." Basically, this
is a IPv4 value which specifies the "size" of a network. You can
assume the word "size" means "range" if you want.
A chart describing the different classes in CIDR format and their
wildcard equivalents would probably help at this point:
CIDR version dot notation (netmask) Wildcard equivalent
-----------------------------------------------------------------
A.0.0.0/8 A.0.0.0/255.0.0.0 A.*.*.* or A.*
A.B.0.0/16 A.B.0.0/255.255.0.0 A.B.*.* or A.B.*
A.B.C.0/24 A.B.C.0/255.255.255.0 A.B.C.* or A.B.C.*
A.B.C.D/32 A.B.C.D/255.255.255.255 A.B.C.D
The question on any newbies mind at this point is "So what do all
of those values & numbers actually mean?"
Everything relating to computers is based on binary values (1s and
zeros). Binary plays a *tremendous* role in CIDR notation. Let's
break it down to the following table:
A B C D
-------- -------- -------- --------
/8 == 11111111 . 00000000 . 00000000 . 00000000 == 255.0.0.0
/16 == 11111111 . 11111111 . 00000000 . 00000000 == 255.255.0.0
/24 == 11111111 . 11111111 . 11111111 . 00000000 == 255.255.255.0
/32 == 11111111 . 11111111 . 11111111 . 11111111 == 255.255.255.255
The above is basically a binary table for the most common netblock
sizes. The "1"s you see above are the 8-bit values for each octet.
If you split an 8-bit value into each of it's bits, you find the
following:
00000000
^^^^^^^^_ 1sts place (1)
|||||||__ 2nds place (2)
||||||___ 3rds place (4)
|||||____ 4ths place (8)
||||_____ 5ths place (16)
|||______ 6ths place (32)
||_______ 7ths place (64)
|________ 8ths place (128)
Now, since computers consider zero a number, you pretty much have
to subtract one (so-to-speak; this is not really how its done, but
just assume it's -1 :-) ) from all the values possible. Some
examples of decimal values in binary:
15 == 00001111 (from left to right: 8+4+2+1)
16 == 00010000 (from left to right: 16)
53 == 00110101 (from left to right: 32+16+4+1)
79 == 01001111 (from left to right: 64+8+4+1)
254 == 11111110 (from left to right: 128+64+32+16+8+4+2)
So, with 8 bits, the range (as I said before) is zero to 255.
If none of this is making sense to you at this point, you should
back up and re-read all of the above. I realize it's a lot, but
it'll do you some good to re-read it until you understand :-).
So, let's modify the original table a bit by providing CIDR info
for /1 through /8:
A B C D
-------- -------- -------- --------
/1 == 10000000 . 00000000 . 00000000 . 00000000 == 128.0.0.0
/2 == 11000000 . 00000000 . 00000000 . 00000000 == 192.0.0.0
/3 == 11100000 . 00000000 . 00000000 . 00000000 == 224.0.0.0
/4 == 11110000 . 00000000 . 00000000 . 00000000 == 240.0.0.0
/5 == 11111000 . 00000000 . 00000000 . 00000000 == 248.0.0.0
/6 == 11111100 . 00000000 . 00000000 . 00000000 == 252.0.0.0
/7 == 11111110 . 00000000 . 00000000 . 00000000 == 254.0.0.0
/8 == 11111111 . 00000000 . 00000000 . 00000000 == 255.0.0.0
At this point, all of this should making a lot of sense, and you
should be able to see the precision that you can get by using CIDR
at this point. If not, well, I guess the best way to put it would
be that wildcards always assume /8, /16, or /24 (yes hello Piotr,
we can argue this later: I am referring to IPs *ONLY*, not domains
or FQDNs :-) ).
This table will provide a reference to all of the IPv4 CIDR values
cidr|netmask (dot notation)
----+---------------------
/1 | 128.0.0.0
/2 | 192.0.0.0
/3 | 224.0.0.0
/4 | 240.0.0.0
/5 | 248.0.0.0
/6 | 252.0.0.0
/7 | 254.0.0.0
/8 | 255.0.0.0
/9 | 255.128.0.0
/10 | 255.192.0.0
/11 | 255.224.0.0
/12 | 255.240.0.0
/13 | 255.248.0.0
/14 | 255.252.0.0
/15 | 255.254.0.0
/16 | 255.255.0.0
/17 | 255.255.128.0
/18 | 255.255.192.0
/19 | 255.255.224.0
/20 | 255.255.240.0
/21 | 255.255.248.0
/22 | 255.255.252.0
/23 | 255.255.254.0
/24 | 255.255.255.0
/25 | 255.255.255.128
/26 | 255.255.255.192
/27 | 255.255.255.224
/28 | 255.255.255.240
/29 | 255.255.255.248
/30 | 255.255.255.252
/31 | 255.255.255.254
/32 | 255.255.255.255
So, let's take all of the information above, and apply it to a
present-day situation on IRC.
Let's say you have a set of flooding clients who all show up from
the following hosts. For lack-of a better example, I'll use a
subnet here at Best:
nick1 (xyz@shell9.ba.best.com) [206.184.139.140]
nick2 (abc@shell8.ba.best.com) [206.184.139.139]
nick3 (foo@shell12.ba.best.com) [206.184.139.143]
Most people will assume the they were all in the same class C
(206.184.139.0/24 or 206.184.139.*).
This, as a matter of fact, is not true. Now, the reason *I* know
this is solely because I work on the network here; those IPs are
not delegated to a class C, but two portions of a class C (128 IPs
each). That means the class C is actually split into these two
portions:
Netblock IP range
-------- --------
206.184.139.0/25 206.184.139.0 to 206.184.139.127
206.184.139.128/25 206.184.139.128 to 206.184.139.255
For the record, 206.184.139.0 and 206.184.139.128 are both known as
"network addresses" (not to be confused with "netblocks" or "Ethernet
hardware addresses" or "MAC addresses"). Network addresses are
*ALWAYS EVEN*.
206.184.139.127 and 206.184.139.255 are what are known as broadcast
addresses. Broadcast addresses are *ALWAYS ODD*.
Now, the aforementioned list of clients are in the 2nd subnet shown
above, not the first. The reason for this should be obvious.
The remaining question is, "Well that's nice, you know what the netblock
is for Best. What about us? We don't know that!"
Believe it or not, you can find out the network block size by using
whois -h WHOIS.ARIN.NET on the IP in question. ARIN keeps a list of
all network blocks and who owns them -- quite useful, trust me. I
think I use ARIN 5 or 6 times a day, especially when dealing with
D-lines. Example:
$ whois -h whois.arin.net 206.184.139.140
Best Internet Communications, Inc. (NETBLK-NBN-206-184-BEST)
345 East Middlefield Road
Mountain View, CA 94043
Netname: NBN-206-184-BEST
Netblock: 206.184.0.0 - 206.184.255.255
Maintainer: BEST
Does this mean you should D-line 206.184.0.0/16? Probably not.
That's an entire class B-sized block, while you're only trying
to deny access to a subnetted class C.
So then how do you get the *real* info? Well, truth is, you don't.
You have to pretty much take a guess at what it is, if ARIN reports
something that's overly vague. Best, for example, was assigned the
above class B-sized block. We can subnet it however we want without
reporting back to ARIN how we have it subnetted. We own the block,
and that's all that matters (to ARIN).
Not all subnets are like this, however. Smaller subnets you may
find partitioned and listed on ARIN; I've seen /29 blocks for DSL
customers show up in ARIN before.
So, use ARIN any chance you get. The more precision the better!
Now, there is a small issue I want to address regarding use of CIDR
notation. Let's say you D-line the following in CIDR format (hi
sion ;-) ):
205.100.132.18/24
Entries like this really makes my blood boil, solely because it adds
excessive confusion and is just basically pointless. If you
examine the above, you'll see the /24 is specifying an entire
class C -- so then what's the purpose of using .18 versus .0?
There IS no purpose. The netmask itself will mask out the .18 and
continue to successfully use 205.100.132.0/24.
Doing things this way just adds confusion, especially on non-octet-
aligned subnets (such as /8, /16, /24, or /32). Seeing that on a
/27 or a /19 might make people go "wtf?"
I know for a fact this doc lacks a lot of necessary information,
like how the actual netmask/CIDR value play a role in "masking out"
the correct size, and what to do is WHOIS.ARIN.NET returns no
netblock information but instead a few different company names with
NIC handles. I'm sure you can figure this stuff out on your own,
or just ask an administrator friend of yours who DOES know. A lot
of us admins are BOFH types, but if you ask us the right questions,
you'll benefit from the answer quite thoroughly.
Oh, I almost forgot. Most Linux systems use a different version of
"whois" than FreeBSD does. The syntax for whois on Linux is
"whois <INFO>@whois.arin.net", while under FreeBSD it is
"whois -h whois.arin.net <INFO>" Debian uses yet another version
of whois that is incompatible with the above syntax options.
Note that the FreeBSD whois client has shortcuts for the most commonly
used whois servers. "whois -a <INFO>" is the shortcut for ARIN.
Also note that ARIN is not authoritative for all IP blocks on the
Internet. Take for example 212.158.123.66. A whois query to ARIN
will return the following information:
$ whois -h whois.arin.net 212.158.123.66
European Regional Internet Registry/RIPE NCC (NET-RIPE-NCC-)
These addresses have been further assigned to European users.
Contact information can be found in the RIPE database, via the
WHOIS and TELNET servers at whois.ripe.net, and at
http://www.ripe.net/db/whois.html
Netname: RIPE-NCC-212
Netblock: 212.0.0.0 - 212.255.255.255
Maintainer: RIPE
This query tells us that it is a European IP block, and is further
handled by RIPE's whois server. We must then query whois.ripe.net
to get more information.
$ whois -h whois.ripe.net 212.158.123.66
% Rights restricted by copyright. See
http://www.ripe.net/ripencc/pub-services/db/copyright.html
inetnum: 212.158.120.0 - 212.158.123.255
netname: INSNET-P2P
descr: Point to Point Links for for London Nodes
country: GB
--snip--
This tells us the actual IP block that the query was a part of.
Other whois servers that you may see blocks referred to are:
whois.ripn.net for Russia, whois.apnic.net for Asia, Australia, and
the Pacific, and whois.6bone.net for IPv6 blocks.
Contributed by Jeremy Chadwick <jdc@best.net>
Piotr Kucharski <chopin@sgh.waw.pl>
W. Campbell <wcampbel@botbay.net> and
Ariel Biener <ariel@fireball.tau.ac.il>

61
doc/Hybrid-team
View file

@ -1,61 +0,0 @@
$Id: Hybrid-team 54 2005-09-10 05:12:55Z nenolod $
The hybrid team is a group of ircd coders who were frustrated
with the instability and all-out "dirtiness" of the EFnet ircd's
available. "hybrid" is the name for the collective efforts of a group
of people, all of us.
Anyone is welcome to contribute to this effort. You are encouraged
to participate in the Hybrid mailing list. To subscribe to the
Hybrid List, use this link:
https://lists.ircd-hybrid.org/mailman/listinfo/hybrid
The core team as, of this major release:
adx, Piotr Nizynski <adx@irc7.pl>
billy-jon, William Bierman III <bill@mu.org>
cryogen, Stuart Walsh <stu@ipng.org.uk>
Dianora, Diane Bruce <db@db.net>
joshk, Joshua Kwan <joshk@triplehelix.org>
kire, Erik Small <smalle@hawaii.edu>
knight, Alan LeVee <alan.levee@prometheus-designs.net>
metalrock, Jack Low <jclow@csupomona.edu>
Michael, Michael Wobst <michael.wobst@gmail.com>
Rodder, Jon Lusky <lusky@blown.net>
Wohali, Joan Touzet <joant@ieee.org>
The following people have contributed blood, sweat, and/or code to
recent releases of Hybrid, in nick alphabetical order:
A1kmm, Andrew Miller <a1kmm@mware.virtualave.net>
AndroSyn, Aaron Sethman <androsyn@ratbox.org>
bane, Dragan Dosen <bane@idolnet.org>
bysin, Ben Kittridge <bkittridge@cfl.rr.com>
cosine, Patrick Alken <wnder@uwns.underworld.net>
David-T, David Taylor <davidt@yadt.co.uk>
fl, Lee Hardy <lee@leeh.co.uk>
Garion, Joost Vunderink <garion@efnet.nl>
Habeeb, David Supuran <habeeb@cfl.rr.com>
Hwy101, W. Campbell <wcampbel@botbay.net>
jmallett, Juli Mallett <jmallett@FreeBSD.org>
jv, Jakub Vlasek <jv@pilsedu.cz>
k9, Jeremy Chadwick <ircd@jdc.parodius.com>
kre, Dinko Korunic <kreator@fly.srk.fer.hr>
madmax, Paul Lomax <madmax@efnet.org>
nenolod, William Pitcock <nenolod@nenolod.net>
Riedel, Dennis Vink, <riedel@chaotic.nl>
scuzzy, David Todd <scuzzy@aniverse.net>
spookey, David Colburn <spookey@spookey.org>
TimeMr14C, Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>
toot, Toby Verrall <to7@antipope.fsnet.co.uk>
vx0, Mark Miller <mark@oc768.net>
wiz, Jason Dambrosio <jason@wiz.cx>
Xride, Søren Straarup <xride@x12.dk>
zb^3, Alfred Perlstein <alfred@freebsd.org>
Others are welcome. Always. And if we left anyone off the above list,
be sure to let us know that too. Many others have contributed to
previous versions of this ircd and its ancestors, too many to list
here.
Send bug fixes/complaints/rotten tomatoes to bugs@ircd-hybrid.org.

14
doc/Makefile.am
View file

@ -1,4 +1,3 @@
# $Id: Makefile.in 3376 2007-04-03 11:37:39Z nenolod $
prefix = @prefix@
exec_prefix = @exec_prefix@
exec_suffix = @exec_suffix@
@ -8,8 +7,6 @@ sysconfdir = @sysconfdir@
localstatedir = @localstatedir@
# Local to the etc Makefile
mandir = @mandir@/man8
MANPAGES = ircd.8
CONFS = ircd.conf.example reference.conf
@ -19,11 +16,6 @@ install-mkdirs:
mkdir -p $(DESTDIR)$(sysconfdir); \
fi
-@if test ! -d $(DESTDIR)$(mandir); then \
echo "mkdir -p $(mandir)"; \
mkdir -p $(DESTDIR)$(mandir); \
fi
install: install-mkdirs
@echo "ircd: installing example config files ($(CONFS))"
@for i in $(CONFS); do \
@ -42,9 +34,3 @@ install: install-mkdirs
$(RM) $(DESTDIR)$(sysconfdir)/links.txt; \
fi
@echo "ircd: installing manpage"
@for i in $(MANPAGES); do \
if test ! -f $(DESTDIR)$(mandir)/$(PROGRAM_PREFIX)$$i; then \
$(INSTALL_DATA) $$i $(DESTDIR)$(mandir)/$(PROGRAM_PREFIX)$$i; \
fi; \
done

17
doc/README.cidr_bans
View file

@ -1,17 +0,0 @@
$Id: README.cidr_bans 6 2005-09-10 01:02:21Z nenolod $
Basically what this patch does is allow for users to use cidr masks when
setting bans, exceptions, and invite invex(modes beI respectively). This
works for both IPv4 and IPv6 addresses.
I won't go into details of how cidr works here, but to use them, you could
do something like:
/mode #foo +b *!*@10.0.0.0/8
/mode #foo +e *!*@10.0.10.0/24
Aaron Sethman <androsyn@ratbox.org>
August 06, 2002

18
doc/Ratbox-team
View file

@ -1,18 +0,0 @@
$Id: Ratbox-team 1640 2006-06-05 00:02:19Z jilles $
ircd-ratbox is an evolution where ircd-hybrid left off around version 7-rc1.
Currently the ircd-ratbox team consists of the following developers:
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
anfl, Lee Hardy <lee -at- leeh.co.uk>
Special thanks for support, code and ideas to:
Hwy, W. Campbell <wcampbel -at- botbay.net>
jilles, Jilles Tjoelker <jilles -at- stack.nl>
larne, Edward Brocklesby <ejb -at- sdf.lonestar.org>
Of course our work is based on the work of many, many others over the past
10 or so years since irc has existed, including the work done by the Hybrid
team, our thanks goes to them.

272
doc/Tao-of-IRC.940110
View file

@ -1,272 +0,0 @@
The Tao of Internet Relay Chat
Copyright (C) Ove Ruben R Olsen 1994
Version of 940110
Contributing masters: Master ScottM
-----
Something is formed by the electrons, born in the silent cable. Shaping
and growing and ungrowing. It is there yet not there. It is the source of
Internet Relay Chat. I do not know the name, thus I will call it the Tao
of Internet Relay Chat.
If the Tao is great, then the IRC is running ceaselessly. If the IRC is
great then the server is running without ever stoping. If the server is
great then the client will always be the server. The luser is then pleased
and there is Chat in the world.
The Tao of IRC squits far away and connects on returning.
-----
The genetic potential of birth, a lot to know, yet unknown.
In the begining there was nothing.
Out of nothing the Tao gave birth to tolsun.oulu.fi. tolsun gave birth to
OuluBox.
OuluBox gave birth to rmsg.
rmsg was not Tao, so MUT gave birth to IRC.
No one knows when IRC came into existance, the mighty master WiZ have it
to be at the end of the eight month in the year of the Dragon.
-----
Each channel has its purpose, however humble. Each channel is the Yin and
Yang of IRC. Each channels has it's place within the IRC.
In the beginning there was only channel 0, thus channel 0 is the soil of
IRC.
Channel 1 to channel 10 then was open as the sea. Channel 11 to 999 was the
trees and forests of IRC. Channels above 999 should not be mentioned, and
channels below 0 were unborn and contained many secrets.
This was not the right Tao, so IRC gave birth to +channels.
+channels had the yin and yang. Mode does not.
This was not the right Tao still, so IRC gave birth to #channels.
#channels have the yin and yang.
Only channel 0 is the right path to Tao, but avoid speaking on channel 0.
-----
There was a great dispute among the Broom-Walkers of the Relay. Some of them
wanted neither yin nor yang. Out of this Eris came into existance. Some of the
Broom-Walkers then created Eris Free-net.
This was the right Tao.
Kind Gentle and Boring Net was another wrong path to the Tao of Internet Relay
Chat.
Some time later there was a quantity of some lusers who wanted to be
Broom-Walkers also. The Eris Free Broom-Walkers did not agree with them,
thus a new IRC was born. This IRC is called the Undernet.
But this is not the right Tao, either.
-----
There will always be disputes among the Broom-Walkers of Internet Relay Chat.
This is the very nature of the IRC.
-----
Lusers that do not understand the Tao is always using the yang of Mode on
their channels. Lusers that do understand the Tao are always using Ignore
on their channels.
How could this not be so ?
-----
The wise sage luser is told about the Chat and uses it. The luser is told
about the IRC and is looking for it. The flock are told about the Tao and
make a fool of the IRC.
If there was no laughter, there would be no Tao.
-----
The master says:
"Without the Tao of Internet Relay Chat, life becomes meaningless."
The Relay of the old time was mysterious and sacred. We can neither imagine
its thoughts nor path; we are left but to describe.
-----
The sage luser must be aware like a frog crossing the highway.
-----
The great master Wumpus once dreamed that he was an automaton. When he awoke
he exclaimed:
"I don't know whether I am Wumpus dreaming that I am a client,
or a client dreaming that I am Wumpus!"
So was the first Automata born.
The master Nap then said:
"Any automata should not speak unless spoken to.
Any automata shall only whisper when spoken to."
Thus replied the master Gnarfer:
"The lusers shall keep in mind that a automata can be either good or
bad. Create good automata, and the IRC will hail you and you will
gain fame and fortune. Create bad automata and people will start to
hate you, and finaly you will be /KILLed to ethernal damnation"
Many lusers have fallen into the clutches of ethernal damnation. They where
not following the Tao.
-----
There once was a luser who went to #BotSex. Each day he saw the automatons.
The luser decided that he also would have such a automata.
He asked another luser for his automata. The other luser gave his automata
away.
The luser was not within the Tao, so he just started the automata. The automata
had only Yang inside so all the lusers files where deleted.
Some moons laither the same luser then had become a sage luser, and did create
his automata from the very grounds with materials found inside the IRC.
The luser was now within the Tao and his automata lived happily ever after.
-----
There once was a master who wrote automatons without the help of master Phone.
A novice luser, seeking to imitate him, began with the help of master Phone.
When the novice luser asked the master to evaluate his automata the master
replied: "What is a working automata for the master is not for the luser.
You must must BE the IRC before automating."
-----
Master BigCheese gave birth to master Troy; his duty clear. Master Troy gave
birth to master Phone, for the Tao of Irc must be eternal and must flow as the
ceaseless river of Time itself.
-----
Master Phone once said about the ircII client:
"public_msg is for a message from someone NOT on the channel
public_other is for a message on a channel that doesn't belong to
a window. public is for a message on a channel that belongs to a
window!"
Out of this raised the mighty chaos.
-----
The sage luser came to the master who wrote automata without the help of
master Phone. The sage luser asked the master who wrote automata: "Which is
easiest to make. A automata with the help of master Phone or an automata
made with the help of a language ?"
The master who wrote automata then replied:
"With the help of a language."
The sage luser was disapointed and exclaimed: "But, with master Phone you
do not need to know anything about the soil of IRC. Is not that the easiet
way ?"
"Not really" said the master who wrote automata, "when using master Phone
you are closed inside a box. For sure, it is a great box for the lusers,
but the master will need more power, thus a language is the only path to go.
With the language the master will never have to limit himself. When using
such a language the master will seek the best between the need and the
availibility."
"I see", said the sage luser.
This is the essence of Tao of IRC automatas.
-----
A client should be light and be used for communication. The spirit of a good
client is that it should be very convinient for the luser to use, but hard
for the luser who want to create automata.
There should never ever be too many functions or too few functions.
There should always be a ignore.
Without ignore the client is not within the Tao of Chating.
The client should always respond the luser with messages that will not
astnonish him too much. The server likewise. If the server does not, then it
is the clients job to explain what the server says.
A client which fails this, will be useless and cause confusion for the lusers.
The only way to correct this is to use another client or to write a new one.
-----
A luser asked the masters on #IrcHelp: "My client does not work".
The masters replied: "Upgrade your client".
The luser then wondered why the master knew. The master then told him about
the Protocol.
"Your client does not work beaucse it does not understand the server. Why
should it always work ? Only a fool would expect such. But, clients are made
by humans, and humans are not perfect. Only Tao is.
The IRC is solid. The IRC is floating, and will always be dynamic. Live with
that or /quit."
-----
The luser came to the masters of #IrcHelp, asking about the Tao of IRC within
the client.
The masters then said that the Tao of IRC always lies inside the client
regardless of how the client connects to the server.
"Is the Tao in irc ?" asked the luser.
"It so is" replied the masters of #IrcHelp.
"Is the Tao in the ircII, Kiwi, rxirc, vms, rockers and msa ?" asked the
luser.
"In all of them and in the TPC, irchat, zenirc, zircon X11-irc and even the
dos irc has the Tao" said the master quietly.
"Is the Tao in a telnet connection directly to the server ?"
The master then was quiet for a long time and said. "Please leave, such
questions are not within the Tao of IRC".
-----
The master says: "Without the Protocol of TCP the messages will not travel.
Without the client, the server is useless."
-----
There once was a luser who used the ircII client. "ircII can do anything I
ever need for using IRC" said the emacs client user, "I have /ON's, I have
assignments, I have aliasing. Why don't you use this instead of the huge
emacs client, which also has a messy screen?"
The emacs client user then replied by saying that "it is better to have a
scripting language that is the client instead of have a client that has
a scripting language." Upon hearing this, the ircII client luser fell silent.
-----
The master Wumpus said: "Time for you to leave. I did, now I'm happy."
The master Gnarfer replied: "Use, but never overuse IRC, then you will also
be happy within IRC"
-----
A luser came unto the masters of #EU-Opers and asked, "How can I be, yet not
be, a user@host within the IRC?"
The masters of #EU-Opers replied: "To be Tao is to be ones true self. To hide
ones self is not Tao, and is not IRC, you have much to learn before you shall
be at rest within the Flow of Irc. Please leave"

91
doc/old/Authors → doc/credits-past.txt
View file

@ -1,3 +1,7 @@
===============================================================================
IRCD 2.8 CREDITS
===============================================================================
/************************************************************************
* IRC - Internet Relay Chat, doc/AUTHORS
* Copyright (C) 1990
@ -135,3 +139,90 @@ 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>
===============================================================================
IRCD-HYBRID CREDITS
===============================================================================
The hybrid team is a group of ircd coders who were frustrated
with the instability and all-out "dirtiness" of the EFnet ircd's
available. "hybrid" is the name for the collective efforts of a group
of people, all of us.
Anyone is welcome to contribute to this effort. You are encouraged
to participate in the Hybrid mailing list. To subscribe to the
Hybrid List, use this link:
https://lists.ircd-hybrid.org/mailman/listinfo/hybrid
The core team as, of this major release:
adx, Piotr Nizynski <adx@irc7.pl>
billy-jon, William Bierman III <bill@mu.org>
cryogen, Stuart Walsh <stu@ipng.org.uk>
Dianora, Diane Bruce <db@db.net>
joshk, Joshua Kwan <joshk@triplehelix.org>
kire, Erik Small <smalle@hawaii.edu>
knight, Alan LeVee <alan.levee@prometheus-designs.net>
metalrock, Jack Low <jclow@csupomona.edu>
Michael, Michael Wobst <michael.wobst@gmail.com>
Rodder, Jon Lusky <lusky@blown.net>
Wohali, Joan Touzet <joant@ieee.org>
The following people have contributed blood, sweat, and/or code to
recent releases of Hybrid, in nick alphabetical order:
A1kmm, Andrew Miller <a1kmm@mware.virtualave.net>
AndroSyn, Aaron Sethman <androsyn@ratbox.org>
bane, Dragan Dosen <bane@idolnet.org>
bysin, Ben Kittridge <bkittridge@cfl.rr.com>
cosine, Patrick Alken <wnder@uwns.underworld.net>
David-T, David Taylor <davidt@yadt.co.uk>
fl, Lee Hardy <lee@leeh.co.uk>
Garion, Joost Vunderink <garion@efnet.nl>
Habeeb, David Supuran <habeeb@cfl.rr.com>
Hwy101, W. Campbell <wcampbel@botbay.net>
jmallett, Juli Mallett <jmallett@FreeBSD.org>
jv, Jakub Vlasek <jv@pilsedu.cz>
k9, Jeremy Chadwick <ircd@jdc.parodius.com>
kre, Dinko Korunic <kreator@fly.srk.fer.hr>
madmax, Paul Lomax <madmax@efnet.org>
nenolod, William Pitcock <nenolod@nenolod.net>
Riedel, Dennis Vink, <riedel@chaotic.nl>
scuzzy, David Todd <scuzzy@aniverse.net>
spookey, David Colburn <spookey@spookey.org>
TimeMr14C, Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>
toot, Toby Verrall <to7@antipope.fsnet.co.uk>
vx0, Mark Miller <mark@oc768.net>
wiz, Jason Dambrosio <jason@wiz.cx>
Xride, Søren Straarup <xride@x12.dk>
zb^3, Alfred Perlstein <alfred@freebsd.org>
Others are welcome. Always. And if we left anyone off the above list,
be sure to let us know that too. Many others have contributed to
previous versions of this ircd and its ancestors, too many to list
here.
Send bug fixes/complaints/rotten tomatoes to bugs@ircd-hybrid.org.
===============================================================================
IRCD-RATBOX CREDITS
===============================================================================
ircd-ratbox is an evolution where ircd-hybrid left off around version 7-rc1.
Currently the ircd-ratbox team consists of the following developers:
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
anfl, Lee Hardy <lee -at- leeh.co.uk>
Special thanks for support, code and ideas to:
Hwy, W. Campbell <wcampbel -at- botbay.net>
jilles, Jilles Tjoelker <jilles -at- stack.nl>
larne, Edward Brocklesby <ejb -at- sdf.lonestar.org>
Of course our work is based on the work of many, many others over the past
10 or so years since irc has existed, including the work done by the Hybrid
team, our thanks goes to them.

0
doc/account-notify.txt → doc/features/account-notify.txt
View file

0
doc/away-notify.txt → doc/features/away-notify.txt
View file

2
doc/challenge.txt → doc/features/challenge.txt
View file

@ -82,5 +82,3 @@ ratbox-respond/README for more information.
A number of scripts for clients have already been written to automate this
process, see client-scripts/README for more information.
--
$Id: challenge.txt 678 2006-02-03 20:25:01Z jilles $

2
doc/collision_fnc.txt → doc/features/collision_fnc.txt
View file

@ -43,5 +43,3 @@ the same on all servers for each nick-user pair, also if a user with a UID
nick changes their nick but is collided again (the server detecting the
collision will not propagate the nick change further).
--
$Id: collision_fnc.txt 3422 2007-04-22 14:35:28Z jilles $

2
doc/extban.txt → doc/features/extban.txt
View file

@ -88,5 +88,3 @@ The function is called whenever a (local) client needs to be checked against
a +bqeI entry of the given extban type, and whenever a local client tries to
add such an entry. (Clients are allowed to add bans matching themselves.)
--
$Id: extban.txt 1639 2006-06-04 23:26:47Z jilles $

0
doc/extended-join.txt → doc/features/extended-join.txt
View file

15
doc/features/index.txt Normal file
View file

@ -0,0 +1,15 @@
Here is an overview of the docs in the doc/features directory.
account-notify.txt - Description of the account-notify system
away-notify.txt - Description of the away-notify system
challenge.txt - Overview of the challenge/response system for
obtaining operator status
collision_fnc.txt - Overview of the SAVE nick collision method
extban.txt - Description of extended bans
extended-join.txt - Description of the extended-join system
modeg.txt - Description of UMODE +g, the caller ID system
monitor.txt - Description of the MONITOR system
sasl.txt - Description of the SASL services authentication
system
services.txt - Overview of features added by services
tgchange.txt - Overview of the target change system

1
doc/modeg.txt → doc/features/modeg.txt
View file

@ -215,4 +215,3 @@ which is ambiguous if the user may contain a [ and in the author's opinion ugly.
--
W. Campbell
updated by J. Tjoelker
$Id: modeg.txt 3556 2007-08-18 14:45:10Z jilles $

1
doc/monitor.txt → doc/features/monitor.txt
View file

@ -1,6 +1,5 @@
MONITOR - Protocol for notification of when clients become online/offline
Lee Hardy <lee -at- leeh.co.uk>
$Id: monitor.txt 3520 2007-06-30 22:15:35Z jilles $
-------------------------------------------------------------------------
Currently, ISON requests by clients use a large amount of bandwidth. It is

1
doc/sasl.txt → doc/features/sasl.txt
View file

@ -127,4 +127,3 @@ Kucharski (IRCnet), IRC Client Capabilities Extension. March 2005.
This internet-draft has expired; it can still be found on
http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html
$Id: sasl.txt 3169 2007-01-28 22:13:18Z jilles $

18
doc/services.txt → doc/features/services.txt
View file

@ -1,9 +1,12 @@
ratbox-services compatibility documentation - Lee H <lee -at- leeh.co.uk>
-------------------------------------------------------------------------
Services compatibility documentation
------------------------------------
Compatibility with ratbox-services is always enabled. Note that some or
all of this is also used by atheme-services and anope. It will add the
following features to ircd:
Originally written by Lee Hardy for ircd-ratbox. Minor changes by Elizabeth
Myers for modern services.
Compatibility with services is always enabled. Supported services include
atheme and anope. They add the following features to Charybdis:
1. Channel mode +r
@ -17,8 +20,8 @@ following features to ircd:
Ability to specify the names of services servers in ircd.conf:
service {
name = "services.ircd-ratbox.org";
name = "backup-services.ircd-ratbox.org";
name = "services.charybdis.io";
name = "backup-services.charybdis.io";
};
These must be specified for certain features to work. You may specify as
@ -60,4 +63,3 @@ following features to ircd:
Gives numeric 486 to users sending a PRIVMSG who are not logged in:
:<server> 486 <nick> <targetnick> :You must log in with services to message this user
# $Id: services.txt 6 2005-09-10 01:02:21Z nenolod $

3
doc/tgchange.txt → doc/features/tgchange.txt
View file

@ -41,6 +41,3 @@ you are messaging that channel or a client within that channel. The latter
can be done explicitly using the CNOTICE and CPRIVMSG commands, see
/quote help cnotice and /quote help cprivmsg, but is also implicit in a
normal /msg, /notice or /invite.
--
$Id: tgchange.txt 6 2005-09-10 01:02:21Z nenolod $

30
doc/index.txt
View file

@ -1,28 +1,20 @@
# $Id: index.txt 6 2005-09-10 01:02:21Z nenolod $
Here is the overview of the documents in the doc/ directory.
CIDR.txt - Description of CIDR in IPv4
Tao-of-IRC.940110 - No comment...
challenge.txt - Overview of the challenge/response system for
obtaining operator status
Subdirectories:
features/ - Documents about features and standards
technical/ - Technical documents about ircd internals and
protocol information
sgml/ - SGML documentation
Files:
ircd.conf.example - An example ircd.conf file describing most of the
user settable options
guidelines.txt - Documentation guidelines
hooks.txt - Overview of the hooks available
index.txt - This file
ircd.8 - The new revised manpage, read with the following
commands in the prefix directory:
man -M . ircd
ircd.motd - A default ircd.motd used by make install
credits-past.txt - Credits for the predecessors to Charybdis
logfiles.txt - Description of formatting of some logfiles
modeg.txt - An in depth description of the server side silence
user mode (+g)
modes.txt - A list of all user and channel modes
operguide.txt - EFnet operator's guide
opermyth.txt - Oper myth's, describes what opers can and cannot do
server-version-info - Overview of the flags shown in /version
whats-new.txt - What new features are available
server-version-info.txt - Overview of the flags shown in /version
Also in the contrib/ directory you will find:
example_module.c - An example module, detailing what the code in a module

120
doc/ircd.8
View file

@ -1,120 +0,0 @@
.\" @(#)ircd.8 2.0 22 April 2004
.\" $Id: ircd.8 6 2005-09-10 01:02:21Z nenolod $
.TH IRCD 8 "ircd-ratbox" 22 April 2004
.SH NAME
ircd \- The Internet Relay Chat Program Server
.SH SYNOPSIS
.hy 0
.IP \fBircd\fP
[-dlinefile filename] [-configfile filename] [-klinefile filename]
[-logfile filename] [-pidfile filename] [-resvfile filename]
[-xlinefile filename] [-conftest] [-foreground] [-version]
.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.
.SH OPTIONS
.TP
.B \-dlinefile filename
Specifies the D-line file to be used. This file is used for both reading
D-lines at startup, and writing to while \fIircd\fP is running.
.TP
.B \-configfile 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 \-klinefile filename
Specifies the K-line file to be used. This file is used for both reading
K-lines at startup, and writing to while \fIircd\fP is running.
.TP
.B \-logfile filename
Specifies an alternative logfile to be used than that specified in config.h
.TP
.B \-pidfile filename
Specifies the ircd.pid used. The option is used to override the default
ircd.pid given at compile time.
.TP
.B \-resvfile filename
Specifies the resv.conf file to be used for this ircdaemon. The option
is used to override the default resv.conf given at compile time.
.TP
.B \-xlinefile filename
Specifies the xline.conf file to be used for this ircdaemon. The option
is used to override the default xline.conf given at compile time.
.TP
.B \-conftest
Makes \fIircd\fP check the ircd.conf for errors
.TP
.B \-foreground
Makes \fIircd\fP run in the foreground
.TP
.B \-version
Makes \fIircd\fP print its version, and exit.
.SH USAGE
If you plan to connect your \fIircd\fP server to an existing Irc-Network,
you will need to alter your local IRC configuration file (typically named
"ircd.conf") so that it will accept and make connections to other \fIircd\fP
servers. This file contains the hostnames, Network Addresses, and sometimes
passwords for connections to other ircds around the world. Because
description of the actual file format of the "ircd.conf" file is beyond the
scope of this document, please refer to the file INSTALL in the IRC source
files documentation directory.
.LP
.SH 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 \fBnot\fP part of your Unix's 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.
.SH EXAMPLE
.RS
.nf
tolsun% \fBbin/ircd\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.
.RS
.nf
leguin% \fBbin/ircd -foreground\fP
.fi
.RE
.LP
Runs ircd in the foreground.
.RS
.nf
.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
(c) 1997,1998,1999,2000,2001 The IRCD-Hybrid project.
.LP
For full COPYRIGHT see LICENSE file with IRC package.
.LP
.RE
.SH FILES
"ircd.conf"
.SH BUGS
None... ;-) if somebody finds one, please inform author
.SH AUTHOR
irc2.8 and earlier: Jarkko Oikarinen, currently jto@tolsun.oulu.fi.
.LP
ircd-hybrid-7: IRCD-Hybrid Project, ircd-hybrid@the-project.org.
.LP
manual page written by Jeff Trim, jtrim@orion.cair.du.edu,
later modified by jto@tolsun.oulu.fi.
.LP
modified for ircd-hybrid-7 by Edward Brocklesby, ejb@klamath.uucp.leguin.org.uk.
.LP
updated by W. Campbell, wcampbel@botbay.net

2
doc/ircd.conf.example Executable file → Normal file
View file

@ -4,8 +4,6 @@
* Copyright (C) 2002-2005 ircd-ratbox development team
* Copyright (C) 2005-2006 charybdis development team
*
* $Id: example.conf 3582 2007-11-17 21:55:48Z jilles $
*
* See reference.conf for more information.
*/

3
doc/logfiles.txt
View file

@ -1,5 +1,4 @@
ircd-ratbox logfiles - Lee H <lee -at- leeh.co.uk>
$Id: logfiles.txt 6 2005-09-10 01:02:21Z nenolod $
Charybdis logfiles - Lee H <lee -at- leeh.co.uk>
---------------------------
fname_killlog

5
doc/modes.txt
View file

@ -4,7 +4,6 @@ Standard channel modes are listed in help/opers/cmode
The sgml docs have more detailed descriptions.
User mode +h (hide hostname) is provided by contrib/ip_cloaking.so
User mode +x (hide hostname) is provided by contrib/ip_cloaking.so
Server notice mask +F (far connects) is provided by contrib/sno_farconnect.so
# $Id: modes.txt 996 2006-03-09 01:14:34Z jilles $
Information on the caller ID system can be found in doc/features/modeg.txt

368
doc/operguide.txt
View file

@ -1,368 +0,0 @@
EFnet Oper Guide
Last update: 02-21-2002
Written and maintained by Riedel
E-Mail: dennisv@vuurwerk.nl
1. Commands you should know about
2. The client of your choice
3. Your primary responsibilities
4. Re-routing
4.1 Re-routing other servers and remote connects
5. Kills and klines
6. Kill and K-Line requests
7. Happy birthday!
8. Security
9. Know who your friends are
10. The TCM bot
11. Services
12. G-Lines
1. Commands you should know about
This is no longer covered here. IRCD-hybrid is changing too rapidly, so
this section would be outdated in no time ;) For an up-to-date version,
please download the latest hybrid at www.ircd-hybrid.org.
2. The client of your choice
There are many IRC clients around for a wide variety of operating systems.
Being an IRC Operator doesn't *require* you to use a UNIX client, however
I personally prefer UNIX-based clients. If you're familiar with UNIX and
use UNIX for opering, I suggest ircII / epic. There are a lot of scripts
available for those two clients, and it's not that hard to write scripts
yourself to suite your needs. It is important that you know how to operate
your client, and familiarize yourself with the options and features. For
whatever client you chose this goes for any of them: You should be in
control of your client, instead of the client being in control of you.
Resources :
www.mirc.co.uk - mIRC (MS-Windows)
www.irchelp.org - a variety of clients and scripts
ftp.blackened.com - several UNIX based clients available
3. Your primary responsibilities
As an IRC Operator, you're responsible for maintaining the server on a
real-time basis. You represent your server, and you represent the network.
Irresponsible / rude / offensive / stupid behavior may discredit your server
and the network. You should focus on the task you were chosen for...
maintainance. Sounds simple, no? It means getting rid of users that abuse
the service, enforcing the server's policy and keeping the server linked.
Users will ask you questions, and expect you to know all the answers.. after
all, you're the oper!
Be prepared for users trying to fool you, sweet talk you into things you
don't want, lie and deceive. Most users are handling in good faith...
however, the abusers have learned how to manipulate opers. They have studied
the alien creature 'oper' for ages like biologists study animals. Be
paranoid, be curious and be suspicious. I can't stress the importancy of that
often enough.
Second priority has the network. You were not chosen to maintain the network
but you were chosen to maintain the server. However, you may want to be able
to reroute servers. If you see something broken, don't be afraid to fix it.
If you do, be sure you fix things and don't make it worse. Before you
step into routing, be sure you've familiarized yourself with the network's
topology, and be confident enough to perform such actions. (re)routing is
covered in the next chapter.
Opers on the network depend on a trusting relationship. You can usually take
the word from an oper. Other opers are considered -trusted-, however, there
are exceptions. Sometimes even opers lie to opers to get things done. Don't
be afraid to ask for proof of a certain statement, such as logs.
This doesn't mean you distrust the oper in question, but -you- and you alone
are responsible for your actions. You call the shots on your server, unless
your admin says otherwise.
4. Re-routing
Re-routing is not hard, and it's not scary but it is important that you do it
right. The commands you'll use are SQUIT and CONNECT. First, a very simple
example. Let's say your server, irc.yourserver.com is lagged to it's uplink,
irc.uplink.com and you want to reroute your server. You have to think about
where you want your server to be linked, and you have to time your reroute.
An example topology :
irc.yourserver.com ---- irc.uplink.com
| | \
B C D
/ \
E F
/ \
G H --- O
/ | \ | \
I J K L M
\
N
In this case, you're uplinked by irc.uplink.com
irc.uplink.com also hubs B, C and D. Server B functions as hub for E and F;
F hubs G and H; H hubs L, M and O. G hubs I, J and K. M hubs N.
Your server is allowed to connect to server B, F and G. So you consider the
servers you're able to connect to. Is the lag caused by a server that uplinks
irc.uplink.com ? Use /stats ? irc.uplink.com to determine lag to the other
servers. If irc.uplink.com does not respond, the lag is to your uplink. If
so, you cannot be sure about the state of the other uplinks, so you'd have to
get on a remote server and determine lag by using /stats ? and /trace. For
example, you could connect to server N, and /trace yournick. Yournick, being
the nick on your server. You'll see which route it takes, and what the
problem server is. Example /trace output :
S:[SERVER-N ] V:[2.8/hybrid] U:[SERVER-M ]
S:[SERVER-M ] V:[2.8/hybrid] U:[SERVER-H ]
S:[SERVER-H ] V:[2.8/hybrid] U:[SERVER-F ]
S:[SERVER-F ] V:[2.8/hybrid] U:[SERVER-B ]
S:[SERVER-B ] V:[2.8/hybrid] U:[irc.uplink.com ]
S:[irc.uplink.com ] V:[2.8/hybrid] U:[irc.yourserver.com ]
The trace doesn't complete... server-b announces irc.uplink.com, and
irc.uplink.com announces your server. Your server should return something
like :
S:[irc.yourserver.] OPER [yournick!user@yourhost]
If it doesn't, we know the lag is only between yourserver and uplink.
Usually if there is lag between your server and your uplink, the send-queue
rises. This is not always the case. Sometimes your server can write perfectly
to your uplink, but not reverse. That is called one sided lag.
We pick server B to link to. It means we have to SQUIT and CONNECT.
To unlink from irc.uplink.com and connect to SERVER_B we'd type:
/quote SQUIT irc.uplink.com :reroute
/connect SERVER_B
we *DON'T* SQUIT irc.yourserver.com... and I'll try to explain why:
If we wanted to remove hub M from the network, and with it N, we'd issue
a SQUIT M. An SQUIT follows a path, relays the SQUIT request to each server
in that path. Finally it reaches server H, which is the hub for M. Server H
sees the SQUIT and drops the link to M.
Now a different situation, we want to separate yourserver, uplink, C and D
from the rest of the network, in order to reroute. We'd have to SQUIT server
B, since we want the -uplink- of server B (being irc.uplink.com) to drop the
link to server B.
If you'd SQUIT irc.yourserver.com, you ask yourserver.com to drop the link to
itself, which is impossible. If you SQUIT irc.uplink.com, you ask yourserver
to drop the link to uplink, which is what we want to do.
After the SQUIT and CONNECT, the new situation looks like this :
irc.uplink.com
| | \
irc.yourserver.com -- B C D
/ \
E F
/ \
G H --- O
/ | \ | \
I J K L M
\
N
If yourserver is a Hub, it makes the situation more complex, since your
actions have more impact.
4.1 - Re-routing other servers and remote connects
Example topology :
irc.uplink.com
| | \
irc.yourserver.com -- B C D
/ \
E F
/ \
G H --- O
/ | \ | \
I J K L M
\
N
Let's say, hub H is way lagged to F, but G to F is fine... we want to reroute
H, and stick H to G.
We'd do :
/quote SQUIT serverh :re-routing you babe
/connect serverh 6667 serverg
A global wallops will be sent :
!serverg! Remote CONNECT serverh 6667 from ItsMe
When re-routing, always give the server some time to prevent nick collides.
When there is lag, people will connect to another server. When you SQUIT and
CONNECT to fast, a lot of those clients will be collided. Also, stick to your
territory. How enthusiastic you may be, you cannot route the world. If you're
an oper on the US side, stick to the US side when re-routing. Needless to
say, if you're EU, keep it to EU ;)
5. Kills and klines
As an oper, you're given the incredible power *cough* of KILL and KLINE.
/kill nick reason disconnects a client from IRC with the specified reason.
A /quote kline *evil@*.dude.org :reason here bans the user from your server.
Abusive kills and klines may draw attacks to your server, so always consider
if a kline or kill is deserved. If the server gets attacked after a valid
kill or kline, well.. tough luck. You should never be 'afraid' to kline
anyone on your server. If it's a good reason, make it so. Even if you know
it may cause the server to be attacked. Maybe good to think about is this:
- if /ignore solves the problem rather than a kick, /ignore
- kick if a ban is unneeded
- ban if a /kill is unwarranted for
- kill rather than kline if that solves the problem
- kline when a server ban is really needed.
You kline a user when you absolutely don't want this user to use the service
your server is providing.
Crosskills (killing users on another server) are another issue. Some admins
don't care if users get /kill'ed off their server, for any reason or no
reason at all... and other admins are very anal about it. A good way to go
(IMO) is to issue a KILL if there is an absolute need for the target user to
be disconnected. If there are active opers on that server, let them handle
it. They'll be upset if you /kill a user off their server, without
contacting them. /stats p irc.server.here shows the active opers on a
particular server. Some opers have multiple o-lines and are not watching all
sessions. If you can't find an active oper on a server, you can
/quote operwall a request for opers from that server.
Ghost KILLs are another story, an often misunderstood one.
When you see a /KILL from an oper with the reason 'ghosted' they usually
KILL a client that's about to ping timeout. That is not what a ghost is!
To quote Dianora: "a ghost happens because a client misses being killed when
it should be. Its a race condition due to nick chasing". In other words,
Server X thinks client A has been KILLed, while server Y missed the KILL
for that client.
6. Kill and K-Line requests
As previously mentioned, if an oper from another server contacts you and
requests a kill or a kline for a local client with a good reason, you can
usually trust this request. Opers depend on a trusting relationship. However,
since you're responsible for the kill or kline, it is not rude to ask for
proof. It depends on the oper making the request how thats interpreted, but
the way they respond to asking for proof tells more about them than about
you.
The more and longer you oper, how better you get to know the other opers.
You know who is honest, you'll know who are lying and deceiving. Before
you acquire this knowledge, you can merely rely on common sense and
instincts. You'll probably make mistakes occasionally, and thats nothing to
be ashamed of. Opers are - despite contrary believes - human.
Users occasionally will ask you to kill or kline a user/bot too. Some
requests are straight-forward and clear, others require you to be cautious. I
recommend to always investigate such requests, and when you're confident the
request is valid, issue the kill or kline.
7. Happy birthday!
It is a custom on EFnet to birthday /kill opers of whom it is his/her
birthday. Not all opers like this, but typically those opers don't let
others know about their birthday. You'll notice that the KILLS say a lot
about who likes who and who is friends with who. Whether you want to
participate, is entirely up to you.
8. Security
As with any privilege, you have to handle it cautiously and responsibly.
Be sure that your o/O line doesn't get compromised! Oper only from secure
hosts. You and only you should know your password. Don't share your oper
account, and make your oper password a UNIQUE one. If your o/O line gets
compromised, nasty things may/will happen. Imagine an oper with crosskill
capabilities who's operline gets 'hacked'... the results are often
disastrous and you will lose respect and trust from others. It can cause
your oper privileges to be revoked, or even the server to be (temporarily)
delinked.
9. Know who your friends are
As an oper you will get a lot of users that want to be 'friends' with you.
Users offer you free* access to their *nix servers, ops in channels,
unlimited leech access to the biggest and fastest warez sites *gasp* and
more. They want favors in return. They say they don't but they truly want
something in return. They -expect- something in return. You could either
don't respond to such offers, or use them. The last option creates an even
more distorted image of opers and doesn't do any good for the user <-> oper
relationship. Your *real* friends are usually the persons who were your
friends _before_ you acquired the extra privileges.
10. The TCM Bot
A TCM bot can be a valuable tool for opers. It keeps record of all connected
clients, flags clients with multiple connections and has all sorts of other
useful commands. There are three different kind of TCM's in use on EFnet,
being OOMon, TCM-Dianora and TCM-Hybrid. Every one of them requires you to
log in to be able to access the privileged commands. On OOMon you DCC chat
the TCM bot and do '.auth yournick yourpass' where yournick is your oper
name in your o/O line. In TCM-Dianora and TCM-Hybrid you register with:
'.register yourpass', where yourpass is your password ;)
All TCM commands start with a period. If you forget the period, the text goes
into the 'partyline', where it is echoed to all connected opers.
Resources : http://toast.blackened.com/oomon/help
http://www.db.net/~db/tcm.html
11. Services
A recent addition to EFNet is Channel Fixer, aka ChanFix. This is an
automated service that re-ops clients on opless channels. There are a few
restrictions. First, the channel has to be of significant size for ChanFix
to store it in its database. Second, it only logs static addresses.
How does it work? Periodically it stores information about the channel state
in its database, for every channel in there. On every 'run', a channel
operator gets one point. These scores make a top-5 of 'most frequent opped
clients'. When a channel becomes opless, ChanFix will join and op the top-5
opped clients CURRENTLY IN THE CHANNEL.
Chanfix can be invoked manually by server administrators. /msg ChanFix
chanfix #channel is the command to do it. ChanFix will join, and treat the
channel as if it were opless. It lowers TS by one (resulting in a deop of
the entire channel) and re-ops the top-5 clients currently in the channel.
The Channel Fixer won't log or actively fix channels when there's a split of
significant size. Needless to say, the chanfix command must be used with
caution.
12. G-Lines
Oh yes! A G-Line section. Currently, a part of EFNet (EU-EFnet) has G-Lines
enabled. This was decided by the EU admin community and is now mandatory
within EU-EFnet. In order for a G-Line to be activated, three opers from
three different servers need to issue the _exact_ same G-Line. The reason
is not counted.
G-Lines work best when the EU side of EFNet is not fragmented. G-Lines
will, however, propogate through a Hybrid 6 hub (but not a CSr hub) even
if the hub server has G-Lines disabled. This propogation allows two halves
of EU-EFnet to have concurrent G-Lines set even when split by US hub servers.
Questions / Comments / Suggestions are welcome.
You can e-mail me: dennisv@vuurwerk.nl
Best regards,
--
Dennis "Riedel" Vink ___~___ Email - dennisv@vuurwerk.nl
Unix System Administrator \ | / Phone - +31 23 5111111
Vuurwerk Internet '|.|' PGP - 0xD68A7AAB
And on the seventh day, He exited from append mode.
# $Id: operguide.txt 6 2005-09-10 01:02:21Z nenolod $

137
doc/opermyth.txt
View file

@ -1,137 +0,0 @@
Date: Thu, 30 Jul 1998 16:21:40-0700 (MST)
To: operlist@the-project.org
From: rayp@primenet.com (Ray Powers)
Subject: The myths of opers....
I've always wanted to write something like this.. Its half rant, half
fact, so bear with it. Hopefully it will be worth reading.
There's a lot of hate for opers for a lot of reasons. Some are directly
oper related (i.e. 99% of us are colossal assholes), some are directly
user related (i.e. 99% of you are raving lunatics), and some is just plain
misconceptions. I'd like to take a minute to talk about part three in
hopes of clearing a few things up. This will kind of be in a FAQ form,
maybe you'll like it, maybe not, but its worth a shot.
Q: What can an oper on EFnet do.
A: This is an EXACT list of what we can do:
1) /squit a server, separating it from the rest of the net
2) /die our server
3) /kill a user, this disconnects them from the server they are on
4) /kline a hostmask, this bans them from our server
5) /dline an ip, this bans them from our server, regardless of
hostmask
6) See all invisible users on our server
7) Mass Msg/CTCP/notice a hostmask
8) Mass Msg/CTCP/notice a server
9) See and send Operwall/wallops notices
That's it. We can see more server messages than you, but that's not the
point.. The point to be shown here is very simple, *none* of these things
have anything to do with channels. Which leads us to our next question.
Q: What can opers *NOT* do, but keep being asked to anyways?
A: We can *NOT*:
1) Enter a channel that is +i or +k without being invited or
having the key
2) See who is inside a +s channel
3) Op ourselves or op you on a channel (unless of course we are a
channel op for that channel)
4) Tell you what XXXX's new nick is since they changed it to hide
from you.
5) Deop someone for you on a channel (unless of course we are a
channel op for that channel)
Notice a trend, with the exception of 4, all of these are 100% channel
related. EFnet is made so that opers have *NO* power of channels, for
better or worse. If we don't help you with these requests, its not because
we won't, its because we are completely incapable doing so. On the other
hand....
Q: What can opers do, but won't?
A: This will be a bit differently done, because I figure I should explain
why opers don't do these things, when they may normally make sense.
1) Why won't they kill somebody who has stolen your nick.
EFnet has gone on the basis of nicks not being owned, which is
why there is no nickserv on EFnet. Of course we see opers kill
all the time for nicks, though, so it seems rather hypocrital,
doesn't it?
An oper who kills for his nick will tell you its because the
other person was a bot, was juping his nick, or was imitating an
oper. It may be true, but it really comes down to the same
feeling you get when your nick is taken "Hey! that's my name! I
don't want that person using my name!"
I personally, do not kill for nicks. If someone takes my nick,
they can have it. Let them get my several hundred messages a day.
:P But the problem with the oper is this: How does an oper know
that you are really the person that uses that nick, or are you
the guy that wants to nick jupe that nick out from the real guy?
Unless the oper knows you well, they don't.. And saying that
people generally tell the truth means you haven't been on EFnet
very long.
I would prefer to think I am one of the more well respected
people on the net and people still lie to me on a regular basis.
So, the oper is stuck refusing to help because he can't tell who
is who. Remember this line of reasoning, its going to be coming
up a lot. :P
2) Why won't they kill that guy nuking/smurfing/ping -f'ing me?
This one is simple. There is no way to prove that somebody is
doing any of these things to you from an opers point of view. All
logs are fakeable, and the oper has no way to firsthand prove its
happening. Your best bet in this situation is to log what you can
and complain loud and long to their ISPs.
3) Why won't they help me take my channel back?
There's a bunch of answers to this. First, it is popular
opinion at EFnet that channels are not owned, and therefore, if
you lose a channel, you should go make another one. Notice I
say popular instead of official, because EFnet has never had an
"official" policy on much of anything.
But more and more you see opers killing for takeovers, so why
are they helping their channels and not yours.
Well, first, let's say your channel was taken over, and is now
+smtinlk. How exactly is the oper supposed to find out who is
oped in the channel right now to mass kill them? Even if they do get
all the nicks, they have to somehow manage to kill them all in
one hit, or they'll all just op each other again and it will be
fruitless. Or worse, they could have it all set up, and some
other oper could kill them halfway through because they don't
like mass-kills and it would be all ruined.
Or, let's say the mass-kill goes off, then the channel is
opless and generally speaking, chaos begins. People start
mass-nuking or flooding the channel to clear it out, or just to
be annoying. And there's still a 50/50 chance that takeover
people will get the channel back on a split and we'll have to try
to do it all over again.
If you're about to ask why they don't split their server,
the answer is very simple: We are not about to screw up roughly
30,000 peoples chatting for your channel. Its rude. This of
course is all based on the fact that we can prove its taken over,
as per the conversation about nicks, we often can't.
4) But.. its obvious they took it from me! The topic says
"Ha ha, we took your channel Rick!" for Pete's sake! And
there's only One op, so you can kill him and get the channel
back immediately!
This one is a bit more complex, but its really a personal
call. That one op could be a rampant smurfpup with a penis so
tiny he has no choice but to rampantly smurf and synflood anyone
that gets in his way. This is popularly known on irc as SPS, or
Small Penis Syndrome. In this case, if the oper does help you
out, they could end up with their server being downed for a day
or two, and it really isn't worth it for your channel, no
offense.
Keep in mind that this is all spoken from the perspective of someone who
*DOES* help with channels when possible, but understands greatly the
reasons not to, and judges each situation very carefully.
That's the gist of the information I was trying to get across. If you
were cluefull enough to get on operlist, a lot of this may be common
knowledge to you, but sometimes its good to step back and see why opers do
what they do a lot of the time.
Hoping this is of value to SOMEONE....
Ray Powers
Monkster/MimePunk/PrimeMonk/PacMonk/MtgMonk/Ihavefartoomanynickstonickjupe

1
doc/reference.conf Executable file → Normal file
View file

@ -6,7 +6,6 @@
*
* Written by ejb, wcampbel, db, leeh and others
*
* $Id: reference.conf 3582 2007-11-17 21:55:48Z jilles $
*/
/* IMPORTANT NOTES:

10
doc/server-version-info → doc/server-version-info.txt
View file

@ -1,15 +1,15 @@
Server VERSION Info
$Id: server-version-info 1851 2006-08-24 17:16:53Z jilles $
Copyright (c) 2001 by ircd-hybrid team
Copyright (c) 2002 ircd-ratbox development team
Copyright (c) 2016 Charybdis development team
----------------------------------------------------------------------
When you type /version, you will often see something like this:
ircd-ratbox-1.0rc7(20021120_0). embers.lan egGHIKMpZ6 TS5ow
charybdis-3.5.0-rc1(20151011-d09bde1). joestar.interlinked.me :eIKMpSZ6 TS6ow 1US
Ever wondered what those funny chars mean after the version number? Well
here they are:
@ -17,10 +17,6 @@
+----------------------------+
| 'e' | USE_EXCEPT |
|------+---------------------|
| 'g' | NO_FAKE_GLINES |
|------+---------------------|
| 'G' | GLINES |
|------+---------------------|
| 'H' | HUB |
|------+---------------------|
| 'I' | USE_INVEX |
@ -43,7 +39,7 @@
|------+---------------------|
| 'TS' | Supports TS |
|------+---------------------|
| '5' | TS Version 5 |
| '6' | TS Version 6 |
|------+---------------------|
| 'o' | TS Only |
|------+---------------------|

330
doc/technical/README.TSora
View file

@ -1,330 +0,0 @@
Protocol changes for +TSora
---------------------------
Note:
The protocols described here implement TimeStamps on IRC channels and
nicks. The idea of IRC TimeStamps was started on Undernet, and first
implemented by Run <carlo@runaway.xs4all.nl>. The protocols used here
are not exactly the same as the ones used on Undernet; the nick-kill
handling is very similar and must be credited to Run, while the
"TimeStamped channel description" protocol is quite different.
TSora servers keep track of which version of the TS protocol (if any)
their neighboring servers are using, and take it into account when
sending messages to them. This allows for seamless integration of TS
servers into a non-TS net, and for upgrades of the protocol.
Each server knows which is the lowest and the highest version of the
TS protocol it can interact with; currently both of these are set to 1:
#define TS_CURRENT 1 /* the highest TS ver we can do */
#define TS_MIN 1 /* the lowest TS ver we can do */
Timings and TS versions:
========================
. Keep a 'delta' value to be added to the result of all calls to time(),
initially 0.
. Send a second argument to the PASS command, ending in the 'TS' string.
. Send a
SVINFO <TS_CURRENT> <TS_MIN> <STANDALONE> :<UTC-TIME>
just after "SERVER", where <STANDALONE> is 1 if we're connected to
more TSora servers, and 0 if not, and <UTC-TIME> is our idea of the
current UTC time, fixed with the delta.
. When we receive a "SVINFO <x> <y> <z> :<t>" line from a connecting
server, we ignore it if TS_CURRENT<y or x<TS_MIN, otherwise we
set a flag remembering that that server is TS-aware, remember the TS
version to use with it (min(TS_CURRENT, x)). Additionally, if this is
our first connected TS server, we set our delta to t-<OUR_UTC> if
z==0, and to (t-<OUR_UTC>)/2 if z!=0. The SVINFO data is kept around
until the server has effectively registered with SERVER, and used
*after* sending our own SVINFO to that server.
Explanations:
Servers will always know which of their directly-linked servers can do
TS, and will use the TS protocol only with servers that do understand
it. This makes it possible to switch to full TS in just one
code-replacement step, without incompatibilities.
As long as not all servers are TS-aware, the net will be divided into
"zones" of linked TS-aware servers. Channel modes will be kept
synchronized at least within the zone in which the channel was
created, and nick collisions between servers in the same zone will
result in only one client being killed.
Time synchronization ensures that servers have the same idea of the
current time, and achieves this purpose as long as TS servers are
introduced one by one within the same 'zone'. The merging of two zones
cannot synchronize them completely, but it is to be expected that
within each zone the effective time will be very close to the real
time.
By sending TSINFO after SERVER rather than before, we avoid the extra
lag created by the identd check on the server. To be able to send
immediately a connect burst of either type (TS or not), we need to
know before that if the server does TS or not, so we send that
information with PASS as an extra argument. And to avoid being
incompatible with 2.9 servers, which check that this second argument
begins with "2.9", we check that it *ends* with "TS".
The current time is only used when setting a TS on a new channel or
nick, and once such a TS is set, it is never modified because of
synchronization, as it is much more important that the TS for a
channel or nick stays the same across all servers than that it is
accurate to the second.
Note that Undernet's 2.8.x servers have no time synchronization at
all, and have had no problems because of it - all of this is more to
catch the occasional server with a way-off clock than anything.
NICK handling patches (anti-nick-collide + shorter connect burst):
==================================================================
. For each nick, store a TS value = the TS value received if any, or our
UTC+delta at the time we first heard of the nick. TS's are propagated
to TS-aware servers whenever sending a NICK command.
. Nick changes reset the TS to the current time.
. When sending a connect burst to another TS server, replace the
NICK/USER pair with only one NICK command containing the nick, the
hopcount, the TS, the umode, and all the USER information.
The format for a full NICK line is:
NICK <nick> <hops> <TS> <umode> <user> <host> <server> :<ircname>
The umode is a + followed by any applying usermodes.
The format for a nick-change NICK line is:
:<oldnick> NICK <newnick> :<TS>
. When a NICK is received from a TS server, that conflicts with an
existing nick:
+ if the userhosts differ or one is not known:
* if the timestamps are equal, kill ours and the old one if it
was a nick change
* if the incoming timestamp is older than ours, kill ours and
propagate the new one
* if the incoming timestamp is younger, ignore the line, but kill
the old nick if it was a nick change
+ if the userhosts are the same:
* if the timestamps are equal, kill ours and the old one if it
was a nick change
* if the incoming timestamp is younger, kill ours and propagate
the new one
* if the incoming timestamp is older, ignore the line but kill
the old nick if it was a nick change
. When a NICK is received from a non-TS server that conflicts with
an existing nick, kill both.
. Do not send "Fake Prefix" kills in response to lines coming from TS
servers; the sanitization works anyway, and this allows the "newer
nick overruled" case to work.
Explanations:
The modified nick-introduction syntax allows for a slightly shorter
connect-burst, and most importantly lets the server compare
user@host's when determining which nick to kill: if the user@host
is the same, then the older nick must be killed rather than the
newer.
When talking to a non-TS server, we need to behave exactly like one
because it expects us to. When talkign to a TS server, we don't kill
the nicks it's introducing, as we know it'll be smart enough to do it
itself when seeing our own introduced nick.
When we see a nick arriving from a non-TS server, it won't have a TS,
but it's safe enough to give it the current time rather than keeping
it 0; such TS's won't be the same all across the network (as long as
there is more than one TS zone), and when there's a collision, the TS
used will be the one in the zone the collision occurs in.
Also, it is important to note that by the time a server sees (and
chooses to ignore) a nick introduction, the introducing server has
also had the time to put umode changes for that nick on its queue, so
we must ignore them too... so we need to ignore fake-prefix lines
rather than sending kills for them. This is safe enough, as the rest
of the protocol ensures that they'll get killed anyway (and the
Undernet does it too, so it's been more than enough tested). Just for
an extra bit of compatibility, we still kill fake prefixes coming from
non-TS servers.
This part of the TS protocol is almost exactly the same as the
Undernet's .anc (anti-nick-collide) patches, except that Undernet
servers don't add usermodes to the NICK line.
TimeStamped channel descriptions (avoiding hacked ops and desynchs):
====================================================================
. For each channel, keep a timestamp, set to the current time when the
channel is created by a client on the local server, or to the received
value if the channel has been propagated from a TS server, or to 0
otherwise. This value will have the semantics of "the time of creation
of the current ops on the channel", and 0 will mean that the channel
is in non-TS mode.
A new server protocol command is introduced, SJOIN, which introduces
a full channel description: a timestamp, all the modes (except bans),
and the list of channel members with their ops and voices. This
command will be used instead of JOIN and of (most) MODEs both in
connect bursts and when propagating channel creations among TS
servers. SJOIN will never be accepted from or sent to users.
The syntax for the command is:
SJOIN <TS> #<channel> <modes> :[@][+]<nick_1> ... [@][+]<nick_n>
The fields have the following meanings:
* <TS> is the timestamp for the channel
* <modes> is the list of global channel modes, starting with a +
and a letter for each of the active modes (spmntkil), followed
by an argument for +l if there is a limit, and an argument for
+k if there's a key (in the same order they were mentioned in
the string of letters).
A channel with no modes will have a "+" in that field.
A special value of "0" means that the server does not specify the
modes, and will be used when more than one SJOIN line is needed
to completely describe a channel, or when propagating a SJOIN
the modes of which were rejected.
* Each nick is preceded by a "@" if the user has ops, and a "+" if
the user has a voice. For mode +ov, both flags are used.
SJOINs will be propagated (when appropriate) to neighboring TS
servers, and converted to JOINs and MODEs for neighboring non-TS
servers.
To propagate channels for which not all users fit in one
SJOIN line, several SJOINs will be sent consecutively, only the first
one including actual information in the <mode> field.
An extra ad-hoc restriction is imposed on SJOIN messages, to simplify
processing: if a channel has ops, then the first <nick> of the first
SJOIN sent to propagate that channel must be one of the ops.
Servers will never attempt to reconstruct a SJOIN from JOIN/MODE
information being received at the moment from other servers.
. For each user on a channel, keep an extra flag (like ops and voice)
that is set when the user has received channel ops from another
server (in a SJOIN channel description), which we rejected (ignored).
Mode changes (but NOT kicks) coming from a TS server and from someone
with this flag set will be ignored. The flag will be reset when the
user gets ops from another user or server.
. On deops done by non-local users, coming from TS servers, on channels
with a non-zero TS, do not check that the user has ops but check that
their 'deopped' flag is not set. For kicks coming from a TS server, do
not check either. This will avoid desynchs, and 'bad' modechanges are
avoided anyway. Other mode changes will still only be taken into
account and propagated when done by users that are seen as having ops.
. When a MODE change that ops someone is received from a server for a
channel, that channel's TS is set to 0, and the mode change is
propagated.
. When a SJOIN is received for a channel, deal with it in this way:
* received-TS = 0:
+ if we have ops or the SJOIN doesn't op anyone, SJOIN propagated
with our own TS.
+ otherwise, TS set to 0 and SJOIN propagated with 0.
* received-TS > 0, own-TS = 0:
+ if the SJOIN ops someone or we don't have ops, set our TS to the
received TS and propagate.
+ otherwise, propagate with TS = 0.
* received-TS = own-TS: propagate.
* received-TS < own-TS:
+ if the SJOIN ops someone, remove *all* modes (except bans) from
the channel and propagate these mode changes to all neighboring
non-TS servers, and copy the received TS and propagate the SJOIN.
+ if the SJOIN does not op anyone and we have ops, propagate
with our own TS.
+ otherwise, copy the received TS and propagate the SJOIN.
* received-TS > own-TS:
+ if the SJOIN does not introduce any ops, process and propagate
with our own TS.
+ if we have ops: for each person the mode change would op, set the
'deopped' flag; process all the JOINs ignoring the '@' and '+'
flags; propagate without the flags and with our TS.
+ if we don't have ops: set our TS to the received one, propagate
with the flags.
Explanations:
This part of the protocol is the one that is most different (and
incompatible) with the Undernet's: we never timestamp MODE changes,
but instead we introduce the concept of time-stamped channel
descriptions. This way each server can determine, based on its state
and the received description, what the correct modes for a channel
are, and deop its own users if necessary. With this protocol, there is
*never* the need to reverse and bounce back a mode change. This is
both faster and more bandwith-effective.
The end goal is to have a protocol will eventually protect channels
against hacked ops, while minimizing the impact on a mixed-server net.
In order to do this, whenever there is a conflict between a TS server
and a non-TS one, the non-TS one's idea of the whole situation
prevails. This means that channels will only have a TS when they have
been created on a TS-aware server, and will lose it whenever a server
op comes from a non-TS server. Also, at most one 'zone' will have a TS
for any given channel at any given time, ensuring that there won't be
any deops when zones are merged. However, when TS zones are merged, if
the side that has a TS also has ops, then the TS is kept across the
whole new zone. Effective protection will only be ensured once all
servers run TS patches and channels have been re-created, as there is
no way servers can assign a TS to a channel they are not creating
(like they do with nicks) without having unwanted deops later.
The visible effects of this timestamped channel-description protocol
are that when a split rejoins, and one side has hacked ops, the other
side doesn't see any server mode changes (just like with Undernet's
TS), but the side that has hacked ops sees:
* first the first server on the other side deopping and devoicing
everyone, and fixing the +spmntkli modes
* then other users joining, and getting server ops and voices
The less obvious part of this protocol is its behavior in the case
that the younger side of a rejoin has servers that are lagged with
each other. In such a situation, a SJOIN that clears all modes and
sets the legitimate ones is being propagated from one server, and
lagged illegitimate mode changes and kicks are being propagated in the
opposite direction. In this case, a kick done by someone who is being
deopped by the SJOIN must be taken into account to keep the name list
in sync (and since it can only be kicking someone who also was on the
younger side), while a deop does not matter (and will be ignored by
the first server on the other side), and an opping *needs* to be
discareded to avoid hacked ops.
The main property of timestamped channel descriptions that makes them
a very stable protocol even with lag and splits, is that they leave a
server in the same final state, independently of the order in which
channel descriptions coming from different servers are received. Even
when SJOINs and MODEs for the same channel are being propagated in
different direction because of several splits rejoining, the final
state will be the same, independently of the exact order in which each
server received the SJOINs, and will be the same across all the
servers in the same zone.

2
doc/technical/cluster.txt
View file

@ -1,5 +1,3 @@
$Id: cluster.txt 6 2005-09-10 01:02:21Z nenolod $
Short description of how remote kline and friends are propagated under
the old hyb7 style (CAP_KLN etc) and under the new style over ENCAP.

2
doc/technical/euid.txt
View file

@ -1,5 +1,3 @@
$Id: euid.txt 1863 2006-08-27 13:40:37Z jilles $
Extended UID command proposal
Jilles Tjoelker <jilles@stack.nl>

2
doc/technical/event.txt
View file

@ -1,8 +1,6 @@
Overview of the event subsystem
Adrian Chadd <adrian@creative.net.au>
$Id: event.txt 6 2005-09-10 01:02:21Z nenolod $
One of the things that immediately struck me whilst first looking at the
code was that the ircd periodically scheduled things in io_loop() but

47
doc/technical/fd-management.txt
View file

@ -1,47 +0,0 @@
Overview of the filedescriptor subsystem
Adrian Chadd <adrian@creative.net.au>
$Id: fd-management.txt 6 2005-09-10 01:02:21Z nenolod $
Filedescriptor lists
--------------------
The filedescriptor list is managed through the routines in fdlist.c .
These include:
fd_open() - tag an FD as "open" and active
fd_close() - tag an FD as "closed" and close() the filedescriptor
fd_note() - update the filedescriptor tag
You can get the current list of open filedescriptors through /stats F as
an oper.
FD lists
--------
The FD list support is very alpha. There are a few lists defined:
typedef enum fdlist_t {
FDLIST_NONE,
FDLIST_SERVICE,
FDLIST_SERVER,
FDLIST_IDLECLIENT,
FDLIST_BUSYCLIENT,
FDLIST_MAX
} fdlist_t;
FDLIST_NONE Not on any list (ie close()d)
FDLIST_SERVICE A service - listen() sockets, resolver, etc
FDLIST_SERVER Server connections
FDLIST_IDLECLIENT An idle client
FDLIST_BUSYCLIENT A busy client
FDLIST_MAX Used for bounds checking
The idea is that the SERVICE sockets need polling frequently, the SERVER
sockets also need polling frequently, BUSYCLIENT is for busy clients
which need frequent polling (eg we're trying to write to them), and
IDLECLIENT is for clients which we don't need to poll frequently.
THIS hasn't been decided upon yet.

1
doc/hooks.txt → doc/technical/hooks.txt
View file

@ -121,4 +121,3 @@ community.
"iorecv"
"iorecvctrl"
$Id: hooks.txt 3414 2007-04-15 16:54:50Z jilles $

1
doc/technical/hostmask.txt
View file

@ -1,6 +1,5 @@
The hostmask/netmask system.
Copyright(C) 2001 by Andrew Miller(A1kmm)<a1kmm@mware.virtualave.net>
$Id: hostmask.txt 6 2005-09-10 01:02:21Z nenolod $
Contents
========

21
doc/technical/index.txt
View file

@ -1,19 +1,10 @@
Technical Documentation for ircd-hybrid-7
Technical Documentation for Charybdis
Persistent_Clients.txt - A global UID and Persistent client (with cookies)
proposal
README.TSora - Description of the TS3 protocol
README.openssl - Information for users who have problems with
Hybrid, OpenSSL, and their operating system
cryptlink.txt - Outline of CRYPTLINK protocol
capab.txt - Description of server capabilities
cluster.txt - Technical description of the cluster system
euid.txt - Description of TS6 EUIDs
event.txt - Outline of the event system
fd-management.txt - Outline of the file descriptor management system
file-management.txt - Outline of the disk file management system
hooks.txt - Internal IRC daemon hoks
hostmask.txt - Outline of hostmask handling
linebuf.txt - Outline of the linebuf system (dbuf replacement)
network.txt - Outline of the network traffic subsystem
rfc1459.txt - The IRC RFC
send.txt - Document on all of the send_to functions
whats-new-code.txt - Whats changed in the code
# $Id: index.txt 6 2005-09-10 01:02:21Z nenolod $
ts6-protocol.txt - Description of the TS6 protocol

3
doc/technical/linebuf.txt
View file

@ -1,10 +1,7 @@
linebuf - a dbuf replacement for the New World Order(tm)
By Adrian Chadd <adrian@creative.net.au>
$Id: linebuf.txt 6 2005-09-10 01:02:21Z nenolod $
History
-------

105
doc/technical/network.txt
View file

@ -1,105 +0,0 @@
Overview of the network subsystem
Adrian Chadd <adrian@creative.net.au>
$Id: network.txt 6 2005-09-10 01:02:21Z nenolod $
This document is an overview of the new and hopefully improved network
subsystem.
The code is based loosely upon the network core found in the Squid web cache
server, with some optimizations for ircd-specific IO patterns.
Filedescriptor IO
-----------------
Filedescriptor IO is initiated using comm_setselect(). comm_setselect()
registers interest in reading from or writing to a file descriptor.
When a filedescriptor is ready for the required IO a callback is called
from the IO loop.
The comm_setselect() usage is:
void
comm_setselect(int fd, fdlist_t list, int type, PF *callback, void *cbdata,
int timeout)
where:
fd filedescriptor
list Which list the FD should be put on
type IO type. Can currently include:
COMM_SELECT_READ - register for read
COMM_SELECT_WRITE - register for write
callback Function to call when the FD is ready
cbdata Data to be passed to above function
timeout Update the timeout value. 0 is "don't update".
A typical use is:
..
/* Register interest in the FD for a read event */
comm_setselect(fd, FDLIST_SERVICE, COMM_SELECT_READ, read_callback, read_data,
0);
..
(FD becomes ready for read in the IO loop)
void
read_callback(int fd, void *data)
{
/* called when the FD becomes ready for read */
retval = read(fd, buf, len);
..
/* Ok, we need to read some more when its ready */
comm_setselect(fd, FDLIST_SERVICE, COMM_SELECT_READ, read_callback, data,
0);
}
Socket timeouts
---------------
A "socket timeout" is a callback registered to be called when a certain
amount of time has elapsed. Think of it as an event, but against a FD.
A good example of socket timeouts is in the comm_connect_tcp() code.
When the connect() begins, comm_settimeout() is called to call
comm_connect_timeout() if the timeout occurs. Once the connect() completes,
comm_settimeout() is called with a timeout of 0 and callback of NULL
to deregister the timeout. If the timeout occurs, comm_connect_timeout()
is called and the connection attempt is aborted.
Functions
---------
comm_open() - a socket() wrapper, enforcing fd limitations and tagging the
file descriptor with a note
comm_accept() - an accept() wrapper, enforcing fd limitations and tagging
the file descriptor with a note
comm_connect_tcp() - attempt an async connect(). Handles DNS lookups if
required, and will call the given callback at completion or error
comm_settimeout() - set a callback to be called after a given time period.
This is good to implement things like PING checks and connect() timeouts.
Notes:
* All socket creation should go through comm_open() / comm_accept().
* All socket closing should go through fd_close(). comm_close() isn't
implemented yet.
* comm_connect_tcp() is your best friend. :-)
* *ALL* network sockets should be non-blocking. If your OS doesn't support
non-blocking sockets, you shouldn't be here.

253
doc/technical/send.txt
View file

@ -1,253 +0,0 @@
send.c re-work
PREFIXES
========
Server prefixes are the ":%s" strings at the beginning of messages.
They are used by servers to route the message properly and by servers to
local clients to update their idea of who is whom.
":nick!user@host" is a prefix ":name" where name is either a nick
or name of a server is another valid prefix.
Typical prefix for a local client to a channel:
":Dianora!db@irc.db.net"
for a prefix to a remote server:
":Dianora"
e.g. as seen locally on a channel:
":Dianora!db@irc.db.net PRIVMSG #us-opers :ON TOP OF ...\r\n"
e.g. as seen sent to a remote server:
":Dianora PRIVMSG #us-opers :ON TOP OF ...\r\n"
It has been argued that full prefixes sent locally are a waste of bandwidth
(Isomer from Undernet has argued this). i.e. instead of sending:
":nick!user@host" for a local prefix, one could just send ":nick"..
Unfortunately, this breaks many clients badly. Personally I feel that
until clients are updated to understand that a full prefix isn't always
going to be sent, that this should be held off on.
As much as possible, prefix generation is now moved "upstairs" as
much as possible. i.e. if its known its a local client only, then the
onus of the prefix generation, is the users, not hidden in send.c
This allows somewhat faster code to be written, as the prefix doesn't
have to be regenerated over and over again.
Prefixes aren't sent in all cases, such as a new user using NICK
A prefix is needed when it must be routed.
i.e.
NICK newnick
There is obviously no prefix needed from a locally connected client.
FUNCTIONS
=========
sendto_one() - Should be used for _local_ clients only
it expects the prefix to be pre-built by user.
usage - sendto_one(struct Client *to, char *pattern, ...);
typical use:
sendto_one(acptr,":%s NOTICE %s :I'm tired", me.name,
acptr->name);
Note: This was from a server "me" hence only one
name in prefix.
This would be an example of a client sptr, noticing
acptr IF acptr is known to be a local client:
sendto_one(acptr,":%s!%s@%s NOTICE %s :You there?",
sptr->name,
sptr->username,
sptr->host,
acptr->name);
sendto_one_prefix()
- Sends a message to a remote client, with proper
prefix and target (name or UID).
usage - sendto_one_prefix(struct Client *target_p,
struct Client *source_p,
const char *command,
const char *pattern, ...)
typical use:
sendto_one_prefix(target_p, source_p, "INVITE", ":%s",
chptr->chname);
sendto_one_notice()
- Sends a notice from this server to target. Target may
be a local or remote client.
Prefix and target are chosen based on TS6 capability.
typical use:
sendto_one_notice(source_p, ":You suck. Yes, really.");
sendto_one_numeric()
- Sends a numeric from this server to target. Target may
be a local or remote client.
Prefix and target are chosen based on TS6 capability.
typical use:
sendto_one_numeric(source_p, RPL_STATSDEBUG,
"p :%u staff members", count);
sendto_channel_flags()
- This function sends a var args message to a channel globally,
except to the client specified as "one", the prefix
is built by this function on the fly as it has to
be sent both to local clients on this server and to
remote servers.
For type use one of:
ONLY_SERVERS ALL_MEMBERS ONLY_CHANOPS ONLY_CHANOPSVOICED
If type is not ALL_MEMBERS it's not sent to not-CHW-capable
servers.
Deaf (umode +D) clients are always skipped.
usage - sendto_channel_flags(struct Client *one,
int type,
struct Client *from,
struct Channel *chptr,
const char *pattern, ... );
sendto_channel_butone(cptr, ALL_MEMBERS, sptr, chptr
"PRIVMSG %s :HI!",
chptr->chname);
e.g. if channel message is coming from "cptr"
it must not be sent back to cptr.
sendto_server()
- This function sends specified var args message
to all connected servers except the client "one"
which have all of "caps" capabilities but none
of "nocaps" capabilities.
If "chptr" is not NULL and is a local channel,
nothing is sent.
usage - sendto_server(struct Client *one,
struct Channel *chptr,
unsigned long caps,
unsigned long nocaps,
const char *format, ... );
sendto_common_channels_local()
- This function is used only by m_nick and exit_one_client
its used to propagate nick changes to all channels user
is in, and QUIT messages to all channels user is in.
As it only sends to local clients, prefix generation
is left to the user. It also sends the message to the
user if the user isn't on any channels.
usage - sendto_common_channels_local(struct Client *user,
const char *pattern,
...);
sendto_channel_local()
- This function is used to send only locally, never
to remote servers. This is useful when removing
local chanops, or adding a local chanop. MODE/SJOIN
sent to remote server allows that server to propagate
mode changes to its clients locally.
The message is also sent to deaf (umode +D) clients.
usage - sendto_channel_local(int type,
struct Channel *chptr,
const char *pattern, ... );
prefix must be pre-built. type is a flag
denoting ONE of
ALL_MEMBERS - all members locally are sent to
ONLY_CHANOPS_VOICED - only chanops and voiced see this
ONLY_CHANOPS - only chanops see this
sendto_match_butone()
- only used for the old style oper masking
i.e. /msg #hostmask which in hyb7 is /msg $#hostmask
or /msg $servermask in hyb7 /msg $$servermask
usage - sendto_match_butone(struct Client *one,
struct Client *source_p,
char *mask,
int what,
const char *pattern, ... );
one is the client not to send to
mask is the actual mask
what is either MATCH_HOST or MATCH_SERVER
sendto_match_servs()
- Allows sending a message to servers whose names match
the given mask. A message is also sent to non-matching
servers which have matching servers behind them.
Used for ENCAP, remote kline, etc.
No message is sent to source_p->from.
usage - sendto_match_servs(struct Client *source_p,
const char *mask,
int cap, int nocap,
const char *pattern, ...);
sendto_anywhere()
- Allows the sending of a message to any client on the net
without knowing whether its local or remote. The penalty
is the calculation of a run-time prefix.
It is less efficient then sendto_one()
usage - sendto_anywhere(struct Client *to,
struct Client *from,
const char *command,
const char *pattern, ...);
e.g.
sendto_anywhere(target_p, source_p,
"PRIVMSG", ":Hi, Where ever you are");
sendto_realops_flags()
- combines old sendto_realops and sendto_realops_flags
sends specified message to opers locally only
depending on umodes. UMODE_ALL is UMODE_SERVNOTICE.
the message is sent as a server notice, prefixed with
"*** Notice -- ".
usage - sendto_realops_flags(int flags,
const char *pattern, ... );
e.g.
sendto_realops_flags(UMODE_ALL,
"Don't eat the yellow snow");
sendto_wallops_flags()
- sends specified message to opers/users locally,
depending on umodes. used for messages that need
to be in wallops form
- some policy decisions about who gets what live in here
usage - sendto_wallops_flags(int flags,
struct Client *, const char *patterm ...);
e.g.
sendto_wallops_flags(UMODE_LOCOPS,
sptr, "Message");
-- Diane Bruce
Updated Jan 2006 by jilles with ratbox and late hybrid7 changes
$Id: send.txt 587 2006-01-27 19:45:11Z jilles $

71
doc/technical/ts6-protocol.txt
View file

@ -1,5 +1,6 @@
TS6 protocol description
Written by Jilles Tjoelker
Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
General format: much like rfc1459
Maximum parameters for a command: 15 (this does not include the prefix
@ -18,6 +19,7 @@ nicknames and server names are accepted, possibly with wildcards; from servers,
UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
the function hunt_server(). Any rate limiting should be done locally.
duration: a parameter type used for ban durations. It is a duration in seconds.
A value of 0 means a permanent ban.
@ -112,6 +114,75 @@ type D
+g (allow any member to /invite)
+z (send messages blocked by +m to chanops)
Nick TS rules:
A server receiving a command that requires nick TS rules must check for a
collision between an existing user, and the nick in the received message.
(the "new user"). The collisions must obey the rules specified in Nick TS
collisions.
If the TS received is lower than the TS of the existing user the server will
collide the existing user if the clients user@host are different, if the
clients user@hosts are identical it will collide the new user.
If the TS received is equal to the TS of the existing user both clients are
collided.
If the TS received is higher than the TS of the existing user, the server
will collide the existing user if the user@hosts are identical, if the
clients user@host are different it will collide the new user and drop the
message.
Nick TS collisions:
If both users are to be collided, we must issue a KILL for the existing
user to all servers. If the new user has a UID then we must also issue a
KILL for that UID back to the server sending us data causing the collision.
If only the existing user is being collided, we must issue a KILL for the
existing user to all servers except the server sending us data. If the
existing user has a UID and the server sending us data supports TS6 then
we must also issue a KILL for the existing users UID to the server sending
us data.
If only the new user is being collided, we must issue a KILL for the new user
back to the server sending us data if the new user has a UID.
Channel TS rules:
A server receiving a command that requires normal channel TS rules must
apply the following rules to the command.
If the TS received is lower than our TS of the channel a TS6 server must
remove status modes (+ov etc) and channel modes (+nt etc). If the
originating server is TS6 capable (ie, it has a SID), the server must
also remove any ban modes (+b etc). The new modes and statuses are then
accepted.
If any bans are removed, the server must send to non-TS6, directly connected
servers mode changes removing the bans after the command is propagated.
This prevents desync with banlists, and has to be sent after as clients are
still able to send mode changes before the triggering command arrives.
If the TS received is equal to our TS of the channel the server should keep
its current modes and accept the received modes and statuses.
If the TS received is higher than our TS of the channel the server should keep
its current modes and ignore the received modes and statuses. Any statuses
given in the received message will be removed. A server must mark clients
losing their op (+o) status who do not have a UID as 'deopped'. A server must
ignore any "MODE" commands from a user marked as 'deopped'.
Simple channel TS rules:
A server receiving a command that requires simple channel TS rules must
apply the following rules to the command.
If the TS received is lower, or equal to our TS of the channel the modes are
accepted. If the TS received is higher than our TS of the channel the modes
are ignored and dropped.
Simple channel TS rules do not affect current modes in the channel except
for the modes we are accepting.
<numeric>
source: server
parameters: target, any...

299
doc/technical/ts6.txt
View file

@ -1,299 +0,0 @@
$Id: ts6.txt 3211 2007-02-20 00:34:28Z jilles $
TS6 Proposal (v8)
Written by Lee H <lee@leeh.co.uk>
Ideas borrowed heavily from ircnet (Beeth, jv, Q)
- Changes between v7 and v8 -
-----------------------------
In the v7 specification, the JOIN command included the channel modes of a
channel, and acted on them following TS rules. In the v8 specification,
JOIN will never send modes.
Desyncs can occur both when they are sent and when they are not. If they
are sent, then you can have a situation where a user on one side of the
network issues "MODE #channel -l", and a user on another side of the network
issues "JOIN #channel" whilst the +l still exists. As the JOIN string sent
server<->server includes the full modes at the time of the user joining,
this will propagate the +l, but there is a -l crossing in the other
direction. Desync will occur beyond where they intersect.
If the modes are not sent, then a lower TS JOIN command, or a JOIN command
that creates a channel will cause a desync.
It is judged that the desync with sending the modes is worse than the desync
by not sending them, as such the v8 specification dictates modes are not
sent with a JOIN command server<->server.
The v8 specification also clarifies that servers may issue TMODE.
- Introduction -
----------------
This document aims to fix some of the flaws that are still present in the
current TS system.
Whilst only one person may use a nickname at any one time, they are not
a reliable method of directing commands between servers. Clients can change
their nicknames, which can create desyncs. A reliable method of directing
messages between servers is required so that a message will always reach the
intended destination, even if the client changes nicks in between.
UID solves this problem by ensuring that a client has a unique ID for the
duration of his connection.
This document also aims to solve the lack of TS rules to channel 'bans' on
a netburst. Bans from both sides of a TS war (losing/winning) are kept.
Bursting the bans with a TS solves this problem.
There is also a race condition in the current TS system, where a user can
issue a mode during a netburst and the mode will be set on the server
we are bursting to.
- Definitions -
---------------
Throughout this document, the following terms are used:
SID - A servers unique ID. This is three characters long and must be in
the form [0-9][A-Z0-9][A-Z0-9]
ID - A clients unique ID. This is six characters long and must be in
the form [A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]. The
numbers [0-9] at the beginning of an ID are legal characters, but
reserved for future use.
UID - An ID concateneted to a SID. This forms the clients UID.
TS6 - The TS version 6.
- Support -
-----------
Support for this document is given by the TS version 6.
Wherever a destination parameter or source parameter is used, it must use
the SID or UID if the server/client has one. A TS6 capable server must
translate any SIDs/UIDs back into the server/clients name when communicating
with a server that does not support TS6.
A TS6 server must also support the QS (quitstorm) system, and the encap
specification found here:
http://www.leeh.co.uk/ircd/encap.txt
The TS6 protocol does not supports masked entities.
- Nick TS rules -
-----------------
A server receiving a command that requires nick TS rules must check for a
collision between an existing user, and the nick in the received message.
(the "new user"). The collisions must obey the rules specified in Nick TS
collisions.
If the TS received is lower than the TS of the existing user the server will
collide the existing user if the clients user@host are different, if the
clients user@hosts are identical it will collide the new user.
If the TS received is equal to the TS of the existing user both clients are
collided.
If the TS received is higher than the TS of the existing user, the server
will collide the existing user if the user@hosts are identical, if the
clients user@host are different it will collide the new user and drop the
message.
- Nick TS collisions -
----------------------
If both users are to be collided, we must issue a KILL for the existing
user to all servers. If the new user has a UID then we must also issue a
KILL for that UID back to the server sending us data causing the collision.
If only the existing user is being collided, we must issue a KILL for the
existing user to all servers except the server sending us data. If the
existing user has a UID and the server sending us data supports TS6 then
we must also issue a KILL for the existing users UID to the server sending
us data.
If only the new user is being collided, we must issue a KILL for the new user
back to the server sending us data if the new user has a UID.
- Channel TS rules -
--------------------
A server receiving a command that requires normal channel TS rules must
apply the following rules to the command.
If the TS received is lower than our TS of the channel a TS6 server must
remove status modes (+ov etc) and channel modes (+nt etc). If the
originating server is TS6 capable (ie, it has a SID), the server must
also remove any ban modes (+b etc). The new modes and statuses are then
accepted.
If any bans are removed, the server must send to non-TS6, directly connected
servers mode changes removing the bans after the command is propagated.
This prevents desync with banlists, and has to be sent after as clients are
still able to send mode changes before the triggering command arrives.
If the TS received is equal to our TS of the channel the server should keep
its current modes and accept the received modes and statuses.
If the TS received is higher than our TS of the channel the server should keep
its current modes and ignore the received modes and statuses. Any statuses
given in the received message will be removed. A server must mark clients
losing their op (+o) status who do not have a UID as 'deopped'. A server must
ignore any "MODE" commands from a user marked as 'deopped'.
- Simple channel TS rules -
---------------------------
A server receiving a command that requires simple channel TS rules must
apply the following rules to the command.
If the TS received is lower, or equal to our TS of the channel the modes are
accepted. If the TS received is higher than our TS of the channel the modes
are ignored and dropped.
Simple channel TS rules do not affect current modes in the channel except
for the modes we are accepting.
- The following commands are defined here as the TS6 protocol -
---------------------------------------------------------------
- PASS -
PASS <PASSWORD> TS <TS_CURRENT> :<SID>
This command is used for password verification with the server we are
connecting to.
Due to the burst being sent on verification of the "SERVER" command, and
"SVINFO" being sent after "SERVER", we need to be aware of the TS version
earlier to decide whether to send a TS6 burst or not.
The <PASSWORD> field is the password we have stored for this server,
<TS_CURRENT> is our current TS version. If this field is not present then
the server does not support TS6. <SID> is the SID of the server.
- UID -
:<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS>
This command is used for introducing clients to the network.
The <SID> field is the SID of the server the client is connected to.
The <NICK> field is the nick of the client being introduced. The <HOPS>
field is the amount of server hops between the server being burst to and
the server the client is on. The <TS> field is the TS of the client, either
the time they connected or the time they last changed nick. The <UMODE>
field contains the clients usermodes that need to be transmitted between
servers. The <USERNAME> field contains the clients username/ident. The
<HOSTNAME> field contains the clients host.
The <IP> field contains the clients IP. If the IP is not to be sent
(due to a spoof etc), the field must be sent as "0". The <UID> field is the
clients UID. The <GECOS> field is the clients gecos.
A server receiving a UID command must apply nick TS rules to the nick.
- SID -
:<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS>
This command is used for introducing servers to the network.
The first <SID> field is the SID of the new servers uplink. The
<SERVERNAME> field is the new servers name. The <HOPS> field is the hops
between the server being introduced nd the server being burst to.
The second <SID> field is the SID of the new server. The <GECOS> field i
is the new servers gecos.
Upon receiving the SID command servers must check for a SID collision.
Two servers must not be allowed to link to the network with the same SID.
If a server detects a SID collision it must drop the link to the directly
connected server through which the command was received.
Client and servers which do not have a UID/SID must be introduced by old
methods.
- SJOIN -
:<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS>
This command is used for introducing users to channels.
The <SID> field is the SID of the server introducing users to the channel.
The <TS> field is the channels current TS, <CHANNAME> is the channels
current name, <CHANMODES> are the channels current modes. <UIDS> is a
space delimited list of clients UIDs to join to the channel. Each clients
UID is prefixed with their status on the channel, ie "@UID" for an opped
user. Multiple prefixes are allowed, "peons" (clients without a status) are
not prefixed.
A server receiving an SJOIN must apply normal channel TS rules to the SJOIN.
A TS6 server must not use the SJOIN command outside of a netburst
to introduce a single user to an existing channel. It must instead
use the "JOIN" command defined in this specification. A TS6 server must
still use SJOIN for creating channels.
- JOIN -
:<UID> JOIN <TS> <CHANNAME> +
This command is used for introducing one user unopped to an existing channel.
The <UID> field is the UID of the client joining the channel. The
<TS> field is the channels current TS, <CHANNAME> is the channels
current name.
A server receiving a JOIN must apply normal channel TS rules to the JOIN.
No channel modes are sent with the JOIN command. In previous versions of
this specification, the "+" parameter contained the channels current modes.
A server following this version of the specification must not interpret this
argument and must not propagate any value other than "+" for this parameter.
It should be noted that whilst JOIN would not normally create a
channel or lower the timestamp, during specific conditions it can. This
can create a desync that this specification does not rectify.
- BMASK -
:<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS>
This command is used for bursting channel bans to a network.
The <SID> field is the SID of the server bursting the bans. The
<TS> field is the channels current TS, <CHANNAME> is the channels
name. <TYPE> is a single character identifying the mode type (ie,
for a ban 'b'). <MASKS> is a space delimited list of masks of the
given mode,limited only in length to the size of the buffer as defined
by RFC1459.
A server receiving a BMASK must apply simple channel TS rules to the BMASK.
A TS6 server must translate BMASKs into raw modes for non-TS6
capable servers. This command must be used only after SJOIN has
been sent for the given channel.
It should be noted however, that a BMASK with a lower TS should
not be possible without a desync, due to it being sent after
SJOIN.
- TMODE -
:<SID|UID> TMODE <TS> <CHANNAME> <MODESTRING>
This command is used for clients issuing modes on a channel.
<SID|UID> is either the UID of the client setting the mode, or the SID of
the server setting the mode. <TS> is the current TS of the channel,
<CHANNAME> is the channels name. <MODESTRING> is the raw mode the client is
setting.
A server receiving a TMODE must apply simple channel TS rules to the TMODE.
A TS6 server must translate MODEs issued by a local client, or received from
a server into TMODE to send to other TS6 capable servers.