MirrorHub/construct
0
0
Fork 0
mirror of https://github.com/matrix-construct/construct synced 2024-05-17 18:33:46 +02:00
Code Issues Releases Wiki Activity

doc: Remove old docs.

Browse source
This commit is contained in:
Jason Volk 2018-09-04 04:47:04 -07:00
parent 755cfbffb0
commit 79364ef610
134 changed files with 0 additions and 10171 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
Makefile.am
View file

@ -5,7 +5,6 @@ SUBDIRS = include/ircd
SUBDIRS += ircd
SUBDIRS += modules
SUBDIRS += construct
SUBDIRS += doc
.PHONY: subdirs $(SUBDIRS)
$(SUBDIRS):

1
configure.ac
View file

@ -42,7 +42,6 @@ AC_CONFIG_FILES(\
include/ircd/Makefile \
construct/Makefile \
ircd/Makefile \
doc/Makefile \
modules/Makefile \
)

35
doc/Makefile.am
View file

@ -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

276
doc/credits-past.txt
View file

@ -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

57
doc/features/account-notify.txt
View file

@ -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.

43
doc/features/away-notify.txt
View file

@ -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.

84
doc/features/challenge.txt
View file

@ -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.

45
doc/features/collision_fnc.txt
View file

@ -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).

90
doc/features/extban.txt
View file

@ -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.)

36
doc/features/extended-join.txt
View file

@ -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.

15
doc/features/index.txt
View file

@ -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

217
doc/features/modeg.txt
View file

@ -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

115
doc/features/monitor.txt
View file

@ -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.

129
doc/features/sasl.txt
View file

@ -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

65
doc/features/services.txt
View file

@ -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

43
doc/features/tgchange.txt
View file

@ -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.

89
doc/help/Makefile.am
View file

@ -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

11
doc/help/opers/accept
View file

@ -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

11
doc/help/opers/admin
View file

@ -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

4
doc/help/opers/away
View file

@ -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
doc/help/opers/capab
View file

@ -1 +0,0 @@
CAPAB - Server to Server Protocol Command.

10
doc/help/opers/challenge
View file

@ -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.

6
doc/help/opers/chantrace
View file

@ -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.

4
doc/help/opers/close
View file

@ -1,4 +0,0 @@
CLOSE
Close any connections from clients or servers who have
not fully registered yet.

68
doc/help/opers/cmode
View file

@ -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

16
doc/help/opers/connect
View file

@ -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.

11
doc/help/opers/credits
View 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>

5
doc/help/opers/die
View file

@ -1,5 +0,0 @@
DIE server.name
Terminates the IRC server.
- Requires Oper Priv: oper:die

20
doc/help/opers/dline
View file

@ -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

8
doc/help/opers/error
View file

@ -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.

16
doc/help/opers/etrace
View file

@ -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.

35
doc/help/opers/extban
View file

@ -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

6
doc/help/opers/help
View file

@ -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.

24
doc/help/opers/index
View file

@ -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

8
doc/help/opers/info
View file

@ -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.

6
doc/help/opers/invite
View file

@ -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.

6
doc/help/opers/ison
View file

@ -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.

11
doc/help/opers/join
View file

@ -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

6
doc/help/opers/kick
View file

@ -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.

7
doc/help/opers/kill
View file

@ -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

26
doc/help/opers/kline
View file

@ -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

7
doc/help/opers/knock
View file

@ -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.

17
doc/help/opers/links
View file

@ -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

22
doc/help/opers/list
View file

@ -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

4
doc/help/opers/locops
View file

@ -1,4 +0,0 @@
LOCOPS :<message>
Sends a LOCOPS message of <message> to all
opers on local server who are umode +l

8
doc/help/opers/lusers
View file

@ -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.

4
doc/help/opers/map
View file

@ -1,4 +0,0 @@
MAP
MAP shows a graphical map of the network with user
counts and TS6 SIDs (if known).

9
doc/help/opers/masktrace
View file

@ -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.

8
doc/help/opers/modlist
View file

@ -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

8
doc/help/opers/modload
View file

@ -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

6
doc/help/opers/modreload
View file

@ -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

7
doc/help/opers/modrestart
View file

@ -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

8
doc/help/opers/modunload
View file

@ -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

27
doc/help/opers/monitor
View file

@ -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.

5
doc/help/opers/motd
View file

@ -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.

11
doc/help/opers/names
View file

@ -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

7
doc/help/opers/nick
View file

@ -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.

35
doc/help/opers/notice
View file

@ -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

8
doc/help/opers/oper
View file

@ -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.

16
doc/help/opers/operspy
View file

@ -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.

6
doc/help/opers/operwall
View file

@ -1,6 +0,0 @@
OPERWALL :<message>
Sends an OPERWALL message of <message> to all
opers who are umode +z
- Requires Oper Priv: oper:operwall

10
doc/help/opers/part
View file

@ -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

6
doc/help/opers/pass
View file

@ -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.

6
doc/help/opers/ping
View file

@ -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.

6
doc/help/opers/pong
View file

@ -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.

5
doc/help/opers/post
View file

@ -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.

35
doc/help/opers/privmsg
View file

@ -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

12
doc/help/opers/privs
View file

@ -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.

5
doc/help/opers/quit
View file

@ -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.

28
doc/help/opers/rehash
View file

@ -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

5
doc/help/opers/restart
View file

@ -1,5 +0,0 @@
RESTART server.name
Restarts the IRC server.
- Requires Oper Priv: oper:die

11
doc/help/opers/resv
View file

@ -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.

16
doc/help/opers/scan
View file

@ -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
doc/help/opers/server
View file

@ -1 +0,0 @@
SERVER - Server to Server Protocol Command.

28
doc/help/opers/set
View file

@ -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
doc/help/opers/sjoin
View file

@ -1 +0,0 @@
SJOIN - Server to Server Protocol Command.

19
doc/help/opers/snomask
View file

@ -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

4
doc/help/opers/squit
View file

@ -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

45
doc/help/opers/stats
View file

@ -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
doc/help/opers/svinfo
View file

@ -1 +0,0 @@
SVINFO - Server to Server Protocol Command.

3
doc/help/opers/testgecos
View file

@ -1,3 +0,0 @@
TESTGECOS <gecos>
Looks for matching xlines for the given gecos.

12
doc/help/opers/testline
View file

@ -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.

5
doc/help/opers/testmask
View file

@ -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.

6
doc/help/opers/time
View file

@ -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.

10
doc/help/opers/topic
View file

@ -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

17
doc/help/opers/trace
View file

@ -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.

5
doc/help/opers/uhelp
View file

@ -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.

24
doc/help/opers/umode
View file

@ -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).

5
doc/help/opers/undline
View file

@ -1,5 +0,0 @@
UNDLINE <ip>
Will attempt to undline the given <ip>
- Requires Oper Priv: oper:unkline

10
doc/help/opers/unkline
View file

@ -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

6
doc/help/opers/unreject
View file

@ -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.

5
doc/help/opers/unresv
View file

@ -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.

10
doc/help/opers/unxline
View file

@ -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

7
doc/help/opers/user
View file

@ -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

10
doc/help/opers/userhost
View file

@ -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.

6
doc/help/opers/users
View file

@ -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.

4
doc/help/opers/version
View file

@ -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.

8
doc/help/opers/wallops
View file

@ -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

69
doc/help/opers/who
View file

@ -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

8
doc/help/opers/whois
View file

@ -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