 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
    |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Unreal Downloads Home>UnrealIRCd Doc's
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
UnrealIRCd
Head Coders: Stskeeps / Codemastr Due to the increasing complexity of UnrealIRCd3.2 We have switched to a easier to navigate, more inclusive documentation set. To view this documentation you must have a compatible browser, which are listed below. Compatible Browsers: INDEX / TABLE OF CONTENTS This document was written for exclusively for use with UnrealIRCd. Use of this document with another software package, or distribution of this document with another software package is strictly prohibited with out the written permission of the UnrealIRCd Development Team. This document may be copied/printed/reproduced/published as many times as you like, providing it is for use with UnrealIRCd and is not modified in anyway. – Copyright UnrealIRCd Development Team 2002 1.1 – Notes on new documentation This document is the first try at an official COMPLETE Unreal3.2 Document. It is still a work in progress. I rushed a bit to get it ready for the beta12 release. I will be adding a lot more detail & examples as time goes on. If you have any feedback, comments, suggestions, please feel free to contact me with them, and I will do my best to work them in. My goal is to make Unreal3.2 and its powerful features, easier to setup, and easier to use. Email: docs@unrealircd.com 1.2 – Notes on current release I M P O R T A N T R E A D I N G (YES, YOU WILL NEED TO READ ALL OF THIS) * Unreal3.2-Selene is a lot different than Unreal3.1.1. Forget all you have learned about setting up Unreal3.1.1 - this is a lot different. We have got a new configuration format that integrates all the former config files,ircd.conf, vhost.conf, chrestrict.conf, unrealircd.conf, into to one newunrealircd.conf (what the ircd.conf is called now). See doc/ for more information on the configuration format * THIS IS A BETA VERSION, REPORT BUGS ON http://bugs.unrealircd.org * We have introduced a new cloaking algorithm (+x), which makes it incompatible with Unreal3.1.1 - these can however still link, but the hostname will look different. This is made of three big numbers, configured in the config file - and these MUST be the same on all servers on the network. Keep these numbers secret, and the cloaking algorithm is uncrackable (within 55 years, that is). The +x algorithm was changed slightly to fix a method of cracking that was found. #define COMPAT_BETA4_KEYS to use the beta4 system for compatibility with older betas. * If you use Linux and have problems where the IRCd complains that MAXCONNECTIONS is larger than FD_SETSIZE, you need to get your root to edit /usr/include/bits/types.h - #define __FD_SETSIZE 1024 to be somenumber that is equal or higher than MAXCONNECTIONS. This is a problem with Linux that it is hard coded and non override able in some distributions. We recommend you use FreeBSD or the variants of this if you need to run high load IRC servers. * We use autoconf to help with compilation, and this should make us able to a lot more platform (we have even ported to BeOS). * We require a pthreads library for the SOCKS scan now - and this is now done in the background (no more waiting!). * The IRCd is now modularized, and you load modules with the
loadmodule command. You will most likely want to add these lines: If you would like to code a module, doc/ will contain a module guide,and we got an example module in src/modules/m_dummy.c. * We have some IPv6 support, and there are some minor bugs in it. * The documentation is NOT yet 100% complete * We have added snomask (similar to ircu), basically this allowed us to remove several modes. Modes +cfFkje are gone, but don't worry, you can still use them. They are now added like this: /mode yournick +s +cF You set the flags in the second parameter of the mode command for a mode change +s, setting -s with no parameters removes all your snomask. You can remove a specific snomask by doing: /mode yournick -s -c The current snomasks are: c - local connects It shouldn't be too hard to figure out, just play around with it a bit :) * /who needs testing it was recorded and may contain bugs * We have added alias {} which allows you to dynamically create commands such as /nickserv Read example.conf for more information on how to create your own. To use standard ones include one of the following files aliases/ircservices.conf (IRCServices,
Daylight) * You can now use an IP in the oper::from and vhost::from fields even if the host resolves * Added an http proxy scanner (scan_http.so) * Added oper::snomask to specify default oper snomask modes * /helpop text has been moved to a config directive, help {}. To keep the standard help text you need to include help.conf so add include "help.conf"; to your config file. * To be able to use G:lines you must now have the can_gkline flag (or t if old style flags) * Usermode +T (Tech Admin) has been removed, since it is 100% useless * Added a make install to copy files to the installation location * Removed ./ircd, ./killircd, crypt/mkpasswd, ./rehash and merged them into a new ./unreal [start|stop|rehash|mkpasswd] for mkpasswd the format is ./unreal mkpasswd [method] [password] * Added a new system for crypting passwords. You now do for example password "my password" { crypt; }; This allows you to have some crypted passwords and others not. If you have SSL enabled you may also use the md5 and sha1 methods. * The old blackhole is now set::scan::endpoint and specifies an IP and port to tell proxies to connect to. * You can now specify a cipher list for SSL links (read doc/conf.doc for more info) * +I is now in invisibility.so so it is easily disabled * set::socks has been replaced by set::scan (read doc/conf.doc for more info) * If you experience problems with the scanners, perhaps check out BOPM (http://www.blitzed.org/bopm) * log {} syslog support added (read doc/conf.doc for more info) * Added ripemd-160 password encryption support * Enabled sha1 and md5 password encryption on Win32 regardless of whether SSL is used. * Added WinNT/2k/XP service support (experimental) To use this
you use the unreal.exe utility: unreal install -installs the service Config errors and crashes are now logged to service.log when in service mode. * Implemented a new win32 debugger to make fixing bugs much easier. * Added a win32 installer to simplify installing under Windows. * AKILL/RAKILL is deprecated. Server command still works but will be removed eventually (aliases to TKL G). For normal opers it notices that the commands are deprecated. Made the config parser smarter when it comes to time values and size values. Entries are no longer limited to 1d2h1m. You can now enter "1day 2 hours 1 minute" for example. See doc/conf.doc for more information. * The oper override code has been rewritten to be less intrusive. You can now no longer automatically join a channel for which you must override a mode. You must /invite yourself to the channel. The idea behind this is it prevents the accidental "rejoin on kick" ban override and joining a +s channel without realizing it is +s and therefore you shouldn't know it exists. * If you use the SSL features of Unreal, you should use OpenSSL 0.9.6e or later. This is important as the older versions may make the program exploitable. See http://www.openssl.org for more information * We have made a lot of changes to deal with SSL, and if you find any flaws or problems, please contact the coder team. We however think that the changes will make SSL more transparent and make it work more efficiently. * Added technical documentation in doc/technical. This directory will contain information about the protocol used by Unreal. * Added EGD support for SSL. EGD allows entropy to be gathered on systems that do not have a random device (/dev/random or /dev/urandom) or have an unreliable random device. Unreal has been tested using EGADS (http://www.securesoftware.com/egads.php) [With EGD support enabled], PRNGD (http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html), and EGD (http://egd.sourceforge.net). Other EGD compatible programs should work as well. * We have created a new complete set of docs!
doc/unreal32docs.html is now a complete * We have removed ./Setup - Please read the new docs for
information on configuring & * MAKE SURE YOU RERUN ./Config AND RUN make clean BEFORE USING THIS VERSION!!! Unreal 3.2 is ONLY compatible with Unreal3.1.4 and Unreal3.2 servers. DO NOT ATTEMPT to link to servers that it is NOT compatible with. 2.0 - Installation Installation Instructions 3.0 - Configuring your unrealircd.conf 3.1 Configuration File Explained This section will help explain the way the new unrealircd.conf works. It is A LOT different than any ircd.conf you have seen in the past! This file as a C based structure, and is a bit scary when you first look at it. But as you learn it, and start to understand it, it is acutely much easier to use. The new system uses a block-based system. Each entry, or block, in the new format has a specific format. The format works like: <block-name> <block-value> { <block-name> is the type of block, such as me, or admin. <block-value> sometimes specifies a value, such as /oper login, but other times it will be a sub-type such as in ban user. <block-directive> is an individual variable specific to the block, and <directive-value> is the Associated value. Directives and their values do not have to be separated by an equal sign, but they maybe if you choose to do so. If <directive-value> contains spaces, or characters that represents a comment it must be contained in double quotes. If you want to use a quote character inside a quoted string use \" and it will be understood as a quote character. A <block-directive> can have directives within it, if that’s the case it will have it's own set of curly braces surrounding it. Some blocks do not have directives and are specified just by <block-value>, such as include. Also note that there is no set format, meaning the whole block can appear on one line or over multiple lines. The format above is what is normally used (and what will be used in this file) because it is easy to read. Note: the configuration file is currently case sensitive so BLOCK-NAME is not the same as block-name. There is a special notation used to talk about entries in the config file. For example, to talk about <directive-name> in the example above, you'd say <block-name>::<block-directive>, and if that directive has a sub block you want to reverence, you would add another :: and the name of the sub directive. To talk about an unnamed directive you would do <block-name>:: which would in this case mean <block-value>, or it could be an entry in a sub block that has no name. Comments are supported in three formats, both multi-line and single-line comments are supported. To comment a single line there are two options, a shell style comment, or a C++ style comment. A shell style comment begins with a # and a C++ style begins with a //. These comments can appear anywhere in a line and comment anything until the end of the line. For multi-line comments, a C style comment is supported. To start the comment you enter /* and anything from there until the */ is commented. Examples of comments that are ignored: #Comment type 1 (Shell type) 3.2 - Me Block (Previously known as the
M:Line) Syntax: These values are pretty obvious. The me::name specifies the name of the server, me::info specifies the server's info line, me::numeric specifies a numeric to identify the server. This must be a value between 1 and 255 that is unique to the server meaning no other servers on the network may have the same numeric. Example: 3.3 - Admin Block (Previously known as the
A:Line) Syntax: The admin block defines the text displayed in a /admin request. You can specify as many lines as you want and you they can contain whatever information you choose, but it is standard to include the admin's nickname and email address at a minimum. Other information may include any other contact information you wish to give. Example: 3.4 - Class Block (Previously known as the
Y:Line) Syntax: The class block is a vastly simplified version of the Y:line. You are no longer limited to naming them with a number, you can now use an alpha-numeric string which is specified in the class::. The values of this block define the connection classes, class::pingfreq specifies the number of seconds between PINGs, class::connfreq is only used in server classes to specify the time in seconds between connection attempts, class::maxclients specifies the maximum amount of clients that may use this class to connect, and class::sendq specifies the amount of information that can remain in the send queue buffer. Examples: class servers{ 3.5 - Allow Block (Previously known as the
I:Line) Syntax: The allow class is similar to an I:line but provides more features. The allow::ip specifies a user@ip hostmask for a user to match to connect and allow::hostname specifies a user@host to match to connect, allow::class is the name of a preexisting (must appear before this) class block that will be used for this class. The rest of the directives are optional, allow::password specifies a password that users must enter to connect. The allow::password:: allows you to specify an authentication method. Currently supported methods are crypt, md3, and sha1, ripemd-160. If you are using plain-text you can just leave this sub-block out. This directive also allows you to configure clone killing, allow::maxperip lets you specify the maximum number of clients that may connect from a single IP. Lastly, the allow block supports redirection when the server is full, allow::redirect-server specifies the address of a server to forward to, and allow::redirect-port specifies the port, if no port is specified, 6667 is assumed. Note: for auto-redirection to occur the client must have support for the redirection numeric, at this time not many clients do. Examples: allow {
3.6 - Listen Block (Previously known as the
P:Line) Syntax: This block allows you to specify the ports on which the IRCD will listen. If no options are required, you may specify this without any directives in the form listen <ip:port>;. Valid listen::options are clientsonly (only users may connect), serversonly (only servers nameconnect), java (CR javachat support), ssl (SSL encrypted port). A combination of any of those flags may be specified. Since IPv6 is now supported, and the IPv6 seperator is a : it makes
the Examples: listen *:6601 { Or if there are no options: listen *:8067; 3.7 - Oper Block (Previously known as the
O:Line) oper <name> { The oper block allows you to assign IRC Operators for your server. The oper:: specifies the login name for the /oper. The oper::from::userhost is a user@host mask that the user must match, you can specify more than one hostmask by creating more than one oper::from::userhost. The oper::password is the password the user must specify, oper::password:: allows you to specify an authentication method for this password, valid auth-types are crypt, md5, and sha1, ripemd-160. If you want to use a plain-text password leave this sub-block out. The oper::class directive specifies the name of a preexisting (appears before this in the config file) class name that the oper block will use. The oper::flags directive has two formats. If you wish to use the old style oper flags i.e., OAa, you use the flags <flags> method, if you want to use the new style,i.e., services-admin, then you use the flags { <flag>; } method. Below is a list of all the flags (in both formats) and what they do.
Certin flags give you other flags by default:
The oper::swhois directive allows you to add an extra line to an opers whois information. The oper::snomask directive allows you to preset an opers service notice mask
on oper up.
Example: 3.8 - DRpass Block (Previously known as the
X:Line) Syntax: This block sets the /restart and /die passwords with drpass::restart and drpass::die respectively. The drpass::restart:: and drpass::die:: allow you to specify the type of authentication used by this item. The currently supported authentication types are crypt, md5, and sha1, ripemd-160. Example: drpass { Syntax: This directive specifies a filename to be loaded as a separate configuration file. This file may contain any type of config block and can even include other files. Wildcards are supported in the file name to allow you to load multiple files at once. Example: That would be the statement to use if you wanted to use a separate network file. Separate network files are no longer required; all the network settings can be inserted directly into the unrealircd.conf. Or you can put an include statement them to load the file. Syntax: This directive specifies a filename to be loaded as a module. Some modules may have there own documentation which should be consulted when setting it up. Loadmodule also supports wildcards to easily load multiple modules at once. Modules that come standard with Unreal3.2: scan_http.so - HTTP proxy scanner module Example: Syntax: The log block allows you to assign different log files for different purposes. The log:: contains the name of the log file. log::maxsize is an optional directive that allows you to specify a size that the log file will be wiped and restarted. You can enter this string using MB for megabytes, KB, for kilobytes, GB, for gigabytes. The log::flags specifies which types of information will be in this log. You can specify one or more of the following, errors, kills, tkl (G:lines and Shuns), connects, server-connects, kline, and oper. You may also have multiple log blocks, to log different things to different log files. Available Flags: errors self explanatory Example: log ircd.log { 3.12 – TLD Block (Previously known as the
T:Line) Syntax: The tld block allows you to specify a motd, rules, and channel for a user based on their host. This is useful if you want different motds for different languages. The tld::mask is a user@host mask that the user's username and hostname must match. The tld::motd and tld::rules specify the motd and rules file, respectively, to be displayed to this hostmask. Lastly the tld::channel is optional, it allows you to specify a channel that this user will be forced to join on connect. If this exists it will override the default auto join channel. Example: 3.13 – Ban Nick Block (Previously known as the
Q:Line) Syntax: The ban nick block allows you to disable use of a nickname on the server. The ban::mask allows wildcard masks to match multiple nicks, and ban::reason allows you to specify the reason for which this ban is placed. Most commonly these blocks are used to ban usage of the nicknames commonly used for network services. Example 3.14 – Ban User Block (Previously known as the
K:Line) Syntax: This block allows you to ban a user@host mask from connecting to the server. The ban::mask is a wildcard string of a user@host to ban, and ban::reason is the reason for a ban being placed. Note, this is only a local ban and therefore the user may connect to other servers on the network. Example 3.15 – Ban IP Block (Previously known as the
Z:Line) Syntax: The ban ip block bans an IP from accessing the server. This includes both users and servers attempting to link. The ban::mask parameter is an IP which may contain wildcard characters, and ban::reason is the reason why this ban is being placed. Since this ban affects servers it should be used very carefully. Example 3.16 – Ban Server Block (Previously known as the
q:Line) Syntax: This block disables a server's ability to connect to your server. The ban::mask field specifies a wildcard mask to match against the server attempting to connect's name, and ban::reason specifies the reason for which this ban has been placed. Example 3.17 – Ban RealName Block (Previously known as the
n:Line) Syntax: The ban realname block allows you to ban a client based on the GECOS (realname) field. This is useful to stop clone floods because often clone bots use the same realname. The ban::mask specifies the realname which should be banned. The mask may contain wildcards. The ban::reason specifies the reason why this ban is being placed. Example 3.18 – Ban Exceptions Block (Previously known as the E:Line) Syntax: The except ban block allows you to specify a user@host that will override a ban placed on a broader host. This is useful when you want an ISP banned, but still want specific users to be able to connect. The except::mask directive specifies the user@host mask of the client who will be allowed to connect. Example 3.19 – Scan Exception Block (Previously known as the
e:Line) Syntax: The except scan block allows you to specify an IP mask that will override the scanners. This only works if you have chosen to load the scanner modules. The except::mask specifies an IP mask that will not be banned because of any type of scanner problem. Example 3.20 – Deny DCC Block (Previously known as the
dccdeny.conf) Syntax: The deny dcc block allows you to specify a filename which will not be allowed to be sent via DCC over the server. This is very useful in helping stop distribution of trojans and viruses. The deny::filename parameter specifies a wildcard mask of the filename to reject sends of, and deny::reason specifies the reason why this file is blocked. Example 3.21 – Deny Version Block (Previously known as the
V:Line) Syntax: This block allows you to deny a server from linking based on the version of Unreal it is running and what compile time options it has. The format for this block is somewhat complex but isn't too hard to figure out. The deny::mask directive specifies a wildcard mask of the server name this applies to. The deny::version specifies the protocol number of the version this refers to. For example, 3.0 is 2301, 3.1.1/3.1.2 is 2302, 3.2 is 2303. The first character of this parameter can be one of the following >, <, =, !. This character tells the IRCd how to interpret the version. If the first character is a > then all version greater than the specified version are denied, if it is a < all versions lower are denied, if it is an = only that version is denied, and if it is a ! then all versions except the specified are denied. The deny::flags directive allows you to specify what compile time flags the server may or may not have. The flags are arranged one after the other with no separation between, if a character is prefixed by a ! then it means the server may not have this flag compiled into it, if it does not have a ! prefix, then it means the server must have this flag compiled. 3.22 – Deny Link Block (Previously known as the
D/d:Line) Syntax: This block allows you to use specific rules to deny a server from linking. The deny::mask specifies a wildcard mask of the server name to apply this rule to. The deny::rule directive is very complex. A crule expression allows you to control the link in great detail, and it is set up like a programming expression. Four operators are supported, connected(<servermask>), returns true if a server matching servermask is connected, directcon(<servermask>), returns true if the server matching servermask is directly connected to this server, via(<viamask>,<servermask>), returns true if a server matching servermask is connected by a server matching viamask, and directop(), which returns true if the operator issuing a /connect is directly connected to this server. These operators can be combined using && (and) and || (or), items may also be enclosed in parenthesis to allow grouping. In addition, an operator preceded with a ! checks if the operator returned false. If the entire expression evaluates to true, then the link is denied. The deny::type allows two different values, auto (only applies to autoconnects, /connect will still work), and all (applies to all connection attempts). 3.23 – Deny Channel Block (Previously known as the
chrestrict.conf) Syntax: The deny channel block allows you to disallow users from joining specific channels. The deny::channel directive specifies a wildcard mask of channels the users may not join, and the deny::reason specifies the reason why the channel may not be joined. Example deny channel { Syntax: The allow channel block allows you to specify specific channels that users may join. The allow::channel directive specifies the wildcard mask of the channels which may be joined. Example 3.25 – Vhost Block (Previously Known As
vhosts.conf) Syntax: The vhost block allows you to specify a login/password that can be used with the /vhost command to obtain a fake hostname. The vhost::vhost parameter can be either a user@host or just a host that the user will receive upon successful /vhost. The vhost::from::userhost contains a user@host that the user must match to be eligible for the vhost. You may specify more than one hostmask. The vhost::login in the login name the user must enter and vhost::password is the password that must be entered. Lastly vhost::password:: allows you to specify the type of authentication used by this item. The currently supported authentication types are crypt, md5, and sha1, ripemd-160. Example 3.26 – Bad Words Block (Previously Known As
badwords.*.conf) Syntax: The badword block allows you to manipulate the list used for user and channel mode +G to strip "badwords". The badword:: specifies the type, valid types are channel and messages, channel is for the channel +G list, and message is for the user +G list. The badword::word is a regular expression of the word we should search for and remove. The badword::replace is what we should replace this match with. If badword::replace is left out, the word is replaced with <censored>. Example 3.27 – ULines Block (Previously Known As
U:Line) Syntax: The ulines block lets you define certain servers as having extra abilities. This should only be used for servers such as services and stats. This should not be set for a normal server. Each entry is the name of the server which will receive the extra abilities. Example 3.28 – Link Block (Previously Known As
C/N/H:Lines) Syntax: The link block is a simplified way to link servers. The link:: should be the name of the server which is to be linked, link::username is a wildcard mask of the username the server must have, and link::hostname is an IP mask the server must match. If you are running with IPv6 enabled and you want to link to an IPv4 server, specify the hostname in the format ::ffff:<ip>, example ::ffff:203.123.67.1. The link::bind-ip specifies an IP that the server will bind to in order to make this connection and link::port specifies the port it will establish the connection on. The link::password-connect must be a plain-text password since it will be sent to the other server, but link::password-receive may be encrypted using a method specified in link::password-receive:: valid methods are crypt, md5, and sha1, ripemd-160. You can leave the auth-type parameter out to have it remain plain-text. The link::hub and link::leaf directives may not be used together, either a server is a hub or a leaf. If link::hub is specified, the value is a mask of what servers this hub may connect. If link::leaf is specified the value specifies the mask that this server will act like a leaf towards. The link::leafdepth directive should only be specified if link::leaf exists and is also optional. This value specifies the depth (number of hops) this server may have beneath it. The link::class is the name of a preexisting (appears before this in the config) class block that will be used for the server connecting with the link block. The link::options is a list of one or more options you wish this server to use, valid options are ssl (the server will connect using SSL encryption), autoconnect (the server will be autoconnected based on the value in the specified link::class), quarantine (opers on this server will maintain locop status). Example link hub.mynet.com { Syntax [standard alias]: The alias block [standard alias] allows you to forward a command to a user, for example /chanserv sends a message to the user chanserv. The alias:: specifies the name of the command that will be the alias, ex /chanserv, alias::nick is the nickname it will forward to, if the alias:: is the same as the nick it will forward to, alias::nick can be left out. The alias::type specifies the type of alias, valid types are services (the user is on the services server), stats (the user is on the stats server), and normal (the user is a normal user on any server). The alias block also has another purpose which is explained below. Syntax [command alias]: When the alias block is used in this format, it allows you a much broader range of usage. For example you can create aliases such as /identify. The alias:: is the same as above, the name of the alias command. The alias::format specifies a regular expression that compares against the text sent to the alias command, when matched the sub-entries of that alias::format will be used, you may have multiple alias::format's to make the command do different things depending on the text sent to it. The alias::format::alias is the name of a preexisting (appears before this in the config file) alias block in the standard format that when that format is matched will be used. The alias::format::parameters is what will be sent as the parameters to this alias. To specify one of the parameters given to the command alias specify % followed by a number, for example, %1 is the first parameter. To specify all parameters from a given parameter to the end do % followed by the number and a -, for example %2- returns all parameters from the second till the last. For examples of using the alias block in the command format, consult doc/example.conf. Syntax: The help block allows you to create entries for use in /helpop. The help:: is the value that must be passed to /helpop as a parameter, if the help:: is left out, then it will be used when no parameter is passed to /helpop. The entries for the help block are the text that will be displayed to the user when requesting the /helpop. 3.31 – Set Block (Previosuly Known As unrealircd.conf / networks file) The set file is what use to be our networks/unrealircd.conf and our networks file. On single server networks, rather than have 3 files, I recommend including all of the set commands in the unrealircd.conf . Now, if your server is on a network, chances are you will all basicly use the same Set settings. Therefore it makes more sense to have a network file, which is loaded with a include:: directive. Below you will find all of the set directives available. Also, please note, that this release was rushed a bit, in future releases; I will expand on all of the set settings and syntax listed below. Syntax: The set block sets options for individual server features. Each entry does something different and therefore each will be described below. Some directives have sub blocks which will also be described. set::kline-address <email-address>; set::modes-on-connect <+modes>; set::modes-on-oper <+modes>; set::auto-join <channels>; set::oper-auto-join <channels>; set::anti-spam-quit-message-time <timevalue>; set::prefix-quit <text-to-prefix-quit>; set::static-quit {quit message}; set::oper-only-stats <stats-list>; set::maxchannelsperuser <amount-of-channels>; set::options::hide-ulines; set::options::no-stealth; set::options::show-opermotd; set::options::identd-check; set::options::show-connect-info; set::dns::timeout <timevalue>; set::dns::retries <number-of-retries>; set::dns::nameserver <name-of-dns-server>; set::network-name <name-of-network>; set::default-server <server-name>; set::services-server <server-name>; set::stats-server <server-name>; set::help-channel <network-help-channel>; set::cloak-keys { <value>; <value>; <value>; }; set::hiddenhost-prefix <prefix-value>; set::hosts::local <locop-host-name>; set::hosts::global <globop-host-name>; set::hosts::coadmin <coadmin-host-name>; set::hosts::admin <admin-host-name>; set::hosts::servicesadmin <servicesadmin-host-name>; set::hosts::netadmin <netadmin-host-name>; set::hosts::host-on-oper-up <yes/no>; set::scan::endpoint <ip:port>; set::bind-ip {ip}; set::message {message}; set::ban-time {time} set::ssl::egd <filename>;
5 – User & Oper Commands Table
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
