[IRCServices] Services 5.0.0 released
Andrew Church
achurch at achurch.org
Sun Oct 6 13:49:00 PDT 2002
With thanks for everyone's patience, I'm pleased to announce that
IRC Services 5.0.0 has been released, and can be downloaded from:
ftp://ftp.ircservices.za.net/pub/ircservices/ (South Africa)
ftp://ftp.esper.net/ircservices/ (USA, California)
27a762b806867b1279fe745d193bebf7 ircservices-5.0.0.tar.gz
3109af26d287ce825c80d5045dd46fdc ircservices-5.0.0-1.i386.rpm
c1c77425af52894cb279c95ba0ac3a1f ircservices_5.0.0-1_i386.deb
The other mirrors should have it shortly.
As this is a new major release, the previous version (4.5) will no
longer be supported; all users are encouraged to upgrade to version 5.0 at
their convenience. Support for version 5.0 will now be handled on this
list (ircservices at ircservices.za.net); the ircservices-coding list should
be reserved for technical discussions. Also, please be aware that
upgrading from previous versions will require some preparation--see the
"What's New" information at the end of this message and the documentation
included in the package (docs/index.html) for details.
As most of you probably know by now, Services 5.0 features a rewrite
of a significant amount of the code base (which is now over 60,000 lines
long). I had three primary reasons for doing this:
- First, to add module support. This is the main "new feature" in
Services 5.0, and provides more flexibility in configuring Services;
for example, networks can now choose to not run MemoServ, for example,
or to require mail confirmation for nicknames, simply by selecting or
not selecting the relevant modules for loading. (Mail is itself
implemented as a set of modules.) Using modules also helps limit
undesired interactions between code; much as with the concept of
"encapsulation" in computer science, modules allow individual pieces
of functionality to be separated and hidden from each other, forcing
interactions between them to go through a defined interface, rather
than taking shortcuts that lead to all sorts of bugs. The various
modules are still intertwined to a degree (I had to cut some corners
to have any hope of getting it finished at all in my limited free
time--I could do better if anyone out there is willing to fund
Services development ;) ), but their relationships are better defined
than they used to be.
- Second, to add alternate database support--both an improved binary
format and external, i.e. SQL, databases--to Services. The previous
code base was very dependent on the particular database format used,
and the complexity of that format has caused several problems.
Unfortunately, this is one of the things I didn't have time to
implement for version 5.0, mostly because the code _is_ so dependent
on the current database format, and there are a lot of assumptions
made that I would have to go back and check or correct. I haven't
forgotten this, however, and I'm hoping to get to work on it in a
revision or two.
- Third, and most importantly, to give the code a thorough cleaning.
Some of you may be familiar with noted computer scientist Fred Brooks'
book "The Mythical Man-Month", which discusses many of the mistaken
assumptions and preconceived notions that cause software projects to
go awry. The quote that applies in this case is "Plan to throw one
away; you will, anyhow" (chapter 11). In other words, the first time
you write a program you won't know exactly how it should be designed,
and the end result, even if it works, will generally be a mess--so you
should plan for it to be a mess, and set aside time to redo it from
scratch. I considered version 5.0 to be my chance to do that, at
least partially, with Services.
While I've been adding features to Services for over six years (*),
I've never taken the time to go back and clean it up, and it shows in
both the lax code style in some places--some code actually dates back
to 1994 or so, when I was a considerably less experienced programmer--
and in the rare crash bugs which plagued Services until very recent
versions, most of which were due to forgetting to set a pointer
correctly or similar careless errors. One of the first things I did
after forking the code base for version 5.0 was to replace all linked
list and most array references with macros to ensure that no mistakes
were made handling them; with one special-case exception in the
commands.c source file, there are now no references to the "next" or
"prev" fields of linked list nodes outside of the header file
list-array.h which defines those macros. Hash tables (for users and
channels, among other things) are also handled using a header file,
allowing much common code to be merged into a single location. These
and other corrections should make Services 5.0 considerably more
stable than previous versions.
(*) For the curious, Services 1.0, which was not released publicly,
was finished in late April 1996 and had 6,550 lines of code and no
documentation.
It's been over a year and a half since I started work on version 5.0,
and while I'm not completely satisfied with the end result, I do like it a
lot more than the previous versions. The module system is still very much
a hack, not at all well designed, and it will probably end up being thrown
away a la Brooks--but it works, and I like the flexibility it's added to
Services. While I didn't have time to go back and redo everything from
scratch, I was able to fix the most glaring problems, like the list bugs
mentioned above, and I'm considerably more confident about the stability of
this version than that of any previous release. I also added in several
commonly requested new features, including nickname E-mail address
authentication, as well as a couple of pet ideas of mine (such as the
HTTP server), and I hope people will find them useful.
By the way, Services finally has a real manual, as opposed to the
short README in previous versions. The manual, written in HTML and found
in the "docs" directory of the distribution (as well as on the Services
home page: http://www.ircservices.za.net/docs/), contains over half a
megabyte of text which thoroughly documents all of Services' features, and
includes everything from an overview of each pseudoclient's functions to
command and configuration file references and details on the internals of
the new module system. I am also planning to write a design document for
Services to help those who want to modify Services themselves, but as that
will take a significant amount of time, I decided to go ahead and release
version 5.0 without it. I will get it written eventually, though.
I'd like to take this time to thank the many people without whom
Services would not have grown this far:
First and foremost, Andrew Kempe, who runs the web site and mailing
lists, and who kept Services going in 1999-2000 (versions 4.3 and 4.4) when
I didn't have enough time to work on it myself. Services probably owes its
continued existence to Andrew; if he hadn't picked it up, Services might
have become just one more abandoned open-source project.
The language file translators: Martin Pels (Dutch), Elijah M (French),
Jacek Margos and Holger Baust (German), Janos Kapitany and Krisztian Romek
(Hungarian), Ely Linares (Spanish), and Yusuf Iskenderoglu (Turkish). The
Services language file, which contains all of the messages used by
Services, is nearly 5,000 lines long. That by itself is a whole lot of
work to translate, but on top of that, the messages include many terms and
phrases which don't translate well into other languages. Having done the
Japanese translation myself (twice, because the first time I did it I
didn't know the language very well), I know what these folks have gone
through, and I'm grateful for the time they've devoted to Services.
The mirror site operators: Ian Justman (ftp.esper.net), Michael Raff
(ftp.electrocity.com), Michael Haardt (ftp.freenet.de), Sotiris Tsimbonis
(www.irc.gr), and Andre Arruda (ftp.ircd.com.br). Services may not be a
large program, but it has a fairly large user base spread around the world,
and a single distribution site just isn't enough. Thanks for taking the
time to set up mirrors.
Contributors to Services development. As can be seen in the Changes
files, many, many people have helped in the development of Services,
whether by actually sending code or by just suggesting ideas. There are
far too many to list here, but I appreciate each of your contributions;
without them, I doubt Services would have progressed even half as far as
it has.
Developers of Services derivatives. I don't know how many of them
read this list, but I'd like to say that I'm flattered that people would
care enough about improving my software to start their own versions of it.
This is, in my mind, one of the best things about open-source software;
people can take the source code and change it as they think best, and
eventually the best parts of each will spread to the others. Even Services
itself owes several bugfixes and improvements to such derivative programs.
I'd especially like to mention Epona; while I'm not particularly fond of
the sarcastic comments in the Changes file, I do appreciate the help
finding and fixing bugs, and the idea for the new nickname linking system
in version 5.0.
The anonymous cracker who broke into airship.esper.net five or six
years ago (I don't even remember exactly when anymore) and stole the
Services source code, which at the time was not publicly available. I was
furious at first, but then I figured that if someone wanted the source code
so badly they'd break into a machine to get it, I might as well release it
myself; no point in trying to cram the genie back into the bottle. I still
don't condone cracking, but as a result of this particular incident,
Services has grown to proportions I never dreamed of when I started
developing it. Thanks to you, Services (along with its derivatives) now
0WNZ 7H3 W0R1D!!! H0H0H0 ;)
And finally, everyone who uses Services. I know it sounds trite, but
the simple, honest truth is that you all make it worth the effort. I can't
even begin to count the number of evenings and weekends I've devoted to
Services even since graduating from university and starting a full-time
job, or the number of times I've had people tell me I need to get out more.
(Although I do plan to get out more in the coming weeks!) But if it wasn't
for the fact that so many people use Services, I know that I wouldn't have
spent nearly so much time on it--perhaps none at all. I know I haven't
been able to please everyone; to be frank, I know I can't, so I don't try.
But I do listen to all of your comments, both praising and scathing, and
I'm truly honored that so many people would find software of mine useful.
Thank you all.
--Andrew Church
achurch at achurch.org
http://achurch.org/
---------------------------------------------------------------------------
What's New
=============================================
Summaries of changes in new Services versions
Note: This is intended to highlight only the major changes between
versions. For a complete list of changes, see the "Changes" file.
------------
Version 5.0:
------------
The single biggest addition to this version of Services is module support.
This allows the various functions of Services to be added to and modified
without having to touch the main source code itself. Modules also provide
much more flexibility in configuring Services; IRC server support and
database file format can be selected by simply loading the appropriate
module, and you can even choose which of the pseudoclients (NickServ,
ChanServ, etc.) you want available. See the example configuration files
in the "data" subdirectory for more information.
Services is now capable of sending E-mail. Currently, this functionality
is used by:
+ The new "authorization" feature of NickServ (in the "nickserv/mail-auth"
module). This sends a message to a user upon nick registration or
E-mail address change, and requires the user to "authorize" their
nickname with a random numeric code included in the message before it
is recognized as a valid registered nick by Services/
+ The new SENDPASS command for NickServ and ChanServ (in the
"nickserv/sendpass" and "chanserv/sendpass" modules, respectively).
which allows a user to send themselves their nick or channel password.
+ The new memo forwarding function of Services, which allows users to
have their memos automatically forwarded to their E-mail address.
Services also sports a built-in HTTP server (module "httpd/main"), which
(with the help of additional modules in the "httpd" directory) can be used
for queries about nicknames, channels, and network status. See the
documentation (section 3-6) for details on its abilities, and please submit
a feature request if you have any additional ideas for what functionality
the server should provide.
Nickname links have been redesigned for simplicity and robustness. In the
new linking system, nicks are organized into single-level "groups" which
share settings the way linked nicks did in previous versions, rather than
multi-level "trees" as version 4 used. The LINK command has changed as
well: instead of creating a link from the current (unlinked but registered)
nick to a registered master nick, the link is made from the current
registered nick to a new (unregistered) nick, to simplify registration of
multiple links at once and to offer slightly better protection against
"rogue links" created by guessing nick passwords (though as always, the
best defense is to use good passwords). The old behavior of the LINK
command is still available through the "nickserv/oldlink" module, although
this module is deprecated and will be removed in a future version.
Finally, the documentation for Services (what used to be in the README and
FAQ files) has been greatly expanded and rewritten in HTML, and now includes
references for all Services pseudoclient commands and configuration options.
The manual also contains important information for users upgrading from
version 4.x or earlier; if you are already using Services and plan to
upgrade to version 5.0, please read this information before upgrading.
Other changes:
+ Nicknames now have an "Information" line, similar to a channel's
description, which can be set freely for each group of nicks.
+ The number of nicknames that can be registered per E-mail address can
now be limited (NSRegMaxEmail configuration directive).
+ The default options for newly registered channels can now be set in the
configuration file.
+ Identifies for nicknames are now recorded, removing the necessity to
re-identify after every nick change.
+ The Services stamp of the last user to identify for a nick is now
recorded on disk, removing the necessity to re-identify when
Services is restarted.
+ A time zone can be set for each registered nick, to allow users to get
information from Services in their own time zones.
+ Nicknames can be listed by E-mail address with the new LISTEMAIL command.
+ Users can set channels to automatically join whenever they identify for
their nickname (nickserv/autojoin module) on IRC servers supporting
the SVSJOIN command (such as Unreal or trircd).
+ The NickServ and ChanServ REGISTER and GETPASS commands can now be
(individually) disabled via the configuration file.
+ Users with auto-op access for a channel will now be opped when they
identify for their nickname even if they are already in the channel.
+ Channel access levels are now limited to -999..999; default levels have
been rescaled to make better use of the available range (in
particular, levels -25..25 have been multiplied by 10).
+ The ChanServ OP, VOICE, etc. commands now default to the person sending
the command if a target nick is not specified (e.g. "OP #channel").
+ ChanServ now has a KICK command.
+ Channel information can now be hidden with the new ChanServ SET HIDE
command, similar to the NickServ command of the same name.
+ The ChanServ STATUS command is now available to normal (non-admin) users
with sufficient privileges on the target channel.
+ Users can prevent certain other users from sending memos to them
(memoserv/ignore module).
+ Autokill exclusions (exceptions to autokill masks) are now supported
through the EXCLUDE command (operserv/akill module).
+ S-lines (SGLINE/SQLINE/SZLINE) are now supported (operserv/sline
module), and can even be used (except SZLINE) on servers which do
not support S-lines natively.
+ Services now records the last time an autokick or autokill was
triggered, as well as the set time for autokicks.
+ The maximum expiry time for autokills set by Services operators (as
opposed to Services admins) can now be limited.
+ OperServ now has a SERVERMAP command to show the IRC server tree.
+ Services is now slightly more robust against denial-of-service attacks
which use repeated HELP messages to overload network buffers; if
the network buffer size exceeds the threshold defined by the
NetBufferLimit configuration directive, Services will ignore
commands sent to it until the buffer size decreases. The OperServ
STATS command has a new option, NETWORK, which can be used to show
the current network buffer status.
+ Support for the Chunky Monkey and trircd IRC servers is now available.
+ Services can now synchronize the clocks of all servers on the network
for IRC server types which support this feature (Unreal).
+ Configuration files can now be re-read (rehashed) while Services is
running, using either the new OperServ REHASH command or kill -HUP.
+ The log file can now be rotated automatically based on the date.
+ Databases can now be imported (merged) and exported in XML format.
+ A sample crontab script is now included in the distribution.
* The configuration file has been changed to accommodate modules;
ircservices.conf (formerly services.conf) now contains only options
related to core Services functionality, while module-related
options (including NickServ, ChanServ, etc. settings) are in a new
file called "modules.conf". Many options have been added, changed,
or removed; see the example configuration files for details.
* The network I/O subsystem has been completely redesigned for robustness
and ease of use; multiple sockets (including listener sockets) can
be used simultaneously via read/write callbacks, and sockets now
have variable buffer sizes, allowing more efficient use of memory.
* Database handling has been improved to avoid database corruption on
power outage or process termination/crash.
* The "do not abuse NickServ" warning in the main NickServ help message
is now optional, to allow networks more freedom in writing their
own policies.
* Passwords, URLs, and E-mail addresses are now shared by each group of
linked nicks.
* NickServ DROP now requires a password to avoid accidental use, and
drops all linked nicks in a group at once. The command for
Services administrators to drop a nick is now DROPNICK.
* The channel "#", which has been known to cause problems with both IRC
servers and Services-like programs, is now explicitly not
supported; Services will refuse to register, forbid, or import it.
* Users must now identify for their nickname before registering a channel.
* Channel autokicks specified by nickname now work for that nickname
only, not for any nicks linked to it.
* The CSRestrictDelay option now works correctly and is enabled by default.
* Newly-registered nicks will now always use the default language set in
config.h, even if that language is changed after registration.
* Command-line options that take values now use an "=" instead of a space
between the option name and the value.
* The database conversion utility (convert-db) now outputs an XML
database file, which can be used with the XML import feature,
rather than writing databases directly.
* The configuration script "configure" now asks fewer questions, and can
be completely automated if the "-prefix" option is used.
* "configure" now understands GNU-style options, e.g.: --prefix=/usr
- The AUTODEOP and NOJOIN channel levels have been removed in favor of
the SECUREOPS and RESTRICTED channel options.
- The deprecated CheckClones functionality has been removed in favor of
session limiting.
- The IrcIIHelp pseudoclient (online help for the ircII client) has been
removed.
- The "listnicks" and "listchans" programs have been removed in favor of
the built-in HTTP server.