Ginormous docs cleanup.
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:
parent
4dbb75ee84
commit
a5c46d31e4
42 changed files with 215 additions and 2439 deletions
5
CREDITS
5
CREDITS
|
@ -16,7 +16,7 @@ in nick-alphabetical order:
|
||||||
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
|
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
|
||||||
anfl, Lee Hardy <lee -at- leeh.co.uk>
|
anfl, Lee Hardy <lee -at- leeh.co.uk>
|
||||||
beu, Elfyn McBratney <elfyn.mcbratney -at- gmail.com>
|
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>
|
Entrope, Michael Poole <mdpoole -at- trolius.org>
|
||||||
gxti, Michael Tharp <gxti -at- partiallystapled.com>
|
gxti, Michael Tharp <gxti -at- partiallystapled.com>
|
||||||
jdhore, JD Horelick <jdhore1 -at- gmail.com>
|
jdhore, JD Horelick <jdhore1 -at- gmail.com>
|
||||||
|
@ -26,5 +26,8 @@ twincest, River Tarnell <river -at- attenuate.org>
|
||||||
viatsko, Valerii Iatsko <dwr -at- codingbox.io>
|
viatsko, Valerii Iatsko <dwr -at- codingbox.io>
|
||||||
w00t, Robin Burchell <surreal.w00t -at- gmail.com>
|
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 the Charybdis website at: http://www.charybdis.io
|
||||||
Visit us on IRC at: irc.freenode.net #charybdis
|
Visit us on IRC at: irc.freenode.net #charybdis
|
||||||
|
|
316
doc/CIDR.txt
316
doc/CIDR.txt
|
@ -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>
|
|
|
@ -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.
|
|
|
@ -1,4 +1,3 @@
|
||||||
# $Id: Makefile.in 3376 2007-04-03 11:37:39Z nenolod $
|
|
||||||
prefix = @prefix@
|
prefix = @prefix@
|
||||||
exec_prefix = @exec_prefix@
|
exec_prefix = @exec_prefix@
|
||||||
exec_suffix = @exec_suffix@
|
exec_suffix = @exec_suffix@
|
||||||
|
@ -8,8 +7,6 @@ sysconfdir = @sysconfdir@
|
||||||
localstatedir = @localstatedir@
|
localstatedir = @localstatedir@
|
||||||
|
|
||||||
# Local to the etc Makefile
|
# Local to the etc Makefile
|
||||||
mandir = @mandir@/man8
|
|
||||||
MANPAGES = ircd.8
|
|
||||||
|
|
||||||
CONFS = ircd.conf.example reference.conf
|
CONFS = ircd.conf.example reference.conf
|
||||||
|
|
||||||
|
@ -19,11 +16,6 @@ install-mkdirs:
|
||||||
mkdir -p $(DESTDIR)$(sysconfdir); \
|
mkdir -p $(DESTDIR)$(sysconfdir); \
|
||||||
fi
|
fi
|
||||||
|
|
||||||
-@if test ! -d $(DESTDIR)$(mandir); then \
|
|
||||||
echo "mkdir -p $(mandir)"; \
|
|
||||||
mkdir -p $(DESTDIR)$(mandir); \
|
|
||||||
fi
|
|
||||||
|
|
||||||
install: install-mkdirs
|
install: install-mkdirs
|
||||||
@echo "ircd: installing example config files ($(CONFS))"
|
@echo "ircd: installing example config files ($(CONFS))"
|
||||||
@for i in $(CONFS); do \
|
@for i in $(CONFS); do \
|
||||||
|
@ -42,9 +34,3 @@ install: install-mkdirs
|
||||||
$(RM) $(DESTDIR)$(sysconfdir)/links.txt; \
|
$(RM) $(DESTDIR)$(sysconfdir)/links.txt; \
|
||||||
fi
|
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
|
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
||||||
|
|
|
@ -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.
|
|
||||||
|
|
|
@ -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"
|
|
||||||
|
|
|
@ -1,3 +1,7 @@
|
||||||
|
===============================================================================
|
||||||
|
IRCD 2.8 CREDITS
|
||||||
|
===============================================================================
|
||||||
|
|
||||||
/************************************************************************
|
/************************************************************************
|
||||||
* IRC - Internet Relay Chat, doc/AUTHORS
|
* IRC - Internet Relay Chat, doc/AUTHORS
|
||||||
* Copyright (C) 1990
|
* Copyright (C) 1990
|
||||||
|
@ -135,3 +139,90 @@ Basalat Ali Raja <gwydion@tavi.rice.edu>
|
||||||
Eric P. Scott <eps@toaster.sfsu.edu>
|
Eric P. Scott <eps@toaster.sfsu.edu>
|
||||||
Dan Goodwin <fornax@wpi.wpi.edu>
|
Dan Goodwin <fornax@wpi.wpi.edu>
|
||||||
Noah Friedman <friedman@ai.mit.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.
|
||||||
|
|
|
@ -82,5 +82,3 @@ ratbox-respond/README for more information.
|
||||||
A number of scripts for clients have already been written to automate this
|
A number of scripts for clients have already been written to automate this
|
||||||
process, see client-scripts/README for more information.
|
process, see client-scripts/README for more information.
|
||||||
|
|
||||||
--
|
|
||||||
$Id: challenge.txt 678 2006-02-03 20:25:01Z jilles $
|
|
|
@ -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
|
nick changes their nick but is collided again (the server detecting the
|
||||||
collision will not propagate the nick change further).
|
collision will not propagate the nick change further).
|
||||||
|
|
||||||
--
|
|
||||||
$Id: collision_fnc.txt 3422 2007-04-22 14:35:28Z jilles $
|
|
|
@ -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
|
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.)
|
add such an entry. (Clients are allowed to add bans matching themselves.)
|
||||||
|
|
||||||
--
|
|
||||||
$Id: extban.txt 1639 2006-06-04 23:26:47Z jilles $
|
|
15
doc/features/index.txt
Normal file
15
doc/features/index.txt
Normal 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
|
|
@ -215,4 +215,3 @@ which is ambiguous if the user may contain a [ and in the author's opinion ugly.
|
||||||
--
|
--
|
||||||
W. Campbell
|
W. Campbell
|
||||||
updated by J. Tjoelker
|
updated by J. Tjoelker
|
||||||
$Id: modeg.txt 3556 2007-08-18 14:45:10Z jilles $
|
|
|
@ -1,6 +1,5 @@
|
||||||
MONITOR - Protocol for notification of when clients become online/offline
|
MONITOR - Protocol for notification of when clients become online/offline
|
||||||
Lee Hardy <lee -at- leeh.co.uk>
|
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
|
Currently, ISON requests by clients use a large amount of bandwidth. It is
|
|
@ -127,4 +127,3 @@ Kucharski (IRCnet), IRC Client Capabilities Extension. March 2005.
|
||||||
This internet-draft has expired; it can still be found on
|
This internet-draft has expired; it can still be found on
|
||||||
http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html
|
http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html
|
||||||
|
|
||||||
$Id: sasl.txt 3169 2007-01-28 22:13:18Z jilles $
|
|
|
@ -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
|
Originally written by Lee Hardy for ircd-ratbox. Minor changes by Elizabeth
|
||||||
all of this is also used by atheme-services and anope. It will add the
|
Myers for modern services.
|
||||||
following features to ircd:
|
|
||||||
|
|
||||||
|
Compatibility with services is always enabled. Supported services include
|
||||||
|
atheme and anope. They add the following features to Charybdis:
|
||||||
|
|
||||||
1. Channel mode +r
|
1. Channel mode +r
|
||||||
|
|
||||||
|
@ -17,8 +20,8 @@ following features to ircd:
|
||||||
|
|
||||||
Ability to specify the names of services servers in ircd.conf:
|
Ability to specify the names of services servers in ircd.conf:
|
||||||
service {
|
service {
|
||||||
name = "services.ircd-ratbox.org";
|
name = "services.charybdis.io";
|
||||||
name = "backup-services.ircd-ratbox.org";
|
name = "backup-services.charybdis.io";
|
||||||
};
|
};
|
||||||
|
|
||||||
These must be specified for certain features to work. You may specify as
|
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:
|
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
|
:<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 $
|
|
|
@ -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
|
can be done explicitly using the CNOTICE and CPRIVMSG commands, see
|
||||||
/quote help cnotice and /quote help cprivmsg, but is also implicit in a
|
/quote help cnotice and /quote help cprivmsg, but is also implicit in a
|
||||||
normal /msg, /notice or /invite.
|
normal /msg, /notice or /invite.
|
||||||
|
|
||||||
--
|
|
||||||
$Id: tgchange.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
|
@ -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.
|
Here is the overview of the documents in the doc/ directory.
|
||||||
|
|
||||||
CIDR.txt - Description of CIDR in IPv4
|
Subdirectories:
|
||||||
Tao-of-IRC.940110 - No comment...
|
|
||||||
challenge.txt - Overview of the challenge/response system for
|
features/ - Documents about features and standards
|
||||||
obtaining operator status
|
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
|
ircd.conf.example - An example ircd.conf file describing most of the
|
||||||
user settable options
|
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
|
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
|
logfiles.txt - Description of formatting of some logfiles
|
||||||
modeg.txt - An in depth description of the server side silence
|
server-version-info.txt - Overview of the flags shown in /version
|
||||||
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
|
|
||||||
|
|
||||||
Also in the contrib/ directory you will find:
|
Also in the contrib/ directory you will find:
|
||||||
example_module.c - An example module, detailing what the code in a module
|
example_module.c - An example module, detailing what the code in a module
|
||||||
|
|
120
doc/ircd.8
120
doc/ircd.8
|
@ -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
2
doc/ircd.conf.example
Executable file → Normal file
|
@ -4,8 +4,6 @@
|
||||||
* Copyright (C) 2002-2005 ircd-ratbox development team
|
* Copyright (C) 2002-2005 ircd-ratbox development team
|
||||||
* Copyright (C) 2005-2006 charybdis 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.
|
* See reference.conf for more information.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
|
|
@ -1,5 +1,4 @@
|
||||||
ircd-ratbox logfiles - Lee H <lee -at- leeh.co.uk>
|
Charybdis logfiles - Lee H <lee -at- leeh.co.uk>
|
||||||
$Id: logfiles.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
fname_killlog
|
fname_killlog
|
||||||
|
|
|
@ -4,7 +4,6 @@ Standard channel modes are listed in help/opers/cmode
|
||||||
|
|
||||||
The sgml docs have more detailed descriptions.
|
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
|
Server notice mask +F (far connects) is provided by contrib/sno_farconnect.so
|
||||||
|
Information on the caller ID system can be found in doc/features/modeg.txt
|
||||||
# $Id: modes.txt 996 2006-03-09 01:14:34Z jilles $
|
|
||||||
|
|
|
@ -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
137
doc/opermyth.txt
|
@ -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
1
doc/reference.conf
Executable file → Normal file
|
@ -6,7 +6,6 @@
|
||||||
*
|
*
|
||||||
* Written by ejb, wcampbel, db, leeh and others
|
* Written by ejb, wcampbel, db, leeh and others
|
||||||
*
|
*
|
||||||
* $Id: reference.conf 3582 2007-11-17 21:55:48Z jilles $
|
|
||||||
*/
|
*/
|
||||||
|
|
||||||
/* IMPORTANT NOTES:
|
/* IMPORTANT NOTES:
|
||||||
|
|
|
@ -1,15 +1,15 @@
|
||||||
Server VERSION Info
|
Server VERSION Info
|
||||||
|
|
||||||
$Id: server-version-info 1851 2006-08-24 17:16:53Z jilles $
|
|
||||||
|
|
||||||
Copyright (c) 2001 by ircd-hybrid team
|
Copyright (c) 2001 by ircd-hybrid team
|
||||||
Copyright (c) 2002 ircd-ratbox development 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:
|
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
|
Ever wondered what those funny chars mean after the version number? Well
|
||||||
here they are:
|
here they are:
|
||||||
|
@ -17,10 +17,6 @@
|
||||||
+----------------------------+
|
+----------------------------+
|
||||||
| 'e' | USE_EXCEPT |
|
| 'e' | USE_EXCEPT |
|
||||||
|------+---------------------|
|
|------+---------------------|
|
||||||
| 'g' | NO_FAKE_GLINES |
|
|
||||||
|------+---------------------|
|
|
||||||
| 'G' | GLINES |
|
|
||||||
|------+---------------------|
|
|
||||||
| 'H' | HUB |
|
| 'H' | HUB |
|
||||||
|------+---------------------|
|
|------+---------------------|
|
||||||
| 'I' | USE_INVEX |
|
| 'I' | USE_INVEX |
|
||||||
|
@ -43,7 +39,7 @@
|
||||||
|------+---------------------|
|
|------+---------------------|
|
||||||
| 'TS' | Supports TS |
|
| 'TS' | Supports TS |
|
||||||
|------+---------------------|
|
|------+---------------------|
|
||||||
| '5' | TS Version 5 |
|
| '6' | TS Version 6 |
|
||||||
|------+---------------------|
|
|------+---------------------|
|
||||||
| 'o' | TS Only |
|
| 'o' | TS Only |
|
||||||
|------+---------------------|
|
|------+---------------------|
|
|
@ -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.
|
|
||||||
|
|
||||||
|
|
|
@ -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
|
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.
|
the old hyb7 style (CAP_KLN etc) and under the new style over ENCAP.
|
||||||
|
|
||||||
|
|
|
@ -1,5 +1,3 @@
|
||||||
$Id: euid.txt 1863 2006-08-27 13:40:37Z jilles $
|
|
||||||
|
|
||||||
Extended UID command proposal
|
Extended UID command proposal
|
||||||
Jilles Tjoelker <jilles@stack.nl>
|
Jilles Tjoelker <jilles@stack.nl>
|
||||||
|
|
||||||
|
|
|
@ -1,8 +1,6 @@
|
||||||
Overview of the event subsystem
|
Overview of the event subsystem
|
||||||
Adrian Chadd <adrian@creative.net.au>
|
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
|
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
|
code was that the ircd periodically scheduled things in io_loop() but
|
||||||
|
|
|
@ -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.
|
|
|
@ -121,4 +121,3 @@ community.
|
||||||
"iorecv"
|
"iorecv"
|
||||||
"iorecvctrl"
|
"iorecvctrl"
|
||||||
|
|
||||||
$Id: hooks.txt 3414 2007-04-15 16:54:50Z jilles $
|
|
|
@ -1,6 +1,5 @@
|
||||||
The hostmask/netmask system.
|
The hostmask/netmask system.
|
||||||
Copyright(C) 2001 by Andrew Miller(A1kmm)<a1kmm@mware.virtualave.net>
|
Copyright(C) 2001 by Andrew Miller(A1kmm)<a1kmm@mware.virtualave.net>
|
||||||
$Id: hostmask.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
||||||
|
|
||||||
Contents
|
Contents
|
||||||
========
|
========
|
||||||
|
|
|
@ -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)
|
capab.txt - Description of server capabilities
|
||||||
proposal
|
cluster.txt - Technical description of the cluster system
|
||||||
README.TSora - Description of the TS3 protocol
|
euid.txt - Description of TS6 EUIDs
|
||||||
README.openssl - Information for users who have problems with
|
|
||||||
Hybrid, OpenSSL, and their operating system
|
|
||||||
cryptlink.txt - Outline of CRYPTLINK protocol
|
|
||||||
event.txt - Outline of the event system
|
event.txt - Outline of the event system
|
||||||
fd-management.txt - Outline of the file descriptor management system
|
hooks.txt - Internal IRC daemon hoks
|
||||||
file-management.txt - Outline of the disk file management system
|
|
||||||
hostmask.txt - Outline of hostmask handling
|
hostmask.txt - Outline of hostmask handling
|
||||||
linebuf.txt - Outline of the linebuf system (dbuf replacement)
|
linebuf.txt - Outline of the linebuf system (dbuf replacement)
|
||||||
network.txt - Outline of the network traffic subsystem
|
ts6-protocol.txt - Description of the TS6 protocol
|
||||||
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 $
|
|
||||||
|
|
|
@ -1,10 +1,7 @@
|
||||||
|
|
||||||
linebuf - a dbuf replacement for the New World Order(tm)
|
linebuf - a dbuf replacement for the New World Order(tm)
|
||||||
|
|
||||||
By Adrian Chadd <adrian@creative.net.au>
|
By Adrian Chadd <adrian@creative.net.au>
|
||||||
|
|
||||||
$Id: linebuf.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
||||||
|
|
||||||
|
|
||||||
History
|
History
|
||||||
-------
|
-------
|
||||||
|
|
|
@ -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.
|
|
|
@ -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 $
|
|
|
@ -1,5 +1,6 @@
|
||||||
TS6 protocol description
|
TS6 protocol description
|
||||||
Written by Jilles Tjoelker
|
Written by Jilles Tjoelker
|
||||||
|
Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
|
||||||
|
|
||||||
General format: much like rfc1459
|
General format: much like rfc1459
|
||||||
Maximum parameters for a command: 15 (this does not include the prefix
|
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
|
UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
|
||||||
the function hunt_server(). Any rate limiting should be done locally.
|
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.
|
duration: a parameter type used for ban durations. It is a duration in seconds.
|
||||||
A value of 0 means a permanent ban.
|
A value of 0 means a permanent ban.
|
||||||
|
|
||||||
|
@ -112,6 +114,75 @@ type D
|
||||||
+g (allow any member to /invite)
|
+g (allow any member to /invite)
|
||||||
+z (send messages blocked by +m to chanops)
|
+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>
|
<numeric>
|
||||||
source: server
|
source: server
|
||||||
parameters: target, any...
|
parameters: target, any...
|
||||||
|
|
|
@ -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.
|
|
||||||
|
|
Loading…
Reference in a new issue