[x] Direct Chat
Mibbit Chat Client, Chat here
Those who use IRC chat clients such as X-Chat or Mirc can connect to events.ukscifi.net or irc.ukscifi.net on ports 6665-6669.

All guest chats are live from audioserv.ukscifi.net:9000 - Listen with Winamp or Windows Media Player.

Our Wish: To develop a chat community dedicated to the science fiction and fantasy as well as a place for fans, writers publishers and producers to share their ideas and interests and to build a safe place for all to chat, providing the best that our services have to offer.

Please Note: We are changing the site around again (Running everything on linux), so we can add some new services, from this point on user(s) have to register to access the Downloads and Forums, We welcome users to submit downloads, News (Scifi /Tech related) dont be shy. Let us know.


IRCop, Admin Manual

UKScifi Networks: IRCop, Admin Manual

IRCop Manual.

This document is designed to familiarize new opers with the policies and expectations they will have to deal with while serving The UKScifi.Net IRC Network. You should familiarize yourself with its contents completly, and keep it on hand for future reference.

If you have any suggestions for changes or additions to this document, E-Mail the author at Yu@UKScifi.net. Please indicate that this document is the subject of your E-Mail.

This document assumes that you have a good knowledge of IRC and it's most basic commands. If you don't you may wish to reconsider being an IRCOp.

Table of Contents

1.0.0 Required Reading

This section outlines things every oper should know. You will be expected to know everything listed here. You will not be expected to be familiar with the CSOp and Admin sections unless you hold those positions, but reading them won't hurt.

1.1.0 Responsibilities as an oper

Being an IRCOp is a job, not a status symbol. You have been given this job so you can help the network and its users. If you are only interested in being an oper so you can look cool and kill people who piss you off, then don't be the least bit surprised when you suddenly can't oper.

While you are opered, you are expected to do several things:

* Be courteous to the network's patrons.

This means is you are expected to be friendly and helpful to the people that use this network. It's like any other job serving the public, if your a complete ass, you get fired. If you're busy when someone asks for help, tell them you're occupied and refer them to someone or somewhere where they can be helped. Do the same if you just don't know the answer to their question. While you are opered you will be expected to be visible (-i) so that people looking for help can find you in a /who.

* Do everything in your power to keep the network running.

This means assist in routing, dealing with clones, working in the help channels, etc. These are all optional. You're not REQUIRED to help in the help channels, nor are you REQUIRED to assist in routing or dealing with problem users. But doing so earns you respect in the eyes of your fellow opers and the network in general, and it is the path to greater power and influence on the network. It also helps to ensure that when your admin hits that magical number of 5 opers and wants to add someone new, you're not the first to go.

* Help those who ask for it.

If someone sees you, an oper, with a low idle time and not set away, they're going to assume (rightfully so) that you are willing to help them. If you're not willing to do this, deoper until you are. If someone asks a question you don't know the answer to, refer them to the proper help channels. You might also join them there so that you too can learn the answer.

If you're not willing or able to do these at the time, you should not be opered. Set yourself -o until you feel ready to face the challenges and responsibilities of that mode.

1.1.1 Abusive behaviour

Abusive behaviour by an oper will not be tolerated. It gives a bad impression of the network. While you are free to conduct yourself as you see fit in channels you are opped in (with the exception of #Help), You are not free to abuse users simply because you can. Verbal abuse and abuse of your power (such as unwarranted kills) will not be tolerated and will result in temporary, possibly permant, loss of your O:Line.

1.1.2 Channel disputes

UKScifi.Net IRCOps should not get involved in channel disputes. If you have access in the channel, feel free to get involved, but not as an oper. We do not handle reports of abusive channel ops, nor do we police any channel unless they are breaking network rules. The only exception to this is channel takeovers. If someone says their channel has been taken over, inform them of how to regain control over it with ChanServ (/cs clear #channel ops, /cs op #channel). If they say their channel password was stolen, refer them to a CSOp. If you are a CSOp, see section 2.0.0 for more information.

1.2.0 Command Listing

This section will deal with various commands available to you as an oper. This section is not an authoritive listing of all commands available, it merely explains the function and usage of several more frequently used commands.

1.2.1 OPER

The OPER command is what you use to become an IRCOp. Before you can successfully use this command, you need to have an O:Line on the server you're on. If you have an O:Line on another server, you need to be on that server before you can oper.

The syntax for the OPER command is: /OPER Nickname Password 'NickName' does not nessicarily need to be your current nickname, it's specified by your admin. Similarily, 'Password' is specified by your admin, and is not nessicarily the same as your NickServ password.

1.2.2 KILL

The KILL command is one of the most basic IRCOp commands. As with other OPER-related things, abuse of the KILL command is not tolerated. KILL may only be used if the person being KILLed has broken the network rules. KILLing people who have not broken network rules (ie, they're annoying you, or a friend of yours) will be dealt with as abuse and may result in the loss of your O:Line.

The syntax for the KILL command is: /KILL User Reason

You can stack up to 20 KILLs at a time with one command. This is useful cloning attacks.

The syntax for stacked KILLs is: /KILL User1,User2,User3 Reason

Note that the list of users to KILL is a comma-seperated list, with no spaces. After a space, the IRCd will consider it to be part of the KILL reason.

KILL simply disconnects a user, and they can freely reconnect right away. To remove a user from a server temporarily, see the KLINE command. To remove a user from the network temporarily, see the AKILL command.

1.2.3 KLINE

The KLINE command should only be used when a client has violated local server policies, such as a bot on a non-bot server. They are not global on the network, and will only stop the client from connecting to the server you are on. To remove a user from the network globally, see the AKILL command.

The syntax for KLINE is: /KLINE User :Reason

Note the colon before the reason. Without it, only the first word of the reason will be used. Note that K:Lines done with the KLINE command are temporary and will be lost when the server is restarted or rehashed. If you want to permanently remove a user from your server, talk to your admin about having a K:Line placed in the conf.


The UNKLINE command is used to remove a temporary KLINE put in place with the KLINE command. Before you can remove a K:Line, you must first know the exact user@host that is K:Lined. Use the STATS K command to see the K:Lines.

The syntax for UNKLINE is: /UNKLINE user@host

A successful UNKLINE will result in a message like this:

-phoenix.tx.us.UKScifi.net- Temp K:Line user@host is now removed.

1.2.5 SQUIT

The SQUIT command assits in rerouting servers. Do not SQUIT a server without a very good reason (ie, to reroute it). See section 1.8.0, Routing, for more information on how SQUIT works and when it should be used.

The syntax for SQUIT is: /SQUIT server.UKScifi.net Reason

You do not need to provide a colon for multi-word reasons.


The CONNECT command attempts to establish a connection between two servers. These servers must have C/N:Lines for eachother before this command can be successful. If two servers lose their connection, you will be expected to attempt to reconnect them. Splits happen, but the less time they're split, the better. See section 1.8.0, Routing, for more information on how CONNECT works.

The syntax for CONNECT is: /CONNECT server.UKScifi.net

Additionally, you can do remote connects to attempt to re-establish a connection between two servers that you are not on.

The syntax for a remote CONNECT is: /CONNECT splitserver.UKScifi.net 7500 presentserver.UKScifi.net

You must specify a port. UKScifi.Net uses port 7500 for routing. Note that the server that is split is first, and the server that you want to try and establish the connection is last.

1.2.7 REHASH

The REHASH command is only really useful if you are the server's admin, but you may have access to it anyhow. REHASH re-reads the ircd.conf file and updates the servers information (O:Lines, K:Lines, etc). Rehash also removes any temporarly klines, akills and zlines.

The syntax for REHASH is: /REHASH


The RESTART command will shut down IRCd and restart it. Before using this, you had best have a good reason, or you will have to answer to your admin and may lose your O:Line over it. If you do have a good reason, send a local notice to the users on the server informing them that the server is restarting, and give them 5 minutes or so to switch to another server. It's best if you send at least two notices before restarting the server. See section 1.2.12, NOTICE, for more information on sending local notices. You should also inform other opers of your action via ChatOps or GlobOps.

The syntax for RESTART is: /RESTART RestartPassword :Reason

1.2.9 DIE

The DIE command shuts down the server permanently. Unless there is a crontab or some other program running to restart it, the server will be down until the admin restarts it. As with RESTART, if you use this without a very good reason, you will likely lose your O:Line. Also as with RESTART, you should send no less than 2 local notices informing users that the server is shutting down, and inform other opers that you are shutting the server down and why.

The syntax for DIE is: /DIE DiePassword

The DIE command currently does not accept reasons.


GLOBOPS, WALLOPS, LOCOPS and CHATOPS are a series of 'channels' in the IRCd that are for oper/server traffic. CHATOPS is specifically designed for oper chat, and all oper chat should be directed there. GLOBOPS is mainly used by Services and the IRCd, WALLOPS is mainly obsolete, and LOCOPS is for local server traffic.

The syntax for GLOBOPS is: /GLOBOPS Text

The other commands have identical syntax.

1.2.11 NOTICE

The NOTICE command has several uses for IRCOps. In addition to the basic user->user and user->channel notices, you can now send notices to servers. This is useful for sending a message to all users on a specific server, or all users on the network (although use of the Global Noticer on Services is encouraged).

The syntax for local notices is: /NOTICE .UKScifi.net Text

You can be more specific with this, ie, if you wanted to send a notice to all users on Canadian servers, you could do: /NOTICE .UKScifi.net Text

The syntax for global notices is: /NOTICE .net Text

Since all UKScifi.Net servers run under the UKScifi.net domain, all users on the network would receive this notice. If however there were multiple domains in use, it might require several notices to get the message out.

1.2.12 STATS

The STATS command shows you various information about the server and network. It is useful for finding out if a server is set up to connect to another server, what opers are on a given server, etc. You can do local STATS queries, or remote ones.

The syntax for local STATS queries is: /STATS Letter

The syntax for remote STATS queries is: /STATS Letter server.UKScifi.net

'Letter' is any letter from A-Z; a-z. Some stats are case sensitive, others are not. For example, /STATS C and /STATS c will both return the C/N lines for the server. However, /STATS U will show the U:Lines for the server, whereas /STATS u will show the server's uptime.

Not every letter has a STATS reply. If there is no information for the requested stats, you will simply receive 'End of /STATS report' with no information.

/STATS K will show you the K:Lines. It's one of the more complex STATS reports, and will be explained in depth. Several types of K:Lines are shown in this report. They are distinguished by the letter they start with. For example:

A *@*.someisp.com * You are not welcome 0 -1 This is an example of an AutoKill. All users on the someisp.com domain will be automatically denied access with the reason 'You are not welcome'.

k *.someisp.com Bots_are_not_allowed_here user 0 -1 This is an example of a temporary K:Line. The output is somewhat out of order. The K:Line is against any users from the someisp.com domain with a username of 'user', as shown by the 4th field. The reason is in the third field. Spaces are shown as underscores.

K *.someisp.com Bots_are_not_allowed_here user 0 -1 This is an example of a permanent K:Line. It is nearly identical to the temporary K:Line shown above, except that it uses an upper case K instead of a lower case one.

z Don't_irc_from_the_local_machine 0 -1 This is an example of a temporary Z:Line. All users attempting to connect from will be denied and given the reason 'Don't irc from the local machine'. Notice the in the username field, as Z:Lines do not use a username.

Z Don't_irc_from_the_local_machine * 0 -1 This is an example of a permanent Z:Line in the ircd.conf. It is nearly identical to the temporary Z:Line shown above, except that an upper case Z is shown, and the username field is a * instead of due to the way Z:Lines are stored in the conf.

1.3.0 Terminology

There are several terms used in this document, and others you may come across in the future you may not understand. They will be explained in depth here.

IRC IRC is an acronym for Internet Relay Chat. Of course, you already knew that, right?

IRCd IRCd is an acronym for Internet Relay Chat Daemon, is the actual server program. The IRCd holds the clients, communicates with its clients and other servers on the network.

IRCOp IRCOp is an abbreviation for IRC Operator. An IRCOp is someone who has powers over that of normal users. These powers are given to someone to enable them to assist in keeping the network running smoothly. IRCOps are most commonly referred to as 'Opers'. They are sometimes referred to as 'IRC Cops', which is incorrect and shouldn't be used.

KILL KILLing a user means to remove them from the network. KILLS are often issued when a user violates network or server policies.

AKILL AutoKills are Services based K:Lines. All IRCOps can set them. If a user is AKilled, they will not be able to connect to any servers on the network. AKills should only be used when a user repeatedly violates network policies. Repeated violations of server policies should be dealt with with a K:Line. AKILLs expire after one week.

PAKILL Permanent AutoKills are identical to AKILLs, except that Services will not automatically expire them.

LOCOPS LocOps is a 'channel' that is sent to every operator on the server it originated from. You can use it via the /LOCOPS command which is explained in section 1.2.10.

GLOBOPS GlobOps is another 'channel'. GlobOps are sent to all operators on the network. You can use it via the /GLOBOPS command which is explained in section 1.2.10. You must be +g to see GlobOps.

CHATOPS ChatOps is another 'channel'. All users set +b can see ChatOps. Additionally, you must be set +b yourself to send them. You can use it via the /CHATOPS command which is explained in section 1.2.10.

WALLOPS WallOps is the most basic of these 'channels'. All clients set +w (including non opered clients) may view it, however only opers can send them. WallOps are rarely used. You can use it via the /WALLOPS command which is explained in section 1.2.10.

CSOP CSOPs are Services Operators. These people have an intermediate level of access to Services between IRCOps and SRAs. The main CSOp powers are GETPASS and SETPASS, which allow them to retrieve or change the password of a channel or nick.

SRA Services Root Admins generally have the most power on the network, since they're usually server admins as well. They have access to services commands such as SHUTDOWN and can restart services if needed.

1.4.0 UKScifi.Net rules and policies

This section is an excerpt from the Rules & Policies section of the website.

No flooding This includes CTCP flooding, text flooding, action flooding, and any other forms of flooding.

No cloning Clones are defined as multiple connections from the same user, whether on the same host or not. Although OperServ will not see users on different hosts as clones, our staff will, and they will be dealt with as such. Each user may have up to 5 connections at any time. Any additional connections will be removed from the network upon connecting. If you set off the clone trigger 5 times, your host will be autokilled for one week. If you require more than 5 connections (ie, a shell, school, internet cafe, etc) ask in #Help for more information on having your host excepted to the clone detection.

No advertising or inviting Advertising your channel, website, network, etc on UKScifi.Net will result in you being removed, and the proper authorities informed. Be aware that advertising (spamming) is not tolerated by many providers, and you will quite possibly lose your internet or shell access.

Bots Some UKScifi.Net servers allow (friendly) bots, others do not. View the servers /MOTD, or the servers page for a list of servers that do and do not allow bots. Friendly bots are defined as bots which do not have a harmful purpose such as flooding or takeovers. Harmful bots will be removed from the network, bots on non-bot servers will be removed from that server.

Channel Disputes UKScifi.Net staff will not get involved in channel disputes, aside from issues of ban evasion. Use ChanServ to regain control over your channel in the event of a takeover.

Denial of Services attacks Users found to be using DoS attacks against users or servers will be removed from the network and reported. * Note to users reporting DoS attacks: You must have sufficient logging available to have a user removed from the network. Unless we have proof, we can not do anything about it. You are free however to contact that users ISP and state your case to them.

Channel & Nick Hoarding Each user is allowed 5 channels and 6 nicknames. Users who register large amounts of channels and nicknames, seemingly for the purpose of owning them before anyone else does, will be removed from the network and the channels/nicks will be dropped.

1.5.0 Services

As you should well know, UKScifi.Net has IRC Services. These consist of 4 user services, ChanServ, NickServ, MemoServ and StatServ, and two IRCOp services, OperServ and RootServ. All of them have helpfiles detailing their functions and how to use them. You should familiarize yourself with all of the services, as you will undoubtedly be asked questions about them from time to time.

1.5.1 ChanServ

ChanServ allows users to register and maintain their channels without the need of a channel bot. It also eliminates such things as channel takeovers. In order to take over a channel, someone would have to be in the channels access lists. If a channel is taken over, the user may not know how to retrieve it. If this happens, inform the user how to regain control of their channel. This is done with two commands: /cs deop #channel nickname, and /cs op #channel. When the user executes these commands, ChanServ will deop the user who tookover the channel (nickname) and op the user in their channel. They are now back in control of it.

If the person who took the channel over is on the channels access list, tell the user to remove them (/cs aop #channel del nick), then redo the commands above if the channel was taken over again.

You should NOT kill anyone involved in a channel takeover. The person doing the takeover may very well have legitimate access, and you may be aiding the person actually taking over the channel. You should join the channel in question and monitor what happens. CS INFO will let you know who the channel founder is. If it's one of the two people involved, you'll know who you should be helping.

You should only act on the report of a channel takeover if you can confirm that the person reporting it is indeed the channel founder or an op there.

If someone has forgotten their channel password, do a NS INFO on the founder's nickname. If they have an email set, you can use the CS SENDPASS command to have the founder password emailed to the founder's nickname.

1.5.2 NickServ

NickServ allows uses to register their nickname and keep it available for when they want to use it. Having a nickname registered means users don't have to resort to DoS or other attacks to get their nick when they come online. (They still, however, have to put up with DoS or other attacks from people unhappy that they can't get that nick) If someone comes to you saying someone 'stole' their nick, tell them to type /NickServ RECOVER nick password. If they say they do not have the password, Refer them to a CSOp (or #Help), Or tell them to type /motd services.* and msg one of the people listed in bold. If they have an email set, you can use the SENDPASS function to have their password emailed to them.

As an IRCOp, you are REQUIRED to have an email set with NickServ. This should be a valid email. If you haven't had an @UKScifi.net address set up yet, set it to your real email. If you have had an @UKScifi.net email set up, feel free to display this in NickServ. If you do not wish for your email to be visible, set the HideMail flag. (/NS help SET HideMail) In order to get an @UKScifi.net email, send an E-Mail to forwarders@UKScifi.net and request one. Be sure to give your nickname and the address you want your E-Mail forwarded to. Additionally, you can request a pop3 @UKScifi.net account if you would prefer that over a forwarder.

1.5.3 MemoServ

MemoServ allows users to send short (256 chars or less) memos to each other. Problems are rarely encountered with this service, however occasionally someone decides to memo bomb a user. Users can only have up to 25 memos at any time, read or otherwise. If someone complains about memo bombing, refer them to a CSOp. If you are a CSOp, refer to section 2.

1.5.4 StatServ

StatServ gives various information on the network.

StatServ's MAP command shows how the servers are linked together, each servers ping time from services, and how many users are on each server.

StatServ is mainly useful to higher level network staff as a tool to gauge performance of individual servers and the network as a whole. StatServ also has several other commands you may find of some use. Feel free to check its helpfiles.

1.5.5 OperServ

Here we will focus on OperServ and the additional functions it provides to make your life as an oper easier.

OperServ makes the following functions available to you as an IRCOp:

JUPE: Allows you to add server and nickname jupes. These can be removed with an squit or a kill, respectively. Do not jupe without good reason. (which you likely don't have.)

AKILL: Allows you to add, delete or list the AKILL list.

CLONES: Shows you a listing of nick!user@hosts that OperStats considers to be clones. You should not have any reason to kill any of these hosts. OperStats will automatically kill any clients that break the clone limit, which is 5 per host. Thus, anything listed here is under the limit, and thus not breaking the rules.

TRIGGER: Allows you to add/remove/list TRIGGERs. You likely do not have any reason to bother with this.


GLOBAL: Sends a global notice using Global. These should only be used for something involving the entire network.

SEARCH: Allows you to search OperStats' logfiles. Be aware that OperStats is NOT services, and as such, its logfiles don't contain much of interest besides AKill and clone activity.

AUTH: This allows IRCOps to authenticate with OperServ for SRA access.

For more information on OperServ's commands, check its helpfiles.

1.5.6 RootServ

RootServ is a service similar to OperServ. The main difference is that RootServ runs on Services. For most things, you will use OperServ. RootServ is mainly for CSOps and SRAs to maintain services, nicknames and channels. Do not use RootServ for placement of AKills unless OperServ is down.

1.6.0 How to deal with users

Here we will explain how an oper should interact with the users on the network.

First of all, as an oper, you'll be seen as a god. Someone who, because they have power, must be cool. Because of this, a lot of people are going to want to be your friend. You're going to have to learn to put up with this. Some people who will try to strike up a conversation with you will be intelligent, competent people who themselves might become opers someday. Some will be completely new to IRC, and probably won't know much besides having 'IRC Operator' in your whois makes you cool. The majority will be between these 2 points. All deserve the same respect and courtesy you yourself would expect.

Just because someone can't speak good english or doesn't know what a /kill is doesn't mean they should be put down and insulted by you.

You should treat every law abiding user on the network as a precious resource. Treat them with dignity and respect. Help the ones who just don't get it, and remove the ones who break the rules.

1.7.0 How to deal with clones

There are several types of clone attacks. They can range from simple ones, where a user opens several clients, to medium ones, where they use a clonebot program or raw socket connections, to advanced ones where they use clonebot programs and bring on clones from different addresses.

The simple ones will be dealt with by OperServ. If OperServ is not present, or not functioning properly for some reason, You will have to deal with them manually. Adding a Temp K:Line for the cloning address will disconnect all the clones. (See Subsection 13, 'Oper Commands' for more info on doing this) You can also use a MassKill script to kill each clone individually yourself. You can also use RootServ in the absence of OperServ.

The medium attacks are similar to the simple, but easier for the user to execute. Medium attacks also connect from the same address, but most likely have different usernames. (Simple ones can have different user names as well, but usually don't.) Deal with medium attacks in the same fashion as simple ones.

Advanced attacks cause the trouble. OperServ will not trigger, since the clones all come from different addresses and are not visible as clones to any script. Noticing these clones is easy. Getting rid of them is not. No filter scripts will be able to deal with them, so they will have to be removed individually. The cloners address supply has a limit. You should K:Line or AKill each clone bot. Several are probably using the same address. Once you have removed them all, (hopefully other opers on the network are helping to do this) You should go through the addresses that connected. If it's a common hostname, (aol.com for example) Add it to AKill. If it's a wingated or otherwise spoofed address, (ie, it resolves to something fake like 'INTERNET') Add it (or have it added) to PAKill.

1.8.0 Routing

We will now explain routing. Here you will learn when a server needs to be rerouted, how to retoute a server and how to do remote connects.

1.8.1 When to reroute

A server can be in need of rerouting on any of several occations: The server lags from its current link Its current link goes offline

Other difficulties may arise which require rerouting. Rerouting should only be done if it is nessecary. Don't reroute a server just because it's current link hits a lag pocket. If it's current link dies completely, that would be a good time to reroute. ;) Do not reroute a server simply because StatServ says it's lagged. If StatServ continually says it's lagged, rerouting should be considered. Note that StatServ itself may be lagged, and if it reports that most of the network is lagged, this is a good indication of this. There is very little you can do in this instance.

1.8.2 Rerouting

First of all, you can only reroute a server to another server that is set up to accept it. Trying to connect pegasus.* to phoenix.* won't do any good if either pegasus or phoenix doesn't have C/N lines for the other server. You can check a servers C/N lines by typing /stats c .

If both servers have the lines present, we're going to assume that the passwords match and an attempt to link them will succeed. (If it doesnt, contact the admins of the servers in question)

In this example, we're going to pretend that events.* is currently linked to pegasus.*, but that pegasus is offline or lagging heavily. We want to reroute irc to lighten the load on pegasus and give it a chance to recover, and so the clients on events and the servers behind it can function normally.

The network could be laid out like this:

phoenix---------pegasus | || `-operstats `-services `-irc | `-events

As you can see, irc and services are linked to pegasus, pegasus, operstats are connected to phoenix, and events is linked to irc.

Now we reroute. We'll assume you're on phade. This will be local routing. Here's the procedure.

A) Send a notice. Inform the users of phade that you are going to be doing some rerouting. This is done with the following command:

/notice .*,events.* [Notice] Due to lag, We will be doing some rerouting shortly. The split should only last a few seconds.

Notice that the notices are stacked. This notice will only go to the users on irc and stain. If other servers were linked behind pegasus, you should include them as well. You should inform every server behind irc about the rerouting. That includes servers linked to events, servers linked to servers linked to events, etc. Depending on how many servers are behind irc, and the ones behind those, you could be splitting a good portion of the network.

You should then wait about 20-30 seconds before beginning the routing process.

B) Delink from pegasus. Before you can connect irc to phoenix, you need to remove it from pegasus. This is done with the following command:

/squit pegasus.*

This will cause the link between irc and pegasus to be terminated.

Notice that events is connected to irc. Therefore when the squit is given, all users on events and irc will be split from the rest of the net.

If all goes well, you will see a message similar to the following:

-Irc.UKScifi.net- *** LocOps -- Received SQUIT Pegasus.UKScifi.net from seti[r39-1.ukscifi.dial.uk] (seti)

C) Connect to phoenix. Once the link between pegasus and irc is severed, the next step is to connect to phoenix. This is done with the following command:

/connect Events.*

If all goes well, you will see a message similar to the following:

-Irc.UKScifi.net- *** Connecting to *@[Events.UKScifi.net].

-Irc.UKScifi.net- *** LocOps -- Link with Events.UKScifi.net[UKScifi.@] established.

The routing is now complete. irc and all the servers behind it are now linked to phoenix, and hopefully the problem leading up to the rerouting is gone.

If you get any errors such as 'password mismatch' or 'no n line', link to another server and consult the admin of the server you tried to connect to. (or the server you tried to connect from, whichever is at fault)

2.0.0 CSOps

2.1.0 Password retrieval policies

UKScifi.Net has a 'No E-Mail, No Password' policy. If a user requests a password, but their nick doesn't have an E-Mail set, Inform them of this fact and that they will have to either remember the password or wait for the nick to expire. If they learn from this, they will set an E-Mail as soon as they get the password back. They will most likely say something like 'my email is isuck@lamer.net email it there!!!' Inform them that you have no way of knowing if they are the actual owner of that nick and therefore they are not getting the password. If they continually badger you or other CSOps about getting their password, remove them from the channel or /ignore them. If they are insistant and will not give up, a /Kill may be issued with a reason like 'You cannot get a password without an E-Mail set in NickServ. This is final. Do not ask again.'

If there IS a valid E-Mail set in NickServ, use SENDPASS (/NickServ SENDPASS nick). This will have services E-Mail the password to the user.

If the user was in fact lying about their ownership of the nick, then they won't get the E-Mail. A stupid user will ask you to just msg them the password. A smart user will figure out they're not going to get it via msg and leave you alone about it. The stupid user is the annoying one. They are likely to continue asking for the password, even after you have told them that it has been E-Mailed. /Ignore the stupid user. /Kick the stupid user. Do not /Kill the stupid user, since being stupid is not a violation of network policies.

SENDPASS for a channel is similar to SENDPASS for a nick, except, of course, it is issued with /ChanServ SENDPASS #Channel. ChanServ will email the password to the E-Mail the founder of the channel has set in NickServ. If the founder has not set an E-Mail, inform him/her that a SENDPASS is not possible.

You should keep records of ALL SENDPASS' you perform. These records can be used later if the person at the other end of the E-Mail did not actually request the password to figure out who did. You should keep these records for several days at least.

3.0.0 Responsibilities as an admin

As you should well know from the server app (remember, that 9k of text you DID read before you sent the app in?) Your server should not accumulate more than 12 hours of downtime a week. If it does, it could be delinked, especially if the case is extreme and your server is split more than it is linked.

If you oper JoeLuser because Joe said he'd move his channel here, and Joe goes on a rampage and starts killing everyone and everything in sight, Joe will be severly flogged, as will you. You should not give someone an O:Line unless you know them, trust them, and can vouch for their sanity.

You have a responsibility to upgrade your servers IRCd to the latest version when it becomes available. New versions of the IRCd aren't made available for fun, they are made available because they contain bugfixes or new features. Bug fix upgrades aren't life threatening, and you need not upgrade your server INSTANTLY. New features can vary in severity, from those that won't make a difference from server to server, to those that can cause the net to split if a server doesn't understand what another is telling it. In any case, you have one week to upgrade your IRCd before you risk being delinked.

UKScifi.Net enforces a policy of 2 admins and 5 opers maximum per server. If your server ever goes over these limits, it will be restricted to local or delinked until it is compliant again. This is done for several reasons:

Every person you meet isn't going to be an oper

Less opers means less chance of a bad oper

It gives admins an excuse to deny people asking for O's

Natural selection. If you can only have 5 opers, you're likely to choose 5 good opers, not a bunch of friends. (at least, you'd better.)

Your O:Lines will be checked at random times to make sure you are compliant. You can still have multiple O:Lines for one oper, but only 5 opers. (In short, there shouldn't be more than 7 nicks in your stats o.)

If you have a backup O:Line for an oper on another server, this does not count towards your total. You are, however, responsible for this persons behaviour while opered on your server. Backup O:Lines must be listed as nickname-backup in your stats o, otherwise they will be counted towards your total. If one of your backups loses their primary O:Line, you're now thier primary. Remove -backup or the oline entirely.

3.2.0 Your servers policies

Your server may have policies that are not global to UKScifi.Net, such as whether or not you allow bots. These policies should be clearly stated in your ircd.motd.

You cannot change the global UKScifi.Net policies for your server.

You can only kill people for violating your servers policies if they are ON your server. Do not kill a bot on another server simply because your server doesn't allow bots.

3.3.0 ircd.conf

As you should know by now, your ircd.conf is the configuration file for your server. An ircd.conf is made up of different 'lines' that are defined by their first letter. Note that the UKScifi.Net server archive comes with an ircd.conf that is ready to go. You should use this conf and edit and add appropriate sections, and leave the rest alone.

The following lines are in the default conf, and should remain mostly untouched:

U:Line - Above ALL else, your conf MUST have a U:Line for services.UKScifi.net. If you do not have one, your server WILL fight with services when they try to function normally. This will disrupt the ENTIRE network. If you don't have a U:Line, it won't go unnoticed for more than a few minutes at most, and once it it noticed, expect your server to be delinked and juped immediatly until it is added.

You should have the following line:


The sections of a U:Line are as follows:

U: The identifier for this line Field: The name of the server to U:Line (Unused): (Unused):

Q:Lines - Q:Lines tell the server which nicks to disallow from users. All servers should have the 8 standard Q:Lines present in their confs:

Q::Reserved for services:*Serv Q::Reserved for services:UKScifi. Q::Reserved for services:?S Q::Bug in mIRC:Status

The first 2 are fairly self explanitory. The 3rd is to stop people from using nicks such as CS, NS, MS, etc. Some people make the mistake of /msg NS instead of /NS, and passwords are hijacked.

The last is because of a bug in mIRC.

The sections of a Q:Line are as follows:

Q: The identifier for this line. (Unused): Field: Reason for the Q:Line Field: What to Q:Line

Wildcards are valid. For example:

Q::Reserved for services:*Serv

This will prevent any non opered clients from using a nick with the word 'serv' in it. It is not case sensitive. If they attempt to use it, They will recieve the message ' Erroneus Nickname: Reserved for services'.

Another example:

Q::One letter nicks suck.:?

This will prevent any nicks that are only 1 character in length.

There is another type of Q:Line, defined in the conf as q: (lowercase) These are server quarantines. They are NOT to be used. Make sure all your Q:Lines are a capital Q.

Y:Lines - Y:Lines define your servers connection classes. The default ones are:

Y:1:90:0:1000:100000 Y:5:90:0:30:100000 Y:10:180:900:1:3500000

You should probably leave these alone unless you have a good reason to change them.

The sections of a Y:Line are as follows:

Y: - The identifier of the line. #: - The class number #: - How often clients/servers in this class are pinged #: - How often the server will attempt to connect to this class #: - Maximum number of connections this class will allow #: - Maximum SENDQ for this class

The higher the class number, the higher the priority for the connections in that class.

Now, Lets take a look at connection class 1, which is the client connection class.


1: We see that this is Class 1. 90: Clients in this class will be sent PING requests every 90 seconds.

0: The server will never attempt to connect to this class. Why? Clients connect to servers, not the other way around. 1000: This class will only hold 1000 connections. 100000: This class will allow a client a buffer of up to 100000 bytes, or 100k, before overflowing and disconnecting the user with an Excess Flood message.

Now lets look at connection class 10, which is our server<>server class.


10: This is connection class 32.

180: Servers will be pinged every 180 seconds. (3 minutes)

900: The server will attempt to autoconnect to servers in this class every 900 seconds, or 15 minutes. Note that autoconnects will only be attempted if the C/N lines indicate it. See C/N lines.

1: Since this is a server connection class, 1 indicates that the server should auto connect to servers in this class, rather than limit this classes connections to 1. 3500000: This class will allow a buffer of up to 3500000 bytes, or 3.5MB before overflowing and disconnecting the client.

(In this case a server)

The majority of the Y:Lines in your ircd.conf are not used. These are holdovers from earlier days. They should dissapear eventually in a future version of the IRCd. However, you should leave them alone for now, just to be safe :)

M:Line - The M:Line identifies your server to the world. It is required, and there can only be one M:Line. The format is as follows:

M:yourserver.UKScifi.net:*:UKScifi.Net's Shiny New Server:7000

M: The identifier of the line. Field: Your servers name. IP: An IP address, if any, to bind to. These are usually wildcards, however if your server is on a shell machine and you are assigned an IP that differs from the machines real IP, you must put it here. Field: Your servers description. This can be anything, keep it short. Port: Your servers default port. For UKScifi.Net, this is 7000.

A:Line - The A:Line identifies who hosts your server, who the admin (you) is, and your E-Mail. The format is as follows:

A:Hosted by a my box:Your admin sucks:yournick@UKScifi.net

A: The identifier of the line. Field: Who hosts the server. Field: Who admins the server. 'Your admin is skold' or 'Your admins are skold and Syro', etc. Field: Your E-Mail. yournick@UKScifi.net is recommended.

I:Lines - I:Lines are client authorization lines. You are required to have at least one I:Line, otherwise no one will be able to connect to your server. The format is as follows:


I: The identifier of the line. Field: Which IP masks to allow (wildcards valid) Password: The password required to connect (optional) Field: Which hostmasks to to allow (wildcards valid) (Unused): Class: The connection class used for this line

We see serveral things about this line. First off, It will allow ANYONE to connect, without using a password. Second, It puts clients into connection class 1, which is our client class.

If we wanted, we could restrict the connections.


This will allow any IPs matching 204.244.142.* OR any hosts matching uniserve.ca to connect. Note that it will attempt a match for the hostname FIRST.

You can also restrict connections to certain usernames (determined by identd, not what the user sends during auth)


This will allow any clients with 'bot' as their ident to connect. All others will recieve the message 'You are not authorized to use this server'.

If you have more than one I:Line, they are read from the bottom up. For example,

I:*@*:password:*@*::1 I:*@163.32.*::*@*.some.isp.tld::1

This will allow anyone matching the IP 163.32.* or the hostname *.some.isp.tld to connect freely. Anyone not matching this is passed on to the next I:Line, which requires a password. If they don't match the IP or host, and don't provide a password, they are told 'You are not authorized to use this server'.

X:Line - The X:Line defines the passwords to be used to restart or shut down your server. The format is as follows:


X: This is the identifier for this line. Field: This is the password required to /die the server. Field: This is the password required to /restart the server.

Note that in order to use either /die or /restart, you must have the appropriate flags in your O:Line, or be a global oper. The D flag is required to /die, the R flag is required to /restart.

P:Lines - These define what ports your server will listen for connections on. The format is as follows:


P: The identifier for this line. Field: Which IP to bind the port to. Should be the same as the IP (if any) you used in the M:Line. (Unused): (Unused): Port: Which port to use for this line.

One P:Line is required for every port you wish to listen on. Do NOT add a P:Line for port 7100, since it was defined in your M:Line. This will stop your server from starting. Note that P:Lines for port 6667, 6668, 6669, and 7100 are REQUIRED. You can add others if you wish.

The following lines are NOT present in the default conf:

O:Lines - These define your opers. A client MUST have an O:Line to oper. The format is as follows:


O: The identifier for this line. Field: The hostmask a client must match in order to use this O:Line. Password: The password required to /oper. Nick: The nick to oper under (Need not be the clients current nickname). Flags: Flags for this O:Line (to define various powers) Class: Connection class for this client. When a client opers, they are moved from class 1 to Class 10.

In order to oper, several things must happen:

The client opering must match the hostmask field. this field can be either an IP or a host mask. If your IP doesn't resolve, you won't be able to oper.

The password must match.

You need to oper with the nick.

For this case, you would type /oper urnick uroperpass to oper.

A note about the flags:

T he above example contains every modeflag possible in IRCd. You should NOT copy this example for your other O:Lines. For this reason there are no O:Lines present in the standard conf. Suggested flags for a regular oper are rhgwlCKbBnNufORD.

The flags for an O:Line are as follows:

Valid Flags:

r = access to /rehash server
R = access to /restart server
D = access to /die server
h = oper can send /help ops
g = oper can send /globops
w = oper can send /wallops
l = oper can send /locops
c = access to do local /squits and /connects
L = access to do remote /squits and /connects
k = access to do local /kills
K = access to do global /kills
b = oper can /kline users from server
B = oper can /unkline users from server
n = oper can send local server notices(/notice message)
G = oper can send global server notices(/notce $*.my.net message)
S = oper can join unlimited amount of channels
A = admin
u = oper can set /umode +c
f = oper can set /umode +f
^ = oper can set /umode +I
e = oper can set /umode +e
W = oper can set /umode +W
H = oper gets auto +x on /oper
o = local oper, flags included: rhgwlckbBnuf
O = global oper, flags included: oRDCK
a = services admin, access to /samode
C = co admin
T = tech admin
A = admin
N = network admin access to remote /rehash and remote /restart and a bunch more
* = flags included: AaNCTzSHW^

Notice that global opers have access to /die and /restart the server regardless of the flags you give them concerning those functions. For this reason you should keep your diepass and restartpass secret.

C:Lines - These lines define which servers your server tries to connect to. C:Lines are to be used in conjunction with N:Lines. C:Lines and N:Lines will not work on their own.

The format of C:Lines is as follows:


C: The identifier for this line Field: The IP address of the server to connect to. Password: The password for the link. (Must be the same on both servers) Field: The name the server your connecting to identifies itself as (defined in it's M:Line) Port: The port to link on (UKScifi.Net servers link on port 7500) Note that the port field is optional. If you don't define a port, your server will not try to auto connect to that server, but it will still accept connections from it.) Class: The connection class (as mentioned in the Y:Lines, our servers run on connection class 10.)

This will tell your server to attempt to connect to, and to look for the server calling itself someserver.UKScifi.net.

N:Lines - These lines define which servers your server accepts connections from. These are used in conjunction with C:Lines.


Notice it is the same format as the C:Line, with 2 differences:

It is N:, not C:.

It doesn't have a port listed.

H:Lines - These define which servers your server will treat as a hub. If a server has an H:Line, your server will allow that server to bring other servers into the link. Without an H:Line, your server will terminate the link if the linked server has other servers linked to it. If you see the message 'Too many servers' when a server rejects a link, It's because that server doesn't have an H:Line for its link. You should add H:Lines for any servers you're going to be linking to, since they will undoubtedly be bringing other servers onto the net. The format is as follows:


H: The identifier for this line. Field: What servers to allow behind the hub. (Unused): Server: The name of the server to allow to act as a hub.

For example:


This will allow server.UKScifi.net to bring any servers that match *.UKScifi.net onto the network. The link will be rejected if other servers are brought on. Since All UKScifi.Net servers run under a common domain, an H:Line with :*: is sufficient.

L:Lines - These lines define what servers your server treats as leafs, ie, which servers it will never allow to bring other servers on. L:Lines are not nessecary and rarely used. The format is as follows:


L: The identifier for this line Field: Address to disallow (Unused): Field: Server to treat as a leaf Depth: Link depth (optional)

The above example will stop any servers under *.au.UKScifi.net from linking servers under *.us.UKScifi.net.


This will stop pandora.UKScifi.net from linking any servers with servers behind it. IE, pandora can link as many servers as it wants, but they all have to be leaves to pandora. None can be hubbing other servers.

K:Lines - These lines define which clients are not allowed to connect. The format is as follows:

K:*.aol.com:AOL sucks:lamer

K: The identifier for this line. Field: The mask of the address to K:Line. Reason: The reason for the K:Line. Field: The username to combine with the mask.

This will disconnect any clients attempting to connect that match the address *!*lamer@*.aol.com with the reason 'AOL sucks'.

The following lines are no longer used or are strongly discouraged:

Timed K:Lines - Timed K:Lines have the time defined in the Reason field, for example:


This will ban all people using *.edu addresses between the hours of 8AM to 12 Noon, and 1PM to 5PM. The client will be allowed to connect at all other times.

Timed K:Lines are not supported by the IRCd by default.

They should not be used.

R:Lines - R:Lines restrict access based on an external checking system. They require an external program to be run to determine if a client should be allowed to link or not.

They are obsolete.

Z:Lines - Z:Lines stop an address from even connecting to the server. It is similar to a K:Line, but different in that a K:Line connects the client, then disconnects it. Z:Lines deny clients from even connecting. There is no notice. They are usually only useful when a server is delinked and the admin doesn't grasp the concept of delinking and tries to reconnect. The format is as follows:

Z:183.203.123.*:Grab a clue, you've been delinked:*

Z: The identifier for this line IP: The IP to zap (can only be IPs. Hosts will not work here.) Reason: The reason for the zapping (Unused): The :* is required.

Z:Lines are strongly discouraged.

This concludes the UKScifi.Net Oper Manual. I hope you found it informative and enlightening. If you found any spelling errors, incorrect information, or have any suggestions for new sections or subsections, E-Mail me at Yu@UKScifi.net.

If you have any further questions, please contact Seti@ukscifi.net

Site Disclaimer - Status

Latest: wardani
New Today: 0
New Yesterday: 0
Overall: 39

People Online:
Members: 0
Visitors: 44
Total: 44
Who Is Where:
01: Statistics
02: Statistics
03: Statistics
04: Links
05: News
06: News
07: Statistics
08: My Account
09: News
10: Statistics
11: Links
12: Topics
13: News
14: Statistics
15: Statistics
16: Statistics
17: Links
18: Statistics
19: Links
20: Statistics
21: Links
22: Links
23: Statistics
24: Links
25: Statistics
26: Statistics
27: Statistics
28: Statistics
29: Statistics
30: Statistics
31: Statistics
32: Statistics
33: Statistics
34: Statistics
35: Statistics
36: Links
37: IRCop Manual
38: Statistics
39: Links
40: Statistics
41: Links
42: Statistics
43: Links
44: Statistics

Staff Online:

No staff members are online!
All original content on this site is part property of UKScifi.Networks

(unless its used by the original authors consent).

All other content is the property of its creator and will be identified as such where possible, We are not responsible for comments posted by our users, as they are the property of the poster.

If you find content on this site that you feel is here without your permission please contact the UKscifi Staff.

The PHP code is the Property of the DragonflyCms team.

UKScifi is hosted on
Ubuntu/8.04 | MySql5.0.51 | PHP5.2.5 | CMS9.2.1

Help keep us alive.
Feed the Kitty!.

Disabled link


Get Firefox!
Original Hardwired theme for CPG-Nuke v1.0 by Twillux, www.twillux.com
Only the Banner (header_01.bmp and middle_background.bmp has been changed)
The logos and trademarks used on this site are the property of their respective owners
We are not responsible for comments posted by our users, as they are the property of the poster
Interactive software released under GNU GPL, Code Credits, Privacy Policy