LizardIRC Network Staff Guide

Ambox emblem arrow.svg 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

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
RingLord
SithLord
TimeLord

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
Network Operations Bot

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
sra

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):

  1. +a: Redirect all users immediately (except for opers) and cause them to quit with the given reason
  2. +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
Valid FILTER 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.

See also: SANICK, NICKLOCK.

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:

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:

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:

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:

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:

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:

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:

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.

See also: SQUIT, RSQUIT.

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:

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:

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:

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.

See: GLINE, ZLINE, KLINE.

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.

View original page on LizardWiki

augmentative