NewNet OperFAQ ------------------- A Helpful Guide for IRCops. The Opers Golden Rule: If you are unsure of what you are doing, then DON'T DO IT!! Ask someone for help! Revised 6/25/98 Released Written by EddieB . Send any questions, additions, changes, etc to that email address. Ideas were gathered from the previous OperFaqs from NewNet. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OperServ -------- HELP -Syntax : /msg OperServ HELP -Purpose: Shows what commands are available. MODE -Syntax : /msg OperServ MODE <#Channel> -Purpose: Changes channel modes. Useage is the same as /mode command. -Example: /msg OperServ MODE #Services -b *!eddieb@*.dragondata.com KICK -Syntax : /msg OperServ KICK <#channel> -Purpose: Kick a user off a channel. -Example: /msg OperServ KICK #Services EddieB Flooding GLINE -Syntax : /msg OperServ GLINE <+hours> -Purpose: Denies access for the specified user@host for the time noted. A reason MUST be included. Using the GLINE command on a top level domain such as *.com, *.net, *.org, etc will result in an automatic kill. -Example: /msg OperServ GLINE eddieb@*.dragondata.com +3 Excess clones. -Special Note : This command will not work until a new IRCD is in place that supports it. REMGLINE -Syntax : /msg OperServ REMGLINE -Purpose: Removes a GLINE set on the user@host before it expires. -Example: /msg OperServ REMGLINE eddieb@*.dragondata.com Hacked O:line - Special Note : This is not yet avaiable. KLINE -Syntax : /msg OperServ KLINE <+hours> -Purpose: Denies access to the network for the specified user@host for the time noted. A reason MUST be included. Using the KLINE command on a top level domain such as *.com, *.net, *.org, etc will result in an automatic kill. -Example: /msg OperServ KLINE eddieb@*.dragondata.com +3 Excess Clones. GLOBAL -Syntax : /msg OperServ GLOBAL -Purpose: Sends a message to all users online. -Example: /msg OperServ GLOBAL [Attention all users] - We will be having a tutorial on using the new services in #Classroom so stop by if interested. STATS -Syntax : /msg OperServ STATS -Purpose: Shows the number of users online, the number of IRCops online the max number of users and services' uptime. NOTICE : All commands issued to OperServ are logged! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Other IRCop commands ----- ----- -------- Changing a Channel password. /msg ChanServ set password Example: /msg ChanServ set #Services password 1K8cua9P Founder forgot pass. Note : Be VERY sure it's the real founder. Changing a Nick Password. /msg NickServ set password Example : /msg NickServ set password K8fka9UUw EddieB Founder forgot pass. Note : Be VERY sure it's the real founder. Setting yourself as channel founder /msg ChanServ set founder Example /msg ChanServ set #Services founder EddieB Fixing desynch. Note : This should only be used to fix desynchs when all else fails and to fix the access/akick list when the founder is not available. Be sure to reset the founder after finishing, meaning you MUST know the real founder before you do it in order to set him/her as the founder upon completion. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Channel TakeOver Scenario NOTE: Always do steps 1 & 2 before ever joining the channel STEP 1: /msg chanserv info (to figure out who is the founder) STEP 2: /msg chanserv access list * (so you know who doesn't belong) STEP 3: Try and join channel, say hi, act like nothing is wrong while you /names then : /msg operserv mode -o+o STEP 4: Fix all channel modes and clear all bans set by the takeover person STEP 5: Check the ban list, remove any bans set by the takeovers END OF EASY TAKEOVER SCENARIO That was an easy takeover solution, but it doesn't always go that way. BEGIN Additional Steps: A) If you are banned, type /msg ChanServ who B) Find the ban preventing you from joining on the list and remove it: /msg OperServ mode -b C) Join the channel and follow the above steps in the easy scenario. If the person continues to prevent you from getting in, ban and them with OperServ or issue a /kill. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Channel Desynchs ------- -------- First, see if someone on the ChanServ access list is online. If so have them do a /msg ChanServ join . That will fix the desynch. If no one is present then : Type /msg chanserv info and check who the founder is. Type /msg chanserv set founder Fixing desynch. Type /msg chanserv join Type /msg chanserv set founder Returning to founder after fixing desynch. Be sure to include reasons in your founder changes as shown above. These commands ARE logged along with reasons for the commands. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Channel Akick List ------- ----- ---- In the event that something happens and *!*@* or something along those lines is akicked, take the following steps: Type /msg chanserv set founder Fixing akick list. Type /msg chanserv akick list Type /msg chanserv akick del Type /msg chanserv set founder Returning to founder. Be sure to include reasons in your founder changes as shown above. These commands ARE logged along with reasons for the commands. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Routing ------- Learn this inside and out since a bad command and break the net apart. Pre-Routing --- ------- To see the current way the servers are connected use either the /links or /map command. The /map command provides a more visual representation of the was everything is connected. The comparison : A /map : irc.dragondata.com |-wingate.dragondata.com |-irc.klis.com `-hub.dragondata.com |-newnet.grolier.fr |-irc.intergate.bc.ca `-hub.eskimo.com A /links : irc.dragondata.com (0) P9 DragonData Internet Services hub.dragondata.com (1) P9 Flying Toaster hub.eskimo.com (2) P9 [204.122.16.36] Eskimo North -- Seattle, WA USA How to read a /map --- -- ---- - ---- There are two types of servers: leafs and HUBS. HUBS allow other servers to connect to them thus forming the network. Some HUBS allow client connections and others don't. Leafs allow client connections for people to come and chat. On the /map, the first server listed is the one you are on with your client. Servers with branches coming off of them are the HUBS while servers without are the leafs. For example : irc.dragondata.com <---- HUB |-wingate.dragondata.com |-irc.klis.com `-hub.dragondata.com <---- HUB |-newnet.grolier.fr |-irc.intergate.bc.ca `-hub.eskimo.com <---- HUB |-irc.gaianet.net |-services.newnet.net |-services2.newnet.net |-irc.tscnet.com <---- HUB | `-newnet.telia.NO <---- HUB | `-irc.salgsnett.no |-irc.salamander.com |-irc.eskimo.com <---- HUB |-irc.para-net.com <---- HUB | |-irc.assassination.org | |-obelix.norges.net | |-irc.aohell.org | |-irc.sprintlink.co.za | |-irc.busprod.com | |-irc.ncplus.com | |-newnet.online.be | |-irc.jaxn.com | |-irc.aye.net | `-irc.keytech.com `-irc.fastlane.net From the picture you cannot tell that irc.eskimo.com is a HUB since it is not carrying any servers at the moment. If you follow the branch down from hub.eskimo.com you can see the leafs and hubs connected to it (irc.gaianet.net, services.newnet.net, services2.newnet.net, irc.salamander.com, irc.eskimo.com, irc.paranet.net and irc.fastlane.net). Before doing any moving of server be sure to do a /uping command. Upings show lag and packet loss (if any) to the specified HUB. If you are checking your server's uping times use the command : /uping HUB's_server_name For example if you're on irc.dragondata.com and want to check your upings to hub.eskimo.com, you would type : /uping hub.eskimo.com And receive a response similar to : -irc.dragondata.com- Sending 5 pings to hub.eskimo.com[204.122.16.36] port 7007 -irc.dragondata.com- UPING hub.eskimo.com 160 110 120 107 102 -irc.dragondata.com- UPING Stats: sent 5 recvd 5 ; min/avg/max = 102/120/160 ms 102 ms = the minimum ping time 120 ms = the average ping time 160 ms = the maximum ping time The lower all these are the better but the average and maximum times count the most. To uping servers you are not on use : /uping leaf HUB Example: /uping irc.klis.com hub.dragondata.com Upings can be wildcarded for ease. The previous example could have been done : /uping *klis* hub.dragondata* Actual Moving of Servers ------ ------ -- ------- Rule #1 - NEVER squit services. Your O:line will be pulled immediately. Rule #2 - If you don't understand routing don't touch anything. Rule #3 - See re-read rules one and two. -- Moving your own server -- First use a /wallops message to announce your intention so all Opers are aware : /wallops I'm going to move to due to lag. Then you need to disconnect from your current HUB : /squit currentHUB -Be sure to include a reason. Then reconnect at the new HUB : /connect newHUB On NewNet our server port for connections is 5555. Example : Someone on irc.klis.com wants to reroute. It's current HUB (see map above) is irc.dragondata.com. The klis oper finds irc.para-net.com to be the best uplink so the oper does : /wallops Moving irc.klis.com to irc.dragondata.com /squit irc.dragondata* Lagged to HUB /connect irc.dragondata* 5555 -- Moving another server you're not on (Remote routing) -- Usually let active opers on that server move it themselves. The steps are generally the same : First do a /wallops message to announce what you're going to do : /wallops Moving klis to hub.eskimo Then disconnect the leaf from the hub : /squit Then reconnect it at the new HUB : /connect ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stats Info ----- ---- Doing a /stats can show information about your server. Doing a /stats can show information about another server. What stats you can do : C : Shows what the server can connect to. H : Shows what servers are allowed to be HUBs for the server. I : Shows what clients can connect to the server. K : Shows what user@hosts are banned from connection to the server. L : Shows available connection ports on the server. M : Shows commands avaiable on the server. N : Shows what the server allows to connect to it. O : Shows Operator lines for IRCops. U : Shows U:lines which give services it's "power". W : Shows the userload for your server. Y : Shows connection class information. Z : Nothing you need to worry about :-) t : Shows general server information. u : Shows uptime for the server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Oper Conduct -Wallops Wallops is used for making network announcements such as routing changes and changing network conditions. Never use profanity in wallops or make degrading remarks about others. Users set +w can read wallops and we need to keep our image high. -Assistance IRCops are to help users whenever possible. If you don't know the answer to a question, say so. Users get more frustrated with silence. If at all possible refer them to another person for help. If everyone is busy helping others or doing other things please help when you can. Everyone appreciates the extra help given. -Problem Users Users breaking policy should be warned of the violation. If they continue to be a problem a /kill should be used. If they persist a kline should be the next step. K:lines should never be as specific as possible. Never K:line an entire domain unless it is critical. -NetSplits If servers split due to various reasons they should reconnect on their own but you can manually reconnect them. Read the routing section for details on how to perform routing and be 100% sure you know what you're doing. -Language Never use profanity in wallops, kill messages, or K:line messages. Swearing at the users also reflects poorly upon all of us so be curteous. -Clients Try to know the most you can about your particular client and if possible learn the basic commands of other clients so that you can assist users no matter what client they are using. -Services Learn all about the services (NickServ, ChanServ, MemoServ, OperServ, etc) that you can so when someone has a question you can help them. Odd questions arise and if an IRCop can answer it and get things working for the user again they will be happy and more likely to stay a part of NewNet. -Other IRCops Not everyone will get along; it's a fact of life. This doesn't need to be expressed in public though. Killing or K:lining other IRCops or making degrading comments in wallops is considered bad behavior. If you have a problem with someone use the /msg command or the /ignore command. Not the /kill command. -Clones Current NewNet policy allows three connections per user@host. Anything over three is breaking policy and should be warned, then killed if the number is not brought to three or less. In cases such as mass clones (example: 15 or more) a K:line is most likely in order. Four connections could be an accident with one or more clients being ghosted so warn first. There are some IP's that are exempt from the cloning rule and are listed below : chat.eskimo.com cougar.hardlink.net 206.146.5.99 ruacad-gw.runet.edu into.devoid.net cougar.puddle.com millenium.bomb.net thalie.unice.fr ai.yoc.com goof.soundeffect.com sunfire.ucs.net sinsen.sn.no User1@hes*.southwind.net -Other Oper Items -Always ask if unsure about something. -Only use /kill and K:lines when necessary and be sure it's valid. -Use reasons in routing, kills, K:lines, etc. Foul language should not be used. The reason should make it clear to all what happened. -Try to know all the HUBs for each leaf, either by memory or make notes if needed. Doing a /stats C on each server gives the necessary information. -Have fun on NewNet. Opers are users too.