[IRC-Dev CVS] [CVS] Module ircd-ircdev: Change committed
Brought to you by:
zolty
Menu
▾
▴
[IRC-Dev CVS] [CVS] Module ircd-ircdev: Change committed
|
From: Toni G. <zo...@us...> - 2007-09-21 11:30:44
|
Committer : zolty
CVSROOT : /cvsroot/irc-dev
Module : ircd-ircdev
Commit time: 2007-09-21 11:30:37 UTC
Modified files:
doc/en/crules.txt doc/en/cvs.txt doc/en/iauth.txt doc/en/who.txt
Log message:
Actualizacion de documentacion en ingles
---------------------- diff included ----------------------
Index: ircd-ircdev/doc/en/crules.txt
diff -u ircd-ircdev/doc/en/crules.txt:1.1 ircd-ircdev/doc/en/crules.txt:1.2
--- ircd-ircdev/doc/en/crules.txt:1.1 Wed Jan 5 10:00:33 2005
+++ ircd-ircdev/doc/en/crules.txt Fri Sep 21 04:30:27 2007
@@ -1,4 +1,4 @@
-$Id: crules.txt,v 1.1 2005/01/05 18:00:33 zolty Exp $
+$Id: crules.txt,v 1.2 2007/09/21 11:30:27 zolty Exp $
SmartRoute
Rule based connects
@@ -89,23 +89,24 @@
ircd.conf entries
-----------------
-A rule is listed in the ircd.conf file using a D or d line (which can
-be thought of as a "disallow" line). D lines will apply to all oper
-and server originated connects, while d lines will apply only to
-autoconnects (ie: they are overrideable by opers). The formats are:
-
-D:targetmask::rule
-d:targetmask::rule
-
-Remember that newlines are not allowed in conf lines. Two examples
-(from above) are:
-
-D:*eu.irc-dev*::connected(*eu.irc-dev*)
-d:*eu.irc-dev*::connected(*eu.irc-dev*) || directop()
-
-Connects originating from other servers will be checked against and
-matching D lines, while matching d lines will be ignored as it will not
-be clear whether or not the connection attempt is oper initiated.
+A rule is listed in the ircd.conf file using a CRule line (which can
+be thought of as a "disallow" line). You may specify "ALL" either
+before or after the target mask to make the rule apply to all
+connections (inbound, automatic outbound and oper-initiated outbound);
+without the "ALL" modifier, the rule will apply only to automatic
+outbound connections. The formats are:
+
+CRule "targetmask" rule;
+CRule "targetmask" all rule;
+
+Two examples (from above) are:
+
+CRule "*.eu.irc-dev*" all connected("*eu.irc-dev*");
+CRule "*.eu.irc-dev*" connected("*eu.irc-dev*") || directop();
+
+Connects originating from other servers will be checked against any
+matching ALL CRules, while matching non-ALL CRules will be ignored as
+it will not be clear whether the connection attempt is oper-initiated.
Checking and viewing rules
--------------------------
Index: ircd-ircdev/doc/en/cvs.txt
diff -u ircd-ircdev/doc/en/cvs.txt:1.1 ircd-ircdev/doc/en/cvs.txt:1.2
--- ircd-ircdev/doc/en/cvs.txt:1.1 Wed Jan 5 10:00:34 2005
+++ ircd-ircdev/doc/en/cvs.txt Fri Sep 21 04:30:27 2007
@@ -1,89 +1,44 @@
-$Id: cvs.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+$Id: cvs.txt,v 1.2 2007/09/21 11:30:27 zolty Exp $
-Notes on checking out from the IRC-DevCVS archive and maintenance.
+Notes on checking out from the IRC-Dev CVS archive and maintenance.
-General Strategy:
-The main trunk of the tree will be used for ongoing development only
-(alpha) this code is not intended to be used on the production network.
-When development has reached a point of relative stability a tag will be
-applied to the development branch and a beta tag will be applied to that
-branch. For beta test servers only the tagged branches will be used.
-When a tag is applied we will also produce a snapshot tarball of the
-tag. Once a beta tagged release has been proven stable any fixes will be
-merged into the main tagged version and the code will be voted on for
-release. Fixes after release will be tagged with a patchlevel tag.
-
-You check out a tagged release by specifying the -r tag option to cvs.
-This is the command to check out the most recent tagged version of
-IRC-Dev1.0.1:
-cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -r 1_0_1 -P ircd-ircdev
-
-Developers doing maintenance and bug fixes should only check out the
-current tagged patchlevel for the affected version. Once the fix has
-proven stable, it will be merged into the tree the fix is relative to.
-
-We will not merge the changes that have been made to IRC-Dev1.0 since
-it's release into the development branch, the IRC-Dev1.0 branch is a
-maintenance only branch.
-
-If you have any questions on how to check out tagged versions check out
-the IRC-Dev web page http://www.irc-dev.net or the cvs
-manual page. If you're really stumped feel free to ask in #irc-dev.
-
-We will put out new tarballs for every tagged release which will be
-available on the IRC-Dev web page.
-
-Naming Conventions:
-
-Tag Names:
-Major release - 1
-Beta release - 1_0_0
-Production patch - 1_0_0
-
-The tree currently looks like this:
-
-Trunk: development only
-------------------------------------------------
- \ \
- \----- u2_10_07 \---- u2_10_10 --- release ---------
- \ \ \
- \--- u2_10_07_pl9 \--- u2_10_10_beta06 \ u2_10_10_pl01
-
-Patches will be rolled into the tagged branch and eventually rolled into
-the development branch. All new development should be relative to the
-trunk, only bugfixes and maintenance coding should be applied to any
-tagged version. Developers doing maintenance should only check out the
-latest pl or beta tag and apply the changes relative to that tag. These
-changes will be committed to the tag they were checked out from and once
-proven stable they will be merged into the main tagged trunk by the
-maintainer.
-
-Where to get CVS:
-http://www.cvshome.org
-
-Checking out:
-First you need to login to cvs:
-cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev login
-
-It will prompt you for a password. There is no password so hit enter.
-
-To check out the recommended patchlevel for ircu2.10.07 use:
-cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -r u2_10_07_pl6 -P ircd-ircdev
-
-For the ircu2.10.10 beta archive use:
-cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -r u2_10_10_beta06 -P ircd-ircdev
-
-To check out the current development archive use:
-cvs -d :pserver:ano...@cv...:/cvsroot/irc-dev co -P ircd-ircdev
-
-When you want to update your source tree later to the latest version, use
-cvs update -P
-
-inside ircd-ircdev/, the directory ircd-ircdev was checked out to.
-
-How to find the most current available release:
-We will announce the most current release tag when we make it available, in general
-you will check out the main branch of any given tree, if you want the current production
-release use the "u2_10_07" tag, for patched versions use a patchlevel tag "u2_10_07_pl6".
-You can always find the most recent tag for any version by looking at the IRC-Dev CVS
-archive: http://cvs.irc-dev.net/viewcvs.py/irc-dev/
+The main trunk of the tree (HEAD) will be used for development only.
+When the maintainers believe the code is stable enough to prepare for
+a release, they will make a branch for that release series.
+
+Each branch will have a base name, which is the name of the release
+series where dots are replaced with underscores. The branch name will
+be the base name with the suffix "_branch". Once an official release
+is made, each release branch will have one or more fixed tags and one
+moving tag. The fixed tags will indicate specific patchlevels, and
+have the base name with a suffix giving the zero-based patchlevel.
+The moving tag's name will be the base name, and will always point to
+the same state as some fixed tag on the branch.
+
+This allows developers to easily track the most recent version of any
+branch (by checking out using the branch's name), and allows server
+admins to easily track the most recent release on the branch (by
+checking out using the branch's base name).
+
+For example, for the ircu2.10.12 release series, the branch's base
+name is u2_10_12. The branch's name is u2_10_12_branch. The first
+release (ircu2.10.12) would be permanently tagged as u2_10_12_0, and
+until an update is released, it would also have the tag u2_10_12.
+When the first update is released, it would be permanently tagged as
+u2_10_12_01, and the tag u2_10_12 would be changed to point to it.
+
+If the current stable series is 2.10.12, server admins should check
+out the code using the command:
+ cvs -d :pserver:ano...@cv...:/cvsroot/undernet-ircu co -r u2_10_12 -P ircu2.10
+Admins may only run unreleased code on Undernet with coder-com
+approval. The command above will retrieve the most recent release.
+
+Developers should check out the release branch using the command:
+ cvs -d :pserver:ano...@cv...:/cvsroot/undernet-ircu co -r u2_10_12_branch -P ircu2.10
+
+http://sourceforge.net/cvs/?group_id=63470 gives more information on
+using CVS to access the ircu code; http://www.nongnu.org/cvs/ gives
+more information on using CVS in general.
+
+NOTE: Release before ircu2.10.12 used a different branching scheme.
+Older revisions of this readme.cvs explain that system.
Index: ircd-ircdev/doc/en/iauth.txt
diff -u ircd-ircdev/doc/en/iauth.txt:1.1 ircd-ircdev/doc/en/iauth.txt:1.2
--- ircd-ircdev/doc/en/iauth.txt:1.1 Wed Jan 5 10:00:34 2005
+++ ircd-ircdev/doc/en/iauth.txt Fri Sep 21 04:30:27 2007
@@ -1,84 +1,434 @@
-$Id: iauth.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+$Id: iauth.txt,v 1.2 2007/09/21 11:30:27 zolty Exp $
OVERVIEW
========
-The IAUTH protocol used here is based on the one in ircd-hybrid 7.0,
-with minor changes to support login-on-connect and true IAUTH-side
-connection classes. (Several networks use central authorities to vary
-per-netblock connection limits; for example, users from one ISP may
-only be allowed one connection per IP, or one shell provider's
-netblock may be limited to 50 total connections.) IAUTH-side
-connection classes are controlled by a configuration option; if that
-is enabled, this document will say ICLASS is enabled.
-
-As in IRC, lines sent between the IRC and IAUTH servers are limited to
-512 characters, including the terminating <CR> <LF> sequence. As in
-IRC, the final argument on a line may be prefixed with :, and must be
-prefixed with : if it contains a space (decimal 32) character. Tokens
-are separated by single space characters, and each line is a separate
-command. The first token on a line is a case-insensitive command
-name; unrecognized commands must be ignored.
+The iauth protocol used here is based on the one in irc2.11.1, with
+minor changes to support challenge-response protocols and
+login-on-connect. Reference to that version's iauth-internals.txt and
+source code may be useful. For clarity, this document uses "server"
+to refer to any IRC server implementing this protocol, "ircu" to refer
+to Undernet ircd, and "ircd" to refer to IRCnet ircd.
+
+Certain messages are relayed to interested operators. ircu implements
+this by using the 131072 (SNO_AUTH) server notice mask. ircd
+implements this by using the &AUTH local channel.
-GREETING
-========
+STARTING IAUTH
+==============
-The IRC server connects and sends the Server greeting:
- Server <servername> [password]
-If ICLASS is enabled, it sends a list of currently connected users:
- MyUsers <uid>:<username>@<hostname>:<ip> ...
-The IRC server may send several MyUsers lines. When it has sent all
-MyUsers lines, it sends an EndUsers line:
- EndUsers
-If ICLASS is disabled, EndUsers is sent immediately after Server.
+The path to the iauth program is specified in the server configuration
+file. The server spawns that program when reading the configuration
+file or when the previous iauth instance terminates. To protect
+against a series of crashes, the server will refuse to restart an
+iauth instance that it spawned in the last five seconds. A rehash
+operation will clear this behavior. The server and iauth instance
+communicate over the iauth instance's stdin and stdout.
+
+Every message from the server to the iauth instance is a single line.
+The line starts with an integer client identifier. This may be -1 to
+indicate no particular client or a non-negative number to indicate a
+client connected to the server.
+
+When the server starts the iauth instance, it sends a line formatted
+like "-1 M irc.example.org 20000" to indicate its name and an
+exclusive upper bound on valid client identifiers. In that example,
+possible client identifiers would be from 0 through 19999 inclusive.
+This upper bound is called MAXCONNECTIONS in the server code.
+
+When the iauth instance starts, it sends a V message to indicate its
+version.
+
+The server should provide /stats subcommands that report the iauth
+instance's version, configuration and statistics.
+
+Line formats in both direction are IRC-like in format: space
+characters separate arguments and a colon at the start of an argument
+indicates that the remainder of the line is one argument. To avoid
+problems, IPv6 address arguments with a leading colon may have to be
+prefixed with a 0 -- for example, ::1 sent as 0::1.
+
+When the iauth instance sends messages that relate to a particular
+client, that client is identified by three parameters from the
+server's Client Introduction message (<id>, <remoteip> and
+<remoteport>). If any of these disagree with the server's current
+user tables, it is an error.
+
+CLIENT STATES
+=============
+
+Each client is conceptually in one of four states: GONE, REGISTER,
+HURRY or NORMAL. Each client starts in the GONE state. Certain
+messages from the server signal a client's transition from one state
+to another, and certain messages from the iauth instance cause a state
+transition.
+
+To be pedantic, the REGISTER state is a collection of sub-states since
+certain commands must occur at most and/or at least one time during
+the REGISTER state. The distinctions between these sub-states are
+distracting and not important, so they are described as one state and
+the repetition limitations are described for each command.
+
+The rationale for the HURRY state is to give explicit input to the
+iauth instance as to when the server believes it has sent the complete
+set of data for the client. Rather than defining the complete set of
+information in this protocol document, that is left to the server.
+ircd does not indicate this state.
+
+POLICIES AND USE CASES
+======================
+
+The historical application of iauth has been to block users that
+appear to be drones early, before they have a chance to disrupt the
+network, and without affecting other users on the same host (which
+K-lines do). This protocol extends that application by adding the n
+server message and by allowing challenge-response exchanges with the
+client.
+
+Eventually it would be nice to move the DNS and ident lookups into
+iauth, and remove that code from the IRC server. ircd already does
+this; since ircu does not, it adds the u server message.
+
+For trusted proxies, this protocol gives the capability for clients
+connecting through those proxies to be displayed with their actual
+username, IP address and hostname. The same functions allow other
+clients to use iauth-assigned spoofs, for example to hide the IP
+addresses used by operators.
+
+This protocol allows login-on-connect, for example by clients that
+send their account name and password in PASS, through the R iauth
+message.
+
+This protocol allows iauth to assign a client to a particular class by
+specifying a class name in the D or R iauth message.
+
+SERVER MESSAGES
+===============
+
+X - Example Message Description
+Syntax: <id> X <several> <arguments>
+Example: 5 X arguments vary
+States: REGISTER(1), HURRY, NORMAL
+Next State: -
+Comments: This is an example message description. Each message is a
+ single character. The States field indicates which states the
+ message may occur in and any restrictions on how many times the
+ message may be sent during those states (restrictions only make
+ sense when Next State is -). The Next State field indicates which
+ new state is implied by the message; a hyphen indicates no state
+ change is implied. The X (Example) message is not a real message
+ type.
+Compatibility: If we believe ircu behavior is different than ircd's,
+ this describes ircd's behavior or expectations.
+
+C - Client Introduction
+Syntax: <id> C <remoteip> <remoteport> <localip> <localport>
+Example: 5 C 192.168.1.10 23367 192.168.0.1 6667
+States: GONE
+Next State: REGISTER
+Comments: Indicates that <localport> on <localip> accepted a client
+ connection from <remoteport> on <remoteip>.
+
+D - Client Disconnect
+Syntax: <id> D
+Example: 5 D
+States: REGISTER, HURRY, NORMAL
+Next State: GONE
+Comments: Indicates that a client is disconnecting from the server.
+
+N - Hostname Received
+Syntax: <id> N <hostname>
+Example: 5 N host-1-10.example.org
+States: REGISTER(1)
+Next State: -
+Comments: Indicates that the server received hostname information for
+ a client. Only one of 'N' and 'd' is sent.
+
+d - Hostname Timeout
+Syntax: <id> d
+Example: 5 d
+States: REGISTER(1)
+Next State: -
+Comments: Indicates that the server did not receive hostname
+ information for a client in a timely fashion. Only one of 'N' and
+ 'd' is sent.
+
+P - Client Password
+Syntax: <id> P :<password ...>
+Example: 5 P :buddha n1rvan4
+States: REGISTER
+Next State: -
+Comments: Indicates the client's password information. This may be a
+ traditional client password, an account and pass phrase pair, or the
+ response to a challenge (see the iauth C message). This message is
+ enabled by requesting the A policy.
+
+U - Client Username
+Syntax: <id> U <username> <hostname> <servername> :<userinfo ...>
+Example: 5 U buddha bodhisattva.example.com irc.undernet.org :Gautama Siddhartha
+States: REGISTER(1+)
+Next State: -
+Comments: Indicates the client's claimed username and "GECOS"
+ information, along with client hostname and server name. This
+ information is not reliable. This message is enabled by requesting
+ the A policy.
+Compatibility: ircd only sends the <username> parameter.
+
+u - Client Username
+Syntax: <id> u <username>
+Example: 5 u notbuddha
+States: REGISTER(1)
+Next State: -
+Comments: Indicates a more reliable username for the client.
+Compatibility: This is an Undernet extension and ircd does not send
+ it. It is enabled by the iauth instance requesting the U policy.
+
+n - Client Nickname
+Syntax: <id> n <nickname>
+Example: 5 n Buddha
+States: REGISTER(1+), HURRY
+Next State: -
+Comments: Indicates the client's requested nickname.
+Compatibility: This is an Undernet extension and ircd does not send
+ it. It is enabled by the iauth instance requesting the U policy.
+
+H - Hurry Up
+Syntax: <id> H <class>
+Example: 5 H Others
+States: REGISTER
+Next State: HURRY
+Comments: Indicates that the server is ready to register the client
+ except for needing a response from the iauth server. <class> is
+ a tentative connection class for the user, which will be used unless
+ iauth overrides it in a D or R message.
+Compatibility: This is an Undernet extension and ircd does not send
+ it. It is enabled by the iauth instance requesting the U policy.
+
+T - Client Registered
+Syntax: <id> T
+Example: 5 T
+States: HURRY
+Next State: NORMAL
+Comments: Indicates the server got tired of waiting for iauth to
+ finish and the client is being accepted. This message should
+ never be sent when the R policy is in effect.
+Compatibility: ircd allows this message for clients in the REGISTER
+ state.
+
+E - Error
+Syntax: <id> E <type> :<additional text>
+Example: 5 E Gone
+States: N/A
+Next State: -
+Comments: Indicates that a message received from the iauth instance
+ could not be rationally interpreted. This may be because the client
+ could not be found, the client was in an inappropriate state for the
+ message, or for other reasons. The <type> argument specifies the
+ general type of error and <additional text> provides details. <id>
+ may be -1.
+
+M - Server Name and Capacity
+Syntax: <id> M <servername> <capacity>
+Example: -1 M irc.example.org 20000
+States: GONE(1)
+Next State: -
+Comments: Indicates the server's name and upper bound on client
+ identifiers.
+Compatibility: ircd does not include the <capacity> information.
+ The <id> should be ignored: ircd sends 0 and ircu sends -1.
-LOGIN REQUESTS
+IAUTH MESSAGES
==============
-When users connect, the IRC server sends a DoAuth request:
- FullAuth <uid> <nickname> <username> <hostname> <ip> <account> <password> <realname>
-<uid> is a text string up to 20 characters long that identifies the
-client, and is unique a BadAuth response is received or until an
-ExitUser command is sent with the same uid (see below for details on
-those messages). <uid> may not contain a colon character. <nickname>
-is the client's initially requested nickname. <username> is the
-username returned by the ident server (RFC 1413), or a tilde-prefixed
-username supplied by the user. <hostname> is a text hostname,
-possibly in the form of a dotted quad or IPv6 address, or the
-character '?'. <ip> is a dotted quad IPv4 address or an IPv6 hex
-address. <account> and <password> are optional, and are used when the
-client attempts login-on-connect. <realname> is the realname
-specified by the client's USER message, and may contain spaces.
-
-If the client is accepted, the IAUTH server responds:
- DoneAuth <uid> <username> <hostname> <class> [account]
-<username> is a replacement username, and <hostname> is a replacement
-hostname. If the <hostname> from DoAuth was ?, <hostname> is the
-result of a DNS lookup for the client. <class> is the name of a
-connection class for the client. <account> is optional and is
-provided if the user's login was successful.
-
-If the client is rejected, the IAUTH server responds:
- BadAuth <uid> :<reason>
-<reason> may include spaces, and should have a leading ':' sentinel.
-
-DISCONNECTS
-===========
-
-If ICLASS is enabled, the IRC server sends ExitUser when a client
-disconnects:
- ExitUser <uid>
-
-DIFFERENCES FROM IRCD-HYBRID
-============================
-
-The ircd-hybrid IAUTH code is slightly bitrotted and disabled in 7.0
-(through at least 7.0.1). This code added the following items:
- MyUsers, EndUsers and ExitUser commands
- Server passwords may contain whitespace and be prefixed by :
- DoneAuth may include an account name
- FullAuth command replaces DoAuth command and adds account, password,
- realname parameters
-The Class command is present in ircd-hybrid's code but not used here.
-IP addresses in ircd-hybrid are "in unsigned int format," which is
-limited to IPv4, and so it is not used here.
+X - Example Message Description
+Syntax: X <arguments>
+Example: X something
+Notify: yes
+States: N/A
+Next State: N/A
+Comments: This is an example message description. Each message is a
+ single character. If the Notify field is present and says yes,
+ interested operators (with SNO_AUTH set) should be notified of the
+ message. The States field, where present, indicate which states
+ accept this message. Clients in other states should ignore the
+ message or treat it as an error. The Next State field, where
+ present, indicates what the next state should be for the client.
+Compatibility: If we believe ircu behavior is different than ircd's,
+ this describes ircd's behavior or expectations.
+
+> - Operator Notification
+Syntax: > :<message text>
+Example: > :Hello Operators!
+Notify: yes
+Comments: Contains a message that the iauth instance wants to send to
+ interested operators.
+
+G - Set Debug Level
+Syntax: G <level>
+Example: G 1
+Notify: yes
+Comments: Sets a debug level for the server's end of the iauth
+ conversation. When enabled, debug messages should be sent to the
+ same channel (group, mask, etc) as other iauth notifications.
+ Debug level 0 suppresses iauth-related debug output, and positive
+ integers enable iauth debugging messages.
+
+O - Set Policy Options
+Syntax: O <options>
+Example: O RTAWU
+Notify: yes
+Comments: Sets policy options for the iauth conversation. Old policy
+ options should be forgotten. Valid policy options are:
+ A - Send username and password information.
+ This causes the server to send the U and P messages.
+ R - Require clients to be approved before registering them.
+ When this policy is in effect, it affects the behavior
+ of a registration timeout; for details, see the documentation
+ for the T server message.
+ T - When the R policy is in effect and the iauth service does not
+ respond for a client, this causes the server to count the number
+ of clients refused, to send a warning message to interested
+ operators periodically, and to send the count of rejected users
+ to interested operators when the iauth instance responds again.
+ U - Send nickname, confirmed username and hurry information.
+ This causes the server to send the n, u and H messages.
+ W - Allow extra time for iauth to respond based on hostname.
+ When this policy is in effect and a DNS message (N or d) is
+ sent for a client, that client's registration timeout is
+ extended or reset.
+Compatibility: The U policy is an Undernet extension and is not
+ recognized by ircd.
+
+V - iauth Program Version
+Syntax: V :<version string>
+Example: V :Undernet-iauthu v1.0
+Notify: yes
+Comments: Indicates the iauth program version. This should only be
+ used in diagnostic messages, and must not change protocol behavior.
+
+a - Start of new configuration
+Syntax: a
+Example: a
+Notify: yes
+Comments: Indicates that a new configuration is being loaded by the
+ iauth instance. Any cached configuration records should be cleared.
+
+A - Configuration Information
+Syntax: A <hosts?> <module> :<options>
+Example: A * rfc931
+Notify: yes
+Comments: Indicates new configuration information.
+
+s - Start of new statistics
+Syntax: s
+Example: s
+Notify: yes
+Comments: Indicates a new set of statistics will be sent. Any cached
+ statistics records should be cleared.
+
+S - Statistics Information
+Syntax: S <module> :<module information>
+Example: S rfc931 connected 0 unix 0 other 0 bad 0 out of 0
+Notify: yes
+Comments: Indicates new or additional statistics information.
+
+o - Forced Username
+Syntax: o <id> <remoteip> <remoteport> <username>
+Example: o 5 192.168.1.10 23367 bubba
+States: REGISTER, HURRY
+Next State: -
+Comments: Indicates that the username should be used for the specified
+ client even if the normal sanity-checking would prohibit the
+ username.
+
+U - Trusted Username
+Syntax: U <id> <remoteip> <remoteport> <username>
+Example: U 5 192.168.1.10 23367 buddha
+States: REGISTER, HURRY
+Next State: -
+Comments: Indicates that the iauth instance believes <username> is
+ accurate for the specified client.
+
+u - Untrusted Username
+Syntax: u <id> <remoteip> <remoteport> <username>
+Example: u 5 192.168.1.10 23367 enlightened_one
+States: REGISTER, HURRY
+Next State: -
+Comments: Indicates that the iauth instance does not strongly trust
+ <username> to be accurate, but has no more trusted username.
+
+N - Client Hostname
+Syntax: N <id> <remoteip> <remoteport> <hostname>
+Example: N 5 192.168.1.10 23367 buddha.example.org
+States: REGISTER, HURRY
+Next State: -
+Comments: Indicates that the iauth instance believes the specified
+ client should use the hostname given.
+Compatibility: This is an Undernet extension and ircd does not support
+ this message.
+
+I - Client IP Address
+Syntax: N <id> <currentip> <remoteport> <newip>
+Example: N 5 192.168.1.10 23367 127.128.129.130
+States: REGISTER, HURRY
+Next State: -
+Comments: Indicates that the iauth instance wants the server to
+ present and treat the client as using <newip>. This means that
+ future iauth messages relating to the client must use <newip>
+ as the <remoteip> parameter.
+Compatibility: This is an Undernet extension and ircd does not support
+ this message.
+
+C - Challenge User
+Syntax: C <id> <remoteip> <remoteport> :<challenge string>
+Example: C 5 192.168.1.10 23367 :In which year did Columbus sail the ocean blue?
+States: REGISTER, HURRY
+Next State: -
+Comments: Indicates that the challenge string should be sent to the
+ specified user, for example via NOTICE AUTH :*** <challenge string>.
+ The client responds by sending PASS :<response>, which should be
+ relayed via the P server message. This requires that the A policy
+ be in effect.
+Compatibility: This is an Undernet extension and ircd does not support
+ this message.
+
+k - Quietly Kill Client
+Syntax: k <id> <remoteip> <remoteport> :<reason>
+Example: k 5 192.168.1.10 23367 :Open proxy found.
+States: REGISTER, HURRY, NORMAL
+Next State: GONE
+Comments: Indicates that the specified client should be disconnected
+ for the reason given without notifying operators.
+Compatibility: ircu does not use the same notification mechanism as
+ ircd, so operators are notified using SNO_CONNEXIT anyway.
+
+K - Kill Client
+Syntax: K <id> <remoteip> <remoteport> :<reason>
+Example: K 5 192.168.1.10 23367 :We don't like you.
+States: REGISTER, HURRY, NORMAL
+Next State: GONE
+Comments: Indicates that the specified client should be disconnected
+ for the reason given. Operators should be notified.
+
+D - Done Checking
+Syntax: D <id> <remoteip> <remoteport> [class]
+Example: D 5 192.168.1.10 23367
+States: REGISTER, HURRY
+Next State: NORMAL
+Comments: Indicates that the iauth instance believes the specified
+ client should be allowed onto the network. If a class parameter is
+ given, the client should be assigned to that class.
+Compatibility: Specifying the class is an Undernet extension and ircd
+ does not support that parameter.
+
+R - Registered User
+Syntax: R <id> <remoteip> <remoteport> <account> [class]
+Example: R 5 192.168.1.10 23367 Buddha
+States: REGISTER, HURRY
+Next State: NORMAL
+Comments: Indicates that the iauth instance believes the specified
+ client should be allowed onto the network, pre-authenticated to
+ the account listed. If a class parameter is given, the client
+ should be assigned to that class.
+Compatibility: This is an Undernet extension and ircd does not support
+ this message.
Index: ircd-ircdev/doc/en/who.txt
diff -u ircd-ircdev/doc/en/who.txt:1.1 ircd-ircdev/doc/en/who.txt:1.2
--- ircd-ircdev/doc/en/who.txt:1.1 Wed Jan 5 10:00:34 2005
+++ ircd-ircdev/doc/en/who.txt Fri Sep 21 04:30:27 2007
@@ -1,4 +1,4 @@
-$Id: who.txt,v 1.1 2005/01/05 18:00:34 zolty Exp $
+$Id: who.txt,v 1.2 2007/09/21 11:30:27 zolty Exp $
WHO documentation, updated on 02 Jan 1999.
@@ -43,7 +43,7 @@
For both the masks and the options (and thus for all flags) case is NOT
significative (so "/who <any> o" is exactly the same as "/who <ANY> O".
-The "options2" part can be as follows:
+The "options" part can be as follows:
[<flags>][%[<fields>[,<querytype>]]]
@@ -101,6 +101,7 @@
t : Include the querytype in the reply
u : Include userID with eventual ~
a : Include account name
+ o : Include oplevel (shows 999 to users without ops in the channel)
And the ,<querytype> final option can be used to specify what you want the
server to say in the querytype field of the output, useful to filter the
----------------------- End of diff -----------------------
|
