LizardIRC Network Staff Guide
LizardIRC Network Staff Guide
This page documents the capabilities of LizardIRC network staff, as well as procedures that should be followed by staff in the course of their official network duties. Though the primary audience of this page is the LizardIRC network staff, the contents of this page are by no means secret. In the interests of transparency, the contents of this document are public. Readers of this page should be familiar with the general IRC help guide in its entirety. |
Contents
- 1 Network operator classes/types
- 2 What staff CANNOT do
- 3 Oper Override
- 4 Staff Round Robin
- 5 Staff Wiki
- 6 Network management commands
- 6.1 USERIP
- 6.2 TLINE ("test line")
- 6.3 LOCKSERV
- 6.4 UNLOCKSERV
- 6.5 JUMPSERVER
- 6.6 FILTER (regex-based global spam filter)
- 6.7 OJOIN ("Official Join")
- 6.8 CLONES
- 6.9 CHECK
- 6.10 ALLTIME
- 6.11 RCONNECT ("Remote Connect")
- 6.12 RSQUIT ("Remote Server Quit")
- 6.13 GLOBOPS
- 6.14 CBAN
- 6.15 SAJOIN
- 6.16 SAPART
- 6.17 SAMODE
- 6.18 SANICK
- 6.19 SAKICK
- 6.20 SATOPIC
- 6.21 SAQUIT
- 6.22 SETIDLE
- 6.23 SETHOST
- 6.24 SETIDENT
- 6.25 SWHOIS
- 6.26 NICKLOCK
- 6.27 NICKUNLOCK
- 6.28 CHGHOST
- 6.29 CHGNAME
- 6.30 CHGIDENT
- 6.31 SHUN
- 6.32 DIE
- 6.33 RESTART
- 6.34 KILL
- 6.35 REHASH
- 6.36 CONNECT
- 6.37 SQUIT
- 6.38 KLINE
- 6.39 ZLINE
- 6.40 QLINE
- 6.41 GLINE
- 6.42 ELINE
- 6.43 WALLOPS
- 6.44 RLINE
- 6.45 CLEARCACHE
- 6.46 CLOSE
- 6.47 ALINE
- 6.48 GALINE
- 7 Services management commands
- 7.1 OperServ GLOBAL
- 7.2 InfoServ POST
- 7.3 InfoServ DEL
- 7.4 OperServ AKILL
- 7.5 OperServ RMATCH
- 7.6 ChanServ CLOSE
- 7.7 OperServ CLEARCHAN
- 7.8 OperServ KLINECHAN
- 7.9 NickServ HOLD
- 7.10 ChanServ HOLD
- 7.11 NickServ VHOST
- 7.12 HostServ WAITING
- 7.13 HostServ ACTIVATE
- 7.14 HostServ REJECT
- 7.15 ChanServ FTRANSFER
- 7.16 ChanServ FFLAGS
- 7.17 ChanServ FDROP
- 7.18 NickServ FDROP
- 7.19 NickServ FUNGROUP
- 7.20 NickServ FREEZE
- 7.21 NickServ RESTRICT
- 7.22 NickServ FENFORCE
- 7.23 * MARK
- 7.24 NickServ SENDPASS
- 7.25 OperServ OVERRIDE
- 7.26 OperServ IGNORE
- 7.27 OperServ RWATCH
- 7.28 OperServ COMPARE
- 7.29 OperServ JUPE
- 7.30 OperServ NOOP
- 7.31 OperServ UPTIME
- 7.32 ChanFix CHANFIX
- 7.33 ChanFix LIST
- 7.34 ChanFix INFO
- 7.35 ChanFix SCORES
- 8 NetOpsBot commands
- 9 Procedures
Network operator classes/types[edit | edit source]
There are several classes of network operator that network staff can belong to. The five general categories are (from least privileged to most privileged):
- Lord
- Able to act as "global channel operators" - that is, through use of Oper Override, Lord-class staff can act as channel operators in any channel on the network.
- Able to join staff-only channels.
- Able to set staff-only usermodes and channel modes, with the exception of channel mode
+P
(permanent channel). - Able to send network-wide announcements (WALLOPS and OperServ global messages).
- Able to use the
/ojoin
command to join channels on official network business.
- RingLord
- All capabilities of the Lord class, plus:
- Able to issue global network bans (K-lines, G-lines, Z-lines, A-lines, Q-lines, channel bans (
/cban
),/shun
, etc.). - Able to issue user manipulation commands (the
/sa*
commands). - Able to set channel mode
+P
(permanent channel). - Can see extra details about users, servers, and channels (for example, can view a list of secret/private channels a user is in, and can see channels an invisible [usermode
+i
] user is in without being in those channels). - Can be in more channels at any given time than normal users (though this is a very high limit, even for normal users).
- SithLord
- All capabilities of the Lord and RingLord classes, plus:
- Can control server linkages (i.e., manually split and rejoin servers).
- TimeLord
- All capabilities possible (akin to root permissions). Functionally, there are not many differences between TimeLords and SithLords; two notable capabilities TimeLords have that SithLords don't is the ability to shutdown servers and reload their configuration files.
There are two more classes of network operator, but these are generally only assigned to bots (automated programs that interface with the network as if they were clients):
- FloodExemptBots
- No capabilities except being able to send lots of text without being automatically fakelagged or disconnected from the server.
- Network Operations Bot
- Functionally similar to SithLord, but only assigned to bots.
- Able to send lots of text without being automatically fakelagged or disconnected from the server.
Finally, independent of network operator class, there are two IRC services operator classes, which control permissions individual staffers receive with things like NickServ, ChanServ, and OperServ:
- ircop
- most human staffers have this level
- sra
- Services Administrator, generally only assigned to TimeLord-class staff; grants extra privileges that most staff don't need
Note that the descriptions of the permissions assigned to each class are general; individual items (commands, procedures, etc.) discussed below will indicate the minimum privileges required to perform the item.
What staff CANNOT do[edit | edit source]
There are some things that staff cannot do. For example, staff cannot read messages in channels they are not in, and they cannot join channels silently. That is, any time a staffer joins a channel, a join message will always be sent.
Staff also cannot do things like intercept private messages or view your NickServ passwords.
The role of staff on LizardIRC is to be helpful, not invasive. Beyond the normal management of the network and enforcing the global network rules, staff are here to, for example, help channel operators deal with a spammer, as needed.
Oper Override[edit | edit source]
Oper Override is a basic system that allows all Lord-class and higher network staff to be able to perform channel operator commands in any channel, regardless of whether or not they are channel operators in that channel.
To use oper override, simply issue channel operator commands as you would normally. Oper override works automatically, and kicks in when you use a privileged command in a channel that you don't have the permissions for normally (note that previously, oper override might fail to work if you had any flags at all in the channel; this has been fixed).
Note that there is one special usage of oper override, oper override join. If you are banned from a channel, or the channel has a restrictive mode set (e.g., channel modes +i
, +l
, or +k
), you can join the channel with the key "override" (e.g., /join #someChannel override
) to bypass bans/restrictions and join the channel anyway. Note that the server will notify all users in the channel that you used oper override to join the channel, in a fashion similar to OJOIN. Also note that unlike OJOIN, joining using oper override won't make you unkickable (by setting +Y
on you), so consider using OJOIN instead of oper override join if this is a concern.
Staff Round Robin[edit | edit source]
Per the LizardIRC server linking policy, a server donated/controlled by someone who isn't LizardIRC network staff has o-lines completely disabled on it. To this end, a special round robin, staff.lizardirc.org
, exists as a subset of LizardIRC servers on which staff will be able to regularly oper up on (by extension, these servers are those controlled by LizardIRC network staff). For convenience, staff are advised to use this round robin instead of the standard IRC round robin for connections on which they oper up.
Staff Wiki[edit | edit source]
A private LizardIRC staff-only wiki is maintained at https://staffwiki.lizardirc.org. Staff should feel free to use that wiki for documenting anything they think should be preserved there for long-term storage, or for discussions that should be preserved in wiki-form instead of being carried out in #operchat.
In addition, please document problem users and network bans you set in the appropriate places on the wiki.
Network management commands[edit | edit source]
This section will explain various aspects of network management from the perspective of the commands used. For each command, usage instructions and usage scenarios will be provided. The Procedures section explains aspects of network management from the perspective of what needs to be accomplished.
Notes:
All of these commands are server-side commands. They may be passed to the server automatically by your IRC client, or your IRC client may complain that the command is unknown. Your IRC client may even (rarely) provide its own version of some of these commands. To ensure that you are using the correct form of the commands, as described here, you may need to prefix the command with /quote
or /raw
- for example, instead of /kline
, you may have to do /quote kline
, etc.
For all commands, required arguments are in italics. Optional arguments are [bracketed and in italics] (don't include the brackets when giving the arguments!).
Finally, note that all commands that require a duration will usually accept 0
as a duration, meaning indefinite.
USERIP[edit | edit source]
Usage: /userip nick [nick] [nick] [...]
Required operator class: RingLord
Returns the ip and nickname of the given users.
TLINE ("test line")[edit | edit source]
Usage: /tline host/IP mask
Required operator class: RingLord
This command returns the number of local and global clients matched, and the percentage of clients matched, plus how they were matched (by IP address or by hostname).
Useful for determining if the K/G/Z/A-line you are thinking about setting will cause any collateral damage.
LOCKSERV[edit | edit source]
Usage: /lockserv
Required operator class: SithLord
Locks out all new connections notifying connecting users that the service is temporarily closed and to try again later. Will act on the server you are currently connected to; there is no way to manually specify a different server to act on.
Use of this command is not recommended unless absolutely necessary.
See also: UNLOCKSERV, JUMPSERVER.
UNLOCKSERV[edit | edit source]
Usage: /unlockserv
Required operator class: SithLord
Opens the server up again for new connections. Will act on the server you are currently connected to; there is no way to manually specify a different server to act on.
Use of this command is not recommended unless absolutely necessary.
See also: LOCKSERV, JUMPSERVER.
JUMPSERVER[edit | edit source]
Usage: /jumpserver [<newserver> <newport> (+|-)flags :[reason]]
Required operator class: SithLord
Sets or cancels jumpserver mode. If no parameters are given, jumpserver mode is cancelled, if it is currently set. If parameters are given, a server address must be given for newserver and a server port must be given for newport. Zero or more status flags should be given for flags, from the list below (if you do not wish to specify any flags just place a +
in this field):
+a
: Redirect all users immediately (except for opers) and cause them to quit with the given reason+n
: Redirect any new users who connect and cause them to quit during registration
You may use + and - to set or unset these flags in the command, the default flags are -a+n
, which will just redirect new users. The reason parameter is optional, and if not provided defaults to "Please use this server/port instead" (the default given in various numeric lists)
Use of this command is not recommended unless absolutely necessary.
See also: LOCKSERV, UNLOCKSERV.
FILTER (regex-based global spam filter)[edit | edit source]
Usage: /filter filter-definition [action flags gline-duration :reason]
Required operator class: RingLord
This command will add a filter when more than one parameter is given, for messages of the types specified by the flags, with the given filter definition, action, gline duration (when the action is 'gline') and reason.
The filter-definition is in the form of a PCRE (Perl-compatible regular expression). Do not include the delimiters. If you need to make the regex case-insensitive, prefix it with (?i)
. Remember not to include spaces in the regex; you can instead use the \s
keyword to stand for whitespace.
The filter will take effect when a message of any type specified by the flags and matching the definition is sent to the server, and perform the specified action.
- Valid FILTER Actions
none
- Does nothing
block
- Blocks message and informs staff of the blocked message and all relevant info (in #opers)
silent
- Blocks message, but does not notify staff
kill
- Kills the user
gline
- Glines the user for the specified duration (the gline-duration parameter is only needed if specifying
gline
for action)
- Glines the user for the specified duration (the gline-duration parameter is only needed if specifying
- Valid FILTER Flags
p
- Block private and channel messages
n
- Block private and channel notices
P
- Block part messages
q
- Block quit messages
o
- Don't match against staff
c
- Strip all color codes from the message before matching
*
- Represents all of the above flags
-
- Does nothing, a non-op for when you do not want to specify any flags
The reason for the filter will be used as the reason for the action, unless the action is 'none', and is sent to the user when their text is blocked by 'block' and 'silent' actions.
A gline duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
When only one parameter is provided (the filter pattern) the provided filter will be removed. Note that if you remove a configuration-defined filter, it will reappear at next rehash unless it is also removed from the config file.
To view the list of active FILTERs, use the command /stats s
.
See also: RLINE.
OJOIN ("Official Join")[edit | edit source]
Usage: /ojoin #channel
Required operator class: Lord
Force joins you to the specified channel (bypassing any bans, channel modes +i
, +l
, or +k
, etc.), and gives you +Y
, preventing you from being kicked. The server will announce to all in the given channel that you have joined on official network business.
Useful when joining a channel on network business, and when you need to make clear to a channel's users that you are joining in your official capacity as network staff. Useful as a "louder" version of oper override join.
CLONES[edit | edit source]
Usage: /clones limit
Required operator class: RingLord
Retrieves a list of users with more clones than the specified limit.
CHECK[edit | edit source]
Usage: /check nick|ip|hostmask|channel [server]
Required operator class: RingLord
Allows staff to look up advanced information on channels, hostmasks or IP addresses, in a similar way to /who
but in more detail, displaying most information the IRC server has stored on the target, including all metadata.
With the second parameter given, runs the command remotely on the specified server (specify the server's full hostname, e.g., phazon.lizardirc.org
).
ALLTIME[edit | edit source]
Usage: /alltime
Required operator class: SithLord
Shows the time on all servers on the network.
RCONNECT ("Remote Connect")[edit | edit source]
Usage: /rconnect source-mask target-mask
Required operator class: SithLord
The server matching source-mask will try to connect to the first server in the config file matching target-mask. For relinking two remote servers.
See also: RSQUIT, CONNECT, SQUIT.
RSQUIT ("Remote Server Quit")[edit | edit source]
Usage: /rsquit target-mask [reason]
Required operator class: SithLord
Causes a remote server matching target-mask to be disconnected from the network. For delinking a server that is not connected to the server you are currently connected to.
See also: RCONNECT, CONNECT, SQUIT.
GLOBOPS[edit | edit source]
Deprecated command, do not use.
Usage: /globops message
Required operator class: Lord
Sends a message to all users with the +g snomask. Which is probably no one. Simply talk in #operchat (preferably) or #opers.
CBAN[edit | edit source]
Usage: /cban #channel [duration [:reason]]
Required operator class: RingLord
Sets or removes a channel ban. You must specify two or three parameters to add a ban, and one parameter to remove a ban (just the channel). The reason is optional, and if not supplied, will be "No reason given".
A banned channel will be unavailable for users to join (anyone who tries will receive a message explaining that the channel is banned from existing, along with the reason). If the channel is in use at the time of the CBAN, none of the users in the channel at the time of the CBAN will be affected - they will need to be manually removed. Any user attempting to join a CBAN'd channel will trigger a staff notification in #opers.
When CBAN'ing a registered channel, you should also set ChanServ CLOSE on the channel in addition to the CBAN.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active CBANs, use the command /stats C
.
See also: OperServ CLEARCHAN, OperServ KLINECHAN, ChanServ CLOSE.
SAJOIN[edit | edit source]
Usage: /sajoin nick #channel
Required operator class: RingLord
Forces the user to join the channel, bypassing bans and other restrictive channel modes.
Note that unlike oper override join and OJOIN, this command does not notify the users in a channel about its usage. Do not use it for official network business.
See also: OJOIN.
SAPART[edit | edit source]
Usage: /sapart nick channel [message]
Required operator class: RingLord
Forces the user to part the channel, optionally with part message message.
SAMODE[edit | edit source]
Usage: /samode target (+|-)modes [parameters]
Required operator class: RingLord
Applies the given mode change to the channel or nick specified. Note that this command can also be used to force user mode changes. Please do not abuse it.
SANICK[edit | edit source]
Usage: /sanick nick new-nick
Required operator class: RingLord
Force changes the user's nick to the new nick.
See also: NICKLOCK, NICKUNLOCK.
SAKICK[edit | edit source]
Usage: /sakick #channel nick reason
Required operator class: RingLord
Force-kicks the given user from the specified channel with the specified reason.
SATOPIC[edit | edit source]
Usage: /satopic channel [new topic]
Required operator class: RingLord
Force applies the given topic to the specified channel. Clears the topic if new topic is not given.
SAQUIT[edit | edit source]
Usage: /saquit target message
Required operator class: RingLord
Force quits the target user from the network, with message message.
SETIDLE[edit | edit source]
Usage: /setidle idletime
Required operator class: Lord
Sets your idle time (in seconds) to the specified value. Note that settings this to very high values can cause IRC clients to crash; use wisely!
SETHOST[edit | edit source]
Usage: /sethost hostname
Required operator class: Lord
Sets your host to the specified host.
See also: CHGHOST.
SETIDENT[edit | edit source]
Usage: /setident ident
Required operator class: Lord
Sets your ident to the specified ident.
See also: CHGIDENT.
SWHOIS[edit | edit source]
Usage: /swhois nick swhois
Required operator class: SithLord
Sets the user's swhois field (an extra line in the normal /whois
output) to the given swhois. Lost when the user disconnects.
NICKLOCK[edit | edit source]
Usage: /nicklock nick new-nick
Required operator class: RingLord
Changes the user's nick to the new nick, and forces it to remain as such for the remainder of the session (until they disconnect).
nick can be set the same as new-nick to lock a user to their current nickname.
See also: SANICK, NICKUNLOCK.
NICKUNLOCK[edit | edit source]
Usage: /nickunlock nick
Required operator class: RingLord
Allows a previously locked user to change nicks again.
CHGHOST[edit | edit source]
Usage: /chghost nickname hostname
Required operator class: Lord
Changes the hostname of the user to the new hostname.
See also: SETHOST.
CHGNAME[edit | edit source]
Usage: /chgname nickname realname
Required operator class: Lord
Changes the realname (gecos) of the user to the new realname.
CHGIDENT[edit | edit source]
Usage: /chgident
nickname ident
Required operator class: Lord
Changes the ident of the user to the new ident.
See also: SETIDENT.
SHUN[edit | edit source]
Usage: /shun nick!user@host [duration :reason]
Required operator class: RingLord
Sets or removes a shun (server side global quiet) on a host and ident mask. You must specify all three parameters to add a shun, and one parameter to remove a shun (just the nick!user@host argument).
Shuns are essentially server-side quiets. Shunned users will be unable to speak in or take most actions in a channel, and they will be unable to send private messages; they will still be able to join channels and connect to the network, though (part and quit messages will be suppressed). Shuns act like G-lines and apply to all servers on the network.
Users will never be automatically informed that they are shunned, either at the time the shun is set or when they attempt to speak; in this way, shuns are somewhat analogous to shadowbans on Reddit. Because of this, shuns should only be used in exceptional cases, and if used, the staffer setting the shun should consider PMing the user to inform them of the shun and the reason. Note that, despite this, it is fairly trivial for a user to determine if they are shunned, as a shun will - for example - prevent bots from responding to commands.
The specific commands that are still allowed from a shunned user are: PING, PONG, QUIT, PART, JOIN, NICK, MODE, USER, CAP, NS, AUTHENTICATE, and PASS. All others will be silently ignored.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active shuns, use the command /stats H
.
See also: OperServ IGNORE.
DIE[edit | edit source]
Usage: /die password
Required operator class: TimeLord
This command shuts down the local server. A single parameter is required, which must match the password in the configuration for the command to function.
RESTART[edit | edit source]
Usage: /restart password
Required operator class: TimeLord
This command restarts the local server. A single parameter is required, which must match the password in the configuration for the command to function.
KILL[edit | edit source]
Usage: /kill nick reason
Required operator class: RingLord
This command will disconnect a user from IRC with the given reason. The reason will be shown to the disconnected user (and all other users), and will include your nickname.
Note that nothing prevents a user from (automatically) reconnecting after they are KILLed.
REHASH[edit | edit source]
Usage: /rehash [mask]
Required operator class: TimeLord
This command will cause the server configuration file to be reread and values reinitialized for all servers matching the server mask, or the local server if one is not specified.
CONNECT[edit | edit source]
Usage: /connect servermask
Required operator class: SithLord
Add a connection to the server matching the given server mask. You must have configured the server for linking in your configuration file before trying to link them. Note that this command is only for linking a server to the server you are currently connected to.
Not to be confused with the /connect
command provided by most IRC clients. Remember to use /quote
or /raw
as appropriate with this command!
See also: RCONNECT, RSQUIT, SQUIT.
SQUIT[edit | edit source]
Usage: /squit servermask
Required operator class: SithLord
Disconnects the server matching the given server mask from this server. Note that this command is only for delinking a server from the server you are currently connected to.
See also: RCONNECT, RSQUIT, CONNECT.
KLINE[edit | edit source]
Usage: /kline user@host [duration :reason]
Required operator class: RingLord
Sets or removes a k-line (local host based ban) on a host and ident mask. You must specify all three parameters to add a ban, and one parameter to remove a ban (just the user@host argument).
The host part can be a hostname with the normal IRC wildcards (*
and ?
), or it can be an IPv4 or IPv6 address. If an IP address is used, a range can be specified either by using the standard IRC wildcards, or by using CIDR notation. If an IP address (or range) is used, it will act on users connecting from the affected address(es), regardless of their displayed hostnames/cloaks.
K-lines only take effect on the server you are currently connected to. To set a "global K-line", use a G-line. K-lines are not very useful because of this, so almost always you'll want to use a G-line instead.
When a K-line is set, currently connected affected users will be immediately disconnected with a quiet message (visible to all users) "K-lined:" followed by the reason you give when issuing the K-line. The banned user will also see the same, along with a message advising them to email LizardIRC staff if they would like an unban. Users trying to connect to the network will be rejected from connecting after they attempt registration, with the same messages given to them (the reason and the email address). Note that the duration is never revealed to anyone except other network staff, and that as mentioned above, K-lines can be bypassed simply by connecting to a different server of the network!
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active KLINEs, use the command /stats k
. If you want to get the list of active KLINEs for a server other than the one you are currently connected to, add the server name as the second parameter - e.g., /stats k phazon.lizardirc.org
.
See also: GLINE, ZLINE, RLINE.
ZLINE[edit | edit source]
Usage: /zline ipmask [duration :reason]
Required operator class: RingLord
Sets or removes a z-line (ip based ban) on an ip range mask. You must specify all three parameters to add a ban, and one parameter to remove a ban (just the ipmask).
Z-lines apply to all servers, like G-lines. The ipmask may be a single IPv4 or IPv6 address, or may be a range of IPs specified in IPv4/IPv6 CIDR notation. You can also use the normal wildcards (*
and ?
), but you cannot use both wildcards and CIDR notation.
Functionally, Z-lines and G-lines act the same, with one notable exception. Unlike all other network ban types (include K-, G-, A-, GA-, E-, Q-, R-lines, and SHUNs), Z-lines are the only type of network ban that are checked immediately upon a connection to the network being initiated. All other ban types are checked only after a connecting user has completed registration (i.e., declaring their username/ident, gecos, and initial nickname). This makes Z-lines particularly well-suited to dealing with instances of clear and obvious network resource abuse, as opposed to general rule-breaking.
Z-lines are most often seen being applied by the IRC server automatically, when acting upon a DNSBL match. Z-lines will act on users connecting from the affected address(es), regardless of their displayed hostnames/cloaks - this is desired behavior. If someone is repeatedly getting Z-lined due to DNSBL hits (since DNSBL auto-Z-lines normally expire after one hour) and it starts flooding the oper logs, you can manually set a longer Z-line (up to 30 days, as you see fit). If you do this, set the new Z-line reason's to be the auto-Z-line's reason with the text "and contact unbans@lizardirc.org after removal from blacklist for unban, or to request an exemption" appended to the end, and target your new Z-line for the auto-Z-line's target in CIDR single-address notation - that is, append /32
if it's an IPv4 address or /128
if it's an IPv6 address (if you don't do this, the server will complain that a Z-line already exists for the given IP).
When a Z-line is set, currently connected affected users will be immediately disconnected with a quiet message (visible to all users) "Z-lined:" followed by the reason you give when issuing the Z-line. The banned user will also see the same, along with a message advising them to email LizardIRC staff if they would like an unban. Users trying to connect to the network will be immediately rejected from connecting, as described above, with the same messages given to them (the reason and the email address). Note that the duration is never revealed to anyone except other network staff.
G-lines are more likely to display correctly in a banned user's IRC client than Z-lines, so when you are setting a ban, consider using a G-line instead of a Z-line.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active ZLINEs, use the command /stats Z
.
See also: KLINE, GLINE, RLINE.
QLINE[edit | edit source]
Usage: /qline nickmask [duration :reason]
Required operator class: RingLord
Sets or removes a q-line (nick based ban) on a nick mask. You must specify all three parameters to add a ban, and one parameter to remove a ban (just the nickmask).
Q-lines apply to all servers, like G-lines. No one (except IRC services) can use a Q-lined nickname, and anyone using a nickname when it is Q-lined will have their nickname forcibly changed to their connection user ID immediately; these users will be informed that their nickname has been banned from use and be given the reason you specify when setting the Q-line. Users who attempt to use a Q-lined nickname after-the-fact will be notified that the nickname is forbidden and also be shown the reason; a notification will be sent to #opers notifying staff that someone tried to use a Q-lined nickname. Users who attempt to use a Q-lined nickname when registering to the network upon connecting will also receive an "invalid nickname" message with the reason, and will be required to choose a nickname before registration can be completed; no notification will be sent to #opers in this case.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active QLINEs, use the command /stats q
.
GLINE[edit | edit source]
Usage: /gline user@host [duration :reason]
Required operator class: RingLord
Sets or removes a g-line (host based ban) on host mask. Unlike K-lines, G-lines will apply to all servers on the network.
You must specify all three parameters to add a ban, and one parameter to remove a ban (just the user@host section).
The host part can be a hostname with the normal IRC wildcards (*
and ?
), or it can be an IPv4 or IPv6 address. If an IP address is used, a range can be specified either by using the standard IRC wildcards, or by using CIDR notation. If an IP address (or range) is used, it will act on users connecting from the affected address(es), regardless of their displayed hostnames/cloaks.
When a G-line is set, currently connected affected users will be immediately disconnected with a quiet message (visible to all users) "G-lined:" followed by the reason you give when issuing the G-line. The banned user will also see the same, along with a message advising them to email LizardIRC staff if they would like an unban. Users trying to connect to the network will be rejected from connecting after they attempt registration, with the same messages given to them (the reason and the email address). Note that the duration is never revealed to anyone except other network staff.
G-lines are most useful when dealing with cases of trolling, one-off abuse, rule-breaking, etc. On the other hand, for dealing with persistent network resource abuse, you may wish to consider issuing Z-lines, which are checked immediately when a user tries to connect to the network, before registration. Note, though, that Z-lines only accept IP addresses as parameters; if you must ban against a hostname or a user/ident, you have to use G-lines.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active GLINEs, use the command /stats g
.
See also: KLINE, ZLINE, RLINE.
ELINE[edit | edit source]
Usage: /eline user@host [duration :reason]
Required operator class: RingLord
Sets or removes a e-line (ban exception) on the given host mask. You must specify at least 3 parameters to add an exception, and one parameter to remove an exception (just the user@host section).
E-lines apply to all servers on the network, like G-lines.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
This command has a few important limitations. Bans on *@ip (including Z-lines) can only be negated by an eline on *@ip, bans on *@host can be negated by elines on *@ip, or *@host, and bans on ident@* or ident@host can be negated by any eline that matches.
This command is useful for helping trusted users bypass the DNSBLs when absolutely needed.
To view the list of active ELINEs, use the command /stats e
.
WALLOPS[edit | edit source]
Usage: /wallops message
Required operator class: Lord
Sends a message to all users who have set usermode +w
on themselves. Useful for unimportant global network messages. For important ones, you should use OperServ GLOBAL or InfoServ.
See also: OperServ GLOBAL, InfoServ POST.
RLINE[edit | edit source]
Usage: /rline regex [duration :reason]
Required operator class: RingLord
Sets or removes an r-line (regex line) on a nickname!user@host\sgecos
mask. You must specify all three parameters to add an rline, and one parameter to remove an rline (just the regex).
The regex must be a PCRE (Perl Compatible Regular Expression). To make the regex case-insensitive, prefix it with (?i)
. Remember that the regex cannot contain whitespace; use the keyword \s
to represent whitespace instead (note that the first \s
is used to separate the hostname from the gecos, and only the gecos can contain whitespace).
When a R-line is set, currently connected affected users will be immediately disconnected with a quiet message (visible to all users) "R-lined:" followed by the reason you give when issuing the R-line. The banned user will also see the same, along with a message advising them to email LizardIRC staff if they would like an unban. Users trying to connect to the network will be rejected from connecting after they attempt registration, with the same messages given to them (the reason and the email address). Note that the duration is never revealed to anyone except other network staff.
R-lines should only be used if you need to use regular expressions and/or need to match against a user's gecos/realname. Because they are regex-based, they are more computationally expensive than other ban types. If you don't need the extended functionality of R-lines, use G-lines or Z-lines instead.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active RLINEs, use the command /stats R
.
See also: KLINE, GLINE, ZLINE, FILTER, OperServ RWATCH, OperServ RMATCH.
CLEARCACHE[edit | edit source]
Usage: /clearcache [server]
Required operator class: TimeLord
This command clears the DNS cache of the specified server. If no server is specified, the local server's DNS cache will be cleared.
CLOSE[edit | edit source]
Usage: /close
Required operator class: SithLord
Closes all unregistered connections to the server you are currently connected to.
ALINE[edit | edit source]
Usage: /aline user@host [duration :reason]
Required operator class: RingLord
Sets or removes a a-line on host mask. A-lined users must be authenticated to NickServ to use the network. You must specify all three parameters to add a ban, and one parameter to remove a ban (just the user@host section).
When an A-line is set, currently connected affected users who are also not identified to NickServ will be immediately disconnected with a quit message (visible to all users) "A-lined:" followed by the reason you give when issuing the A-line. The banned users will also see the same, along with a message "You need to identify via SASL to use this server (your host is A-Lined)". Users trying to connect to the network will be rejected from connecting if they do not attempt SASL authentication, seeing the same "A-lined" messages (if SASL authentication is attempted but failed, they are given a standard SASL authentication failed error, followed by getting disconnected as if they did not attempt SASL authentication; if SASL authentication is attempted and succeeds, the user is allowed to connect to the network as normal). Note that the duration is never revealed to anyone except other network staff.
A-lines are useful in cases when there is isolated abuse across a range of hosts/IPs, especially when there are known good users on the same range.
A-lines only apply to the server they are set on, like K-lines. To set a global a-line, use the /galine
command. Note that because of this, you'll almost always want to use GA-lines instead.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active ALINEs, use the command /stats a
.
See also: GALINE.
GALINE[edit | edit source]
Usage: /galine user@host [duration :reason]
Required operator class: RingLord
Sets or removes a global a-line (ga-line) on host mask. GA-lined users must be authenticated with NickServ to use the network. You must specify all three parameters to add a ban, and one parameter to remove a ban (just the user@host section).
When a GA-line is set, currently connected affected users who are also not identified to NickServ will be immediately disconnected with a quit message (visible to all users) "GA-lined:" followed by the reason you give when issuing the GA-line. The banned users will also see the same, along with a message "You need to identify via SASL to use this server (your host is GA-Lined)". Users trying to connect to the network will be rejected from connecting if they do not attempt SASL authentication, seeing the same "GA-lined" messages (if SASL authentication is attempted but failed, they are given a standard SASL authentication failed error, followed by getting disconnected as if they did not attempt SASL authentication; if SASL authentication is attempted and succeeds, the user is allowed to connect to the network as normal). Note that the duration is never revealed to anyone except other network staff.
Note that users connecting through the Tor hidden service need to perform SASL authentication to use the network, as if they were GA-lined (though the implementation and effects are different).
Like A-lines, GA-lines are useful in cases when there is isolated abuse across a range of hosts/IPs, especially when there are known good users on the same range.
A ga-line will apply to all servers, like a g-line. Use the /aline
command to set an a-line that applies to only one server (like a K-line). In almost all cases, you'll want to use GA-lines instead of A-lines.
The duration may be specified in seconds, or in the format 1y2w3d4h5m6s
- meaning one year, two weeks, three days, 4 hours, 5 minutes and 6 seconds. All fields in this format are optional.
To view the list of active GALINEs, use the command /stats A
.
See also: ALINE.
Services management commands[edit | edit source]
This section will explain various aspects of services (e.g., NickServ, ChanServ, OperServ) management from the perspective of the commands used. For each command, usage instructions and usage scenarios will be provided. The Procedures section explains aspects of services management from the perspective of what needs to be accomplished.
Note that this section will not cover every (staff-only) services command, only the most important ones. As always, to get a full command list, do /msg service HELP
(note that staff-only commands will only appear in HELP output to staffers).
Finally, note that full usage instructions will not be covered here, since services contain their own very complete HELP functionality. Instead, this section will give a one-line usage summary, the permissions needed to perform the command, and use cases. Finally finally, remember that to use these commands, you need to be logged in to a NickServ account with the appropriate services operator class ("ircop" or "sra") and also be opered-up on the IRC server.
OperServ GLOBAL[edit | edit source]
Usage: /msg OperServ GLOBAL message|SEND|CLEAR|LIST
Required services operator class: ircop
Sends a global notice to all users connected to the network. For urgent or important network news/notifications. Lines are added to the notice by sending OperServ GLOBAL message
, and all message lines are sent (in order) when OperServ GLOBAL SEND
is used.
Unlike InfoServ POST, OperServ GLOBAL is for one-time notifications, and should be used if the notification is one-time, doesn't need the distribution controls given by InfoServ, or is multiple-lines.
See also: InfoServ POST, WALLOPS.
InfoServ POST[edit | edit source]
Usage: /msg InfoServ POST importance subject message
Required services operator class: ircop
Posts a new network news item. Depending on the setting of the importance parameter, the item may be displayed to users only when they connect, be sent to all users as a network notice immediately, or both. There is also a setting that causes the item to be sent as a private message to all users immediately (instead of as a NOTICE, which is standard); this should never be used.
Note that InfoServ cannot accept multiple-line news items; OperServ GLOBAL should be used instead for this, or if the notification is one-time and doesn't need the distribution controls given by InfoServ.
See also: OperServ GLOBAL, WALLOPS.
InfoServ DEL[edit | edit source]
Usage: /msg InfoServ DEL id
Required services operator class: ircop
Deletes news items that are shown to users upon connect (the similar ODEL command is used to delete news items that are shown to staff when they oper-up). This command is of note because it deletes the news item permanently for everyone - it does not only delete or hide it for you and should not be used for this purpose.
Please ask the staffer who added a news item before deleting it, unless of course you are the same staffer who added it.
OperServ AKILL[edit | edit source]
Usage:
/msg OperServ AKILL ADD nick|hostmask [!P|!T minutes] reason
/msg OperServ AKILL LIST|DEL hostmask|number
/msg OperServ AKILL SYNC
Required services operator class: ircop
OperServ AKILL is essentially a G-line, implemented at the services level instead of the IRC server level. Indeed, OperServ will "enforce" AKILLs as G-lines with durations matching the specified duration with the AKILL. Likewise, there's not much reason to use OperServ AKILL over simply setting G-lines, and G-lines are the recommended way to issue global network bans over AKILLs.
In other words, you probably shouldn't use this directly, but it exists and is available to be used. In general, AKILLs are only used by other OperServ ban functions, and shouldn't be set directly by staff (set G-lines instead).
See also: GLINE.
OperServ RMATCH[edit | edit source]
Usage: /msg OperServ RMATCH /pattern/[i][p] [FORCE]
Required services operator class: ircop
OperServ RMATCH allows you to use regular expressions to get a list of matching users on the network. Do /msg OperServ HELP RMATCH
for full usage instructions. The regex pattern can either be a POSIX regex, or a PCRE (Perl-compatible regular expression) in which case the p
flag is added to the end of the pattern. This command is useful to test a regex before using it with OperServ RWATCH. In PCRE mode, this command is useful to check your regex for accuracy and syntax before passing it to R-line.
Clarification of the OperServ documentation: There is a limit to how many entries this command will return, which can be overrided with the FORCE
keyword - but regardless of whether this keyword is used, the total count of matches will always include all matches.
See also: RLINE, OperServ RWATCH.
ChanServ CLOSE[edit | edit source]
Usage: /msg ChanServ CLOSE #channel ON|OFF reason
Required services operator class: ircop
Registered channels can be closed through ChanServ to disallow their use by anyone. Closed channels cannot be dropped and cannot have foundership transferred. When a channel is CLOSE'd, anyone in it is immediately kickbanned, and anyone who attempts to join is as well.
CLOSE'd channels will still expire. If you wish for a CLOSE'd channel to not expire, set ChanServ HOLD on it after setting CLOSE. You also can't close a held channel, so you must first disable HOLD, set CLOSE, and then set HOLD again (if desired). Unless there is a genuine risk that the channel will be recreated with malicious intent after it is expired, you shouldn't set HOLD on a channel after closing it.
CBAN provides similar functionality, but is implemented at the IRC server level and works on non-registered channels as well. When a channel is closed, it should also be CBAN'd as CBANs notify opers when someone tries to use the channel. In this case, the purpose of ChanServ CLOSE is to prevent those with ChanServ access to the channel from manipulating it.
The reason for the closure, and the closer's name, will be shown in ChanServ INFO output to other staff. Non-staff will simply see the message "#channel has been closed down by the LizardIRC administration".
See also: ChanServ HOLD, CBAN, NickServ FREEZE.
OperServ CLEARCHAN[edit | edit source]
This is a Very Dangerous Command. Use it wisely, and ensure you follow the procedures described here. Misuse, including accidents, can cause SERIOUS network damage!
Usage: /msg OperServ CLEARCHAN KICK|KILL|AKILL #channel reason
Required operator class: ircop for KICK
, sra for KILL
and AKILL
.
OperServ CLEARCHAN removes all users from #channel, by kicking them, killing them, or adding them to the OperServ AKILL list, depending on which of the three actions you choose in the command. Note that only the "kick" action is available to ircops; you must be sra to use "kill" or "akill".
Useful in combination with CBAN to clear users out of an unregistered channel (if the channel is registered, you should be using ChanServ CLOSE along with CBAN, which itself will automatically clear the channel in a fashion similar to OperServ CLEARCHAN KICK).
Note that the reason you provide will be displayed to network staff and to the affected users.
See also: OperServ KLINECHAN, ChanServ CLOSE, CBAN.
OperServ KLINECHAN[edit | edit source]
This is a Very Dangerous Command. Use it wisely, and ensure you follow the procedures described here. Misuse, including accidents, can cause SERIOUS network damage!
Usage: /msg OperServ KLINECHAN #channel ON|OFF reason
Required services operator class: sra
This command sets a channel as an automatic K-line channel. This is a slightly misleading name: The effect is that any non-staff who joins a channel with KLINECHAN set on it will be immediately G-lined for one week.
There are only a few narrow cases where using this is a good idea, such as channels that only attract n'er-do-wellers, botnet C&C channels, and the sort. If in doubt, ask other staff.
To set up a KLINECHAN channel, follow this procedure exactly:
- If the channel is unregistered, register it in your name. If it is registered, use ChanServ FTRANSFER to transfer ownership to your name.
- Use ChanServ SET to set the
RESTRICTED
,SECURE
, andPRIVATE
options. - Use ChanServ SET MLOCK to set the channel's mode-lock to
+nst
. - Enable KLINECHAN on the channel.
- (Optional) use OperServ CLEARCHAN AKILL to AKILL users already in the channel, since enabling KLINECHAN only acts on users who join the channel in the future. Use the same reason as you provided when enabling KLINECHAN.
- Close the channel using ChanServ CLOSE, providing the same reason as you did when enabling KLINECHAN. Do not CBAN the channel in this case, even though the procedures for using ChanServ CLOSE tell you to.
- Enable ChanServ HOLD on the channel to prevent it from expiring.
The reason you provide will be shown to users who are G-lined by KLINECHAN, as well as to other staff who look up channel information using ChanServ INFO. Regular users who use ChanServ INFO on a KLINECHAN channel will only see the message, "#channel has been closed by the LizardIRC administration".
To unset KLINECHAN and return a channel to normal use (given the circumstances in which KLINECHAN might be necessary, this will probably never happen), perform the above procedure in reverse (disable ChanServ HOLD, disable ChanServ CLOSE, disable OperServ KLINECHAN, and so forth) or simply drop the channel (ChanServ DROP or ChanServ FDROP).
See also: ChanServ FTRANSFER, OperServ CLEARCHAN, ChanServ CLOSE, ChanServ HOLD, CBAN.
NickServ HOLD[edit | edit source]
Usage: /msg NickServ HOLD account ON|OFF
Required services operator class: ircop
When NickServ HOLD is set on an account, it prevents that account and all nicks registered to it from expiring.
In general, HOLD should only be applied to NickServ accounts of network staff, though there may be other reasons for setting HOLD as well (for instance, long-term impersonation risk).
See also: ChanServ HOLD.
ChanServ HOLD[edit | edit source]
Usage: /msg ChanServ HOLD #channel ON|OFF
Required services operator class: ircop
When ChanServ HOLD is set on a channel, it prevents that channel from expiring.
In general, HOLD should only be applied to official network channels; the same channels one might set channel mode +P
(permanent) on.
See also: NickServ HOLD.
NickServ VHOST[edit | edit source]
Usage: /msg NickServ VHOST account ON|OFF vhost
Required services operator class: ircop
Sets or removes a cloak (vHost) on the given NickServ account. The vhost arguments needs only be provided when you are granting a cloak (NickServ VHOST ON).
This command should be used when directly granting a cloak to a user (e.g., user promoted to network staff, user requested cloak directly in #help, etc.). Remember that cloaks must follow the rules set forth here.
See also: HostServ ACTIVATE.
HostServ WAITING[edit | edit source]
Usage: /msg HostServ WAITING
Required services operator class: ircop
Shows a list of users who have requested cloaks using HostServ REQUEST. Staff can act on waiting requests using the HostServ ACTIVATE or HostServ REJECT commands described below.
See also: HostServ ACTIVATE, HostServ REJECT.
HostServ ACTIVATE[edit | edit source]
Usage: /msg HostServ ACTIVATE nickname
Required services operator class: ircop
Grants the cloak requested by nickname. A list of requested cloaks can be found by using HostServ WAITING. Remember that cloaks must follow the rules set forth here, and that non-compliant cloak requests should be rejected.
Though NickServ VHOST provides similar functionality, it should not be used when dealing with cloaks requested through HostServ; that's what HostServ ACTIVATE and REJECT are for.
See also: HostServ WAITING, HostServ REJECT, NickServ VHOST.
HostServ REJECT[edit | edit source]
Usage: /msg HostServ REJECT nick [reason]
Required services operator class: ircop
Rejects the cloak requested by nickname. A list of requested cloaks can be found by using HostServ WAITING. A memo will be sent (automatically via MemoServ) notifying the user that their request was rejected. You can (and should) also provide a reason, which will be included in the memo.
See also: HostServ WAITING, HostServ ACTIVATE.
ChanServ FTRANSFER[edit | edit source]
Usage: /msg ChanServ FTRANSFER #channel newfounder
Required services operator class: ircop
Forcibly transfers a #channel registration to the ownership of newfounder. This command may only be used in cases where a staffer is forcibly transferring a channel ownership in their official capacity as network staff. The "correct" way to "normally" transfer ownership of a channel (also accessible to regular users) is ChanServ SET FOUNDER, or to use ChanServ FLAGS to grant the flags +*F
.
ChanServ FFLAGS[edit | edit source]
Usage: /msg ChanServ FFLAGS #channel target flags
Required services operator class: ircop
Forcibly changes the flags granted to target in #channel as given in the flags argument, even if the user using FFLAGS doesn't have ChanServ flag +f
in the channel. This command may only be used in cases where a staffer needs to intervene in a channel, in their official capacity as LizardIRC network staff. Using FFLAGS is strongly discouraged in favor of either using ChanServ FLAGS to perform a flags change as one normally would, or working with the operators of the channel directly instead of forcing a flags change.
ChanServ FDROP[edit | edit source]
Usage: /msg ChanServ FDROP #channel
Required services operator class: ircop
Forcibly drops #channel, irrevocably erasing it from ChanServ's database. Will fail if the channel is held via ChanServ HOLD. This command may only be used in cases where a staffer is forcibly dropping a channel they do not own, in their official capacity as network staff. If you wish to drop a channel you own, just use the normal ChanServ DROP command.
Note that, in all foreseeable cases as of this writing, using ChanServ FDROP is inadvisable; closing problem channels via ChanServ CLOSE is the recommended course of action.
See also: ChanServ HOLD, ChanServ CLOSE, NickServ FDROP.
NickServ FDROP[edit | edit source]
Usage: /msg NickServ FDROP account
Required services operator class: ircop
Forcibly drops the NickServ account account, including all nicknames owned by that account. This irrevocably erases the account and all its data from NickServ's database. This command may only be used in cases where a staffer is forcibly dropping an account they do not own, in their official capacity as network staff. If you wish to drop an account you own, just use the normal NickServ DROP command.
Note that this command drops entire accounts; to forcibly ungroup a registered nickname from an account - that is, to free up the nickname without destroying the account too - use NickServ FUNGROUP.
Also note that, in all foreseeable cases as of this writing, using NickServ FDROP is inadvisable; freezing problem accounts via NickServ FREEZE is the recommended course of action.
See also: ChanServ FDROP, NickServ FUNGROUP, NickServ FREEZE.
NickServ FUNGROUP[edit | edit source]
Usage:
/msg NickServ FUNGROUP nickname
/msg NickServ FUNGROUP accountname new-accountname
Required services operator class: ircop
Forcibly removes nickname from the NickServ account that owns it, without otherwise altering the account. The nickname will be freed up for use and registration by others, though note that nothing prevents the original owner from regrouping the nickname.
If the nickname happens to also be the name of the NickServ account, you must also specify a new account name (which itself must be another nickname owned by the user). Therefore, it is impossible to use FUNGROUP on NickServ accounts that only own one nickname; NickServ FDROP is the only thing that will work in this case.
See also: NickServ FDROP.
NickServ FREEZE[edit | edit source]
Usage: /msg NickServ FREEZE nick ON|OFF reason
Required services operator class: ircop
This command disables the NickServ account that owns nickname nick. Disabled accounts cannot be logged in to, and anyone logged in to an account when it is frozen will have all their sessions logged out.
The fact that an account is frozen will appear on its NickServ INFO output, but the reason will only be shown to staff. No notification will be sent to the user when their account is frozen, but future IDENTIFY attempts will result in the message "You cannot identify to nick because the nickname has been frozen".
Frozen accounts will still expire as normal. If account recreation after expiry is a risk, you can set NickServ HOLD on the account to prevent expiration.
The reason needs only be provided when enabling FREEZE on an account.
See also: NickServ FDROP, NickServ RESTRICT, ChanServ CLOSE.
NickServ RESTRICT[edit | edit source]
Usage: /msg NickServ RESTRICT nickname ON|OFF reason
Required services operator class: ircop
This is primarily an anti-abuse command. When enabling RESTRICT on a NickServ account (a reason is only needed when enabling RESTRICT, not when disabling), the account can still be used but the following functions are disabled for the user:
- Grouping nicks
- Changing account name
- Registering a channel with ChanServ
- Registering a group with GroupServ
- Requesting a cloak through HostServ
- Accepting a cloak offered through HostServ
Setting NickServ RESTRICT is a good response to abuse of the above functions. The reason for the restriction and the fact that the account is restricted will be visible to staff only in NickServ INFO output for the account. The restricted user will see a message along the lines of "You have been restricted from action by network staff" when they attempt to perform a prohibited action.
See also: NickServ FREEZE.
NickServ FENFORCE[edit | edit source]
Usage: /msg NickServ FENFORCE account ON|OFF
Required services operator class: ircop
This command allows a staffer to force enable or disable nickname enforcement on an account. In general, if you use FENFORCE, it will be to turn off enforcement, not to turn it on. This command may only be used in cases where a staffer is forcibly disabling nickname enforcement account they do not own, in their official capacity as network staff.
Using FENFORCE to disable nickname enforcement on an account is useful in cases where a user has forgotten their password, has requested a password reset, but still wants to be able to use their nicknames until they can actually complete the reset. Or if a user hasn't used an account in a while, and someone has presented a reason for wanting to use the nickname but before it has automatically expired.
* MARK[edit | edit source]
Usage: /msg Service MARK entity ON|OFF comment
Required services operator class: ircop
This command is supported by multiple services, all with approximately the same effect. Service can be one of: NickServ, ChanServ, ChanFix.
This command adds a comment to entity's record in Service INFO output. For example, using ChanServ MARK on a channel causes the line "This channel has been marked" along with the comment, and the staffer who added the MARK, in that channel's ChanServ INFO output. Channels can be marked in ChanServ and ChanFix (ChanServ MARKs only appear in ChanServ INFO, and ChanFix MARKs only appear in ChanFix INFO), and nicknames can be marked in NickServ.
Only one MARK can be set on any entity at any given time, per Service. MARKs are only visible to network staff, so are useful for storing staff-only information relevant to the channel (e.g., "Channel historically used for warez distribution").
Comment only needs to be provided as an argument when enabling MARK.
NickServ SENDPASS[edit | edit source]
Usage: /msg NickServ SENDPASS account [FORCE|CLEAR]
Required services operator class: ircop*
This command allows a staffer to reset the password of a NickServ account. When called, this command sends a standard password reset email to the owner of the account. Note that to prevent abuse, only staff can use this command; regular users need to request password resets in #help or from a staffer directly.
Accounts marked with NickServ MARK cannot have their passwords reset in this fashion unless you specify the FORCE argument.
If a password reset email has been sent using SENDPASS but it is no longer needed, you can revoke the password reset token by using SENDPASS again, but this time with the CLEAR argument. Note that the password reset tokens expire automatically after 24 hours from being sent.
*Note: To reset the password of an account with services operator permissions (ircop or sra), you need sra permissions yourself.
You cannot send a password reset for an account that is currently logged in to, even with the FORCE argument.
OperServ OVERRIDE[edit | edit source]
This is a Very Dangerous Command. Use it wisely, and ensure you follow the procedures described here. Misuse, including accidents, can cause SERIOUS network damage!
Usage: /msg OperServ OVERRIDE target service command [parameters]
Required services operator class: sra
This command is like sudo - it allows you to perform any services action as another user. Target is the user you want to perform the action as, service is the service you are sending the command to, and parameters are any parameters the command needs.
Note that there are certain commands, like NickServ REGISTER and NickServ GROUP, that cannot be used through OVERRIDE.
Only use this command if you have a real reason that makes using it absolutely necessary. Abuse of this command will not be tolerated. The author of this guide cannot come up with any situations where using this command would be necessary, but since not all situations are foreseeable, the command is provided nonetheless.
OperServ IGNORE[edit | edit source]
This is a Very Dangerous Command. Use it wisely, and ensure you follow the procedures described here. Misuse, including accidents, can cause SERIOUS network damage!
Usage:
/msg OperServ IGNORE ADD nick!user@host reason
/msg OperServ IGNORE DEL nick!user@host
/msg OperServ IGNORE LIST
/msg OperServ IGNORE CLEAR
Required services operator class: sra
This command allows a staffer to add users to OperServ's ignore list. Anyone matching an entry on OperServ's ignore list will not get a reply when they attempt to interact with any of the IRC services. Yes, all of them - NickServ, ChanServ, the whole shebang. This notably includes SASLServ, so users won't be able to use SASL authentication, so take care not to accidentally add A-lined or GA-lined ranges to the OperServ IGNORE list as they will be effectively banned from the network even if they have valid credentials.
Likewise, OperServ IGNORE should only be used in the most egregious cases of services abuse. Note that there is built-in flood protection in services; more than 7 actions* in 10 seconds will cause services to temporarily auto-ignore the user (with a warning message indicating that the user has been temporarily auto-ignored due to flooding) the first two times, and services will set a 10 minute AKILL on the third offense.
*Note: Some resource-intensive commands, like NickServ REGISTER, count as multiple actions (usually between two and four). Most commands count as one.
Also note that a further rate-limiting is applied to the commands HelpServ REQUEST, HostServ REQUEST, NickServ REGISTER, and ChanServ REGISTER - these commands can be used at most 5 times in 60 seconds, and any use exceeding that will be ignored until the next 60 second period.
OperServ IGNORE CLEAR will clear all entries from the ignore list.
OperServ RWATCH[edit | edit source]
Usage:
/msg OperServ RWATCH ADD /pattern/[i][p] reason
/msg OperServ RWATCH DEL /pattern/[i][p]
/msg OperServ RWATCH LIST
/msg OperServ RWATCH SET /pattern/[i][p] options
Required services operator class: sra for OperServ RWATCH SET KLINE, ircop otherwise
OperServ RWATCH allows you to set regex-based watches on the network. RWATCH can either report matching users to #opers when they connect to the network, or set a 24-hour AKILL on them (you will need sra to do this). In KLINE mode (which sets the 24-hour AKILL), OperServ RWATCH is similar to RLINE, so you should probably use RLINE instead even if you have the required sra permissions. By default, when a RWATCH is added, it is only in report-to-#opers mode; you must enable KLINE mode by using OperServ RWATCH SET KLINE.
OperServ RMATCH is useful for testing regexes before using them in OperServ RWATCH.
For full usage instructions, please do /msg OperServ HELP RWATCH
.
See also: OperServ RMATCH, RLINE.
OperServ COMPARE[edit | edit source]
Usage:
/msg OperServ COMPARE nick1 nick2
/msg OperServ COMPARE #channel1 #channel2
Required services operator class: ircop
This command compares two nicknames and shows the channels the two nicknames have in common. Alternatively, the command compares two channels and shows the nicknames the two channels have in common.
Potentially useful for clone analysis.
OperServ JUPE[edit | edit source]
Usage: /msg OperServ JUPE server reason
Required services operator class: ircop
This command allows one to prevent a server from linking to the network by introducing a fake server with the real server's name. If the real server is connected to the network, one must first use SQUIT or RSQUIT to split it from the network. Jupes can also be removed by using RSQUIT.
This command is useful if a server is continuously splitting and rejoining the network, and is starting to get annoying.
OperServ NOOP[edit | edit source]
This is a Very Dangerous Command. Use it wisely, and ensure you follow the procedures described here. Misuse, including accidents, can cause SERIOUS network damage!
Usage:
/msg OperServ NOOP ADD HOSTMASK nick!user@host [reason]
/msg OperServ NOOP ADD SERVER server [reason]
/msg OperServ NOOP DEL HOSTMASK nick!user@host
/msg OperServ NOOP DEL SERVER server
/msg OperServ NOOP LIST HOSTMASK
/msg OperServ NOOP LIST SERVER
Required services operator class: sra
This command can be used to disallow staff access to their O-line (and, by extension, their services operator privileges). When a hostmask is added to OperServ's NOOP list, any user matching that hostmask who opers-up will be immediately killed by OperServ (but not AKILLd). When a server is added to OperServ's NOOP list, any user on that server who opers-up will be immediately killed as well.
This makes the command useful for locking out an abusive oper, but doesn't require access to the servers' configuration files. Use it wisely.
For the OperServ NOOP ADD commands, if a reason is not provided, a default of "Abusive oper" will be used.
OperServ UPTIME[edit | edit source]
Usage: /msg OperServ UPTIME
Required services operator class: ircop
Shows uptime and other basic statistics about services (such as number of registered accounts, nicknames, and channels). Exciting!
ChanFix CHANFIX[edit | edit source]
Usage: /msg ChanFix CHANFIX #channel
Required services operator class: ircop
ChanFix is a system that allows users (registered and unregistered) to operate unregistered channels with reduced risk of channel takeovers. It is very similar to the ChanFix system used on the (otherwise service-less) EFNet IRC network, so first read this page to learn about ChanFix and how it works.
This command allows a staffer to trigger a manual ChanFix run on an unregistered, qualifying channel. LizardIRC's ChanFix will deploy itself as described in EFNet's documentation, so a manual ChanFix is only needed for the same conditions as described in EFNet's documentation.
Note that because LizardIRC has full services in addition to ChanFix, this allows us to do something important: An unregistered channel that qualifies for ChanFix protection can only be registered with ChanServ by channel operators ChanFix considers "regular". At this time, there is no way to override this behavior.
There is one additional difference between LizardIRC ChanFix and EFNet ChanFix - Channel scores are tied to NickServ accounts when possible (for registered users), while unregistered users are still tracked by hostmask.
ChanFix LIST[edit | edit source]
Usage: /msg ChanFix LIST [pattern]
Required services operator class: ircop
Lists all channels with ChanFix records (or if pattern is specified, the list will be filtered to channels matching the pattern). This usually only includes channels that are unregistered and eligible for ChanFix protection, though note that for a little while after a services restart the list will include all channels on the network (before ChanFix has a chance to filter out ineligible channels).
ChanFix INFO[edit | edit source]
Usage: /msg ChanFix INFO #channel
Required services operator class: ircop
(Please ensure you are first familiar with EFNet's ChanFix documentation before running this command.)
Shows ChanFix-specific information about the #channel.
If you see the error "No CHANFIX record available for #channel; try again later", ChanFix has determined that the channel is ineligible for ChanFix protection, probably because it is registered with ChanServ or doesn't meet the activity requirements (documented in EFNet's ChanFix documentation).
ChanFix SCORES[edit | edit source]
Usage: /msg ChanFix SCORES #channel
Required services operator class: ircop
(Please ensure you are first familiar with EFNet's ChanFix documentation before running this command.)
Shows the channel operator scores tabulated for #channel. Do not disclose these scores to anyone other than other network staff!
If you see the error "No CHANFIX record available for #channel; try again later", ChanFix has determined that the channel is ineligible for ChanFix protection, probably because it is registered with ChanServ or doesn't meet the activity requirements (documented in EFNet's ChanFix documentation).
NetOpsBot commands[edit | edit source]
LizardIRC's Network Operations Bot (NetOpsBot) has a few staff-only commands. These commands are only acknowledged in #operchat, and are for manipulating the LizardIRC round robins and setting the "network alert status".
Round Robin Control[edit | edit source]
NetOpsBot contains in its configuration file the IPs of every server linked to the network, as well as whether or not the servers allow o-lines. It thus allows staff to check the status of the round robin DNS zones, as well as add or remove servers from the round robins. It automatically determines which round robins are appropriate to be modified - for example, a server will only be added to the cjdns.irc.lizardirc.org
round robin if it has a CJDNS address (and is peered to Hyperboria, the largest CJDNS-based meshnet).
The commands are as follows:
+check
- Checks the status of all round robins for all servers. For each round robin, a server's status is either given as PRESENT (the server's IP is listed in the round robin), ABSENT (the server's IP is not listed), or DUPLICATES (the server's IP is listed multiple times; this is probably an accident but shouldn't affect anything). Note that round robins that are innapropriate for a given server (such ascjdns.irc.lizardirc.org
for a server without CJDNS) are not listed at all for those servers.+add servername
- Adds the server servername to all appropriate round robin DNS zones. servername can be the short name (for example,emerald
) or the server's FQDN (e.g.,ruby.lizardirc.org
). Note that this command does not check if a server is already in the zone, so it can cause duplicates to be added. It is therefore recommended that you use+check
to check the round robins' status first. If necessary, the+remove
command, described below, can be used to clear servers that are partially entered into the round robins.+remove servername
- Removes the server servername from all appropriate round robin DNS zones. Note that this command assumes that a server will never be listed in an inappropriate DNS zone - these are indeed not checked for by the command. As with+add
, servername can be a short name or a FQDN. The remove command operates on duplicates and partial entries (i.e., a server is not listed in all appropriate round robin zones).
Network Alert Status[edit | edit source]
NetOpsBot can be used to signal network alerts to all staff who have provided contact information to FastLizard4. The alerts are distributed by email, though it is encouraged that you use an email-to-SMS gateway (provided by most cellphone carriers, or can be set up using a service like IfThisThenThat) to ensure rapid reception. Alerts are sent out using this command: +setcondition color
The following colors are recognized and have the following meanings:
- Red - Red alert means that all network staff, even those who are not necessarily available, should immediately come on IRC and stand ready to take immediate and quick actions, as well as carefully monitor logging channels. Red alerts are usually declared if an attack on the network is in progress. (Usage of Red Alert is not limited to attacks.)
- Yellow - Yellow alert means that all available network staff should immediately come online and stand ready to take staff actions. Yellow alerts are usually issued if an attack on the network was threatened, has occurred, or is occurring but does not require the same level of alertness and readiness as a Red Alert. (Usage of Yellow Alert is not limited to attacks.)
- Green - Condition green is the "default" alert state, and indicates that staff do not need to do anything special at this time. A condition green being declared after an alert means that staff may at that point stand down from increased readiness.
- Blue - Condition blue means that an exceptional situation has arisen on the network, but it does not require increased readiness or any general staff action beyond awareness of the situation. Available staff should come online at least briefly to be informed of the situation. Example usages of Condition Blue include non-attack related major networking issues and major network events.
All staff are authorized to set the network alert status as they see fit. Be bold, too - unnecessary alerts can always be rescinded by going back to Condition Green.
Procedures[edit | edit source]
This section will explain various aspects of network and services management, from the perspective of what needs to be accomplished. If you are looking for documentation on what individual commands do, please see the "Network management commands" section or the "Services management commands" section.
This section won't try to cover everything that might need to be done in the course of staff duties, but will discuss some of the more common situations a staffer might need to address.
Problem user[edit | edit source]
When dealing with a problem user (troll, spammer, flooder), whether to use a channel ban or a network ban is generally at your discretion. While it's not necessary to chase after every channel-banned troll to issue a K-line, it may be worth network-banning problem users who appear in major channels (such as #lizardirc). Consider the severity of the user's actions, and whether or not they were in violation of the network rules (network bans may only be issued for network rule violations). If you do decide to issue a network ban, you'll probably want to issue a G-line since those are more likely to be presented properly in IRC clients, though Z-lines may be used in cases where the early matching of Z-lines is advantageous. Z-lines should not be used against hosts known to be shared hosts, and if a problem user has an ident (not prefixed with '~'), consider setting the G-line against ident@host instead of *@host, and only expanding to *@host if the abuse returns.
You'll probably never want to set a K-line to deal with a problem user, since those are relatively easy to bypass.
Repeated DNSBL hits[edit | edit source]
If someone from a single IP address is repeatedly getting Z-lined due to DNSBL hits (since DNSBL auto-Z-lines normally expire after one hour) and it starts flooding the oper logs, you can manually set a longer Z-line (up to 30 days, as you see fit). If you do this, set the new Z-line reason's to be the auto-Z-line's reason with the text "and contact unbans@lizardirc.org after removal from blacklist for unban, or to request an exemption" appended to the end, and target your new Z-line for the auto-Z-line's target in CIDR single-address notation - that is, append /32
if it's an IPv4 address or /128
if it's an IPv6 address (if you don't do this, the server will complain that a Z-line already exists for the given IP).
See: ZLINE.