]> 10 June 2001 Andrew Suffield

asuffield@users.sourceforge.net

2001 Andrew Suffield Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation A copy of the license is included in the section entitled "GNU Free Documentation License". This document describes the commands and functions available to operators in the dancer ircd, version 1.0, as used on the Open Projects Network. This document also details some of the basic philosophies and procedures of the Open Projects IRC network. It is recommended that you read the dancer users guide for more complete details of normal network operation from the perspective of the users. While this document may be of some interest to the users of dancer servers, it is intended as a reference for operators. The dancer ircd is based on hybrid-6, although much has changed. hybrid-6 is commonly used on efnet, and some other networks. The dancer IRC server was written for the Open Projects Network, and designed with OPN philosophy in mind. As such, it may have features which are at odds with other networks and their philosophies. The Open Projects Net philosophy has several components. OPN exists to provide interactive services to projects and groups involved with "Open Source, Open Technology and Open Information." We work to provide an interaction environment in which free software community members can improve their skills in the areas of communication and coordination of effort. We also try to provide an environment which serves to introduce new participants to the free software community. The basic principles of OPN are: Community members benefit from better access to each other. Putting a number of projects in close proximity in an interactive environment creates linkages between developers and projects, and helps community members take better advantage of each other's work. Communication and coordination skills are important to community projects. Free software and open source work because the paradigm works. Developers and community members are not unusually gifted at project coordination and communication. But improving those skills can make projects work better. Friendly interaction is more efficient than flaming. Calm, relaxed discourse without angry contention provides for better exchange of information. Flaming produces situations in which the listener must contend with the state of his or her emotions at least as much as with the comprehension of a speaker's comments. Open source developers are self-driven. No one guarantees your work will be used, but only you decide whether a project is worth doing. There is no single right approach to any coding or support problem, and friendly competition is a fundamentally good thing. The free software community is small, and needs to grow. Many valuable projects chronically lack skilled, motivated developers with time to devote to them. Our potential developer base includes programmers in all fields and disciplines, and both students and working professionals. Our potential user base includes individuals and organizations standing to benefit from software projects we successfully pursue. The community must continue to grow. Free software is about the software. Free software and open source were not born in the recent venture-capital, pre-IPO environment. Our roots are in coders coding software for the benefit of themselves and their organizations, and for the pleasure of producing quality work. It is completely legitimate to profit monetarily from coding and supporting free and open applications. Corporate sponsors of open source projects are welcome on OPN. It's time, though, for the community to get back to its roots. The OPN IRC network provides a controlled environment in which open projects can communicate between developers and users. To this end, OPN is centrally maintained, and operators are expected to try and resolve situations without actually exercising their power when possible. They are also expected to stay out of channel politics and arguments, so don't bother asking them to intervene if you disagree with the people who run a channel. They won't. OPN runs a full services implementation, which allows nicks and channels to be registered and protected by the server, thusly making channel takeovers largely impossible, while maintaining a consistant interface for channels to be managed. If an individual has somehow gained ops on a channel, then the channel founder, or people with an appropriate level of access, can handle it themselves with chanserv; refer to the dancer users guide for details. If somebody has managed to take founder access (by guessing the founder password, or whatever), then the original founder should come to channel #openprojects ASAP so that the situation can be resolved. The most visible change from vanilla hybrid, and most other IRC servers, is with relation to operators. In most IRC servers, an operator has considerable power, being able to use KILL and KLINE to remove people from the network, and possibly more. In the now aging dancer-ircu, operators were gods, able to join any channel, kick, ban, etc. This is not the case in dancer. These are the things that any operator can now do: See the oper help, and motd When attempting to gain a restricted mode they do not have access to, opers will be told that. Normal users will be told there is no such mode. Show up as operators in commands like WHOIS and TRACE, if the person who invoked the command can see operators. Be counted in LUSERS and similar commands as an oper. That's it. No more. All other functionality has been distributed across the umodes, which can be individually granted in ircd.conf. In dancer, every operator is granted a set of allowed umodes, and default umodes. Default umodes are those which are automatically set when the person becomes an operator with the OPER command. Allowed umodes are those which the user may set on themselves afterwards. These will be listed when the OPER command is successfully invoked. Auspex is the ability to see all users, servers, and IP addresses. Auspex users can see inivisible users and secret channels. Care should be taken to keep this information private, and not reveal it to non-auspex users. Users with the +b umode set will receive warning messages from the server when potentiol flooders and spambots are detected. Users who have the +c umode set will receive server notices when clients attach to the network. They are also warned when a client fails to provide reverse DNS or ident information. The +d umode provides extra information and commands which may be of interest to debuggers. It will also cause the user to receive server notices if certain assertions fail inside the server. It's precise meaning is extremely variable. While every effort will be made to ensure that it grants no extra privileges, no guarantees can be made. Do not depend on the effects of this umode as they can and will change without notice in later revisions. Note that this may (and usually will) divulge information about the network routing. It may also give away IP addresses. Yeah, it's a security risk. Sorry. The DIE command causes a server to cease processing at once and exit. This umode should not be granted without due care. This umode is used for integration with dancer/hybserv. A user with the +e umode has successfully identified with nickserv. Under no circumstances should +e be granted in an O:line. This is a user umode, which anybody can set. It is not specific to operators. If a user has the +E umode set, then any users who do not have the +e umode set will receive an error message if they attempt to send a private message or notice to the +E user. Users with the +f umode set will receive notices when an I:line becomes full, and users can no longer connect. +F users will not be throttled in their use of commands, nor will they be checked by the flood detection code. This umode grants the ability to use the GLINE command. This is a global ban which distributes across the network to every server, against a given user@host mask. It should be used with caution. An operator who can do global kills can kill a user who is attached to a different server. See +K, local kill. A person with high priority set will have their connection polled more often by the server, and will still be able to do stuff while the server is in high traffic mode. Normally, high traffic mode means that most commands from attached clients will be rejected, until the server can clear it's backlog of processing. This mode should be granted sparingly, to only those people who would need to be able to work rapidly when the server is under extreme load. This grants the ability to use the rehash command, to reload the server configuration files. This is a user umode, which anybody can set. It is not specific to operators. Invisible users do not show up in WHO unless you can see them, and their WHOIS will only show channels on which you can see them. See +a, auspex. This is a user umode, which anybody can set. It is not specific to operators. If you have the +I umode set, nobody will be able to issue an INVITE to let you in to a channel. Users with the +k umode set will receive server notices when server kills occur. With the +K umode, a person can set klines and use the KILL command, to remove people from the server they are connected to. A user with +l set will receive a server notice when a new channel is created (by somebody entering it). With the +L umode set, a user can use the 4-argument LUSERS message to force a recount. they are able to speak even if they are banned. A user with +M set can send notices to people based on a mask. A notice to $* will go out to every user on the network. A user with +n set will receive a server notice every time somebody changes their nick, giving the old and new nicks. The +N umode overrides Q:lines and X:lines, which normally forbid the use of given nicks. This is potentiolly useful if running without services, to protect the nicks of opers, should you wish to do that. This indicates global operator status. It's meaning is now minimal; it is a gateway to the operator umodes. Setting -o will automatically remove all the operator umodes. The things which +o still does are listed in Dancer operators. Under no circumstances should +o be granted in an O:line. do, they can always join channels and speak regardless of channel modes, limits, or bans. This umode allows the use of the command SETNAME, SETHOST, and SETIDENT. It also allows the operator to change another person's umode, although they cannot grant modes that the target user doesn't have without +*, grant modes. Users with this umode set will receive a server notice when somebody tries to use an invalid nick/username, or a quarantined nick (Q:link) or banned nick (X:line). This umode grants the use of the commands CONNECT and SQUIT, in both local and remote forms. It also allows the use of the HTM command to query/change current HTM settings. This umode allows a user to receive server notices. This allows various commands, notably ADMIN, INFO, MOTD, VERSION, and STATS, to be used in their remote form, where an extra server parameter is given and the command executes on a remote server, returning results to the user. Note that this command does not affect the local or remote forms of the CONNECT and SQUIT commands; these are controlled entirely by umode +R. This grants the use of the UNKLINE command. This causes the privileges an oper has available to be returned when the +v user WHOIS's them. This allows the routing between the servers to be seen. This activates the MAP command, and shows routing information in LINKS, as well as showing full server connection messages. This is a user umode, which anybody can set. It is not specific to operators. Users with the +w umode set will receive WALLOPS messages. Users with the +W umode can use the WALLOPS command to send WALLOPS messages. People who have the +x umode set will see all servers being introduced when a server rejoins, not just the one which made the connection. (This means all the servers already connected on the other side of the link). This obviously divulges routing information, and is rather loud on a large network. It's value is uncertain. This umode controls access to various experimental features of dancer. It is deliberately undocumented. If you do not know what it does (if you are not involved in the development of dancer) then you should not use it. The features it controls will eventually be moved out and documented when their usage (and their side effects) are better understood. This umode should be used with caution, as it is an invasion of privacy. Nonetheless, it is necessary that some people have this ability to detect stealthy floods. All sorts of client activity will be reported to an oper with umode +y set. OPERWALL differs from WALLOPS in that the ability to receive such messages is restricted. Users with +z set will receive OPERWALL messages. The ability to send OPERWALL messages is controlled by the +Z umode. Users with the +0 umode set are able to tell that a person is an oper by their WHOIS, and in various other commands such as STATS o and TRACE. This umode allows the use of STATS commands to see: B:lines (deprecated) E:lines (deprecated) F:lines (deprecated) I:lines Y:lines This umode allows the use of STATS commands to see: D:lines G:lines K:lines This umode allows the use of STATS commands to see: Q:lines X:lines This allows the use of the STATS T command, to get general server statistics. This allows the use of the STATS ? command, to get a list of all servers and some statistics on them from the perspective of the current server. This umode enables the TESTLINE command. This umode allows the user to grant umodes they have access to to other people. As such it is very dangerous, and should be carefully controlled. It is strongly recommended that * never be put in the default umodes for anybody, and that it only be set when it is needed, to prevent accidents. When a user has +* set, then they may set a mode on another user which that user would not normally have access to (assuming the originator has the ability to gain that mode themselves). This umode will be added to the list of umodes that the target has access to for the duration of the session. Similarly, removing a umode will revoke the ability to use that mode, unless it is in the list of normal user modes. This umode is useless without +P also set. All commands and names are case insensitive. CONNECT target port source Initiate a connection attempt to server target. If a port is given, connect to that port on the target, otherwise use the one given in ircd.conf. If source is given, tell that server to initiate the connection attempt, otherwise it will be made from the server you are attached to. SQUIT server reason Closes down the link to server from the current server. If a reason is given, it will be sent out in the server notices on both sides of the link. REHASH DNS IP TKLINES GLINES GC MOTD OMOTD HELP DLINES With no parameter given, ircd.conf will be re-read and parsed. DNS Re-read /etc/resolv.conf IP Reload the internal IP hash. Don't use it unless you know what that means. TKLINES Clear all temporary K:lines GLINES Clear all G:lines GC Force immediate garbage collection MOTD Reload the MOTD file OMOTD Reload the operator MOTD file HELP Reload the help file DLINES Rehash D:lines Cause an immediate total shutdown of the IRC server, and restart from scratch as if it had just been executed. DIE server reason Immediately terminate the IRC server, after sending notices to all connected clients and servers, optionally with the given reason This command cannot be used remotely. The server name is used only as a safety measure. HTM ON OFF TO rate QUIET NOISY With no parameters, the server will return the current HTM rate and status High Traffic Mode controls how the server polls it's connections. When HTM is on, the server will poll server and high-priority connections more often, making it more efficient on those connections. This will make it notably less efficient at handling normal local client traffic. ON Forces HTM on OFF Forces HTM off TO rate Sets the traffic level at which the server will automatically switch HTM on until things calm down QUIET Prevents the server from notifying the operators when HTM is activated/deactivated NOISY Makes the server notify operators when HTM is activated/deactivated SET LOG MAX FLUDNUM FLUDTIME FLUDBLOCK SPLITDELAY SMALLNET SPAMNUM SPAMTIME value The SET command sets a runtime-configurable value LOG Logging level for ircd.log and syslog MAX Set the maximum connections allowed (may not exceed the compiled-in value HARD_FDLIMIT) FLUDNUM The number of messages needed to trip the flud alarm FLUDTIME Number of seconds in which FLUDNUM messages must occur to trip the flud alarm FLUDBLOCK Number of seconds to block fluds for. 0 disables flud checking. DRONETIME Number of seconds in which DRONECOUNT messages must occur to trip the drone alarm DRONECOUNT Number of messages which constitutes a drone flood. 0 disables drone flood checking. SPLITDELAY Number of minutes after a connect burst begins until joining an empty channel will give you ops SMALLNET Sets the number of servers which are needed to constitute "attached to the network", as opposed to "split" SPAMNUM Sets the number of JOINs/PARTs which constitutes a possible spambot SPAMTIME Staying on a channel for less than this length of time adds to the SPAMNUM count Shows some internal hashing statistics. If you don't know what it means, don't use it. Shows some statistics about the internal asynchronous resolver. If you don't know what it means, don't use it. KILL nick reason Disconnects the user with the given nick from the server they are connected to, with the reason given, if present, and broadcast a server notice announcing this. Closes all connections from clients who have not completed registering. KLINE length nick user@host user@a.b.c.d :reason Add a K:line to the local server config file to ban the given user from using that server. If a nick is given, the user@host they currently have will be banned, otherwise the ban will be directly added. If the optional parameter length is given, the K:line will be temporary and last that long in minutes. If an IP address is given, the ban will be against all hosts matching that IP regardless of DNS. The IP address can be given as a full address (192.168.0.1), as a CIDR mask (192.168.0.0/24), or as a glob (192.168.0.*). All clients matching the K:line will be disconnected from the server immediately. If a reason is specified, it will be sent to the client when they are disconnected, and whenever a connection is attempted which is banned. UNKLINE user@host Will attempt to remove a K:line matching user@host from the config files, and will flush a temporary K:line. DLINE nick a.b.c.d :reason Add a D:line to the config files, which will deny any connections from the IP address of the banned client (either the address given, or the address of the user specified). If a reason is specified, it will be sent to the client when they are disconnected, and whenever a connection is attempted which is banned. D:lines are less load on a server, and may be more appropriate if somebody is flooding connections. user@host :reason Adds a global network ban on the given hostmask. All clients attached which match this hostmask will be disconnected. If a reason is specified, it will be sent to the client when they are disconnected, and whenever a connection is attempted which is banned. user@host a.b.c.d Looks up the given hostmask or IP address and reports back on any I:, D:, G:, or K: lines found. SETNAME nick value SETIDENT nick value SETHOST nick value Set the fullname, ident (username), or hostname associated with a particular nick for the duration of this session. STATS type nick server Display various statistics. c Show C/N:lines d Show D:lines g Show G:lines h Show H/L:lines i Show I:lines k Show temporary K:lines, or matched temporary K:lines K Show K:lines, or matched K:lines L Show IP and generic information about the given nick l Show hostname and generic information about the given nick m Show commands and their usage statistics o Show O/o:lines P Show configured ports p Show opers connected and their idle times q Show Q:lines r Show resource usage by the ircd Only available if compiled in debugging mode s Show the server name cache t Show generic server stats U Show U:lines u Show server uptime v Show connected servers and their idle times x Show X:lines y Show Y:lines z Show memory usage stats ? Show connected servers and sendq information about them TRACE server nick Shows client information about the given target, or about the current server if no targets are specified. The path to the target will also be given, and all servers and opers connected. WALLOPS :message Sends a WALLOPS message to all users who have the +w umode set. This is for things you don't mind the whole network knowing about. OPERWALL :message Sends an OPERWALL message to all users who have the +z umode set. +z is restricted, OPERWALL should be considered private communications. The config file consists of a series of discrete lines. Each line consists of a series of colon-separated fields, the first of which is a single character, which defines what sort of thing the line is describing. A line may also be a .include directive, which is of the form .include "file" and causes file to be read in at that point, before the rest of the current file is processed. Anything from a # to the end of a line is a comment. Blank lines are ignored. M:server name:bind address:description the name the server will claim to be to clients and to other servers, and usually is chosen to be something that resolves to the server's IP address. The text description is sent out in LINKS and when clients connect. The optional bind address is which interface to bind to/send from when making outgoing connections. A:text:text:text This line should contain exactly three text fields, which can contain any arbitrary text. It is returned by the ADMIN command. It is suggested that it contains the name of the organisation running the IRC network, and a means to contact the network/server administrator (probably email). Y:class:ping frequency:connect frequency:maximum links:sendq size Y:lines define classes of connections for later use. The class number is used to connect them to other lines in the config file. All fields are integers. The class field must be a value greater than zero, and must uniquely identify the connection class within the config. The rate at which things in this connection are pinged to see if their connection is still alive is controlled by the second field. connect frequency for a server connection is the time in seconds this server will wait before attempting to make a connection (if autoconnect is allowed). If the connect frequency is 0 then only one connection will be attempted, at server startup. For a client class, this is the number of connections which will be allowed from the same originating IP address, or 0 for no limit. sendq is the size in bytes of the queue which holds messages awaiting delivery to the target. For clients a few hundred thousand bytes is adequete; for servers at least 4Mb is recommended. I:IP mask:password:domain mask::connection class I:lines allow client connections to the server, and control/set various flags about those connections. If the IP mask is 'NOMATCH' then the server will check that the hostname supplied by the client is correct for their IP address. If the domain mask is 'x' then the IP mask is a CIDR mask giving a range of IP addresses which match this I:line. If this is a spoofing I:line then the IP mask is instead the hostname to spoof to. If a password is given, then it must be used at connection time to match this I:line. The domain mask matches user@host, and may (and usually does) contain wildcards. The domain mask may have several prefixes which affect the client connection. They are: - Don't prefix a ~ to the username if the ident check fails. + Require ident check to succeed to connect. ! Only allow n connections (as defined in the Y:line) per IP address, not per hostmask. ^ Exempt from K/G lines. Partially exempt from D lines. & Will not be killed by the bot check. > Exempt from connection limits. _ Exempt from G:lines. = Spoof the hostname. Note that you cannot specify an IP address range *and* a domain mask at the same time. The IP mask will be parsed as the hostname to spoof to. NOMATCH is the usual contents of the IP mask. O:hostname:password:nick:allowed umodes:connection class:default umodes O:lines define who may use the OPER command to gain extended privileges. The hostname may be a mask, and must match for an OPER command to work. The password may be encrypted as an MD5 hash, depending on compile-time configuration. Dancer uses a very different system than most ircds. Rather than a capabilities field, it has a field which contains the list of umodes an oper may have. This allows for very fine control of what a person can and can't do. When an OPER command succeeds, the user will be moved into the connection class specified in the O:line, and they will have all the umodes in the "default umodes" field set. C:hostname:password:name:port:connection class N:hostname:password:name::connection class These always appear in matched pairs, and define what servers may connect or be connected to. The hostname must match that of the remote server. The cleartext password in the C:line on one side of a link must match the (possibly hashed) password in the N:line on the other side. The name must match that given in the first field of the M:line on the remote server. If a port is given in the C:line, a connection will be automatically attempted according to the connection class, on startup, and at regular intervals when a server is not connected. K:hostname:time ranges:username A K:line bans all users matching a given user and host from connecting to the server. Both the hostname and the username may contain wildcards. The time ranges field is deprecated. It allows a range of times in which the K:line is in effect. D:IP address:comment D:lines (dumps) drop all connections from the given address or CIDR mask. This is notably less expensive on the server than a K:line, so should be used by preference to deal with persistant attackers. Note that D:lines must be individually placed on each server, and should not be used lightly. Q:nick mask:reason:user@host Q:lines (quarantines) prevent the given nick or anything matching the given mask from being used, unless the user is connected matching the given user@host mask. X:mask:reason::kill X:lines match the mask against the realname field for the a client attempting to connect. If kill is non-zero (true) then the client will be dropped as if they were K:lined, instead of being allowed to connect, otherwise a warning notice will be broadcast to the opers with +r set. H:domain mask::server name An H:line allows a remote server matching the given masks to introduce other servers. P::bind address::port number A P:line specifies what ports a server should listen on. &fdl;