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 period - Personal and public apology - Replacing or reconstructing damaged records - Removal of channel AOPs; temporarily or permanently for repeated misuse - Removal of the O:line or staff position - Removal of Services Admin or CSop access - Mailing list moderation or removal - Refusal of future O:line opportunities 6.3 NETWORK AND SERVER MAINTENANCE ----------------------------------- One of the most important duties for IRC operators is to keep the network running. However, normally there isn't that much to do in this regard, as mostly the servers work fine without outside intervention. What changes and operations are needed are usually handled by the server's admin, or an IRC operator whom the admin has given instructions. The following sections deal with the most common things that might need operator intervention. It is impossible to give exact instructions for every possible situation, so use you own best judgement. 6.3.1 HOW TO DEAL WITH: LAG ---------------------------- Lag is one of the most common problems on IRC. As an IRC operator, you may actually attempt to fix it -- however, you should take care to investigate the situation and make sure that you don't make the situation worse. The solution to lag is to reroute, and that means actually breaking a connection, so it should only be tried if the lag doesn't seem to get better with time. Under most circumstances, lag will either disappear with time or break the connection anyway, so operator interference is not usually needed. If you notice lag and want to see if it can be fixed, the first thing you should do is try to pinpoint what is causing it. Make sure it's not your OWN connection to the server (ping yourself, if this takes a long time then you are lagged to the server). If that is not the problem, then you should try to use pings, /traces and /version commands to try to figure out the lagging link. You will also need to use /links to find out the current network layout. After you have found out the lagging link, and are sure that it's not going to improve on its own, you may attempt to reroute that connection. See chapter 7 for rerouting instructions, particularly section 7.3.1. 6.3.2 HOW TO DEAL WITH: NETSPLITS AND MISSING SERVERS ------------------------------------------------------ Servers have admin-configurable autoconnects which make them automatically connect to other servers if there is a netsplit. However, sometimes the autoconnect will not work, or will try a "wrong" server, or take a long time to happen. Autoconnects might also not try to connect to all the possible servers (eg. a backup hub). It's also possible to configure a server not to autoconnect at all when there are IRC operators present on the server. You should ask your admin about your server's configuration. Usually you should leave autoconnects to take care of server connects when a netsplit happens. However, in some occasions human judgement is much better than the "dumb" logic of autoconnects. For example, if your server happens to split and you see it try to connect to a hub which you know is down, it might fix things sooner if you just do a manual /connect to another hub which you know is up. (See section 3.2.5 on usage of /connect.) If you happen to notice a missing server from the network, the reason is probably that it is down or the system is unreachable netwise. Because of autoconnects, any server will sooner or later automatically connect back to the network if possible. However, unless you know what the situation with a particular server is (eg. the admin has announced it is down for a system upgrade), and it is missing, it is a good idea to investigate further. The following is a list of steps to follow in this kind of situation: 1. Try to make contact with someone on the server staff online and ask about the server's situation. It might be that there is a problem that the staff is unaware of. If there is a problem, the staff member probably should take care of handling the matter. 2. If you can't locate a server staff member, send a globop and find out if anyone knows of the situation or is working on it. Attempt to remote connect the server back to the network a few times, unless someone has already tried that. Connect attempts don't hurt anything, even if they fail. 3. If the other opers don't know anything, and there is no further information available about the server, consider trying to reach the server's contact person in "real life", ie. with a phone call or a pager. The DALnet Contact Directory may help here. 4. All else failing, take the matter into your own hands: make sure the server admin/staff is notified of the situation, and also contact hostmaster if that is warranted (ie. to point the server's name to the irc.dal.net pool temporarily so that clients don't try to connect to a server which is down). 6.3.3 HOW TO DEAL WITH: DESYNCHS --------------------------------- First, make sure it's REALLY a desynch. Connect to different servers and look at the situation from many different "viewpoints". Check whether the info appears the same or different, and that there is not a split or synch in progress. Desynchs are rather rare, but they do happen occasionally. They mostly happen in times of bad lag and splits (ie. bad network conditions overall on the Internet), and when things get better the desynch usually disappears too. There are various means to clear a desynch. These vary depending on whether it's a channel or a nickname which has been desynched. Channel desynchs can be cleared by clearing a channel completely. If available, you may also attempt to use the OperServ mode command. For nicknames, issuing a kill for the nickname or (for ghost nicks) using that nick on some other server might clear the desynch. Disconnecting a desynched server and reconnecting it back is another option. Sometimes the problem might be that a resynch never really finishes, in this case the server will split eventually again. Desynchs are elusive by nature, and it's impossible to say what exactly will clear something. Squitting and reconnecting the desynched server(s) should always fix it though, as it forces the servers to start synching their databases from scratch. Also getting an oper on the desynched server to look into the thing from the "other side" is a very good action to take. Sometimes desynchs can only be effectively fixed from one side. 6.3.4 HOW TO DEAL WITH: SERVICES GOING DOWN -------------------------------------------- Services do sometimes go down, disappearing from the net. It doesn't happen very often, and when it does it might actually be deliberately done in order to upgrade the program or for some other maintenance reason. In this case, you will likely see a globops message about this by a Services root, or in the very least see "Services shutting down by command of " there. Since someone who can control Services is obviously already aware of it, you don't need to do anything specific in this case. However, ocassionally Services does crash. Usually in this case it will send a "PANIC!" globop just before it quits the network. If this happens, make a note of whatever messages Services sent before it disappeared. First wait a few minutes, since Services has been set to auto-restart every 5 minutes. If this doesn't happen, and nobody else has said anything in globops, you should make a query about it. If possible, someone should try to reach a Services root and explain the situation (in the very least, send an email to service@dal.net with the information Services sent before it quit). Be sure to coordinate this with the other active operators who are online. 6.4 HELPING USERS ------------------ One of the main duties for DALnet IRC operators is to help users. You should provide help as best you can, whether you are helping on a help channel or are approached privately. Be polite and have patience for typos, as well as never ridicule the user asking help. If you cannot help the user yourself for whatever reason (eg. you don't know the answer or are busy doing other things), try to instruct them on how they can get help. For instance, most generic IRC questions can be answered in the help channels, or give pointers to some other appropriate help resource. On the whole, teach users to help themselves. This is very important. Explain about help commands, Services help pages, and other help resources. DALnet official help documents can be found at the FTP site, the URL is ftp://ftp.dal.net/dalnet/document/official-help. For more immediate help, or when a better explanation is needed than what is available in the help texts, a user may visit the DALnet help channels. Encourage users to find information themselves. Remember that DALnet does not take part in channel matters (see section 6.5.7). Issues such as channel policies or ops disputes should be handled by the channel itself, and ultimately by the channel's founder. You may act as a mediator for disputes if you wish, however make sure you are impartial and fair, and that the people you are dealing with are aware of that you are there in an advisory capacity only (see section 6.6). When helping users, especially with problems relating to something that the user has/hasn't done, it's good to remember that they might leave out parts or even outright lie in some occasions. This might happen even if they really don't have any malicious intents. An exaggerated example: yeah, my channel was registered to me but the logs don't show that.. umm, well, it wasn't, really. i was just going to 6.5 POLICY ENFORCEMENT ----------------------- DALnet has quite a few policies and rules concerning how users are expected to behave. They all really boil down to one thing: play nice. Make sure you are familiar with the policy and rules documents that do exist, and any guidelines given to you by your admin. As was said before, the actual situation you will come across will vary a lot. It is impossible to give advice for every situation that will happen. Use your own best judgement in situations where any of these guidelines don't apply. For reference, here's a short list of things which aren't allowed on DALnet: 1. Flooding 2. Running an excessive number of clients simultaneously, running automatons which use an excessive amount of server resources. 3. Running bots on servers which don't allow them, or running unregistered bots on servers which require bot registration 4. Harassment of ANY kind 5. Takeovers and stealing of channels or registered nicknames 6. Evading channel bans or server connection restrictions (for example, K:lines) 7. Evading user ignores and silences 8. Mass messaging and advertising 9. Abuse of Services (NickServ, ChanServ, MemoServ) 10. IRC operator or other DALnet staff impersonation, Services impersonation 11. Denial of service attacks, exploiting weaknesses and bugs in client or server software 12. Transferring, requesting, or offering pirated software (warez) 13. Transferring, requesting, or offering child pornography Remember: IRCops are not IRC cops. IRC operators are technicians, who look after a service (DALnet) and who should deal with those who abuse it. The policing ends there. 6.5.1 HOW TO DEAL WITH: CLONEBOTS AND CLONING ---------------------------------------------- Clonebots are strictly not allowed on DALnet, since there is no legitimate reason to run them. You may disconnect clonebots on sight, as long as you are SURE that they are clonebots (and, for example, not a computer class). If you are able to determine who is the actual person running the clonebots, you should try to negotiate and warn him/her against running clonebots, instead of just /kill'ing off the user too with the clonebots. Services has a clone detection feature, which shows alerts for possible clonebots. If you see an alert, doing a /who command on the hostname shown will show all connections from that host. You should ALWAYS verify whether the clients are really clonebots before you proceed to (mass)kill them off the network. Please note that a user having 2, or even 5 simultaneous connections isn't forbidden on DALnet, just the act of running clonebots. As long as there is some good reason to have multiple clients from the same address, it's allowed. How to tell apart clonebots from real users? First clue is the information seen with /who or /whois, of course. If the nicknames are something like LKJASDDVN, or there's a group of clients with nicks of, for example, from Fred1 to Fred8, then those are very likely clonebots. If the real name is the same for each of the clients, then that also indicates clonebots. The same goes for the username as well, though in some cases a group of users using a gateway/proxy program to connect to IRC will all share the same username. If the clients are all on different channels, this probably means that they are real users. There are smart clonebot scripts which make their bots look very much like real users, though. Thus sometimes you need more information. You may check the idle times for a few of the clients -- flooding clonebots will have a low idle time. If the version reply is the same for all of the clients (and it's something else than mIRC), then that's an indication of bots. Finally, trying to send a message to a few or all of the users and *asking* will usually help, as clonebots are unlikely to respond or at least will reply with a standard message. Clones who do not pose an immediate threat to the network should be warned, AND given a reasonable time to respond before being akilled. There are several reasons for this. First, because it is consistent with our "friendly" image. Second, because in a fairly large percentage of cases+ the user with the clones would rather remove them voluntarily than be akilled, thus we save the cost of one more akill on services 6.5.2 HOW TO DEAL WITH: FLOODING --------------------------------- Flooding is not allowed on DALnet, and you may /kill any user doing that. Since a flooder might not see any warning sent to him/her, it is permissible to disconnect a known flooder without warning. You should consider giving a warning in these cases too, just in case. Don't wait too long for the flooder to stop, though. Mostly the trouble is finding out whether a flood is actually happening, or not. If a user comes to you with a complaint of someone flooding, how can you tell if the complaint is legitimate or not? Most of the complaints are, but that is not proof. Here are a few hints for detecting if someone is flooding or not: - change to the flooded nick, or join the flooded channel - check the flooder's idle time (messages change this, but nick changes, joins/parts, notices and DCC don't) - check the received/sent message counts and received/sent data amounts for the flooder and the person being flooded with the "/stats l " command (see section 4.1.2) Additionally, if you have the usermode +f set, you will see a notice of any flood disconnects that your server does. See the description of the +f usermode in section 4.3.7. 6.5.3 HOW TO DEAL WITH: IGNORE / BAN / K:LINE EVASION ------------------------------------------------------ Evasion means deliberately changing the address information to get around an ignore, a ban or a K:line placed against you. This is not allowed on DALnet, users are allowed to NOT listen to someone if they so choose, and everyone must respect that right. If you get complaints of ban evasion, check first if it's really happening -- that the ban/akick really *is* there. For silence, you can check that user's silence list with /silence nick. For ignores, you just have to take the user's word for it, as there's really no way to check that. Also, evasion of very "weak" bans or ignores (such as those placed only on the basis of a nickname, and not by address) is so easy that it might happen even by accident. For evasion to happen, the user also needs to know that his/her presence or messages are not wanted, ie. they need to be aware of being ignored or banned. In dealing with evasion, first -- especially in the case of too-weak ignores and bans -- teach users to set up proper ignores and bans. Then also warn the offender. If this is a repeat of an evasion, and you know the user has been warned before, then warn again but make sure the point gets across (eg. "Do NOT ban evade -- you WILL be /kill'ed if I get another complaint about you."). If the user still continues the evasion, use /kill as needed. If the user does not get the point from that, and somehow manages to still evade (despite setting up proper ignores or bans), then an autokill may be used. As a note, autokill evasion is in itself something that a user may be autokilled for. Also remember to never concentrate your attention to just the abusive user, as was said before, make sure that the other users who are involved know how to place proper ignores, silences, bans and akicks. 6.5.4 HOW TO DEAL WITH: HARASSMENT ----------------------------------- The word harassment is used here to indicate the sort of harassment that goes on for a long time; several days, weeks, even months. A flooder pestering someone for an hour or two is not "harassment" as the term is used in this section. Rather, this section discusses things such as (death) threats and other severe forms of harassment. Harassment on IRC is almost always connected to some other, non-IRC forms of harassment. If this the case, your first advice to any user who is suffering from harassment should be that they need to contact local legal authorities. For example, in the US this would be the FBI. For other countries, the user should contact similar authorities. After this, you should take great care in handling the situation. Victims are usually very scared and think that their harasser can do a lot of things they in fact can't (such as listen in on conversations on IRC, etc.). Because of this you should explain just what is and isn't possible on IRC. You should also teach the user to use the relevant IRC commands, such as /ignore and /silence. Also, if needed, explain about registered nickname and channel security, teach the user to use bans, etc. Make sure the user knows how to contact you even if you are not online (for example, give your email address), or how they can find help online when you yourself are not present. Try to reassure the user that the problem can be solved. If needed, you should use the normal means to control abusive users: warnings, /kills, and finally autokills (ask a Service Admin or CSop to help if needed). However you should consider each of these very carefully, as they can possibly make the situation worse for the user. Asking help from a fellow oper in these situations is usually a very good idea, if you feel that you are unsure of how to handle the issue. 6.5.5 HOW TO DEAL WITH: MASS-MESSAGES -------------------------------------- Mass-messages are messages which are sent to a large group of people automatically. They typically contain advertisements for a channel, another IRC server, a WWW page, or other things. Regardless of the content, mass- messages are not allowed on DALnet at all. Note that it is mass-messaging, not advertisement in itself, which is forbidden on DALnet. For example, advertising an IRC network on a channel which is founded for that purpose is allowed. Mass-messaging is a relatively new problem, but a rather annoying one. The normal solution of using /ignore or /silence doesn't work, because rarely will there be repeated mass-messages from the same address. Also, the affected group of people is very large, not just a few users. Most mass-messages are done as private notices or messages to everyone online. Some are done as invites to channels "out of the blue", and others are sent as messages on join/part to (popular) channels. Yet another tactic is to join each channel which has been formed, send the message, and leave. In the case of join/part messages, the matter should be primary handled by channel ops -- after all, it's a channel matter in a way. However, IRC operators may interfere at their own discretion, provided that the channel's operators (if any are present) agree with the actions. If a client is mass-messaging by hopping from channel to channel and sending the message to each channel, it can be caught by doing repeated /whois'es on the offender. If the channels changes constantly, then it's a very probable case of mass-messaging. There are three ways to detect privately sent mass-messages: - Through MassOp (a bot which will be explained shortly) - You yourself receiving a notice, message, or invite or noticing a "channel hopper" or a message on join/part - Someone reporting an offence of this nature A typical MassOp report looks something like this: *** HelpOp: MassOp (Local): 3 messages by Prez (x@khaos.dsuper.net): insert message here What you should do when receiving this notice is first check the message and see if it appears to be a mass-message. If so, you are free to /kill the client at will (it most likely is a bot). Any Service Admins (or CSops) should also consider autokilling the site. If you yourself happen to receive a mass-message, act as above. Finally, the most tricky case is when someone reports a mass-message. For instance, if you are given this log: come to my great server /server lame.server.com 6667 How are you sure it's not a fake log? You're not. So you can do a couple of things. One is to watch the idle time of the offending party, if it is constantly below two or three seconds, there is a good chance he/she is mass- messaging. Checking the client's SendQ is another, high values may indicate mass-messaging. In any case, care should be taken when killing on the basis of a reported mass-message, because fake logs are very easy to produce. MassOp catches most of mass-messages, and is a more reliable source of reports. If you enter a popular channel (for example #funfactory or #chatzone), and get auto-join messages or /notices, you may consider /kill'ing them provided that the ops in the channel agree with the action. Use your discretion of defining a "popular" channel. 6.5.6 HOW TO DEAL WITH: DESYNCHS --------------------------------- Although desynchs are really a technical problem, they can be used by abusive users to cause trouble. This is really rare as desynchs are rare in themselves, but if it does happen, just try to fix the desynch as normal (see section 6.3.3). Using /kill to disconnect a desynched and abusive user is usually easily justified in these situations. 6.5.7 HOW TO DEAL WITH: CHANNEL MATTERS ---------------------------------------- In short, don't. DALnet does not take part in internal channel matters. Each channel should arrange to look after itself with the tools provided by DALnet (meaning ChanServ and IRC features such as /kick and bans). You should instruct users how to use the proper ChanServ and IRC commands or refer them to the appropriate user help resources, if that's needed (see section 6.4). You MAY act as a mediator if all parties (including you) agree to it, but you can only do that in an advisory capacity, so keep in mind that the founder is the person who makes the final call in the issue, not you. Because of this it usually doesn't make much sense to get involved. Channel ownership disputes are discussed in section 6.6.3. If you get a report of a flooder on a channel, you should deal with that of course. Opless channels make easy targets for flooders, so frequently IRC operators are asked to help with flooders in these kind of situations. In that case, deal with the flooder as normal: warn first, then use /kill. An alternative is to ask someone with Service Admin access to op you on that channel in order to do a kick and ban, however keep in mind that a /kill works just as well as a /kick and is entirely appropriate when dealing with flooders. Getting ops and using a kick/ban is really only needed in special situations (banning a repeat flooder or many flooders, or trying to fix a desynch, for example). However, IRC opers should not need to "babysit" channels, each channel should keep a sufficient number of AOPs to deal with channel problems. If a channel has recurring problems due to no ops, try to contact the founder or SOPs and request them to add more AOPs. 6.5.8 HOW TO DEAL WITH: ICMP FLOODING AND OTHER NON-IRC MATTERS ---------------------------------------------------------------- There is a group of attacks such as ICMP floods, winnukes, sspings and the like that do not travel through DALnet, rather they are client to client attacks (they work using a similar method as DCC). They typically make use of a bug or problem in operating systems. ICMP flooding works like a flood on IRC, except that instead of using IRC messages for flooding they use ICMP messages which aren't usually visible to the user at all. Although the actual attack is not happening over DALnet, the necessary info (the user's hostname or IP address) for making it is obtained through IRC. Because of this it is an IRC problem, or a form of attack that is done "on IRC". Dealing with these kind of problems is handled a lot like flooding. If you are being ICMP'd or otherwise attacked in this manner yourself, you may kill the offender (if you are sure of who it is). However, if a user complains to you of being attacked, there is the question of whether you can believe it or not. Unfortunately, getting any sort of proof is much more difficult than for flooding. Perhaps the best advice you can give is to tell the user the following: "ICMPs (replace ICMP with offence) do not travel through DALnet. If you can, log the offender's IP, hostname and an accurate time/date stamp, and send it to his Internet Service Provider along with the complaint. They will deal with it accordingly." Also advice the user on how to get a fix for the problem and how to detect and log these attacks, if you know that. In the case of more exotic attack methods, such as mail-bombing or sending fake emails, DALnet is not involved at all. Thus, these are not handled on DALnet. Any complaints should be taken to the appropriate ISP. 6.5.9 HOW TO DEAL WITH: SPOOFING --------------------------------- Spoofing means faking info, usually on IRC this means faking address info as something else than what is real. This can be used to just hide the real information, or to impersonate someone (this would even fool Services in cases where it relies on just the address for identity checks). DALnet servers have an anti-spoof check for connecting users which prevents IP-spoofing, where the user fakes the IP address from where he/she appears to come. However, there is another type of spoofing, called DNS-spoofing, which is still possible (though not easy, nor common). The problem is not in the ircd in fact, but in the DNS software run on the server computer, and the whole DNS protocol itself which allows this to happen. If someone is DNS spoofing, he/she may set the hostname which is shown on DALnet. However, the real IP address is still known to the server which the user uses to connect, and can be seen with the command "/stats L ". This can be used to trace down the person who is doing this. (See section 4.1.2 for more information about the /stats command.) A DNS spoofer may be prevented from connecting to a server by the use of Z:lines, via the /zline command (see section 3.2.12 for an explanation). Spoofing is of course not allowed on DALnet. It is not possible to do it "by accident", which should be kept in mind when dealing with any spoofer. 6.5.10 HOW TO DEAL WITH: WAREZ AND CHILD PORNOGRAPHY TRADING ------------------------------------------------------------- This has always been a touchy issue. Mainly, channels for trading warez (illegally copied software) and child pornography are to be shut down ONLY by official closers. The debated policy is that it would be best if these kind of illegal matters would be handled by the appropriate legal authorities. You might get users complaining about this degrading act. All you can really say is: "If you'd like, log the channel activity, make sure you get accurate timestamp and the addresses of the offenders, and send it to policy@dal.net." You also may not kill offenders at your own will for trading illegal files. However, it is often done by using unregistered fserves and bots on servers which do not allow them -- and this is a valid reason for a kill. 6.5.11 HOW TO DEAL WITH: SERVICES ABUSE --------------------------------------- Services abuse means a variety of things, generally using Services in any way it hasn't been meant or planned for, or not following other DALnet rules concerning the use of Services. In practice this usually means stealing nickname and channel registrations (through whatever means) or doing anything to hinder the performance of Services, for example by flooding it or using up more than a normal amount of resources (registering too many nicks, filling up the AOP list with too many entries, etc.). Depending on what kind of Services abuse is in question, you may or may not be able to address the issue yourself as an IRC operator. For the cases where you cannot solve the issue yourself, ask either a SA or CSop to look into the matter. If you are a CSop, and still can't solve it yourself or are unsure of how to proceed, you may send a report to service@dal.net (Services roots). The first step should always be to talk to the user and try to convince him/her to stop the Services abuse. Leniency should be practiced when the abuse has been unintentional. The ChanServ count command can be very helpful in checking for excessive AOP/SOP/AKick entries. 6.6 DISPUTE MEDIATION ---------------------- IRC operators are not IRC cops, although many people believe this misconception and may even ask questions that could be asked from a law enforcement officer. While you are not an IRC cop, it does become the role of a DALnet IRC operator to help maintain DALnet as a safe, fun and friendly environment for our users to IRC in. As DALnet grows, its opers find themselves increasingly more involved in disputes between DALnet's users. General rules of thumb when dealing with disputes include: - Clearly identify yourself as an IRC operator - Don't hesitate to consult with another IRCop/Admin if you have any questions - Enforce the DALnet policies and remember that an IRC operator is not a cop When mediating a situation, the recommendations about conduct in section 6.2.3 will also prove invaluable. Remember to also let the users know that you want to help. Disputes generally fall into one of four categories; nick ownership, channel ownership, channel control (ops/kicks and bans/takeover attempts), or inappropriate behaviour such as harassment or flooding. 6.6.1 NICK/CHANNEL OWNERSHIP: THE PASSWORD RULE ------------------------------------------------ If a password has been given to someone, so has the right to that particular channel or nick. Sometimes learning is a painful experience, but you cannot make exceptions to this rule. It is the responsibility of the original owner to protect their channels and nicks by keeping their passwords secret and secure. 6.6.2 NICKNAME OWNERSHIP ------------------------- DALnet's NickServ allows a user to register (own) a nick. The nick may be taken by another user under certain circumstances such as when NickServ is down, by getting (guessing) the password for the nick, or when the registered owner did not set nick kill enforce on and someone else is using the nick despite warnings from NickServ. To see who the registered owner of a nick is use NickServ's info command and then compare the address with that of the user making the complaint and/or using the nick. A CSop will be able to help determine who owns the nick and recover the password if it is appropriate to do so. Checking NickServ logs can also be helpful. There have also been complaints from users about others using similar nicks such as variations in spelling or just adding '_' before or after the nick. In this case, try to help de-escalate the situation, but also keep in mind that you cannot ask a user to change nicks just because it is similar to someone else's. There have been cases of a nick registration expiring and another user registering the same nick. In this case, the first user may want to register a similar nick using '_' or other characters, however when the registration is allowed to expire we cannot ask the new registrant to return the nick to the first user. 6.6.3 CHANNEL OWNERSHIP ------------------------ DALnet's ChanServ allows a user to register (own) a channel. At times there are disputes over channel ownership such as when someone has gotten the founder's password and changed it so that the founder is no longer able to control the registered channel. A CSop will be able to help determine who owns the channel and recover the password if it is appropriate to do so. Checking ChanServ logs can also be helpful in determining proper ownership. Please remind users to pick a password that is not easy to guess and to not give it to others. In cases where channel SOP has been given access to the password by the founder and taken over the channel, all you can do is ask the new founder to give the channel back. This is possibly one of the most difficult situations for an IRC operator to mediate, as generally both sides will be unwilling to negotiate. If nothing can be decided between the parties, the ownership right should fall to the new founder. 6.6.4 CHANNEL CONTROL ---------------------- DALnet's Services helps address the problem of channel takeovers, however the attempts continue to become more frequent as well as more creative. Techniques include joining the channel during a netsplit to get ops, talking other ops into giving them ops and even attempts to kill off ops by flooding. By the time the problem comes to the attention of an IRC operator there are usually several very upset legitimate users of the channel as well as at least one determined and often hostile intruder. In most cases it is helpful to ask other IRCops/Admins to assist. This way someone is available to address the questions and concerns from the channel users, while another may address the users attempting the takeover. In rare cases you may also need to ask a services operator (SA) to assist, since they are able to op you or themselves on the channel through the use of OperServ. In situations when a channel's users or ops complain about how the channel is run, the issue should be solved by SOPs and (ultimately) by the founder. The founder has full control over the channel and may run it as he or she pleases. 6.6.5 INAPPROPRIATE BEHAVIOUR ------------------------------ DALnet's goal is "to provide a network where people can talk with each other and enjoy themselves" meaning that "nobody is allowed to flood another user, take over another's channel or otherwise interfere with another user's ability to IRC. Anyone blatantly violating this will first be /kill'd then, if the person persists in annoying other people he/she will be K:lined...". "Annoying, in this context, refers to ban evasion, continued pestering of someone despite /ignores and /bans, and especially flooding." Complaints about the behaviour of others vary and can sometimes be rather vague. The user making the complaint is often upset which can make it harder to objectively state what happened. (It can be helpful to see a log if available, however be aware that logging is also a sensitive issue for some users.) First try to determine what happened as this will also clarify whether it is a channel matter for the channel founder and ops to handle, or something which requires the intervention of an IRC operator. Find out the nick of the individual(s) about which the complaint is made and try to establish contact with them, usually via private messages. There have been situations in which false or exaggerated complaints were lodged during a disagreement so it is helpful to initiate contact in a fair and non-threatening way. The individual may be more cooperative if you begin by asking if there is a problem and how you could help. For example, a user complained that she went to a channel and was harassed in private messages and on channel with profanity and inappropriate remarks then kicked and banned for no reason. Initially the angry channel founder and ops responded harshly giving the impression that they were behaving offensively, but eventually they were able to explain that the user making the complaint had actually been harassing them by coming to the channel with different nicks and being inappropriate toward them all evening. Their patience wore thin and they responded by telling her off and banning her. They were further upset that she then complained about them. The situation turned out to be different than it first appeared on the surface. It is often possible to resolve a problem via private messages, however at times it's helpful to open a channel and meet with both parties there. Keeping distractions to a minimum is best, so the channel should be secret or private, and perhaps invite only. If necessary, this channel may be moderated to further control of the discussion until all involved are able to discuss the matter calmly. Whether on a channel or in private messages, ask both parties to explain what they think the problem is and how it might best be resolved. When identifying possible solutions, try to allow for all possible solutions to be included without judgement, so that everyone will have an opportunity to contribute to the decision making process. This helps you to maintain the role of mediator rather than assume the work and responsibility of a judge / parent / decision maker. Inappropriate solutions will be eliminated quickly when weighing the advantages and disadvantages of each. This helps so that the users are responsible for making the solution work rather than the oper being in the position of enforcer. At the same time, establish a back up plan. In the event that the agreed upon solution fails, be sure both parties know what to expect next, as well as whom to contact with further questions or concerns. In addition to this text, see section 6.5 on policy enforcement for more information on how to deal with specific instances of inappropriate behaviour not allowed on DALnet. 6.6.6 GENERAL GUIDELINES ------------------------- Steps in problem solving: 1. State the problem clearly. 2. Identify possible solutions. 3. Weigh the advantages and disadvantages of each possible solution. 4. Select one possible solution and plan to implement it. 5. Agree to try another if it doesn't work. A large number of problems and conflicts between users are caused because something was not stated clearly. Sometimes it is appropriate to remind channel ops that if users are kicked and/or banned without a reason being provided, it is possible for the user to become frustrated and create even more problems for the channel and its users. This should never be stated as a rule as it is up to each channel to decide how it should be administered, but it is often worth mentioning. Wherever possible, a situation which requires the intervention of an IRC operator should be an educational experience for all parties. Turning a negative event into a positive learning experience can only benefit DALnet's reputation as a friendly and caring one, and this should be strived for. If you feel that JAG or other Admins/IRCops will be consulted about transpired events in the future, try to compile a written summary as soon as possible. This will help prevent any confusion later. Also consider logging the discussions (remember to ask for a permission, or at least state that you are doing so). Please remember too, that while everyone has different values and opinions, in your capacity as a DALnet oper you should strive to remain as objective and impartial as possible. If you feel you are unable to adequately mediate or intervene in a situation, PLEASE ask another oper to help. DALnet's JAG is available to assist in the resolution of disputes which remain unresolved. Please contact JAG (jag@dal.net) for more information. 6.7 TEAM ISSUES ---------------- T = Together E = Each A = Accomplishes M = More The following guidelines apply to all the teams on DALnet: server teams, the functional/service teams, even to the all-encompassing "DALnet Team" to some extent. A team is a group of people that have the same set of goals and objectives. Being part of a team allows the members to have more information and knowledge available to the entire team. This means that where one team member has a weakness, another may have a strength. This provides a greater range of options, and a relief/interchange of duties for all team members. Teams are developed through administrative support. Your superior (admin for operators, team leader for other teams) will be providing you training as an individual, and training in a group. Check with your superior to find out when staff meetings are scheduled. Being in attendance at staff meetings and in formal training is imperative to your success as a team member, whether that is part of a server team or a service team. In these meetings the team will be able to process what they are doing well, and what they should do differently in the future. Updates will be given on changes in services and/or policy. Important things to do when you are part of a team: 1. Keep your ego out of it. It doesn't matter who has the most experience and training. The team works together and uses everyone's knowledge. 2. Don't be afraid to ask questions, or accept constructive criticism. 3. Treat all team problems as confidential, as disclosure of problems often leads to making the problem worse. 4. Stay openminded, and be willing to approach things in a new way. 5. Make suggestions to the team in a way that helps build the team. 6. Follow through on your commitments, and don't drop the ball if you have agreed to do something. 7. Treat all team members with dignity and respect. Successful teams require work, and a dedication to the team you are on. 6.7.1 HELP THE DALNET TEAM --------------------------- In general, try to be helpful, not just to the users but also to the other members of the DALnet staff. If an oper asks for help, please do so if it's possible. If an oper asks for comments in globops about something, see if you can say something helpful and constructive. If yes, consider whether you should make the reply in a private message, or whether it's something that the other opers should see too in globops. If other operators are busy with assisting other users or bringing the net back together, offer to be of some help. Especially at time of busy net times (during prime-time hours, and at times of bad splits) there often are things you can do as an oper. In times of trouble, keep the users aware of the current situation; consult other opers in globops on what is appropriate and whether a wallops for informing the users (and non-opered opers too!) is needed, or even a global notice, if the situation is extremely bad. As another way to help out, make an effort to visit help channels such as #OperHelp and #DALnetHelp, particularly during heavy splits and when Services is down. These are critical times for people requiring information and also the times when channels are the most vulnerable. At the very least, if you are not busy during these periods, try to have the +h user mode set (being a HelpOp). 6.8 PRIVILEGES AND RESPONSIBILITY ---------------------------------- This should be self-evident, but I'm going to state it anyway. DO NOT ABUSE IRCOP COMMANDS. This cannot be stressed enough, never use the special access commands for personal reasons. Another thing that cannot be said too often, THINK BEFORE YOU ACT. And if you can't remain calm and objective, deoper -- it's a very simple way to avoid annoying mistakes. Now that's out of the way, a few words about your position as an IRC operator. As an oper and a member of the DALnet staff, you will sometimes hear things about other people which need to be kept confidential: this may happen in the course of dispute mediation, or disciplining a staff or user, or some other instance. When this happens, do not disclose any personal and confidential information you hear. This should be done so that the individual does not have to suffer from embarrassment or distress, retaining their dignity and respect and allowing them to work through difficulties. Another issue about confidentiality is that you will hear confidential information about DALnet and related issues. Examples of this are the messages sent in globops, and postings on privileged mailing lists. This information should not be revealed to non-staff members. This is extremely important with sensitive topics such as security issues. To discuss another issue, you should remember that some users will "look up" to you just because you are an IRC oper. But being an IRCop is not about being cool, it's about running and maintaining a service. As an IRC operator, you have access to a lot of things which give you "power" on the network. There are a lot of rules and guidelines on how these privileges should be used. However, don't be so scared of making mistakes that you shy away from using your operator powers. Remember, your admin obviously trusts your judgement in using the operator commands and handling position, or you wouldn't be an operator at all. Remember that you are an IRC oper so that you can help run the network. If you don't use the IRCop commands when you have the chance to help out, then you're not being of any help to the network at all. Do what you can to help out, and ask for guidance and help if you are uncertain of how to do something. You learn with experience. Everyone makes mistakes, that's human nature. Try your hardest not to make any, but if you do, follow these simple steps: 1. Do your best to fix what you caused. Tell your admin or a senior staff member about it. 2. Learn from it. 3. Carry on, it's not the end of the world. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 7. REROUTING ===================== - Moving servers Rerouting means changing the configuration (or order, if you prefer that term) of how the servers are connected to each other. This is one of the most complex issues for operators in controlling the IRC network. The difficulty is a combined result of that the used commands are not the simplest, the network's structure is not always easy to understand from the output of /links, and finally, the act of moving servers has a lot of considerations to be taken into account. Additionally, rerouting potentially affects hundreds and thousands of users, and as such it should be done carefully to minimize the amount of disturbance. To be a good router, you need to: 1. Understand how an IRC network is laid out, and how the server links function 2. Know how the commands work (/connect, /squit) 3. Be able to determine the current state of the net - current layout (/links) - pinpoint problem links (/version server.*, /trace nick, /stats l server.*) 4. Know which servers are hubs and which are leafs (this determines which servers can connect each other and which can't) 5. Optionally, be able to determine current Internet connection status with traceroute and ping, and have experience in knowing which solutions work and which don't 6. Decide based on all of the above what kind of rerouting is needed to make things better, if any, and then carry it out In addition to reading the information provided in this chapter, please also take a look at the Routing Manual, intended for all IRC operators, written by bits^ of the Routing Team. 7.1 INTERNET ISSUES -------------------- Connections between IRC servers are in fact established as standard TCP/IP (Internet) connections. This means that they go over Internet (that's where the "I" comes from in IRC) and are affected by the status of the Internet itself. Because of this, Internet routing/connection issues also affect IRC connections. Here is a very brief explanation about that. Data in a TCP/IP connection is sent as "packets", ie. it's split up into small chunks, some additional information (such as the destination and the origination) are added to form a header, and then it's sent to the Internet to be delivered to the target computer. Packets are transmitted over physical lines between "routers", each of which looks at the destination address, and then sends it off over the next appropriate connection to the next router, which hopefully is closer to the destination. This results in a "route" which the packets take between the sending computer and the destination computer. The connection between two routers is also called a "hop", for example, you can count the number of hops between two computers. Packets do not always make it to their destination. A connection between two routers may be down so that it won't work at all. It can also may be saturated or congested, in which case the packets get dropped by a router when they cannot be delivered. Routers may also dynamically adjust how they handle routing, either by manual configuration changes or by automatic changes. This means that if one link in the route between two computers is down, there may exist an alternate route. 7.2 NON-IRC COMMANDS --------------------- When determining whether a particular connection between servers will work, the only way to do it from IRC is to just try it out and see what happens. There is really very limited amount of info possible to get on IRC about the connections. More information can be found out by using two non-IRC commands, ping and traceroute, which are explained here. These programs are widely available for a lot of different platforms, usually as a part of the standard network software package (on Microsoft platforms, traceroute is usually called "tracert"). 7.2.1 TRACEROUTE ----------------- Traceroute is a program for showing what route Internet data packets take when sent from one computer to another, ie. which routers (and thus, connections) they pass through. Traceroute can only get information for routes starting from the computer in which it is run -- if there are computers A, B and C, and you are running traceroute on A, you can see the route between A and B as well as between A and C, but NOT between B and C. Traceroute also gives information on how long each connection between two different routers/computers (or, each hop) takes. 7.2.2 PING ----------- Ping is a program for "pinging" a remote host. It sends repeated packets to the other computer or router, asking for a reply. It is possible to estimate the quality of a link with ping, based on how long the packets take to make the roundtrip, and what the packet loss percentage is (how many of the packets disappear). Of the two, packet loss is the more significant one, as that has much more effect on how well an IRC connection will function. However, packet loss can vary a lot, and routes with higher ping times tend to have more packet loss overall (this is just a general rule and there probably exist a lot of contradictions to it). 7.3 WHEN SHOULD SERVERS BE REROUTED, AND WHERE TO -------------------------------------------------- It is very difficult to give hard and fixed rules for which servers should be placed on which hubs, and how hubs should be interconnected. The overriding rule is "anything that works", and sometimes that can be found only by trial and error. Another good rule to go by is "if it works, don't mess with it". :) Reroutes should not be done lightly, as sometimes keeping the network together is hard enough as it is. As a general rule, operators of the server to be rerouted should be handling it. This is both because they will be the most familiar with the server and its connections, as well as are the best suited for it (local connects are always better than remote connects). If there are no opers from a particular server present, it can be rerouted by any operator. Routing Team members also handle a lot of the rerouting. The Team designs DALnet's routing issues as well, and decides which servers are to act as hubs. You should always keep up to date on the current hubs at least, so that you know what options you have for routing. When deciding if a reroute is needed, it is always a judgement call. The relevant issues are how much inconvenience would be caused to the users (and how many users), vs. what would be the benefits? If the network is running fine without any lag or other problems, there really aren't that many good reasons for a reroute -- only in case a hub is expected to be going down for example. On the other hand, if there have been continuous splits for the past 30 minutes, another reroute is certainly worth doing (even though it would affect thousands of users), if it even has a chance to improve the situation. Experience is an important factor here, it can help a lot. If you haven't done much rerouting, you probably should ask a more experienced oper to help you and give you guidance with the rerouting. Always ask for opinions from other operators! (Even if you ARE an experienced IRCop. See the rerouting procedure below.) This is very important, since other operators may have information that you don't about the situation. It also helps to prevent accidents and mistakes in rerouting, for example rerouting of a "lagged" link which is, in fact, working fine -- while the real problem is elsewhere. Common reasons for rerouting are to get rid of lag, changing to a better link in order to get rid of continuous splits, or to reroute leafs off hubs when that hub is expected to be going down in the near future. These are discussed in detail in the following sections. As a special case, services.dal.net should NEVER be rerouted -- it is not possible to use a /connect to bring it back to the network, if it is missing. 7.3.1 REROUTES TO REDUCE LAG ----------------------------- Servers should be rerouted if there is noticeable lag between two servers, and the lag keeps up for more than a few minutes. The problem is usually in determining exactly which server-to-server connection is the source of the lag. There are several ways to detect this. One of the more obvious ways is to ping a user on the server in question. However, constant pings can become extremely annoying to the user you're pinging. In addition, there may be lag between the user and his/her server (if he/she is connected via modem and is downloading a large file, for example). Instead of pinging, doing a /trace command on a user on the lagged server can be much better, as it won't bother the user in question, as well as letting you know which link it is that is lagging. Another method is to use the "/version " command, or some other command that returns information from the remote server, such as "/stats u " or "/admin ". Using a stopwatch or some other form of timekeeping, see how long the reply takes to come back to you. If it's a few seconds, that's fine. If it's much more than that, then it may be time for a reroute. Try a couple more /version (or other appropriate) commands within the next minute or two; if they come back equally or more lagged, then you can be more sure it's time to reroute. But also do a "/stats l" check (discussed below) before doing a reroute. With the "/stats l" command, you can view connection statistics for the server you are using, or for remote servers. The most interesting value in these statistics is the sendQ, which is the first number on each line right after the connection name. See section 4.1.2 for an explanation of this command. In most cases the command is only meaningful when used on a hub, since usually the connection from the hub to the leaf is the one that's going to be lagged. If you are able to do "/stats l" checks from both sides of the lagged link, it's possible to determine if the lag is "one-way". This means that only ONE direction is lagged, ie. one server has trouble sending to the other while the data going in the other direction is not lagged. Using pings, /version checks or other such commands will not reveal whether lag is one-way or not, since they require a message to first travel one way and then back. DALnet's standard Y:lines allow for a sendQ size of 3.5 million to leafs, and 4 million to hubs (that is, 3.5 million for connections from a hub to a leaf, and 4 million for a connection from a leaf to a hub, or a hub to a hub) -- although these are subject to change. If the sendQ value you see is higher than about half a million, and continues to climb on subsequent checks, then chances are it's time for a reroute. Likely, such a link will eventually split on its own, either with a "ping timeout" or "max sendq exceeded" error. When in doubt, ask someone (a member of the routing team, if possible). :) 7.3.2 REROUTES TO REDUCE SPLITS -------------------------------- At particularly bad times, there may be continuous splits, with servers "splitting left and right": when one server connects, another splits. One reason for this is the "cascading splits problem", when the splitting of one server (or a rejoin) causes a split elsewhere, because both a split and a new connection cause a "burst" of messages sent between the servers. If a connection is strained already, this burst may result in that connection splitting, making the situation worse again. Another situation is where a particular connection between two servers just won't work: the connection gets established, but soon splits again. Because of autoconnects, this can happen over and over again. In both of these situations human interference may make the situations better. Autoconnects are only automated rules for connections, they don't have any kind of intelligence. In order to make a situation better, determining which connections won't work and trying alternatives to them will usually solve the problem. Though, sometimes things settle only with time. A good thing to do is to make sure each connection has been synched before doing the next one, so that the connection bursts don't happen at the same time and place more stress on the existing network connections than they can handle. 7.3.3 REROUTES DUE TO HUB ISSUES --------------------------------- Sometimes it is necessary to reroute servers in anticipation of possible problem situations. For example, if a major hub is expected to go down for whatever reason, it makes sense to reroute all the leaf servers off that hub in advance, one by one. If nothing is done in advance, the leafs would all get split off as the hub goes down, all reconnecting at the same time, causing much more of a strain to the network than had they been moved one by one. Another similar situation is a case when a hub has many leafs, and can't take the load of them all with increasing usage (for example, when time is getting nearer to prime time). In such a case the load may be reduced by rerouting a leaf server or two to another hub. This is something the operators on the hub server usually take care of, as they can best monitor their own server's performance. 7.4 REROUTING PROCEDURE ------------------------ The following steps should be used when rerouting: 1. Determine the need to reroute a server/connection. Find out which connection is the source of problems, if any. 2. Send a globops message about this, asking for comments. If you have a plan or suggestion, state that too. For example, "*GLOBOPS* JoeOper: ohare seems to be lagging on toronto, any comments on moving it to trapdoor?" 3. Wait for a response, if any. Give the other opers at least a couple of minutes to react, there could be lag or perhaps they just are in the middle of something and cannot respond immediately. 4. If deemed necessary (in the instance of a major reroute), send a wallops message. This should also be something that is decided jointly by the opers. If the reroute concerns only moving a single server, another possible method to alert the users of that particular server is to send a server notice (see section 4.2.2). This should preferably be done only when you are yourself using that server. 5. Use the /squit command to disconnect the appropriate link. Use of the /squit command is explained in section 3.2.6. 6. After the link has been squit'ted, use /connect to reconnect the server(s) back in a new location. The /connect command is explained in section 3.2.5. 7. If more than a one server is rerouted, wait for the first connection to synch before starting to reroute the next one. This places less stress on the other network connections. 8. Optionally, make a wallops announcement when the servers have synched up, letting the interested users know that things are working smoothly again. Please note that these steps do not necessarily have to be done by the same operator! Team work can make things much simpler, for example with JaneOper doing the /squit and JoeOper the /connect. In this case, coordination is very important -- if someone is doing a reroute, do not try to "help" out of the blue without telling about it! 7.5 WHAT CAN GO WRONG ---------------------- The /connect command only makes a server ATTEMPT a connection, it doesn't mean one will be established for sure. The following sections list the common (and even some uncommon) errors and things which can go wrong. 7.5.1 AUTOCONNECTS ------------------- It sometimes happens that before you can do a manual /connect, an autoconnect on some server interferes and connects one of the servers in question. Usually this doesn't have even nearly the same effect as what the human was planning, so it can be rather annoying. Your choices are to either /squit the new connection immediately, before it has synched, or to wait and see what comes of it. 7.5.2 NO C/N:LINES ------------------- This may happen if either the originating server is missing a C:line (in which case you get a "host not listed in ircd.conf" error), or if the target server has no N:line for the connecting server (the error would be "no N:line" then). Two servers need to have exchanged C/N:lines in order to be able to connect to each other. 7.5.3 NO RESPONSE ------------------ No response is the a very common error, usually due to bad Internet routing, or because the server computer is down. It means that there wasn't any kind of response to the connect attempt. 7.5.4 WRITE ERROR ------------------ A "write error" means that the target computer is up, but it didn't accept the connection to the specified port. The default port is set in the C:line and on DALnet it is usually 7325, this is used if no port is given in the /connect attempt. There are two common reasons for this error: either ircd is not running, or the remote server thinks that the connecting server already exists on the network (it would display "server already present"). (Related to "server exists", explained in section 7.5.8.) This error could also be the result of a wrong IP-number in the connecting server's C:line. In this case, the connection gets attempted to the wrong computer entirely! That computer is not likely to have an IRC server running, so attempts to connect to the ircd port will fail. 7.5.5 WRONG IP --------------- If the target server's N:line has a wrong IP-address listed for the connecting server, it will refuse the connection. If the C:line has a wrong IP-number, then the error is likely a "no response" or "write error" (see above). 7.5.6 BAD PASSWORD ------------------- In addition to other security measures, in order for two servers to be able to connect to each other, their respective C/N:lines must have matching passwords. The connection will fail with "password mismatch" or "bad password" if the passwords don't match. 7.5.7 I'M A LEAF NOT A HUB! ---------------------------- The "I'm a leaf not a hub!" error means that a non-hub server would have ended up with more than one server connection. Because this is not allowed for leafs, the connection is rejected. This might happen, for example, if a leaf hasn't noticed yet that its uplink connection to the hub has split, and another hub tries to connect to it. 7.5.8 SERVER EXISTS -------------------- Another common error, especially in times of bad routing, is "server exists". This means that the target server thinks that the connecting server already exists on the network (as seen from its point of view). This happens typically when a connection gets split but one server doesn't notice it as soon as another, and then the other tries to reconnect back. It might also happen if some other connection is lagged, in which case the message about the split is lagged too and takes time to reach the "other side of the network". 7.6 REROUTING EXAMPLE ---------------------- Suppose that the leaf server gothic.dal.net is connected to the hub trapdoor.dal.net, and you happen to notice that the connection is badly lagging (you are not using gothic yourself). First you should wait a little while and keep checking, to see whether the lag clears on its own or not. In this case, it doesn't, so you decide that maybe it would help to try to connect it to another hub, for example voyager. You send the following globops about the situation: /globops Any gothic opers here? It seems to be lagging on trapdoor... Any objections to moving it to voyager? You get a few replies saying that it's ok to try to move it. No gothic opers respond who you could ask to do the reroute, so you proceed yourself with it. In order to let the interested users (and non-opered opers) know about the reroute, you send a wallops: /wallops Rerouting gothic from trapdoor to voyager to get rid of lag. Stand by, and sorry for the upcoming split. (In practice, usually no wallops message is sent when rerouting a single leaf, but it is included here for the sake of the example.) Next you disconnect gothic from trapdoor with an appropriate reason: /squit gothic.* Rerouting to voyager After you receive the confirmation that the link to gothic has been squit'ted (and thus, gothic is split from the rest of the network), you go on and tell voyager to attempt to connect to gothic: /connect gothic.* 7325 voyager.* Voyager reports that it has established a connection to gothic, however gothic refuses the connection because "server exists". This is because gothic was lagged from trapdoor, and it still hasn't noticed that the link has been disconnected. Even the message telling that the link has been disconnected is lagged! You try the same /connect command again. Again voyager tells that it has connected to gothic, but this time there is no error message, and the connection holds. You keep watch in case the new connection shows signs of trouble, but the sendQ for gothic on voyager steadily goes down, until it's close to zero and you can get an immediate response to a "/version gothic.*" command. The reroute is now complete. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 8. DALNET ORGANIZATION =============================== - In and outside of IRC As DALnet has grown from a small fledgling net into a full and popular IRC network, the administrative issues have also gotten much more complex. This chapter explains about how DALnet's organization is set up. Also see the explanation of what DALnet is, in section 2.16. DALnet maintains support services for both the users and the administration. With the aid of these services, a lot of the DALnet management actually happens OUTSIDE of the actual IRC network. 8.1 SERVERS, TEAMS AND OTHER GROUPS ------------------------------------ The various DALnet teams and groups form the administrative foundations of DALnet. First, there are the "Server Teams" -- depending on which server you have your primary O:line, you belong to the team of opers for that server. Some servers have tight teams, while others don't make it into an issue at all. The admin of each server has ultimate control on how that server is run, and decides on server-specific issues such as who gets an O:line, what the MOTD message says, etc. Some admins choose to share this with the server operators, letting selected people have access to the config files and asking for opinions from the operators in the server-specific issues. The various other teams and groups can be divided roughly into two: administrative and broad policy/decision making groups, and those which center on providing a particular service or work on a specific aspect of DALnet development and maintenance. The admins of each server form a fundamental DALnet group in itself. Admins are responsible for running the servers, and such they have control over a critical part of DALnet. The main ruling and decision making body is called the Executive Board (EB), which makes decisions on broad network and policy issues. For example, the EB decides on which servers get linked, based on the expressed opinions from the admins. There are a lot of service teams and groups which focus on taking care of a particular DALnet service or issue. The service and development teams are essential to the service DALnet provides to its users. Please, if you have a field of interest or want to help out, consider joining one or more of the groups. There is no general rule for all the teams and groups to decide on membership. Some are open to everyone, some are decided internally by the team, and some choose to only get new members by asking someone to join. If you do not know what a particular team's policy is and are interested in joining it, contact the team and ask. Finally, everyone of DALnet's staff is also a member of the "DALnet Team" -- everyone is dedicated to working for DALnet and making it a better IRC network. 8.1.1 LIST OF TEAMS AND GROUPS ------------------------------- Here is a more or less complete list of all DALnet Teams and groups, with the email contact address for each. The operators for each server may be emailed to the address -staff@dal.net. EXECUTIVE BOARD eb@dal.net - Main ruling and decision making body on DALnet SERVER ADMINS admins@dal.net - DALnet server admins IRCOPS ops@dal.net - DALnet IRC operators ADMINS ADVISORY COUNCIL advisory@dal.net - Advisory council formed of DALnet admins MANAGEMENT COUNCIL (no email) - Council for facilitating cross-team communication JAG jag@dal.net - Judicial Advisory Group, solutions for disputes (focuses on those issues which involve DALnet staff) HELP COMMITTEE hc@dal.net - User help management committee HELP DESK TEAM help@dal.net - The DALnet Help Desk (email help) team GLOBAL KLINE TEAM kline@dal.net - The autokill/abusive user management team MASS MESSAGE TEAM massm@dal.net - Mass message abuse handling team POLICY TEAM policy@dal.net - The team handling policy information issues on warez and child pornography CLOSERS TEAM closers@dal.net - The team handling services-abuse channels MAILING LIST STAFF moderators@dal.net - Mailing list moderators MERCHANDISING TEAM merchandise@dal.net - The Merchandise management team STAFF TRAINING training@dal.net - Staff training administration and trainers WEB TEAM webteam@dal.net - DALnet WWW pages authoring team IRCD CODING TEAM dalnet-src@dal.net - DALnet ircd develepement HOSTMASTERS hostmaster@dal.net - DALnet DNS administration POSTMASTERS postmaster@dal.net - DALnet mail service administration ROUTING TEAM routing@dal.net - DALnet network routing team SERVICES ROOT STAFF service@dal.net - The DALnet Services maintenance and development personnel USER DOCUMENTATION TEAM docs@dal.net - DALnet user help document maintaining and development 8.2 SUPPORT SERVICES --------------------- Since IRC is real-time, it is very hard, if not actually impossible to gather all the relevant people online at the same time. Because of this, the main medium for administrative issues is the mailing lists. In addition to management issues, the support services provide a service to DALnet users and the general public. They offer IRC and DALnet user resources as well as DALnet related information. The most important support services are email (mailing lists and email address aliases), FTP and WWW service. DNS is a mostly invisible, but also a very critical service. 8.2.1 MAILING LISTS, MAIL ALIASES ---------------------------------- Email is the fundamental tool in DALnet administration. (This is somewhat ironic, since an IRC network is a communication tool in itself, yet it cannot be used to fully administrate itself.) Both private and mailing list email are used extensively to handle DALnet administration issues. Because of this, email is a necessity and a requirement for anyone involved in DALnet's administration. If you are not yet familiar with the DALnet mailing lists, or how to use the majordomo mailing list software to subscribe to mailing lists, you should learn about them. As a few pointers, see section 6.1.8 for new oper's actions, email majordomo@dal.net with the word "help" in the body (and nothing else), or visit the DALnet WWW site. Or, ask a friend or your admin to help you. As a note, when posting to the mailing lists, please include your nickname in the signature so that others know who you are on DALnet. Also remember that when you post on the DALnet lists, you are doing so as a DALnet staff member, so you should follow all the appropriate guidelines and rules. Each DALnet staff member is also given a personal email alias, which is usually of the form @dal.net (eg. wizzu@dal.net). This is NOT an email account, it merely forwards the mail to your real email account. Mailing lists and mail aliases are maintained by the postmaster team. 8.2.2 LIST OF MAILING LISTS ---------------------------- Here's a list of the mailing lists you may join as an operator. dalnet The main administrative and discussion list ops The operator list ops-chat The operator discussion list dalnet-announce The (public) announcements list dalnet-outage The DALnet outage notifications list dalnet-services The Services discussion list dalnet-src The server development list helpers The helpers list outage The Internet outages notifications list What each of the main mailing lists are for: dalnet: The main DALnet administrative list. Open to users, mandatory for staff and administration. Ops should be able to bypass moderation. All non-privileged administrative matters should be handled on this list and opened to the public. Owned by Dalvenjah, maintained by the DALnet moderators. ops: A DALnet "ops only" administrative list. Posts should go to this list ONLY when you feel they are of a secure nature and would be damaging to the idea or the network to share them on the dalnet list. Owned and maintained by the DALnet Postmasters. ops-chat: A non-administrative "chat" list exclusively for DALnet operators. Subscription is NOT mandatory. Administrative announcements of network importance should not be posted here. Owned and operated by the DALnet Postmasters. 8.2.3 LIST OF EMAIL CONTACT ADDRESSES -------------------------------------- Here's a list of various email contact addresses (these are not handled by a team, which is why they were not included in the list in section 8.1.1). KEY STAFF - Chief Executive Officer dalvenjah dalvenjah@dal.net - Chief Operative Officer Studded studded@dal.net - Technical Director JoelKatz joelkatz@dal.net VOTING - CFVs cfv@dal.net - Server link/delink votes SERVER APPLICATIONS apply@dal.net - New server applications submit address CYBERCAFE CONTACT ccafe@dal.net - Contact address for cybercafes and other similar sites FTP ftp@dal.net - DALnet FTP service (ftp://ftp.dal.net) contact address WEBMASTER www@dal.net - DALnet WWW service (http://www.dal.net) contact address 8.2.4 OTHER SUPPORT SERVICES: WWW, FTP, DNS, FINGER ---------------------------------------------------- The DALnet WWW pages at http://www.dal.net offer public information about DALnet and related issues. There are also privileged "intranet" WWW pages for the DALnet staff. The WWW issues are handled by the WWW team which may be contacted at www@dal.net. The DALnet FTP site at ftp://ftp.dal.net is used to distribute files related to DALnet. Among other things, it has the current ircd source code, various clients, and help documents. The FTP site is maintained by the ftp administrator who can be contacted at ftp@dal.net. The DNS is a technical service which controls all the names in the dal.net domain. Issues about DNS are handled by the hostmaster team, which can be contacted at hostmaster@dal.net. Finally, there are a few "fingerable addresses". Most notably, the current list of DALnet client servers is available by fingering the address servers@dal.net. 8.3 HOW DALNET WORKS --------------------- All of the above -- lists of teams, services, etc. -- do not go much towards explaining how DALnet's administration really functions. To explain this, first there is a list of the key elements of DALnet's existence and functioning: - DALnet would be nothing without the users (thus, the users make the network) - DALnet servers are operated by the admins, without which there would not be an IRC network at all - DALnet was founded by Dalvenjah, and in the end, the domain dal.net is owned by him (so in one sense, DALnet is Dalvenjah's network) - The Executive Board is the main decision making body on DALnet - DALnet relies on IRC operators and the teams for its operation As you can see, every part is critical. None are overbearing, and they are all needed for DALnet to function. Cooperation is the only way things can work. The administration is based on the following control structure: - Server admins are in charge of their servers - Teams handle various issues, specific to their function - The Technical Director oversees the technical aspects of DALnet - The COO oversees general non-technical operations on DALnet - The EB and the CEO have the highest authority for network decisions And responsibility is laid out as follows: - Operators are answerable to their admin - Individual admins are answerable to the EB - Team members are answerable to the team leader - Teams are answerable to the EB - The EB is answerable to the CEO and the admins (as a group) Servers are linked to DALnet according to the following procedure: 1. Admins wishing to link their server to DALnet must fill out a server application and submit it to apply@dal.net, where it is checked. 2. The finished application is posted to the DALnet mailing list(s) for review and discussion. 3. A CFO (Call For Opinions) is held, in which admins may give their opinion on the prospective server to the EB -- opers may give their views to their admins, before they submit their opinion on the server. 4. The EB votes on the server, based on the opinions of the admins, the information in the application, and on the public discussion about it. 5. Only servers which are linked with this method are recognised as full DALnet servers administratively, and only the admins of such servers are given the rights/privileges/responsibilities of a "DALnet server admin". Additionally, there are a few other methods for linking servers: - The Routing Team may link routing servers (in which case such servers have "-r" in the end of their names), which are always hub-only. - The EB may link servers for testing or emergency reasons (such servers have "-e" in the end of their names). - The Coding Team may link servers for ircd development testing (the server name will end in "-c"). - Admins may run another server, provided that it's at practically the same netwise location and benefits the server in question (typically, running two servers instead of just one, a client server and a hub server). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 9. FINAL WORDS ======================= As the closing section of this rather longish manual, I have a few words by Mikki (also known as WatchMan to some). Thanks for getting this far! - - - Okay... By now you've most likely read all of the above stuff. Y'know, commands, routing, procedures, policies and a load of other topics. Pretty heavy stuff, too. DALnet's got plenty of things that can weigh you down if you're not careful -- in fact, the mere quantity of things this document contains is enough to make your head spin. You can get yourself tangled in all of this technical stuff and never manage to get yourself free enough to take a good look at the big picture. But let me tell you a little something: It's not important. That's right. It's not important. Oh, don't get me wrong -- yes, it's important to know what you're doing, and it's important to do things the right way when you start messing around with that O:line. It's even more important to be able to believe in yourself and know that if something happens, you have the technical expertise to handle it. That'll come with experience. But the truly important bit... Well... all of this is superficial. These are just the means; the tools of your job. What you must figure out for yourself is not HOW to do this job, it's WHY you do this job, and WHAT FOR. Many people never do, and that's why they end up quitting with a bad taste in their mouths. Not that there is anything wrong with quitting, mind you -- but if you do it because you get tired of this job, then something's wrong. It should never, ever go that far. Let me put this another way. Why do I do this job after all these years? Why do I put up with all of the bad stuff that inevitably happens when you work with a large group of people? Why do I -- and I'll be honest here; you're most likely going to witness this stuff sooner or later on the mailing lists or real-time on IRC anyway, if you haven't already -- why do I stick around and do my bit even though at times -- yes, I freely admit this -- I'm so sick and tired of DALnet that the thought of telling everyone to get the hell out of my face and leaving the place for good feels like a really great idea? Why do I play this game time and time again, despite all the things that really bug me? To quote a song, "And I ain't in it for the power And I ain't in it for my health And I ain't in it for the glory of anything at all And I sure ain't in it for my wealth. But I'm in it till it's over and I just can't stop If you wanna get it done You gotta do it yourself." -- Jim Steinman, "Everything Louder Than Everything Else" Well. I've been here for a long time now, and I've seen us grow from a small, private thing which was mostly done for a cheap laugh into a respectable, serious IRC network which gives thousands of people all over the world the chance to talk to each other. Communication -- that's what this place is all about. Forget the talk about merchandising, forget the talk about getting big, public and famous, forget the services we provide, forget all of that. In the end, if you strip us down to bare essentials, we're nothing but a bunch of computers connected to other computers. That's all. We are nothing else -- unless we have people online, using what we provide them with, talking to each other. In this time and age, that's worth a lot more than you might think. Well, it is to me. Not that this is the only reason. I've made a lot of very good friends on DALnet, and if nothing else, to me they're worth quite a bit. Most likely more than any of the other stuff we have here. But that's why *I* do this. What you have to do is figure out why YOU do this. And don't make that into some kind of a complicated process where you spend hours pondering about the Meaning of Life and do your best to figure out where you fit in in the Great Puzzle of DALnet. Just use a bit of common sense and try to figure out what you get out of this thing. For many, it's as simple as having a good time, and there's nothing wrong with that. In many ways, that's perhaps the best, the purest motive of all that I've seen here. There is absolutely nothing wrong with wanting to have a good time. But if you do this for all the glory you get when you use that O:line, or for the network itself, or if you think that you have some kind of a duty here, you're wrong. Whatever glory there may be is greatly overrated and not worth a damn. The network itself is NOTHING without the people on it. And duty...? The only duty here is what you choose to take responsibility for. If you want a hint, do it for yourself. Do it for your friends. And above all, do it because it's a good, fun way of spending some of that spare time of yours. But don't ever let it run your life. That's going to lead to burnout, and you really don't want to join those who quit with the aforementioned bad taste in their mouths. That's not fun at all... and unless you have a good time doing this job, it's not worth much. It's okay to take a break if you need one. In fact, you SHOULD take one when you need one. Don't let anyone tell you that you're not doing your duty -- they're wrong. Your life is more important than DALnet, and the second DALnet starts to eat that life more than it should, you should have a bunch of alarm bells ringing in your head. But, hey, as I said... it's up to you to figure out why you do this. Just make sure that you do. It's worth the trouble. And above all... have a good time, okay? As the man said... "If the thrill is gone, then it's time to take it back." - Mikki Mikko Rautalahti is the official "old fart" of DALnet, and is well known for his tendency to rant about subjects such as "the wonderful art of communication and just why it's such a darn good idea to use some of that every once in a while", "the good old days", "how come no one ever tells me anything" and "the application of common sense in real life and DALnet's internal politics" over and over again. As his hobbies, he fights windmills and tells bad jokes. Reliable sources report that in Real Life, he's just as annoying, only a bit louder. Really. He can be reached at watchman@iki.fi. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The New DALnet Operator's Manual Copyright (C) 1997,1998 by the DALnet IRC Network [End of Manual] ------------------------------------------------------------------------------- IRC: /server irc.dal.net 7000 (also port 6667) The Info on WWW: http://www.dal.net DALnet FTP site: ftp://ftp.dal.net IRC Mailing lists: http://www.dal.net/documentation/lists.html Network! Email: help@dal.net (help), docs@dal.net (help documents), comments@dal.net (comments and suggestions)