|
|
| UnrealIRCd FAQ |
|
|
| What is the current version and when will next version be released? |
||||||||||||||||||||||||
| The latest Stable version is 3.2.10.1, released on April 5, 2013.
This was a minor update to 3.2.10, released on December 25, 2012. There's no time estimate for a 3.2.11 release |
||||||||||||||||||||||||
| What's new in the latest version? |
||||||||||||||||||||||||
| Have a look at the Release notes of Unreal 3.2.10. Note that 3.2.10.1 was only a minor update to 3.2.10, see the 3.2.10.1 release announcement. |
||||||||||||||||||||||||
| I found a bug or I have feature suggestion |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Begin - I got this .tar.gz thing, what to do with it? how to extract? |
||||||||||||||||||||||||
| If
you don't know how then you SHOULD NOT run this ircd. UnrealIRCd
requires some basic knowledge about networking, IRC and *NIX. |
||||||||||||||||||||||||
| Begin - What's a nameserver? |
||||||||||||||||||||||||
| If
you don't know how then you SHOULD NOT run this ircd. UnrealIRCd
requires some basic knowledge about networking, IRC and *NIX. |
||||||||||||||||||||||||
| Begin - What to do after extracting? How to config? |
||||||||||||||||||||||||
| Have a look at the README file :). |
||||||||||||||||||||||||
| Compiling - configure: error: C++ preprocessor "/lib/cpp" fails sanity check |
||||||||||||||||||||||||
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 checkFix: 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 |
||||||||||||||||||||||||
| Compiling - I ran ./configure and got tons of problems |
||||||||||||||||||||||||
| Do NOT use ./configure! Use ./Config instead. |
||||||||||||||||||||||||
| Compiling - make: *** No targets specified and no makefile found. Stop. |
||||||||||||||||||||||||
| Did you run ./Config? Probably something went wrong when running ./Config, take a look at the output. Maybe you don't have a C compiler or you are compiling on a non-support(-yet) OS. |
||||||||||||||||||||||||
| Compiling - (v)fork: Resource temporarily unavailable |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Compiling - undefined reference to RAND_query_egd_bytes |
||||||||||||||||||||||||
| This
is a problem with your system. the version of your openssl header files
are not the same version as your openssl library files. Probably you
have multiple (mixed) openssl
versions on your system (ex: /usr/lib vs /usr/local/lib, /usr/include
vs /usr/local/include, etc). Try something like this: # locate libssl.so /usr/lib/libssl.so /usr/lib/libssl.so.0 /usr/lib/libssl.so.0.9.6 /usr/lib/libssl.so.0.9.7 # locate opensslv.h /usr/include/openssl/opensslv.h # grep OPENSSL_VERSION /usr/include/openssl/opensslv.h #define OPENSSL_VERSION_NUMBER 0x0090702fL #define OPENSSL_VERSION_TEXT "OpenSSL 0.9.7b 10 Apr 2003" #define OPENSSL_VERSION_PTEXT " part of " OPENSSL_VERSION_TEXT # strings /usr/lib/libcrypto.so|grep 0.9. libcrypto.so.0.9.7 libssl.so.0.9.7 SSLv2 part of OpenSSL 0.9.7b 10 Apr 2003 SSLv3 part of OpenSSL 0.9.7b 10 Apr 2003[in this case the versions matched and there were no multiple header files / conflicting libraries (you can have both 0.9.6 and 0.9.7 libs)] |
||||||||||||||||||||||||
| Compiling - ../include/struct.h:68:23: tre/regex.h: No such file or directory |
||||||||||||||||||||||||
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. |
||||||||||||||||||||||||
| Compiling - Windows: unresolved external symbol .. |
||||||||||||||||||||||||
This can mean multiple things, but if you get 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). |
||||||||||||||||||||||||
| Compiling - set owner/group ..: Operation not permitted |
||||||||||||||||||||||||
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. |
||||||||||||||||||||||||
| Compiling - make: don't know how to make w. Stop |
||||||||||||||||||||||||
| DO NOT use 'gmake', use 'make' instead (as ./Config said when it finished). |
||||||||||||||||||||||||
| Compiling - Windows: I'm unable to compile UnrealIRCd on windows |
||||||||||||||||||||||||
| First of all, be sure to have read doc/compiling_win32.txt to see what you need and how to compile. Also, see below for a list of compiler versions that work and do not work.
|
||||||||||||||||||||||||
| Compiling - FreeBSD: libtool: compile: cannot determine name of library object from `' |
||||||||||||||||||||||||
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 2Then this is a weird FreeBSD problem (rare?). In any case, upgrading the bash package should fix it. |
||||||||||||||||||||||||
| Compiling - FreeBSD: make: permission denied |
||||||||||||||||||||||||
|
The problem On *BSD you sometimes get this error after or during ./Config: make: Permission denied This is due to a bug in FreeBSD (5.x? 6.x?). We have a partial workaround in Unreal but it doesn't catch newer cases where it fails during configuring or building of TRE. If you are experiencing this error, please report them to the FreeBSD devs, as it is not an UnrealIRCd but a FreeBSD bug. It has been reported that compiling as root does not have this issue. WHY? This is a FreeBSD bug, it does not happen on my 5.2.1 and 4.x but it does happen on some 5.5 and 6.x (though others may be affected as well). It happens both in bash and tcsh, making us suspect it's not a shell-specific problem. The problem has also been noted by the eggdrop guys in their FAQ (-dead link removed-). |
||||||||||||||||||||||||
| Booting - Windows - It doesn't start?? nothing happens! |
||||||||||||||||||||||||
| Check service.log (or ircd.log) and fix your errors. |
||||||||||||||||||||||||
| Booting - This application has failed to start because the application configuration is incorrect |
||||||||||||||||||||||||
Some users experience the following error when they try to start UnrealIRCd:This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.It should be noted that, reinstalling the program does not fix the problem. Instead, download and install the Microsoft Visual C++ 2008 Redistributable Package (x86). |
||||||||||||||||||||||||
| Booting - Someone forgot to load modules with proper commands in them |
||||||||||||||||||||||||
| 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"; |
||||||||||||||||||||||||
| Booting - set::<something> missing |
||||||||||||||||||||||||
| You didn't set a required variable in your set block. All variable are explained in detail in the documentation (set block). |
||||||||||||||||||||||||
| Booting - <someblock> { } block missing |
||||||||||||||||||||||||
| Your configfile doesn't contain a required block, please check the documentation which describes every block in detail. |
||||||||||||||||||||||||
| Booting - unknown directive |
||||||||||||||||||||||||
| 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! |
||||||||||||||||||||||||
| Booting - illegal something::class, unknown class 'something' |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Booting - listen with SSL flag enabled on a non SSL compile |
||||||||||||||||||||||||
| You
didn't compile your IRC Server with SSL support but have ssl in your
listen::options block. Either remove the ssl from your listen options
or recompile the server with SSL support (answer Yes to the ./Config
question about SSL). |
||||||||||||||||||||||||
| Booting - link somelink with SSL option enabled on a non-SSL compile |
||||||||||||||||||||||||
| You
didn't compile the ircd with SSL support and have ssl set in your
options block of a link, either recompile with SSL support or remove it
from your link::options block. |
||||||||||||||||||||||||
| Booting - link somelink with ZIP option enabled on a non-ZIP compile |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Booting - The OS enforces a limit on max open files |
||||||||||||||||||||||||
If you get:The OS enforces a limit on max open files Hard Limit: 512 MAXCONNECTIONS: 1024 Fix MAXCONNECTIONSor 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). |
||||||||||||||||||||||||
| Booting - set::cloak-keys: (key 1) Keys should be mixed a-zA-Z0-9 .. |
||||||||||||||||||||||||
| With the new cloaking method that got introduced in 3.2.1 the cloak keys use a new format. You now need to use a string with random lowercase (a-z), uppercase (A-Z) and digit characters. The string should be 5-100 characters long (10-20 is just fine) So for example: set {
cloak-keys {
"a2JO6fh3Q6w4oN3s7";
"Shfid6sfw3gqG8If";
"sdh3iAe2QH7UfdNsh";
};
};
As always, these cloak keys must be the same on all servers on the networks or else bans won't work correctly. |
||||||||||||||||||||||||
| Booting - Error binding stream socket to .. Address already in use |
||||||||||||||||||||||||
| This means another process is listening at this port. Usually it's on of these: - An ircd process is already running - You are on a shell box, you then have to bind to a specific IP in your listen block instead of *. |
||||||||||||||||||||||||
| Booting - It seems to start but the screen goes away / connection refused ?? |
||||||||||||||||||||||||
| Check ircd.log or service.log :). |
||||||||||||||||||||||||
| Booting - I've a self-compiled windows version and it crashes on startup! |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Booting - [error] ERROR: No cloaking module loaded. |
||||||||||||||||||||||||
You need to load a cloaking module.
This was mentioned in the release notes of 3.2.1 (and is also mentioned in example.conf):== [ NEW ]==
- [!] Cloaking has been modulized.
- This means you now MUST load a cloaking module in order to boot.
Example: loadmodule "src/modules/cloak.so";
- 2 cloaking modules are provided: 'cloak' and 'oldcloak':
- 'cloak' is the new, RECOMMENDED, and much more secure cloaking algorithm that uses
md5 internally. It requires 3 keys of 5-100 characters (10-20 is fine) consisting
of mixed lowcase (a-z), upcase (A-Z) and digits (0-9). So for example:
set { cloak-keys { "AHsHS6ds2sQGAkish"; "qF5D3orm6Evba26hjf"; "f6oaO2hhd6sIHSfs"; };
- 'oldcloak' is the <=3.2 cloaking algorithm, it is ONLY ment for use during the
upgrade process (it will give a warning if you use it), you should switch to the
much more secure 'cloak' module as soon as all your servers are upgraded.
- 3rd party cloak modules are also possible. |
||||||||||||||||||||||||
| Booting - failed to load: src/modules/commands.so |
||||||||||||||||||||||||
| 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). |
||||||||||||||||||||||||
| Booting - Unexpected EOF for section starting on line NNN |
||||||||||||||||||||||||
If you get a message ike:
[error] unrealircd.conf: Unexpected EOF for section starting on line 123Then 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!";
}
OR:
admin {
"blablabla";
};
"blah!";
OR:
admin {
"blablabla"
"blah!"
};
etc... |
||||||||||||||||||||||||
| Booting - * unrealircd.conf:xx: loadmodule src/modules/commands.so: [..] undefined symbol: [..] |
||||||||||||||||||||||||
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). |
||||||||||||||||||||||||
| Linking - Users on my Windows server are getting killed by other servers very soon after linking |
||||||||||||||||||||||||
| 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! |
||||||||||||||||||||||||
| Linking - Trouble with linking two servers |
||||||||||||||||||||||||
| 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; |
||||||||||||||||||||||||
| Linking - Connection reset by peer directly after connecting |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Linking - Connecting to blabla and then nothing? |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Linking - Colliding server numeric |
||||||||||||||||||||||||
| 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). |
||||||||||||||||||||||||
| Linking - Link blah is having a different cloak key |
||||||||||||||||||||||||
| 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). |
||||||||||||||||||||||||
| Linking - (sync) Possible negative TS split at link server.blah.net (1078875430 - 1078875478 = -48) |
||||||||||||||||||||||||
| 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 few: - 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.. Synch the server clock - *NIX 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. Synch the server clock - Windows There are various time synching progs out there (just google), but newer windows versions (XP, 2003) should already do it automatically. UnrealIRCD's built-in timesynch UnrealIRCd has built-in time synchronization (enabled by default) which synchronizes the clock when UnrealIRCd is started. This can be used as a fallback where you cannot implement any of the other solutions. It's not 100% perfect because it does not handle 'clock drift' which many computers have: the clock will drift a few seconds off per hour or per day, gradually causing it to be more and more inaccurate. About time zones Note that linking ircds from different timezones is NO PROBLEM because GMT/UTC time is used for everything. |
||||||||||||||||||||||||
| Linking - connect: Invalid argument |
||||||||||||||||||||||||
| If
you get an "invalid argument" error when trying to connect (either via
/connect or autoconnect) then you could be experiencing an
odd-unreal-behavior-issue. Fix: specify the IP to bind to in bind-ip inside your link block (eg: "1.2.3.4" instead of "*"), use the IP of the box itself here [not the one to connect to!] ;). Another way to fix: reorder your listen lines (eg: move the top one to the bottom, etc) and restart the ircd, see if that helps. |
||||||||||||||||||||||||
| Connecting - Unable to resolve server |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Connecting - I can't connect / connect timed out / .. |
||||||||||||||||||||||||
| 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). |
||||||||||||||||||||||||
| Connecting - I'm trying to run my ircd from my cable/*dsl connection but outside users can't connect!! |
||||||||||||||||||||||||
| First
of all, always try connecting with the IP first, so instead of '/server
irc.blah.com' try '/server 1.2.3.4' where 1.2.3.4 is your internet IP
(the one of the IRC server). If that didn't work, and you verified the ircd is running (eg: task manager on windows, or 'ps x' on *NIX), then most likely you have: 1. A router in between or 2. A firewall If you have a router you need to forward 1 or more ports to your IRC server, usually port 6667. To find out how to do that, consult your router documentation; Unreal support is not Router support! For a firewall, you will need to allow the IRC ports in (usually 6667). Consult your firewall documentation on how to do it. |
||||||||||||||||||||||||
| Running - Helpop doesn't work |
||||||||||||||||||||||||
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". |
||||||||||||||||||||||||
| Running - ircop - I can't op myself / I can't join a +k/+i/etc channel! |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Running - I've k/g-lined myself!!! |
||||||||||||||||||||||||
| *sigh*
One possible solution to get in again: except tkl { mask *@1.2.3.4; type { gline; gzline; shun; }; };
except ban { mask 1.2.3.4; };
And then run './unreal rehash'.
These exception blocks will make you immune from: glines, klines,
gzlines and shuns. At the time of writing (unreal3.2.2) there was no
exception for 'zline' yet.NOTE: There's no way to remove *lines from the shell, in case you wondered ;). |
||||||||||||||||||||||||
| Running - /helpop doesn't work |
||||||||||||||||||||||||
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... |
||||||||||||||||||||||||
| Running - I can't /oper myself |
||||||||||||||||||||||||
| *
First of all are you listed in '/stats o'? If not then there's some
problem with your oper block. Oh and don't forget to /rehash of course
;) * Try first with oper::from::userhost set to *@* and after you succeeded in /oper'ing up you can set it more strict if you want. * you must oper up by typing: '/oper username password'. both username and password are case sensitive! |
||||||||||||||||||||||||
| Running - I want to broadcast a GLOBAL message, how? |
||||||||||||||||||||||||
| You could use:
/notice $*.yournet.com Hi this is a message blabla but this requires all of your servernames to end in yournet.com. If you have services, you usually use operserv for this, like: /os global Hi this is a message |
||||||||||||||||||||||||
| Running - If I type /list (even as ircop) it hides certain channels |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Running - Warning! Possible desynch: SJOIN for channel .. has a fishy timestamp (XX) |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Running - I (suddenly) got clients quiting with Max SendQ exceeded! |
||||||||||||||||||||||||
| SHORT ANSWER: Increase your class::sendq
LONG ANSWER: |
||||||||||||||||||||||||
| Running - hostnames are not resolving |
||||||||||||||||||||||||
| 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.4In 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 5the Rp 0 means it received 0 replies, clearly a problem here. |
||||||||||||||||||||||||
| Running - I'm getting tired of spam/advertising/worms etc! |
||||||||||||||||||||||||
| 3.2-RC1 contains "spamfilter", an effective tool for fighting spam. Read more about it in the docs. |
||||||||||||||||||||||||
| Running - Exiting ssl client [..] Internal OpenSSL error or protocol error |
||||||||||||||||||||||||
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). |
||||||||||||||||||||||||
| Running - I don't get an oper/admin/.. host when I oper up! |
||||||||||||||||||||||||
| You need to have set::hosts::host-on-oper-up 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. |
||||||||||||||||||||||||
| Running - I've added an operflag but it doesn't seem to work! |
||||||||||||||||||||||||
| 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 |
||||||||||||||||||||||||
| Running - Temporary *lines/shuns are removed too early/too late on different servers!! (*line desynch) |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Running - All my users disappeared in the channel / some users cannot see everyone!!? |
||||||||||||||||||||||||
| Most
likely you (accidently) set channelmode +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 ment for celebrity alike chat systems, read-only
news/announcements channels, and things like that.
|
||||||||||||||||||||||||
| Running - WARNING: (g)zlines should be placed on user@IPMASK, not user@hostmask |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Running - I want to disable host cloaking (hosts like: Gll-20409F99.arcor-ip.net) |
||||||||||||||||||||||||
| 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 moduleWhile 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). There used to be 3rd party module called 'nocloak' which does this. |
||||||||||||||||||||||||
| Running - Self-compiled windows version crashes on-join, on-link, or whatever.. |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Running - IPv6: How to make the IRCd listen on IPv4 addresses? |
||||||||||||||||||||||||
| Starting with Unreal3.2.8 the ::ffff:1.2.3.4 stuff of below is no longer needed and you can just use 1.2.3.4 like IP's! If you're using a IPv6 build, and cannot get it to listen on IPv4, then be sure to read next FAQ item. |
||||||||||||||||||||||||
| Running - IPv6: I have compiled with IPv6, but can't get it to listen at IPv4 addresses |
||||||||||||||||||||||||
| Situation If you 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. You MIGHT (but don't have to!) even get an error like: Error binding stream socket to IP [..] Invalid argument(..which can also be caused by completely different issues..) Solution This is split in *BSD and Linux... *BSD 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. Linux: Debian, Ubuntu Change sysctl net.ipv6.bindv6only to 0. You can do this by adding net.ipv6.bindv6only=0 to your /etc/sysctl.conf and reboot, and/or executing "sysctl -w net.ipv6.bindv6only=0" as root. More information We are working on a fix for this, in CVS, so in the future you don't have to tweak this sysctl setting. |
||||||||||||||||||||||||
| Services - Where is nickserv? chanserv? |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Services - Why doesnt unreal come with services? |
||||||||||||||||||||||||
| 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". |
||||||||||||||||||||||||
| Services - Where do I get them? Which do you recommend? |
||||||||||||||||||||||||
| Again, you should decide yourself which services you want.
To give you some links: |
||||||||||||||||||||||||
| Services - /cs or /chanserv say: Services are currently down. Please try again later. |
||||||||||||||||||||||||
Your set::services-server should point to your services server. For example:
set {
services-server "services.mynet.net";
}; |
||||||||||||||||||||||||
| Services - /cs or /chanserv say: Unknown command |
||||||||||||||||||||||||
| 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: |
||||||||||||||||||||||||
| Services - NickServ/ChanServ don't op me or say I'm not a registered nick all the time |
||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||
| Services - Hey I need help with services, can I ask in #unreal-support? |
||||||||||||||||||||||||
| 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! |
||||||||||||||||||||||||
| Other - My server crashed!! |
||||||||||||||||||||||||
| If your server crashed and you are running the latest 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). |
||||||||||||||||||||||||
| Other - My server crashed when sending an incorrect raw command from another server (eg: services) |
||||||||||||||||||||||||
| 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 will 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, and we DO NOT INTEND TO. 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 Such ways to crash UnrealIRCd will not be fixed, instead 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 (in fact, the situation is exactly the same). This philosophy is not unique to Unreal. Update 2007-01-22: While I've considered rethinking this position, my conclusion - certainly for now with scarce resources - is that we should dedicate developer resources on other things, and stick with our current position. |
||||||||||||||||||||||||
| Other - Invisibility (usermode +I) doesn't work |
||||||||||||||||||||||||
| Invisibility (usermode +I) was removed over 5 years ago (beta15). There are two reasons for this: 1. Technical: it was a total mess. You have to deal with invisibility in: join, part, names, who, whois, invite, kick, etc. It made the source really ugly. Also as a consequence of this, the code was buggy so spying could easily be detected 2. Ethics: it's unethical to use +I, this also gave Unreal a bad reputation NOTE: Any discussion on our forum/IRC channel/etc about spying will cause you (or your message) to be removed immediately. |
||||||||||||||||||||||||
| Other - How do I get the latest development version? (CVS/HG/Mercurial) |
||||||||||||||||||||||||
We use mercurial (hg), you can check out the latest development version of UnrealIRCd by:hg clone http://hg.unrealircd.org/unrealIf you get something like 'hg: command not found' then you need to install mercurial, usually the package is called 'mercurial'. If you don't have such a package, or you are on Windows or Mac OS X, then go to the mercurial site. Alternatively, you can download the daily generated .tar.gz's from here. Windows users can download development builds here (binary versions with installer etc). Or take a look at my main UnrealIRCd page here. |
||||||||||||||||||||||||
| Other - I would like a symbol/prefix for +q/+a like ./*/^/etc (or: how to get rid of the &/~ prefixes) |
||||||||||||||||||||||||
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 It is NOT possible to use any other symbol than & and ~, if you try it anyway you'll loose support and break other things. Also support questions on this will result in an immediate ban/topic delete/etc. |
||||||||||||||||||||||||
| Other - why is running an old UnrealIRCd version bad? |
||||||||||||||||||||||||
| In
UnrealIRCd (just like in any other software package) bugs are
discovered all the time which are then fixed in the new version. Now we
see people happily running beta14 or 3.1.3, but you should understand
that these bugs also include ones which enable any user to crash the server or even worse bugs which enable you to become an ircop or execution of code. So even while you were running a particular version for 2 years, you NEED to upgrade.. It's not 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... |
||||||||||||||||||||||||
| Other - Why is modifying the source not supported? |
||||||||||||||||||||||||
| 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. 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 watch television 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 (modifications done by someone of the team), in that
case the person that did the modifications will help you if you have
any crashes/weird bugs. |
||||||||||||||||||||||||
| Other - I want my ircd to hold over 1024 connections! |
||||||||||||||||||||||||
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) and it's not easy so it might be better to do just like most people do: run multiple servers.
** The global maximum ** ** The ulimit value **
** The header files **
*** UnrealIRCd *** *** Test results ***
Windows |
||||||||||||||||||||||||
| Other - irssi and prefixes (&/~) |
||||||||||||||||||||||||
| 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/ |
||||||||||||||||||||||||
| Other - I would like to restrict /map and /links |
||||||||||||||||||||||||
| 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... |
||||||||||||||||||||||||
| Other - How do I make my users spread evenly over multiple servers? |
||||||||||||||||||||||||
| 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.4you 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 :). |
||||||||||||||||||||||||
| Other - how can I use an encrypted certificate when running the ircd as a service under windows? |
||||||||||||||||||||||||
| 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:
|
||||||||||||||||||||||||
| Other - What's the current status on development of UnrealIRCd 3.2/3.3/3.4/4.0? |
||||||||||||||||||||||||
| See the forum post: Future development - Unreal3.2 & Unreal3.4.
|
||||||||||||||||||||||||
| Other - I want to get rid of this annoying connect message on windows / get rid of nospoof |
||||||||||||||||||||||||
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:
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. |
Generated with a modified version of phpFAQ.