Please see our other FAQ which answers this question better.

Please check out the releases announcements on the forums

How is this different than a regular download?

Below we describe how to get the very latest code from our git repository. This contains code changes committed only minutes or days ago and is considered 'bleeding edge'. Possibly nobody has tested this code, or just one person. It may not even compile. Most people use the Downloads instead as they would have received some testing (or minimal testing in case of 3.4.x)

A word of caution...
Note that in addition of the warning of above, 3.4.x is also in early development. Therefore the IRCd may crash from time to time, so use it at your own risk (and be sure to read the release notes). That being said, you'll help us a lot by trying out the latest development versions and reporting bugs on our bug tracker. Just don't run it as a production server ;).

GitHub
Previously we used a different source control system. Now we have moved to git and we have our own page at GitHub. You can also easily see the most recent activity there, just like before.

Option #1: I'm lazy, I just want a .tar.gz or zip!
Go to our GitHub page and on the right click on 'Download ZIP'.

Option #2: The 'real way' to get the latest source...
This describes how to 'checkout' the repository on your machine, which allows you to easily pull in updates (which happen every day/week). First, run:

git clone https://github.com/unrealircd/unrealircd.git

This will create a directory 'unrealircd' with all the source code (3.4.x by default, see later).
If, after a few days, you want to pull in the latest changes then run the following in your unrealircd directory:

git pull

3.2.x or 3.4.x?
By default you will see the 3.4.x development branch called 'unreal34'. If you want to see the 3.2.x branch then type 'git checkout master' in the 'unreal' directory. You can later switch back to 3.4.x by typing 'git checkout unreal34'

git: command not found
If you get something like git: command not found then you need to install git, the package is usually also called 'git'.

If you think you found a bug, or you have a feature suggestion for us, please report it at bugs.unrealircd.org.
This process only takes a couple of minutes.

We use bugtracker software so we don't loose track of bugs, so PLEASE report it there and don't report bugs to us via IRC, email, forums, or any other way... all that will happen is we will forget about it and then your bug will not be fixed.

The bugtracker aids us with coordinating what bugs should be fixed in next version, what has priority, which bugs are similar (or duplicates) and thus may help us spot patterns, who should fix what bugs, etc.

First of all, if you're on Windows, be sure to download the Windows version (not the .tar.gz).

If you are on *NIX and have no idea what to do with a .tar.gz then.. Sorry, but you SHOULD NOT run this ircd. UnrealIRCd requires some basic knowledge about networking, IRC and *NIX.

For ALL OS's except Windows: you need to configure and compile the IRCd:

1. Run: ./Config
2. Run: make
3. If you want to install the IRCd at a different location than the defaults then finally run: make install
4. Then, see next...

For both Windows and *NIX:
If you are new, then you need to create your own configuration file:
copy doc/example.conf to your main UnrealIRCd directory and call it unrealircd.conf.
Then open it in an editor and carefully modify it, consult the documentation where necessary and use this FAQ.

If you get this when you did ./Config:

checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check

Fix: This means you need to install a C++ compiler, usually this means you need to install a package named "gcc-c++", "g++", or something similar. After doing that, re-run ./Config and the error should no longer be there.

This issue is also fixed in Unreal3.2.5

Do NOT use ./configure! Use ./Config instead.

Did you run ./Config?
Probably something went wrong when running ./Config, take a look at the output :P. Maybe you don't have a C compiler or you are compiling on a non-support(-yet) OS.

You are trying to compile you ircd on a nice shell and your sysadmin has set your process limit too low.
Explain the problem to your sysadmin (say you are unable to compile because of the process limit) and paste the error to him.

If you get something like:

$ make
Building src
make[1]: Entering directory `/home/irc/Unreal3.2/src'
gcc -I../include -I/home/irc/Unreal3.2/extras/regexp/include -pipe -g -O2 -funsigned-char -export-dynamic   -c auth.c
In file included from auth.c:21:
../include/struct.h:68:23: tre/regex.h: No such file or directory
In file included from auth.c:21:
../include/struct.h:797: error: parse error before "regex_t"
../include/struct.h:797: warning: no semicolon at end of struct or union
../include/struct.h:800: error: parse error before '}' token
In file included from auth.c:21:
../include/struct.h:1200: error: parse error before "regex_t"
../include/struct.h:1200: warning: no semicolon at end of struct or union
../include/struct.h:1282: error: parse error before "regex_t"
../include/struct.h:1282: warning: no semicolon at end of struct or union
make[1]: *** [auth.o] Error 1
make[1]: Leaving directory `/home/irc/Unreal3.2/src'
make: *** [build] Error 2

Then it means something went wrong during ./Config, so check out the last output of that.
Also make sure the date/time on your system is correct (run 'date') or else things will be wrong anyway.
If that didn't work, let us know of the problem and report it on bugs.unrealircd.org, be sure to include the last 30 lines or so from the ./Config output, and the 'make' output as well, Thanks.

NOTE: We highly suggest you to simply download the Windows precompiled version from unrealircd.com instead of compiling your own (unless you need to).

This error can mean a number of things, but if you see unresolved symbols in non-windows functions, such as:

  Creating library L_COMMANDS.lib and object L_COMMANDS.exp
M_OPER.obj : error LNK2019: unresolved external symbol _sendto_snomask_global re
ferenced in function _m_oper
M_INVITE.obj : error LNK2001: unresolved external symbol _sendto_snomask_global
src/modules/commands.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

Then this is because the wircd.def file is not up to date with your compile settings. Fixing this is simple, you need to download dlltool.exe and place it in your path (eg: c:\winnt\system32). Then, for compiling you use something like this:

nmake -f makefile.win32 [your other options here]
nmake -f makefile.win32 SYMBOLFILE
nmake -f makefile.win32 [your other options here]

So basically you just run nmake -f makefile.win32 SYMBOLFILE and then restart compiling again.

If that didn't help, then this is a different problem (eg: old compiler, too new compiler, invalid compile environment, etc).

If you get something like:

mv: Makefile: set owner/group (was: 1002/0): Operation not permitted
config.status: creating src/modules/Makefile
mv: src/modules/Makefile: set owner/group (was: 1002/0): Operation not permitted
config.status: creating unreal
mv: unreal: set owner/group (was: 1002/0): Operation not permitted
config.status: creating ircdcron/ircdchk
mv: ircdcron/ircdchk: set owner/group (was: 1002/0): Operation not permitted
config.status: creating include/setup.h
mv: include/setup.h: set owner/group (was: 1002/0): Operation not permitted.

Then you can safely ignore these warnings.

Long story: if /tmp is mounted with special options, then files copied to there will have their user/group changed, ./Config tries to correct this but that's denied. This is a completly harmless warning, so you can safely ignore it.

DO NOT use 'gmake', use 'make' instead (as ./Config said when it finished).

NOTE: We highly suggest you to simply download the Windows precompiled version from unrealircd.com instead of compiling your own (unless you need to).

First of all, be sure to have read doc/compiling_win32.txt to see what you need and how to compile.
HOWEVER, see below for a list of compiler versions that work and do not work.

Version:	Official name:	Works?	Details:
6.0	Microsoft Visual Studio 6.0	No	No longer able to compile Unreal
7.0	Microsoft Visual Studio .NET (2002)	Yes
7.1	Microsoft Visual Studio .NET 2003	Yes
8.0	Microsoft Visual Studio 2005	Yes	Works since 3.2.5.
9.0	Microsoft Visual Studio 2008	Yes	Works. Used for official compile.

If you get something like this:

if /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -g -O2 -Wall -MT tre-ast.lo
-MD -MP -MF ".deps/tre-ast.Tpo" -c -o tre-ast.lo tre-ast.c; \
then mv -f ".deps/tre-ast.Tpo" ".deps/tre-ast.Plo"; else rm -f ".deps/tre-ast.Tpo"; exit 1; fi
libtool: compile: cannot determine name of library object from `'
gmake[3]: *** [tre-ast.lo] Error 1
gmake[3]: Leaving directory `/home/irc/Unreal3.2/extras/tre-0.7.2/lib'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/irc/Unreal3.2/extras/tre-0.7.2/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/irc/Unreal3.2/extras/tre-0.7.2'
gmake: *** [all] Error 2

Then this is a weird FreeBSD problem (rare?).

In any case, upgrading the bash package should fix it.

Check service.log (or ircd.log) and fix your errors.

You didn't load the commands module, you need to load some modules in order to get UnrealIRCd to work. Be sure to have the following lines in your unrealircd.conf:

*NIX:

loadmodule "src/modules/commands.so";
loadmodule "src/modules/cloak.so";

Windows:

loadmodule "modules/commands.dll";
loadmodule "modules/cloak.dll";

You didn't set a required variable in your set block. All variable are explained in detail in the documentation (set block).

Your configfile doesn't contain a required block, please check the documentation which describes every block in detail.

Several possibilities:
a. you have a unknown/misspelled variable name.
b. you forgot to load a module
c. you are using an older unreal version (note that the online documentation is about CVS so it may contain features not yet available in the current release).
d. you have put the setting in the wrong place, for example set::options::dont-resolve means set { options { dont-resolve; }; };.
e. you have a parse error in your config file. For example, the admin block should be something like:

admin {
    "Blah";
    "Blahblah";
};

If you forget a ; or a } it won't work!

You are referring to a class which you didn't declare before. You refer from allow/oper/server blocks to class blocks so the class blocks should be defined _before_ you refer to them. See the documentation about the class block.

You are trying to use SSL on an IRC server without SSL support. You have two options:
1. Recompile or download UnrealIRCd with SSL support (RECOMMENDED, see below)
-or-
2. Remove 'ssl' from your listen block to make it a non-SSL port.

Assuming you do want to use SSL (and you should, it's cool..):

• On *NIX this means you have to re-run ./Config and answer Yes to the question about SSL, then run 'make' and 'make install' and restart the IRCd.
  
• Windows users can simply download the Windows SSL version of UnrealIRCd.

You are trying to use SSL on an non-SSL IRCd. Either recompile/redownload UnrealIRCd with SSL support or remove the 'ssl' option in the link block. See the answer to previous question for more details.

You didn't compile the ircd with ziplinks (zlib) support and have zip set in your options block of a link. Either recompile with zip links support or remove it from your link::options block.

If you get:

The OS enforces a limit on max open files
Hard Limit: 512 MAXCONNECTIONS: 1024
Fix MAXCONNECTIONS

or something similar, then your OS is limiting your maximum number of open files/sockets... You need to rerun ./Config and answer the number showed in "Hard Limit" (512 in this example) to the question "How many file descriptors (or sockets) can the IRCd use?", and recompile (make clean; make).

You need to set your 3 cloak keys to a string with random lowercase (a-z), uppercase (A-Z) and digit characters. The string should be 5-100 characters long (we suggest 15-25 characters)
Example:

set {
 cloak-keys {
  "a2JO6fh3Q6w4oN3s7";
  "Shfid6sfw3gqG8If";
  "sdh3iAe2QH7UfdNsh";
 };
};

Important notes:

• NOTE: DO NOT JUST COPY THE CLOAK KEYS FROM ABOVE! The cloak keys must be SECRET!
• The keys need to be the same on all servers on one IRC network, otherwise bans won't work correctly.

This means another process is listening at this port. Usually it's on of these:

• An IRCd process is already running on the same port(s).
• You are on a shell box. Then you need to 'bind' to a a specific IP which the shell provider assigned to you.
  For example, change:

  listen         *:6667;

  To:

  listen         1.2.3.4:6667;

  Where 1.2.3.4 is the IP you receveived from your shell provider.
  You probably need to do this for ALL your listen blocks.
  
  See the documentation on the listen block for more details if you like.
  

Check ircd.log or service.log :).

If you compiled with zlib, openssl or remote includes support, be sure you checked out the win32 development page and use the win32 development package.

NOTE TO END USERS: If you did not compile your own UnrealIRCd versions, see Other - My server crashed! on what to do.

You need to load a cloaking module.

Add this to your unrealircd.conf if you're on *NIX:

loadmodule "src/modules/cloak.so";

Add this to your unrealircd.conf if you're on Windows:

loadmodule "modules/cloak.dll";

You also need to set your cloak keys. See Booting - set::cloak-keys.

If you are on windows:
loading the commands and cloak module is required, but you need to specify the proper paths for them. Remove the old loadmodule lines and add these:

loadmodule "modules/commands.dll";
loadmodule "modules/cloak.dll";

If you are on *NIX: Most likely something went wrong with your compile... check if src/modules/commands.so is present in your unreal source dir. If it is, and you specified a different path than the defaults in ./Config, make sure the path in your loadmodule line is correct (eg: perhaps for you it should be modules/commands.so).

If you get a message ike:

[error] unrealircd.conf: Unexpected EOF for section starting on line 123

Then this means you forgot a };, " or ; somewhere BEFORE that line number (could be 1 line above, but also 100 lines earlier).
Here's an example of what is GOOD:

admin {
  "blablabla";
  "blah!";
};

And here are some examples to show what is WRONG:

admin {
  "blablabla";
  "blah!";
} <-- missing ; character

admin {
  "blablabla" <-- missing ; character
  "blah!" <-- missing ; character
};

admin {
  "blablabla";
};
  "blah!"; <-- outside any block

etc...

If you get undefined symbol errors such as:

* unrealircd.conf:52: loadmodule src/modules/commands.so: failed to load: tmp/F73A8A80.commands.so: Undefined symbol "ssl_get_cipher"

Then most likely you did not upgrade or (re)compile UnrealIRCd properly:
make sure you do: 'make clean; ./Config; make && make install'

Reasons why it might not have worked:
- Perhaps you forgot 1 of the steps of above
- Make sure your irc is installed in the path you think it is: 'grep PATH config.settings' will show you what the IRC installation directory is and the path to the ircd binary.
- Perhaps the ircd binaries or modules (.so's) are still the older ones, double check by ls -al'ing them (use the PATH information from above!) and checking the date/time

If all that didn't work, try a clean UnrealIRCd... rm -rf or rename your current one, extract a fresh .tar.gz and configure&compile it (you can just use your original configfiles/motds/rules/etc of course).

There was an issue in 3.2.10 on Windows where users would get killed on the Windows server by other servers soon after linking. Also other errors where broadcasted to all IRCOps.
Here are a few examples of error messages that could occur:

Notice -- Received KILL message for XXX!yyy@zzz from xxxxx Path: irc!xxxxx (XXX <- YYY)
Cannot find server XX (&....
Missing user XX in SJOIN for #...
      

The solution is simple: upgrade to UnrealIRCd 3.2.10.1!

Please check on both sides which messages you get... The *receiving side* will have the detailed error message. Take a look at the documentation on the Link block. The error messages are explained here:
No link block named 'something'
The server does not have a (correct) linkblock with that name, it should be: link servername {. Servername is the name of the remote me { } block, not the ip or something.
Username 'something' didn't match 'blabla'
The link::username field didn't match, just use: username *;
Server is in link block but IP/host didn't match
The servername and username are right, however the link::host and/or link::ip fields didn't match, you should fill in the right hostname or ip of the remote server, this is used both for connecting and validating. Example: hostname irc.blah.com;

Multiple possibilities... Are you perhaps connecting to a SSL port while you don't have ssl in your link options block? If that wasn't the problem, check both sides for error messages, check host/ip/port, etc.

Multiple possibilities...
SSL: Do you have ssl in your link options field and are you perhaps connecting to a non-SSL port? Do "/mode yourself +s +j" and if you get something like "Internal OpenSSL error or protocol error" then this is probably the case (if you do want to link with SSL then also make sure both servers are compiled with SSL support).
Network: Check link::ip, link::host and link::port.. Also check if the remote host isn't firewalled (?). The easiest way to do this is to simply telnet from server A to server B to the irc port and see if it gets connected.

Your me::numeric should be different at all servers, see the documentation on the Me block.

After changing the numeric you simply do a /REHASH (note: if you are linked to any servers, you must unlink them first, before rehashing).

Your cloak keys (set::cloak-key) should be the same at all servers. If you ignore this advice then bans at cloaked hosts won't work correctly (because the cloaked host will differ between servers).

If you get such a warning this means your clocks are not synched.
Correct time is VERY important for IRC servers, if the clocks are off for just 20 seconds you may run into trouble already. If your clocks are minutes or even hours off, you are guaranteed to have problems.
To name a number of problems that will occur if your time is off:

• temporary *lines/shuns will not expire correctly, they might expire like an hour earlier (or even directly on add) or later
• sudden (wrong) nick collision kills
• channels might not show up in /LIST (this requires the time to be off by 24h or more)
• services might be unable to set a user +r (+r = register user)
• more..

Solution 1 (RECOMMENDED) (*NIX): Synch the server clock
You should run ntpd (=daemon) or ntpdate (=simple util, usually ran via cron) on all your servers.. this is pretty easy to set up and once it's working it should take care of all your worries. Note however that this requires root access. On most Linux distro's you simply run

apt-get install ntp

or

yum install ntp

Once you are certain ntp is running (check your system log), then we recommend you to disable the build-in time synchronization in UnrealIRCd by adding this to your configuration file:

set { timesynch { enabled no; }; };

Solution 1 (RECOMMENDED) (Windows): Synch the server clock
Newer Windows versions (XP and later) should automatically synchronize the clock. If it isn't working, google around.

Solution 2: build-in time synchronization in UnrealIRCd
UnrealIRCd has build-in NTP support and will try to synchronize the clock when it boots and then maintain an internal offset. This will make time appear correct (for the IRCd). Unfortunately this does not help against 'clock drift' where the time offset will change, for example if your clock is too slow it may be off by 2 seconds on the first day.. 4 seconds on the 2nd day.. and so on. Only NTP (see Solution 1) can help with this.

Solution 3: Synch via services or /TSCTL
We no longer recommend this. This can ONLY be used if your clock is off just for like <30 seconds because otherwise the IRCd may do all kinds of weird things (it really doesn't like time jumps of 30 seconds or more, in the future or in the past).
Your services may provide this command, it's usually called TSCTL or something with TIME.

About time zones
Note that linking ircds from different timezones is NO PROBLEM because GMT/UTC time is used for everything. It is however important that you have your time zone (and time) configured correctly. For example if you are on the eastcoast USA then don't set the time zone to westcoast with an eastcoast time.

When trying to link to another server the link may be rejected if the clocks don't match. Example error:

Rejecting link xx.xx.xx[@X.X.X.X.59383]: our clock is 575 seconds ahead.
Correct time is very important in IRC. Please verify the clock on both services.test.net (them) and
maintest.test.net (us), fix it and then try linking again

Or from a link error:

Your clock is -1337 seconds ahead of my clock. Please verify both your clock and mine, fix it
and try linking again.

This is a safety measure from UnrealIRCd, as having incorrect clocks can be a major source of trouble.

Go on and read this FAQ item to read why correct time is so important and how to make sure the clock on your servers are correct.

Some people have reported seeing an "invalid argument" error when trying to connect to another server (either via /connect or autoconnect).

One explanation is that you have a firewall blocking outgoing connects. This is not really standard, so if you have this you probably know you have :).

Another explanation is some kind of error / odd behavior. This has likely been fixed in 3.2.10.3. You may be able to work around it by using an IP in link::bind-ip rather than using "*". Be sure to use the IP of the machine itself here and not the IP of the server you are connecting to!.

This means you do not have your DNS properly configured. If you are connecting to for example 'irc.blah.com' then you need to OWN the domain 'blah.com' and add an A record for 'irc' and point it to your IP.

This is really basic network admin knowledge.

If you are connecting locally: If the IRCd is on the same box as you then try '/server 127.0.0.1', if the ircd is running and your listen lines are correct (the default ones are ok) then you should be able to get onto the ircd. If not (still talking locally here), then most likely your ircd is not running or your listen blocks are wrong.

If you are connecting remotely: See next question (below).

First of all, can you connect locally to your IRCd?
Try /server 127.0.0.1 6667 to connect to localhost.
If even yourself can't connect to your own IRCd by this then verify if the IRCd is running at all! Or maybe you bounded to a specific IP. Everything below assumes you can successfully connect locally, so if you can't, then stop reading here.

Have outside users connect to your IP
First of all, always have users try to use your IP first rather than a hostname. So '/server 1.2.3.4 6667' where 1.2.3.4 is your internet IP. You can find out your internet IP by going to whatsmyip.org or similar sites.

You probably need some port forwarding..
If users still can't connect to your Internet IP then most likely a router or firewall in-between is blocking their access. Most likely your router.
You need to "forward" your IRCd port (usually 6667 and 6697) on your router. Identify the brand of your router and see portforward.com for help on how to do this.

Don't forget Windows firewall!
You may need to allow the Windows Firewall to allow incoming connections to your IRCd. It should have asked this when you fired up the IRCd. Alternatively, you can disable Windows firewall if you trust the people on the same LAN and are connected to the internet via a router.

Finally...
When the port has been forwarded on your router and windows firewall is turned off (or on but incoming IRCd connections are allowed) then it should be no problem to get outside users on your IRCd. Have fun!

You probably didn't include load the help file in your unrealircd.conf. Add:

include "help.conf";

Also if you are an oper (helpop) you must prefix your request with a "?", like: "/helpop ?" and "/helpop ?usercmds".

Since this can be pretty abusive you need an additional flag called can_override in your operflags (see oper block).
NOTE: don't forget to /rehash and re-oper (mode yournick -o and then /oper again)!

If you have can_override, you can now op yourself (/mode #chan +o yournick) or without can_override as a services admin or higher you can use /samode #chan +o yournick.
To join a +k/+i/etc channel you need to invite yourself, it will then override it.

*sigh*

One possible solution to get in again:
Edit your unrealircd.conf and add an exception block & except ban block for your IP.
For example:

except tkl { mask *@1.2.3.4; type all; };
except ban { mask 1.2.3.4; };

And then run './unreal rehash'. These exception blocks will make you immune from gline, klines and so on.

NOTE: There's no way to remove *lines from the shell

First, you need to include help.conf in your configfile, like:

include "help.conf";

2nd, if you are an ircop (helpop) you need to prefix your request with a ?, so: "/helpop ?", "/helpop ?usercmds", etc...

• Note that both the username and password are case-sensitive. So if you have an oper block for SyzoP with password xyz then you really need to type:

  /oper SyzoP xyz

• Most problems arrise from a too strict oper::from::userhost. Try setting it to *@* to start with, you can make it more strict later.
• Be sure to REHASH the IRCd after making any changes. A restart of UnrealIRCd works too, but is unnecessary drastic. Rehashing can be done in Windows from the GUI, or in *NIX on the command line through

  ./unreal rehash

• Services packages usually provide this. You can use

  /OS GLOBAL Hi this is a message to everyone!

• You can also (without services) use:

  /NOTICE $*.yournet.com Hi this is a message blabla

  However, this requires all of your servernames to end in yournet.com.

First, /list does of course hide +s channels unless you are an oper or already in that channel.
Another possibility is that it's the channelname, mIRC for example has an option called 'Hide non-alphanumeric channels' under 'list options' which is enabled by default and which will hide channels like #.blah, other clients might have similar "features".
There's another possibility as well, if the time on your servers are off by 24h then some or all channels will be hidden.. Solution: SYNCH YOUR CLOCKS.

In older Unreal versions (3.2.2 and earlier) this happened after a while after an oper used /SAMODE with certain parameters, this has been fixed in 3.2.3.
If you still get this problem and all your servers are running Unreal3.2.3 then there are still a few posibilities:
- a protocol error, by for example weird services.
- memory corruption

The only solution for it is to recreate the channel. So: let everyone leave the channel and after everyone has done that, join again.

Technical details: the timestamp is when the channel has been created and is measured in epoch time (the amount of seconds since 1-1-1970 00:00 GMT), obviously values like '1' or '30' are impossible.

SHORT ANSWER:
Increase your class::sendq
LONG ANSWER:
This happens when a client issues a request that will return A LOT of data, usually '/who' (eg /who #channel). If you for example have large channels like 300+, 500+ etc... then /who #chan will return A LOT of data, therefore the max sendq (sendq == send queue) is reached and the client is disconnected... Some scripts do a '/who #chan' on join, this explains why certain people will die directly on join, while others will not :).

The solution is to simply increase the sendq. What the best value is? Something like 250000 is reasonably high. If that doesn't work, try 500000.

You get *** Couldn't resolve your hostname; using your IP address instead?
The best way to test is to let someone from a remote location (not your LAN) connect to you where you can be sure of his host resolves (for example it works at ircnet/efnet/undernet/..). If it doesn't work, it's probably something with your box or unrealircd:

Currently the 3.2* series ignore the set::dns block and read the nameserver info directly from /etc/resolv.conf (*NIX) or the registry (windows). Type '/quote dns i' (as an oper) to see the current nameserver in use by UnrealIRCd, if you changed your nameserver settings in resolv.conf or in windows then you will have to RESTART (not rehash).

Example of how to test your nameserver at *NIX:

# host 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer test.domain.
# host test.domain
test.domain has address 1.2.3.4

In this example the host is correct and the nameserver seems to work fine.

Perhaps your firewall/router?
UnrealIRCd uses it's own resolver and listens on a random udp port, this could in rare cases cause problems with firewalls (for example if you use a remote dns server and a dumb+strict firewall). If you type '/quote dns' (as an oper) you'll then see something like:

-test.test.net- Ca 0 Cd 0 Ce 0 Cl 0 Ch 0:0 Cu 0
-test.test.net- Re 0 Rl 5/0 Rp 0 Rq 5
-test.test.net- Ru 0 Rsh 0 Rs 10(5) Rt 5

the Rp 0 means it received 0 replies, clearly a problem here.

UnrealIRCd contains a feature called "spamfilter" which is an effective tool for fighting spambots. Read more about it in the docs.

If you get messages like:

Exiting ssl client [@1.2.3.4.1234]: SSL_write(): Internal OpenSSL error or protocol error
Exiting ssl client [@1.2.3.4.1234]: SSL_write(): OpenSSL functions requested a read()

Or anything else like that then it's nothing to worry about, these are sent to the JUNK snomask.. which is.. guess what? for junk...
What this error message means is that someone (or something) tried to connect to the SSL port but something went wrong.. in almost all cases it is a non-SSL client connecting to a SSL port, things like a bot, another server (w/autoconnect) or services trying to connect every X minutes...

To summarize: it's usually nothing to worry about and not an attack, unless you get like X msgs of these per second the whole time ;).
If you don't like it, remove the junk snomask (/mode nick +s -j).

You need to have set::hosts::host-on-oper turned on and have the get_host flag in oper::flags.
When you have both of them enabled it should work.

NOTE: As usual.. always /rehash and re-oper (/mode yournick -o, and /oper up again) to test it.

Of course you need to /rehash (and check if it doesn't give you any errors or warnings)...
And if you have changed the oper block then you ALSO need to re-oper, so:
- /mode yournick -o
- /oper nick pass

If you add a new gline/gzline/shun with a time limit (say, 300 seconds) and:
- some servers immediately remove it after it was added OR:
- some servers don't seem to remove it at all (or perhaps XX minutes or hours too late!)
(if you are not on those servers you can easily check it remotely via /stats)
Then most likely your clocks aren't synched correctly!
You can check this out via /TSCTL ALLTIME, this will show something like:
*** Server=alpha.test.net TStime=1086743157 time()=1086743160 TSoffset=0
*** Server=beta.test.net TStime=1086743157 time()=1086743159 TSoffset=0
*** Server=gamma.test.net TStime=1086740151 time()=1086740151 TSoffset=0
As you can see the difference between the alpha+beta and gamma are ~3000 seconds, this is WAY too much.. it may only be a few seconds, anything over 15 seconds is not recommended and likely to bring you into trouble.

Synch the clock
See this FAQ item about how to synch your clocks and more info.

Most likely you (accidently) set channelmode +u. Simply unset it through /MODE #chan -u

+u (auditorium) hides normal users (users without voice, ops, etc) in the nicklist and doesn't show join/parts/quits/.. for them to other normal users.

It is/was meant for celebrity alike chat systems, read-only news/announcements channels, and things like that. In practice it only confuses people and is scheduled for removal in 3.4.x.

Situation:
You do something like /(g)zline *@blablabla.dialin.bla.com and get:

WARNING: (g)zlines should be placed on user@IPMASK, not user@hostmask (this is because (g)zlines are processed BEFORE a dns lookup is done)

Explanation:
zlines (and global zlines, gzlines) need to be placed on an IPmask and not a HOSTmask. The reason for this is that zlines are processed right after accepting the connection, before any data is received and before any dns lookups are done. So a (g)zline disconnects the user IMMEDIATELY (that's, in fact, the difference between (g)zlines and klines/glines).

Solution:
Place the ban on the IP of the user (eg: *@194.92.91.90), you can get this by /whois'ing the user (the 'connecting from' line). If the user already left then you could use your '/dns [host]' client command, although that's a tad less safe[1].

[1] If the bad guy owns the domain, then he might have updated his name to point to another ip.

What is cloaking?
Cloaking is a means to hide the real host from other users, for resolvable hostnames it looks a like Gll-20409F99.arcor-ip.net, and IP's will look like 9DD2051.356EF559.713C47B6.IP. You get a cloaked host by the usermode +x (this can be manually set, or automatically by the server). For more general information on cloaking, see the section on cloaking in the docs.

How to disable it?
You have several options:
Option 1: make cloaking not the default
Just remove the 'x' in set::modes-on-connect, then users will not be set +x automatically and thus will not be cloaked.
Users can still, if they want to, set themselves usermode +x.
Option 2: fully deny users to be cloaked If you don't even want users to be cloaked when they want themselves to, in other words: prevent users from setting themselves +x. Then like the previous step, remove 'x' from set::modes-on-connect if it is present, AND set set::restrict-usermodes to 'x':

set { restrict-usermodes "x"; };

Option 3: load a "nocloak" cloaking module
While option 2 is recommended if you really want to disable cloaking, it still requires you to set cloak keys etc... To really remove the whole cloaking algorithm from the server you can load a cloaking module that does nothing (iotw: it returns the real host). You can find the nocloak module here.

Are you using Microsoft Visual Studio 2005 (8.x)? If so, then it's likely the IRCd will crash. This is a known issue.

See this faq item for compilers that DO work ok and some more info. about this issue.

If you are NOT using MSVC8, then report it at bugs.unrealircd.org and give some details.
If it's possible to reproduce the bug, then it would be very helpful if you could also check if the official unreal version (from unrealircd.com) also crashes or not (otherwise you might be asked to do this).
Naturally, the usual rules apply, that is: if you modified the source code (excluding config.h changes) then we are not responsible for the code/crashes anymore. Additionally, if you run 3rd party modules, we might as you to remove them and try again, BUT.. it's still worth to directly report crashes since we are generally quite interested in them.

Situation
If you are on *BSD (eg: FreeBSD), have compiled with IPv6 ENABLED, and have something like:

listen *:6667;

and while it's listening on the IPv6 address(es) just fine, connecting to the IPv4 IP on 6667 does not work.
Solution
Change sysctl net.inet6.ip6.v6only to 0. You can do this by adding net.inet6.ip6.v6only=0 to /etc/sysctl.conf and reboot, and/or executing "sysctl -w net.inet6.ip6.v6only=0" as root.

When we are at it, make sure you have ipv6_ipv4mapping="YES" in your /etc/rc.conf as well.

NickServ, ChanServ, .. are supplied by a services package. UnrealIRCd (just like most ircds) doesn't come with services, you have to choose, download and install your services separately.

We don't integrate services in UnrealIRCd itself because we feel you should be able to choose a package that you like yourself. People tend to disagree on which services are the best, it's better to keep this separate from the ircd or else we get "religious wars".

See our Links section.

Your set::services-server should point to your services server. For example:

set {
 services-server "services.mynet.net";
};

These things are called aliases, and you should configure them, usually by just including the correct configuration file in your unrealircd.conf. See the aliases/ directory.

For anope it's for example:
include "aliases/anope.conf";

Make sure your services are U-lined at all servers. Also, after you change your ulines, rehash and the services server has to be RELINKED (just restart it).
While you are at it, make sure your set::services-server is set correctly too.

NO!
#unreal-support is strictly (surprise!) for UnrealIRCd support. It is NOT for support on any other software or hardware like: services, DSL modems, routers, how-to-use-Linux, ..
Sure, you can talk about this stuff with someone in a query but not in the channel. If you do start such an conversation, don't be surprised if you get banned!

If your server crashed and you are running the latest or previous version without any source modifications, then please report it at bugs.unrealircd.org.
EXCEPTION: If it crashed due to your self-coded services or raw commands then maybe not, see next question... (if you don't know what this means, then just report the bug, since this exception probably does not apply to you ;P).

If you managed to crash Unreal by sending some illegal command from a linked server, for example by /OS RAW ..., or by sending your own incorrect raw command by your self-coded services, then this might very well not be fixed.

Rationale:
UnrealIRCd trusts remote servers (once they are linked), this ranges from access checking (servers have [almost] full power) to syntax checking. Often for various reasons (speed, lazyness, etc) we do (often) not have checks in place to check the syntax of all remote-server traffic.
Examples of ways to crash Unreal by a trusted server are:

• sending commands like a STATS request with a server as source (and not a [psuedo-]client)
• sending a command with a missing (or extra) parameter, such as an invalid TKL command
• many more

There are currently too many ways to crash UnrealIRCd by sending illegal trusted server traffic, you should not be sending these illegal things in the first place!.

Users coding their own services or experimenting with RAW should know what they are doing!
Major services packages such as anope and ircservices also warn for the use of RAW and discourage it's use, the same is true if you're not toying with services raw but with a directly linked "own server" or telnet / nc (in fact, the situation is exactly the same).
This philosophy is not unique to Unreal.

History...
Previously our position was that such ""bugs"" never would be fixed. Nowadays we might if we come across them, but we don't actively find & fix them since should do far more useful things without our scarce developer resources!

PREFIX_AQ will give +a (chanadmin) the & prefix, and +q (chanowner) the ~ prefix... just like +o has @. This also means you no longer need to +qo/+ao a user, just +q/+a is enough.

The question whether to enable this is asked during ./Config on *NIX. It's turned ON in all our windows builds.

How to turn it off
As said above for *NIX, just say No to the ./Config question. Windows users will have to compile their own UnrealIRCd (which requires a compiler and some experience with this), grab the source (the .tar.gz) and see doc/compiling_win32.txt for instructions. You can find the PREFIX_AQ define in include\setup.h

It is NOT possible to use any other symbol than & and ~, these two characters were carefully selected for a number of technical reasons. If you try to use other symbols anyway you'll loose support and break other things.

First, let me explain that an IRCd is relatively unique in the sense that it has to run 24/7 without any interruptions. If there's even a single (major) error somewhere it will crash and all existing users are disconnected. Compare this to a web or mail server where in case of a crash the user will simply have to press Refresh or Resend and in many cases crashes even go completely unnoticed.

In UnrealIRCd (just like in any other software package) bugs are discovered all the time and these bugs are then fixed in the next version. These are often minor bugs or tweaks but also include bugs that may enable any user to crash the server. Or even worse, bugs that enable you to become an IRCOp or give you the ability to execute random code.

Even if you are running the same version without any problems for 3 years, just the fact that it's 3 years old most likely means serious bugs have been discovered in those past 3 years. You should really keep your IRCd up-to-date. It's no fun when a kiddie is crashing all your servers every 5 minutes and you need to upgrade all ircds as soon as possible, half of your admins are away/unreachable and your users are going crazy...

First, WE DO NOT HELP with modifying the source.
Second, if you modify the source you'll loose all support (weird bugs, crashes, etc) because we can no longer be sure if any bug is caused by us or by you. It's easy to make a tiny mistake in C which causes memory corruption and can screw everything up, we don't want to waste OUR resources on YOUR bugs.
However, you can still get support by trying to reproduce any bugs on a "clean" UnrealIRCd (that is, ircd with no modification), and then reporting it on bugs.unrealircd.org. So it's not like you are completely cut off.. We just want you to retry things on the official version.

You can imagine what our reaction is after (an) hour(s) of debugging just to find out it's caused by your modifications!
Here's an example [IRC LOG]: I was about to leave, but then some came in #unreal-support and talked about crashes, so I thought let's query him quickly.. I ask him explicitly if he's using any 3rd party modules or modifications, he says no... in the end it turns out unrealircd crashes at an impossible position because of HIS modified code.

We do offer Custom Coding for money however, these are modifications done by someone of the team. If you then have any crashes or weird issues, the person who did the modifications will help you.

This is easier said than done. The maximum amount of connections (also called file descriptors [fd's] or open files) depends on multiple things... Before you read all of this you should understand that the following requires help of your sysadmin (unless you have root access yourself). Note that you shouldn't try to have all your 10K clients on one server, in general it's better to spread them among multiple servers!
** The system maximum **
On Linux this is all OK, go to next step
With FreeBSD you should do something like: sysctl kern.maxfiles=8192 (and add it to your /etc/sysctl.conf of course). You probably also need to increase kern.ipc.nmbclusters, and perhaps some other ones as well I'm unaware off. [FEEDBACK is welcome].

** The ulimit value **
The command 'ulimit -n' shows how many file descriptors (sockets) you may open. Usually this defaults to 1024. You cannot change this unless you are root:
FreeBSD: Run 'sysctl kern.maxfilesperproc=4096' and add this setting to /etc/sysctl.conf. Then re-login and check with 'ulimit -n' if you see the new limit.
Linux: what you probably want is edit /etc/security/limits.conf and add 2 lines like:
username hard nofile 4096
username soft nofile 4096
Where 'username' is your login name (eg: syzop)
Assuming your pam is configured correctly, relogin (yes you have to login again!) and type ulimit -n, it should now show 4096.
If it didn't, then your pam isn't loading the session limit module (or something else), you'll have to add a line like session required pam_limits.so to /etc/pam.d/login, /etc/pam.d/sshd, /etc/pam.d/su, and perhaps some others as well (cron???). But please be careful, since you can lock yourself out if you make a mistake, so be sure to keep 1 terminal logged in etc ;).

*** UnrealIRCd ***
Now you've finished everything, doublecheck that ulimit -n displays the correct value, and then you can specify this value at the MAXCONNECTIONS question (eg: 4096) of ./Config (and then do make.. etc).

Some numbers (recommended specifications for many clients)
You can safely run 2048 - 4096 clients on a GHz machine if it has 2GB - 4GB of memory. Most of the time a lot less memory will be actually used. The extra margin (huge margin) is there so in case of an attack the IRCd won't be crashed due to an out of memory issue. Also, this memory is not only for UnrealIRCd but also for (kernel) socket buffers. We do not recommend 1GB or less for 2048+ clients.

Client counts such as 10000 have been succesfully tested. However in general we rarely see this in use. Again, we recommend to spread the load a bit among multiple servers rather than have 1 big server with (almost) all your clients on it. Multiple servers prevent the Single Point Of Failure problem.

Since irssi 0.8.10 (released on December 11 2005), irssi has support for & and ~ prefixes, +q/+a channel modes, and more ("005 support").

See http://www.irssi.org/

The reason we don't have this feature is because it would give a false sense of security... and having a false sense of security is worse than ""no security"".

Let me explain some ways how you can discover servernames:
- /who
- /whois
- /whowas
- netsplits
- netjoins
- usually, there's a list somewhere online (see later)
- "server unmask"-tricks, /version a*, /version b*, it's fun!
- and more... main thing is: server names were never ment to be 'private information'!

So back to "why is this useful"? Hiding the names of your client servers makes no sense, since.. because they are client servers.. people have to connect to them so they are either listed on the webpage or have some kind of dns round robin..

Now some reasons which DO make sense:
A. You want a "flat map" so the routing information isn't shown (what is linked to what, hopcount, etc), this function exists and is implemented as set::options::flat-map (since 3.2.1).
B. You want to hide your hubs (non-public servers). See Section 8.6 Denial of Service attacks (DoS) [or: how to protect my hub] for a (similar) solution to this.
Both are usually ment to prevent (or rather.. limit the impact of) [D]DoS attacks...

If you have multiple servers and you want your users to automatically spread evenly over several (or all) servers, then you use DNS Round Robin.

DNS Round Robin is a DNS (Domain Name System) feature, basically it means you add multiple "A records" for the same domainname in your nameserver, so instead of:

irc.blah.net A 1.2.3.4

you do:

irc.blah.net A 1.2.3.5
irc.blah.net A 5.23.52.2
irc.blah.net A 74.36.3.36
etc..

Naturally for all this to work, you need to own a domainname, and have access to the nameserver records of your domain (either directly or indirectly via a web interface).

For more information, just google at "dns round robin", there are tons of articles and howto's about it :).

Short answer:
You can't.
The solution is to remove the password from the certificate (see the openssl manual or google).
OR, run UnrealIRCd in GUI mode so you get prompted for the password (note: this is not recommended for "real servers").

Long answer:
If you think of it, it also doesn't make any sense to do so.
Situation: you have the certificate encrypted for security reasons, so that when somebody can get his/her hands on the certificate it will not be broken immediately.
And now you want it so the ircd can boot automatically without providing the passphrase?
The only solution to do that is to store the password somewhere. This password cannot be stored hashed ("unencryptable") since it has to be entered. Hence, it will either have to be stored somewhere as plaintext or fake-encrypted (near-identical to plaintext, just obfuscated).
So how does this help?
It only gives a false sense of security.

UnrealIRCd 4.0 is almost ready for a stable release. We expect 4.0.0 to be available in December 2015. It contains all the new features we have worked on in the past 2+ years.

UnrealIRCd 3.2 will be supported for a while, even after 4.0 is declared stable. Support will most likely consist of security fixes only.

When a client connects to a win32 UnrealIRCd (or another ircd with nospoof) it gets:

*** If you are having problems connecting due to ping timeouts, please type /quote pong 50CF4C86 or /raw pong 50CF4C86 now.

The client then has to PONG back to a random number, this happens automatically for any sane client.

Some people have requested disabling of this message, this is now done as of Unreal3.2.6 by default. If this is what you want, you can stop reading here ;).

Others have requested to disable the entire protection (initial PING/PONG) altogether.
On *NIX this is generally no problem, simply re-run ./Config and choose NO when asked for nospoof support (but feel free to read on, since it can still actually protect you against post proxies).
On Windows, this is generally a BAD idea.

This nospoof protection does two things:

1. On some OS's (mainly Windows NT/2000/XP) it is there to fight IP spoofing. Without it, a user can show up onto your server with almost any IP, including funny things like [email protected]. To be exact: this is because some OS's have an insecure TCP ISN, which makes it easy for hackers to spoof any IP.
2. In general (regardless of the OS), nospoof also protects against other "blind clients". One example of this is HTTP POST proxies. They can't connect succesfully if nospoof is enabled.

So, disabling nospoof on windows is a bad idea since it allows people to spoof IP's. Hence, disabling nospoof is NOT supported on Windows.

If you're on *NIX, and you are using any recent Linux/FreeBSD/OpenBSD/Solaris, it's completely safe to disable nospoof.
Some "obscure" *NIX'es or older versions (like 5+ year old) can still have insecure TCP ISN issues, in such a case nospoof would still be necessary. Again, if you are using any recent *NIX of the "normal" *NIX'es you shouldn't have any problem.

Our policy might change in the future, due to the fact that 2003 seems to have secure ISN's and that in the past few years there have been some (major) enhancements to w2k/XP as well but I have not investigated them yet.