NewNet's OperFAQ

A Guide for Helpful IRCops

Compiled and Written by:


Consultants and other contributors: Bill, DragonFlu, Maya, Kara, Debora, Artemis, CoreDump, rale, Sharaika, LilPenny, RLD

The Opers Golden Rule: If you are unsure of what you are doing, then DON'T DO IT!! Ask someone for help!

Revised: 8/04/97

This guide was designed as a quick reference for Opers. It was created to fill a gap in the current documentation and provide each oper with the information necessary to help the users with Services-related issues that are commonly seen in the help channel #Services.

The format will be similar to our #Services FAQ with the exception of the section dealing with the step-by-step procedures necessary to fix certain problems in the channels.

Please send all comments, additions and corrections to JumpMan.


OperServ Commands/Explanations
Official from the Online Help Commands
Operserv General Help - /msg OperServ HELP

MODE (channel) (modes) - Change a channel's modes
KICK (channel) (nick) (reason) - Kick a user from a channel
KLINE (user@host mask) (hours) (reason) - Add a global KLINE
Notice: All commands sent to OperServ are logged!

OperServ Modes Help - /msg OperServ HELP MODE

Syntax: /msg OperServ MODE (channel) (modes)
Allows IRCops to set channel modes for any channel.
Parameters are the same as for the standard /MODE command.

OperServ KLINE Help - /msg OperServ HELP KLINE

Syntax: /msg OperServ KLINE (user@host mask) (+hours) (reason)
user@host mask is the hostmask of the user(s) you want off the
network (dwild@*, etc) hours is the number of hours
the user should be banned. (reason) is a description of why
this user was banned. When you come up with a reason, please
be specific, and keep in mind that this user is being banned
from the _entire network_. If needed, talk to and/or /kill the
user to see if you can get your point across without a global
Kline. DO NOT BAN *@*.domain except in extreme situations.
Also, keep in mind that abuse of services in any way will
result in disciplinary action, up to and including loss of
O: line or the server's links.


Common OperServ Commands

OperServ OP - /msg OperServ mode (channel) +o (nickname)
Gives you or anyone you choose ops in the specified channel.

OperServ KICK - /msg OperServ KICK (channel) (nickname) (reason)
Kicks the person out of the selected channel.

OperServ BAN - /msg OperServ mode (channel) +b (mask)
(note: you can do this after joining the channel and getting ops and using your irc client to do the ban. /mode (channnel) +b (mask)
There are a few different bans you can use:

/msg OperServ mode #services +b bill@*
/msg OperServ mode #services +b *!*@*
/msg OperServ mode #services +b Bill!*@*
/msg OperServ mode #services +b Bill!

Bans the person from the selected channel.

OperServ MODE - /msg OperServ mode (channel)
Note: When set to + (activated) Modes are:

n=no external messages
t=only ops can change the topic
i=invite only
s=secret (will not show on the /list)
l=limit (requires a number after it, limiting the number of users allowed on the channel)
m=moderated (only +v and above can be recognized)
k=keyed (requires a key (password) after it) Only those with the key are allowed entry.

Recommended for most channels: +nt-isplmk

*NOTE* although OperServ can do these mode changes, it is recommended that we use Chanserv for this. OperServ should be used for functions chanserv cannot do for us, like remove bans, op and de-op ourselves and users. To use ChanServ for this, use:
/msg chanserv set (channel) mlock (modes)

OperServ KLINE - /msg OperServ KLINE (user@host mask) (hours) (reason)
Globally removes the user from the Network for a specified timeframe.
/msg operserv kline * +24 reason permissible times are from 1 to 72 hours.


Common ChanServ Commands - To put the function of ChanServ how it relates to IRCops in the simplest of terms, before we use OperServ for anything, Global Opers have roughly the same priveledges as a level 5 channel op in any channel on NewNet. In addition, IRCops can leave and/or join a channel that is set to invite only without doing anything special.

This enables us to help users with channel problems without going thru a lot of commands to do it. For example, a channel is set to +i and there is no-one there, we can go in to the channel unassisted, and change the channel modes /msg chanserv set (channel) mlock -i. Since you have done a /msg chanserv info (channel) before going into the channel, it's easy to see what the founder set the modes to. Most channels are set to +nt only, if the founder is there (or an op from the access list) explain to them that +nt-smkpli is much safer and will help prevent takeovers and that you would be happy to set it for them in that manor.

In this section, we have tried to compile the most common and useful step-by-step instructions to fix the most frequent problems that we encounter in dealing with the users.

There are two instances that the Global Oper must become the founder.

These are:

To part/join ChanServ
To add/del from access list and akick list


Changing the Founder Pass (user forgets pass)
/msg chanserv set (channel) password (new pass) (reason)

alternate method:

/msg chanserv drop (channel) user requested
user can now re-register the channel

This method must be a last resort since it also clears all modes, access list, akick list, etc.


Channel TakeOver Scenario

NOTE: Always do steps 1 & 2 before ever joining the channel

STEP 1: /msg chanserv info (channel)
(to figure out who is the founder)
STEP 2: /msg chanserv access (channel) list
(so you know who doesn't belong)
STEP 3: Try and join channel, say hi, act like nothing is wrong while
you /names (channel) then /msg operserv mode (channel) -o (nick)
then /msg operserv mode (channel) +o (yournick)
STEP 4: /msg chanserv set (channel) mlock (-modes locking the channel)
STEP 5: Check the ban list, remove any bans set by the takeovers


That was an easy takeover solution, but doesn't always go that way.

BEGIN Additional Steps:

A) If you are banned, type /msg operserv mode (channel) -b *!*@*
and join the channel. Op up an de-op the person as quickly as possible.

B) If they are fast and get you, then you have to guess what ban they used.
**NOTE** If you log, as most opers should and do, you can usually check your log for that channel and see how the ban was added. This doesnt always work, but can save you a lot of guesswork.

C) Since we can't see in the channel, unless you got in and got a /names (channel) you have a problem if their user mode is +i. If you know who is in the channel, you can:
a) use operserv to de-op or
b) kill them for taking over the channel

D) If you can't figure out what ban was placed, you can change founder to yourself and have ChanServ part the channel thus clearing the ban list. This is providing ChanServ is the only op in the channel and providing they set the channel to +i so they can't get back in either.

E) Join the channel and bring back ChanServ, check the akick list, just to be sure there are no bans like *!*@* and reset the mlocks to +nt-skmlip.

F) Tell the others to join the channel. If the attackers return, set the ban on the channel (not akick) to keep them out until the founder decides otherwise.

G) Return the channel to founder.

If services are down and there is only 1 op in the channel (the perpetrator of the takeover) CON them into giving you ops. Tho this may sound laughable, if you are good, you can accomplish it and save yourself and the users of the channel a lot of grief.


UnBanning Yourself from a Channel
/msg operserv mode (channel) -b *!*@*


Depending on how the ban was written.


Resynching a Channel When the Founder isn't Present

Step 1: Type /msg chanserv info #channel and check who the founder is.
Step 2: Type /msg chanserv set #channel founder yournick (fixing desynch)
Step 3: Type /msg chanserv join #channel
Step 4: Type /msg chanserv set #channel founder (the nick of the founder from step 1) (returning to founder after fixing desynch)


Fixing Akick List in a Channel

/msg chanserv set (channel) founder JumpMan to fix akick list
/msg chanserv akick (channel) list
/msg chanserv set (channel) founder (nick) done


Removing yourself from an Akick List
Step 1: /msg operserv mode (channel) -o (nick who banned you)
Step 2: /msg chanserv set (channel) founder JumpMan fixing akick
Step 3: /msg chanserv akick (channel) list
Step 4: /msg chanserv akick (channel) del (mask found above, or number)


De-Opping a person from outside the channel
/msg operserv mode #(channel) -o (nick)


Temporary commands we can use to help users with nick problems

Dropping A Nick (user forgot password)
/msg nickserv drop (nick) user requested

Changing the users password
/msg nickserv set password (pass) (nick) (reason)


Oper User Modes:
to enable or disable, type /mode (nick) (mode)
Example: /mode JumpMan +d

o = opered
u = unwanted notices such as seeing who did a /whois on you
w = wallops
d = deaf mode
i = invisible mode
c = to see connection notices
k = to see kills??
s = server notices
f = see nick changes
l = kill messages

Server Routing Procedures 101 by Cypress
Routing is basically the way servers are interconnected together on the internet. And also the most important part of a network technically. Bad routing can cause lag and downtime for certain servers.

Listing the map to see how servers are connected


To see the how the network is presently routing you can either do /map or /link although /map is more graphic and for some more understandable then the /links. Usually when you do either one of these commands...the server you do them from will be at the top of the list.

Example. Right now I'm on so if i do a /map it shows like this :
| |
| |

If i do a /links it shows like this

How to recognize where leafs and hubs are linked exactly?

Well when you do /map (which i recommend) the graphic looks like a tree with branches. Leafs derive from one main server which is called a HUB.

This is an example of a /map : <-------server you are on is always first
` <-------Hub
| |-*
| |-*
| |-*
| |-*
| |-*
| `-*
| <-------European Hub
| `
| `
| <------Hub
| |
| | <------Hub
| | |
| | |
| | |
| | |
| | | <-------Hub
| | | |
| | | |
| | | |
| | | |
| | | `
| | |
| | | <------Hub
| | | |
| | | |
| | | `
| | |
| | |
| | |
| | `
| |
| |
| |
| |
| `
` <-----Hub
End of /MAP

All servers you see coming down from on the same *branch* so to speak are it's leafs. Meaning,,,,, and others are leafs attached to hub.eskimo at this time. Now if you look at the is linked to as well, meaning that is tscnet's "uplink" which interlaces through the rest of the net. And as you notice has some servers linked to it and one of them being wich is also a HUB. Same thing for being a Hub and having as it's uplink.


**BEFORE Routing**

Your server anywhere you should always try to do a /uping HUBname. HUBname being the hub you might want to try and link to. This will send 5 packets to the hub and give you ping times in return. You should always try and link to the hub where you have hardly or no packet loss and low ping times.

ie : /uping

results: Sending 5 pings to[] port 7007 UPING 73 102 152 149 160 UPING Stats: sent 5 recvd 5 ; min/avg/max = 73/127/160 ms

notice 73 is the minimum time
127 being average
160 max time

You should usually look at average and max time. The lower they are the better.


Commands for rerouting:


Also Services cannot be remotely connected so don't try. And Anyone squiting on purpose will result in the lost of their O line and services access removed.

1) If you are presently on a "leaf" server wich needs to be rerouted-->
/squit present-hubs-name REASON /connect New-Hubs-name

ie: lets say is linked to eskimo and wants to link to, then one of the opers would do the following :
/squit REASON or /squit *eskimo* REASON
and then..
/connect or /connect *chelms*

NOTE : You can wildcard server names and make sure that when you squit from your present uplink that you squit the right HUBs name.

2) If you are presently on a HUB that needs to be rerouted and it leafs to another hub.
/squit present-hubs-name REASON
/connect new-hubs-name

3) If you want to reroute a leaf server remotely (meaning you aren't presently on that server):
/squit (leaf_servername) (present_HUB_name) REASON

...this will squit the leaf you want to reroute from it's present uplink then..
/connect (leaf_servername) 5555 (new_HUBs_name)

..this will remote connect the leaf to the new hub on port 5555 (which is the autoconnect port)

4) If you want to reroute a HUB server AND it's leafs which is what you ALWAYS want to do and you aren't on that hub then...
/squit (HUB-needed-squit) (HUBs_uplink) REASON

ie: if is linked to with 6 leafs attached to it and i want to reroute it to I would do
Which means will be squited from (it's present uplink)

to connect : /connect (HUBname) (new_uplink_hub)
ie: in this case i would do /connect * 5555 *paonline*

If Someone who is NOT a leaf server attached to a HUB that is about to be squited or is not that HUB's uplink and does /squit then you will squit the HUB ONLY..which should *never* be done. What will happen exactly..lets say eskimo has 9 servers attached to it. It will squit and leave the leafs out in the cold.It will detach from whatever it is linked to and what is linked to it as well.

So for example. Let's say i'm on and i am NOT linked to and i do /squit that will cause the server to squit in the middle of nowhere and leaves whatever servers that was linked to it at the time alone out in the cold as well.


Also Please note a leaf will usually find it's best link on it's own. Let's say a server keeps pinging out from a link to and links to then it's no use trying to put it back to it's original place. Also when routes are bad..this is where it comes handy. Usually due to very bad routes..and server downtime leafs will link in the best place on it's own and usually this will be it's best uplink for that time.


Server Misc. Info
A:Lines--Specifies what information is seen when /ADMIN is typed
C:Lines--Specifies which server it can connect to.
E:Lines--Exempts defined users from K:Lines
H:Lines--Specifies which servers are to be considered Hubs.
I:Lines--Informs the server which clients are authorized to access server
K:Lines--Defines to server which clients are prohibited to access server
k:lines--Defines to server which clients are prohibited to access server temporarily. (Set by IRCop)
M:Lines--Specifies the server name, description and port number it is on
N:Lines--Specifies which servers it will accept connections from.
O:Lines--Informs the server which clients can access Operator commands
o:lines--Informs the server which clients can access Operator commands (restricted to local server commands; e.g., /KILL will only work on users on the server the operator has an o:Line on)
P:Lines--Sets which ports the server may listen on
Q:Lines--Informs server of which nicks cannot be used on that server
U:Lines--Informs the server over which servers are authorized to make changes to user and channel mode settings regardless of actual user status.
Y:Lines--Specifies how servers accept IRC clients. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Oper Conduct

1) /wallops PHRASE. This is used to talk to those users who have their user mode set to +w. /wallops is a way for operators to talk about important matters in linking etc. Do not abuse this! The /wallop command should never be used for chat that can take place in a channel. This is only to be used in important network matters. Users who have their mode set to +w, will be able to see wallops, so be careful!

2) An IRCops chief responsibility is to provide speedy and high-quality assistance to any user who is in need of help courteously. In the event you may not be able to provide such service, please direct them to #Services or perhaps another IRCop will be able to help them.

3) Users should feel free and come to any IRCop about any person who is harassing them. If a user is violating server policies, the user should be warned at least twice. Then they should be forcibly removed from the IRC network. If the user persists by returning to IRC and continues his/her offensive behavior, a temp K:Line should be engaged. Also, please try to keep your warnings logged...this log should be given to your Server Administrator to verify user conduct.

4) In the event of a netsplit, servers are automatically made to reconnect. However, sometimes a server will disconnect and not reconnect on its own. Unless another Operator gives you good reason to not do this, re-connect the split servers. Read Routing above. Be absolutely sure you know the correct procedure.

5) If other Operators are busy with assisting other users or bring the network back together, offer to be of some help. The more team effort, the more smoothly your job will be, not to mention your appreciation from others for your help.

6) Please be courteous to users and refrain using foul language. We are all human and are likely to curse once or twice in our lifetime, however, people of all ages come and we cannot afford to lose users because parents think this is a bad place to be. Also, it represents us as irresponsible and vulgar. And, once again, please be friendly to a user asking a question. There is no question worth yelling at them for; just remember, you were once a newbie too.

7) Always drop Idle conversation in a help channel, such as #Services to assist a user in need. If you don't know the answer to the question, say so (one of the main frustrating elements in a help channel is that when nobody knows the answer, and don't say anything). If you know anyone on IRC that can help them, direct the questioner to them.

8) Study your client more. IRC has hundreds of commands, and your knowledge of these commands will benefit not only the person asking the question, but you as well.

9) Study the main services (ChanServ, NickServ) so that when users ask you questions about how to do unusual tasks such as add other addresses to their nickname access list or change founders of their channel, you may be able to give them the proper information.

10) When you are in a help channel, do not idle when you have users asking for help. Users who ask a question and get no reply merely become frustrated and leave--most likely never to return. NewNet is still in the process of growing and doesn't need to lose users and even worse, it projects a bad image of an irresponsible IRC network.

11) Do not kick, ban, kill other IRCops or defame them in public. If you have a problem with someone, take it up in private /msg, E-Mail or merely avoid them all together.


Clones and Bots

NewNet allows a maximum of three connections per user@host.
Anyone found connected with more than 3 connects MUST be warned first *before* any kill.
Any user still having over 3 connections to NewNet, after a warning, is in violation of policy and will be /killed.
The following IP's are exempt from this rule:

.Dont Kill These!

Bots can be used to help people, and can be used to hurt them. There are clone bots, nickname-changing flood bots, hack-bots (designed to steal ops on channels),etc. Also, there are useless bots..such as vanity bots, op-hogging bots (bots that join empty channels just to have ops), cafe-bots (bots that use action commands to serve drinks and food) or bots that don't do anything at all. But, there are a lot of "Good" bots out there. Most people use bots to keep the channel open, and to prevent a channel from take-overs. IRC is for chatting and unless this bot augments that purpose, it is frowned upon by most users----especially server administrators.

Make sure to make clear to get permission from the server administrator if a user wants to run a bot on the server, even if they have an open bot policy. Some servers have no bot policies and make sure to make clear to users to respect that request.


Oper Do's and Don'ts
1) Again, it you are unsure of something, dont do it. Ask someone who can help you learn the correct procedure.

2) Appreciate the power of "/ignore nick all" and teach other users the power of it. This single command stops most floods and most disputes between individuals. It is not necessary to /kill a user for common floods unless they evade an ignore.

HINT: To know for sure someone is actually being flooded, tell the victim to change their nick quickly, assume the victims previous nickname, and the flooding will then be directed at you.

3) Mass Invites, Mass Messaging, Mass Advertising, icmp or nuking, user harrassment by evading a /ignore, and if Services are down and there are no channel ops in a channel and it is being flooded are all reasons for a /kill on the first offense. Proof is required anytime a /kill is performed and common sense is an absolute necessity.

4) All of the above on the third offense and AFTER speaking with the offender and getting no satisfaction, a KLINE is probably in order. But remember, if it is possible to handle a user thru negotiation, it is far better for our network to do so.

5) Use Meaningful and Concise comments in your /kill and kline's. No foul language is allowed. It detracts from the professional image we have a responsibility to nurture.

6) Concerning Routing: You should do a /stats c on every server to know their primary, and secondary hubs, then if a server is disconnected, you can review your notes to determine the proper remote link. Ensure your notes are up-to-date and complete. Routing is a very sticky business if you are not exactly sure of what you are doing.

You are visitor # since 12/24/97