|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.
UKScifi Networks: IRCop, Admin 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
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
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.
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.
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
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
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.
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
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.
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
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.
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
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.
1.2.10 GLOBOPS, WALLOPS, LOCOPS, CHATOPS
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.
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.
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
/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 127.0.0.1 Don't_irc_from_the_local_machine 0 -1
This is an example of a temporary Z:Line. All users attempting to
connect from 127.0.0.1 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 127.0.0.1 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.
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
IRC is an acronym for Internet Relay Chat. Of course, you already
knew that, right?
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 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.
KILLing a user means to remove them from the network. KILLS
are often issued when a user violates network or server policies.
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.
Permanent AutoKills are identical to AKILLs, except that Services
will not automatically expire them.
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 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 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
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.
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.
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
1.4.0 UKScifi.Net rules and policies
This section is an excerpt from the Rules & Policies section of the
This includes CTCP flooding, text flooding, action flooding, and
any other forms of flooding.
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
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.
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.
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.
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
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
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.
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.
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.
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
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.
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.
EXCEPTION: Similar to TRIGGER.
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
For more information on OperServ's commands, check its helpfiles.
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
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
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.
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.
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:
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
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:
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
If all goes well, you will see a message similar to the following:
-Irc.UKScifi.net- *** LocOps -- Received SQUIT Pegasus.UKScifi.net from
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:
If all goes well, you will see a message similar to the following:
-Irc.UKScifi.net- *** Connecting to *@188.8.131.52[Events.UKScifi.net].
-Irc.UKScifi.net- *** LocOps -- Link with
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.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 firstname.lastname@example.org 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
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
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.
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
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
Q:Lines - Q:Lines tell the server which nicks to disallow from users.
All servers should have the 8 standard Q:Lines present in
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.
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
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
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
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
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
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)
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
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
If you have more than one I:Line, they are read from the bottom
up. For example,
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.
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
Password: The password required to /oper.
Nick: The nick to oper under (Need not be the clients current
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:
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
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 2184.108.40.206,
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.
Server: The name of the server to allow to act as a hub.
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
L: The identifier for this line
Field: Address to disallow
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: 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
If you have any further questions, please contact Seti@ukscifi.net