T h e N e w D A L n e t O p e r a t o r' s M a n u a l Version 1.1, April 11th 1998 Version 1.1.1, March 27th 1999 By Wizzu With help from NetMaiden Jilli Prez Glory Studded Data Luce Aysmonte MirclMax JoelKatz Strahd And final words by Mikki Based on the DALnet Operator's Manual, version 4.01, by Dairenn Sentinele Meep MrPlastic Wizzu The most recent version of this manual is available from ftp://ftp.dal.net/dalnet/ircop/operator.txt Table of Contents ================= Chapter 1. Introduction 1.1 Preface 1.2 How To Read This Manual 1.2.1 If You Are a New IRC Operator 1.2.1 If You Already Have Experience As an IRC Operator 1.3 IRC And DALnet History 1.4 DALnet Features Part I - TECHNICAL INFORMATION Chapter 2. Terminology 2.1 Services 2.2 Opers, Admins, CSops, etc. 2.3 Globals, Globops, Wallops, Chatops And Locops 2.4 Rerouting 2.5 Server Lines 2.6 Kills, Killable Offenses 2.7 K:Lines, Autokills (AKills) 2.8 Services Ignores 2.9 Marks 2.10 Clonebots (Clones, Cloning) 2.11 ircd 2.12 Links 2.13 Sync(h)s 2.14 Jupes 2.15 SendQ, RecvQ (RcveQ) 2.16 DALnet Chapter 3. A New View To IRC 3.1 IRC Technical Operation And Network Structure 3.1.1 IRC Technical Operation 3.1.2 IRC Network Structure 3.1.3 IRC Protocol Commands 3.2 IRC Operator Server Commands 3.2.1 /oper 3.2.2 /globops, /wallops, /chatops and /locops 3.2.3 /kill 3.2.4 /kline and /unkline 3.2.5 /connect 3.2.6 /squit 3.2.7 /rehash 3.2.8 /restart 3.2.9 /die 3.2.10 /close 3.2.11 /samode 3.2.12 /zline and /unzline Chapter 4. Some IRC Features From an Operator's View 4.1 Network Status 4.1.1 /links 4.1.2 /stats 4.1.3 /version 4.1.4 /trace 4.1.5 /lusers 4.2 Other Commands 4.2.1 /helpop and /help 4.2.2 /notice and /msg 4.2.3 /who 4.2.4 /motd and /admin 4.2.5 /silence 4.2.6 /nick 4.3 Usermodes And Server Messages 4.3.1 Usermode +o 4.3.2 Usermode +s 4.3.3 Usermode +w 4.3.4 Usermode +g 4.3.5 Usermode +c 4.3.6 Usermode +k 4.3.7 Usermode +f 4.3.8 Usermode +h 4.3.9 Usermode +a 4.3.10 Usermode +A 4.3.11 Usermode +b 4.4 Other IRC Issues Chapter 5. IRC Operator Services Commands 5.1 Access Levels 5.2 OperServ Commands Available To All Opers 5.2.1 trigger 5.2.2 broad 5.2.3 uptime 5.2.4 listadm 5.2.5 autokill list 5.3 OperServ Commands Available To Service Admins 5.3.1 mode 5.3.2 massdeop 5.3.3 masskick 5.3.4 autokill 5.3.5 ignore 5.3.6 drop 5.4 OperServ And Services Commands Available To CSops 5.4.1 getpass 5.4.2 clearmask 5.4.3 mark 5.4.4 close and reopen 5.4.5 freeze 5.5 Other Services Features 5.5.1 Extra NickServ/ChanServ Accesses 5.5.2 Services Logs 5.5.3 Services Root Access Part II - OPERDOM Chapter 6. Social Section - Expectations, Duties And Privileges 6.1 Requirements 6.1.1 Help Maintain The Network And Your Server 6.1.2 Help The Users 6.1.3 Enforce DALnet Rules 6.1.4 Follow The Guidelines And Instructions Given In This Guide 6.1.5 Behave In a Fitting Manner For a DALnet IRC Operator 6.1.6 Keep Up To Date On DALnet Matters, Rules And Policies 6.1.7 Do Not Share Confidential Information With Non-Opers 6.1.8 New Operator's Actions 6.2 Conduct 6.2.1 "On Duty" And "Off Duty" 6.2.2 General Conduct Guidelines 6.2.3 Guidelines For Dealing With Users 6.2.4 Guidelines For Staff Interaction 6.2.5 Staff Misconduct 6.3 Network And Server Maintenance 6.3.1 How To Deal With: Lag 6.3.2 How To Deal With: Netsplits And Missing Servers 6.3.3 How To Deal With: Desynchs 6.3.4 How To Deal With: Services Going Down 6.4 Helping Users 6.5 Policy Enforcement 6.5.1 How To Deal With: Clonebots 6.5.2 How To Deal With: Flooding 6.5.3 How To Deal With: Ignore / Ban / K:Line Evasion 6.5.4 How To Deal With: Harassment 6.5.5 How To Deal With: Mass-messages 6.5.6 How To Deal With: Desynchs 6.5.7 How To Deal With: Channel Matters 6.5.8 How To Deal With: ICMP Flooding And Other Non-IRC Matters 6.5.9 How To Deal With: Spoofing 6.5.10 How To Deal With: Warez And Child Pornography Trading 6.5.11 How To Deal With: Services Abuse 6.6 Dispute Mediation 6.6.1 Nick/Channel Ownership: The Password Rule 6.6.2 Nickname Ownership 6.6.3 Channel Ownership 6.6.4 Channel Control 6.6.5 Inappropriate Behaviour 6.6.6 General Guidelines 6.7 Team Issues 6.7.1 Help The DALnet Team 6.8 Privileges And Responsibility Chapter 7. Rerouting 7.1 Internet Issues 7.2 Non-IRC Commands 7.2.1 Traceroute 7.2.2 Ping 7.3 When Should Servers Be Rerouted, And Where To 7.4 Rerouting Procedure 7.5 What Can Go Wrong 7.5.1 Autoconnects 7.5.2 No C/N:Lines 7.5.3 No Response 7.5.4 Write Error 7.5.5 Wrong IP 7.5.6 Bad Password 7.5.7 I'm a Leaf Not a Hub! 7.5.8 Server Exists 7.6 Rerouting Example Chapter 8. DALnet Organization 8.1 Servers, Teams And Other Groups 8.1.1 List Of Teams And Groups 8.2 Support Services 8.2.1 Mailing Lists, Mail Aliases 8.2.2 List Of Mailing Lists 8.2.3 List Of Email Contact Addresses 8.2.4 Other Support Services: WWW, FTP, DNS, Finger 8.3 How DALnet Works Chapter 9. Final Words - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 1. INTRODUCTION ======================== This guide, "The New DALnet Operator's Manual", is not only meant for new DALnet operators. Rather, it is meant as a full manual for all opers, both new and experienced. The "New" in the name was added because this text is a complete re-write of the original "DALnet Operator's Manual" by Dairenn. I hope this document will be informative and provide a lot of help for you as an IRC operator on DALnet. I've tried to make it as complete as possible, which is why the text is so long. I've also tried to write it in such a manner that the guidelines wouldn't get obsolete and grow old as changes happen, but it is inevitable that this happens over time, so you shouldn't ever rely on JUST this manual for instructions. Let me know if you have any comments, questions, find misinformation or typos, or anything else you want to say. I'd especially like to hear of missing topics and subjects which aren't explained clearly enough. Send comments by email to wizzu@dal.net, or you could talk to me on DALnet or send a memo. - Wizzu 1.1 PREFACE ------------ Congratulations and Welcome to the DALnet Team! You have been selected by the Server Administrator of a DALnet IRC Server to be an IRC Server Operator! Because of this, it is assumed that you already have a working knowledge of most common IRC commands and concepts and a full understanding of DALnet Services commands (if not, don't be afraid to ask). In all likelihood, you were selected to be an IRC Server Operator due to your dedicated assistance of users in need of help (specifically in the DALnet recommended help channels), because your attitude is helpful, friendly and you are patient, and finally, due to your interest in the success of DALnet and the wish to make it the best possible IRC network. This manual will tell you about the things you need to know to be a good DALnet IRC operator. The information given here is written as general operator guidelines on DALnet. IRCops must answer to their admin, and because of that, where these rules conflict with instructions you have been given by your admin, you should listen to your admin. 1.2 HOW TO READ THIS MANUAL ---------------------------- This manual is divided into the preface (this chapter) which has the introduction and tells you about DALnet history and features, the technical part which tells you about the new commands and IRC features available to you as an IRC operator (chapters 2 to 5), and the social part which gives advice on being an IRC operator on DALnet (chapters 5 to 8). If you feel that this text is too long to read, it could help to read it one part or even one chapter at a time. The text here has been written to be read (and printed) using a fixed-width font. If you use a non-fixed width font, the diagrams in the document will likely be unreadable, but there will probably be no other problems. 1.2.1 IF YOU ARE A NEW IRC OPERATOR ------------------------------------ There is a lot of information given here, and you are not expected to learn everything at once! Also, please do refer back to this manual at a later date if you are unsure about something, the document has been designed to be used as a reference too. This manual might include some instructions for things you already know how to do. Please browse through these parts as well, since there could be new features or details you have yet to be aware of. As an operator, you are generally expected to have a fair understanding of the topics explained here. Finally, keep in mind that experience is the best teacher. Everyone learns by doing! This guide will explain a lot of things, but it's no substitute for experience. 1.2.1 IF YOU ALREADY HAVE EXPERIENCE AS AN IRC OPERATOR -------------------------------------------------------- This manual probably has instructions for quite a few things you already know how to do. You may skip these parts, but it might be worth your while to also skim through them as well, since there could be new features or details you aren't aware of yet (as an operator, you are generally expected to have a fair understanding of the topics explained here). Another approach would be to read the table of contents and only read those sections which you feel you are unfamiliar with. If your oper experience is on another network and not DALnet, I do suggest reading or at least browsing through all of this manual. There are a lot of things which are specific to DALnet (some commands, policies, guidelines). You may also use this document as a reference manual, checking things only when you need to know something specific. 1.3 IRC AND DALNET HISTORY --------------------------- IRC was created in 1988. It was originally written by Jarkko Oikarinen, but since then many other people have contributed to its existence. As you might already know, IRC stands for "Internet Relay Chat". The "original IRC", EFnet (or "Eris-Free Network") was started in 1988, about when IRC first began, and it is the currently largest and oldest IRC network in existence. As an alternative to this popular, but chaotic and sometimes frustrating medium, a new IRC network called the Undernet was formed in 1992, with servers in the United States, Canada, Australia, and Europe. In July 1996, the EFnet split into two, with servers in North America forming the new EFnet and rest of the servers - mostly in Europe - forming a new network called IRCnet. The Undernet has attempted to get rid of channel chaos and constant problems of takeovers and op wars by setting up what is known as the CService. It tries to get rid of the problems caused by a large proportion of users running bots to protect against takeovers and to manage the channel. This service allows users to register channels with the W or X bots to protect them against troublemakers, as well as to permanently register channel settings and attributes such as the channel mode or topic. In addition to the idea of a channel service, the Undernet stands out in the area of ircd (IRC daemon, the IRC server program) developement. Numerous small and some significant changes were made to give more information to the users, help the operators in server and network management and to make the network operate better. In the summer of 1994 DALnet was founded, by Dalvenjah FoxFire and his friends MirclMax, Morpher and Lefler. These people realized that IRC could be free from the havoc of EFnet and started a network of their own. At first, the Undernet versions of ircd was used. New and original improvements were added later by the DALnet people such as Lefler at first, and Russell, Aetobatus and Donwulff later developing the program further. The DALnet ircd is currently maintained and developed by the DALnet Coding Team, with many others contributing through the dalnet-src@dal.net mailing list. The DALnet server source code can be downloaded from ftp.dal.net, in the directory /dalnet/server (at the time of writing this the current version is dal4.6.5.DreamForge). The first Windows and Macintosh IRC clients started to appear and gain popularity in 1995. Before this, IRC had been almost exclusively populated with unix clients, ircII as the most common one. DALnet was listed at the top of the default server list for the popularity gaining Windows client called mIRC, and as a result many curious newcomers to IRC wandered to DALnet. This was one of the reasons why DALnet started to became popular during the later half of 1995. During the summer of 1995 the "highest max client number" (ie. the highest number of IRC clients on at the same time) had been just over a hundred -- during the late fall, it breached 1,000 and kept skyrocketing. The 10,000 max client count was reached during late 1996, and 20,000 about a year later. The client count has been on a steady rise for a long time and so far, there have been no signs of that ending. What makes DALnet prominent is that it was the first, and currently the only large IRC network featuring advanced user services (NickServ, ChanServ and MemoServ). Coded originally early in 1995 by Morpher and going online at roughly the same time as Undernet's CService, the DALnet services allow users and operators alike to enjoy the luxury of nickname and channel ownership via NickServ and ChanServ, respectively. The addition of MemoServ has made the IRC /note command obsolete. Services (the collective name for NickServ, ChanServ, MemoServ, HelpServ and OperServ) works well because all communications between it and the user are handled by the pseudo-server services.dal.net, which is designed to connect to the network hubs for its uplink, and thus allowing for a more efficient system to monitor the network than traditional bots. Services is property of DALnet, and is not in use on any other network. DALnet's Services has been widely imitated and because of this other networks may have similarly styled services, but they have been developed independently after DALnet's example. Services are currently maintained by the DALnet Services team. 1.4 DALNET FEATURES -------------------- There have been numerous small and some major improvements to DALnet's ircd. Some of these are visible changes to users, while others are of significance only to operators or even manifest only as better server and network performance. Among the user visible features are: a 30 character limit on nicknames (instead of the original 9 on IRC), centrally manageable K:lines so that it's possible to ban users effectively from the entire network, the watch system which is a new notify-style system but which is designed to minimize the bandwidth used, and finally HelpOps which is an online help system for users. The DALnet Services have been widely imitated due to their success. NickServ's and ChanServ's automated nickname and channel registration is very easy to do and hassle-free. NickServ provides the totally transparent operation of allowing you to use your favorite nickname anytime you want and even allows you to set an URL so other users can look up your web page or know where to send email to you. NickServ registration also enables users to register their channels with ChanServ or use MemoServ to leave brief online notes to each other. ChanServ is easy to use, very responsive, and above all provides seamless channel security while also taking care of automatically opping the people designated by the channel's founder. For the aid of IRC operators, Services features OperServ. This guide will give a brief overview of the OperServ commands. Additionally, doing a "/msg OperServ help" command on DALnet while having your operator-status activated will give you command help. Some IRC operators are given further control over DALnet, primarily in the area of ChanServ and NickServ, in the form of SA (Service Admin) or CSop (Service Operator) access. Above all, DALnet represents "The Friendly Network", where IRC users don't have to stay alert for unscrupulous users or technical failures. Instead, DALnet users can have a great time chatting with friends on a favorite channel or in private. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ============================== Part I - TECHNICAL INFORMATION ============================== The IRC Operator's Tools This part (chapters 2 to 5) will explain about new IRC operator commands, give you a basic knowledge of how IRC works, and describe in detail the IRC features important to an IRC operator. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 2. TERMINOLOGY ======================= - Things you will hear about This chapter will not explain about common IRC terms, such as bots or lag. Rather it will focus on terminology that is used mostly by IRC operators and that you might not have heard before. Some of the other terms will get a new meaning with explanations of IRC features and functionality that follows in later chapters. 2.1 SERVICES ------------- Services is a single program which connects in the same way as a server would to DALnet. NickServ, ChanServ, MemoServ, HelpServ and OperServ which make up Services are merely aspects of this one program. It is very important for an IRC operator to understand what IRC features are part of the IRC servers and/or the IRC network, and what are provided by Services. The NickServ, ChanServ, MemoServ (and so on) services are not bots in the normal sense of the word. Whether they actually are bots at all or not is a debatable case. Since Services is an independent program, they may go down or crash independently of the network (however, if it does go down, see section 6.3.4 on how to deal with that). In this guide "Services" means the single program which appears as the various "services" on DALnet (NickServ, ChanServ, etc.), as well as collectively referring to all of the services as a group. 2.2 OPERS, ADMINS, CSOPS, ETC. ------------------------------- Here's a brief explanation of the DALnet staff positions and hierarchy. - An IRC operator (also referred to as oper, IRC op, IRCop, O:line holder, someone with a *) is someone who has been granted IRC operator status on a server. IRC operators are answerable to the admin of their server. Some operators have an O:line on more than one server, in that case they must choose a primary server. (See the definition of "lines" in section 2.5 for an explanation about the "O:line".) The preferred term is "oper" or "IRC operator", as "IRCop" and similar titles may be read as "IRC cop". - An admin is a person who runs (administrates) a server and is responsible for it. Admins select the operators for their server. On the IRC itself, an admin actually has no more privileges than any other oper. Services has a number of administrative staff positions as well. These do not denote any sort of rank, except for Services access comparative purposes (see the explanations) -- they signify only added responsibilities, with extra access to Services to handle these responsibilities. To be able to handle any of these responsibilities, you need to be an IRC operator. See chapter 5 for more information. - Service Admins (SAs) have access to a few extra Services commands, to help deal with abusive users or other problem situations. Most notably, SAs can add and remove autokills. - Service Operators (CSops, NickServ/ChanServ Admins) have the same access as Service Admins, but are also able to deal with nickname and channel ownership issues (lost passwords, etc.). - Services root access users (roots) are the ones who actually manage and run Services. They have access to several Services features not available to anyone else, in addition to all CSop features. DALnet has a lot of other administrative positions and teams, but these are not actually visible online IRC. More on these in chapter 8 on DALnet organization. 2.3 GLOBALS, GLOBOPS, WALLOPS, CHATOPS AND LOCOPS -------------------------------------------------- A global (short from "global notice") is a notice sent by an operator to all DALnet users who are using the network. Globals can also technically be done with normal messages instead of notices, but in practice that is never done for a number of reasons. Notices may also be sent to a limited group of users, either based on which servers they are using, or what their address is. If the notice is sent to the clients on only one server, it's usually called a server notice (confusingly enough, since server notices are also messages sent by servers to anyone who has the usermode +s set -- to avoid this these kind of globals could be labelled after the server's name, for example a "davis notice"). If the notice is sent to part of a network, for example "*.eu.dal.net" (all the users on the European servers), it is a network part notice. If it's sent to users based on their address/hostname, it's called a domain notice or notice to hostmask. A globop is a message sent by an operator or a server to all IRC operators who have set the usermode +g (more on this in section 4.3.4). Globops are a means for opers to discuss important network issues without users seeing. For extended discussions, joining a channel is strongly recommended. Some people might refer to globops as "globals" too, but this is not proper usage and is discouraged. Globops should not be used for idle chat, see chatops (below) for that. A wallop is a message sent by an operator to all users who have the usermode +w set (more on this in section 4.3.3). Only IRCops can send them, but they are visible to anyone who sets the usermode. Wallops are a bit "antique", and because of this they shouldn't be used much. The point is arguable though. Many curious users set themselves +w in order to see interesting operator messages. The best current use for them is for announcing network issues to the "interested users", especially in cases when a global is not proper. Chatops are technically identical to globops. The corresponding usermode is +b (see section 4.3.11). Unlike globops, there are no automatically generated chatops messages. Chatops have been added purely as a free chat medium for IRC operators in order to let globops be used for strictly network related issues. Sending globals is explained in section 4.2.2, sending globops, wallops, locops and chatops is explained in section 3.2.2. 2.4 REROUTING -------------- Rerouting means changing the current network layout: the order of how servers connect to each other. The reason for rerouting is to get rid of a bad network connection and start using one that works better. Reroutes are basically done by issuing a /squit command to disconnect a link on the network, and then using a /connect to establish another link elsewhere. There are actually many things to consider in rerouting -- for more information, see the sections explaining /connect (3.2.5), /squit (3.2.6) and especially chapter 7 which explains rerouting. 2.5 SERVER LINES ----------------- IRC servers all have a configuration file which controls various aspects of the server, usually called ircd.conf. This file consists of various "lines", which are all named after the first character in that line. Thus there are O:lines, K:lines, C/N:lines, etc. Some of these lines can be viewed with the /stats command on IRC (for more information on /stats, see section 4.1.2). Here's a brief explanation of what each line does: A:line -- Specifies what information is seen with the /admin command. C:lines -- Specify which servers the server can connect to. D:lines -- Connect rules for all connects. d:lines -- Connect rules for autoconnects only. H:lines -- Specify which servers are to be considered hubs. I:lines -- Define which clients are authorized to connect to the server, and what connection class they should use (see Y:lines). K:lines -- Define which clients are prohibited access to the server (banned). k:lines -- Define which clients are prohibited access to the server temporarily (settable by server opers). L:lines -- Specify which servers are to be considered leafs. M:line -- Specifies the server name, description and the port number it should "listen" to. N:lines -- Specify which servers are allowed to connect to the server. O:lines -- Define which clients can access operator commands on the server. o:lines -- OBSOLETE, however the term "local o" is still in use. Define which clients can access local operator commands (restricted set of operator commands; eg. /kill will only work on users on the same server). P:lines -- Set which additional ports the server may listen to. (Also select IP addresses to use if the computer has more than one.) Q:lines -- Set which nicknames cannot be used on that server. q:lines -- Set which server names are not allowed on the network (need to be set on all servers for things to work properly). R:lines -- OBSOLETE. A more strident system of checking for user access than K:lines. U:lines -- Define which servers are authorized to make changes to user and channel mode settings regardless of actual user status (restricted to services.dal.net on DALnet). Y:lines -- Specify how the server accepts and treats connections by setting up "connection classes". Z:lines -- Define which hosts (based on IP address) are not allowed to connect to the server at all. z:lines -- Define which hosts (based on IP address) are not allowed to connect to the server at all (settable by opers). 2.6 KILLS, KILLABLE OFFENSES ----------------------------- A kill is an IRC term for disconnecting a user from the network. Care should be taken so that nobody confuses this with real world killing. See the operator command /kill for more information, section 3.2.3. Killable offences are those breaches of DALnet rules for which an operator may use the /kill command to disconnect the user. For more information, refer to the section 6.5 on policy enforcement. 2.7 K:LINES, AUTOKILLS (AKILLS) -------------------------------- A K:line is a ban for a user or group of users on an IRC server. K:lining means adding a K:line, or in general terms banning a user from a server or the entire network. Permanent K:lines are added to the server's configuration file by the server's admin. Temporary k:lines (a lower case k is used for them) may be added by that server's operators on IRC, and it stays until the server goes down or a rehash is done (see the /rehash command, section 3.2.7). Autokill (commonly shortened to akill) is a Services feature to automatically kill any user whose address matches a mask in the autokill list. Additionally, Services adds a temporary k:line (shown with an "A:" heading with a "/stats k" command) on the server the user was using. Autokills can be set and removed by Service Admins and CSops, while the autokill list is viewable by all opers. Autokills are the key feature in keeping abusive people out of DALnet. For usage information, see section 5.3.4. 2.8 SERVICES IGNORES --------------------- Services ignore works just like a normal ignore: anyone in Services' ignore list gets ignored by Services (autokills, akick's and similar things are still enforced, though). Ignores can be set or removed by Service Admins (and above). Ignores are a less forceful way (than autokills) to deal with abusive people, and they are mostly used in cases of Services abuse. For usage information, see section 5.3.5. 2.9 MARKS ---------- Nicknames and channels registered with Services can be marked by CSops. The purpose of a mark is to show that the nick/channel has been looked over by another CSop and nobody else should touch it without talking to the person who placed the mark. It can be used in situations when a nick/channel ownership issue is complex or uncertain. For usage information, see section 5.4.3. 2.10 CLONEBOTS (CLONES, CLONING) --------------------------------- Clonebots (commonly shortened to clones) are a form of bots used to flood other people. Since IRC prevents you from sending more than one message every two seconds, in order to effectively flood someone you need to use more than one client. Clonebots are mostly quite easy to tell apart from other users because their nickname, username and ircnames are usually formed of random characters. There is no valid reason for having clonebots on DALnet, which is why they have been banned. See section 6.5.1 for how to deal with clonebots. Running clonebots is sometimes called cloning. Please note that having a second connection to the network is not the same as running clonebots! 2.11 IRCD ---------- ircd is the name of the IRC server program (it comes from "Internet Relay Chat Daemon", but spelled all lowercase according to unix tradition). It is used when talking of the actual server program, while "server" usually refers to the whole entity that a server running on DALnet is: the admin, server operators, link permission, etc. 2.12 LINKS ----------- A link is a connection between two servers. That's why the command to show all the server connections on the network is called /links (see section 4.1.1 for more information about the command). Another meaning for a link is as "permission to be linked to the network", as in all the DALnet servers have a link (to DALnet) while those servers which are applying don't have it (yet). A "delink" is the opposite of this, it means "not part of the network". 2.13 SYNC(H)S -------------- Synch (or sync) is short from "synchronization". On IRC the term is used to describe the act of exchanging data between two servers in order to synchronize the databases, so that both of the servers hold the same information about what users are online and which channels have been formed (known as "synching"). It's also used when describing the status of two connected servers which have finished synching and when they are working together seamlessly (known as "synched"). A resynch is when two servers connect to each other and synch after a netsplit. A desynch occurs when the servers on a network do not agree about the state of some nickname or channel. For example, a single desynched server might hold that a user has ops, while all the other servers see him/her as just a normal channel member. This means that the desynched user is able to kick and ban others seemingly without ops on the channel, for example. 2.14 JUPES ----------- A jupe (comes from "jupiter", a user's nick once of EFnet) is a fake connection that stops something else from connecting on IRC by taking their name/place. On DALnet, it usually means a fake server using another server's name, stopping the real server from connecting to the network. Jupes are used very rarely, and only as an emergency and temporary measure. 2.15 SENDQ, RECVQ (RCVEQ) -------------------------- The 'Q' in these comes from "queue". The sendQ is used by the server to buffer the outgoing (send) data, while the recvQ (receive queue, also sometimes written as rcveQ) stores incoming (receive) data from a client or server. There is a separate sendQ and recvQ for each client and server connection. Also, for server connections, the sendQ sizes may be different on each server, eg. server A's sendQ for the connection to server B may be different from the sendQ that server B has for its connection to server A. For clients, exceeding the receive queue is a possible sign of flooding, while exceeding the send queue is likely due to using a command which generated a lot of output (such as /list). For servers, exceeding the sendQ is a common symptom when a connection is broken, but the server doesn't receive an actual notification of the fact. The server will keep trying to send data through the link to the other server, until the sendQ overflows, and the connection is closed. 2.16 DALNET ------------ DALnet is a non-profit organization founded by Dalvenjah FoxFire and co-founded by MirclMax. It is an IRC network formed of independently run servers. The servers are ircd programs running on computers provided by various Internet Service Providers, computer (or other) companies, or educations establishments. DALnet does not pay or charge for running of the servers. The administration is formed of individual volunteers and computer system administrators from the organizations which host the servers. As a note about the name, it is -just- "DALnet", not "The DALnet", "DALNet", Dalnet", "DalNet", "dalnet", "dal.net" or any other variation. There also is no "the" before the name, unless you're speaking of the IRC network called DALnet, ie. the DALnet IRC network. It is JUST: DALnet. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 3. A NEW VIEW TO IRC ============================= - The new stuff There are quite a few things you need to learn in becoming an IRC operator. Very few of these are, in fact, new commands. There are 16 new IRC commands for operators, but you will likely need only 2 or 3 of these every day. Most of the new things are either learning when, where and how to use these new commands, and getting a more in-depth understanding of how IRC works. 3.1 IRC TECHNICAL OPERATION AND NETWORK STRUCTURE -------------------------------------------------- From the user end, technical specifics about IRC are nearly impossible to speculate on. However, as an IRC server operator you should know the underlying workings of IRC. Things can be confusing when you start, so this section is meant to explain the basic structure of an IRC network. 3.1.1 IRC TECHNICAL OPERATION ------------------------------ IRC, as you might already know, stands for Internet Relay Chat. IRC relies on a system similar to most all Internet communications relationships. A program called a client connects to another program called a server to send and receive information. For IRC, many clients have been developed for various platforms (Windows, unix, Macintosh, VMS). To list a few, ircII, sirc, SmallIRC, and TinyIRC for UNIX; Zircon for X-windows (X11); mIRC, pIRCh, CuteChat, Netscape Chat, WSIRC, and irc4win for Windows; and Ircle, Homer, and Global Chat for Macintosh. The server is a program called ircd. Currently all DALnet servers run on the unix operating system, although lately it has become possible to run an IRC server on a Windows NT system too. An IRC network is composed of servers that are connected to each other, some directly, some through other servers which are in between and relay the messages. The messages transmitted between clients and servers are described in a document called RFC 1459. 3.1.2 IRC NETWORK STRUCTURE ---------------------------- An IRC network is laid out so that there is only one possible route between any two servers, either directly, or by relayed connections through other servers. Perhaps the best way to visualise it is by thinking of a tree with branches. There are two types of servers, leafs and hubs. Hubs can connect to more than one other server, while leafs can only connect to one (which is known as the leaf's uplink). For example, the server glass.dal.net may not be _directly_ connected to the server gothic.dal.net; however, when one of them is connected to trapdoor.dal.net (a hub) and the other is connected to toronto.dal.net (another hub), which _are_ connected, then glass and gothic will also be connected. To clarify this, a diagram is provided below (which won't make much sense unless you read this text with a fixed width font): hub servers --> voyager <-> toronto <-> trapdoor | | | | leaf servers --> raptor gothic glass stlouis A netsplit occurs when a connection between two servers is broken. This might happen for many possible reasons: bad (Internet) network conditions (which is the most common reason), a problem with the computer on which a server is running, or an operator using the /squit command (see section 3.2.6 for the command's description). What happens in a netsplit is that the net splits into two sections. The users in one section appear to leave/quit the network as seen from the other section, and vice versa. If you are on a channel with a user who splits, the quit message will have the names of the servers between which the connection broke. It is important to realise that even though the users "seem" to sign off IRC, they are still connected to their server on the "other side" of the split. For example, let's consider a netsplit in a network which is laid out like in the diagram above. Say, the connection between voyager and toronto gets broken. All the users on both raptor and voyager are seen to "quit", as seen from all the other servers (toronto, trapdoor, gothic, glass, stlouis). And, similarly, users on voyager and raptor see all the users on the other servers disappear. IRC networks may also be laid out in a "star like" structure, which is not readily apparent from the first example. You can have a "central" hub which connects more than two other hub servers. These other hubs (as well as the central one) then hold leaf servers. The following example shows such a situation: hebron sodre \ / toronto | trapdoor -- spider / \ voyager quantum-r | | gothic ced In this figure, trapdoor is a "central hub", holding connections to the three other hubs (toronto, voyager, quantum-r) as well as the leaf spider. Toronto has two leafs (hebron and sodre), voyager holds gothic and ced's hub is the quantum-r server. IRC networks may be arbitrarily large; however long paths (routes from one server to another through other servers) are prone to lag and splits, which is why it is better to avoid long "chains" of servers. 3.1.3 IRC PROTOCOL COMMANDS ---------------------------- It might be necessary for you to know how to send "raw" IRC commands to the IRC server you are using. This is because not all clients support all the DALnet commands, and in such cases the command has to be sent directly to the server. Most IRC clients allow sending direct server command by prefixing them with the "/quote" command. In that case, the server command does not have the / placed in front. For example, to send a message to Nick, the server format would be "PRIVMSG Nick :message text", and the actual command to type would be: /quote PRIVMSG Nick :message text here It is usually possible to add an alias or script for these kinds of commands, and that is recommended. 3.2 IRC OPERATOR SERVER COMMANDS --------------------------------- This section lists and explains the IRC commands that an IRC operator may use. It is possible for server admins to limit and choose to some extent which commands and usermode are allowed for an oper, by specifying the appropriate O:line flags. The most common setups are "local operator" (ie. the oper cannot affect things outside his or her server, aka. "small o:line") and "global operator" who has access to all the commands (aka. "big O:line"), except those which require SA access (the +a usermode) to use. Your admin should let you know about any limitations there are in your O:line -- if you are unsure, ask. 3.2.1 /OPER ------------ /oper is the basic command for assuming IRC operator status. The syntax for the command is: /oper The nick you should give after the command should be your IRC operator nickname (or more technically, whatever was used in the O:line in the server's configuration file). The password is your operator password (for that O:line, passwords can vary from server to server and even depend on the address you are using). Some clients (notably ircII) or scripts allow to use a format where you only give the nickname. You will then be prompted for your operator password. This second format is recommended if your client/script supports it, because it is less prone to accidentally revealing operator passwords (for example, consider the difference between "/oper mynick" and "/oper mynick mypass", if the "/" is accidentally left out). It is not advisable to put your operator password in any scripts, as that increases the risk of accidentally giving it away (for example, when sending someone a copy of your script). When you oper successfully, the server will set the usermode +o for you, which means you are now an IRC operator. While you have the +o usermode set, anyone who does a /whois on you will see the text "* Nick is an IRC operator" (or whatever the message looks like on his/her server, it is possible for a server's admin to change it). Also, in any /who or /names list an asterisk ("*") will be shown after your nickname. You may remove the oper status by removing the +o mode with the "/mode -o" command, and some clients also provide the "/deop" command. In addition of the +o, the /oper command will also add the +s, +w, +g and +f usermodes for you. It is also possible to set the +h and +c usermodes, which are not available to normal users. See section 4.3 for an explanation of the usermodes. 3.2.2 /GLOBOPS, /WALLOPS, /LOCOPS AND /CHATOPS ----------------------------------------------- /globops is the command for sending globops-messages, which are only visible to other IRC operators. /wallops is the command for sending wallops-messages, which are visible to any user who is set usermode +w (more about this in section 4.3.3). /locops is exactly like /globops, except it only sends the message to local operators (those operators using the same server). /chatops is similar to /globops, except it goes only to those opers who have the +b usermode set. Normally, to send a globops, wallops, chatops or locops, you will use: /globops /wallops /locops /chatops Globops is a new DALnet command, and because of that your client might not support it directly. In that case it is recommended that you make an alias for it. The server needs to see a message of the form "GLOBOPS :message text", where the colon is required, see section 3.1.3 on sending commands directly to the server. Globops can be used to let other opers know about something or to ask a question or for an opinion. Globops should not be used to send messages which have nothing to do with the network. Asking for help with network related problems from other operators is ok, as is discussing things such as "Anyone dealing with clonebots from evil@site?". If someone else asks a question or makes a comment in globops and you want to reply, consider whether what you have to say is something that every other operator needs to see -- if not, make your reply in a private message. Longer discussions, especially those not directly relating to network status or use should ALWAYS be taken to a channel. Also, anything that could be expressed on the mailing lists, should be. Wallops are an alternative to globops. When using them you should keep in mind that they can be seen by users, in particular avoid any security-related topics. Users who are interested in "what's going on in the net" will likely have +w set. While globops require that an oper is opered to see them, wallops do not. Thus, wallops messages are a good way to make small "announcements" and the like. They could be used to announce rerouting, a server going down, etc. Locops is a new command, like globops, and most of what applies to globops applies to that too (the server format is "LOCOPS :message text"). The appropriate use of it on each server is up to the admin. Chatops are a free chat medium for operators, created in order to free the globops from idle chat and other inappropriate use. You need to have the usermode +b set in order to send and receive chatops (see section 4.3.11 for more information on +b). There are no specific established rules for chatops, but same good behaviour guidelines as for channels do apply. Admins may choose to disable the use of the /chatops command on their server. 3.2.3 /KILL ------------ A /kill will disconnect another user from the IRC network. The format of the command is /kill Unlike with the /kick command, you must give a reason. It should be matter-of-fact and describe why the user was disconnected, for both the user getting disconnected and other operators and users who might see it. A kill will "track" a user if the user has recently (within 90 seconds) changed nicknames, this is known as "kill chasing". You must ALWAYS warn before a /kill, preferably more than once. In non-critical situations you should warn the user at least twice. In all cases this might not be possible, but if it is - do it. You should also attempt to use other ways to deal with a user before using a /kill. Consult the DALnet Policies and Procedure guide (or your admin or trainer) for what is and what isn't allowed on DALnet. Breaking DALnet rules is usually a killable offence, after multiple warnings have been given. An exception in the "always warn" policy is when disconnecting mass-messagers (this covers all mass-messages and mass-invites, whether they are done with /msg, /notice or /invite). Mass-messages usually originate from some sort of script or bot, and as such the user who is responsible is not likely to see any messages sent to him/her/it. A /kill may NEVER be used for personal reasons. Doing this will result in the loss of your O:line or other sanctions. If vulgarity appears in the kill message you leave yourself open to be autokilled. It is not acceptable to kill any type of user with a kill message that is unprofessional containing long strings of swears or other types of vulgarity. 3.2.4 /KLINE AND /UNKLINE -------------------------- IRC operators may temporarily K:line a user or user mask from a particular server. This is the last resort and is the most powerful defensive system available to any IRCop without the help of Services in protecting DALnet from repeat offenders or harmful bots. A k:line will both stop new connects from the specified mask as well as disconnect all users matching that mask (on that server). /kline is (again) a new DALnet command, so your client will probably not have direct support for it. The server needs to see a message of the form "KLINE :" or "KLINE :", see section 3.1.3 on using server commands directly. If you give a nickname, the server will set up a mask for the k:line based on the user's current address. As a note, you specifically can NOT kline a full nick!user@host mask. The /unkline command can be used to remove temporary k:lines. The format is exactly the same as above, with "unkline" replacing "kline", and no reason given. The removal will only work if the mask is exactly the same which was used when the k:line was added, use /stats k to view the addresses. The key limitation in a local K:line (or, in this case, k:line) is that it's server specific -- the user in question may freely connect to another server even though they are K:lined on another. Thus in most cases an autokill is much more effective. However, there are some situations in which placing a local server k:line can be useful: - If an unauthorized bot keeps connecting over and over again to the server. - If there are a lot of clonebots from the same address connecting, placing a local k:line might help the situation. - If Services is lagged or down, local k:lines can become very useful. - Placing autokills requires Service Admin access to Services, and if you can't find a SA or a CSop to help you, your only choice is to try to use kills and local k:lines. - Other special situations In some cases it may be better to use a temporary z:line instead (see section 3.2.12), for example if there is a flood of connections coming to the server from the same host which are all getting stopped by a K:line. You can view the current list of K:line with the command /stats k. Lines beginning with a capital K are permanent K:lines (added by the admin), lines beginning with a small-case k are temporary k:lines, and lines beginning with an A are autokill-K:lines, added by Services. If the server has any Z:lines or z:lines (temporary Z:lines), they will be shown also. Doing a /rehash will remove all temporary and autokill K:lines and temporary z:lines on that server. Use of /kline and /unkline may vary depending on the server. Check with your admin on the appropriate use of these commands. As a further note, do not send any email to the Kline Team about locally added /kline's unless it's a part of some other report. 3.2.5 /CONNECT --------------- The /connect command is used to connect servers. It is the most complex operator command, along with /squit. Because of this its explanation has been divided into 6 subsections. 3.2.5.1 /CONNECT OVERVIEW -------------------------- This command is used to connect (or re-connect) servers. You can use it to "bring back" a missing part of the network, or if you are on a single split server, the whole missing network. If you are on the main net you can, of course, also use it to bring back a single server. Although the command to connect the two servers is simple enough, what those servers are connected to in turn (if anything) is something you need to be aware of. There are always two servers involved in making a /connect: the server attempting the connect (also called the "originator"), and the "target" server (the server which is to be connected to). For two servers to be able to connect to each other, they need to have exchanged C/N lines. (The C/N lines hold configuration information for making the connection.) It doesn't matter whether you yourself are on a hub or a leaf, your goal is to connect the network visible on your server to the rest of the network which is missing. The TARGET is the missing network! When using /connect, the target server must NOT be on the network as seen from your point of view. This means it should not be currently visible if you do a /links list. Otherwise the connect attempt will fail with a "server already exists" error. This is explained in greater detail in chapter 7 on rerouting. The results of connect attempts are displayed as server or globops messages, so you should make sure you have the usermodes +s and +g set when using this command. 3.2.5.2 /CONNECT SYNTAX ------------------------ The syntax for the /connect command is as follows: /connect [ []] The details inside the [] are optional. If the fromserver is not included, it is known as a "local connect", where the server you are currently using is the originator. 3.2.5.3 /CONNECT USAGE ----------------------- Remember that what you are trying to do is connect a server on your side of the net, to a target server on the other side of the split. In addition to the target server's name, you need to give a port number to connect to (7325 on DALnet) and the connecting server's name as well. The command for this is: /connect targetserver.* 7325 fromserver.* In this case, you are attempting a connection between "targetserver.*" and "fromserver.*". If you leave out the second server name, it's exactly the same as if you used your current server's name (making it a local connect attempt). DALnet uses 7325 as the port number for connections between servers. Some servers occasionally use other ports, in which case the admin of the server is responsible for informing anyone who needs to know of such a setup. When specifying server names in a /connect command you can either use the full server name (eg. "/connect voyager.ca.us.dal.net"), or wildcards (eg. "/connect voyager.*"), but it is important to avoid masks which are too short as these can lead to potential problems. For example, "/connect ar*" could be either armory or arpa-r. If you always give the name up to and including the first dot, then there is no problem ever on DALnet. 3.2.5.4 A SCHEMATIC EXAMPLE ---------------------------- Suppose the network was split as in the following diagram, with the connection between voyager and toronto down. ___________ x ___________ ____________ | | x | | | | | voyager | x | toronto | <-> | trapdoor | |___________| x |___________| |____________| | x | | | raptor x ced glass stlouis The connect command you would need to fix this split depends on which server you are using. If you are on voyager, you can simply make it a local connect: /connect toronto.* However, if you are on raptor, you would need to use a remote connect to make voyager attempt to connect to toronto: /connect toronto.* 7325 voyager.* If, on the other hand, you are on the other side of the split, you would need to instruct toronto to try to connect to voyager. On toronto a local connect to voyager is enough, but on any other server the correct command would be: /connect voyager.* 7325 toronto.* 3.2.5.5 GLOBOPS NOTIFICATION ----------------------------- You should always send a globop about your intentions before issuing the /connect command. This allows other operators to know what you are doing and, if necessary, comment on it. It also ensures the coordination in the connect attempt. Uncoordinated multiple connects may result in chaos. See chapter 7 which discusses rerouting in more detail. 3.2.5.6 FINAL NOTE FOR /CONNECT -------------------------------- The problem with /connect's is that while the connect attempt can be satisfactory, the results might not be! Either a connection won't be made, or it will be slow and perhaps split soon after. The reason is that most manual /connects are done in times of bad network conditions and at better times there is no need for them as things usually run smoothly. See section 7.5 for more details on what can go wrong. 3.2.6 /SQUIT ------------- The /squit command is the opposite of /connect: it breaks (disconnects) a connection between two servers. The name comes from "server quit". The usage of the command is: /squit You may give the name of the server in the form of "server.*", just make sure there is only one server which matches the "mask". The reason is optional, but you should always consider giving one so that others who see the squit know why it was done. When issuing the command, you give the name of the server you want to disconnect from the network. If this server happens to be a hub, all the other server connections that it might have will stay intact (i.e. all the servers that the hub holds will "go with it"). Squits always work relative to where you are connected yourself. Thus, before you use the /squit command, it is EXTREMELY important that you understand the IRC network structure (see section 3.1.2) and know the current layout of the network, viewed with the /links command (see section 4.1.1). This can be best illustrated with an example. Let us use the sample network layout from before: voyager <-> toronto <-> trapdoor | | | | raptor gothic glass stlouis The command "/squit toronto.*" will disconnect a different link, depending on which server you are connected to when issuing it. If you are on glass, stlouis or trapdoor the result would be that the connection between toronto and trapdoor gets squitted. If you are on gothic, the link between toronto and gothic is disconnected. Finally, if you were on raptor or voyager, the affected connection would be that between voyager and toronto. (As a curiosity, if you are actually using toronto when you /squit it, this will disconnect you from the server.) If you wanted to disconnect the link between voyager and toronto, and you are currently using voyager or raptor, the correct command would be: /squit toronto.* However, if you were on toronto or any of the other servers, the command would instead be: /squit voyager.* Like connects, squits should be announced in globops (and perhaps in wallops as well) so that other operators have a chance to give input and opinions before you act. In most cases, a /squit should always be followed by a /connect to reconnect the disconnected server somewhere else. This act is known as rerouting, for more information about this see chapter 7. The same chapter also has information on when and how you should use this command. Finally, a /squit should NEVER be used for unofficial or personal reasons. 3.2.7 /REHASH -------------- This command makes ircd reload its configuration file. This needs to be done whenever the server admin changes information in the file and needs to reflect these changes within the running server. Rehashing will clear any temporary and autokill K:line's not permanently set within ircd.conf. /rehash is used without any extra parameters. 3.2.8 /RESTART --------------- /restart restarts ircd. This command is similar to /rehash because it updates any changes that are made in the configuration file, except it reloads the program too. Like with the /die command (below), all users (and servers too) are disconnected. It is possible that the server admin has set up additional password to use this command (via an X:line). If so, you will need to place the /restart password after the command for it to work. Normally you do not need to use this command, like /die (below). 3.2.9 /DIE ----------- /die stops the server. Sweet and simple, DO NOT USE THIS COMMAND. It is possible that the server admin has set up additional password to use this command (via an X:line). If so, you will need to place the /die password after the command for it to work. If your client supports aliases, I STRONGLY RECOMMEND you replace DIE with an alias so that you don't accidentally use the command. Here is an example: ircII: /alias die echo *** If you're sure you want to use die, use: /terminateserver /alias terminateserver /quote die mIRC: /alias /die /echo *** If You're sure you want to use die, use: /terminateserver /alias /terminateserver /quote die Pirch: Alias Die: Type /terminateserver if you really want to do this. Alias terminateserver: /quote die Feel free to replace /terminateserver with any extremely long command that cannot be typed too easily or accidentally. Also make sure that your script, if you have one, does not have this command. There is no circumstance under which that would be needed. If you ever need to use the command, you may type it manually. Should the server admin not be available for consulting on an emergency situation, you may be forced to use this command to stop your server from continuing to malfunction (should it be badly afflicting DALnet). However, under normal circumstances, unless you are asked by your own admin to use this command, do not use it (in all likelihood, the admin of the server will use it himself if not kill the process from his shell prompt instead). /die will disconnect all users using the server (including you) from IRC, you will have to reconnect to another server. 3.2.10 /CLOSE -------------- The /close command closes all "unknown connections" to the server. It's useful only in very rare occasions, mainly if someone is using unregistered (not properly logged on) clients with malicious intent, such as filling up the server. See the /trace command for a way to list the unknown connections (section 4.1.4). 3.2.11 /SAMODE --------------- The /samode (SA mode) is the ircd counterpart to the OperServ's mode command (explained in section 5.3.1), which is available to Service Admin and higher access. It can be used to set any mode on a any channel. The command is used like the normal /mode for channels, however channel ops or even presence on a channel is not needed to change its mode. Only opers set as Service Administrators (usermode +a, see section 4.3.9) may use this command. Same guidelines as for the OperServ mode command apply, the instances in which this command should be used are VERY rare. See section 6.5.7 on how to deal with channel matters for more information. 3.2.12 /ZLINE AND /UNZLINE --------------------------- The /zline and /unzline commands can be used to add and remove temporary Z:lines, much like /kline and /unkline do with temporary K:lines. The difference is that Z:lines only work for IP-addresses, not hostnames. You also cannot use a username (ident). Similarly as with /kline and /zline, /zline and /unzline are new DALnet commands so you need to follow the instructions in section 3.1.3 on sending commands directly to the server. The usage of /zline is "ZLINE :comment text". You may also specify a username part, but this will get always changed into a "*" in the mask. The /unzline command is used to remove temporary z:lines. The usage is predictably "UNZLINE ", where the mask has to be exactly the same as given in the original /zline command. Use the "/stats k" command to see the current list of z:lines on the server. Adding z:lines is mostly useful in cases where there is a huge number of repeated connect attempts from some host, which are all stopped by a local K:line on the server. Adding a z:line will make these connection attempts invisible and make ircd do the least amount of work when dropping these connections. Caution should be used when using z:lines. Consult your admin to find out the policy on use for your server. This command is only available for Service Administrators, ie. those operators who have the +a usermode set (see section 4.3.9). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 4. SOME IRC FEATURES FROM AN OPERATOR'S VIEW ===================================================== - It does that too? This chapter discusses some old and familiar commands which gain a new significance for operators. All of these commands are available for all users of IRC, however they may not yield any interesting information for non-operators. Some of them have extended usages available only for opers. 4.1 NETWORK STATUS ------------------- The following commands are very useful in determining the network's current status. 4.1.1 /LINKS ------------- The /links command is the fundamental tool in determining how the network is currently set up, which servers are connected where, etc. It is available to all users, even though it's only meaningful to those who are interested in the current network layout. The command (in the basic form, without scripts) shows every server-server connection on the network. The output of the command varies between different clients. Additionally, you can get scripts to modify how the output is shown. Therefore it is very difficult to give an explanation here of how to read the list shown with the command. 4.1.2 /STATS ------------- Stats is a command for retrieving server status and configuration information. Despite the name, there is more than statistical information available with this command. The available information is divided to two categories, server configuration information (the various server "lines") and server state information. For both of these the basic usage of the command is the same: /stats [server] The is a single letter which determines what kind of information is shown, see below for a reference table. You may specify a remote server from which the information is shown. (Note that the info will then be requested from that server, so the output is affected by lag and other network conditions.) If you leave out the server, the current server is assumed. You may also specify a nickname instead of the server, in which case the information comes from the server which has that nickname's connection. There is a special case with the "/stats l " and "/stats L " commands, which actually show connection statistics for that client connection. Server configuration lines: /stats c -- C:lines, N:lines /stats d -- D:lines, d:lines /stats h -- H:lines /stats i -- I:lines /stats k -- K:lines, k:lines, autokill k:lines (shown as A:lines), Z:lines /stats n -- C:lines, N:lines (same as /stats c) /stats o -- O:lines, o:lines (these may not be shown for non-opers) /stats Q -- Q:lines (note, capital Q only) /stats U -- U:lines (note, capital U only) /stats y -- Y:lines Note that there might be no response if there are no such lines, especially if the client hides the "end of /stats report" messages. Server statistics: /stats l -- connection stats (with user's resolved hostname if available) /stats L -- connection stats (with user's username, IP address, and also the connection port if opered) /stats m -- command usage counts / data received for each /stats q -- Q:lines introduced by Services /stats u -- server uptime and highest connection count /stats t -- debugging statistics /stats w -- usage statistics /stats x -- shows missing servers (based on the server's C:lines, use on hubs, eg. "/stats x hubserver.*") /stats z -- internal ircd memory usage statistics This is a table explaining the l/L report output fields (in the order they appear on the line). It's a bit hard to read in the raw format, so getting a script to present it in a nicer and more readable format is recommended. In any case, the most important number in each line is usually the sendQ, which appears right after the connection name. link name -- server name/nickname, with IP/hostname inside [] sendQ -- current sendQ size for the connection, in bytes sent messages -- number of sent (IRC protocol) messages sent kilobytes -- amount of data sent, in kilobytes received messages -- number of received (IRC protocol) messages received kilobytes -- amount of data received, in kilobytes time connected -- time the connection has been up, in seconds time idle -- time since a message was last received, in seconds (this is the same number as seen with /whois, so it doesn't count notices and other commands) The only difference between "/stats l" and "/stats L" is in the link name field, which shows slightly different information. The l/L information is perhaps the most useful report, so here are a few tips on using it: 1. It is very important for routing purposes, when used to view server connections. It shows each connection's sendQ value which can be used to determine if a link is failing or not, and monitoring the progress of a resynch. The idle time also shows "dead" links, since server connections should always have very low idle times, if not 0. 2. The "/stats l " report shows both the idle time as well as the number of received messages and amount of received data. If the user is not idle and is sending out a lot of messages or a lot of data, this could be an indication that he/she is flooding. 3. The "/stats L " report shows the real IP address of the user, in case he/she is DNS-spoofing. This can be used to trace the user later. Make sure to get an exact timestamp of when the user was online, so the ISP can determine which user was doing it. For those of you who are interested, here are explanations for the m, t and w reports, which aren't really useful in general for opers. The rest of you can skip to the next section. The output for "/stats m" looks like this: *** PRIVMSG : 343262185 540850796 *** NICK : 20727440 1353933315 ... and so on. The first number is simply the usage count for the command, and the second is the total amount of data that has been received with these commands. After 4GB the counter will wrap, which is why in that example the figure for PRIVMSG's seems so low, only 540MB. :) The output for "/stats t" looks like this (the explanations are mixed in): *** accepts 4876 refused 3368 This lists the number of accepted/refused connections. *** unknown commands 1012 prefixes 142735 This lists the number of unknown commands and commands with unknown prefixes. *** nick collisions 15102 unknown closes 3869 This lists the number of nickname collisions and connections which have been closed while they still were unknown (before "registering" as a user/server). *** wrong direction 62862 empty 0 Number of "Fake Directions" and completely empty messages. *** numerics seen 8235520 mode fakes 0 Number of numerics and hacked mode changes. *** auth successes 1465 fails 3676 Number of successful/failed ident lookups. *** local connections 0 udp packets 0 *** local connections 0 udp packets 0 Local connection information (never really used nowadays). *** Client Server The following lines have two entries, one for client connections and one for server connections (this is the header line). *** connected 805 571 Number of client/server connections since server startup. *** bytes sent 583143.566K 69452344.481K Total amount of bytes sent to client/server connections. *** bytes recv 71013.1003K 30203172.317K Total amount of bytes received from client/server connections. *** time connected 15209310 14566469 Total amount of accumulated connection time, in seconds. The output for "/stats w" looks like this: *** Minute Hour Day Yest. YYest. Userload for: *** 2.00 2.0 2 2 2 irc.rift.com clients *** 8.00 8.0 8 8 8 total clients *** 15.00 15.8 15 16 12 total connections This shows the average number of local clients/clients/all connections for the past minute, the past hour, the past day, yesterday, and the day before yesterday. 4.1.3 /VERSION --------------- The /version command shows the client and server version information. You can also do this command "remotely" on a server, by giving the server name or a suitable mask (usually, "server.*") after the command. When used remotely it's possible to use this command to check for lag between you and the specified server, because the reply message gets sent from the other server. If you use the command and there is delay before you get a reply (or there is no reply at all), it is an indication of lag. You may use multiple /version commands to different servers to try to pinpoint which link is the lagged one. Also do more than just a single check for lag, so you can tell if the situation is getting better or worse. 4.1.4 /TRACE ------------- There are two different uses for the /trace command. 4.1.4.1 /TRACE ---------------------- The more important use for /trace is when you specify a nickname after the command, in which case you will be shown a "route" of all the servers between you and the user whose nickname you gave. The usage is in this case: /trace All the lines you will see originate from different servers (from each server along the route), which means that this command is very useful when trying to pinpoint lag. Unfortunately different clients show the command's output differently, so the example output given here might differ from what's shown on your client. Suppose that there are four servers connected, A <-> B <-> C <-> D JoeOper is on server A, while JaneUser is on server D. JoeOper gives the command "/trace JaneUser", and sees the following output: *** Link dal4.4.12 JaneUser B.dal.net *** Link dal4.4.12 JaneUser C.dal.net *** Link dal4.4.12 JaneUser D.dal.net *** Server 0 0S 0C D.dal.net *!*@D.dal.net 25081034 Each of those lines is actually sent by a different server along the "route" from JoeOper to JaneUser. The first line is sent by the server A, the second line is sent by server B, and so on. This is somewhat confusing, because those Link lines are composed as follows: *** Link For example, in the first line "dal4.4.12" is the version for server A, and "B.dal.net" designates the NEXT server. The message might mislead to think that it originated from server B and server B's version is "dal4.4.12" (which it is, in this example, but that is not shown until the next line). If JoeOper is opered, the last line shown will instead be something like this: *** User 6 JaneUser[dialup0.isp.net] 0 The 6 is the connection class for JaneUser on the server D, and the 0 in the end is the current sendQ for her. Alternatively, if JaneUser is an oper, the first word would be "Operator" instead of "User". (Connection class means the "type" of the connection, as set up in the server's Y:lines.) The nickname tracing functionality is available to all users, not just IRC operators. 4.1.4.2 /TRACE ------------------------ The second form of the command is used to list connections to a specified server. Operators can see all connections, while normal users only see operator connections (current opers on that server who aren't set invisible). If you do not give any arguments, the local server is assumed. When used in this way, the command's usage is: /trace As usual, you may use "server.*" instead of the server's full name. This method will show all the connections to the specified server, including servers, operators, users and "unknown" connections. Here's what the output (for opers) is composed of: *** User Nick[user@host] *** Operator Nick[user@host] *** Server S C Normal users see just the operator connections (invisible (+i) opers are not shown, though). Unless you have a script to filter out user connections, this form of /trace is not very useful, except when used on hub-only servers which do not have many clients. 4.1.4.3 USES FOR /TRACE ------------------------ The uses of /trace might not be readily apparent from the description. The more often used function is with the first form, when used on a nickname. Since each of the lines you see are sent by each server along the "route", this is an effective way to pinpoint lag. For example, if you use a command such as /trace JoeUser, and might see output like this: *** Link dal4.4.12 JoeUser toronto.on.ca.dal.net *** Link dal4.4.12 JoeUser voyager.ca.us.dal.net And then, nothing else. This means that there is lag between toronto and voyager (remember that that last line comes from toronto, and that voyager.ca.us.dal.net is the "next server"). The rest of the output will follow eventually later, when your command gets to voyager and other servers (if needed), except unless the lag was due to the link failing and a split happens between toronto and voyager. The other uses of /trace are not needed so often. By using the server-form and listing all the connections on a server, you can see all the unknown connections to a server. Unknown connections are (usually) clients which haven't yet registered (sent a nickname and user info). However, if there are a lot of them and from the same host/IP address, it can be a sign of malicious activity against the server. Another thing to remember is that you can see the sendQ values for the nickname/server when doing a /trace, and this is a way to monitor them. Usually using "/stats l" is better, though. Finally, non-opered clients may use "/trace " to list all the operators on that server. This is one way of finding IRC operators. However, it's generally preferred that the /who command would be used instead (for example, "/who 0 o", "/who ** o", "/who -oper" or "/who o", depending on your client and what exactly you want to see). 4.1.5 /LUSERS -------------- /lusers (short from "login users" or "list users") will show the current number of users on the network and on your local server, the current number of channels, the number of operators and the current number of servers connected to the network and the local server. This information can be very useful to an oper at times. First, the number of servers is a good indication of whether there is a netsplit or not. Second, if you do a few /lusers commands and the user count is rapidly rising, that might mean there is currently a resynch in progress. If it's rapidly decreasing, it might mean there's a netsplit in progress. Third, for IRCops on hub servers, the number of servers connected to the local server can be very useful in estimating its load. You should note that the channel count does not normally include secret channels, but for opers it does. 4.2 OTHER COMMANDS ------------------- The following commands have extended use for opers beyond what normal users can use or see. 4.2.1 /HELP AND /HELPOP ------------------------ The /help command is part of the experimental HelpOp system. Since the /help command is used by many clients to access their own help features, there is an additional alias for this command, /helpop. It's also possible to use /quote help. The HelpOp system is being designed to provide better help for users. Any user may use the /helpop command to send a help request. The server looks in it's own database to see whether the user's message/question matches any help topic it knows about. If not, the question is forwarded to all the HelpOps (users who have the +h usermode set). If the message is prefixed with a '?', it is never passed to HelpOps, even if the server cannot find an appropriate help topic. The opposite behaviour happens if the message is started with a '!', in which case it's always sent to the HelpOps regardless of the content. To get an index page of what online help pages are available, use just plain /helpop with no parameters, or /helpop index. Since the HelpOp system is under developement the contents may change, but currently at the time of writing this all the Services help pages and some documentation on the new DALnet ircd features are available. If the command is used by a HelpOp, the message gets sent to all the other HelpOps automatically. This can be used by HelpOps to discuss and coordinate helping users who send requests. 4.2.2 /NOTICE AND /MSG ----------------------- DALnet's ircd supports extra formats for sending notices (and messages) to channel ops, and channel ops and voices. To send a notice to only the ops of a channel, use the format: /notice @#channel message text And for both ops and voiced members: /notice @+#channel message text These are strongly recommended to be used rather than any client-side solution, as those may result in the user triggering the ircd flood- and spam-message limitations. There is no danger when using these new notice/message formats. These can also be aliased/scripted on most popular clients, and this is recommended. IRC operators have the additional possibility of sending global notices (and messages, but that is not usually done). The recipient group can be specified by either as users on certain servers or users with a certain address. To send a notice which goes to all users on servers which match a given mask, use the format /notice $ So, in order to send a full global notice to all users online, you can use: /notice $*.dal.net Or to send a message to users of a particular server (for example, orion.fl.us.dal.net), you can use: /notice $orion.fl.us.dal.net To send a notice which goes to all users whose address matches a given mask, use the format /notice # Users who receive a global cannot usually tell that it is a global notice or a server/domain notice (as opposed to a private one), so you should indicate this in the message. You should also politely request that no replies are sent, or you might get flooded with replies. Another good idea is to use the nick "DALnet" to send global notices. This cannot be used by those attempting to fake global messages as the nick DALnet is Q:lined on all servers, and it lets those who do not want to see global notice ignore that nick. For example: /nick DALnet /notice $*.dal.net [GLOBAL NOTICE] Services (NickServ, ChanServ, MemoServ) are going down for an upgrade. They will be back up in 5 minutes. We apologise for the inconvenience. (Please do not reply) /nick This procedure can very easily be adapted to make an alias or automatic function with your client (just be careful with it!). Views vary on just what exactly is important enough to warrant a global. If you are considering a global, you should ask yourself whether the issue really concerns all the thousands of DALnet users. Excessive use of globals annoys some users (and opers). What's more, it devalues them -- users will simply ignore them. Before you do send a global, ask for opinions in globops. Also send the message you are planning to send as a global notice into globops first, to allow others to check it for spelling and other mistakes, and a chance for them to comment on it. A good possible alternative to globals is using wallops, see section 3.2.2. In addition to global notices, it is very easy to send server notices. These can be used if the information is relevant only to the users of one, single server. For example: /nick DALnet /notice $vogon.se.eu.dal.net [SERVER NOTICE] vogon.dal.net is going down due to server reboot, it will be back up in a few minutes. Apologies for the inconvenience. (Please do not reply) /nick 4.2.3 /WHO ----------- When opered, you will be able to see the normally invisible users (clients which have the +i usermode set) with the /who command. Such users will have the percent sign ("%") shown after their nickname in the /who list. Usually someone being invisible means that they do not want to disturbed. Be discreet and do not approach anyone +i unless you could have "found" them by other means (for example, you are in the same channel with them), or unless you are going to talk to them in your role of IRC operator. Never reveal information about such users to anyone, except to other opers (in the case of abusive users). This access is only given to opers so they can detect clonebots and abusive users who set themselves +i and change nicks in order to escape attention from opers. It should not be used to, for example, spy on anyone, or to find people in hiding for their "friends". If you've not used the /who command a lot before, here's some advice: You can use wildcards with the command, and it will look for a match in EACH of nickname, username, hostname, ircname ("real name") and servername. So if you give a command such as "/who user@someisp.net", it will not show any users because there is no user who has "user@someisp.net" in their username or hostname. If someone's email address would be that, and he/she had placed that in the ircname field, then that person's information would be shown though. To look for users from a particular site, you would use a command such as "/who *someisp.com". You could also give an exact hostname, without the wildcard. A command of "/who *joe*" will list all users who have "joe" anywhere in their nickname, username, hostname, ircname or in the servername. A "/who *.net" would list ALL users on DALnet, not just those coming from ".net" addresses, because all the server names end in ".net" (it's not a good idea to try this *grin*). As an example, here's what a /who output might look like: * NetMaiden H* beth@ppp36.terrigal.net.au :3 Be good & play fair #DS9 RunAbot H@ runabot@dt9h2n97.san.rr.com :1 On the edge of IRC... #Macadamia Worf H@ sj@bell.maths.tcd.ie :1 sj@earthling.net #torhelp MSofty H@% mark@irc.rift.com :0 Mark Salerno * Wizzu H mihannin@delta.hut.fi :2 Mikko Hänninen, a wizard What each of those lines shows:
: The sections which might need more explanation are: status -- the different characters show the client's status: H = here (not away), G = gone (away), @ = op on the channel, + = voice on the channel, * = IRC operator, % = invisible hops -- the number of "hops" between your server and the other server, 0 means that user is on the same server as you, 1 that it's a server connected to yours, 2 that there's one server in between, an so on Some clients also display the server for each of the shown users. 4.2.4 /MOTD AND /ADMIN ----------------------- The /motd command is useful for finding information about a server, its staff and special policies it might have. MOTD stands for "Message Of The Day", although it's rarely updated daily. Used alone it will show the MOTD info for the local server. If you add a server name (full name, or a "server.*" mask) after the command, the MOTD for that server is shown. There is nothing new in /motd for opers, but it deserves mention as a possible tool for opers to get information about a server. The /admin command works similarly. The only difference is the text shown, the server admin's contact information. /admin 4.2.5 /SILENCE --------------- Silence is an IRC command originating from the Undernet server code, yet it is still not widely supported by different IRC clients, and most users do not know about it. It is basically another form of /ignore, but which stops the messages from a given user at the SERVER, before they reach the client. This only affects private messages, channel messages are still shown. It is mentioned here so that opers would know of it and in addition to using it themselves can teach other users to use it. The command is used as follows: /silence [+]user@host Add the user@host mask to the silence list (*!user@host) /silence -user@host Remove the user@host mask from the silence list (*!user@host) /silence +nick Add nickname based silence (nick!*@*) /silence -nick Remove a nickname based silence (nick!*@*) /silence List the current silence list for you /silence nick Show the silence list for the given nick It is possible to use wildcards as needed in the silence mask. You may need to use the /quote command in front of the silence command if your client does not understand /silence, as explained in section 3.1.3. There is a maximum of 5 silences at one time (on DALnet). Also, a drawback is that you cannot specify the types of messages which are filtered (like you can with /ignore on many clients), rather all private messages from the specified nick/mask get suppressed. 4.2.6 /NICK ------------ You may wonder what new features such a familiar command as /nick has. Well, it really doesn't -- but when you are opered, you may also switch to Q:lined nicknames, like "DALnet". 4.3 USERMODES AND SERVER MESSAGES ---------------------------------- As you might already know, on IRC each user may have "modes" set, just like with channels. Some of these usermodes are available to all users, while others on DALnet are reserved only to IRC operators. Usermodes can be thought of as "settings" for the user, and remain even if the nickname is changed. Usermodes can be changed with the /mode command: To set /mode + To remove /mode - The rest of this section will explain all the usermodes that are significant for opers. The other usermodes are +i, +r and +R. The +i usermode ("invisible") -- when set -- generally stops the user from being visible in a /who or /names list. The +r and +R usermodes can only be set/unset by servers and Services, they are not controllable by users. +r means that the user is using a registered nickname and is seen as a valid user for it. The +R usermode is not yet operational, it is used to indicate password identified clients. If you set the usermodes mentioned in the following it means that you will see additional information (sometimes a lot of it) not usually seen by normal users. It is a good idea to set up a separate "operator window" with all the operator messages going there, instead of getting them mixed with regular IRC messages. 4.3.1 USERMODE +o ------------------ IRC operator status is actually designated by the +o usermode. Unlike other usermodes, it is set by using the /oper command successfully (you need to be on a server with an O:line for you, and use the right nickname and password as well as your current address must match the mask specified in the O:line). You cannot use the normal form "/mode +o". The +o is otherwise a normal usermode, and as such will remain with you even if you change nicks. You may "deoper" (remove the IRC operator status) by using the normal "/mode -o" command. While you have the +o usermode set, anyone who does a /whois on you will see the text "* Nick is an IRC operator" (or whatever the message looks like on his/her server). Also, in any /who or /names list an asterisk ("*") will be shown after your nickname. 4.3.2 USERMODE +s ------------------ The usermode +s indicates that the client will receive server messages. There are many varied server messages, too many and different to list here. This is the basic "administrative information" usermode on IRC, since it controls seeing most normal server and network status or information messages. A lot of the messages (for example, many of the Services kills) might not be something you really want to see, and which just make the things you are interested in seeing that much harder to see. It is possible to come up with "filters" for limiting the type of messages you see, and indeed many operators use such scripts. However, you should be careful not to filter out any important messages. The +s usermode is available to all users, but opers will see some additional messages with this mode. 4.3.3 USERMODE +w ------------------ The usermode +w means that you will see wallops-messages. Currently there are no automatically sent server or network wallops on DALnet, all of them are sent by opers. The +w usermode is available to all users. It is assumed that users who are interested in "what's going on in the net" will likely have +w set, while other users won't. As an oper it's a very good idea to have the +w usermode set always when on DALnet, even when not opered. Wallops are, on DALnet, means of "announcing" network/server matters to interested users (those who have set themselves +w) and communicating about these issues between opers. When using them you should keep in mind that they can be seen by normal users, in particular avoid any security-related topics (discuss these in globops instead). Wallops should not be used for chatting among operators, join a channel for that. 4.3.4 USERMODE +g ------------------ When you have the +g usermode set, you will see the globops messages. Many server/network messages are sent as globops, in particular server connection status notices (connection broken, connection established, etc.). For those people who both have the +g usermode set and are opered, the oper-only globops messages will be displayed. The +g usermode is available to all users. It is a good idea to have the +g usermode set at all times, so that you can monitor network activity as well as see the globops sent by other operators when opered. Globops are a secure means of communication for IRC operators. They are meant for discussing any network issue, although extended chats should be taken to a channel or discussed on a mailing list. Personal messages such as greetings are not allowed. For more info, see the explanation of the /globops command (section 3.2.2). 4.3.5 USERMODE +c ------------------ The +c usermode means that you will see client connect and exit notices for your server. These can be monitored for suspicious connects or exits, for example clonebots connecting or users disconnecting with the "Excess flood" message which indicates a possible flooder. The mode is also sometimes useful for debugging purposes. The +c usermode is only available to opers. If you deoper, this mode will be turned off. For most servers the number of client connects and exits is so large that any monitoring is next to useless (try it); because of this IRCops generally don't use this mode except in special occasions. 4.3.6 USERMODE +k ------------------ The usermode +k controls whether you will see server originating kills or not. These include mostly nickname collision kills and the like, and some kills done by Services. Watching nickname collisions can be a valuable tool for an operator. When things are running well, there are never more than few collisions per minute, and when things are not running well seeing the collisions and checking the servers that are causing them is a good way to find problems. This is an especially good way to find bubble lag between servers. The +k usermode is available to all users. 4.3.7 USERMODE +f ------------------ The +f usermode allows you to see anyone who quits with the "Excess flood" disconnect message. You will see a message which resembles: *** Flood -- bleh!bah@148.210.116.224 (9110) exceeds 8000 recvQ In this example, 9110 is the actual size of the queue, and 8000 is the limit. This means that the client has sent more than the allowed amount of data during a short period. When you see this message, the user has already been disconnected. However, it might be a good idea to look for other clients from the same address. For instance, the client might have been a flooding clonebot. Repeated flood disconnects of users from the same address is another sure warning sign. The +f usermode is only available to opers. If you deoper, this mode will be turned off. 4.3.8 USERMODE +h ------------------ The usermode +h turns you into a HelpOp. A new line will be added to the information shown about you with the /whois command that resembles: *** YourNick looks very helpful. This allows you to see messages which are sent via the /help command (see section 4.2.1 for more information about the command). The HelpOp messages are sent by users who need help with something, or in some cases to send a notice to opers. For example, there is a mass message detection bot which sends notices about mass messages as /help requests. Any /help messages you send while set +h are also shown to other HelpOps, which is useful for discussing and coordinating the answers to the help requests. The +h usermode is only available to opers. However, you may keep this usermode even after you deoper. 4.3.9 USERMODE +a ------------------ Usermode +a means that the user is a Services Administrator. When set +a, you can use Services Administrator commands. Currently the SA-commands are /samode (see section 3.2.11 for an explanation), /zline and /unzline (see section 3.2.12). Being +a does not currently affect the ability to use OperServ commands. When you have the +a usermode set, your /whois reply will show *** YourNick is an IRC Operator - Services Administrator instead of the of the normal "is an IRC Operator" line. This mode is only available for specified operators. Whether an oper can set this mode or not depends on the settings (flags) in the O:line. The current policy is that server admins may not enable the +a mode except for those people who are actual Services Administrators, as decided by the Services root staff. If you deoper, this mode will be turned off. 4.3.10 USERMODE +A ------------------- The +A usermode signifies a server admin. When setting the +A mode, also the +a mode will be automatically set if the user doesn't have it already. However the +a mode can be removed while keeping the +A mode. Currently the only effect the +A mode has is the additional notice in the /whois info: *** Nick is an IRC Operator - Server Administrator Like the +a usermode, whether this usermode is available is defined in the O:line. Naturally, it is not available at all for non-opers. When deopering this mode will be removed. 4.3.11 USERMODE +b ------------------- Another new DALnet added usermode is +b, which enables chatops. When set on, you will see any chatops messages sent by other operators. You will also be able to use the /chatops command to send chatops. The +b usermode is only available to opers. However, you may keep this usermode even after you deoper. 4.4 OTHER IRC ISSUES --------------------- You may already know about server (port) passwords. It is possible to set up password protected server ports which cannot be connected to without knowing the required password. DALnet has added additional functionality to this ircd feature so that if a client used a password to connect and the port was open to all connections, the password is sent to NickServ in an identify command. This is the safest form of automatic nick identification currently available. For operators the functionality remains the same, however since operators use password protected ports more often than regular users (for privileged access or due to other possible reasons), it is important to realise that the auto-identify feature does not work with password protected ports. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 5. IRC OPERATOR SERVICES COMMANDS ========================================== - Services is your friend This section will list OperServ and other special Services commands. For most, only very brief information is given because of security reasons. If you need more information, check the help for the command, ask your admin or trainer, or a fellow IRC operator or CSop. For Service Admin and CSop commands, consult the CSop Manual. OperServ is a service that gives extra abilities to some DALnet opers. It has relatively few commands, most of which are used for things like helping users who have had their channel taken over, or who have forgotten their nick's password. Some commands are related to DALnet security. Also shown is information on the Services log file format, in section 5.5.2. 5.1 ACCESS LEVELS ------------------ Services has a number of administrative staff positions, or access levels. 1. IRC operator 2. Service Admin (SA) 3. CSop (Service Operator) 4. root access To be eligible for any of the higher access levels, you need to be IRC operator. A person having access to one level has automatically access to all the lower level commands; for example a CSop has access to all IRC operator and Service Admin commands. You need to be opered to be granted any special access. For the SA access and higher, you also need to be at least ACC 2 (identified through an access mask) for your nickname. 5.2 OPERSERV COMMANDS AVAILABLE TO ALL OPERS --------------------------------------------- These commands are available to all opers, including Service Admins and CSops. 5.2.1 TRIGGER -------------- /msg OperServ trigger [newlevel] /msg OperServ trigger [newlevel] If you don't specify newlevel, it will show you the current one. Please ask for more information about this command from your admin or trainer. 5.2.2 BROAD ------------ /msg OperServ broad Broadcasts a wallops message. You have no reason to use this command, unless your client can't send wallops notices (most can, and if yours can't you probably should change to some other anyway). 5.2.3 UPTIME ------------- /msg OperServ uptime Shows Services uptime and the time until next database sync. 5.2.4 LISTADM -------------- /msg OperServ listadm Shows a list of Service Admins, CSops, and Roots. 5.2.5 AUTOKILL LIST -------------------- /msg OperServ autokill list [search pattern] Shows the autokill list. The search pattern is optional, if left out the full list is shown. 5.3 OPERSERV COMMANDS AVAILABLE TO SERVICE ADMINS -------------------------------------------------- These commands are available to Service Admins, CSops and Services roots. 5.3.1 MODE ----------- /msg OperServ mode #channel Changes the mode of the channel. Setting mode -k requires a dummy key (any one will work). Setting mode -l doesn't require a dummy value. See also the /samode command, section 3.2.11. The instances in which this command should be used are VERY rare. See section 6.5.7 on how to deal with channel matters for more information. 5.3.2 MASSDEOP --------------- /msg OperServ massdeop <#channel> Mass-deops a channel. 5.3.3 MASSKICK --------------- /msg OperServ masskick <#channel> Mass-kicks a channel. 5.3.4 AUTOKILL --------------- Add /msg OperServ autokill
Add timed /msg OperServ autokill time
Remove /msg OperServ autokill -
List /msg OperServ autokill list [search pattern] Timed autokills are NOT removed if Services go down, and the time is not saved: they get changed to normal autokills. Remember to report autokills as explained in the CSop manual and Kline procedures. Here's a summary of the things you should include: - The mask which has been autokilled. - Nicks and addresses for the autokilled user. - Exact time the user was online (also include the timezone). - Reason for the autokill. - Duration if applicable. - Any logs you may have. 5.3.5 IGNORE ------------- Add /msg OperServ ignore Remove /msg OperServ ignore - List /msg OperServ ignore Remember to report Services ignores as explained in the CSop manual and Kline procedures. Here's a summary of the things you should include: - Nickname(s) and address(es) which has/have been placed on ignore. - Nicks and addresses for the ignored user. - Exact time the user was online (also include the timezone). - Reason for the ignore. - Any logs you may have. 5.3.6 DROP ----------- This refers to the NickServ drop command, it is not an OperServ command. Service Admins have extended access, so they should be very careful with this. 5.4 OPERSERV AND SERVICES COMMANDS AVAILABLE TO CSOPS ------------------------------------------------------ These commands are available to CSops and Services roots. 5.4.1 GETPASS -------------- Getpass is not an OperServ command. /msg NickServ getpass /msg ChanServ getpass <#channel> Retrieve a nickname or channel password. 5.4.2 CLEARMASK ---------------- /msg OperServ clearmask Clears a nickname's access list. 5.4.3 MARK ----------- /msg NickServ mark /msg ChanServ mark <#channel> Marks a nickname or a channel. Remember to report these. Never remove a mark you didn't set, unless you have first talked to the person who set it. 5.4.4 CLOSE AND REOPEN ----------------------- These should be used only by authorized personnel. Unless someone tells you that you're allowed to use them, DON'T. 5.4.5 FREEZE ----------------------- The command may be used by any CSop attempting to deal with a stolen channel. Just like giving the channel to somebody else, the freeze command should not be used unless you fully intend to give the channel back to someone that you know to be the rightful owner. Any other uses of the command must be approved by a services root. Any abuse of this command will result in a loss of services privledges. Freeze is a kinder gentler form of close. When a channel is frozen, chanserv will effectively ignore any commands related to the channel from anyone in the channel access lists. Freeze has also been approved as one of the method steps in dealing with problematic channels that violate network rules. 5.5 OTHER SERVICES FEATURES ---------------------------- Aside from the special commands, there are a few other Services issues a DALnet IRC operator should know about. 5.5.1 EXTRA NICKSERV/CHANSERV ACCESSES --------------------------------------- In addition to the OperServ commands, there is some additional access to Services given to operators and above. Remember that you need to be opered for all of these. 1. IRC operators (and above) may view any channel's AOP, SOP and AKick lists. 2. IRC operators (and above) may use ChanServ's count and why commands for any channel. 3. IRC operators are excempt from the "secured ops" channel setting (ie. they may hold ops even if they don't have AOP status on the channel). 4. Service Admins (and above) may view any nickname's access list. 5. Service Admins (and above) may use ChanServ's access command for any nickname and channel. 6. CSops may do a "forced register" of a channel, registering a channel without holding ops there. 7. CSops may use ChanServ's clean and wipe commands for any channel. 5.5.2 SERVICES LOGS -------------------- Services writes logs about its activity. To access these logs, you need to register for an account for log searching. Accounts are given to all operators, even those who do not have CSop access, contact intra@dal.net for getting an account. The logs are mostly useful only to CSops when handling nickname or channel ownership issues. The format for log entries is: [time] ACTION performed-on (by) ACTION will be a single character. ChanServ: E -- expire C -- change founder A -- AOP wipe S -- SOP wipe K -- AKick wipe F -- forced register R -- register D -- drop or delete NickServ: R -- Register D -- Drop E -- Expire OperServ: [time] (Service) nick!user@host (whatever was sent) 5.5.3 SERVICES ROOT ACCESS --------------------------- Normally, CSops are able to deal with any situation that might arise and where special access to Services is needed. In a situation where Services is behaving oddly or erroneously, a Services root person might be needed to check into the matter. Reports of possible bugs can be emailed to service@dal.net or discussed on the Services mailing list (dalnet-services@dal.net). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ================= Part II - OPERDOM ================= Putting Your Skills to Use This part (chapters 6 to 9) discusses non-technical aspects of being an IRC operator. Issues vary from expected conduct to advice and instructions for common situations to describing DALnet activity outside the actual IRC network. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 6. SOCIAL SECTION - EXPECTATIONS, DUTIES AND PRIVILEGES ================================================================ - Advice, guidelines, rules The chapters before have concentrated on what you can do as an IRC operator, and, in some cases, given some advice on what is appropriate use for those commands and accesses. This chapter will explain what it means to be an oper: what you are expected to do and when, what you should expect yourself, advice and guidelines, and so on. The first section lists operator requirements. The following sections give further instructions, clarifications and explanations for some of these duties, expectations and aspects of being a good IRCop. As an introduction, I've included the two paragraphs from the DALnet Policies and Procedures document which discuss the role of opers: DALnet provides its users with the following: C. IRC Operator Service. DALnet's IRC Operators offer assistance with Services and IRC questions, help managing problem behavior and maintaining network stability. and II. DALnet's Administrative Organization. a. IRC Operators - Server Team Staff (IRCops). A DALnet IRC Operator assists the Admin in server maintenance as assigned and helps maintain network stability. IRCops assist users in becoming oriented to the DALnet network, DALnet Services and in the mediation of disputes. IRCops offer assistance in resolving conflict and work with other administrative staff to maintain a safe environment. 6.1 REQUIREMENTS ----------------- Being an IRC operator on DALnet is a privilege, and like most others, it comes with responsibility. You are an oper so that you can be of benefit to the network. There are a few requirements and duties for all operators, which are detailed in this section. Keep in mind that IRC is meant to be fun. Do not overwork yourself just because you feel that you have to "fulfill your duty". If you don't feel like doing something at a particular time, don't do it (just be polite about it, like when a user requests help from you). See section 6.2.1 for a discussion about being "on duty" and "off duty". Also make sure to read the Final words chapter of this manual (chapter 9). However, if you find that you're mostly never in the mood for doing "IRCop stuff", or that you only set yourself +o to issue /kills, perhaps being an oper is not for you. Here's a list of operator requirements, each described in detail in the following subsections: 1. Help maintain the network and your server 2. Help the users 3. Enforce DALnet rules 4. Follow the guidelines and instructions given in this guide 5. Behave in a fitting manner for a DALnet IRC operator 6. Keep up to date on DALnet matters, rules and policies 7. Do not share confidential information with non-opers 6.1.1 HELP MAINTAIN THE NETWORK AND YOUR SERVER ------------------------------------------------ You should monitor the state of the network and your server. Mostly this means watching out for netsplits and lag, reconnecting and rerouting servers if necessary. You should also look into anything that seems strange or just "wrong" on the network or your server. Your admin may give instructions to you of how your should help with running the server. 6.1.2 HELP THE USERS --------------------- All opers should help users. If a user asks for help, and you can't help him/her yourself for some reason (for example, don't know the answer, you are busy with something else, or you are "off duty"), you should try to locate someone else who can help the user. At the very least you should politely indicate that you cannot help and try to direct the user to another likely source of help. 6.1.3 ENFORCE DALNET RULES --------------------------- Opers should uphold DALnet's rules, as outlined in the DALnet Policies and Procedures document. Use the means available to you to deal with any violation of rules in an appropriate manner. The guidelines given in this document, by your trainer or admin, and in other DALnet sources should help you in choosing the right approach to each situation. See section 6.5 on policy enforcement. 6.1.4 FOLLOW THE GUIDELINES AND INSTRUCTIONS GIVEN IN THIS GUIDE ----------------------------------------------------------------- IRC operators are generally expected to go by this guide. It is possible that some of the instructions given herein will sometimes be changed, clarified or even overruled by your admin or in other DALnet sources (usually, the ops mailing list). In that case, those directions of course take precedence. 6.1.5 BEHAVE IN A FITTING MANNER FOR A DALNET IRC OPERATOR ----------------------------------------------------------- You should behave as is appropriate for a DALnet IRC operator. This is especially true in times when you are "on duty" -- an acting representative of DALnet in some way. For example, when you are helping a user, or dealing with some breach of DALnet rules, or writing mail to a DALnet mailing list. See the section 6.2 on conduct. 6.1.6 KEEP UP TO DATE ON DALNET MATTERS, RULES AND POLICIES ------------------------------------------------------------ DALnet is a growing and evolving community. Things are constantly changing. There might be a new policy added, new features for IRC or Services added, administrative changes taking place, or just about anything else... Because of this it is very important that you keep up with DALnet news. In practice, the single most important thing is being subscribed to the ops mailing list. Subscriptions to the other mailing lists are also encouraged, as they will give you more detailed information about various things, and allow you to take part in the current DALnet issues and discussion. Also, in reverse, you should keep OTHER members of DALnet staff informed of the DALnet matters as best as you can. 6.1.7 DO NOT SHARE CONFIDENTIAL INFORMATION WITH NON-OPERS ----------------------------------------------------------- As a DALnet operator, you will be informed of many confidential issues, facts and matters. Whether these are related to DALnet's security, or to the network's users (eg. nickname/channel passwords) it is VERY important that you do not disclose these to anyone who is not a DALnet operator. This especially concerns information obtained through the privileged operator sources (the ops mailing list, globops, and so on). 6.1.8 NEW OPERATOR'S ACTIONS ----------------------------- When you become a DALnet IRC operator, you should follow these steps. 1. Make sure your nickname is registered, and that you have nick kill enforce set ON. 2. Tell your admin what nickname you want to use for your @dal.net email alias (nickname@dal.net), and what other email addresses you will be posting from regularly. Your email alias will be signed up to ops@dal.net, dalnet-outage@dal.net, and if you are not already subscribed, to dalnet@dal.net. You will also receive server staff email (sent to -staff@dal.net) at that address. If you wish to subscribe to ops-chat@dal.net let your admin know that along with the above information, or email postmaster@dal.net and ask to be subscribed. That's also the place to write if you ever need changes to your email alias or approval addresses. 3. Request AOP access on the IRC operator channels (#OperHelp, the privately owned #operators and (optionally) #dragonrealm, possibly some others) from your admin. You might also consider joining some other DALnet mailing lists: ops-chat The operator chat list dalnet-announce The (public) announcements list dalnet-services The Services discussion list dalnet-src The server development list helpers The helpers list To subscribe, send email to majordomo@dal.net with empty subject and with the body of the email saying just "subscribe listname", replacing listname with the name of the list you wish to subscribe to. For the dalnet list, approved status should be manually requested from the moderators (moderators@dal.net). For the ops and ops-chat lists, you have to also manually request addition and posting approval from postmaster@dal.net. 6.2 CONDUCT ------------ IRC operators are the core of DALnet's staff and are perhaps the single most important factor in how DALnet appears to its users. Because of this the manner in which opers appear is very important to DALnet's image, the whole "spirit" of the net, and how well DALnet lives up to being "The Friendly Network". Other conduct issues about expected behaviour of DALnet staff are covered in the section 6.8 about Privileges and Responsibility. 6.2.1 "ON DUTY" AND "OFF DUTY" ------------------------------- It is recognized that operators may be "on duty" and "off duty". Naturally you have a greater freedom to act as you choose when you are off duty, but you should keep in mind that the activities of an oper reflect upon DALnet even when the operator is not acting as a representatives of it. When you are on duty, you should always pay special attention to conducting in a professional manner. When are you on duty, and when off duty? The single definite rule is that when you are acting as DALnet's representative or a DALnet staff member, you are on duty. It is actually possible to be on duty and off duty at the same time, for example you can be "on duty" on a help channel and "off duty" in a private channel. In this case, anything you do or say on the help channel should be considered being on duty, while the private channel activity is clearly off duty. The interpretation depends upon each situation. If you doubt, it's better to err on the safe side and behave as if you are on duty. Here's a few indications that you are on duty: - Usermode +o set, using operator commands - Usermode +h set, or helping users on a recommended help channel, or helping as a member of DALnet staff (for example, when a user requests help in a private message) - Having channel ops when doing so as a representative of DALnet staff (for example, ops on #OperHelp or another IRC operator channel, or opped on a channel using OperServ) - Participating in the mediation of a user dispute - Monitoring user or channel situations, incognito or not - Attending DALnet staff online meetings - Posting email on DALnet mailing lists 6.2.2 GENERAL CONDUCT GUIDELINES --------------------------------- Here are a few guidelines for general conduct. The first two should not need to be included, but nevertheless they are listed here so that nobody can say that they weren't clearly stated. - Always follow DALnet's rules! - Do not abuse your operator privileges. - Respect and be considerate to all other users. This includes both regular users and other operators. The following should be observed when on duty: - Avoid swearing and derogatory comments. - Do not exhibit sexual behaviour in public. - Keep calm -- if you become upset or angry and cannot remain objective, it is a good idea to ask a fellow operator to handle the situation if possible. 6.2.3 GUIDELINES FOR DEALING WITH USERS ---------------------------------------- The manner in which you present yourself may make a different in how efficiently and effectively you are able to handle any issue with users. You should remain calm and matter of fact at all times when dealing with users. If you become upset or angry, you will be less effective and possibly even unintentionally make the situation worse. It is good to ask someone else to handle the issue for you if you are unable to remain objective. Opers need to work as a team and recognising our individual strengths or weaknesses is an integral part of good team work. All of us have times when our performance is temporarily diminished. It is better for DALnet to have IRC operators who are able to rely on others for help, than to risk handling a situation badly. DALnet operators should NOT look down on users, make fun of or ridicule them. It is part of the DALnet principles that users should be treated with respect. If you feel that you are above the network's "normal users", you should rethink your view. You are an IRC operator on DALnet to serve the network, and thus, its users. When handling situations involving users, the following recommendations will help you handle it in a good and professional manner. Some of them only apply to specific situations. 1. Be polite and respectful. 2. Give the users the benefit of the doubt. If you have had a complaint about a user, ask them to tell you what the problem is themselves before you confront them about their reported behaviour. 3. State the issues clearly, without personal criticism. For example, saying "I received a complaint about someone flooding this channel. Do you know what happened?" will open up communication and the possibility of finding a peaceful solution. Whereas, just saying "I /kill lamers for flooding.", for example, may result in an escalation of the problem. 4. State clearly the rule or policy which was violated. For example, "Flooding is not allowed on DALnet because it interferes with other users' ability to chat and can cause some IRC clients to lose their connection." will be instructional as well as stating the network's position on the issue. 5. State clearly what the consequences are. State, for example, "You are being warned. If I receive one more complaint, I will /kill your IRC session. Any complaints after that may result in a K:line (for you or your site)." This way everyone knows what to expect and there will be no need to engage in any debate. Make sure you know what the appropriate action is for a particular violation and do not threaten to take action which goes against the network's policy for a particular issue. 6. Do not "threaten" an action until you are sure it is what you will do. For example, be sure there is cause to /kill someone before you tell them you are going to do it. While it is good to state that a possible consequence of the action may be /kill, it is important for users to know that once we state we will do so, we follow it through. If Opers vacillate, it can start to sound like empty threats and the user may "test" repeatedly to see if we really mean what we say. It is better to avoid taking the action until you are sure there is no other option, than doing so quickly and without further discussion. Remember to not use profanity or namecalling. Just state the reason based on the offending behaviour. 7. Do not criticize or ridicule users. Have patience for typos. Avoid embarrassing a user in front of others. 8. Remember that DALnet is an international forum. For many English is a second (or latter) language and some colloquialisms and slang may be confusing or easily misinterpreted. Please try to use correct grammar and punctuation as this will facilitate ease of communication. If needed, you may attempt to find a translator. 9. Try to be sensitive to how others view the role of an IRC operator. Control and privileges are easily misunderstood. Being aware of your own feelings in this regard can be helpful in your interactions with others. You should also be aware that because IRC operators are perceived as having "power" on the network due to their privileges, some unscrupulous users will attempt to manipulate and exploit opers for their own benefit. Most users of IRC fall outside of this group, but such people are common enough that every operator will meet one sooner or later. Keep this in mind when dealing with help requests and reports of abuse. 6.2.4 GUIDELINES FOR STAFF INTERACTION --------------------------------------- When dealing with other staff members, how you conduct yourself is very important too. In general, it can have a huge influence in the overall morale, both for good and bad. Here are a few guidelines that should be followed when interacting with other staff members. 1. Be polite and respectful. 2. Help other staff members if they ask for it (see section 6.7). 3. If you think someone is doing a good job and have something nice and encouraging to say, say it. Positive input is always welcome, and can make a big difference. 4. If you think someone is not acting right, you may try to correct him/her in private, POLITELY. Do not make defaming or derogatory comments about other staff members, especially not in public. It only lowers morale and doesn't help to solve the situation. 5. If you want to make a complaint about another staff member, follow the instructions in section 6.2.5. Do not flame him/her in public, or attempt to "get to" him/her in other ways. 6.2.5 STAFF MISCONDUCT ----------------------- The procedure for registering a complaint about a DALnet staff member is: 1. Try to resolve the problem by talking to the other person directly. 2. If there is still a problem, report it to the person's superior. If the issue is related to some team, report it to the team's leader. If the person is an IRC operator and it's a generic complaint, report it to that person's admin. If you do not know the oper's primary server, report it to the admin of the server that the operator was opered on at the time (it is likely you will be directed to talk to the responsible admin). 3. If the problem remains unresolved after the superior has investigated and made a decision, a report can be sent to JAG (jag@dal.net) with supporting documentation (including all the logs from all the meetings with the person and with the superior, if available). In the case of Services related problems, it can be reported to the Services Team (Services roots) in addition to or instead of JAG. 4. Any case unresolved by JAG may be reviewed by DALnet's Executive Board or CEO, who will make the final decision. The possible consequences of misbehaviour are decided by the superior of that staff member (either the IRC oper's admin or the team leader, as appropriate) alone or in conjunction with the JAG, CEO and/or EB. Consequences will be proportional and relevant to the offence and may include: - Demotion to a local operator for a probationary peri