mirror of
https://github.com/matrix-construct/construct
synced 2024-12-26 15:33:54 +01:00
doc: Remove old docs.
This commit is contained in:
Jason Volk
parent
755cfbffb0
commit
79364ef610
134 changed files with 0 additions and 10171 deletions
|
|
@ -5,7 +5,6 @@ SUBDIRS = include/ircd
|
|||
SUBDIRS += ircd
|
||||
SUBDIRS += modules
|
||||
SUBDIRS += construct
|
||||
SUBDIRS += doc
|
||||
|
||||
.PHONY: subdirs $(SUBDIRS)
|
||||
$(SUBDIRS):
|
||||
|
|
|
|||
|
|
@ -42,7 +42,6 @@ AC_CONFIG_FILES(\
|
|||
include/ircd/Makefile \
|
||||
construct/Makefile \
|
||||
ircd/Makefile \
|
||||
doc/Makefile \
|
||||
modules/Makefile \
|
||||
)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,35 +0,0 @@
|
|||
prefix = @prefix@
|
||||
exec_prefix = @exec_prefix@
|
||||
exec_suffix = @exec_suffix@
|
||||
bindir = @bindir@
|
||||
libexecdir = @libexecdir@
|
||||
sysconfdir = @sysconfdir@
|
||||
localstatedir = @localstatedir@
|
||||
|
||||
# Local to the etc Makefile
|
||||
|
||||
CONFS = ircd.conf.example reference.conf spamfilter.conf.example
|
||||
|
||||
install-mkdirs:
|
||||
-@if test ! -d $(DESTDIR)$(sysconfdir); then \
|
||||
echo "mkdir -p $(sysconfdir)"; \
|
||||
mkdir -p $(DESTDIR)$(sysconfdir); \
|
||||
fi
|
||||
|
||||
install: install-mkdirs
|
||||
@echo "ircd: installing example config files ($(CONFS))"
|
||||
@for i in $(CONFS); do \
|
||||
if test -f $(DESTDIR)$(sysconfdir)/$$i; then \
|
||||
$(MV) $(DESTDIR)$(sysconfdir)/$$i $(DESTDIR)$(sysconfdir)/$$i.old; \
|
||||
fi; \
|
||||
$(INSTALL_DATA) $$i $(DESTDIR)$(sysconfdir); \
|
||||
done
|
||||
|
||||
-@if test ! -f $(DESTDIR)$(sysconfdir)/ircd.motd; then \
|
||||
echo "ircd: installing motd file (ircd.motd)"; \
|
||||
$(INSTALL_DATA) ircd.motd $(DESTDIR)$(sysconfdir); \
|
||||
fi
|
||||
|
||||
-@if test -f $(DESTDIR)$(sysconfdir)/links.txt; then \
|
||||
$(RM) $(DESTDIR)$(sysconfdir)/links.txt; \
|
||||
fi
|
||||
|
|
@ -1,276 +0,0 @@
|
|||
===============================================================================
|
||||
IRCD 2.8 CREDITS
|
||||
===============================================================================
|
||||
|
||||
/************************************************************************
|
||||
* IRC - Internet Relay Chat, doc/AUTHORS
|
||||
* Copyright (C) 1990
|
||||
*
|
||||
* AUTHORS FILE:
|
||||
* This file attempts to remember all contributors to the IRC
|
||||
* developement. Names can be only added this file, no name
|
||||
* should never be removed. This file must be included into all
|
||||
* distributions of IRC and derived works.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 1, or (at your option)
|
||||
* any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
*/
|
||||
|
||||
IRC was conceived of and written by Jarkko Oikarinen <jto@tolsun.oulu.fi>.
|
||||
IRC was originally written in University of Oulu, Computing Center.
|
||||
Jan 1991 - IRC 2.6 jto@tolsun.oulu.fi
|
||||
- Multiple Channels and protocol changes
|
||||
|
||||
Contributions were made by a cast of dozens, including the following:
|
||||
|
||||
Markku Jarvinen <mta@tut.fi>: Emacs-like editing facility for the client
|
||||
|
||||
Kimmo Suominen <kim@kannel.lut.fi>: HP-UX port
|
||||
|
||||
Jeff Trim <jtrim@orion.cair.du.edu>: enhancements and advice
|
||||
|
||||
Vijay Subramaniam <vijay@lll-winken.llnl.gov>: advice and ruthless publicity
|
||||
|
||||
Karl Kleinpaste <karl@cis.ohio-state.edu>: user's manual
|
||||
|
||||
Greg Lindahl <gl8f@virginia.edu>: AUTOMATON code, the Wumpus GM automaton,
|
||||
myriad bug fixes
|
||||
|
||||
Bill Wisner <wisner@hayes.fai.alaska.edu>: numerous bug fixes and code
|
||||
enhancements
|
||||
|
||||
Tom Davis <conslt16@zeus.unl.edu> and Tim Russell <russell@zeus.unl.edu>:
|
||||
VMS modifications
|
||||
|
||||
Markku Savela <msa@tel4.tel.vtt.fi>: advice, support, and being the
|
||||
incentive to do some of our *own* coding. :)
|
||||
|
||||
Tom Hopkins <hoppie@buengf.bu.edu>: bug fixes, quarantine lines,
|
||||
consolidation of various patches.
|
||||
|
||||
Christopher Davis <ckd@cs.bu.edu>: EFnet/Anet gateway coding,
|
||||
many automata ;), documentation fixing.
|
||||
|
||||
Helen Rose <hrose@cs.bu.edu>: documentation updating, and fixing.
|
||||
|
||||
Tom Hinds <rocker@bucsf.bu.edu>: emacs client updating.
|
||||
|
||||
Tim Miller <cerebus@bu-pub.bu.edu>: various server and client-breaking
|
||||
features.
|
||||
|
||||
Darren Reed <avalon@coombs.anu.edu.au>: various bug fixes and enhancements.
|
||||
Introduced nickname and channelname hash tables into the server.
|
||||
|
||||
The version 2.2 release was coordinated by Mike Bolotski
|
||||
<mikeb@salmon.ee.ubc.ca>.
|
||||
|
||||
The version 2.4 release was coordinated by Markku Savela and
|
||||
Chelsea Ashley Dyerman
|
||||
|
||||
The version 2.5.2 release was coordinated by Christopher Davis, Helen Rose,
|
||||
and Tom Hopkins.
|
||||
|
||||
The versions 2.6.2, 2.7 and 2.8 releases were coordinated by Darren Reed.
|
||||
|
||||
Contributions for the 2.8 release from the following people:
|
||||
Matthew Green <phone@coombs.anu.edu.au>
|
||||
Chuck Kane <ckane@ece.uiuc.edu>
|
||||
Matt Lyle <matt@oc.com>
|
||||
Vesa Ruokonen <ruokonen@lut.fi>
|
||||
|
||||
Markku Savela <Markku.Savela@vtt.fi> / April 1990
|
||||
Fixed various bugs in 2.2PL1 release server (2.2msa.4) and changed
|
||||
sockets to use non-blocking mode (2.2msa.9). [I have absolutely
|
||||
nothing to do with clients :-]
|
||||
|
||||
Chelsea Ashley Dyerman <chelsea@earth.cchem.berkeley.edu> / April 1990
|
||||
Rewrote the Makefiles, restructuring of source tree. Added libIrcd.a to
|
||||
the Makefile macros, numerous reformatting of server text messages, and
|
||||
added mkversion.sh to keep track of compilation statistics. Numerous
|
||||
bug fixes and enhancements, and co-coordinator of the 2.4 release.
|
||||
|
||||
jarlek@ifi.uio.no added mail functions to irc.
|
||||
|
||||
Armin Gruner <gruner@informatik.tu-muenchen.de> / May, June 1990:
|
||||
* Patched KILL-line feature for ircd.conf, works now.
|
||||
Enhancement: Time intervals can be specified in passwd-field.
|
||||
Result: KILL-Line is only active during these intervals
|
||||
* Patched PRIVMSG handling, now OPER can specify masks for sending
|
||||
private messages, advantage: msg to all at a specified server or host.
|
||||
* Little tests on irc 2.5 alpha, fixed some little typos in client code.
|
||||
Change: common/debug.c has been moved to ircd/s_debug.c, and a
|
||||
irc/c_debug.c has been created, for the benefit that wrong server msg
|
||||
are displayed if client does not recognize them. (strange, if a server
|
||||
sends an 'unknown command', isn't it?)
|
||||
|
||||
Tom Hopkins <hoppie@buengf.bu.edu> / September, October 1990:
|
||||
* Patched msa's K lines for servers (Q lines).
|
||||
* Consolidated several patches, including Stealth's logging patch.
|
||||
* Fixed several minor bugs.
|
||||
* Has done lots of other stuff that I can't seem to remember, but he
|
||||
always works on code, so he has to have done alot more than three
|
||||
lines worth. :)
|
||||
|
||||
Thanks go to those persons not mentioned here who have added their advice,
|
||||
opinions, and code to IRC.
|
||||
|
||||
Various modifications, bugreports, cleanups and testing by:
|
||||
|
||||
Hugo Calendar <hugo@ucscb.ucsc.edu>
|
||||
Bo Adler <adler@csvax.cs.caltech.edu>
|
||||
Michael Sandrof <ms5n+@andrew.cmu.edu>
|
||||
Jon Solomon <jsol@cs.bu.edu>
|
||||
Jan Peterson <jlp@hamblin.math.byu.edu>
|
||||
Nathan Glasser <nathan@brokaw.lcs.mit.edu>
|
||||
Helen Rose <hrose@eff.org>
|
||||
Mike Pelletier <stealth@caen.engin.umich.edu>
|
||||
Basalat Ali Raja <gwydion@tavi.rice.edu>
|
||||
Eric P. Scott <eps@toaster.sfsu.edu>
|
||||
Dan Goodwin <fornax@wpi.wpi.edu>
|
||||
Noah Friedman <friedman@ai.mit.edu>
|
||||
|
||||
|
||||
===============================================================================
|
||||
IRCD-HYBRID CREDITS
|
||||
===============================================================================
|
||||
|
||||
The hybrid team is a group of ircd coders who were frustrated
|
||||
with the instability and all-out "dirtiness" of the EFnet ircd's
|
||||
available. "hybrid" is the name for the collective efforts of a group
|
||||
of people, all of us.
|
||||
|
||||
Anyone is welcome to contribute to this effort. You are encouraged
|
||||
to participate in the Hybrid mailing list. To subscribe to the
|
||||
Hybrid List, use this link:
|
||||
https://lists.ircd-hybrid.org/mailman/listinfo/hybrid
|
||||
|
||||
The core team as, of this major release:
|
||||
|
||||
adx, Piotr Nizynski <adx@irc7.pl>
|
||||
billy-jon, William Bierman III <bill@mu.org>
|
||||
cryogen, Stuart Walsh <stu@ipng.org.uk>
|
||||
Dianora, Diane Bruce <db@db.net>
|
||||
joshk, Joshua Kwan <joshk@triplehelix.org>
|
||||
kire, Erik Small <smalle@hawaii.edu>
|
||||
knight, Alan LeVee <alan.levee@prometheus-designs.net>
|
||||
metalrock, Jack Low <jclow@csupomona.edu>
|
||||
Michael, Michael Wobst <michael.wobst@gmail.com>
|
||||
Rodder, Jon Lusky <lusky@blown.net>
|
||||
Wohali, Joan Touzet <joant@ieee.org>
|
||||
|
||||
The following people have contributed blood, sweat, and/or code to
|
||||
recent releases of Hybrid, in nick alphabetical order:
|
||||
|
||||
A1kmm, Andrew Miller <a1kmm@mware.virtualave.net>
|
||||
AndroSyn, Aaron Sethman <androsyn@ratbox.org>
|
||||
bane, Dragan Dosen <bane@idolnet.org>
|
||||
bysin, Ben Kittridge <bkittridge@cfl.rr.com>
|
||||
cosine, Patrick Alken <wnder@uwns.underworld.net>
|
||||
David-T, David Taylor <davidt@yadt.co.uk>
|
||||
fl, Lee Hardy <lee@leeh.co.uk>
|
||||
Garion, Joost Vunderink <garion@efnet.nl>
|
||||
Habeeb, David Supuran <habeeb@cfl.rr.com>
|
||||
Hwy101, W. Campbell <wcampbel@botbay.net>
|
||||
jmallett, Juli Mallett <jmallett@FreeBSD.org>
|
||||
jv, Jakub Vlasek <jv@pilsedu.cz>
|
||||
k9, Jeremy Chadwick <ircd@jdc.parodius.com>
|
||||
kre, Dinko Korunic <kreator@fly.srk.fer.hr>
|
||||
madmax, Paul Lomax <madmax@efnet.org>
|
||||
nenolod, William Pitcock <nenolod@nenolod.net>
|
||||
Riedel, Dennis Vink, <riedel@chaotic.nl>
|
||||
scuzzy, David Todd <scuzzy@aniverse.net>
|
||||
spookey, David Colburn <spookey@spookey.org>
|
||||
TimeMr14C, Yusuf Iskenderoglu <uhc0@stud.uni-karlsruhe.de>
|
||||
toot, Toby Verrall <to7@antipope.fsnet.co.uk>
|
||||
vx0, Mark Miller <mark@oc768.net>
|
||||
wiz, Jason Dambrosio <jason@wiz.cx>
|
||||
Xride, Søren Straarup <xride@x12.dk>
|
||||
zb^3, Alfred Perlstein <alfred@freebsd.org>
|
||||
|
||||
Others are welcome. Always. And if we left anyone off the above list,
|
||||
be sure to let us know that too. Many others have contributed to
|
||||
previous versions of this ircd and its ancestors, too many to list
|
||||
here.
|
||||
|
||||
Send bug fixes/complaints/rotten tomatoes to bugs@ircd-hybrid.org.
|
||||
|
||||
|
||||
===============================================================================
|
||||
IRCD-RATBOX CREDITS
|
||||
===============================================================================
|
||||
|
||||
ircd-ratbox is an evolution where ircd-hybrid left off around version 7-rc1.
|
||||
Currently the ircd-ratbox team consists of the following developers:
|
||||
|
||||
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
|
||||
anfl, Lee Hardy <lee -at- leeh.co.uk>
|
||||
|
||||
Special thanks for support, code and ideas to:
|
||||
|
||||
Hwy, W. Campbell <wcampbel -at- botbay.net>
|
||||
jilles, Jilles Tjoelker <jilles -at- stack.nl>
|
||||
larne, Edward Brocklesby <ejb -at- sdf.lonestar.org>
|
||||
|
||||
Of course our work is based on the work of many, many others over the past
|
||||
10 or so years since irc has existed, including the work done by the Hybrid
|
||||
team, our thanks goes to them.
|
||||
|
||||
|
||||
===============================================================================
|
||||
IRCD-CHARYBDIS CREDITS
|
||||
===============================================================================
|
||||
|
||||
Charybdis started as an evolution from ircd-ratbox. Its development
|
||||
is led by a team of dedicated developers who have put a lot of time
|
||||
into the project and it has seen use on a variety of different
|
||||
network configurations.
|
||||
|
||||
The Charybdis core team, listed in nick-alphabetical order:
|
||||
|
||||
amdj, Aaron Jones <aaronmdjones -at- gmail.com>
|
||||
Elizafox, Elizabeth Myers <elizabeth -at- interlinked.me>
|
||||
jilles, Jilles Tjoelker <jilles -at- stack.nl>
|
||||
kaniini, William Pitcock <nenolod -at- dereferenced.org>
|
||||
lp0, Simon Arlott <simon -at- arlott.org>
|
||||
mr_flea, Keith Buck <mr_flea -at- esper.net>
|
||||
|
||||
The following people are also project members, listed in nick-alphabetical
|
||||
order:
|
||||
|
||||
grawity, Mantas MikulÄ—nas <grawity -at- gmail.com>
|
||||
jdhore, JD Horelick <jdhore1 -at- gmail.com>
|
||||
viatsko, Valerii Iatsko <dwr -at- codingbox.io>
|
||||
|
||||
The following people have made contributions to the Charybdis releases,
|
||||
in nick-alphabetical order:
|
||||
|
||||
AndroSyn, Aaron Sethman <androsyn -at- ratbox.org>
|
||||
anfl, Lee Hardy <lee -at- leeh.co.uk>
|
||||
beu, Elfyn McBratney <elfyn.mcbratney -at- gmail.com>
|
||||
BlindSight, Matt Ullman <matt -at- airraidsirens.com>
|
||||
Entrope, Michael Poole <mdpoole -at- trolius.org>
|
||||
gxti, Michael Tharp <gxti -at- partiallystapled.com>
|
||||
mniip <mniip -at- mniip.com>
|
||||
spb, Stephen Bennett <spb -at- attenuate.org>
|
||||
Taros, Brett Greenham <taros -at- shadowircd.net>
|
||||
ThaPrince, Jon Christopherson <jon -at- vile.com>
|
||||
twincest, River Tarnell <river -at- attenuate.org>
|
||||
w00t, Robin Burchell <surreal.w00t -at- gmail.com>
|
||||
|
||||
For a list of contributors to ircd-ratbox, ircd-hybrid, and ircd2.8 (the
|
||||
predecessors to Charybdis), see the doc/credits-past.txt file in the Charybdis
|
||||
distribution.
|
||||
|
||||
Visit the Charybdis website at: http://www.charybdis.io/
|
||||
Visit us on IRC at: irc.charybdis.io #charybdis
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
account-notify client capability specification
|
||||
----------------------------------------------
|
||||
|
||||
Copyright (c) 2010 William Pitcock <nenolod@atheme.org>.
|
||||
|
||||
Unlimited redistribution and modification of this document is allowed
|
||||
provided that the above copyright notice and this permission notice
|
||||
remains in tact.
|
||||
|
||||
The account-notify client capability allows a client to be notified
|
||||
when another client's accountname changes. This capability MUST be
|
||||
referred to as 'account-notify' at capability negotiation time.
|
||||
|
||||
When enabled, clients will get the ACCOUNT message to designate the
|
||||
accountname changes for clients on common channels with them.
|
||||
|
||||
The ACCOUNT message is one of the following:
|
||||
|
||||
:nick!user@host ACCOUNT accountname
|
||||
|
||||
This message represents that the user identified by nick!user@host has
|
||||
logged into a new account. The last parameter is the display name of
|
||||
that account.
|
||||
|
||||
:nick!user@host ACCOUNT *
|
||||
|
||||
This message represents that the user identified by nick!user@host has
|
||||
logged out of their account. As the last parameter is an asterisk, this
|
||||
means that an asterisk is not a valid account name (which it is not in P10
|
||||
or TS6 or ESVID).
|
||||
|
||||
In order to take full advantage of the ACCOUNT message, WHOX must be
|
||||
supported by the ircd. In this case, the appropriate strategy to ensuring
|
||||
you always have the accountname to display is to do the following:
|
||||
|
||||
1) Enable the account-notify capability at capability negotiation time during
|
||||
the login handshake.
|
||||
|
||||
2) When joining a channel, query the channel using WHO and ensure that you
|
||||
include the 'a' format token in your WHOX token request. When you get
|
||||
a reply, do appropriate caching.
|
||||
|
||||
3) If the extended-join capability is available, enable it at client capability
|
||||
negotiation time during the login handshake, and then set the accountname
|
||||
based on what is sent in the extended JOIN command.
|
||||
|
||||
Otherwise, if extended-join is unavailable:
|
||||
When new users join a channel that your client does not know the accountname
|
||||
for yet, do a WHO query against that client, again including the 'a' format
|
||||
token in your WHOX token request field. When you get a reply, do appropriate
|
||||
caching.
|
||||
|
||||
4) In the event of a netsplit, the client should query the channel again using
|
||||
WHO with the 'a' format token in the WHOX request field.
|
||||
|
||||
5) When the client receives an ACCOUNT message, update the accountname for the
|
||||
client in question in your accountname cache.
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
away-notify client capability specification
|
||||
----------------------------------------------
|
||||
|
||||
Copyright (c) 2012 Keith Buck <mr_flea@esper.net>.
|
||||
|
||||
Unlimited redistribution and modification of this document is allowed
|
||||
provided that the above copyright notice and this permission notice
|
||||
remains in tact.
|
||||
|
||||
The away-notify client capability allows a client to specify that it
|
||||
would like to be notified when users are marked/unmarked as away. This
|
||||
capability is referred to as 'away-notify' at capability negotiation
|
||||
time.
|
||||
|
||||
This capability is designed to replace polling of WHO as a more
|
||||
efficient method of tracking the away state of users in a channel. The
|
||||
away-notify capability both conserves bandwidth as WHO requests are
|
||||
not continually sent and allows the client to be notified immediately
|
||||
upon a user setting or removing their away state (as opposed to when
|
||||
WHO is next polled).
|
||||
|
||||
When this capability is enabled, clients will be sent an AWAY message
|
||||
when a user sharing a channel with them sets or removes their away
|
||||
state, as well as when a user joins and has an away message set.
|
||||
(Note that AWAY will not be sent for joining users with no away
|
||||
message set.)
|
||||
|
||||
The format of the AWAY message is as follows:
|
||||
|
||||
:nick!user@host AWAY [:message]
|
||||
|
||||
If the message is present, the user (specified by the nick!user@host
|
||||
mask) is going away. If the message is not present, the user is
|
||||
removing their away message/state.
|
||||
|
||||
To fully track the away state of users, clients should:
|
||||
|
||||
1) Enable the away-notify capability at negotiation time.
|
||||
|
||||
2) Execute WHO when joining a channel to capture the current away
|
||||
state of all users in that channel.
|
||||
|
||||
3) Update state appropriately upon receiving an AWAY message.
|
||||
|
|
@ -1,84 +0,0 @@
|
|||
------------------------------------------------------
|
||||
- Oper Challenge/Response System Documentation -
|
||||
- Copyright (C) 2006 Lee Hardy <lee -at- leeh.co.uk> -
|
||||
- Copyright (C) 2006 ircd-ratbox development team -
|
||||
------------------------------------------------------
|
||||
|
||||
The challenge/response system allows the ability to oper though public key
|
||||
authentication, without the insecurity of oper passwords.
|
||||
|
||||
The challenge system documented here was redesigned in
|
||||
ircd-ratbox-2.2/charybdis-1.1 and is not compatible with earlier versions.
|
||||
|
||||
This document does not describe the technical details of the challenge
|
||||
system. If you are reading this as part of the ircd distribution, the
|
||||
programs referred to are contained in ratbox-respond, see
|
||||
http://respond.ircd-ratbox.org for more information and downloads.
|
||||
|
||||
|
||||
- Challenge basics -
|
||||
--------------------
|
||||
When a user requests a challenge to oper up, the ircd takes some random
|
||||
data, encodes it using the opers public key, encodes this output in base64
|
||||
and sends it to the user as a challenge. The server then stores a hash of
|
||||
the original random data.
|
||||
|
||||
The user must then decrypt the data using their private key and generate a
|
||||
hash of the decrypted data. Then the hash is base64 encoded and sent back
|
||||
to the server.
|
||||
|
||||
If the stored hash the server has matches the reply from the client, they
|
||||
are opered up.
|
||||
|
||||
|
||||
- Generating a public/private keypair -
|
||||
---------------------------------------
|
||||
The first step is to use the makekeypair script to generate a public and
|
||||
private key. The public key is set in the ircd config (operator {};
|
||||
rsa_public_key_file) instead of a password, and the private key should
|
||||
be kept secret. It is highly recommended that the key is generated with
|
||||
a secure password. Generating keys without a password is fundamentally
|
||||
insecure.
|
||||
|
||||
|
||||
The commands used in makekeypair to generate keys are as follows:
|
||||
openssl genrsa -out private.key -aes256 2048
|
||||
openssl rsa -in private.key -out public.key -pubout
|
||||
|
||||
If aes256 is not available, the following is used instead:
|
||||
openssl genrsa -out private.key -des3 2048
|
||||
|
||||
|
||||
- Building ratbox-respond -
|
||||
---------------------------
|
||||
If you are using the unix based ratbox-respond this must be built. For the
|
||||
windows version, ratbox-winrespond, please see http://respond.ircd-ratbox.org
|
||||
|
||||
ratbox-respond takes the challenge from the server, and together with your
|
||||
private key file generates a response to be sent back. ratbox-respond
|
||||
requires the openssl headers (ie, development files) and openssl libraries
|
||||
are installed for compilation.
|
||||
|
||||
Change into the ratbox-respond directory, and run:
|
||||
./configure
|
||||
make
|
||||
|
||||
This will generate a 'ratbox-respond' binary, which you may place wherever
|
||||
you like. If configure does not detect your openssl installation, you may
|
||||
pass it the directory where it is installed to via --enable-openssl, this
|
||||
should be the base directory which has lib/ and include/openssl/ within it:
|
||||
./configure --enable-openssl=/path/to/opensslbase
|
||||
|
||||
|
||||
- Opering up -
|
||||
--------------
|
||||
Once you have your public key set in ircd and built ratbox-respond, you oper
|
||||
up by issuing "/challenge <opername>". You should then run:
|
||||
/path/to/ratbox-respond /path/to/private.key
|
||||
and input the challenge. This will give you a response to paste back to the
|
||||
server. The ratbox-respond binary also accepts piped input, see
|
||||
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.
|
||||
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
Nick collision FNC
|
||||
Jilles Tjoelker <jilles -at- stack.nl>
|
||||
--------------------------------------
|
||||
|
||||
Nick collision FNC performs a forced nick change to the user's UID instead
|
||||
of a kill. The criteria for which user may keep the nick are the same as
|
||||
before. Server notices will say the clients are being "saved" instead of
|
||||
"killed". The client will get a 043 numeric, like this:
|
||||
|
||||
:<server> 043 <nick> <uid> :Nick collision, forcing nick change to your unique ID
|
||||
|
||||
The following conditions must be fulfilled:
|
||||
|
||||
- All servers on the network must allow remote nicks starting with a digit.
|
||||
This is not checked; if this is not fulfilled, users will be killed right
|
||||
after being FNCed.
|
||||
|
||||
- All servers on the path between the two clients must support TS6 and
|
||||
nick collision FNC (SAVE capab). If this is not fulfilled, the collision is
|
||||
resolved with kills as before. (This uses the ENCAP GCAP data for remotes.)
|
||||
|
||||
- The general::collision_fnc option must be enabled on the server(s) that
|
||||
detect the collision.
|
||||
|
||||
Technical details:
|
||||
|
||||
The following message is used to propagate the nick change coming from the
|
||||
server that detected the collision:
|
||||
|
||||
:<sid> SAVE <uid> <ts>
|
||||
|
||||
The TS is compared to the current nick TS for the user; if it is not equal,
|
||||
the message is dropped. This prevents nick desyncs if the user changed their
|
||||
nick after being collided. A SAVE message also generates a server notice to
|
||||
+k.
|
||||
|
||||
The SAVE message is used for propagation to the target's server, and also
|
||||
in several other cases if the destination supports SAVE. In other cases, a
|
||||
normal nick change or introduction with the UID as nick is sent.
|
||||
|
||||
The TS of the UID nick is 100. This is necessary to ensure nick TS is always
|
||||
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).
|
||||
|
||||
|
|
@ -1,90 +0,0 @@
|
|||
Extended bans
|
||||
Jilles Tjoelker <jilles -at- stack.nl>
|
||||
--------------------------------------
|
||||
|
||||
Extended bans (ban conditionals) allow different checks than the usual
|
||||
nick!user@host or nick!user@ip match to determine whether someone should
|
||||
be banned, quieted, exempted or invited.
|
||||
|
||||
Extended bans are of the form $[~]<type>[:<data>]. The <type> is one
|
||||
character (case insensitive) and determines the type of match. Most types
|
||||
allow or require an extra field <data>. If the tilde (~) is present, the
|
||||
result of the comparison will be negated, unless the ban is invalid in which
|
||||
case it will never match. Invalid bans are ones where <data> is missing but
|
||||
required or where <data> is otherwise invalid as noted below.
|
||||
|
||||
Unless noted below, all types can be used with +b, +q, +e and +I.
|
||||
|
||||
If any extended ban types are loaded, they are listed in 005 (RPL_ISUPPORT)
|
||||
as EXTBAN=$,<types>.
|
||||
|
||||
Local users cannot add extended bans of an unknown type or invalid bans. If a
|
||||
remote user adds an extended ban of an unknown type, the mode change is
|
||||
processed normally. Furthermore, extended bans of an unknown type can always be
|
||||
listed or removed.
|
||||
|
||||
The ability to send to a channel is cached; this cache may not be updated
|
||||
if a condition for an extended ban changes. To work around this, part and
|
||||
rejoin the channel, or add or remove a +b, +q or +e entry.
|
||||
|
||||
The extban types that come with charybdis are:
|
||||
|
||||
extb_account.so
|
||||
$a
|
||||
matches all logged in users
|
||||
$a:<mask>
|
||||
matches users logged in with a username matching the mask (* and ? wildcards)
|
||||
|
||||
extb_channel.so
|
||||
$c:<channel>
|
||||
matches users who are on the given channel; this is only valid if the channel
|
||||
exists and is not +s or +p. (The ops of the channel the ban is on cannot
|
||||
necessarily see whether the user is in the target channel, so it should not
|
||||
influence whether they can join either.)
|
||||
|
||||
extb_oper.so
|
||||
$o
|
||||
matches opers (most useful with +I)
|
||||
|
||||
extb_realname.so
|
||||
$r:<mask>
|
||||
matches users with a realname (gecos) matching the mask (* and ? wildcards);
|
||||
this can only be used with +b and +q
|
||||
|
||||
extb_server.so
|
||||
$s:<mask>
|
||||
matches users connected to a server matching the mask (* and ? wildcards);
|
||||
this can only be used with +b and +q
|
||||
|
||||
Comparisons:
|
||||
|
||||
+b $~a is similar to +r but also prevents not logged in users talking or
|
||||
changing their nick while on channel.
|
||||
|
||||
+iI $o is the same as +O in dreamforge-derived ircds.
|
||||
|
||||
Creating extban types:
|
||||
|
||||
extban_table, indexed by the extban character, contains function pointers
|
||||
of the following type:
|
||||
typedef int (*ExtbanFunc)(const char *data, struct Client *client_p,
|
||||
struct Channel *chptr, long mode_type);
|
||||
|
||||
The arguments are as follows:
|
||||
data: the text after the colon, NULL if there was no colon
|
||||
client_p: the client to check; this is always a local client, which may be
|
||||
on or off channel
|
||||
chptr: the channel
|
||||
mode_type: CHFL_BAN, CHFL_QUIET, CHFL_EXCEPTION or CHFL_INVEX
|
||||
|
||||
The return value:
|
||||
EXTBAN_INVALID: the mask is invalid, it never matches even if negated and
|
||||
cannot be added; if this is returned for one client_p it must be returned
|
||||
for all
|
||||
EXTBAN_NOMATCH: the client_p does not match the mask
|
||||
EXTBAN_MATCH: the client_p matches the mask
|
||||
|
||||
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.)
|
||||
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
extended-join client capability specification
|
||||
---------------------------------------------
|
||||
|
||||
Copyright (c) 2011 Kiyoshi Aman <kiyoshi.aman@gmail.com>
|
||||
|
||||
Unlimited redistribution and modification of this document is allowed
|
||||
provided that the above copyright notice and this permission notice
|
||||
remains intact.
|
||||
|
||||
The extended-join capability extends the JOIN message to include the
|
||||
account name, or a placeholder if the user hasn't identified with
|
||||
services. This capability MUST be referred to as 'extended-join' at
|
||||
capability negotiation time.
|
||||
|
||||
When enabled, the JOIN message will designate the account name of the
|
||||
user when he/she joins a channel.
|
||||
|
||||
The JOIN message is one of the following:
|
||||
|
||||
:nick!user@host JOIN #channelname accountname :Real Name
|
||||
|
||||
This message represents that the user identified by nick!user@host has
|
||||
logged in to an acount prior to channel ingress. The penultimate
|
||||
parameter is the display name of that account. The last parameter is
|
||||
the user's GECOS.
|
||||
|
||||
:nick!user@host JOIN #channelname * :Real Name
|
||||
|
||||
This message represents that the user has not logged in to an account
|
||||
prior to channel ingress. As the penultimate parameter is an asterisk,
|
||||
this means that an asterisk is not a valid account name (which it is
|
||||
not in P10 or TS6 or ESVID).
|
||||
|
||||
Please see the documentation in account-notify.txt for how to take
|
||||
advantage of this capability.
|
||||
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
Here is an overview of the docs in the doc/features directory.
|
||||
|
||||
account-notify.txt - Description of the account-notify system
|
||||
away-notify.txt - Description of the away-notify system
|
||||
challenge.txt - Overview of the challenge/response system for
|
||||
obtaining operator status
|
||||
collision_fnc.txt - Overview of the SAVE nick collision method
|
||||
extban.txt - Description of extended bans
|
||||
extended-join.txt - Description of the extended-join system
|
||||
modeg.txt - Description of UMODE +g, the caller ID system
|
||||
monitor.txt - Description of the MONITOR system
|
||||
sasl.txt - Description of the SASL services authentication
|
||||
system
|
||||
services.txt - Overview of features added by services
|
||||
tgchange.txt - Overview of the target change system
|
||||
|
|
@ -1,217 +0,0 @@
|
|||
User Mode +g Documentation
|
||||
|
||||
Support of this specification is indicated by the CALLERID token in
|
||||
RPL_ISUPPORT (005). This token takes an optional parameter, of the letter
|
||||
of the user mode. If no parameter is specified, the user mode is g. A
|
||||
typical token would be: CALLERID=g
|
||||
The rest of this specification will assume the user mode is g, as
|
||||
implemented in hybrid, ratbox and charybdis.
|
||||
|
||||
Hybrid 7 includes a new and power feature that all users can take advantage
|
||||
of to help prevent flooding and unwanted messages. This new feature is
|
||||
invoked by setting user mode +g. When a client is set +g, that user will
|
||||
be in "Caller ID" mode. Any user that messages a +g client will receive
|
||||
a notice saying that they are in +g (server side ignore) mode. The target
|
||||
client (who is set +g) will also receive a notice saying that so and so
|
||||
messaged them, and that they are in +g mode.
|
||||
|
||||
The target of the message will only receive one notification per minute, from
|
||||
any client, in order to help prevent flooding. The sender will NOT have the
|
||||
rate limit, and will receive a numeric saying the target is in +g mode every
|
||||
time they send a message. Note that this behavior is similar to the way AWAY
|
||||
messages are done.
|
||||
|
||||
There are numerous benefits for both opers and regular users, including the
|
||||
ability to stop spambot messages from ever reaching your client, stopping
|
||||
private message and CTCP floods, and being able to sit on IRC in privacy.
|
||||
|
||||
One question that arises is how to message specific users, while blocking
|
||||
out everyone else. The command ACCEPT is your answer. To add a user to
|
||||
your accept list, issue the raw command ACCEPT <nick>,<nick>,<nick>,...
|
||||
|
||||
You will not receive a reply from the ACCEPT command if it is succesful,
|
||||
only if an error has occured. There are three possible errors, shown by
|
||||
numerics:
|
||||
|
||||
ERR_ACCEPTFULL (456): :irc.server 456 client :Accept list is full
|
||||
- This is sent when an accept list is full.
|
||||
ERR_ACCEPTEXIST (457): :irc.server 457 client target :already exists
|
||||
- This is sent when a client tries to add a user to the accept list
|
||||
that already exists there
|
||||
ERR_ACCEPTNOT (458): :irc.server 458 client target :doesnt exist
|
||||
- This is sent when a client tries to remove a user from their accept
|
||||
list who is not on the accept list.
|
||||
|
||||
That user will now be able to send messages to your client until the
|
||||
association is broken.
|
||||
|
||||
Associations break in one of the following situations: when an accepted user
|
||||
QUIT's (or is on the other side of a split), you QUIT, or the accepted user
|
||||
changes their nick. The reason why a remote user's nick change will remove
|
||||
them from your accept list is so that you cannot track a user after they
|
||||
changed their nick.
|
||||
|
||||
Viewing the accept list is also very easy. Issue the raw command ACCEPT *.
|
||||
Removing a user from your accept list is also simple. Issue the command
|
||||
ACCEPT -<nick>.
|
||||
|
||||
The ACCEPT command can be used whether or not +g is enabled at the time.
|
||||
Setting -g does not clear the accept list.
|
||||
|
||||
Some users (in particular IRC operators and services) may be exempt from
|
||||
CallerID, and able to message a +g user without being on their accept list.
|
||||
|
||||
Being on the accept list may allow a user to bypass more than +g (for example,
|
||||
a +R user can use the ACCEPT command to receive messages from unidentified
|
||||
users in charybdis).
|
||||
|
||||
Sample Session
|
||||
|
||||
The easiest way to see how this works is by experiencing it. Seeing a sample
|
||||
session can help understand what goes on though.
|
||||
|
||||
Client Hwy-LL is set +g initially.
|
||||
Client Hwy101 wants to message Hwy-LL
|
||||
|
||||
Note that some clients may have to use /quote ACCEPT instead of /accept.
|
||||
|
||||
--
|
||||
|
||||
Client Hwy101: /msg Hwy-LL hi
|
||||
Hwy101 will see: -!- Hwy-LL is in +g mode (server-side ignore.)
|
||||
-!- Hwy-LL has been informed that you messaged them.
|
||||
|
||||
Hwy-LL will see: -!- Hwy101 wcampbel@admin.irc.monkie.org is messaging you, and you have umode +g.
|
||||
|
||||
--
|
||||
|
||||
If Hwy101 sends another message to Hwy-LL (before the minute expires), he will
|
||||
see: -!- Hwy-LL is in +g mode (server-side ignore.)
|
||||
and will not receive the second notice
|
||||
|
||||
Hwy-LL will NOT see any notice. This also applies if the second message comes
|
||||
from a different user.
|
||||
|
||||
--
|
||||
|
||||
Hwy-LL now wishes to see messages from Hwy101 and SpamBot
|
||||
|
||||
Client Hwy-LL: /accept Hwy101,SpamBot
|
||||
|
||||
Neither side will be told of the change in the accept list, Hwy-LL should
|
||||
presume that the accept was succesful if no error occurs.
|
||||
|
||||
Now Hwy-LL can see messages from Hwy101 and SpamBot without any blockage.
|
||||
If Hwy101 was also set +g, then he would have to issue /accept Hwy-LL
|
||||
before he would be able to see messages from Hwy-LL.
|
||||
|
||||
--
|
||||
|
||||
Hwy-LL now wants to see who is on his accept list.
|
||||
|
||||
Client Hwy-LL: /accept *
|
||||
|
||||
Hwy-LL will see:
|
||||
irc.server 281 Hwy-LL Hwy101 SpamBot
|
||||
irc.server 282 Hwy-LL :End of /ACCEPT list
|
||||
|
||||
The replies are in numeric form to help parsing by scripts.
|
||||
--
|
||||
|
||||
Hwy-LL realises he added a spambot to his list, and wants to remove it, and
|
||||
allow messages from services
|
||||
|
||||
Client Hwy-LL: /accept -SpamBot,services
|
||||
|
||||
Hwy-LL will now only accept messages from Hwy101 and services.
|
||||
|
||||
--
|
||||
|
||||
The nicks to be added can be in ANY order, however you cannot add or remove
|
||||
AND list.
|
||||
/ACCEPT x,y,-z,f,-a would be acceptable.
|
||||
/ACCEPT x,y,-z,* would ignore the * and generate an invalid nick
|
||||
response.
|
||||
|
||||
Like Dalnet and Undernet's SILENCE system, the accept list only exists while
|
||||
you are connected to IRC. In order for you to have the same accept list
|
||||
every time you come onto IRC, you must put the accept commands into your
|
||||
client's auto-perform, or manually issue the commands each time.
|
||||
|
||||
This system may seem similar to the SILENCE system, but it is actually a
|
||||
reverse SILENCE. SILENCE ignores certain users and allows the rest. Mode
|
||||
+g ignores all users except certain ones (on your accept list.) Both systems
|
||||
have their place, but the mode +g in Hybrid 7 is what the developers thought
|
||||
would be most useful for clients.
|
||||
|
||||
The goals of this user mode is to provide protection from flooding and
|
||||
spamming, and to provide users with a means to keep their privacy.
|
||||
|
||||
We hope that these goals are obtained.
|
||||
|
||||
Numeric replies
|
||||
---------------
|
||||
|
||||
280 - RPL_ACCEPTLIST
|
||||
--------------------
|
||||
:<server> 280 <nick> <accepted1> <accepted2> ...
|
||||
|
||||
This numeric is used to indicate to a client the list of nicknames they are
|
||||
accepting. At most 15 accepted nicknames may be included; if this is exceeded
|
||||
multiple RPL_ACCEPTLIST must be sent.
|
||||
|
||||
281 - RPL_ENDOFACCEPT
|
||||
---------------------
|
||||
:<server> 281 <nick> :End of /ACCEPT list.
|
||||
|
||||
This numeric is used to indicate to a client the end of an accept list.
|
||||
|
||||
456 - ERR_ACCEPTFULL
|
||||
--------------------
|
||||
:<server> 456 <nick> :Accept list is full
|
||||
|
||||
This numeric is used to indicate to a client that their accept list is full
|
||||
and one or more nicks could not be added.
|
||||
|
||||
457 - ERR_ACCEPTEXIST
|
||||
---------------------
|
||||
:<server> 457 <nick> <target> :is already on your accept list
|
||||
|
||||
This numeric is used to indicate to a client that the given nick was already
|
||||
on their accept list.
|
||||
|
||||
458 - ERR_ACCEPTNOT
|
||||
-------------------
|
||||
:<server> 458 <nick> <target> :is not on your accept list
|
||||
|
||||
This numeric is used to indicate to a client that the given nick was not on
|
||||
their accept list.
|
||||
|
||||
716 - ERR_TARGUMODEG
|
||||
--------------------
|
||||
:<server> 716 <nick> <target> :is in +g mode (server-side ignore.)
|
||||
|
||||
This numeric is used to indicate that a message (PRIVMSG) the client sent
|
||||
could not be delivered because of CallerID restrictions. The <target>
|
||||
parameter is the target user's nick.
|
||||
|
||||
717 - RPL_TARGNOTIFY
|
||||
--------------------
|
||||
:<server> 717 <nick> <target> :has been informed that you messaged them.
|
||||
|
||||
This numeric is sent after 716 if the target user was notified of the message.
|
||||
|
||||
718 - RPL_UMODEGMSG
|
||||
-------------------
|
||||
:<server> 718 <nick> <target> <user>@<host> :is messaging you, and you have umode +g.
|
||||
|
||||
This numeric is sent when a message (PRIVMSG or NOTICE) sent to the user is
|
||||
blocked by CallerID, at most once per minute.
|
||||
|
||||
Problem: hybrid uses the following form instead
|
||||
:<server> 718 <nick> <target>[<user>@<host>] :is messaging you, and you have umode +g.
|
||||
which is ambiguous if the user may contain a [ and in the author's opinion ugly.
|
||||
|
||||
--
|
||||
W. Campbell
|
||||
updated by J. Tjoelker
|
||||
|
|
@ -1,115 +0,0 @@
|
|||
MONITOR - Protocol for notification of when clients become online/offline
|
||||
Lee Hardy <lee -at- leeh.co.uk>
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
Currently, ISON requests by clients use a large amount of bandwidth. It is
|
||||
expected that it is more efficient for this to be done by the server at the
|
||||
expense of cpu cycles. The WATCH implementation that was designed to counter
|
||||
this is (in my opinion) severely flawed. This protocol was designed to
|
||||
provide a cleaner implementation.
|
||||
|
||||
The command used throughout this specification is "MONITOR".
|
||||
|
||||
Each use of the MONITOR command takes a special modifier, indicating
|
||||
the operation being performed. The client MUST NOT attempt to specify
|
||||
more than one modifier. Only one special modifier may be used per MONITOR
|
||||
command.
|
||||
|
||||
Thus it is impossible to combine additions to the list with removals from
|
||||
the list -- these MUST be done with two seperate commands.
|
||||
|
||||
A client MUST NOT issue the MONITOR command more than once per second.
|
||||
Any attempts to do so will generate an error.
|
||||
|
||||
In commands and numerics where multiple nicknames may occur, the length of
|
||||
the nickname list is limited only by the buffer size of 512 chars, as
|
||||
defined in RFC1459.
|
||||
|
||||
Support of this specification is indicated by the MONITOR token in
|
||||
RPL_ISUPPORT (005). This token takes an optional parameter, of the maximum
|
||||
amount of nicknames a client may have in their monitor list. If no
|
||||
parameter is specified, there is no limit. A typical token would be:
|
||||
MONITOR=100
|
||||
|
||||
MONITOR + nick[,nick2]*
|
||||
-----------------------
|
||||
Adds the given list of nicknames to the list of nicknames being monitored.
|
||||
|
||||
If any of the nicknames being added are online, the server will generate
|
||||
RPL_MONONLINE numerics listing those nicknames that are online.
|
||||
|
||||
If any of the nicknames being added are offline, the server will generate
|
||||
RPL_MONOFFLINE numerics listing those nicknames that are offline.
|
||||
|
||||
MONITOR - nick[,nick2]*
|
||||
-----------------------
|
||||
Removes the given list of nicknames from the list of nicknames being
|
||||
monitored. No output will be returned for use of this command.
|
||||
|
||||
MONITOR C
|
||||
---------
|
||||
Clears the list of nicknames being monitored. No output will be returned
|
||||
for use of this command.
|
||||
|
||||
MONITOR L
|
||||
---------
|
||||
Outputs the current list of nicknames being monitored. All output will use
|
||||
RPL_MONLIST, and the output will be terminated with RPL_ENDOFMONLIST
|
||||
|
||||
MONITOR S
|
||||
---------
|
||||
Outputs for each nickname in the list being monitored, whether the client is
|
||||
online or offline. All nicks that are online will be sent using
|
||||
RPL_MONONLINE, all nicks that are offline will be sent using RPL_MONOFFLINE.
|
||||
|
||||
|
||||
Numeric replies
|
||||
---------------
|
||||
|
||||
730 - RPL_MONONLINE
|
||||
-------------------
|
||||
:<server> 730 <nick> :nick!user@host[,nick!user@host]*
|
||||
|
||||
This numeric is used to indicate to a client that either a nickname has just
|
||||
become online, or that a nickname they have added to their monitor list is
|
||||
online.
|
||||
|
||||
The server may send "*" instead of the target nick (<nick>). (This makes it
|
||||
possible to send the exact same message to all clients monitoring a certain
|
||||
nick.)
|
||||
|
||||
731 - RPL_MONOFFLINE
|
||||
--------------------
|
||||
:<server> 731 <nick> :nick[,nick1]*
|
||||
|
||||
This numeric is used to indicate to a client that either a nickname has just
|
||||
left the irc network, or that a nickname they have added to their monitor
|
||||
list is offline.
|
||||
|
||||
The argument is a chained list of nicknames that are offline.
|
||||
|
||||
As with 730 the server may send "*" instead of the target nick.
|
||||
|
||||
732 - RPL_MONLIST
|
||||
-----------------
|
||||
:<server> 732 <nick> :nick[,nick1]*
|
||||
|
||||
This numeric is used to indicate to a client the list of nicknames they have
|
||||
in their monitor list.
|
||||
|
||||
733 - RPL_ENDOFMONLIST
|
||||
------------------------
|
||||
:<server> 733 <nick> :End of MONITOR list
|
||||
|
||||
This numeric is used to indicate to a client the end of a monitor list.
|
||||
|
||||
734 - ERR_MONLISTFULL
|
||||
---------------------
|
||||
:<server> 734 <nick> <limit> <nicks> :Monitor list is full.
|
||||
|
||||
This numeric is used to indicate to a client that their monitor list is
|
||||
full, so the command failed. The <limit> parameter is the maximum number of
|
||||
nicknames a client may have in their list, the <nicks> parameter is the list
|
||||
of nicknames, as the client sent them, that cannot be added.
|
||||
|
||||
|
||||
|
|
@ -1,129 +0,0 @@
|
|||
SASL authentication
|
||||
-------------------
|
||||
|
||||
Note: The primary location for this document is now the IRCv3 sasl-3.1
|
||||
specification, at address:
|
||||
|
||||
http://ircv3.atheme.org/extensions/sasl-3.1
|
||||
|
||||
This document describes the client protocol for SASL authentication, as
|
||||
implemented in Charybdis and Atheme. The SASL protocol in general is documented
|
||||
in RFC 4422 [1], along with the 'EXTERNAL' mechanism. The most commonly used
|
||||
'PLAIN' mechanism is documented in RFC 4616 [2].
|
||||
|
||||
SASL authentication relies on the CAP client capability framework [3].
|
||||
Support for SASL authentication is indicated with the "sasl" capability.
|
||||
The client MUST enable the sasl capability before using the AUTHENTICATE
|
||||
command defined by this specification.
|
||||
|
||||
The AUTHENTICATE command
|
||||
|
||||
The AUTHENTICATE command MUST be used before registration is complete and
|
||||
with the sasl capability enabled. To enforce the former, it is RECOMMENDED
|
||||
to only send CAP END when the SASL exchange is completed or needs to be
|
||||
aborted. Clients SHOULD be prepared for timeouts at all times during the SASL
|
||||
authentication.
|
||||
|
||||
There are two forms of the AUTHENTICATE command: initial client message and
|
||||
later messages.
|
||||
|
||||
The initial client message specifies the SASL mechanism to be used. (When this
|
||||
is received, the IRCD will attempt to establish an association with a SASL
|
||||
agent.) If this fails, a 904 numeric will be sent and the session state remains
|
||||
unchanged; the client MAY try another mechanism. Otherwise, the server sends
|
||||
a set of regular AUTHENTICATE messages with the initial server response.
|
||||
|
||||
initial-authenticate = "AUTHENTICATE" SP mechanism CRLF
|
||||
|
||||
A set of regular AUTHENTICATE messages transmits a response from client to
|
||||
server or vice versa. The server MAY intersperse other IRC protocol messages
|
||||
between the AUTHENTICATE messages of a set. The "+" form is used for an empty
|
||||
response. The server MAY place a limit on the total length of a response.
|
||||
|
||||
regular-authenticate-set = *("AUTHENTICATE" SP 400BASE64 CRLF)
|
||||
"AUTHENTICATE" SP (1*399BASE64 / "+") CRLF
|
||||
|
||||
The client can abort an authentication by sending an asterisk as the data.
|
||||
The server will send a 904 numeric.
|
||||
|
||||
authenticate-abort = "AUTHENTICATE" SP "*" CRLF
|
||||
|
||||
If authentication fails, a 904 or 905 numeric will be sent and the
|
||||
client MAY retry from the AUTHENTICATE <mechanism> command.
|
||||
If authentication is successful, a 900 and 903 numeric will be sent.
|
||||
|
||||
If the client attempts to issue the AUTHENTICATE command after already
|
||||
authenticating successfully, the server MUST reject it with a 907 numeric.
|
||||
|
||||
If the client completes registration (with CAP END, NICK, USER and any other
|
||||
necessary messages) while the SASL authentication is still in progress, the
|
||||
server SHOULD abort it and send a 906 numeric, then register the client
|
||||
without authentication.
|
||||
|
||||
This document does not specify use of the AUTHENTICATE command in
|
||||
registered (person) state.
|
||||
|
||||
Example protocol exchange
|
||||
|
||||
C: indicates lines sent by the client, S: indicates lines sent by the server.
|
||||
|
||||
The client is using the PLAIN SASL mechanism with authentication identity
|
||||
jilles, authorization identity jilles and password sesame.
|
||||
|
||||
C: CAP REQ :sasl
|
||||
C: NICK jilles
|
||||
C: USER jilles cheetah.stack.nl 1 :Jilles Tjoelker
|
||||
S: NOTICE AUTH :*** Processing connection to jaguar.test
|
||||
S: NOTICE AUTH :*** Looking up your hostname...
|
||||
S: NOTICE AUTH :*** Checking Ident
|
||||
S: NOTICE AUTH :*** No Ident response
|
||||
S: NOTICE AUTH :*** Found your hostname
|
||||
S: :jaguar.test CAP jilles ACK :sasl
|
||||
C: AUTHENTICATE PLAIN
|
||||
S: AUTHENTICATE +
|
||||
C: AUTHENTICATE amlsbGVzAGppbGxlcwBzZXNhbWU=
|
||||
S: :jaguar.test 900 jilles jilles!jilles@localhost.stack.nl jilles :You are now logged in as jilles.
|
||||
S: :jaguar.test 903 jilles :SASL authentication successful
|
||||
C: CAP END
|
||||
S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay Chat Network jilles
|
||||
<usual welcome messages>
|
||||
|
||||
Note that the CAP command sent by a server includes the user's nick or *,
|
||||
differently from what [1] specifies.
|
||||
|
||||
Alternatively the client could request the list of capabilities and enable
|
||||
an additional capability.
|
||||
|
||||
C: CAP LS
|
||||
C: NICK jilles
|
||||
C: USER jilles cheetah.stack.nl 1 :Jilles Tjoelker
|
||||
S: NOTICE AUTH :*** Processing connection to jaguar.test
|
||||
S: NOTICE AUTH :*** Looking up your hostname...
|
||||
S: NOTICE AUTH :*** Checking Ident
|
||||
S: NOTICE AUTH :*** No Ident response
|
||||
S: NOTICE AUTH :*** Found your hostname
|
||||
S: :jaguar.test CAP * LS :multi-prefix sasl
|
||||
C: CAP REQ :multi-prefix sasl
|
||||
S: :jaguar.test CAP jilles ACK :multi-prefix sasl
|
||||
C: AUTHENTICATE PLAIN
|
||||
S: AUTHENTICATE +
|
||||
C: AUTHENTICATE amlsbGVzAGppbGxlcwBzZXNhbWU=
|
||||
S: :jaguar.test 900 jilles jilles!jilles@localhost.stack.nl jilles :You are now logged in as jilles.
|
||||
S: :jaguar.test 903 jilles :SASL authentication successful
|
||||
C: CAP END
|
||||
S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay Chat Network jilles
|
||||
<usual welcome messages>
|
||||
|
||||
[1] A. Melnikov (Isode Limited), K. Zeilenga (OpenLDAP Foundation), Simple
|
||||
Authentication and Security Layer (SASL). June 2006.
|
||||
<https://tools.ietf.org/html/rfc4422>
|
||||
|
||||
[2] K. Zeilenga (OpenLDAP Foundation), The PLAIN Simple Authentication and
|
||||
Security Layer (SASL) Mechanism. August 2006.
|
||||
<https://tools.ietf.org/html/rfc4616>
|
||||
|
||||
[3] K. Mitchell, P. Lorier (Undernet IRC Network), L. Hardy (ircd-ratbox), P.
|
||||
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
|
||||
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
Services compatibility documentation
|
||||
------------------------------------
|
||||
|
||||
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
|
||||
|
||||
A simple mode taking no parameters, will require users are logged in
|
||||
with user services before they may join the channel.
|
||||
|
||||
Gives numeric 477 to users who arent logged in:
|
||||
:<server> 477 <nick> <channel> :Cannot join channel (+r)
|
||||
|
||||
2. service block to ircd.conf
|
||||
|
||||
Ability to specify the names of services servers in ircd.conf:
|
||||
service {
|
||||
name = "services.charybdis.io";
|
||||
name = "backup-services.charybdis.io";
|
||||
};
|
||||
|
||||
These must be specified for certain features to work. You may specify as
|
||||
many name entries as you wish, however you must define only one service
|
||||
block.
|
||||
|
||||
Entries will be listed in stats U with the flag 's'.
|
||||
|
||||
3. Services protection
|
||||
|
||||
Services will be protected from being deopped or kicked from a channel.
|
||||
|
||||
4. Username tracking through netsplits
|
||||
|
||||
When users are logged in, the username they are logged in with will be
|
||||
preserved on a netsplit, so users will not have to relogin when the
|
||||
network merges together.
|
||||
|
||||
5. Username given on WHOIS
|
||||
|
||||
When users are logged in, WHOIS will also give numeric 330:
|
||||
:<server> 330 <yournick> <targetnick> <loginname> :is logged in as
|
||||
|
||||
6. Forced nick change
|
||||
|
||||
When using nickname services and a client requests they regain a
|
||||
nickname, services can perform a forced nick change on the client.
|
||||
This forcibly changes the clients nickname to the one they requested
|
||||
they regain, ensuring they can always regain their nickname.
|
||||
|
||||
7. User mode +R
|
||||
|
||||
This user mode will require users are logged in with user services
|
||||
before they may send private messages or notices to the user.
|
||||
|
||||
As with user mode +g, IRC operators and accepted users can send even
|
||||
if they are not logged in.
|
||||
|
||||
Gives numeric 486 to users sending a PRIVMSG who are not logged in:
|
||||
:<server> 486 <nick> <targetnick> :You must log in with services to message this user
|
||||
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
Target Change for Messages
|
||||
Lee H <lee -at- leeh.co.uk>
|
||||
---------------------------
|
||||
|
||||
Reworked by Jilles Tjoelker, February 2010.
|
||||
Channel target change added by Jilles Tjoelker, August 2010.
|
||||
|
||||
If the server you are using uses the target change mechanism, then
|
||||
restrictions are placed on how many different users and/or channels you can
|
||||
message in a set timeframe. This also applies to invites (for the target
|
||||
user) and topic changes.
|
||||
|
||||
Target change does not apply to ctcp replies, messages to yourself, messages
|
||||
to services and joins.
|
||||
|
||||
You will have a set number of 'slots', each different target you message
|
||||
will take up one slot. A client doing a nick change will not use a new slot,
|
||||
however a client disconnecting from the server it is on and reconnecting
|
||||
will. You will receive 1 new slot roughly every minute.
|
||||
|
||||
Additionally, clients that message or invite you are placed in one of a
|
||||
small number of special slots, in many cases allowing replies without using
|
||||
a slot.
|
||||
|
||||
When all slots are filled, messages to new targets will not be accepted.
|
||||
Messages to targets already filling a slot will be accepted. If all slots
|
||||
are full, you will receive the ERR_TARGCHANGE numeric, number 707 in the
|
||||
form:
|
||||
:<server> 707 <yournick> <target> :Targets changing too fast, message dropped
|
||||
|
||||
The slots are operated in an LRU (least recently used), so the person or
|
||||
channel you have talked to least recently will be replaced.
|
||||
|
||||
The number of slots in use will be kept through a reconnection, though the
|
||||
information in those slots will be dropped. However, you will always
|
||||
receive one free slot on a reconnection. Other servers using this mechanism
|
||||
will also be made aware of details about slots.
|
||||
|
||||
Target change does not apply if you are opped or voiced in a channel, and
|
||||
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.
|
||||
|
|
@ -1,89 +0,0 @@
|
|||
# Generated automatically from Makefile.in by configure.
|
||||
# makefile for include/
|
||||
|
||||
AUTOMAKE_OPTIONS = foreign
|
||||
|
||||
prefix= @prefix@
|
||||
exec_prefix= @execprefix@
|
||||
helpdir= @helpdir@
|
||||
uhelpdir= ${helpdir}/users
|
||||
ohelpdir= ${helpdir}/opers
|
||||
|
||||
SYMLINKS= topic accept cmode admin names links away whowas \
|
||||
version kick who invite quit join list nick oper part \
|
||||
time credits motd userhost users whois ison lusers \
|
||||
user help pass error challenge knock ping pong \
|
||||
map trace chantrace extban monitor
|
||||
|
||||
all:
|
||||
build:
|
||||
clean:
|
||||
depend:
|
||||
lint:
|
||||
|
||||
index:
|
||||
@echo building index files
|
||||
rm -f users/index.tmp
|
||||
@for help in users/*; do \
|
||||
if [ -f $$help ]; then \
|
||||
echo $$help >> users/index.tmp; \
|
||||
fi \
|
||||
done
|
||||
@for help in $(SYMLINKS); do \
|
||||
echo $$help >> users/index.tmp; \
|
||||
done
|
||||
echo 'Help topics available to users:' > users/index
|
||||
echo '' >> users/index
|
||||
cat users/index.tmp \
|
||||
| sed -e 's|^users/||' \
|
||||
| sort -u \
|
||||
| tr a-z A-Z \
|
||||
| column -c 65 -x \
|
||||
| expand \
|
||||
>> users/index
|
||||
rm -f users/index.tmp
|
||||
rm -f opers/index.tmp
|
||||
@for help in opers/*; do \
|
||||
if [ -f $$help ]; then \
|
||||
echo $$help >> opers/index.tmp; \
|
||||
fi \
|
||||
done
|
||||
echo 'Help topics available to opers:' > opers/index
|
||||
echo '' >> opers/index
|
||||
cat opers/index.tmp \
|
||||
| sed -e 's|^opers/||' \
|
||||
| sort -u \
|
||||
| tr a-z A-Z \
|
||||
| column -c 65 -s ' ' -x \
|
||||
| expand \
|
||||
>> opers/index
|
||||
rm -f opers/index.tmp
|
||||
|
||||
install:
|
||||
-@if test -d $(DESTDIR)$(helpdir)-old; then \
|
||||
rm -rf $(DESTDIR)$(helpdir)-old; \
|
||||
fi
|
||||
-@if test -d $(DESTDIR)$(helpdir); then \
|
||||
echo "ircd: backing up old help files"; \
|
||||
mv $(DESTDIR)$(helpdir) $(DESTDIR)$(helpdir)-old; \
|
||||
fi
|
||||
|
||||
@echo "ircd: setting up help directory structure"
|
||||
@mkdir -p -m 755 $(DESTDIR)$(helpdir)
|
||||
@mkdir -p -m 755 $(DESTDIR)$(helpdir)/opers
|
||||
@mkdir -p -m 755 $(DESTDIR)$(helpdir)/users
|
||||
|
||||
@for help in opers/*; do \
|
||||
if [ -f $$help ]; then \
|
||||
${INSTALL_DATA} $$help $(DESTDIR)$(ohelpdir); \
|
||||
fi \
|
||||
done
|
||||
@for help in users/*; do \
|
||||
if [ -f $$help ]; then \
|
||||
$(INSTALL_DATA) $$help $(DESTDIR)$(uhelpdir); \
|
||||
fi \
|
||||
done
|
||||
@for link in $(SYMLINKS); do \
|
||||
rm -f $(DESTDIR)$(uhelpdir)/$$link; \
|
||||
ln -s $(ohelpdir)/$$link $(DESTDIR)$(uhelpdir); \
|
||||
done
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
ACCEPT <parameter>
|
||||
|
||||
ACCEPT allows you to control who can send you a NOTICE or PRIVMSG
|
||||
while you have user mode +g enabled.
|
||||
|
||||
Accepted users can also message you if you have user mode +R
|
||||
enabled, even if they are not logged in with services.
|
||||
|
||||
For +g: /QUOTE ACCEPT <nick> -- Add a permitted nickname
|
||||
/QUOTE ACCEPT -<nick> -- Remove a permitted nickname
|
||||
/QUOTE ACCEPT * -- List the present permitted nicknames
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
ADMIN [server]
|
||||
|
||||
With no arguments, ADMIN shows the information that was set by the
|
||||
administrator of the server. This information can take any form that
|
||||
will fit in three lines of text but is usually a list of contacts
|
||||
for the persons that run the server.
|
||||
|
||||
With a second argument, the administrative information for the
|
||||
specified server is displayed.
|
||||
|
||||
See also: stats
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
AWAY :[MSG]
|
||||
|
||||
Without an argument, it will set you back. With an argument,
|
||||
it will set you as AWAY with the specified message.
|
||||
|
|
@ -1 +0,0 @@
|
|||
CAPAB - Server to Server Protocol Command.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
CHALLENGE <nick|+response>
|
||||
|
||||
CHALLENGE is used in the RSA controlled
|
||||
oper {} system. CHALLENGE requires you to
|
||||
issue the command using the nickname in the
|
||||
operator block, while matching the username
|
||||
and hostname specified. The server will
|
||||
send you an RSA challenge. You must send
|
||||
a valid RSA response back to the server,
|
||||
proceeded with a '+' symbol.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
CHANTRACE <#channel>
|
||||
|
||||
Outputs a list of members in #channel in ETRACE format, with the class name
|
||||
replaced by the server the users are on.
|
||||
|
||||
You must be a member of the channel to perform this command.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
CLOSE
|
||||
|
||||
Close any connections from clients or servers who have
|
||||
not fully registered yet.
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
MODE <channel> <+|-><modes> [parameters]
|
||||
|
||||
? designates that the cmode is provided by an extension
|
||||
and may not be present on this server.
|
||||
|
||||
CHANNELMODE - DESCRIPTION
|
||||
------------------------------------------------------------------------
|
||||
NO PARAMETERS:
|
||||
+n - No external messages. Only channel members may talk in
|
||||
the channel.
|
||||
+t - Ops Topic. Only opped (+o) users may set the topic.
|
||||
+s - Secret. Channel will not be shown in /whois and /list etc.
|
||||
+p - Private. Disables /knock to the channel.
|
||||
+m - Moderated. Only opped/voiced users may talk in channel.
|
||||
+i - Invite only. Users need to be invited or match a +I to
|
||||
join the channel.
|
||||
+r - Registered users only. Only users identified to services
|
||||
may join.
|
||||
+c - No color. All markup (color, bold, underline, etc.) in
|
||||
messages is stripped.
|
||||
+g - Free invite. Everyone may invite users. Significantly
|
||||
weakens +i control.
|
||||
+z - Op moderated. Messages blocked by +m, +b and +q are instead
|
||||
sent to ops.
|
||||
+L - Large ban list. Increase maximum number of +beIq entries.
|
||||
Only settable by opers.
|
||||
+P - Permanent. Channel does not disappear when empty. Only
|
||||
settable by opers.
|
||||
+F - Free target. Anyone may set forwards to this (otherwise
|
||||
ops are necessary).
|
||||
+Q - Disable forward. Users cannot be forwarded to the channel
|
||||
(however, new forwards can still be set subject to +F).
|
||||
+C - Disable CTCP. All CTCP messages to the channel, except ACTION,
|
||||
are disallowed.
|
||||
? +O - IRC Operator only channel.
|
||||
? +A - IRC server administrator only channel.
|
||||
? +T - No NOTICEs allowed in the channel.
|
||||
? +S - Only users connected via SSL/TLS may join the channel while this
|
||||
mode is set. Users already in the channel are not affected.
|
||||
|
||||
WITH PARAMETERS:
|
||||
+f - Forward. Forwards users who cannot join because of +i,
|
||||
+j, +l or +r.
|
||||
PARAMS: /mode #channel +f #channel2
|
||||
+j - Join throttle. Limits number of joins to the channel per time.
|
||||
PARAMS: /mode #channel +j count:time
|
||||
+k - Key. Requires users to issue /join #channel KEY to join.
|
||||
PARAMS: /mode #channel +k key
|
||||
+l - Limit. Impose a maximum number of LIMIT people in the channel.
|
||||
PARAMS: /mode #channel +l limit
|
||||
+v - Voice. Allows a user to talk in a +m channel. Noted by +nick.
|
||||
PARAMS: /mode #channel +v nick
|
||||
+o - Op. Allows a user full control over the channel.
|
||||
PARAMS: /mode #channel +o nick
|
||||
+b - Ban. Prevents a user from entering the channel, and from
|
||||
sending or changing nick if they are on it, based on a
|
||||
nick!ident@host match.
|
||||
PARAMS: /mode #channel +b nick!user@host
|
||||
+q - Quiet. Prevents a user from sending to the channel or changing
|
||||
nick, based on a nick!ident@host match.
|
||||
PARAMS: /mode #channel +q nick!user@host
|
||||
+e - Exempt. Allows a user to join a channel and send to it even if
|
||||
they are banned (+b) or quieted (+q), based on a nick!ident@host
|
||||
match.
|
||||
PARAMS: /mode #channel +e nick!user@host
|
||||
+I - Invite Exempt. Allows a user to join a +i channel without an
|
||||
invite, based on a nick!user@host match.
|
||||
PARAMS: /mode #channel +I nick!user@host
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
CONNECT <server_A> [port] [server_B]
|
||||
|
||||
When [server_B] is used, CONNECT asks [server_B] to
|
||||
connect to <server_A>. Requires Oper Priv: oper:routing
|
||||
|
||||
The [port] must be specified with [server_B], this is
|
||||
usually 6667. To use the default port in the connect
|
||||
block, you can use 0 as the port.
|
||||
|
||||
When [server_B] is not used, CONNECT tries to connect
|
||||
your server to <server_A>.
|
||||
|
||||
When [port] is used, the connection will be attempted
|
||||
to [port].
|
||||
When [port] is not used, 6667 is used as a default,
|
||||
unless the port is specified in the conf file.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
Help File Credits
|
||||
|
||||
Help files were written by the following people:
|
||||
|
||||
disasta David Daley <disasta@go.com>
|
||||
Hwy101 W. Campbell <wcampbel@botbay.net>
|
||||
larne Edward Brocklesby <ejb@leguin.org.uk>
|
||||
lyska Sam Dodrill <shadowh511@gmail.com>
|
||||
MoeBass anonymous <moe@moebass.com>
|
||||
screwedup Jonathan Roes <jroes@magenet.net>
|
||||
zartik Daniel Hemmerich <dan@spot.org>
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
DIE server.name
|
||||
|
||||
Terminates the IRC server.
|
||||
|
||||
- Requires Oper Priv: oper:die
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
DLINE [duration] <ip> :[reason] [| oper reason]
|
||||
|
||||
Adds a DLINE to the database which will deny any
|
||||
connections from the IP address of the banned client.
|
||||
The banned client will receive a message saying
|
||||
they are banned with reason [reason].
|
||||
|
||||
Duration is optional, and is in minutes. If specified,
|
||||
the DLINE will not be saved in the database.
|
||||
|
||||
If an oper reason is added (the pipe must be specified
|
||||
to seperate the fields) this will be added into the
|
||||
database but will not be shown to the user when they
|
||||
are given the kline reason.
|
||||
|
||||
DLINE [duration] <ip> ON irc.server :[reason] [| oper reason]
|
||||
will dline the user on irc.server if irc.server accepts
|
||||
remote dlines. irc.server can contain wildcards.
|
||||
|
||||
- Requires Oper Priv: oper:kline
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
ERROR :<message>
|
||||
|
||||
ERROR is sent by the server to clients
|
||||
or other servers when an exception occurs.
|
||||
|
||||
If another server sends your server an
|
||||
ERROR, it will be shown to all operators
|
||||
on the server.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
ETRACE [-full|-v4|-v6|nick]
|
||||
|
||||
With no argument, ETRACE gives a list of all clients connected
|
||||
to the local server, both users and operators.
|
||||
|
||||
With -full option, ETRACE lists all clients along with the
|
||||
two unused fields sent in the USER command when they connected.
|
||||
|
||||
When ipv6 is enabled, the -v4 and -v6 options display clients
|
||||
using ipv4 and ipv6 respectively.
|
||||
|
||||
You may also specify a specific nickname to ETRACE. The target
|
||||
can be a local or remote client, however the ETRACE will be "lost"
|
||||
if the remote server does not support this extension. The
|
||||
"-full" option will be implied and should not be specified with
|
||||
it.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
MODE <channel> <+|-><b|q|e|I> $[~]<type>[:<data>]
|
||||
|
||||
Extended bans (ban conditionals) allow different checks than the usual
|
||||
nick!user@host or nick!user@ip match to determine whether someone should
|
||||
be banned, quieted, exempted or invited.
|
||||
|
||||
Extended bans are of the form $[~]<type>[:<data>]. The <type> is one
|
||||
character (case insensitive) and determines the type of match. Most types
|
||||
allow or require an extra field <data>. If the tilde (~) is present, the
|
||||
result of the comparison will be negated, unless the ban is invalid in which
|
||||
case it will never match. Invalid bans are ones where <data> is missing but
|
||||
required or where <data> is otherwise invalid as noted below.
|
||||
|
||||
Unless noted below, all types can be used with +b, +q, +e and +I.
|
||||
|
||||
extb Type - DESCRIPTION
|
||||
------------------------------------------------------------------------
|
||||
$a - Matches all logged in users
|
||||
$a:<mask> - Matches users logged in with a username matching the mask
|
||||
(* and ? wildcards)
|
||||
$c:<chan> - Matches users who are on the given channel; this is only
|
||||
valid if the channel exists and is not +s or +p. (The ops
|
||||
of the channel the ban is on cannot necessarily see whether
|
||||
the user is in the target channel, so it should not
|
||||
influence whether they can join either.)
|
||||
$o - Matches opers (most useful with +I)
|
||||
$r:<mask> - Matches users with a realname (gecos) matching the mask
|
||||
(* and ? wildcards); this can only be used with +b and +q
|
||||
$s:<mask> - matches users connected to a server matching the mask
|
||||
(* and ? wildcards); this can only be used with +b and +q
|
||||
$j:<chan> - matches users who are or are not banned from a specified
|
||||
channel
|
||||
$x:<mask> - Bans all users with matching nick!user@host#gecos
|
||||
$z - Matches all SSL users
|
||||
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
HELP [topic]
|
||||
|
||||
HELP displays the contents of the help
|
||||
file for topic requested. If no topic is
|
||||
requested, it will perform the equivalent
|
||||
to HELP index.
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
Help topics available to opers:
|
||||
|
||||
ACCEPT ADMIN AWAY CAPAB
|
||||
CHALLENGE CHANTRACE CLOSE CMODE
|
||||
CONNECT CREDITS DIE DLINE
|
||||
ERROR ETRACE EXTBAN HELP
|
||||
INDEX INFO INVITE ISON
|
||||
JOIN KICK KILL KLINE
|
||||
KNOCK LINKS LIST LOCOPS
|
||||
LUSERS MAP MASKTRACE MODLIST
|
||||
MODLOAD MODRELOAD MODRESTART MODUNLOAD
|
||||
MONITOR MOTD NAMES NICK
|
||||
NOTICE OPER OPERSPY OPERWALL
|
||||
PART PASS PING PONG
|
||||
POST PRIVMSG PRIVS QUIT
|
||||
REHASH RESTART RESV SCAN
|
||||
SERVER SET SJOIN SNOMASK
|
||||
SQUIT STATS SVINFO TESTGECOS
|
||||
TESTLINE TESTMASK TIME TOPIC
|
||||
TRACE UHELP UMODE UNDLINE
|
||||
UNKLINE UNREJECT UNRESV UNXLINE
|
||||
USER USERHOST USERS VERSION
|
||||
WALLOPS WHO WHOIS WHOWAS
|
||||
XLINE
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
INFO [server]
|
||||
|
||||
INFO displays the copyright, list of authors and contributors
|
||||
to ircd, and the server configuration (as defined in config.h
|
||||
and ircd.conf).
|
||||
|
||||
If an argument is supplied, the information for the server
|
||||
specified will be returned.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
INVITE <nickname> <channel>
|
||||
|
||||
INVITE sends a notice to the user that you have
|
||||
asked him/her to come to the specified channel.
|
||||
If the channel is +i, +j, +l or +r, this will
|
||||
allow the user to bypass these modes.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
ISON <nick_A> [nick_B] :[nick_C] [nick_D]
|
||||
|
||||
ISON will return a list of users who are present
|
||||
on the network from the list that was passed in.
|
||||
|
||||
This command is rarely used directly.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
JOIN <#channel> [key]
|
||||
|
||||
The JOIN command allows you to enter a public chat area known as
|
||||
a channel. Network wide channels are proceeded by a '#', while
|
||||
a local server channel is proceeded by an '&'. More than one
|
||||
channel may be specified, separated with commas (no spaces).
|
||||
|
||||
If the channel has a key set, the 2nd argument must be
|
||||
given to enter. This allows channels to be password protected.
|
||||
|
||||
See also: part, list
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
KICK <channel> <nick> :[msg]
|
||||
|
||||
The KICK command will remove the specified user
|
||||
from the specified channel, using the optional
|
||||
kick message. You must be a channel operator to
|
||||
use this command.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
KILL <nick> <reason>
|
||||
|
||||
Disconnects user <nick> from the IRC server he/she
|
||||
is connected to with reason <reason>.
|
||||
|
||||
- Requires Oper Priv: oper:local_kill
|
||||
- Requires Oper Priv: oper:global_kill for users not on your IRC server
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
KLINE <user@host> :[reason] [| oper reason]
|
||||
|
||||
Adds a KLINE to the database which will ban the
|
||||
specified user from using this server. The banned
|
||||
client will receive a message saying he/she is banned
|
||||
with reason [reason].
|
||||
|
||||
If an oper reason is added (the pipe must be specified
|
||||
to seperate the fields) this will be added into the
|
||||
database but will not be shown to the user when they
|
||||
are given the kline reason.
|
||||
|
||||
KLINE <user@ip.ip.ip.ip> :[reason] [| oper reason]
|
||||
will kline the user at the unresolved ip.
|
||||
ip.ip.ip.ip can be in CIDR form i.e. 192.168.0.0/24
|
||||
or 192.168.0.* (which is converted to CIDR form internally)
|
||||
|
||||
For a temporary KLINE, length of kline is given in
|
||||
minutes as the first parameter i.e.
|
||||
KLINE 10 <user@host> :cool off for 10 minutes
|
||||
|
||||
KLINE [duration] <user@host> ON irc.server :[reason] [| oper reason]
|
||||
will kline the user on irc.server if irc.server accepts
|
||||
remote klines. irc.server can contain wildcards.
|
||||
|
||||
- Requires Oper Priv: oper:kline
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
KNOCK <channel>
|
||||
|
||||
KNOCK requests access to a channel that
|
||||
for some reason is not open.
|
||||
|
||||
KNOCK cannot be used if you are banned, the
|
||||
channel is +p, or it is open.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
LINKS [[remote] mask]
|
||||
|
||||
LINKS shows a list of all servers linked to the host server.
|
||||
|
||||
With a mask parameter, LINKS will just show servers matching
|
||||
that parameter. With the remote server parameter, LINKS will
|
||||
request the LINKS data from the remote server, matching the
|
||||
mask given.
|
||||
|
||||
The information provided by the LINKS command can be helpful
|
||||
for determining the overall shape of the network in addition to
|
||||
its size.
|
||||
|
||||
NOTE: the links command employs an intensive process to generate
|
||||
it's output, so sparing use is recommended.
|
||||
|
||||
See also: connect map squit
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
LIST [#channel]|[modifiers]
|
||||
|
||||
Without any arguments, LIST will give an entire list of all
|
||||
channels which are not set as secret (+s). The list will be in
|
||||
the form:
|
||||
|
||||
<#channel> <amount of users> :[topic]
|
||||
|
||||
If an argument supplied is a channel name, LIST will give just
|
||||
the statistics for the given channel.
|
||||
|
||||
Modifiers are also supported, seperated by a comma:
|
||||
<n - List channels with less than n users
|
||||
>n - List channels with more than n users
|
||||
C<n - List channels created in the last n minutes
|
||||
C>n - List channels older than n minutes
|
||||
T<n - List channels whose topics have changed in the
|
||||
last n minutes
|
||||
T>n - List channels whose topics were last changed
|
||||
more than n minutes ago
|
||||
|
||||
eg LIST <100,>20
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
LOCOPS :<message>
|
||||
|
||||
Sends a LOCOPS message of <message> to all
|
||||
opers on local server who are umode +l
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
LUSERS [mask [remoteserver]]
|
||||
|
||||
LUSERS will display client count statistics.
|
||||
If a remote server is specified, it will
|
||||
request the information from that server.
|
||||
The mask parameter is obsolete but still
|
||||
needs to be used when querying a remote
|
||||
server.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
MAP
|
||||
|
||||
MAP shows a graphical map of the network with user
|
||||
counts and TS6 SIDs (if known).
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
MASKTRACE [<nick>!]<user>@<host> :<gecos>
|
||||
|
||||
Outputs a list of local users matching the given masks
|
||||
in ETRACE format, with the classname replaced by
|
||||
the server the users are on. Gecos uses the same
|
||||
wildcards as xlines; nick, user and host use just
|
||||
? and *.
|
||||
|
||||
Supports using CIDR ip masks as a hostname.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
MODLIST [match string]
|
||||
|
||||
-- List the modules that are currently loaded into the
|
||||
ircd, along with their address and version.
|
||||
When a match string is provided, modlist only prints
|
||||
modules with names matching the match string.
|
||||
|
||||
- Requires Oper Priv: oper:admin
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
MODLOAD <[path/]module.so>
|
||||
|
||||
-- Load a module into the ircd
|
||||
the optional path can be an absolute path
|
||||
from / or from the IRCD_PREFIX
|
||||
(ie modules/autoload/m_users.so)
|
||||
|
||||
- Requires Oper Priv: oper:admin
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
MODRELOAD <module.so>
|
||||
|
||||
-- Reload a module in the ircd
|
||||
Use just the module name, the path is not needed.
|
||||
|
||||
- Requires Oper Priv: oper:admin
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
MODRESTART
|
||||
|
||||
-- Reload all modules into the ircd
|
||||
All modules are unloaded, then those in modules/autoload
|
||||
are loaded
|
||||
|
||||
- Requires Oper Priv: oper:admin
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
MODUNLOAD <module.so>
|
||||
|
||||
-- Unload a module from the ircd
|
||||
Use just the module name, the path is not needed.
|
||||
When a module is unloaded, all commands associated
|
||||
with it are unloaded as well.
|
||||
|
||||
- Requires Oper Priv: oper:admin
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
MONITOR <action> [nick[,nick]*]
|
||||
|
||||
Manages the online-notification list (similar to WATCH elsewhere). The
|
||||
<action> must be a single character, one of:
|
||||
|
||||
+ adds the given list of nicknames to the monitor list, returns
|
||||
each given nickname's status as RPL_MONONLINE or RPL_MONOFFLINE
|
||||
numerics
|
||||
|
||||
- removes the given list of nicknames from the monitor list, does
|
||||
not return anything
|
||||
|
||||
C clears the monitor list, does not return anything
|
||||
|
||||
L returns the current monitor list as RPL_MONLIST numerics,
|
||||
terminated with RPL_ENDOFMONLIST
|
||||
|
||||
S returns status of each monitored nickname, as RPL_MONONLINE or
|
||||
RPL_MONOFFLINE numerics
|
||||
|
||||
For example:
|
||||
|
||||
MONITOR + jilles,kaniini,tomaw
|
||||
|
||||
RPL_MONONLINE numerics return a comma-separated list of nick!user@host
|
||||
items. RPL_MONOFFLINE and RPL_MONLIST numerics return a comma-separated
|
||||
list of nicknames.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
MOTD [servername]
|
||||
|
||||
MOTD will display the message of the day for the
|
||||
server name specified, or the local server if there
|
||||
was no parameter.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
NAMES [channel]
|
||||
|
||||
With no channel argument, NAMES shows the names (nicks) of all clients
|
||||
logged in to the network that do not have +i flag.
|
||||
|
||||
With the #channel argument, it displays the nicks on that channel,
|
||||
also respecting the +i flag of each client. If the channel specified
|
||||
is a channel that the issuing client is currently in, all nicks are
|
||||
listed in similar fashion to when the user first joins a channel.
|
||||
|
||||
See also: join
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
NICK <nickname>
|
||||
|
||||
When first connected to the IRC server, NICK is required to
|
||||
set the client's nickname.
|
||||
|
||||
NICK will also change the client's nickname once a connection
|
||||
has been established.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
NOTICE <nick|channel> :message
|
||||
|
||||
NOTICE will send a notice message to the
|
||||
user or channel specified.
|
||||
|
||||
NOTICE supports the following prefixes for sending
|
||||
messages to specific clients in a channel:
|
||||
|
||||
@ - channel operators only
|
||||
+ - channel operators and voiced users
|
||||
|
||||
Two other targets are permitted:
|
||||
|
||||
$$servermask - Send a message to a server or set of
|
||||
servers
|
||||
$#hostmask - Send a message to users matching the
|
||||
hostmask specified.
|
||||
|
||||
These two are operator only.
|
||||
|
||||
The nick can be extended to fit into the following
|
||||
syntax:
|
||||
|
||||
username@servername
|
||||
|
||||
This syntax is used to securely send a message to a
|
||||
service or a bot.
|
||||
|
||||
An extension of this is the syntax to send to all opers
|
||||
on a server.
|
||||
|
||||
opers@servername
|
||||
|
||||
In Hybrid 7, all opers on a server will see a message that
|
||||
looks like a modified WALLOPS
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
OPER <name> <password>
|
||||
|
||||
The OPER command requires two arguments to be given. The first
|
||||
argument is the name of the operator as specified in the
|
||||
configuration file. The second argument is the password for
|
||||
the operator matching the name and host.
|
||||
|
||||
The operator privileges are shown on a successful OPER.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
OPERSPY
|
||||
|
||||
Opers with the "oper_spy" flag will be allowed uses of the following
|
||||
commands if they are compiled in. Usage will be sent to +Z and all
|
||||
other servers.
|
||||
|
||||
whois !nick - Gives a full output of channels the user is in.
|
||||
who !mask - Lists all users on the network whose nick, ident, host,
|
||||
server or gecos match the mask.
|
||||
who !#channel - Gives a full output of users on the channel.
|
||||
mode !#channel - Gives the full modes of a channel including any keys.
|
||||
chantrace !#channel - Gives full output despite not being on channel.
|
||||
masktrace !nick!user@host :gecos - Lists matching users on all servers.
|
||||
topic !#channel - Gives full output despite not being on channel.
|
||||
list !#channel - Gives full output despite not being on channel.
|
||||
list ![options...] - Lists all channels, including secret channels.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
OPERWALL :<message>
|
||||
|
||||
Sends an OPERWALL message of <message> to all
|
||||
opers who are umode +z
|
||||
|
||||
- Requires Oper Priv: oper:operwall
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
PART <#channel> :[part message]
|
||||
|
||||
PART requires at least a channel argument to be given. It will
|
||||
exit the client from the specified channel. More than one
|
||||
channel may be specified, separated with commas (no spaces).
|
||||
|
||||
An optional part message may be given to be displayed to the
|
||||
channel.
|
||||
|
||||
See also: join
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
PASS <password>
|
||||
|
||||
PASS is used during registration to access
|
||||
a password protected auth {} block.
|
||||
|
||||
PASS is also used during server registration.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
PING <source> :<target>
|
||||
|
||||
PING will request a PONG from the target. If a
|
||||
user or operator issues this command, the source
|
||||
will always be turned into the nick that issued
|
||||
the PING.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
PONG <pinged-client> :<source-client>
|
||||
|
||||
PONG is the response to a PING command. The
|
||||
source client is the user or server that issued
|
||||
the command, and the pinged client is the
|
||||
user or server that received the PING.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
POST
|
||||
|
||||
The POST command is used to help protect against
|
||||
insecure HTTP proxies. Any proxy that sends a POST
|
||||
command during registration will be exited.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
PRIVMSG <nick|channel> :message
|
||||
|
||||
PRIVMSG will send a standard message to the
|
||||
user or channel specified.
|
||||
|
||||
PRIVMSG supports the following prefixes for sending
|
||||
messages to specific clients in a channel:
|
||||
|
||||
@ - channel operators only
|
||||
+ - channel operators and voiced users
|
||||
|
||||
Two other targets are permitted:
|
||||
|
||||
$$servermask - Send a message to a server or set of
|
||||
servers
|
||||
$#hostmask - Send a message to users matching the
|
||||
hostmask specified.
|
||||
|
||||
These two require Oper Priv: oper:mass_notice
|
||||
|
||||
The nick can be extended to fit into the following
|
||||
syntax:
|
||||
|
||||
username@servername
|
||||
|
||||
This syntax is used to securely send a message to a
|
||||
service or a bot.
|
||||
|
||||
An extension of this is the syntax to send to all opers
|
||||
on a server.
|
||||
|
||||
opers@servername
|
||||
|
||||
In Hybrid 7, all opers on a server will see a message that
|
||||
looks like a modified WALLOPS
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
PRIVS [nick]
|
||||
|
||||
PRIVS displays effective operator privileges for
|
||||
the specified nick, or for yourself if no nick is
|
||||
given. This includes all privileges from the operator
|
||||
block, the name of the operator block and those
|
||||
privileges from the auth block that have an effect
|
||||
after the initial connection.
|
||||
|
||||
The exact format depends on the server the nick is on;
|
||||
if it does not support this extension, you will not
|
||||
receive a reply.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
QUIT :[quit message]
|
||||
|
||||
QUIT sends a message to the IRC server letting it know you would
|
||||
like to disconnect. The quit message will be displayed to the
|
||||
users in the channels you were in when you are disconnected.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
REHASH [option]
|
||||
|
||||
When no [option] is given, ircd will re-read the
|
||||
ircd.conf file.
|
||||
|
||||
[option] can be one of the following:
|
||||
BANS - Re-reads kline/dline/resv/xline database
|
||||
DNS - Re-read the /etc/resolv.conf file
|
||||
HELP - Re-reads help files
|
||||
MOTD - Re-reads MOTD file
|
||||
NICKDELAY - Clears delayed nicks
|
||||
OMOTD - Re-reads Oper MOTD file
|
||||
REJECTCACHE - Clears the reject cache
|
||||
SSLD - Restarts the ssld processes
|
||||
TDLINES - Clears temporary D Lines
|
||||
THROTTLES - Clears throttled IP addresses
|
||||
TKLINES - Clears temporary K Lines
|
||||
TRESVS - Clears temporary nick and channel resvs
|
||||
TXLINES - Clears temporary X Lines
|
||||
|
||||
- Requires Oper Priv: oper:rehash
|
||||
|
||||
REHASH [option] irc.server
|
||||
|
||||
Rehashes [option], or the config file if none given, on irc.server if
|
||||
irc.server accepts remote rehashes.
|
||||
|
||||
- Requires Oper Privs: oper:rehash, oper:remoteban
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
RESTART server.name
|
||||
|
||||
Restarts the IRC server.
|
||||
|
||||
- Requires Oper Priv: oper:die
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
RESV [time] <channel|nick> :<reason>
|
||||
|
||||
Reserves a channel or nickname from use. If [time] is not specified this
|
||||
is added to the database, otherwise is temporary for [time] minutes.
|
||||
|
||||
Nick resvs accept the same wildcard chars as xlines.
|
||||
Channel resvs only use exact string comparisons.
|
||||
|
||||
RESV [time] <channel|nick> ON <server> :<reason>
|
||||
|
||||
Will attempt to set the RESV on <server> if <server> accepts remote RESVs.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
SCAN UMODES +<modes>-<modes> [NO-LIST] [LIST] [GLOBAL]
|
||||
[LIST-MAX <number>] [MASK <nick!user@host>]
|
||||
|
||||
Searches the local server or network for users that have the
|
||||
umodes given with + and do not have the umodes given with -.
|
||||
NO-LIST disables the listing of matching users and only
|
||||
shows the count. LIST enables the listing (default). GLOBAL
|
||||
extends the search to the entire network instead of local
|
||||
users only. LIST-MAX limits the listing of matching users to
|
||||
the given amount instead of the default 500. MASK causes
|
||||
only users matching the given nick!user@host mask to be
|
||||
selected. Only the displayed host is considered, not the
|
||||
IP address or real host behind dynamic spoofs.
|
||||
|
||||
Network searches where a listing is given are operspy
|
||||
commands.
|
||||
|
|
@ -1 +0,0 @@
|
|||
SERVER - Server to Server Protocol Command.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
SET <option> <value>
|
||||
|
||||
<option> can be one of the following:
|
||||
ADMINSTRING - Sets string shown in WHOIS for admins
|
||||
AUTOCONN - Sets auto-connect on or off for a particular
|
||||
server
|
||||
AUTOCONNALL - Sets auto-connect on or off for all servers
|
||||
FLOODCOUNT - The number of lines allowed before
|
||||
throttling a connection due to flooding
|
||||
Note that this variable is used for both
|
||||
channels and clients
|
||||
IDENTTIMEOUT- Timeout for requesting ident from a client
|
||||
MAX - Sets the number of max connections
|
||||
to <value>.
|
||||
OPERSTRING - Sets string shown in WHOIS for opers
|
||||
SPAMNUM - Sets how many join/parts to channels
|
||||
constitutes a possible spambot.
|
||||
SPAMTIME - Below this time on a channel
|
||||
counts as a join/part as above.
|
||||
SPLITMODE - Sets splitmode to <value>:
|
||||
ON - splitmode is permanently on
|
||||
OFF - splitmode is permanently off
|
||||
AUTO - ircd chooses splitmode based on
|
||||
SPLITUSERS and SPLITNUM
|
||||
SPLITUSERS - Sets the minimum amount of users needed to
|
||||
deactivate automatic splitmode.
|
||||
SPLITNUM - Sets the minimum amount of servers needed to
|
||||
deactivate automatic splitmode.
|
||||
|
|
@ -1 +0,0 @@
|
|||
SJOIN - Server to Server Protocol Command.
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
MODE <nick> +s <+|-><modes>
|
||||
|
||||
Server notice masks:
|
||||
|
||||
SNOMASK DESCRIPTION
|
||||
-----------------------------------------------------------------
|
||||
+b - Possible spambot/flooder warnings
|
||||
+c - Local client connections and exits
|
||||
+C - Extended local client connections and exits
|
||||
+d - Server debug messages
|
||||
+f - Clients refused due to limits
|
||||
+k - Server and service kill messages
|
||||
+n - Local client nick changes
|
||||
+r - Invalid usernames and DNSBL listings
|
||||
+s - Generic server messages and oper kills
|
||||
+u - Client connections without auth{} block
|
||||
+x - New server introduction and split messages
|
||||
+y - Juped channel join attempts, etc
|
||||
+Z - Operspy usage
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
SQUIT <server> [reason]
|
||||
|
||||
Splits <server> away from your side of the net with [reason].
|
||||
- Requires Oper Priv: oper:remote for servers not connected to you
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
STATS <letter> [server|nick]
|
||||
|
||||
Queries server [server] (or your own server if no
|
||||
server parameter is given) for info corresponding to
|
||||
<letter>.
|
||||
|
||||
(X = Admin only.)
|
||||
LETTER (* = Oper only.)
|
||||
------ (^ = Can be configured to be oper only.)
|
||||
X A - Shows DNS servers
|
||||
X b - Shows active nick delays
|
||||
X B - Shows hash statistics
|
||||
^ c - Shows connect blocks (Old C:/N: lines)
|
||||
* d - Shows temporary D lines
|
||||
* D - Shows D lines
|
||||
* e - Shows exemptions to D lines
|
||||
X E - Shows Events
|
||||
X f - Shows File Descriptors
|
||||
* g - Shows global K lines
|
||||
^ h - Shows hub_mask/leaf_mask (Old H:/L: lines)
|
||||
^ i - Shows auth blocks (Old I: lines)
|
||||
^ K - Shows K lines (or matched klines)
|
||||
^ k - Shows temporary K lines (or matched klines)
|
||||
L - Shows IP and generic info about [nick]
|
||||
l - Shows hostname and generic info about [nick]
|
||||
m - Shows commands and their usage
|
||||
n - Shows DNS blacklists
|
||||
* O - Shows privset blocks
|
||||
^ o - Shows operator blocks (Old O: lines)
|
||||
^ P - Shows configured ports
|
||||
p - Shows online opers
|
||||
* q - Shows temporary and global resv'd nicks and channels
|
||||
* Q - Shows resv'd nicks and channels
|
||||
* r - Shows resource usage by ircd
|
||||
X S - Shows ssld processes
|
||||
* t - Shows generic server stats
|
||||
* U - Shows shared blocks (Old U: lines)
|
||||
u - Shows server uptime
|
||||
^ v - Shows connected servers and brief status information
|
||||
* x - Shows temporary and global gecos bans
|
||||
* X - Shows gecos bans (Old X: lines)
|
||||
^ y - Shows connection classes (Old Y: lines)
|
||||
* z - Shows memory stats
|
||||
* Z - Shows ziplinks stats
|
||||
^ ? - Shows connected servers and sendq info about them
|
||||
|
|
@ -1 +0,0 @@
|
|||
SVINFO - Server to Server Protocol Command.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
TESTGECOS <gecos>
|
||||
|
||||
Looks for matching xlines for the given gecos.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
TESTLINE [[nick!]user@]host
|
||||
|
||||
Looks up given mask, looking for any matching I/K/D lines.
|
||||
If username is not specified, it will look up "dummy@host".
|
||||
If nickname is specified it will also search for RESVs.
|
||||
|
||||
This command will not perform dns lookups on a host, for best
|
||||
results you must testline a host and its IP form.
|
||||
|
||||
TESTLINE <#channel>
|
||||
|
||||
Shows whether the channel is reserved or not.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
TESTMASK <[nick!]user@host> [:gecos]
|
||||
|
||||
Will test the given nick!user@host gecos mask, reporting how many local
|
||||
and global clients match the given mask. Supports using CIDR ip masks
|
||||
as a host.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
TIME [server]
|
||||
|
||||
The TIME command will return the server's local date and time.
|
||||
|
||||
If an argument is supplied, the time for the server specified
|
||||
will be returned.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
TOPIC <#channel> :[new topic]
|
||||
|
||||
With only a channel argument, TOPIC shows the current topic of
|
||||
the specified channel.
|
||||
|
||||
With a second argument, it changes the topic on that channel to
|
||||
<new topic>. If the channel is +t, only chanops may change the
|
||||
topic.
|
||||
|
||||
See also: cmode
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
TRACE [server | nick] [location]
|
||||
|
||||
With no argument, TRACE gives a list of all clients connected
|
||||
to the local server, both users and operators.
|
||||
|
||||
With one argument which is a server, TRACE displays the path
|
||||
to the specified server, and all servers, opers and -i users
|
||||
on that server.
|
||||
|
||||
Nonopers can only see themselves, opers, and servers in the
|
||||
first two forms.
|
||||
|
||||
With one argument which is a client, TRACE displays the
|
||||
path to that client, and that client's information.
|
||||
|
||||
If location is given, the command is executed on that server;
|
||||
no path is displayed.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
UHELP [topic]
|
||||
|
||||
UHELP allows an operator to view help topics
|
||||
for users without opening a second client
|
||||
or removing their operator status.
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
MODE <nick> <+|-><modes>
|
||||
|
||||
User modes: (* designates that the umode is oper only)
|
||||
(? designates that the umode is provided by an extension
|
||||
and may not be present on this server)
|
||||
|
||||
USERMODE DESCRIPTION
|
||||
-----------------------------------------------------------------
|
||||
+i - Designates this client 'invisible'.
|
||||
+g - "caller id" mode only allow accept clients to message you
|
||||
+w - Can see oper and server wallops.
|
||||
? +h - Has a cloaked host. May be +x depending on cloaking module
|
||||
+o - Designates this client is an IRC Operator.
|
||||
Use the /oper command to attain this.
|
||||
* +a - Is marked as a server admin in whois.
|
||||
* +l - Can see oper locops (local wallops).
|
||||
* +s - Can see server notices (see /quote help snomask).
|
||||
* +z - Can see operwalls.
|
||||
? +C - Prevents you from receiving CTCPs other than ACTION.
|
||||
+D - Deaf - ignores all channel messages.
|
||||
+Q - Prevents you from being affected by channel forwarding.
|
||||
+R - Prevents unidentified users that you have not accepted from
|
||||
messaging you.
|
||||
+Z - Is connected via SSL (cannot be set or unset).
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
UNDLINE <ip>
|
||||
|
||||
Will attempt to undline the given <ip>
|
||||
|
||||
- Requires Oper Priv: oper:unkline
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
UNKLINE <user@host>
|
||||
|
||||
Will attempt to unkline the given <user@host>
|
||||
Will unkline a temporary kline.
|
||||
|
||||
UNKLINE <user@host> ON irc.server will unkline
|
||||
the user on irc.server if irc.server accepts
|
||||
remote unklines.
|
||||
|
||||
- Requires Oper Priv: oper:unkline
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
UNREJECT <ip>
|
||||
|
||||
Removes an IP address from the reject cache. IP
|
||||
addresses are added to the reject cache if they are
|
||||
rejected (e.g. connect and are K-lined) several
|
||||
times in a short period of time.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
UNRESV <channel|nick>
|
||||
|
||||
-- Remove a RESV on a channel or nick
|
||||
Will attempt to remove the resv for the given
|
||||
channel/nick.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
UNXLINE <gecos>
|
||||
|
||||
Will attempt to unxline the given <gecos>
|
||||
|
||||
|
||||
UNXLINE <gecos> ON <server>
|
||||
|
||||
Will attempt to unxline the given <gecos> on <server>.
|
||||
|
||||
- Requires Oper Priv: oper:xline
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
USER <username> <unused> <unused> :<real name/gecos>
|
||||
|
||||
USER is used during registration to set your gecos
|
||||
and to set your username if the server cannot get
|
||||
a valid ident response. The second and third fields
|
||||
are not used, but there must be something in them.
|
||||
The reason is backwards compatibility
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
USERHOST <nick>
|
||||
|
||||
USERHOST displays the username, hostname,
|
||||
operator status, and presence of valid ident of
|
||||
the specified nickname.
|
||||
|
||||
If you use USERHOST on yourself, the hostname
|
||||
is replaced with the IP you are connecting from.
|
||||
This is needed to provide DCC support for spoofed
|
||||
hostnames.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
USERS [remoteserver]
|
||||
|
||||
USERS will display the local and global current
|
||||
and maximum user statistics for the specified
|
||||
server, or the local server if there was no
|
||||
parameter.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
VERSION [servername]
|
||||
|
||||
VERSION will display the server version of the specified
|
||||
server, or the local server if there was no parameter.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
WALLOPS :<message>
|
||||
|
||||
Sends a WALLOPS message of <message> to all users
|
||||
who are umode +w (including non-opers).
|
||||
|
||||
Server sent WALLOPS go to all opers who are umode +w.
|
||||
|
||||
- Requires Oper Priv: oper:mass_notice
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
WHO <#channel|nick|mask> [o][%format]
|
||||
|
||||
The WHO command displays information about a user,
|
||||
such as their GECOS information, their user@host,
|
||||
whether they are an IRC operator or not, etc. A
|
||||
sample WHO result from a command issued like
|
||||
"WHO pokey" may look something like this:
|
||||
|
||||
#lamers ~pokey ppp.example.net irc.example.com pokey H :0 Jim Jones
|
||||
|
||||
Clients often reorder the fields; the order in the
|
||||
IRC protocol is described here.
|
||||
|
||||
The first field indicates the last channel the user
|
||||
has joined. The second is the username and the third
|
||||
is the host. The fourth field is the server the user
|
||||
is on. The fifth is the user's nickname. The sixth
|
||||
field describes status information about the user.
|
||||
The possible combinations for this field are listed
|
||||
below:
|
||||
|
||||
H - The user is not away.
|
||||
G - The user is set away.
|
||||
* - The user is an IRC operator.
|
||||
@ - The user is a channel op in the channel listed
|
||||
in the first field.
|
||||
+ - The user is voiced in the channel listed.
|
||||
|
||||
The final field displays the number of server hops and
|
||||
the user's GECOS information.
|
||||
|
||||
This command may be executed on a channel, such as
|
||||
"WHO #lamers". The output will consist of WHO
|
||||
listings for each user on the channel. If you are
|
||||
not on the channel, it must not have cmode +s set
|
||||
and users with umode +i are not shown.
|
||||
|
||||
If the parameter is not a nickname or a channel, users
|
||||
with matching nickname, username, host, server or
|
||||
GECOS information are shown. The wildcards * and ?
|
||||
can be used. Users with umode +i set that are not
|
||||
on the same channel as you are not shown.
|
||||
|
||||
A second parameter of a lowercase letter o ensures
|
||||
only IRC operators are displayed.
|
||||
|
||||
The second parameter may also contain a format
|
||||
specification starting with a percent sign.
|
||||
This causes the output to use numeric 354,
|
||||
with the selected fields:
|
||||
|
||||
t - Query type. Outputs the given number in each reply.
|
||||
c - Channel.
|
||||
u - Username.
|
||||
i - IP address.
|
||||
h - Host.
|
||||
s - Server.
|
||||
n - Nickname.
|
||||
f - Status.
|
||||
d - Hop count.
|
||||
l - Idle time or 0 for users on other servers.
|
||||
a - Services account name or 0 if none.
|
||||
r - GECOS information.
|
||||
|
||||
"WHO #lamers %tuhnf,42" would generate a brief listing
|
||||
of channel members and include the number 42 in each
|
||||
line.
|
||||
|
||||
See also: whois, userhost, cmode, umode
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
WHOIS [remoteserver|nick] nick
|
||||
|
||||
WHOIS will display detailed user information for
|
||||
the specified nick. If the first parameter is
|
||||
specified, WHOIS will display information from
|
||||
the specified server, or the server that the
|
||||
user is on. This is how to remotely see
|
||||
idle time and away status.
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue