The Unofficial Undernet Operators' Manual Release 1 - August 1, 1993 written by Tony Vencill co-oper of pv1628.vincent.iastate.edu This manual is being written in an attempt to provide a consistent set of guidelines to Undernet opers, so that we all may function as a team. However, as this is being written by one oper, even though it will be passed around for comments, it may not completely represent the views of all the undernet opers. I will try, though, to only represent views that I feel are shared by the majority of the undernet opers. Comments and constructive criticisms are always welcome at vencill@iastate.edu (until September 1993 anyway, when I lose my account). The undernet I. What is the undernet? The undernet is a network of IRC servers very similar in form to EFNet, the larger, better known IRC net. The undernet has servers worldwide and is constantly changing in topology. Though the undernet is similar in form to EFNet, it operates on a different philosophy. I will not attempt to lay down EFNet's philosophy, as I personally do not keep up to date on EFNet politics, but the undernet's goal I know. The undernet is an attempt to provide a friendlier, more usuable environment to IRCers, where conversation is not continually interrupted by netsplits or mass mode changes, and where users do not hear "get a clue" when they ask questions. To paraphrase one of the more useless presidents in history, the undernet is to be a kinder, gentler IRC net. :) II. Working together A secondary challenge that has always been with us undernet opers is to work together as a team. In order to provide a friendly environment, it is important that all opers keep up to date on undernet issues, be accessible when problems arise, and spend time on the undernet with other opers and with our small userbase. II.A. Wastelanders A mailing list called wastelanders has been set up by dl, one of our french opers, for discussion of issues relating to the undernet. Discussion on this list has ranged from policy discussions and botkiller alerts to heated arguments and friendly jests. If you are an oper on the undernet, you should definately be receiving this list so that you are not only aware of, but also contributing to important undernet decisions. Note, however, that mail to this list is sent to many people (not just undernet opers) worldwide, and this is not the place for pointless arguing or for getting in the last word. This list is also not the place for flames, which should be sent through personal email, if at all. But it is a good place for discussion of problems and policies on the net. II.A.1. Subscribing to and using Wastelanders To subscribe to this list, send email to listserv@hplyot.obspm.circe.fr, an automated service, and put "SUB wastelanders " in the body with no preceding spaces. For example, when I subscribed, I sent "SUB wastelanders vencill@iastate.edu Tony". This listserv also offers other services and files. For help, send email to the listserv and put "HELP" (no preceding spaces) in the message body. To post to the list, send your email to wastelanders@hplyot.obspm.circe.fr. II.B. Accessibility It is expected, if you run a server on the undernet, that you spend time on the undernet and be accessible if needed. Running a server on the undernet is not just starting a process and leaving, but is making a commitment to be a part of the net and to help it grow and flourish. II.B.1. Be there With IRC windows, with xterm, or with screen, it is possible to be on the undernet at least as frequently as you are on EFNet, if not more. I would encourage you to do the majority of your IRCing on the undernet and to invite your friends to meet you there. This not only promotes our net, but makes you accessible should problems or questions arise concerning your server. II.B.2. Admin information As part of this accessibility I feel that your /admin information (your A line) should contain the nick and email address of at least one of your server's opers. II.B.3. Oper meetings Occassionally oper meetings are called for on wastelanders, and it is expected that all opers show up to these meetings if at all possible. III. Server list A list of undernet servers is always available from me, Tony . This list includes server names, machine names, port numbers, IP numerics, oper nicks and addresses, and versions, among other information. Please feel free to ask for this list but keep in mind I will be losing my account in September of this year. Your server IV. Your ircd.conf If you're running a server on the undernet, please be sure you understand the function of the ircd.conf lines. All these lines are described in the INSTALL file in the doc directory, and in the sample.conf file. The most important lines to know are the I, Y, C, N, H, and L lines. IV.A. Y lines Y lines allow you to adjust your server's behavior to suit different links. You can define seperate classes for servers and clients, seperate classes for servers with different link characteristics, and even classes for opers' connections. Y line stats should be set and adjusted over time to get the best connection possible between servers and with clients. IV.A.1. If you don't have Y lines If you do not use Y lines, please keep in mind that the default values from config.h will be used for every connection, and the MAX_LINKS define in config.h will determine your maximum number of links (this value defaults to 1). This default Y line, incidentally, appears in every server as class 0, unless class 0 is specifically defined in a Y line. IV.A.2. Y line values Please do not use excessively long ping times (10 minutes should be more than adequate for any link, and the default of 120 seconds is recommended at start), and please do not use very short reconnect times (as this makes rerouting a challenge). Also make sure that the fields that define number of connections allow a reasonable number of clients to connect to your server. IV.A.3. Y line format and sample The format of a Y line is as follows (taken from the INSTALL doc included with the server). A sample Y line with recommended values is shown below the general format line. The class number (5 in the sample) is the number that identifies the specified set of stats and that will appear in your I, O, C, and N lines. Y::::: Y:5:120:600:10 IV.B. I lines I lines allow clients to connect to your server. A sample I line and its format are shown below. I:::: I:*::* # or if using Y line 5 for client connections... I:*::*::5 IV.C. C and N lines C lines define to whom you can connect your server and N lines define who can connect to you. They almost always appear in pairs so that all the servers to whom you may connect may also connect to you. Also see the section on H and L lines. IV.C.1. Choosing link passwords The C and N line passwords need not be the same, but the password in your C line must match the password in the other server's N line, and vice versa. IV.C.2. Link password encryption If using link password encryption (ie: if CRYPT_LINK_PASSWORD is defined in your config.h file), then only the N line password must be run through the mkpasswd utility in ircd/crypt/. The C line password must not be encrypted. IV.C.3. Trouble starting your server? I have found that a server might not start correctly if it cannot resolve all the hostnames in its CN lines into IP numerics. If you are having problems starting your server, you may wish to comment out all CN pairs but one and for that pair use a numeric instead of a hostname. If your server starts with this configuration, then you need to find which hostname in your file your server cannot resolve. Alternatively, you could attempt to lookup each hostname using nslookup. IV.C.4. Autoconnects Filling in the target host port field in a C line allows your server to automatically attempt to connect to the named server under the right conditions. If your server gets disconnected, it may try to connect to any of these autoconnects, or if one of these autoconnects gets disconnected, your server may automatically try to reconnect the named server. On the other hand, a C line without a port number still allows an oper to force the connection but will never result in an automatic connection to the listed server. It is recommended that you limit your autoconnects to three servers and that these be undernet hubs. IV.C.5. Connection order When arranging CN pairs in your ircd.conf file, keep in mind that the LAST CN autoconnect pair in the file is tried FIRST and the first autoconnection listed in the file is tried last. Obviously, order will not matter for connections that are not autoconnects. IV.C.6. CN pair format and sample A sample CN pair are shown below with their formats. C:::: N::: C:pv1628.vincent.iastate.edu:rabbits:pv1628.vincent.iastate.edu:6667 N:pv1628.vincent.iastate.edu:rabbits:pv1628.vincent.iastate.edu # or if using Y line 5 for this server connection... C:pv1628.vincent.iastate.edu:rabbits:pv1628.vincent.iastate.edu:6667:5 N:pv1628.vincent.iastate.edu:rabbits:pv1628.vincent.iastate.edu::5 IV.C.7. Hostmasking It is possible to run the net as a number of seperate interconnected sectors using a technique called hostmasking. For example, if every server in canada presents itself to the US servers as *.ca (how a server presents itself is defined in the N lines), and the US servers present themselves to the canada servers as *.edu, then the servers can route normally within their sectors, but only one intersector (us--ca) link can be made. This is useful for minimizing intercontinental or overseas links while still maintaining the flexibilty of allowing many servers to make this connection. However, if a sector is too small, routing within the sector may sometimes not be sufficient and a server may get isolated. An example of this hostmasking is shown below. #in pv1628's ircd.conf... C:newton.ccs.tuns.ca:sheep:*.ca:6667:0 N:newton.ccs.tuns.ca:rabbits:*.ca:3:0 H:*:*:*.ca #notice the H line... *.ca, not newton... #also notice the "3" in the N line. 3 fields (pv1628.vincent.iastate) # are masked by the *, hence making *.edu #in newton's ircd.conf... C:pv1628.vincent.iastate.edu:rabbits:*.edu:6667:0 N:pv1628.vincent.iastate.edu:sheep:*.edu:3:0 H:*:*:*.edu #again, *.edu in H line and 3 in N line IV.D. H and L lines 2.8 servers require the use of an H or L line for each CN pair. If an H line is not provided, an L line will be assumed. Please be sure you have the undernet hubs H lined and not L lined. L lining a hub such as pv1628 could result in your server being unable to connect to the net. If your server is a hub also, then L lining a hub could result in splitting of the net. IV.D.1. L lining 2.8 and 2.7 servers alike allow use of L lines. L lining can be useful for keeping new or untrusted leafs in line, but some opers question its value. Please ask other opers if you are unsure whether or not a server should be L lined. An L lined server is not allowed to connect to any servers besides its one uplink. If your server is L lined, you will want to keep this in mind when defining autoconnects in your ircd.conf. IV.D.2. H and L line formats and samples Sample H and L lines are shown below. L::*:: L:*:*:elm.circa.ufl.edu H::*: H:*:*:pv1628.vincent.iastate.edu IV.E. Q lines Please never use Q lines on the undernet. The use of Q lines can fracture the net. V. Oper password encryption For security reasons, every server should use oper password encryption. There is a define in the config.h file for CRYPT_OPER_PASSWORD which should be defined. This will require you to encrypt your O line passwords, for which there is a mkpasswd program in ircd/crypt/. Encrypting oper passwords makes it difficult for others to find out a password and become oper illegitimately. V.A. Password selection Cracking passwords is not impossible, and it is a good idea to mix letters and numbers or lowercase and uppercase in your password to make it more difficult to crack. V.B. ircd.conf protection For additional protection, all servers that can should make their ircd.conf files readable only to server operators or admins to further reduce oper hacking and to reduce the possibility of server juping by non-opers. V.C. O line sample with encryption A sample O line for me with password "rabbits" is shown below. O::: O:*iastate.edu:7fRcRBJoIwJg.:Tony # or if using Y line 5 for this oper connection... O:*iastate.edu:7fRcRBJoIwJg.:Tony::5 VI. Sysadmin approval It is requested that if you run a server on the undernet you seek approval or permission to run the server from whoever is in charge of the machine on which you plan to run. The undernet has lost a number of servers to admins deciding the servers were not necessary and we would like to avoid this situation whenever possible. VII. Test servers Many opers from time to time desire to set up a test server to test out a new version or patch. The lifespan of these servers should be short, spanning only the time required for the test, and the one uplink for the test server should be the testing oper's main server unless the test dictates otherwise. VIII. Server patches and hacks The servers on the undernet should operate as standard servers from any other server's point of view. VIII.A. Hacks Hacks such as changing server messages or patching server functions for better readibility or functionality for the server's users are not discouraged (to my knowledge) as long as the hacked server appears standard to other servers on the net. Keep in mind, though, that users will not want to customize their ircrcs for each server, so the server functions should probably not be modified. VIII.B. Patches Patches such as the wallops patch and TS patch that effect the manner in which servers interrelate are sometimes encouraged, and if in question you should check with other opers or post a question to wastelanders. At the time of this writing, the undernet is slowly switching over to 2.8.10.TSpre6 (and soon 2.8.11.TSpre6), so the TS patch (which includes many other patches) is at this time encouraged. VIII.C. Reporting hacks and patches In any case, it is appreciated if you report any hacks and patches you make to me, Tony , for note on the server list. Oper responsibilities IX. Oper duties and powers As oper, you have several abilities that non-opers do not. Though some of these, such as rehash, only effect your server, most effect the entire undernet. Thus you should use these powers responsibly and with care to provide a friendly, usuable environment for other users. IX.A. Killing A user should be killed only if absolutely necessary or if requested by the user him or herself. Problems with users should be worked out through messaging if possible. Killing for revenge is not welcomed on the undernet, but examples of necessary kills are for users who are mass killing, users who have hacked oper and are abusing the oper priviledges, users who repeatedly mass kick, and users who are abusive and do not respond to requests to stop. These are only guidelines, of course; in the end the choice is yours, but keep in mind the philosophy of the undernet when excercising a kill. IX.B. Squitting and connecting The commands squit and connect give you the ability to reroute the undernet. The use of these commands, of course, is restricted to the connections that are listed in the servers' ircd.conf file. That is, you cannot connect two servers unless they have CN lines for one another. But even with this restriction there remains much flexibility in the routing of the net. IX.B.1. Squit The squit command disconnects the named server from the server next closest to you. For example, if I am on server B in a net routed as A--B--C--D, and I squit D, the net will break into A--B--C and D. But if I squit C, the net breaks into A--B and C--D. Note this is not the same result that an oper on server D gets when squitting C, breaking the net into A--B--C and D. It is a very good idea to /trace the server you wish to squit before squitting it so you can judge what impact the squit will have on the net. IX.B.2. When to reroute Rerouting can be beneficial at times, providing users with a less lagged connection, but can also be very disruptive, especially if many servers are rerouted at nearly the same time. Though the undernet does have a routing plan, it is not necessary that the routing exactly correspond to this plan at all times. Server outtages, loss of connections, and other events can cause servers to switch to links besides their primaries, and unless these links are especially lagged, servers with clients attached or behind should not be squitted. A netsplit can be much more annoying than a barely noticable lag. There will be times, however, when rerouting is necessary. For example, if a hub is upgrading or for some other reason must shut down or restart, then connections may be rerouted to other servers. This rerouting would most likely provide a better final routing than the chaotic scramble for connections that occurs when a hub with many links shuts down. However, when rerouting, keep in mind the effect on users, and attempt to notify any user who will be effected by the squit. IX.B.3. How to reroute If any rerouting is to be done, after the impact of the rerouting has been assessed with /trace, you should announce your intentions on wastelanders and you should attempt to notify the users that will be affected. IX.B.4. Restarting and dying Please note that the commands restart and die will cause a server to drop all links. Please use these commands responsibly. These commands also have the potential to effect many users of the net. IX.B.5. Squitting to remove a server from the net Please do not squit in an attempt to remove a server from the net, as this is pointless. Squit does not permanently disconnect a server; the disconnection is only temporary. The server will soon automatically reconnect. Squitting is not a reasonable means for dealing with problems on the net. IX.B.6. Squitting for ops Do not squit for ops. This practice is not smiled upon on the undernet. IX.C. Granting links Each oper has a great ability to shape the undernet through his or her server's links. If links are given out to servers haphazardly, then there exists a great potential for chaos on the undernet. Many times servers have been linked which gave rise to problems on the net, including problems such as uncooperating opers rerouting the net and oversights resulting in oper hacking and mass killing. Please be careful when giving out links and please feel free to ask questions of the new opers and of other opers on the undernet. IX.C.1. Some new link guidelines Please be sure when granting links that new opers are aware of the undernet philosophy and are in agreement with the peaceful goals of this net. A questionaire is available on the listserv that all new links should fill out and post to wastelanders to announce their existance and other relevant information. pv1628, as an example, also requires that all its links have opers on wastelanders, have reasonable Y lines, and have opers that are accessible in case problems arise, as I believe I can help shape this net through enforcing certain link standards at my site. It might also be wise, in light of recent events, to ensure that all new servers use encrypted oper passwords. It is encouraged by some, but not all, opers that new links be L lined until they are trusted and have become familiar with the net. IX.D. Granting oper status Please be careful when granting oper status on your server. Keep in mind that opers can have a great effect on the net and that these opers will reflect directly on your server. X. Problems on the undernet X.A. What to do about non-critical oper or server problems on the undernet If you have or notice a problem on the undernet that is not urgent, then the preferred way of dealing with the problem is to either contact the involved parties through IRC or email, or to post the relevant facts to wastelanders. Urgent in this case will mean not tearing the net apart or making it unuseable. Whether you contact the involved parties yourself or post is up to you and will vary from situation to situation, depending on how accessible the parties are, what kind of problem it is, and how large a scope the problem involves. If you do post, you are encouraged to include all the facts and keep personal opinions and emotions to a minimum (or at least flag them as such) so that all opers may see the situation for what it is and make their own judgements. This also will keep us working together and not yelling across the mailing list at one another. X.B. Handling critical problems on the undernet If an oper or server on the net is misbehaving, splitting the net or making the net otherwise unuseable, then drastic measures may be in line. At least twice since I joined the undernet I've seen a server juped (ie: replaced with a fake to prevent the real server from connecting) to solve such a problem. I've also seen a bot set up to autokill a certain user. These methods are certainly NOT prefered methods on our net and should be used ONLY when absolutely necessary. It would also be a very good idea to quickly consult with other opers online before taking such a measure upon yourself. Hopefully, with more cautious granting of links and with the submittal and revision of this manual, such problems will not occur often. This is the end of the Unofficial Undernet Oper Manual. If you have any questions, comments, or suggestions, or would like to see certain material included in this manual, please email to Tony or contact me on the undernet. Thanks.