Services is a software package providing various services such as nickname and channel registration for IRC networks. Read the documentation for more information.
See section 1-3 of the manual.
Services has been reported to run when compiled under the Cygwin [sources.redhat.com] environment for Windows, but has not been tested extensively and is not supported by the author.
One user has reported success in running Services as a Windows service; however, the database files must be owned by the Windows user under which Services runs (e.g. Administrator), and the files' security properties must be changed to prevent the file owner from being altered.
Services was at one point reported to be usable under OS/2; however, it has not been tested recently and is not supported. The author has also heard reports of Services being used with moderate success on AmigaOS.
GCC versions earlier than 3.4 have bugs which cause the __builtin_apply() and __builtin_return() pseudofunctions to be miscompiled (see GCC Bugzilla, bugs 8028 and 11151 [gcc.gnu.org], for details). Working around this problem requires the use of assembly language, so workarounds are platform-specific; Services has workarounds for these bugs on the Intel x86, SPARC, and PowerPC platforms, but on other systems, you will need to use GCC 3.4 or later, or the configure script will report an error and refuse to continue.
Many system libraries, including some versions of the libraries used with Linux and Solaris, have subtle bugs in their strtok() implementations which cause Services to perform improperly, or even crash in some cases. The configure script checks for these bugs, and reports strtok() as "not found" if one or more bugs are present. (In fairness, the definition of strtok() is vague in some respects, and developers of these libraries may have interpreted it differently than the way it is used in Services.)
Your make program isn't compatible with the Makefile for Services. The Makefile was designed to work with GNU make, version 3.79 or later, and may not work with older versions or other systems' "make" programs. In particular, the make programs bundled with SunOS/Solaris and FreeBSD have been reported not to work; you will need to use GNU make on these systems. See the system requirements section for details.
You forgot to run the configure script first. See the installation directions.
Services can be made to support new IRC protocols with the addition of new protocol modules. You will need to write a protocol module to support the specific protocol you want to use; see the technical manual for details.
You need to configure your IRC server to accept Services as an IRC server. For IRC servers based on the irc2.x distribution, that involves adding two lines like the following to your ircd.conf file:
C:127.0.0.1:password:services.whatever.net::99See your IRC server's documentation for details about configuring your servers to accept connections from Services.
N:127.0.0.1:password:services.whatever.net::99
Note particularly that "no N:line" errors can mean any of several things:
This is typically caused by including a port number in the C:line for Services, which tells your server to try to autoconnect to it. This is not what you want, because Services will connect to the server itself, but does not listen for servers to connect to it. The solution is to remove the port number from the C:line.
As described in answer B.7 above, Services does not listen for connections, so you cannot /connect to it.
You forgot to run "make install" after compiling Services.
This can occur if Services was interrupted (e.g., by a power failure) or crashed while writing the databases. Remove the file given in the warning message (this is the file specified by the ircservices.conf LockFilename directive, by default ".lock" in the Services data directory), then use the OperServ UPDATE command to save the databases; alternatively, the FORCE option can be used with the OperServ UPDATE command to perform both steps at once.
Make certain that (1) the disk on which the databases are stored is not full, and (2) that Services has permission to create files in the data directory (on Unix systems, this means that the user-ID that Services runs as must have write and execute permission on the data directory, as well as execute permission on all parent directories of the data directory).
If you have a really large network (tens of thousands of simultaneous users), Services in its default configuration may not be able to keep up with all the network traffic. Here are some possible ways to speed Services up:
Services has been successfully used on networks as large as 22,000 simultaneous users with 260,000 registered nicks.
Make sure you've selected the correct IRC protocol (IRC server) module in ircservices.conf, as described in section 2-4.
Hopefully most of the bugs have been worked out of Services by now, but if you run into a problem like this, you may find the cron utility useful for dealing with such with it; the ircservices-chk script, installed in the same place as the ircservices executable, will check whether Services is running and restart it if not (see section 2-6 for details).
If you're running the DALnet, Unreal, or Undernet IRC server, make sure every server on your network has a U:line for Services in ircd.conf; for example:
U:services.whatever.net:*:*Services will report in a WALLOPS or GLOBOPS message the first time it discovers it cannot change modes.
If the ircd.conf file was created, edited, or copied from a Windows computer, then it may be corrupt (Windows inserts ^M characters at the end of every line), which will cause the ircd to not recognize the U:line. Use a text editor such as vi or Emacs to remove the ^M characters, or re-create the file from scratch.
This is normal, and happens whenever ChanServ kicks a user from a channel in which they were the first to enter (for example, a user without privileges entering a channel with the RESTRICTED setting active, or a user on the channel's autokick list). In this case, ChanServ joins the channel for a short period of time to prevent the user from joining again immediately after they've been kicked. If you are using the Bahamut or Unreal IRC servers, this will result in a message like the above; it can be safely ignored.
You can't. RFC 1459 (the IRC protocol definition) requires that all automated clients send all replies using NOTICE rather than PRIVMSG, and Services follows that requirement. If you want to change how Services replies appear in your IRC client, change your client's settings.
Yes; enable the MergeChannelModes directive in ircservices.conf. (Note that this has minor security implications—be sure to read the comments in the example configuration file.)
These messages can appear when Services disconnects a user from the network or removes (kicks) a user from a channel, and are the result of time lag inherent in all networked systems. For example, if an autokilled user connects to the network and immediately sends a /join command to join a channel, the user's server may receive the /join before it receives the disconnection message from Services. Services will then receive the /join for what it thinks is a user who no longer exists, and reports that it received a message for a non-existent nickname.
These messages do not indicate a bug or other problem, and can be safely ignored.
This is caused by a bug in the "mIRC" IRC client for Windows computers; if you try to send a very long message using the /operserv (or /nickserv, etc.) command, such as a long global notice, then mIRC will insert a colon in the middle of it. There is nothing Services can do to fix this, since Services can't tell whether the colon was intentionally put there or not. If you experience this problem, try upgrading mIRC to the latest version or using another IRC client. Alternatively, as a workaround you can use /msg OperServ instead of /operserv.
See also this thread [trout.snt.utwente.nl] on the mIRC forums.
This is due to a bug in some versions of GCC running on SPARC systems. Services contains a temporary workaround for this problem, but it is very compiler- and environment-specific, and it may not work for you. The bug has been filed in the GCC bug database as bug 11151 [gcc.gnu.org], and has been fixed as of GCC 3.4.
A message like the following:
WARNING: The server services.example.net is sending nonstandard modes: 'ChanServ MODE +r' where FMODE should be used, and may cause desyncs.
is a side effect of the way Services works, and can be safely ignored; the "may cause desyncs" text does not apply to Services.
Make sure you have Guest* (or whatever prefix you specified in ircservices.conf) listed in a Q:line in the ircd.conf file for all of your servers. For example:
Q::Reserved for Services:Guest*This prevents people from using Guest### nicks and colliding people who get their nicks changed. Note that some IRC servers will generate messages whenever someone gets their nick changed to Guest### by Services and a configuration line like the above is used; you may want to modify your IRC client's configuration so it doesn't display the messages (or change the IRC server itself so it doesn't generate them).
Alternatively, if your IRC server supports SQlines, you can set an SQline on the same mask using the OperServ SQLINE ADD command (in the operserv/sline module), and Services will take care of making sure all servers have Q:lines for the nick.
Another user may have set the same E-mail address on their nickname. Use the LISTEMAIL command to see what nicknames have the problem address associated with them.
You don't. Use a bot instead.
Normally, this is because the successor had too many channels registered; in this case, you will see an entry in the log file like the following:
[date] Successor (SuccessorNick) of channel #somechannel owns too many channels, deleting channel #somechannel
This has nothing to do with Services, and is a feature of the IRC server itself which occurs when Services sets the topic on a channel. The "(nickname)" is not actually included in the topic, and the second and later users to join the channel will not see it. There is no way to disable it for the first user, unless you modify the IRC server itself.
No; just tell those users to not use the ACCESS command. (You can also disable the ACCESS command for the whole network by removing or commenting out the LoadModule chanserv/access-levels line in ircservices.conf, but this will prevent even users who understand the ACCESS command from using it.)
Such functionality is unneeded, because ChanServ requires users to register their nicknames before allowing them to register channels. As long as you require users to include E-mail addresses with nicknames, you can just look up the address for the channel founder's nickname if a problem arises with a particular channel.
Set the RESTRICTED option for the channel, as described in the help for SET MLOCK, or use a bot to keep the channel open.
This is a side effect of security measures which prevent non-autoop users from getting a +v in before Services deops them. Either do the +v before the -o or use the ChanServ VOICE command.
In recent versions of Unreal, it is possible to set bans on a user's IP address. However, Unreal 3.2 servers do not send client IP address information to Services, so it is impossible to tell which IP-address bans match the user; thus the UNBAN command will fail to remove them. Unreal 3.2.1 and later do send IP addresses to Services, so if you upgrade all of your servers the problem will go away.
The STATUS command is intended primarily for use by bots, to allow them to take advantage of access level information stored in Services. For this reason, the responses to the STATUS command, including error messages, need to have a fixed format that can be understood by a computer.
These messages and mode changes are harmless, and are caused by the CSSetChannelTime configuration option (see also the relevant part of section 3-2-1). This functionality is implemented by sending a message to the network that Services has the "proper" timestamp (TS) and modes for the channel. Unfortunately, many IRC servers blindly cancel their own modes, including the channel ops of the user who initially joined the channel, before noticing that Services is not actually changing any modes; this results in the server sending out a "-o" mode change immediately followed by a "+o". Some servers also seem to think that the timestamp change is a bug (or hack attempt) and send out a warning to IRC operators about it.
All of these messages are harmless and can be safely ignored, but if they bother you, you may want to consider disabling the CSSetChannelTime option.
If you are using the Unreal IRC server, this may be caused by "extended ban types", specifically third-party Unreal modules that add ban types beyond the standard types in Unreal 3.2 (q, n, c, and r); Services cannot support such ban types, since their behavior is undefined by the base Unreal protocol. Try disabling such modules and see if the problem persists.
In all irc2.x-derived IRC servers (and possibly others), every server on the network must have an H:line for Services in the ircd.conf file, which looks something like:
H:*::services.example.net
Did you define yourself as the Services super-user? You need to insert your nickname in the ServicesRoot directive in the operserv/main section of modules.conf. Also make sure that you have registered and identified for your nickname, and that you have IRC operator privileges.
You can't. However, you can allow Services administrators to obtain Services super-user privilege by setting a password with the OperServ SET SUPASS command; Services admins can then use the SU command to obtain Services super-user privilege.
Services does not kill users when an autokill is added; it only kills them when they next connect. This is designed behavior, intended to reduce the possibility of a mistyped autokill causing the wrong users to get killed. (Suppose you typed "AKILL ADD *@*" and then accidentally hit Enter before finishing the host mask . . .)
Services doesn't count its own pseudo-clients (NickServ, ChanServ, etc.) in its user count, so Services will normally report a number somewhat lower than /lusers. This number will vary depending on which pseudo-clients are loaded, and will also change as nickname enforcers are introduced and removed.
If you have a very large and/or busy network, there may be an additional offset, either positive or negative, caused by lag (1) between users signing on/off and Services recognizing them, or (2) between Services killing a user and the servers receiving the kill. On a network with under 500 simultaneous clients, this difference should typically not be more than one at any time, but it can increase quickly as the network grows in size. (If the difference is abnormally large, see question C.2 for ways to speed Services up.)
Finally, you may have encountered a bug in Services. If the difference in counts increases over time without a corresponding increase in the number of users online, then this is the most likely explanation.
You need to be opered (i.e., user mode +o from using /oper; this is different from channel operator mode) to access OperServ.
To quote from the help for the RAW command:
This command is intended primarily for testing of Services and IRC servers; it has a very limited range of uses on a live network, and can wreak havoc on a network or cause Services to crash if used improperly. DO NOT USE THIS COMMAND unless you are absolutely certain you know what you are doing!In particular, Services does not process any messages sent with the RAW command; so if (for example) you use KILL to kill a user, Services will think the user is still online, and if they connect to the network again, Services may fail to recognize the new user or even crash. You should not use the RAW command without a detailed understanding of both the IRC protocol and the internal design of Services itself.
This is designed behavior. Use the OperServ AKILL command instead of the /gline command.
If you have EnableExclude defined in the operserv/akill section of modules.conf, but your IRC server does not support autokill exclusions, then Services will not add AKILLs or G:lines, because doing so would prevent autokill exclusions from working properly. See section 3-4-3 for details.
Services never kills users when a new autokill is added; the ImmediatelySendAutokill configuration directive only causes Services to send the autokill itself (that is, the user/host mask from which to prohibit new connections) to the IRC servers on your network. This is a safety feature intended to limit the damage caused by a mistyped autokill; see also answer F.4 above.
Note that some IRC servers will themselves kill users matching a newly-added autokill; this is unrelated to Services.
(This section has been deleted since Services is no longer being maintained.)