mirror of
https://github.com/matrix-construct/construct
synced 2024-11-11 12:31:07 +01:00
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>
|
||||
anfl, Lee Hardy <lee -at- leeh.co.uk>
|
||||
beu, Elfyn McBratney <elfyn.mcbratney -at- gmail.com>
|
||||
Elizacat, Elizabeth Myers <elizabeth -at- interlinked.me>
|
||||
Elizafox, Elizabeth Myers <elizabeth -at- interlinked.me>
|
||||
Entrope, Michael Poole <mdpoole -at- trolius.org>
|
||||
gxti, Michael Tharp <gxti -at- partiallystapled.com>
|
||||
jdhore, JD Horelick <jdhore1 -at- gmail.com>
|
||||
|
@ -26,5 +26,8 @@ twincest, River Tarnell <river -at- attenuate.org>
|
|||
viatsko, Valerii Iatsko <dwr -at- codingbox.io>
|
||||
w00t, Robin Burchell <surreal.w00t -at- gmail.com>
|
||||
|
||||
For a list of contributors to ircd-ratbox, ircd-hyrbid, and ircd2.8 (the
|
||||
predecessors to Charybdis), see the doc/credits-past.txt file.
|
||||
|
||||
Visit the Charybdis website at: http://www.charybdis.io
|
||||
Visit us on IRC at: irc.freenode.net #charybdis
|
||||
|
|
316
doc/CIDR.txt
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@
|
||||
exec_prefix = @exec_prefix@
|
||||
exec_suffix = @exec_suffix@
|
||||
|
@ -8,8 +7,6 @@ sysconfdir = @sysconfdir@
|
|||
localstatedir = @localstatedir@
|
||||
|
||||
# Local to the etc Makefile
|
||||
mandir = @mandir@/man8
|
||||
MANPAGES = ircd.8
|
||||
|
||||
CONFS = ircd.conf.example reference.conf
|
||||
|
||||
|
@ -19,11 +16,6 @@ install-mkdirs:
|
|||
mkdir -p $(DESTDIR)$(sysconfdir); \
|
||||
fi
|
||||
|
||||
-@if test ! -d $(DESTDIR)$(mandir); then \
|
||||
echo "mkdir -p $(mandir)"; \
|
||||
mkdir -p $(DESTDIR)$(mandir); \
|
||||
fi
|
||||
|
||||
install: install-mkdirs
|
||||
@echo "ircd: installing example config files ($(CONFS))"
|
||||
@for i in $(CONFS); do \
|
||||
|
@ -42,9 +34,3 @@ install: install-mkdirs
|
|||
$(RM) $(DESTDIR)$(sysconfdir)/links.txt; \
|
||||
fi
|
||||
|
||||
@echo "ircd: installing manpage"
|
||||
@for i in $(MANPAGES); do \
|
||||
if test ! -f $(DESTDIR)$(mandir)/$(PROGRAM_PREFIX)$$i; then \
|
||||
$(INSTALL_DATA) $$i $(DESTDIR)$(mandir)/$(PROGRAM_PREFIX)$$i; \
|
||||
fi; \
|
||||
done
|
||||
|
|
|
@ -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
|
||||
* Copyright (C) 1990
|
||||
|
@ -135,3 +139,90 @@ Basalat Ali Raja <gwydion@tavi.rice.edu>
|
|||
Eric P. Scott <eps@toaster.sfsu.edu>
|
||||
Dan Goodwin <fornax@wpi.wpi.edu>
|
||||
Noah Friedman <friedman@ai.mit.edu>
|
||||
|
||||
|
||||
===============================================================================
|
||||
IRCD-HYBRID CREDITS
|
||||
===============================================================================
|
||||
|
||||
The hybrid team is a group of ircd coders who were frustrated
|
||||
with the instability and all-out "dirtiness" of the EFnet ircd's
|
||||
available. "hybrid" is the name for the collective efforts of a group
|
||||
of people, all of us.
|
||||
|
||||
Anyone is welcome to contribute to this effort. You are encouraged
|
||||
to participate in the Hybrid mailing list. To subscribe to the
|
||||
Hybrid List, use this link:
|
||||
https://lists.ircd-hybrid.org/mailman/listinfo/hybrid
|
||||
|
||||
The core team as, of this major release:
|
||||
|
||||
adx, Piotr Nizynski <adx@irc7.pl>
|
||||
billy-jon, William Bierman III <bill@mu.org>
|
||||
cryogen, Stuart Walsh <stu@ipng.org.uk>
|
||||
Dianora, Diane Bruce <db@db.net>
|
||||
joshk, Joshua Kwan <joshk@triplehelix.org>
|
||||
kire, Erik Small <smalle@hawaii.edu>
|
||||
knight, Alan LeVee <alan.levee@prometheus-designs.net>
|
||||
metalrock, Jack Low <jclow@csupomona.edu>
|
||||
Michael, Michael Wobst <michael.wobst@gmail.com>
|
||||
Rodder, Jon Lusky <lusky@blown.net>
|
||||
Wohali, Joan Touzet <joant@ieee.org>
|
||||
|
||||
The following people have contributed blood, sweat, and/or code to
|
||||
recent releases of Hybrid, in nick alphabetical order:
|
||||
|
||||
A1kmm, Andrew Miller <a1kmm@mware.virtualave.net>
|
||||
AndroSyn, Aaron Sethman <androsyn@ratbox.org>
|
||||
bane, Dragan Dosen <bane@idolnet.org>
|
||||
bysin, Ben Kittridge <bkittridge@cfl.rr.com>
|
||||
cosine, Patrick Alken <wnder@uwns.underworld.net>
|
||||
David-T, David Taylor <davidt@yadt.co.uk>
|
||||
fl, Lee Hardy <lee@leeh.co.uk>
|
||||
Garion, Joost Vunderink <garion@efnet.nl>
|
||||
Habeeb, David Supuran <habeeb@cfl.rr.com>
|
||||
Hwy101, W. Campbell <wcampbel@botbay.net>
|
||||
jmallett, Juli Mallett <jmallett@FreeBSD.org>
|
||||
jv, Jakub Vlasek <jv@pilsedu.cz>
|
||||
k9, Jeremy Chadwick <ircd@jdc.parodius.com>
|
||||
kre, Dinko Korunic <kreator@fly.srk.fer.hr>
|
||||
madmax, Paul Lomax <madmax@efnet.org>
|
||||
nenolod, William Pitcock <nenolod@nenolod.net>
|
||||
Riedel, Dennis Vink, <riedel@chaotic.nl>
|
||||
scuzzy, David Todd <scuzzy@aniverse.net>
|
||||
spookey, David Colburn <spookey@spookey.org>
|
||||
TimeMr14C, Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>
|
||||
toot, Toby Verrall <to7@antipope.fsnet.co.uk>
|
||||
vx0, Mark Miller <mark@oc768.net>
|
||||
wiz, Jason Dambrosio <jason@wiz.cx>
|
||||
Xride, Søren Straarup <xride@x12.dk>
|
||||
zb^3, Alfred Perlstein <alfred@freebsd.org>
|
||||
|
||||
Others are welcome. Always. And if we left anyone off the above list,
|
||||
be sure to let us know that too. Many others have contributed to
|
||||
previous versions of this ircd and its ancestors, too many to list
|
||||
here.
|
||||
|
||||
Send bug fixes/complaints/rotten tomatoes to bugs@ircd-hybrid.org.
|
||||
|
||||
|
||||
===============================================================================
|
||||
IRCD-RATBOX CREDITS
|
||||
===============================================================================
|
||||
|
||||
ircd-ratbox is an evolution where ircd-hybrid left off around version 7-rc1.
|
||||
Currently the ircd-ratbox team consists of the following developers:
|
||||
|
||||
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
|
||||
anfl, Lee Hardy <lee -at- leeh.co.uk>
|
||||
|
||||
Special thanks for support, code and ideas to:
|
||||
|
||||
Hwy, W. Campbell <wcampbel -at- botbay.net>
|
||||
jilles, Jilles Tjoelker <jilles -at- stack.nl>
|
||||
larne, Edward Brocklesby <ejb -at- sdf.lonestar.org>
|
||||
|
||||
Of course our work is based on the work of many, many others over the past
|
||||
10 or so years since irc has existed, including the work done by the Hybrid
|
||||
team, our thanks goes to them.
|
||||
|
|
@ -82,5 +82,3 @@ ratbox-respond/README for more information.
|
|||
A number of scripts for clients have already been written to automate this
|
||||
process, see client-scripts/README for more information.
|
||||
|
||||
--
|
||||
$Id: challenge.txt 678 2006-02-03 20:25:01Z jilles $
|
|
@ -43,5 +43,3 @@ the same on all servers for each nick-user pair, also if a user with a UID
|
|||
nick changes their nick but is collided again (the server detecting the
|
||||
collision will not propagate the nick change further).
|
||||
|
||||
--
|
||||
$Id: collision_fnc.txt 3422 2007-04-22 14:35:28Z jilles $
|
|
@ -88,5 +88,3 @@ The function is called whenever a (local) client needs to be checked against
|
|||
a +bqeI entry of the given extban type, and whenever a local client tries to
|
||||
add such an entry. (Clients are allowed to add bans matching themselves.)
|
||||
|
||||
--
|
||||
$Id: extban.txt 1639 2006-06-04 23:26:47Z jilles $
|
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
|
||||
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
|
||||
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
|
|
@ -127,4 +127,3 @@ Kucharski (IRCnet), IRC Client Capabilities Extension. March 2005.
|
|||
This internet-draft has expired; it can still be found on
|
||||
http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html
|
||||
|
||||
$Id: sasl.txt 3169 2007-01-28 22:13:18Z jilles $
|
|
@ -1,9 +1,12 @@
|
|||
ratbox-services compatibility documentation - Lee H <lee -at- leeh.co.uk>
|
||||
-------------------------------------------------------------------------
|
||||
Services compatibility documentation
|
||||
------------------------------------
|
||||
|
||||
Compatibility with ratbox-services is always enabled. Note that some or
|
||||
all of this is also used by atheme-services and anope. It will add the
|
||||
following features to ircd:
|
||||
Originally written by Lee Hardy for ircd-ratbox. Minor changes by Elizabeth
|
||||
Myers for modern services.
|
||||
|
||||
|
||||
Compatibility with services is always enabled. Supported services include
|
||||
atheme and anope. They add the following features to Charybdis:
|
||||
|
||||
1. Channel mode +r
|
||||
|
||||
|
@ -17,8 +20,8 @@ following features to ircd:
|
|||
|
||||
Ability to specify the names of services servers in ircd.conf:
|
||||
service {
|
||||
name = "services.ircd-ratbox.org";
|
||||
name = "backup-services.ircd-ratbox.org";
|
||||
name = "services.charybdis.io";
|
||||
name = "backup-services.charybdis.io";
|
||||
};
|
||||
|
||||
These must be specified for certain features to work. You may specify as
|
||||
|
@ -60,4 +63,3 @@ following features to ircd:
|
|||
Gives numeric 486 to users sending a PRIVMSG who are not logged in:
|
||||
:<server> 486 <nick> <targetnick> :You must log in with services to message this user
|
||||
|
||||
# $Id: services.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
@ -41,6 +41,3 @@ you are messaging that channel or a client within that channel. The latter
|
|||
can be done explicitly using the CNOTICE and CPRIVMSG commands, see
|
||||
/quote help cnotice and /quote help cprivmsg, but is also implicit in a
|
||||
normal /msg, /notice or /invite.
|
||||
|
||||
--
|
||||
$Id: tgchange.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
@ -1,28 +1,20 @@
|
|||
|
||||
# $Id: index.txt 6 2005-09-10 01:02:21Z nenolod $
|
||||
Here is the overview of the documents in the doc/ directory.
|
||||
|
||||
CIDR.txt - Description of CIDR in IPv4
|
||||
Tao-of-IRC.940110 - No comment...
|
||||
challenge.txt - Overview of the challenge/response system for
|
||||
obtaining operator status
|
||||
Subdirectories:
|
||||
|
||||
features/ - Documents about features and standards
|
||||
technical/ - Technical documents about ircd internals and
|
||||
protocol information
|
||||
sgml/ - SGML documentation
|
||||
|
||||
Files:
|
||||
|
||||
ircd.conf.example - An example ircd.conf file describing most of the
|
||||
user settable options
|
||||
guidelines.txt - Documentation guidelines
|
||||
hooks.txt - Overview of the hooks available
|
||||
index.txt - This file
|
||||
ircd.8 - The new revised manpage, read with the following
|
||||
commands in the prefix directory:
|
||||
man -M . ircd
|
||||
ircd.motd - A default ircd.motd used by make install
|
||||
credits-past.txt - Credits for the predecessors to Charybdis
|
||||
logfiles.txt - Description of formatting of some logfiles
|
||||
modeg.txt - An in depth description of the server side silence
|
||||
user mode (+g)
|
||||
modes.txt - A list of all user and channel modes
|
||||
operguide.txt - EFnet operator's guide
|
||||
opermyth.txt - Oper myth's, describes what opers can and cannot do
|
||||
server-version-info - Overview of the flags shown in /version
|
||||
whats-new.txt - What new features are available
|
||||
server-version-info.txt - Overview of the flags shown in /version
|
||||
|
||||
Also in the contrib/ directory you will find:
|
||||
example_module.c - An example module, detailing what the code in a module
|
||||
|
|
120
doc/ircd.8
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) 2005-2006 charybdis development team
|
||||
*
|
||||
* $Id: example.conf 3582 2007-11-17 21:55:48Z jilles $
|
||||
*
|
||||
* See reference.conf for more information.
|
||||
*/
|
||||
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
ircd-ratbox logfiles - Lee H <lee -at- leeh.co.uk>
|
||||
$Id: logfiles.txt 6 2005-09-10 01:02:21Z nenolod $
|
||||
Charybdis logfiles - Lee H <lee -at- leeh.co.uk>
|
||||
---------------------------
|
||||
|
||||
fname_killlog
|
||||
|
|
|
@ -4,7 +4,6 @@ Standard channel modes are listed in help/opers/cmode
|
|||
|
||||
The sgml docs have more detailed descriptions.
|
||||
|
||||
User mode +h (hide hostname) is provided by contrib/ip_cloaking.so
|
||||
User mode +x (hide hostname) is provided by contrib/ip_cloaking.so
|
||||
Server notice mask +F (far connects) is provided by contrib/sno_farconnect.so
|
||||
|
||||
# $Id: modes.txt 996 2006-03-09 01:14:34Z jilles $
|
||||
Information on the caller ID system can be found in doc/features/modeg.txt
|
||||
|
|
|
@ -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
|
||||
*
|
||||
* $Id: reference.conf 3582 2007-11-17 21:55:48Z jilles $
|
||||
*/
|
||||
|
||||
/* IMPORTANT NOTES:
|
||||
|
|
|
@ -1,15 +1,15 @@
|
|||
Server VERSION Info
|
||||
|
||||
$Id: server-version-info 1851 2006-08-24 17:16:53Z jilles $
|
||||
|
||||
Copyright (c) 2001 by ircd-hybrid team
|
||||
Copyright (c) 2002 ircd-ratbox development team
|
||||
Copyright (c) 2016 Charybdis development team
|
||||
|
||||
----------------------------------------------------------------------
|
||||
|
||||
When you type /version, you will often see something like this:
|
||||
|
||||
ircd-ratbox-1.0rc7(20021120_0). embers.lan egGHIKMpZ6 TS5ow
|
||||
charybdis-3.5.0-rc1(20151011-d09bde1). joestar.interlinked.me :eIKMpSZ6 TS6ow 1US
|
||||
|
||||
Ever wondered what those funny chars mean after the version number? Well
|
||||
here they are:
|
||||
|
@ -17,10 +17,6 @@
|
|||
+----------------------------+
|
||||
| 'e' | USE_EXCEPT |
|
||||
|------+---------------------|
|
||||
| 'g' | NO_FAKE_GLINES |
|
||||
|------+---------------------|
|
||||
| 'G' | GLINES |
|
||||
|------+---------------------|
|
||||
| 'H' | HUB |
|
||||
|------+---------------------|
|
||||
| 'I' | USE_INVEX |
|
||||
|
@ -43,7 +39,7 @@
|
|||
|------+---------------------|
|
||||
| 'TS' | Supports TS |
|
||||
|------+---------------------|
|
||||
| '5' | TS Version 5 |
|
||||
| '6' | TS Version 6 |
|
||||
|------+---------------------|
|
||||
| 'o' | TS Only |
|
||||
|------+---------------------|
|
|
@ -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
|
||||
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
|
||||
Jilles Tjoelker <jilles@stack.nl>
|
||||
|
||||
|
|
|
@ -1,8 +1,6 @@
|
|||
Overview of the event subsystem
|
||||
Adrian Chadd <adrian@creative.net.au>
|
||||
|
||||
$Id: event.txt 6 2005-09-10 01:02:21Z nenolod $
|
||||
|
||||
|
||||
One of the things that immediately struck me whilst first looking at the
|
||||
code was that the ircd periodically scheduled things in io_loop() but
|
||||
|
|
|
@ -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"
|
||||
"iorecvctrl"
|
||||
|
||||
$Id: hooks.txt 3414 2007-04-15 16:54:50Z jilles $
|
|
@ -1,6 +1,5 @@
|
|||
The hostmask/netmask system.
|
||||
Copyright(C) 2001 by Andrew Miller(A1kmm)<a1kmm@mware.virtualave.net>
|
||||
$Id: hostmask.txt 6 2005-09-10 01:02:21Z nenolod $
|
||||
|
||||
Contents
|
||||
========
|
||||
|
|
|
@ -1,19 +1,10 @@
|
|||
Technical Documentation for ircd-hybrid-7
|
||||
Technical Documentation for Charybdis
|
||||
|
||||
Persistent_Clients.txt - A global UID and Persistent client (with cookies)
|
||||
proposal
|
||||
README.TSora - Description of the TS3 protocol
|
||||
README.openssl - Information for users who have problems with
|
||||
Hybrid, OpenSSL, and their operating system
|
||||
cryptlink.txt - Outline of CRYPTLINK protocol
|
||||
capab.txt - Description of server capabilities
|
||||
cluster.txt - Technical description of the cluster system
|
||||
euid.txt - Description of TS6 EUIDs
|
||||
event.txt - Outline of the event system
|
||||
fd-management.txt - Outline of the file descriptor management system
|
||||
file-management.txt - Outline of the disk file management system
|
||||
hooks.txt - Internal IRC daemon hoks
|
||||
hostmask.txt - Outline of hostmask handling
|
||||
linebuf.txt - Outline of the linebuf system (dbuf replacement)
|
||||
network.txt - Outline of the network traffic subsystem
|
||||
rfc1459.txt - The IRC RFC
|
||||
send.txt - Document on all of the send_to functions
|
||||
whats-new-code.txt - Whats changed in the code
|
||||
|
||||
# $Id: index.txt 6 2005-09-10 01:02:21Z nenolod $
|
||||
ts6-protocol.txt - Description of the TS6 protocol
|
||||
|
|
|
@ -1,10 +1,7 @@
|
|||
|
||||
linebuf - a dbuf replacement for the New World Order(tm)
|
||||
|
||||
By Adrian Chadd <adrian@creative.net.au>
|
||||
|
||||
$Id: linebuf.txt 6 2005-09-10 01:02:21Z nenolod $
|
||||
|
||||
|
||||
History
|
||||
-------
|
||||
|
|
|
@ -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
|
||||
Written by Jilles Tjoelker
|
||||
Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
|
||||
|
||||
General format: much like rfc1459
|
||||
Maximum parameters for a command: 15 (this does not include the prefix
|
||||
|
@ -18,6 +19,7 @@ nicknames and server names are accepted, possibly with wildcards; from servers,
|
|||
UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
|
||||
the function hunt_server(). Any rate limiting should be done locally.
|
||||
|
||||
|
||||
duration: a parameter type used for ban durations. It is a duration in seconds.
|
||||
A value of 0 means a permanent ban.
|
||||
|
||||
|
@ -112,6 +114,75 @@ type D
|
|||
+g (allow any member to /invite)
|
||||
+z (send messages blocked by +m to chanops)
|
||||
|
||||
Nick TS rules:
|
||||
A server receiving a command that requires nick TS rules must check for a
|
||||
collision between an existing user, and the nick in the received message.
|
||||
(the "new user"). The collisions must obey the rules specified in Nick TS
|
||||
collisions.
|
||||
|
||||
If the TS received is lower than the TS of the existing user the server will
|
||||
collide the existing user if the clients user@host are different, if the
|
||||
clients user@hosts are identical it will collide the new user.
|
||||
|
||||
If the TS received is equal to the TS of the existing user both clients are
|
||||
collided.
|
||||
|
||||
If the TS received is higher than the TS of the existing user, the server
|
||||
will collide the existing user if the user@hosts are identical, if the
|
||||
clients user@host are different it will collide the new user and drop the
|
||||
message.
|
||||
|
||||
Nick TS collisions:
|
||||
If both users are to be collided, we must issue a KILL for the existing
|
||||
user to all servers. If the new user has a UID then we must also issue a
|
||||
KILL for that UID back to the server sending us data causing the collision.
|
||||
|
||||
If only the existing user is being collided, we must issue a KILL for the
|
||||
existing user to all servers except the server sending us data. If the
|
||||
existing user has a UID and the server sending us data supports TS6 then
|
||||
we must also issue a KILL for the existing users UID to the server sending
|
||||
us data.
|
||||
|
||||
If only the new user is being collided, we must issue a KILL for the new user
|
||||
back to the server sending us data if the new user has a UID.
|
||||
|
||||
Channel TS rules:
|
||||
A server receiving a command that requires normal channel TS rules must
|
||||
apply the following rules to the command.
|
||||
|
||||
If the TS received is lower than our TS of the channel a TS6 server must
|
||||
remove status modes (+ov etc) and channel modes (+nt etc). If the
|
||||
originating server is TS6 capable (ie, it has a SID), the server must
|
||||
also remove any ban modes (+b etc). The new modes and statuses are then
|
||||
accepted.
|
||||
|
||||
If any bans are removed, the server must send to non-TS6, directly connected
|
||||
servers mode changes removing the bans after the command is propagated.
|
||||
This prevents desync with banlists, and has to be sent after as clients are
|
||||
still able to send mode changes before the triggering command arrives.
|
||||
|
||||
If the TS received is equal to our TS of the channel the server should keep
|
||||
its current modes and accept the received modes and statuses.
|
||||
|
||||
If the TS received is higher than our TS of the channel the server should keep
|
||||
its current modes and ignore the received modes and statuses. Any statuses
|
||||
given in the received message will be removed. A server must mark clients
|
||||
losing their op (+o) status who do not have a UID as 'deopped'. A server must
|
||||
ignore any "MODE" commands from a user marked as 'deopped'.
|
||||
|
||||
Simple channel TS rules:
|
||||
|
||||
A server receiving a command that requires simple channel TS rules must
|
||||
apply the following rules to the command.
|
||||
|
||||
If the TS received is lower, or equal to our TS of the channel the modes are
|
||||
accepted. If the TS received is higher than our TS of the channel the modes
|
||||
are ignored and dropped.
|
||||
|
||||
Simple channel TS rules do not affect current modes in the channel except
|
||||
for the modes we are accepting.
|
||||
|
||||
|
||||
<numeric>
|
||||
source: server
|
||||
parameters: target, any...
|
||||
|
|
|
@ -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