Menu
▾
▴
[Solidircd-CVS] solidircd-stable/doc template.conf,1.8,1.9
|
From: Gabriel B. <sh...@us...> - 2006-03-12 16:06:24
|
Update of /cvsroot/solidircd/solidircd-stable/doc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2097/doc Modified Files: template.conf Log Message: template clean up. Index: template.conf =================================================================== RCS file: /cvsroot/solidircd/solidircd-stable/doc/template.conf,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -d -r1.8 -r1.9 *** template.conf 26 Dec 2005 06:37:14 -0000 1.8 --- template.conf 12 Mar 2006 16:05:53 -0000 1.9 *************** *** 1,5 **** /* ========================================================================= * English Full detailed server configuration ! * Last revised by Gabriel Baez (sh...@so...) *========================================================================= */ --- 1,6 ---- /* ========================================================================= * English Full detailed server configuration ! * Last revised by Gabriel Baez (sh...@so...) on 12/3/2006 ! * Read reference.conf for more detailed information on this template *========================================================================= */ *************** *** 43,62 **** }; - /* - * The DIE and RESTART commands can optionally require passwords to be - * supplied, to help prevent accidents. If the dpass and rpass tokens are - * not specified, no passwords are needed. - * - * The Admin block may be nested here. (This is currently a purely - * organizational/astetic option. This will probably change in future - * releases. -epi) - * - * The server name may only be changed by a server restart. The info line - * can be changed on rehash, but will not propagate to other linked servers. - * - * There must be exactly one Global block. - */ - - /* --- 44,47 ---- *************** *** 105,194 **** - - - /* - * The services and stats IRC server names are used for the shortform - * commands, which are transformed into targeted name@server messages for - * security. The services server name is used by SERVICES, IDENTIFY, - * NICKSERV, CHANSERV, MEMOSERV, ROOTSERV, NS, CS, MS, and RS. The stats - * server name is used by OPERSERV, STATSERV, HELPSERV, OS, SS, and HS. - * >> defaults: services.dal.net, stats.dal.net - * - * The staff_address token is used for operator hostmasking, as described - * in the Allow block documentation. - * >> default: staff.dalnet - * - * The nshelpurl token is used to supply a URL for nick registration help. - * It is sent to clients in the rejection numeric when they encounter a +R - * channel and are not registered. - * >> default: http://docs.dal.net/docs/nsemail.html - * - * The maxchannels token limits the number of channels a user may join at - * one time. The limit for server operators is 3x this one. - * >> default: 10 - * - * The server type changes some behavior to be appropriate to the role. - * CLIENT servers can only link to one other server (their uplink hub). - * HUB servers link several servers together, but are not intended to hold - * general users. The SERVICESHUB type enables some optimizations for - * directly-connected services; it requires special services support and - * should not be used in other cases. - * >> default: CLIENT - * - * The server is capable of sending a set of notices to users on connect, - * providing some information about a proxy bot that scans them. The - * wgmonhost token is the host the bot will be connecting from (for users - * with firewalls or other connection monitoring), and wgmonurl is a web - * page containing additional information about the bot. If neither token - * is specified, the notices will not be sent. - * - * Proper clock synchronization is required among connected servers. This - * requirement can be relaxed by using the ts_warn_delta and ts_max_delta - * tokens. The TS delta is the difference (in seconds) between the clocks - * of this server and the one it is linked to. These options should only - * be used as a last resort; the correct fix for TS delta problems is to - * synchronize the clocks on both server computers, such as with the ntpdate - * tool. Unsynchronized clocks may cause unpredictable network problems. - * >> defaults: 15, 120 - * - * The local_clones and global_clones tokens control the maximum number of - * connections the server will allow from the same place by default. The - * first number refers connections from the same IP (10.0.0.5). This number - * may optionally be followed by a colon ':' and a second number, which - * refers to connections from the same site (10.0.0.*). The local_clones - * token sets the default limits for connections on this server only, and - * may be overridden by the maxclones token in a Class block. The - * global_clones token sets the default limits for connections as seen on - * the entire network, and may be overridden by network services. - * >> defaults: 10:60, 25:150 - * - * The crypt_oper_pass token configures the server to use hashed passwords - * in the Oper blocks, to avoid password discovery by someone reading the - * conf file. If this token is specified, passwords in the Oper blocks - * must be generated by the tools/mkpasswd utility. - * - * The short_motd token enables use of the ircd.smotd file, which is sent - * to clients on connect instead of ircd.motd. The MOTD command still sends - * the contents of ircd.motd as normal. This option is intended to reduce - * traffic on connect, but still convince users to read the full motd when - * appropriate. - * - * The show_links token causes the LINKS command to display real server - * links (though Super servers are still hidden). If this token is not - * specified, LINKS will display the list given to it by services. - * - * The allow_split_ops token causes the server to always give chanop status - * to users who join empty channels, even when no other servers are linked. - * Normally op status will not be given when this server is alone, to help - * prevent channel abuse during netsplits. This token should be used if - * your server is not part of a network. Opers are always given op status - * in empty channels regardless of this setting. - * - * All of these tokens are optional, and can be specified at different times - * in multiple Options blocks. If a token is specified twice, the second - * value overrides the first. - */ - - /* Client Side SSL * Issues to note... --- 90,93 ---- *************** *** 197,209 **** * This means that if you want to be sure that your communication is secure, you and the person with whom you want to * communicate securely should both connect to the same SSL-capable server, and communicate via a query window. ! * If talking on a channel, be aware that everyone on the channel must be on a secure connection. * If one person on the channel is not on a secure connection, your communications on that channel will not be secure. * ! * To create your SSL certificate run the /makecert.sh file in ircd/ssl/. */ - /* uncomment this if ssl is enable. ssl { certificate "ssl/vgc.pem"; # Server Certificate --- 96,109 ---- * This means that if you want to be sure that your communication is secure, you and the person with whom you want to * communicate securely should both connect to the same SSL-capable server, and communicate via a query window. ! * If talking on a channel, be aware that everyone on the channel must be on a secure connection * If one person on the channel is not on a secure connection, your communications on that channel will not be secure. + * + * Channel mode (+S) Only Allows secure connections to access the channel. * ! * To create your SSL certificate run the /makecert.sh file in ircd/ssl/ */ ssl { certificate "ssl/vgc.pem"; # Server Certificate *************** *** 212,216 **** }; ! */ --- 112,116 ---- }; ! *************** *** 274,322 **** - /* - * Idle connections are polled with the PING command every pingfreq seconds. - * - * The maxsendq token controls the size of the internal send buffer, used - * when a connection cannot accept large amounts of data at once. Certain - * server commands emit such large amounts of data. As an example metric, - * a 100KB user send queue can support a WHO <channel> query for a channel - * with approximately 700 users. Large amounts of data are also generated - * when two servers link and synchronize network state. If the send queue - * limit is exceeded, the connection is terminated. - * - * For classes used in the Allow blocks, the maxusers token limits the - * number of clients that may exist in this class. This is the most common - * general user limit for the server. If this limit is reached, additional - * clients will be rejected with a "server busy" message. This token must - * not be specified for classes used in the Connect blocks. - * - * For classes used in the Allow blocks, the maxclones token limits the - * number of clients that may connect from the same place in this class. - * The first number refers to connections from the same IP (10.0.0.5); it - * may be optionally followed by a colon ':' and a second number, which - * refers to connections from the same site (10.0.0.*). If this limit is - * reached, clients will be rejected with a "too many connections from your - * host/site" message. Limits defined here override the defaults as - * configured in the Options block. If a site limit is not supplied here, - * clients in this class will effectively have no site limit; the default - * limit will not be used. This token must not be specified for classes - * used in the Connect blocks. - * - * For classes used in the Connect blocks, the connfreq token specifies the - * frequency at which autoconnections are tried. This token works together - * with maxlinks, which specifies the maximum number of servers in this - * class to autoconnect to. For an autoconnection to take place, the - * Connect block must have a valid port token, and there must be less than - * maxlinks connected servers in this class. The connfreq and maxlinks - * tokens must not be specified for classes used in the Allow or Oper - * blocks. - * - * A "default" class is created internally using definitions in config.h. - * This class is used when no other class is specified, but its settings are - * not useful for most situations. Custom classes are strongly suggested. - * - * There may be multiple Class blocks; at least one is recommended. - */ - /* --- 174,177 ---- *************** *** 371,473 **** }; - /* - * The server uses a default-deny policy for incoming connections; at least - * one Allow block must be supplied if you wish to use your server. - * - * The host and ipmask tokens specify which connections this block matches. - * The server always performs DNS and ident lookups for connections. If DNS - * cannot find a hostname, the IP is used instead. If ident cannot get a - * valid response, "unknown" is used during this stage. The client's - * resolved hostname, IP address, ident reply, and username (from the USER - * line) are used according to the results of the matches described below. - * - * The host token attempts to match first against the resolved hostname if - * available, then against the IP address. To include the connection's - * ident response in the match, use a mask in the form "ident@host". If a - * client matches this token, it appears on IRC using its resolved hostname. - * - * The ipmask token attempts to match against the IP address only. To - * include the connection's ident response in the match, use a mask in the - * form "ident@host". If a client matches this token, it appears on IRC - * using its IP address, even if its hostname was resolved. - * - * If the matching mask used ident ("ident@host" instead of "host"), and no - * ident response was received from the client, it appears on IRC with its - * username prefixed with '~'. If the matching mask used only the "host" - * form, the client's username is not prefixed. If a valid ident response - * was received, it is always used (without prefix), regardless of the mask - * form. - * - * Only one of the host and ipmask tokens is needed; if both are used, host - * is matched first. For typical configurations, using only the host token - * with a "*@host" or "ident@host" mask is recommended. - * - * Examples: - * // client with username "user", ident "ident", hostname "name" - * host ident@*; # appears as ident@name - * ipmask *; # appears as ident@10.0.0.1 - * - * // same client without ident response - * host *; # appears as user@name - * host *@*; # appears as ~user@name - * ipmask unknown@*; # appears as ~user@10.0.0.1 - * - * The port token limits this block to match connections to the specified - * port only. - * - * The passwd token requires that matching connections supply a password to - * use the server. Clients can send a password string in multiple forms, - * depending on which passwords need to be used. The basic format is: - * - * [passwd][:][opername:operpass][:][nickpass] - * - * If the Allow block requires a password, it must be supplied at the front - * of the string. If operator hostmasking is enabled (via the flags token - * described below), the client can mask itself by supplying a "name:passwd" - * string as defined in an Oper block. When masked, a client appears on IRC - * using the Oper block name for its ident, and the Options block - * staff_address for its hostname. Any remaining passwords are sent to - * NickServ in an SIDENTIFY command. All password components must be - * separated from each other by a ':' colon. - * - * Using the examples in this file, a client could connect with the password - * string "secret:johndoe:secret" and be masked as jo...@st.... - * - * The flags token allows special behavior to be assigned to this - * connection, using a set of single-letter options. The available flags - * are: - * - * m Enable operator hostmasking - * C Bypass clone limiting - * F Force umode +F to bypass message flood checks - * T Disable rapid (re)connection throttling - * - * When operator hostmasking is enabled, a matching client can connect using - * a special password to be masked, as described for the passwd token above. - * - * Normally all clients are subjected to a clone limit check when they - * connect, as configured in the Options and Class blocks. The C flag skips - * this check for matching clients, allowing them to have an unrestricted - * number of connections. - * - * The F flag forces matching clients to always have usermode +F, to avoid - * various message flood checks. This flag is intended for special bots and - * should not be used for server operators; opers can make use of the F - * access flag as described in the Oper block documentation. - * - * By default, the server throttles rapid (re)connections from a single IP - * address, to help reduce abuse and load. The T flag disables this - * mechanism for matching clients. To qualify, a client must send valid - * NICK and USER messages to register the connection, and stay connected - * long enough to complete the ident and DNS lookups. However, a correct - * password is not required. - * - * The class token specifies the connection Class to place matching - * connections in. If not specified, the default class is used; see the - * Class block description for details. - * - * There may be multiple Allow blocks; they are matched in the order they - * appear. - */ --- 226,229 ---- |
