1

1.0. Preface................................................1

2.0. Terminology............................................4

3.0. Prime Directives.......................................6

4.0. Required Activities....................................8

5.0. Technical Support......................................9

6.0. Server Operation......................................11

7.0. Dispute Mediation - General Guidelines................17

8.0. Channel Dispute Mediation.............................18

A1. Appendix A: Glossary of OPER commands.................20

A2. Appendix B: KILL/K:line AKill Policy..................21

A3. Appendix C: The DALnet Charter........................22

A4. Appendix D: What DALnet Is............................27

1.0. Preface

=================

Congratulations! 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 a

full understanding of DALnet Services. 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 such channels as #IRChelp, #DragonRealm, #help, or

#mIRC, and due to your interest in the success of DALnet as a competitive IRC

network.

From the user end, technical specifics about IRC are impossible to

speculate on, so it can be confusing once you get started as an IRC Server

Operator. This section is meant to explain the basics of the network.

IRC, as you might already know, stands for Internet Relay Chat. IRC

relies on a system similar to most all Internet communications relationships.

A piece of software called a client connects to another piece of software

called a server to transceive information to and from the Internet. For IRC,

many clients have been developed for various platforms. ircII, sirc, SmallIRC,

and TinyIRC for UNIX; Zircon for X-windows (X11); mIRC, Pirch, Netscape Chat,

WSIRC, and irc4win for Windows; and ircle, Homer, and Global Chat for

Macintosh. The server is a program called ircd (Internet Relay Chat Daemon),

which is currently designed to run only on UNIX operating systems.

An IRC network is composed of servers that are interconnected to each

other. There are two types of servers, leaves and hubs. Hubs are compiled

with special options to carry multiple servers at a time, along with many

hundreds of users (these very powerful machines running ircd have

extraordinarily fast internet links and good routes to the Internet backbones

provided by Sprintlink and MCInet). Hubs are the primary uplinks of leaf

servers.

For example, the server glass.dal.net may not be _directly_ connected to the

server dragon.dal.net; however, when one of them is connected to igc.dal.net (a

hub) and the other is connected to skypoint.dal.net (another hub), which _are_

connected, then glass and dragon will also be connnected. To clarify this, a

diagram is provided below:

leaf servers --> dragon rutgers glass groucho

| | | |

hub servers --> phoenix <-> igc <-> skypoint

There are many different networks of servers that are not connected to

one another. The EFnet (or "Eris-Free Network") was started in 1988, about

when IRC first began, and it is the largest and oldest IRC network in

existence. Unfortunately, in the near decade it has been online, it has been

slowed down by its over 20,000 users on more than 8,000 channels.

The EFnet IRC network has hundreds of servers running an IRC daemon that

allows Channel Mode Hacking and other troubling technical difficulties, and

many of its server operators and channel operators are unfriendly. Also, due

to poor routing, netsplits are massive (frequent as well as long). Because

EFnet has no centralized control structure or network-wide agreed upon set of

guidelines for usage, such things as harrassment, lewdness, flooding (both of

users and of channels), flashing, tsunamis, and other nasty modes of behavior

are common experiences.

As an alternative to this popular but troublesome and frustrating

medium, a new IRC Network called the Undernet was formed in 1992, with servers

in the United States, Canada, Australia, and Europe. The Undernet has

attempted to do away with the high consumption of bandwidth and channel chaos

that was caused by a large proportion of users running "bots" (automated

programs used mainly to protect one's own channel against hackers and

netsplits) by setting up what is known as the CService. 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.

The Undernet fails miserably in the department of technical service and

efficient services. The Undernet admins and IRCops on the channel #wasteland

vehemently demand that users go to #CService for help with the often

malfunctioning and difficult to use W/X bots; however, rarely is anyone

there to serve their customers. Additionally, the manual process of

submitting an application to CService to obtain access to the bots is absurd,

due to the sheer volume of requests and the limited manpower available to

accommodate these requests in a timely fashion.

In one area, however, the Undernet does stand out: its innovations and

modifications to the IRC daemon (server) code. Various changes have been made

to help the user, such as disabling mode changes to channels (making channel

take- overs impossible), not allowing users who are banned on a channel (but

haven't been kicked) to speak on that channel, making intentional nickname

collides impossible, re-enabling WALLOPS (for IRC operators), adding to

banlists the nick of the banner and the time of the ban, adding a nick and

timestamp to the channel topic, and other useful features.

The summer of 1994 featured the dawning of a new age in Internet Relay

Chatting. DALnet was launched, using an ircd that began with the Undernet

improvements listed above and added even more useful features. The DALnet

ircd (current version: dal4a) was modified chiefly by Alexei "Lefler"

Kosut ([email protected]); however, current upgrades are written by Russell

"Russell" Miller ([email protected]). Technical innovations from even the

Undernet's outstanding code include:

1. 30 Character Nicknames.

2. Reserved Nicknames (Q:line) enable some nicknames from not being

used by ordinary users (such as ChanServ, NickServ, etc).

3. Network-wide WALLOPS notices (informs all operators of the status of

all servers and not just its own uplinks).

4. Temporary Global K:lines (so that all servers will ban a certain user

mask effectively).

5. Operators on U:line'd servers may change channel and user modes

despite not having operator status on such channels.

6. A new form of global notice (GLOBOPS) only available to operators;

more secure than WALLOPS.

7. HelpOps may go +h to receive messages from users who use a /QUOTE,

/RAW (for mIRC) or /VERBOSE (ror PIRCH) HELP <message>.

And a lot of other useful features. However, what puts DALnet at the top

of the heap of other IRC nets is Advanced User Services!

Coded in early 1995 by Brian "Morpher" Smith ([email protected]), DALnet

Services allows users and operators alike to enjoy the luxury of Channel and

Nickname Ownership via ChanServ and NickServ, and with MemoServ has made the

ircII /NOTE command obsolete. The key flaw in Undernet's X/W bots is that they

*are* bots, that literally must reside on each channel and act as omnipotent

operator with a U:line, monitoring literally thousands of channels. ChanServ

is superior in that all communications between it and the user are handled by

the pseudo-server services.dal.net, which is designed to connect to the hubs

for its uplink as well.

ChanServ'S completely automated channel registeration eliminates the

lengthy application process. ChanServ is easy to use, very responsive, and

above all provides seamless channel security that Undernet's X/W bots cannot

always provide.

And beyond mere Channel Ownership, DALnet provides its users with the

ability to own their own nicknames by registering them with NickServ.

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 users

can click on your web page or E-Mail you from the DALnet Web Site

(http://www.dal.net/ under "Registered User Pages"). NickServ registration

also enables users to use MemoServ to leave brief online notes to each other.

Some IRC Operators, mostly Server Administrators, are given further

control over DALnet, primarily in the area of ChanServ and NickServ. On

DALnet, do a /MSG OperServ HELP for more information while you have your

IRC-Operator status activated.

HelpServ, NickServ, MemoServ, ChanServ, and OperServ (collectively

referred to as "Services") are maintained by upgrades from Michael "Aetobatus"

Sawyer ([email protected]) and David "JoelKatz" Schwartz.

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 at a favorite channel.

For more information about DALnet policies, read the Charter in Appendix

This manual might include instructions about how to do things you already

know how to do. Please browse through these as well, since there might be new

features or details you have yet to be aware of. As an operator, you are

generally exptected to know the things explained here, so please, even if you

feel like you already know some parts, read through it all.

2.0. Terminology

=====================

Now that you are an operator, you're going to start hearing a new lingo

different from ordinary IRC language (such as user masks, netsplits, etc).

Let's start simple (with what you already know).

2.1: Netsplit.

As stated before the Internet (in America) is a network of sites and other

hosts, machines, et cetera that are all interconnected via a real-time

connection using various sets of protocols listening on several types of ports.

Between these sites are local area network links provided by the city's data

network (usually, fabricated by the local telephone company such as Pacific

Bell). From there, that network connects to the Internet Backbone which spans

the country which is usually a network of T-3 connections bought by MCInet and

Sprintlink. Due to the fact, though, of increased usage, these ultra-fast

fiber/optics links are getting bogged down and thus it takes longer than usual

for a TCP packet to reach one point to the next.

The servers that are connected between each other require this

telecommunications network (like everything else on the Internet) to be

physically connected. And due to the highly _time sensitive_ nature of this

connection, if there is a lapse of contact between two servers (due to the drag

on the net itself), one of them disconnects with a WALLOPS stating "Connection

Timed Out". When this happens, it is called a netsplit because users on the

server that was lagged "disappear" from the rest of the network right along

with that server's existance. Once the server re-establishes its connection,

the status of what the channel was before the netsplit on the splitting server

resets the current status of the channel throughout the DALnet (topic and mode

corrections are made to accommodate the split server). Here is another diagram

to illustrate this:

Before A Net Split.

[User1]

+--Leaf-----[User2]

| [User3]

Hub -|--[User7]--[User8]-[User9]

| [User4]

+--Leaf2----[User5]

[User6]

After A Net Split.

[User1]

+--Leaf -[User2]

| [User3]

Hub -|--[User7]-[User8]-[User9]

[User4]

Split-Leaf2--[User5]

[User6]

To Users 1, 2, 3, 7, 8 and 9 Users 4, 5, 6 signed off because Leaf2 split

from the net (DALnet). A Hub split is worse because when the hub goes, all

leafs on that hub disappear with it and thus all 7 users disappear from anyone

else who might see them from another hub.

2.2: AKill

Using services, a services operator or administrator may instruct Services

to automatically KILL a certain user who appears on the IRC with AutoKill.

This is a messure created in order to keep users from "jumping servers" to

avoid temporary K:lines set by operators in the event they must be banned from

DALnet for various reasons further illustrated in this operator manual.

2.3: Lines

Each server has a set of lines configured for various purposes as seen

below:

A:lines -- Specifies what information is seen when /ADMIN is typed.

C:lines -- Specifies which servers it can connect to.

H:lines -- Specifies which servers are to be considered hubs.

I:lines -- Informs the server which clients are authorized to access the

server.

K:lines -- Defines to server which clients are prohibited access to the

server (banned).

k:lines -- Defines to server which clients are prohibted access to the server

temporarily (set by IRCop).

L:lines -- Specifies which servers are to be considered "Leafs".

M:lines -- Specifies the server name, description and port number it is

configured to answer on.

N:lines -- Specifies which servers it will accept connections from.

O:lines -- Informs the server which clients can access operator commands.

o:lines -- Informs the server which clients can access operator commands

(restricted to local server commands; eg., /KILL will only work on

users on the server the operator has an o:line on)

P:lines -- Sets which ports the server may listen on (ports below 1024

[within the Internet Port Range] requires ircd to be run from

inetd].

Q:lines -- Informs server which nicknames cannot be used on that server

(one of two types of Q:lines).

U:lines -- Informs the server 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 -- Specifies how the server accepts connections.

2.4 Services.

Refers to a program that operates as a server which runs ChanServ,

NickServ, MemoServ, HelpServ and OperServ.

2.5 WALLOPS.

A message sent to all operators (any user who is usermode +w). Operators

may send a wallop themselves, however, these are now reserved for mainly server

messages. Server Notices are now used to share messages with all operators.

Information on these commands is available later in the document.

2.6 GlobOp.

A message sent to all operators (any user who is usermode +og). Replaces

WALLOPs. Ensures all (and only) IRCops receive an important bulletin.

2.7 Global.

A NOTICE message sent to all DALnet users online. It also might refer to

the GlobOps command created to replace WALLOPS, see section 6.4).

2.8 DALnet.

It is -just- DALnet, not "The DALnet," "DALNet," Dalnet," "DalNet,"

"dalnet," "dal.net" or "The" behind any of those either. It is JUST: DALnet.

3.0. Prime Directives

==========================

This section briefly covers all of your duties as a DALnet Server

Operator. As more details will be explained in the sections below.

3.1 Conduct.

More important than understanding how to use OPER commands, DALnet was

founded upon the idea that what makes or breaks an IRC Network is its

operators. Unlike the competition, we have organization and a sense of

responsibility to our users to provide a save haven where they can talk about

whatever they choose without threat of opposing forces knowing there are no

IRCops around to protect them.

A Server Operator's chief responsibility is to provide speedy and

high-quality assistance to any user who is in need of help courteously. In the

event, however, you may not be able to provide such service, please direct them

to #DragonRealm and perhaps any currently on-duty operator that you might know

will be able to help them.

3.2 Promote DALnet

In your USENET posting, include in your .sig _brief_ instructions on how

to get there (usually something along the lines of: "Nickname" on DALnet IRC.

Use server irc.dal.net at Port 7000). Include this in personal E-Mail as well.

In your own web pages, include a link to the DALnet Web Site at

http://www.dal.net/ -- it would help to include a little info on how to get

there as well as some crucial information (such as services, friendly ops, less

lag and splits).

Set up your own IRC Channels on DALnet and tell all your friends to come

up to DALnet. If you can, talk to local computer magazines.

3.3 Provide Technical Support.

Whenever a user asks a question about IRC or DALnet and/or its services,

please attend to their needs if nobody else assists them first. Due to the

redundant nature of some Frequently Asked Questions, scripts (provided within

this User's Manual) for ircII users will be able to provide speedy, yet

in-depth service to such questions as how to register a channel or nickname.

3.4 Policy Enforcement.

DALnet can be best known for being actively involved in matters involving

its own network. Users should be able to feel free and come to any IRC

Operator about any person who is harrassing them. If a user is found in

violation of DALnet Charter and or the policies of the server that the user is

residing on, they should be warned fairly obviously at least twice. Then, they

should be forcibly removed from the IRC Network. If the user persists by

returning to the IRC and continues his/her offensive behavior, a temp K:line

should be engaged.

3.5 Network Restoration.

In the rare event of a netsplit, servers are automatically made to

reconnect. However, sometimes a server will disconnect and not re-connect on

its own. Unless another Operator gives you good reason to not do this,

re-connect the split servers. More details on this later.

3.6 Re-Route to Reduce Lag.

Lag is one of the ugliest trademarks of the EFnet IRC network and it is

caused primarily due to poor routing (also the cause of its netsplits).

Occasionally, users on a server that is lagging will be experiencing lag due

being connected to a hub which has a high-traffic route. For example,

glass.dal.net will be connected to mindijari.dal.net and because mindijari's

link is slow to DALnet or the link to glass.dal.net is slow, I might need

to re-route. Proper procedure on a re-route will be listed in section 6.10.

3.7 Help the Team.

If other Operators are busy with assisting other users or bringing the net

back together, offer to be of some help. For example, services may be lagging

and needs restarting (usually after a netsplit during prime-time hours). Keep

the users aware with global notices. For more on how to do globals, see

section 6.0.

4.0. Required Activities

=============================

Having an O:line means you now take on the responsibity of being a DALnet

Server Operator. These responsibilities are as follows:

* Subscribe to DALnet Operator and Administrator Mailing List. Please

be aware that DALnet Admin Mailing List generates varying magnitudes

of volume. To subscribe, E-Mail [email protected] and put in the body

of the message 'subscribe ops' (without the quotes).

To post to the mailing list, E-Mail [email protected].

* Visit #Operators, #DragonRealm, #DALnetHelp (and if you're an mIRC

user) #mIRC daily. Understandably, real life may not always permit

one to constantly be on any one of these channels hours at a time

every day, however it is expected for operators to remain in at

least #DragonRealm once a week (not idle).

* E-Mail [email protected] and request you are given a @dal.net

address and are added to the <servername>[email protected] mail queue.

Usually, your nickname will be made into the username, however, you

can specify what it will be. Also, be sure to register your nickname,

if you haven't already, with SET KILL ON.

Mailing Lists that Operators are encouraged, but not required to join are:

dalnet (General DALnet Mailing List)

dalnet-services (For Questions, Comments and Suggestions about Services)

To subscribe to these, just E-Mail [email protected] with

subscribe <list-name>

in the body of your message.

5.0. Technical Support

===========================

Due to the sophisiticated nature of the inner-workings of DALnet, IRCops

are usually not required for such mundane tasks as fixing netsplits and such

like, however, there never can be too many people to answer the questions of

new users and experienced ones alike on DALnet. And as such, IRCops' primary

responsibility is to be as helpful as they possibly can be.

Please be courteous to users and refrain from using foul language. We are

all human and are likely to curse once or twice during our lifetimes, however,

people of all ages come and we cannot afford to lose users because parents

think this is a bad place to be. Also, it also represents us as irresponsible

and vulgar. And, once again, please be friendly to a user asking a question.

There is no question worth yelling at them for, just remember, you were a

newbie once yourself.

Always drop idle conversation in a help channel such as #DALnethelp or

#DragonRealm to assist a user in need. If you do not know the answer to a

question, say so (one of the main frustrating elements to other help channel is

that when nobody knows the answer, they don't say anything). If you know

anyone on IRC that can help them, direct the questioner to them.

Study your client more. ircII has practically hundreds of commands that

can be twiddled with to produce enumerable results, so with the right sort of

knowledge, you can help users do advanced tricks such as how to check idle

times for users on a server different from theirs, set events on timer

or using /on commands, et cetera. Advanced expert users of PIRCH and Macintosh

IRC Clients are in _high demand_.

Study the three main services (ChanServ, NickServ and MemoServ) so that

when users ask you questions about how to do unusual tasks such as add other

addresses to their nickname access list or change founders of their channel,

you may be able to give them proper information.

Do not idle in #mIRC, #DALnethelp, or #Dragonrealm. Users who join a

channel, ask a question and get no answer merely become frustrated and leave --

most likely to never return. DALnet, still in the process of growing, doesn't

need to lose its users and even worse, it projects a bad image of an

irresponsible IRC network.

During a crisis situation such as major technical failure (eg.,

services.dal.net netsplit from its connecting server or constant netsplits due

to an Internet backbone outtage), change the topic in #DragonRealm to reflect

these changes. A sample topic would look like this:

*** Topic on #DragonRealm: Services is temporarily unavailable, please stand by

for futher information. Welcome to DALnet Admin/IRCop Channel; if you require

help by from an Operator, please ask your question and wait _patiently_ Thanks.

Also, for your convienience, program yourself an alias to type whenever

someone asks about services in #DragonRealm. Remember, once services goes,

hundreds of people will start to notice (even after the global is sent out, new

people will sign on who didn't see it and will ask about it). Here is a sample

alias.

/alias blah say Services is down, it will be back very shortly.

Please remind users that IRC and/or DALnet related questions are only

answered in #DALnethelp and that to direct their questions for other things to

other channels (#win95 or #windows95 for Windows or visit http://www.yahoo.com/

for WWW info, etc). As time goes on, the volume of questions to innundate

these channels will continue to increase and IRC questions take priority over

those that may be answered in other areas. To ensure this reminder, set the

topic on either channel accordingly. Here is a sample topic:

*** Topic on #DragonRealm: Welcome to DALnet Admin/IRCop channel; if you need

help from an Operator, please ask your question, wait _patiently_ for your

answer or E-Mail [email protected] - thanks.

Keep these URLs handy:

http://www.dal.net/

http://www.eyecandy.com/irc.html

http://www.mirc.co.uk/

http://www.ircle.com/

These sites provide for an invaluable source of IRC Information for the

expert as well as the newbie. New information is constantly being added to

these sites as the realm of IRC expands. The first site is DALnet's official

web sites containing primarily information about DALnet history, how

to run a server, its charter, information about its services, links to

registered user and channel pages (as specified in the URL section in both

NickServ and ChanServ) and links to important documents such as FAQs.

www.mirc.co.uk is the mIRC World Wide Web site. Not only can the client

itself be downloaded from here, but there is a lot of information here for

people using this client. If you don't use mIRC, please direct users here.

www.ircle.com serves the same purpose.

www.eyecandy.com provides useful information on scripts and bots. These

are in great demand, however, due to the wide variety of scripts and bots as

well as platforms they operate from, it is nearly impossible to speculate,

and/or give accurate help on these as you might with an IRC client or DALnet

service. Direct users to investigate their options at the Eye Candy site.

5.1 A Word on Scripts and Bots.

Scripts were designed to augment the abilities of an IRC client by using

optional features already within the client to perform many advanced functions.

However, one isn't required to run a script in order to use IRC. It may be

loaded optionally, however, please advise users who wish to use script to

examine the code carefully _before_ using it. Scripts may or may not

intentionally or unintentionally contain backdoors. Most scripts that are

obtained from their source distribution site (such as the FTP site of the

author) rarely contain hidden backdoors for them to gain unauthorized access to

your account, however, in using a script, there is _always_ a security risk.

A bot, simply put, is an IRC process holding a connection to an IRC server

that is operating without the attention or usage of the person who started the

connection. An mIRC fserve may be considered a bot due to the fact that it is

designed to operate without the attention of the person who started mIRC, for

example.

Bots are like knives. They can be used to help and they've also been used

to hurt. Prevalent on EFnet, there are clone bots, nickname-changing flood

bots, hack-bots (designed to steal ops on channels), etc. Also, there are

useless bots such as vanity bots, op-hog bots (bots that join empty channels

just to have ops) cafe-bots (bots that use action commands to serve food and

drink) or bots that don't do anything at all! But of course, there is the

rare exception of a good bot. Linkbots (such as Alpha_5 on #MMPR or DNB on

#AFD), GameBots (such as RobBot, the Risky Business host of #RiskyBus) and

others. Users should ask themselves, "Do I really _need_ this bot?" Remember,

IRC is for _chatting_ and unless this bot augments that purpose, it is useless

and frowned upon by most users -- especially server admins.

Make clear to try and get permission from the administrator of a server to

use a bot on their server, even if they have an open-bot policy. Respect a

server admin's right not to have bots on his server. On DALnet, there are some

servers that take them (unlike with other IRC nets).

Remind people who think keeping a bot in their channel to keep it on the

/LIST to get users to join that users who join a channel with nicknames listed

but with no talking become quickly frustrated and leave the channel, not

likely to return. It is best to keep the channel empty and when there are

real people there to talk, people will join and stay.

And finally -- bots, TOO, can have backdoors and security risks. It's best

to get good enough to write their own codes for scripts _and_ bots, however, if

they insist on using somebody else's code, let them know to please examine it

carefully. Just like in real life, there are people out there with nothing

better to do than to make other people's lives harder than usual so caution

such users to beware.

5.2 And now for the answer to the all-burning question: How do I become an

irc cop?

Express, firstly, that we are _not_ cops or police in any form imaginable.

We are no different that a technical support representative and service

technicion all in one. We can remove users in violation of our charter,

however, we never are on patrol and go bot hunting, et cetera.

Secondly, you don't ask. An O:line is given to a user that the admin

trusts, is friends with and knows for a fact cares about maintaining DALnet

and making it grow as a competitive force on the Internet as an IRC network.

Not someone who just wants "power" over other users.

Finally, if you're seen by various admins helping out on a regular basis

in #DragonRealm or any other IRC channel over a period of months and you

express an interest in DALnet affairs, then someone may consider making one an

operator, however, the final word on the issue is that it shouldn't be

expected.

Use your own words (obviously) but this is the opinion that can be found

amongst most all server administrators everywhere.

6.0. Server Operation

==========================

This section covers the aspect of using operator commands. A full list of

commands is listed in Appendix A. Now listed below is how to do a global

notice. This is the IRCops' "bull horn" to alert ALL Users on DALnet to DALnet

matters such as situations with services, netsplits, re-routes or other

important news. It should not be used to advertise one's own web site, channel

or other personal and otherwise non-Urgent DALnet related matters. To do one,

type:

/NOTICE $<top-level> [NET BROADCAST] <Your Text here> (Please do not reply.)

Everything after the toplevel domain is the contents of your message,

however, in order to keep from receiving hundreds upon hundreds of /MSG's from

users cluttering up your screen, inform them this is a Network-Wide Notice

(such as that above) and at the end, politely request that nobody replies to

it.

The toplevel domain can be specified in many ways. You can send a message

to all servers on DALnet, all DALnet servers in one country or state and to

even one server. Here is an example

$*.dal.net (or .net) -- Since all DALnet servers end in .dal.net, this will b

networkwide.

$*.[country-code].dal.net -- For example: $*.us.dal.net will send a notice to

just American DALnet servers.

$*.[state].[country].dal.net -- For example: $*.ca.us.dal.net will send a

notice to mindijari, davis, voyager, spider and

cyberverse in California (as of the print-date

of this document).

$[server_name].[state].[country].dal.net - This will send a server wide notice

to which ever server is specified.

ATTENTION: Do a GLOBOPS _prior_ to sending a network wide notice; this is

imperitive to avoid two operators simultaneously sending globals (repeated

globals aggravate users and users become highly irate so it is wise to space

them out). See section 6.4 on how to send a GLOBOPS.

6.1 OPER

This activates your usermode +o so you may become an IRC Server Operator.

To deactivate your IRCop status, type /MODE <your_nickname> -o. However,

because OPER automatically turns on usermodes o, w, s, g, to turn them all off,

you type /MODE <your nickname> -owsg. To use OPER, type /OPER followed by your

nickname and/or password or just type /OPER, press enter and then enter your

password (ircII will not echo your words to your screen).

A local server notice is given when O:line is activated. A globops is sent

when an OPER attempt fails.

6.2 CONNECT

This command is used to connect (or re-connect) servers. Here is a practical

example in which this command may be most in use. dreamscape.dal.net's link to

phoenix.dal.net timed out (You will see: !phoenix.tx.us dal.net! No

response from dreamscape.ny.us.dal.net). This will preclude a netsplit (as

described above). If you were the operator on dreamscape, you would type:

/CONNECT hub*

<hub> maybe replaced with either phoenix, spider, firehouse, voyager or

skypoint (preferably tried in that order). Usually the server that split from

the network reconnects on the first manual /CONNECT request made. Most of the

time, a server has auto-connection queues configured to execute the best

possible connection for it's best uplink.

In another situation, if you were on any other server and dreamscape split

away from the net, you would type:

/CONNECT split_server.* 7325 hub.*

So, in this example, you would type /CONNECT dreamscape* 7000 phoenix.*.

Please note, situations vary wildly so after seeing a few other operators do

some manual connects, I recommend you ask another operator to assist you in

fixing netsplits. 7325 refers to the DALnet port number, you must put this

here when connecting two servers remotely as seen above.

Keep in mind, servers rarely connect on the first try so try different

hubs as the connections fail. If after two cycles through all available hubs

the server doesn't reconnect, wait a while to see if the connection will

re-establish itself and if not, E-Mail the admin -- the process may be date or

the machine might be down.

As the Internet is a dynamic organism of movement, so is DALnet and as

such, the state of hubs in the network can change. It is best that one keeps

up to date by reading E-Mail from the DALnet Mailing List.

6.3 DIE

Sweet and simple. DO NOT USE THIS COMMAND. For ircII users, I STRONGLY

RECOMMEND you replace DIE with an alias. Here is an example:

/ALIAS DIE /ECHO *** If you're sure you wish to use this command, use: /TERMINATESERVER.

/ALIAS TERMINATESERVER /QUOTE DIE

Feel free to replace TERMINATESERVER with any extremely long command that

cannot too easily be typed. /DIE causes ircd to STOP dead in its tracks.

Just completley and totally kill the process. 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 you from IRC and you will have to

reconnect to another server until the admin restarts ircd.

6.4 GLOBOPS.

This is the dal4+ replacement for WALLOPS. To reduce lag and

probability of users seeing these messages, a new user mode (+g) has been

implemented in the new ircd code. To see these messages, merely OPER

yourself or type /mode <your_nickname> +g. To send one, type:

/QUOTE GLOBOPS :<your message here>

In mIRC, the syntax is: /RAW GLOBOPS :<text here>

In PIRCH, the syntax is: /VERBOSE GLOBOPS :<text here>

A sample mIRC alias would be: /GOP /RAW GLOBOPS : $+ $?

6.5 KILL.

This command manually removes a user from IRC (if you are a local

operator, only your server). This command should be used only when required.

In the case where a user is evading a ban or /IGNORE, impersonating services or

an IRC Operator and various other scenarios covered by the Charter in Appendix

C, an IRC Operator is required to warn the offender AT LEAST _twice_ before

administering a KILL. KILL, though, is still rather ineffective due to the

ability to auto-reconnect to the server. In the case of clonebots or

floodbots, a quote kline may be used to keep them from repeatedly connecting.

To remove a user from the DALnet, type:

/KILL <nickname> <Reason>

KILL will not work without a reason being entered. A KILL will work on

a nickname, even if one changes their nickname within the last 90 seconds.

-> KILL's MAY NEVER BE USED IN A PERSONAL VENDETTA <- You will lose your

O:line immediatley.

6.6 KLINE.

IRCops may temporarily K:line a user or user mask from a particular

server. This is the last resort, however, it is the most powerful defensive

system an IRCop has in his or her power to engage to protect the DALnet from a

repeat offender with malicious intent or operating clonebots. (CloneBots are

users with absurd nicknames such as YGGDRAZIBA or EEUMNIWCHA that sign onto

the server from the same host dozens and dozens of times over in a row at an

exponentially quick speed.) K:Line's may be engaged as such:

/QUOTE KLINE <nickname> :<optional reason here>

(In mIRC it is: /KLINE <nickname> :<optional reason here>)

(In PIRCH it is: /VERBOSE KLINE <nickname> :<optional reason here>)

Or...

/QUOTE KLINE <user mask> :<optional reason here>

(In mIRC it is: /KLINE <user mask> :<optional reason here>)

(In PIRCH it is: /VERBOSE KLINE <user mask> :<optional reason here>)

User masks are composed as such:

[email protected]

or:

[email protected] (An IP address)

Nicknames vary and now more and more clonebots have been surfacing with

username morphing as well, so often times an entire site must be K:line'd

(however, this should be considered a last resort as K:line'ing a site

potentially bans hundreds of users from the server you operate). An ordinary

K:line would be constructed as such:

/QUOTE KLINE username@*.site.domain

(domains can look like .com, .edu, .net, .org, etc...)

or for IP-addresses, form your K:line as such:

/QUOTE KLINE [email protected].*

(The fourth group of numbers after the first three groups changes in dynamic IP

addresses).

For example, let us pretend clonebots are coming from

[email protected]. Chances are, slip3 and dialup5

varies and so will that bogus nickname ZZTJPOOB. So, a proper K:Line that will

stick (even if the user hangs up and calls back to use a different slip or what

not) would go: *!*hash@*.infolink.net and they will not return.

Most clonebots, to try and stall IRCops and Admins with confusion, will

try and go IP'd so ZZTJPOOB might come in the form of:

[email protected]

A safe K:line would be: *!*[email protected].* E-Mail [email protected] with

the address temporarily K:line'd so that all servers may carry the K:line (to

prevent server-jumping on the part of the clonebot). Fortunately, however,

services now comes with built-in clonebot detection so manual elimination is

made easier (see ftp.dal.net for ircII and mIRC scripts for mass /KILL'ing).

6.7 LINKS

Links will display all servers presently connected along with their

uplinks. See ftp.dal.net for scripts that makes links to be intelligible to

IRCops. Usage is: /LINKS [Enter]. Or /LINKS server_name* (to bring up one

server and its uplink).

6.8 REHASH

This makes ircd re-load its ircd.conf file. This needs to be done

whenever the server admin changes information in the file and needs to reflect

these changes within the server. Rehashing the configuration file will clear

any temporary K:line's not permanently set within ircd.conf.

6.9 RESTART

This restarts the irc daemon. This command is similar to /REHASH because

it updates any changes that are made, except, /RESTART reloads the binary into

the machine's memory updating any changes in it rather than just ircd.conf

6.10 SQUIT

This means ServerQUIT and that allows operators to deliberately disconnect

one server from the rest of DALnet. This is also can be a highly volatile

command should the operator using it have no idea what they are doing.

Remember, you will lose your O:line if you use SQUIT for unofficial matters.

SQUIT is used most commonly for re-routing servers to avoid lagging

connections. Here is a practical example of proper usage of SQUIT.

cin.dal.net is lagging while on skypoint.dal.net. First, do a GLOBOPS

warning on-duty operators of your intentions. If there are no objections

within a reasonable amount of time (especially from the admins of the servers

you are re-routing with), do a network-wide notice. Using the /NOTICE $*.net

command, here is a sample re-routing global:

[NET BROADCAST] Due to lag to cin.dal.net, I am re-routing it off

skypoint.dal.net to firehouse.dal.net. Please stand by and excuse the

netsplits; thanks. (Please do not reply).

Once you've sent this, type:

/SQUIT servername.<state/province>.<country>.dal.net <reason>

or you may use a wild card (eg., /squit cin.* Re-Route; it will squit the full

server name: cin.il.us.dal.net).

SQUITs will work without a comment, however, a reason is put there to

make sure operators who weren't paying attention know what is happening. After

cin has disconnected a WALLOPS will appear saying SQUIT received by

cin.il.us.dal.net. At which point, quickly, reconnect cin to firehouse (or

whichever server is recommended or is lagging the least by personal estimate)

using:

/connect cin.* 7325 firehouse.*

Skypoint will send you a notice telling you it is attempting to connect to

cin.*. Of course, occasionally, things will differ from the "game plan" so

improvisation is necessary (try using another hub to connect to cin). In any

case, once cin.* is reconnected (hopefully successfully), send out another

global. Here is a sample global to send.

[NET-WIDE NOTICE] cin.dal.net has been succesfully re-routed to

firehouse.dal.net from skypoint.dal.net -- appologies for the temporary

interuption of service. Thank you for using DALnet. (Please do not reply).

This is is a pretty long and drawn out process and should not be

administered unless one is personally experiencing intolerable lag or there are

lots of complaints about it. Otherwise, it's best just to leave the servers

alone (seeing as it is hard enough as it is to keep the servers connected).

6.11 TRACE

Trace lists all the users connected to the server you are currently an

Operator on. For a full description of this command, type /HELP TRACE while on

IRC. See ftp.dal.net for scripts that enables multiple uses of TRACE.

NOTE: .dal4+ implemented that operators can see users who are +i with the /who

command (and any of its switches). Such users will be marked as % after

the H or G.

6.12 UNKLINE

In the event a temporary K:Line needs to removed, a user may administer

the following command:

/QUOTE UNKLINE <user mask> or <nickname>

(In mIRC it is: /RAW UNKLINE <user mask> or <nickname>)

(In PIRCH it is /VERBOSE UNKLINE <user mask> or <nickname>)

It will only be removed if the exact same user mask and/or nickname that

was K:line'd is entered. To see the list of K:line'd users masks, use /STATS K

or /STATS K server_name* (if you're not on the server you wish to check). Temp

K:lines will be listed with a lower-case 'k' and permanent K:lines will be seen

with a captial 'K'. 'A' indicates a Services placed K:line (AutoKill).

This may only be removed by Services Administrators who installed the AutoKill.

(See Appendix B on KILL, K:line and AKill policy.)

7.0. Dispute Mediation - General Guidelines

===========================================

It is a relatively common misconception that IRCops are IRC COPs. Some

users have even asked questions one might ask of a law enforcement officer.

While we are IRCops, not cops, it does become the role of an IRCop to help

maintain DALnet as a safe, fun and friendly environment in which our users

may irc. As DALnet grows we find ourselves increasingly more involved in

disputes between our users. General rules of thumb include: clearly

identify yourself as an IRCop, don't hesitate to consult with another

IRCop/Admin if you have any questions, enforce the DALnet charter and

remember that an IRCop is not a cop.

The manner in which we present ourselves may make a difference in how

efficiently and effectively we are able to mediate a dispute.

Recommendations include:

1. Be polite and respectful. Let users know you want to help.

2. Give the user the benefit of the doubt. Ask them to tell you what the

problem is before you confront them about their reported behavior.

3. State the issue 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 your position clearly.

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.

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 do. If we vascillate, it can

start to sound like an empty threat and the user may "test" repeatedly

to see if we really mean what we say. It is better to avoid taking the

action until we are sure there is no other option, then doing so quickly

and without further discussion. And do not use profanity or namecalling.

Just state the reason based on the offending behavior.

7. Remain calm and matter of fact. If you become upset or angry, you may

be less effective or inadvertently exacerbate the situation. It is good

to ask someone else to handle the situation for you if you find you are

unable to remain objective. IRCops need to work as a team and we all have

strengths or weaknesses in some areas. Also, it is important to recognize

when we are tired or have other reasons for temporarily diminished

performance or sensitive moods. It will be better for DALnet in the long

run to have IRCops who are able to rely on others for help than to risk

handling a situation badly.

8. Do not criticize or ridicule users. Have patience for typos. Avoid

embarrassing a user in front of others.

9. 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 misinterpreted. Please try to use grammar and punctuation

which will facilitate ease of communication in the assistance of other

users.

10. Try to be sensitive to how others view the role of an IRCop. Control

and power can be easily misunderstood. It can also be helpful to be

aware of your own feelings about being an IRCop should they affect your

interactions with others in any way.

8.0. Dispute Mediation - Suggested Techniques

=============================================

Disputes generally fall into one of four categories; nick ownership, channel

ownership, channel control (ops/kicks and bans/takeover attempts), or

inappropriate behavior such as harrassment or flooding.

Nick 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 type '/MSG NickServ INFO <nickname>' then compare the address with

that of the user making the complaint and/or using the nick. A CSOP

(services operator) will be able to help determine who owns the nick and

recover the password if appropriate to do so.

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 keep in mind that we

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

registration is allowed to expire we cannot ask the new registrant to return

the nick to the first user.

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 (services operator) will be able to

help determine who owns the channel and recover the password if appropriate

to do so. Please remind users to pick a password that is not easy to guess

and to not give it to others.

Channel Control:

DALnet's Services help address the problem of Channel takeovers however

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 IRCop 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 so that someone may be

available to address the questions and concerns from the channel users,

another may address those attempting the takeover as well as setting a

K:line if necessary and emailing [email protected] promptly. (Please refer to

KLINE Section 6.6 of this Manual for more information.) Also, you will

probably need to ask a services op to assist as they are able to op

themselves on the channel through the use of OperServ.

Inappropriate Behavior:

DALnet's charter states that our 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." (See Appendix C of this Manual.) Harrasment is also

defined by this context.

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.

Complaints about the behavior 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 IRCop.

Find out the nick of the individual(s) about which the complaint is made and

try to establish contact with them, usually via /MSG. 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 harrassed in /MSG 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 harrassing 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 /MSG however at times it's

helpful to open a channel and meet with both parties there. Keeping

distractions to a minimum is best, so this channel should be private and

perhaps invite only. If necessary, this channel may be moderated to further

control the discussion until all involved are able to discuss the matter

calmly. Whether on channel or in /MSG, ask both parties to explain what

they think the problem is and how it might best be resolved. While

identifying possible solutions, try to allow all possible solutions to be

included without judgement so that everyone will have an opportunity to

contribute to the decision making process. This helps the IRCop maintain

the role of mediator rather than assume the work and responsibility of

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 IRCop 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. If the JAG or other Admin/IRCops may be

consulted in the future, please try to email a summary of what has just

transpired as soon as possible so that they may be better prepared should

they be consulted later.

Please remember too that while we all have values and opinions, in our

capacity as an IRCop on DALnet it is important to remain as objective and

impartial as possible in working with our users. If you feel, for example,

that you are unable to adequately intervene on a channel or situation about

which you have strong feelings or bias, please ask another IRCop to help.

Also, DALnet's JAG is available to assist in the resolution of disputes

which remain unresolved. Please contact Kestral ([email protected]) for more

information.

Appendix A:

----------------------------------

Glossary of OPER commands:

CONNECT: Re-link two servers. (Uusage: /CONNECT servername* 7000 servername*)

DIE: Kill ircd process. (USAGE: /DIE)

GLOBOPS: Send message to all users with umode +g. (USAGE: /QUOTE GLOBOPS

message goes here) [mIRC: /RAW GLOBOPS :<text here>]

[PIRCH: /VERBOSE GLOBOPS :<text here>

KILL: Kick user off IRC (local operators can only do this to users on the

server they operate). (USAGE: /KILL <nickname> <reason>)

OPER: Evoke umode +o. (USAGE: /OPER <nickname> <password> or /OPER)

RESTART: Remove and then load ircd into machine memory again. (USAGE: /RESTART)

SQUIT: Disconnect specified server from the IRC network. (usage: /SQUIT

servername.* <optional reason here>)

TRACE: List all connections to server. (USAGE: /TRACE or /TRACE servername*)

WALLOPS: Send message to all users with umode +w (USAGE: //WALLOPS <messaage>)

[mIRC: /WALLOPS :<text here>]

[PIRCH: /WALLOPS :<text here>]

Appendix B:

-----------------------------

KILL/K:Line/AKill Policy

1) IRCop/Admin akills a user or site.

Some suggestions:

a) Try k:lining the user from the server first.

b) Akill the user by the current username first. Don't akill the site

unless he comes back repeatedly on different servers and with

different usernames.

c) Akills should NOT be used as a quick fix to a problem!

2) IRCop/Admin sends e-mail to [email protected] within 15 minutes of the akill

addressing the following:

a) Why (in some detail) the user was akilled.

b) What exact address he was using (includes faked addresses).

c) The IP address of the site.

d) As accurate a time as possible that the akill occured.

(It should be within 15 minutes of the time the email was

sent to kline).

e) Any logs or files they might have of the offending user. This

would be EXTREMELY helpful.

*** NOTE: The akill will be removed if a user or sysadmin complains

about the akill and [email protected] did not receive an e-mail from

the IRCop that imposed the akill.

3) kline e-mails [email protected] to give a short explanation about

why their site was banned from DALnet. The letter will also contain a

note that ISP should run identd while also stating that if the

offending user was using a ppp/slip account we understand identd would

not have been much help.

4) If no complaints, the AKill stays in place for 14 to 30 days.

5) If a user complains:

a) [email protected] informs the user of the reasons the akill occurred.

b) If we CANNOT give the user a reason, the akill will be removed.

c) If we do have an e-mail informing us of the akill, kline will send a

copy of the e-mail sent to the sysadmin because it will contain all

the information the user would need.

d) The user will be informed that he should talk to the sysadmin and

the sysadmin can contact us at [email protected] if he wants to pursue

the matter.

e) Kline will remove the akill after the sysadmin has assured us that the

offending user was found and warned or removed from the provider or if

he can in some other way assure us the matter was taken care of.

6) If the sysadmin complains, a similar route as above will be taken.

Kline will work with the sysadmin to come to an agreement about removing

the akill if possible.

7) Repeat offenders will be placed on indefinite AutoKill (Global Perminent

K:line in ircd.conf).

Appendix C:

-----------------------------

The DALnet IRC Network Charter

Original Text by dalvenjah ([email protected])

Updated by MirclMax ([email protected])

Version 2.0

Ratified February 1, 1996

Amended Last on August 30, 1996

DALnet was created in July of 1994 as an alternative IRC network in

order to get away from the lag, netsplits, and takeovers of EFnet, a well

known alternative IRC network. Over time, it blossomed into what it is

today: a working IRC net with a steadily growing number of regular

users. Its advantages include 30-character nicknames, friendly admins

and IRC-Operators, certified ownership of channels without requiring

bots to hold ops, registration of nicknames, and the ability to leave

brief memos for users even if they are offline.

This document is its charter, denoting the rules that govern DALnet,

its administrators, IRCops, and users.

1a.The main objective of DALnet is to provide a network where people

can talk with each other and enjoy themselves. In order to fascilitate

this, all clients connecting to DALnet must adhere to the Acceptable

Use Policy (located at ftp://ftp.dal.net/admin/aup.txt &

http://www.dal.net/documentation/aup.html).

[Amd1b:7/25/96:MirclMax]

1b.On DALnet, channels are owned by users. Contrary to the policy of other

nets, the current op-holder, whoever he or she might be, does NOT

necessarily own the channel. DALnet has a service called ChanServ,

with which a user can to register a channel and assign ops and superops,

as well as perform various other functions relating to channel security.

Channel disputes--when one party believes that the current channel owner

isn't running the channel properly, or whatever--will be mediated by one

or more IRCops or admins at the request of the users of the channel.

Similar policies hold for nicknames.

2. The responsibility of DALnet IRCops is to provide for a safe and fun

environment in which to IRC. This means if a user requests an IRCop's

assistance, that IRCop must investigate and take any action necessary

into that user's situation. If the IRCop is otherwise indisposed, however,

he/she must say so in their /away message, so that the user will know

to look elsewhere for assistance.

IRCops must use their judgement on when to use /kill or other means of

enforcing item #1 above. If the battle is 'personal', however, /kill may

not be used. DALnet Administration will support any IRCop's decision to

use /kill if the situation appears to have warranted it.

Example: JoeUser is sitting innocently on a channel when EvilUser floods

JoeUser. JoeUser tells IrcOpJon that EvilUser is flooding him; IrcOpJon

/kill's EvilUser. If EvilUser complains to another IrcOp, IrcOpJon's

opinion--that JoeUser said EvilUser was flooding--is held above EvilUser's,

with JoeUser's testimony to back him up.

I know this has a potential for abuse--we will investigate incidents where

a single user is being flooded by people who don't flood anyone else, or

something like that. It's not easy to be completely fair, but hopefully

this will help.

3a.The responsibilities of a DALnet Admin include, but are not limited to:

* upkeep of his or her server's software, and upgrade of the software to

the current DALnet version within a reasonable time after the

version's release.

* keeping the server's configuration updated and consistent with

DALnet practices.

* keeping him- or herself up-to-date in DALnet policies, procedures,

and activities.

* voting in the majority of official CFV's

* keeping DALnet administration as a whole aware of any prolonged absences

* appointing a representative to fulfill his or her duties when

necessary, and informing the DALnet administration as a whole of

the appointment.

* informing the DALnet administration as a whole of any changes in a

timely fashion.

* all responsibilities granted to IRCops.

3b.The rights of a DALnet Admin include, but are not limited to:

* appointing or removing IRCops he or she trusts to act in the best

interests of his or her server, and of DALnet as a whole

* upgrading the server's machine or link, providing the machine

remains in the same location, net-wise, or making other changes as

necessary in keeping his or her server in the best possible

working condition, where "best possible working condition" is

defined at the discretion of the Admin.

* setting up an additional server to expand the capability of the

site, even if this includes running additional processes on

different machines, providing that the machines are of comparably

capability, and the server's location does not change.

* do whatever is necessary regarding his or her own server, to be

decided at the Admin's discretion, to make a smooth transition

during hardware or software upgrades, or during an emergency

situation.

3c.An Admin does not have the right to:

* move his or her server, net-wise or physically, to a location

generally regarded as inferior, except as a temporary or emergency

measure, as decided by the CEO.

* drastically alter the location of the server net-wise or physically.

* link a server which has not been officially accepted by the DALnet

administration except in emergency situations with the approval of

the CEO.

* have more than one vote, even if he or she runs more than on server,

or co-Admins a server, unless more than one vote is granted by a CFV.

3d.De-linking a DALnet server

The following are reasons for possible removal of a server from the

DALnet network:

* If a server is not connected more than 75% of a 30 day period.

* If a server has no vote in 5 or more of the last 7 CFV's

called by the DALnet administration

* Failure to update the ircd files in a timely manner.

* If the admin loses access to the server, and its files.

* The admin(s) of the server abandon it.

A CFV should be called by the CEO within 5 days of notification by

an Admin, that one of the above conditions have been met. The CFV should

include what should happen if the server is not removed, including voting

rights of the admin.

If the Administration votes in favor of delinking, all DALnet servers

shall remove C/N's at earliest convience.

If the Administration votes against the removal of the server:

* Any actions stated by the CFV are to be put in affect immediately.

* The server should then have a probationary period of 60 days

of closure of the CFV, or from when it reutrns to the DALnet network.

* At the end of the probationary period, another CFV can be requested

if another admin feels the server/admin did not fulfill the

duties neccessary of a DALnet server and admin.

A server may be temporarily delinked (juped) if it shows considerable

disruption the the rest of the network. This action should be no

longer than 5 days. Otherwise, it qualifies for delink (Failure to

update the ircd files in a timely manner.)

[Amd2a:8/30/96:Firemyst]

3e. RE-CFV's AND ACTIONS TAKEN DURING EMERGENCY SITUATIONS

A re-CFV may be called on a server if requested by an Admin, to

approve emergency measures taken by an Admin if those measures are

outside the rights granted to an Admin and have been in place for

more than two weeks, and MUST be called on a server if that server

remains down for longer than 45 days or has been delinked by a CFV.

'Emergency measures' may be taken by a non-Admin if the measures are

approved by the CEO or the CEO's appointed representative. Emergency

measures may be in place for the period of one month without a CFV.

3f. Emergency Situations

An 'emergency situation' is a situation, declared by the CEO, or as

agreed upon by 2/3 of DALnet's Admins.

[Amd2:3/20/96:Catlin]

4. Technical requirements of servers: Each server must be the agreed-upon

version used by DALnet (The latest version can be found at:

ftp://ftp.dal.net/pub/dalnet/server), which contains several

modifications essential for the DALnet environment. Its machine must

have a relatively low system load that will allow for the server. The

machine must be stable enough to support the server 24hours a day,

and the link to the Internet must be at least 256Kb/sec.

5. Policy decisions: Policy decisions include, but are not limited to,

making changes to the charter, adding/removing servers, or voting to

bring action against an admin or IRCop. The way it works is this:

Votes are to be called by DALnet's Chief Executive Officer (The

current CEO, at the time of this document's ratification is DALnet's

founder, dalvenjah) or by a person (or persons) appointed to do so by

the CEO. A single vote is allocated to each of the current servers.

As well, the CEO shall always have a vote regardless of his status as

an admin. [The CEO also has the ability appoint a co-Chief Executive

Officer or nominate a replacement.] It is the job of the IRCops of

each server to convince their admin to vote one way or the other. An

issue will be "passed" if greater than 50% of those eligible to vote,

vote "Yes". An issue will be "rejected" if greater than 50% of those

eligible to vote, vote "No". If neither of the previous instances

occur, the vote will be "pushed" and revoted upon. It is the duty of

each admin to either cast a vote or appoint someone to cast a vote

for them.

6. Disciplinary action against IRCops/admins/server: If an IRCop, admin

or server repeatedly fail to meet their requirements, as laid down in #2,

#3, and #4 above, a review will be held in order to re-evaluate that

person/server. The voting will be the same, except that the

person/server who is being evaluated will not be allowed to participate

in the voting process. If it is decided that the person being

evaluated should be removed from his/her post, then if the person is

an IRCop, their admin must comply and remove that person's O:line. If

that person is an admin, or if a server is voted to be removed, the

links to that server will be removed and the server taken off of DALnet.

I think that's everything. A quick note: I didn't mean this to sound

overly formal; unfortunately, when I start talking legal, I *really*

start talking legal. The main objective of DALnet is indeed to have

fun, and it shouldn't get bogged down by administrivia. So basically,

keep this all mind when you use DALnet, but don't let it keep you rigid.

-*- The DALnet IRC Network -*-

Remember: if you're not on DALnet, you're on the wrong IRC server!!

(/serv irc.dal.net 7000 or telnet telnet.dal.net to try it out)

Appendix D:

------------------------------------

What DALnet Is (aka, useless trivia) ;)

When users ask about how DALnet works, it's a pretty good idea you know

yourself; you may refer to this section for giving quick answers (note, this

_does_ cover things already mentioned here). Basically, DALnet is a non-profit

organization founded by Dalvenjah FoxFire and MirclMax. The servers are run on

machines provided by the ISP or educational establishment usually paid for by

the student tuitions or membership from the ISP's various users. The Admins

are usually the system administrator or assistant system administrator of the

provider are most often the server admin. Server Admins usually are

volunteers, however, sometimes the ISP is either owned by or IS a

telecommunications company and thus the admin is getting paid for his work but

most of the time almost all IRCops are volunteering their time for their

services.

The most common misconception is that DALnet is a server (irc.dal.net). Even

irc.dal.net is not a server--technically, it is a DNS resolver that randomly

places connections on one of DALnet's Servers. DALnet itself is a 'net' of

servers around the world that the channel reside on. However, channels that

begin with & are local to the server they're started on.

ChanServ, NickServ, MemoServ (et cetera) aren't exactly bots. They are

IRC processes generated by a 76MB program for Linux called Services written by

Morpher. This program acts as a pseudo-server called services.dal.net with

phoenix.dal.net as its uplink. dalnet.phoenix.net (that services runs from) is

a 133mhz Pentium with 64MB RAM and a 1.2GB HDD running Linux formerly on

delphis.ict.org (the same computer, but was a user machine) with

mindijari.dal.net as its uplink. Services consumes on average 5% CPU and

16-20MB RAM.

The servers run a program called ircd (which stands for Internet Relay

Chat Daemon) only available for the UNIX platform (SunOS, Linux, FreeBSD etc).

Servers usually take up a great deal _less_ than Services probably ever could.

Resource consumption increases as the maximum connections allowed (set in 128

connection incremints) are configured. This code is based on the Undernet's

modified ircd 2.8.21 called mu3 (based on EFnet's irc2.8.21. dal1 included

more updates and currently ircd 2.8.21.mu3.dal4.3.2 is the current program

running on all DALnet servers.