diff --git a/CREDITS b/CREDITS index 9ed4511b2..5e72d146e 100644 --- a/CREDITS +++ b/CREDITS @@ -16,7 +16,7 @@ in nick-alphabetical order: AndroSyn, Aaron Sethman anfl, Lee Hardy beu, Elfyn McBratney -Elizacat, Elizabeth Myers +Elizafox, Elizabeth Myers Entrope, Michael Poole gxti, Michael Tharp jdhore, JD Horelick @@ -25,6 +25,9 @@ ThaPrince, Jon Christopherson twincest, River Tarnell viatsko, Valerii Iatsko w00t, Robin Burchell - + +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 diff --git a/doc/CIDR.txt b/doc/CIDR.txt deleted file mode 100644 index ddb514f33..000000000 --- a/doc/CIDR.txt +++ /dev/null @@ -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 @whois.arin.net", while under FreeBSD it is - "whois -h whois.arin.net " 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 " 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 -Piotr Kucharski -W. Campbell and -Ariel Biener diff --git a/doc/Hybrid-team b/doc/Hybrid-team deleted file mode 100644 index d193166f4..000000000 --- a/doc/Hybrid-team +++ /dev/null @@ -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 -billy-jon, William Bierman III -cryogen, Stuart Walsh -Dianora, Diane Bruce -joshk, Joshua Kwan -kire, Erik Small -knight, Alan LeVee -metalrock, Jack Low -Michael, Michael Wobst -Rodder, Jon Lusky -Wohali, Joan Touzet - -The following people have contributed blood, sweat, and/or code to -recent releases of Hybrid, in nick alphabetical order: - -A1kmm, Andrew Miller -AndroSyn, Aaron Sethman -bane, Dragan Dosen -bysin, Ben Kittridge -cosine, Patrick Alken -David-T, David Taylor -fl, Lee Hardy -Garion, Joost Vunderink -Habeeb, David Supuran -Hwy101, W. Campbell -jmallett, Juli Mallett -jv, Jakub Vlasek -k9, Jeremy Chadwick -kre, Dinko Korunic -madmax, Paul Lomax -nenolod, William Pitcock -Riedel, Dennis Vink, -scuzzy, David Todd -spookey, David Colburn -TimeMr14C, Yusuf Iskenderoglu -toot, Toby Verrall -vx0, Mark Miller -wiz, Jason Dambrosio -Xride, Søren Straarup -zb^3, Alfred Perlstein - -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. diff --git a/doc/Makefile.am b/doc/Makefile.am index 801f594ad..b49667f39 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -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 diff --git a/doc/README.cidr_bans b/doc/README.cidr_bans deleted file mode 100644 index 7ca9b5fa9..000000000 --- a/doc/README.cidr_bans +++ /dev/null @@ -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 -August 06, 2002 - - diff --git a/doc/Ratbox-team b/doc/Ratbox-team deleted file mode 100644 index b99dcd0a4..000000000 --- a/doc/Ratbox-team +++ /dev/null @@ -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 -anfl, Lee Hardy - -Special thanks for support, code and ideas to: - -Hwy, W. Campbell -jilles, Jilles Tjoelker -larne, Edward Brocklesby - -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. - diff --git a/doc/Tao-of-IRC.940110 b/doc/Tao-of-IRC.940110 deleted file mode 100644 index fa2f55996..000000000 --- a/doc/Tao-of-IRC.940110 +++ /dev/null @@ -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" - diff --git a/doc/old/Authors b/doc/credits-past.txt similarity index 60% rename from doc/old/Authors rename to doc/credits-past.txt index 0051d0b1d..773c029aa 100644 --- a/doc/old/Authors +++ b/doc/credits-past.txt @@ -1,3 +1,7 @@ +=============================================================================== +IRCD 2.8 CREDITS +=============================================================================== + /************************************************************************ * IRC - Internet Relay Chat, doc/AUTHORS * Copyright (C) 1990 @@ -135,3 +139,90 @@ Basalat Ali Raja Eric P. Scott Dan Goodwin Noah Friedman + + +=============================================================================== +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 +billy-jon, William Bierman III +cryogen, Stuart Walsh +Dianora, Diane Bruce +joshk, Joshua Kwan +kire, Erik Small +knight, Alan LeVee +metalrock, Jack Low +Michael, Michael Wobst +Rodder, Jon Lusky +Wohali, Joan Touzet + +The following people have contributed blood, sweat, and/or code to +recent releases of Hybrid, in nick alphabetical order: + +A1kmm, Andrew Miller +AndroSyn, Aaron Sethman +bane, Dragan Dosen +bysin, Ben Kittridge +cosine, Patrick Alken +David-T, David Taylor +fl, Lee Hardy +Garion, Joost Vunderink +Habeeb, David Supuran +Hwy101, W. Campbell +jmallett, Juli Mallett +jv, Jakub Vlasek +k9, Jeremy Chadwick +kre, Dinko Korunic +madmax, Paul Lomax +nenolod, William Pitcock +Riedel, Dennis Vink, +scuzzy, David Todd +spookey, David Colburn +TimeMr14C, Yusuf Iskenderoglu +toot, Toby Verrall +vx0, Mark Miller +wiz, Jason Dambrosio +Xride, Søren Straarup +zb^3, Alfred Perlstein + +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 +anfl, Lee Hardy + +Special thanks for support, code and ideas to: + +Hwy, W. Campbell +jilles, Jilles Tjoelker +larne, Edward Brocklesby + +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. + diff --git a/doc/account-notify.txt b/doc/features/account-notify.txt similarity index 100% rename from doc/account-notify.txt rename to doc/features/account-notify.txt diff --git a/doc/away-notify.txt b/doc/features/away-notify.txt similarity index 100% rename from doc/away-notify.txt rename to doc/features/away-notify.txt diff --git a/doc/challenge.txt b/doc/features/challenge.txt similarity index 98% rename from doc/challenge.txt rename to doc/features/challenge.txt index 3a0771108..88a506bb1 100644 --- a/doc/challenge.txt +++ b/doc/features/challenge.txt @@ -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 $ diff --git a/doc/collision_fnc.txt b/doc/features/collision_fnc.txt similarity index 96% rename from doc/collision_fnc.txt rename to doc/features/collision_fnc.txt index 397c0679b..fa6f02d29 100644 --- a/doc/collision_fnc.txt +++ b/doc/features/collision_fnc.txt @@ -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 $ diff --git a/doc/extban.txt b/doc/features/extban.txt similarity index 98% rename from doc/extban.txt rename to doc/features/extban.txt index 79e71ca50..5f49fdcf3 100644 --- a/doc/extban.txt +++ b/doc/features/extban.txt @@ -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 $ diff --git a/doc/extended-join.txt b/doc/features/extended-join.txt similarity index 100% rename from doc/extended-join.txt rename to doc/features/extended-join.txt diff --git a/doc/features/index.txt b/doc/features/index.txt new file mode 100644 index 000000000..3d0661e5f --- /dev/null +++ b/doc/features/index.txt @@ -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 diff --git a/doc/modeg.txt b/doc/features/modeg.txt similarity index 99% rename from doc/modeg.txt rename to doc/features/modeg.txt index 1e05ed4bc..d99736a92 100644 --- a/doc/modeg.txt +++ b/doc/features/modeg.txt @@ -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 $ diff --git a/doc/monitor.txt b/doc/features/monitor.txt similarity index 98% rename from doc/monitor.txt rename to doc/features/monitor.txt index 8a6dbcab1..e31adb0ec 100644 --- a/doc/monitor.txt +++ b/doc/features/monitor.txt @@ -1,6 +1,5 @@ MONITOR - Protocol for notification of when clients become online/offline Lee Hardy -$Id: monitor.txt 3520 2007-06-30 22:15:35Z jilles $ ------------------------------------------------------------------------- Currently, ISON requests by clients use a large amount of bandwidth. It is diff --git a/doc/sasl.txt b/doc/features/sasl.txt similarity index 99% rename from doc/sasl.txt rename to doc/features/sasl.txt index 59b459c1b..f1155a89a 100644 --- a/doc/sasl.txt +++ b/doc/features/sasl.txt @@ -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 $ diff --git a/doc/services.txt b/doc/features/services.txt similarity index 79% rename from doc/services.txt rename to doc/features/services.txt index ee2d1df92..c2d8a9ab7 100644 --- a/doc/services.txt +++ b/doc/features/services.txt @@ -1,9 +1,12 @@ -ratbox-services compatibility documentation - Lee H -------------------------------------------------------------------------- +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: : 486 :You must log in with services to message this user -# $Id: services.txt 6 2005-09-10 01:02:21Z nenolod $ diff --git a/doc/tgchange.txt b/doc/features/tgchange.txt similarity index 97% rename from doc/tgchange.txt rename to doc/features/tgchange.txt index faea0090a..e0323f28d 100644 --- a/doc/tgchange.txt +++ b/doc/features/tgchange.txt @@ -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 $ diff --git a/doc/index.txt b/doc/index.txt index 3d8766b64..aebf398b0 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -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 diff --git a/doc/ircd.8 b/doc/ircd.8 deleted file mode 100644 index f3a349bda..000000000 --- a/doc/ircd.8 +++ /dev/null @@ -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 diff --git a/doc/ircd.conf.example b/doc/ircd.conf.example old mode 100755 new mode 100644 index 79e58388d..49951a5ef --- a/doc/ircd.conf.example +++ b/doc/ircd.conf.example @@ -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. */ diff --git a/doc/logfiles.txt b/doc/logfiles.txt index a05eae904..8c5b68024 100644 --- a/doc/logfiles.txt +++ b/doc/logfiles.txt @@ -1,5 +1,4 @@ -ircd-ratbox logfiles - Lee H -$Id: logfiles.txt 6 2005-09-10 01:02:21Z nenolod $ +Charybdis logfiles - Lee H --------------------------- fname_killlog diff --git a/doc/modes.txt b/doc/modes.txt index e51c1c910..aa948d12d 100644 --- a/doc/modes.txt +++ b/doc/modes.txt @@ -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 diff --git a/doc/operguide.txt b/doc/operguide.txt deleted file mode 100644 index 132d4df2e..000000000 --- a/doc/operguide.txt +++ /dev/null @@ -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 $ diff --git a/doc/opermyth.txt b/doc/opermyth.txt deleted file mode 100644 index ef6b6373d..000000000 --- a/doc/opermyth.txt +++ /dev/null @@ -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 - diff --git a/doc/reference.conf b/doc/reference.conf old mode 100755 new mode 100644 index b3ff2580f..19e337c56 --- a/doc/reference.conf +++ b/doc/reference.conf @@ -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: diff --git a/doc/server-version-info b/doc/server-version-info.txt similarity index 82% rename from doc/server-version-info rename to doc/server-version-info.txt index 5315729d1..6019ee73c 100644 --- a/doc/server-version-info +++ b/doc/server-version-info.txt @@ -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 | |------+---------------------| diff --git a/doc/technical/README.TSora b/doc/technical/README.TSora deleted file mode 100644 index c99dc05c1..000000000 --- a/doc/technical/README.TSora +++ /dev/null @@ -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 . 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 : - - just after "SERVER", where is 1 if we're connected to - more TSora servers, and 0 if not, and is our idea of the - current UTC time, fixed with the delta. - -. When we receive a "SVINFO :" line from a connecting - server, we ignore it if TS_CURRENT if - z==0, and to (t-)/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 : - - The umode is a + followed by any applying usermodes. - - The format for a nick-change NICK line is: - : NICK : - -. 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 # :[@][+] ... [@][+] - - The fields have the following meanings: - - * is the timestamp for the channel - - * 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 field. - - An extra ad-hoc restriction is imposed on SJOIN messages, to simplify - processing: if a channel has ops, then the first 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. - - diff --git a/doc/technical/cluster.txt b/doc/technical/cluster.txt index 0d2844739..16c8fd905 100644 --- a/doc/technical/cluster.txt +++ b/doc/technical/cluster.txt @@ -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. diff --git a/doc/technical/euid.txt b/doc/technical/euid.txt index d141095c5..3633ae4aa 100644 --- a/doc/technical/euid.txt +++ b/doc/technical/euid.txt @@ -1,5 +1,3 @@ -$Id: euid.txt 1863 2006-08-27 13:40:37Z jilles $ - Extended UID command proposal Jilles Tjoelker diff --git a/doc/technical/event.txt b/doc/technical/event.txt index e8ffa2ff9..aa7a69d32 100644 --- a/doc/technical/event.txt +++ b/doc/technical/event.txt @@ -1,8 +1,6 @@ Overview of the event subsystem Adrian Chadd -$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 diff --git a/doc/technical/fd-management.txt b/doc/technical/fd-management.txt deleted file mode 100644 index 8567541b6..000000000 --- a/doc/technical/fd-management.txt +++ /dev/null @@ -1,47 +0,0 @@ -Overview of the filedescriptor subsystem -Adrian Chadd - -$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. diff --git a/doc/hooks.txt b/doc/technical/hooks.txt similarity index 98% rename from doc/hooks.txt rename to doc/technical/hooks.txt index 002da0ea5..8ea267d5e 100644 --- a/doc/hooks.txt +++ b/doc/technical/hooks.txt @@ -121,4 +121,3 @@ community. "iorecv" "iorecvctrl" -$Id: hooks.txt 3414 2007-04-15 16:54:50Z jilles $ diff --git a/doc/technical/hostmask.txt b/doc/technical/hostmask.txt index d70c114cb..5c9ee0291 100644 --- a/doc/technical/hostmask.txt +++ b/doc/technical/hostmask.txt @@ -1,6 +1,5 @@ The hostmask/netmask system. Copyright(C) 2001 by Andrew Miller(A1kmm) -$Id: hostmask.txt 6 2005-09-10 01:02:21Z nenolod $ Contents ======== diff --git a/doc/technical/index.txt b/doc/technical/index.txt index 0f66856c2..0238d0532 100644 --- a/doc/technical/index.txt +++ b/doc/technical/index.txt @@ -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 diff --git a/doc/technical/linebuf.txt b/doc/technical/linebuf.txt index 556597ed3..b01df5135 100644 --- a/doc/technical/linebuf.txt +++ b/doc/technical/linebuf.txt @@ -1,10 +1,7 @@ - linebuf - a dbuf replacement for the New World Order(tm) By Adrian Chadd -$Id: linebuf.txt 6 2005-09-10 01:02:21Z nenolod $ - History ------- diff --git a/doc/technical/network.txt b/doc/technical/network.txt deleted file mode 100644 index 3d7afe539..000000000 --- a/doc/technical/network.txt +++ /dev/null @@ -1,105 +0,0 @@ -Overview of the network subsystem -Adrian Chadd - -$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. diff --git a/doc/technical/send.txt b/doc/technical/send.txt deleted file mode 100644 index 7c92f1054..000000000 --- a/doc/technical/send.txt +++ /dev/null @@ -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 $ diff --git a/doc/technical/ts6-protocol.txt b/doc/technical/ts6-protocol.txt index f2ca5f546..bf52130da 100644 --- a/doc/technical/ts6-protocol.txt +++ b/doc/technical/ts6-protocol.txt @@ -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. + + source: server parameters: target, any... diff --git a/doc/technical/ts6.txt b/doc/technical/ts6.txt deleted file mode 100644 index 7f82df513..000000000 --- a/doc/technical/ts6.txt +++ /dev/null @@ -1,299 +0,0 @@ -$Id: ts6.txt 3211 2007-02-20 00:34:28Z jilles $ - -TS6 Proposal (v8) -Written by Lee H -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 TS : - -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 field is the password we have stored for this server, - is our current TS version. If this field is not present then -the server does not support TS6. is the SID of the server. - -- UID - - : UID + : - -This command is used for introducing clients to the network. - -The field is the SID of the server the client is connected to. -The field is the nick of the client being introduced. The -field is the amount of server hops between the server being burst to and -the server the client is on. The field is the TS of the client, either -the time they connected or the time they last changed nick. The -field contains the clients usermodes that need to be transmitted between -servers. The field contains the clients username/ident. The - field contains the clients host. - -The 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 field is the -clients UID. The field is the clients gecos. - -A server receiving a UID command must apply nick TS rules to the nick. - -- SID - - : SID : - -This command is used for introducing servers to the network. - -The first field is the SID of the new servers uplink. The - field is the new servers name. The field is the hops -between the server being introduced nd the server being burst to. - -The second field is the SID of the new server. The 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 - - : SJOIN + : - -This command is used for introducing users to channels. - -The field is the SID of the server introducing users to the channel. -The field is the channels current TS, is the channels -current name, are the channels current modes. 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 - - : JOIN + - -This command is used for introducing one user unopped to an existing channel. - -The field is the UID of the client joining the channel. The - field is the channels current TS, 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 - - : BMASK : - -This command is used for bursting channel bans to a network. - -The field is the SID of the server bursting the bans. The - field is the channels current TS, is the channels -name. is a single character identifying the mode type (ie, -for a ban 'b'). 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 - - : TMODE - -This command is used for clients issuing modes on a channel. - - is either the UID of the client setting the mode, or the SID of -the server setting the mode. is the current TS of the channel, - is the channels name. 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. -