What's crackalakin'?

Crackalaka (claka for short) is an IRC server written from scratch in C. It is meant for standalone use by a group of people who are not trying to use IRC to screw each other over. This means:

This last point is slowly becoming less true: there is some rudimentary protection against some kinds of DoS by clients in this version, but it's nothing serious. See MAXBUF/MAXOVER, below.

I have mostly used the original RFC (RFC 1459) as my guide. It is badly written, ambiguous, and just plain dumb in parts, but I was uninterested in any of the improvements made in the subsequent barrage of IRC RFC documents (in accordance RFC420, I am hating the game, and not the players, as all implementors... "SHOULD hate the game, because they MUST NOT hate the playa(sic)").

Crackalaka is not supposed to scale up in large IRC networks, or to thousands of clients (though it can easily do the latter). My mental model of potential crackalaka users is a small workgroup, who wants to run some form of internal chat service for their own collaboration. Do not run crackalaka on the open Internet. Do not use crackalaka in environments where security is a concern. Do not use crackalaka in the preparation of dangerous and/or volatile Indian foodstuffs. Do not operate crackalaka while under the influence of dangerous or illegal narcotics. Safe when used as directed. Void where prohibited by law. No warranty, expressed or implied, is included with this piece of software; however, if you somehow manage to blow up your computer merely by running crackalaka, that would just about be the god-damnedest thing ever, and I'd sure like some pictures.

The license is BSD (see the LICENSE file). Do what thou wilt, just give me some credit, and would it kill you to write once in a while?

Releases

The latest release (along with its attendant MD5 and SHA1) is always the best place to start. There are some older releases in the release area, but I recommend always using the latest available release. If there is a problem compiling the latest release on your platform, I'd sure like to hear about it. You can also check out the README file and the start of a document on internal crackalaka services and how they will be used to make crackalaka extensible while keeping it small and simple.

You can send the author (old pages) an email, preferably including the Subject token [claka] in your message.

Coding Style

Claka began life many years ago as a Java implementation of a minimalistic IRC server. For reasons that I would rather not go into now, I needed to have as comparable a C implementation as possible, and so I adopted a coding style that is not very much like my normal one for the purposes of this project, essentially transliterating the Java into C.

The resulting effect is not altogether unpleasing, but it's too engrained in the code now to ditch, and it does make it easier to explain in parts. In any event, I would appreciate it if any additions or improvements you make stick to the style that I've laid down, which should be obvious after more than 30 seconds of looking at the code (however, now that I've started pulling code from electric Library Land into claka, e.g. buf, ualloc, etc., this is becoming less true - in some future rewrite, the retarded Java-style will go away).

Setup

Although crackalaka has no real configuration file or other such stuff, it does come with a couple odds and ends to make using it a bit easier under normal circumstances.

Two files, claka.conf and claka-control.sh, will end up in whatever autoconf decides is your system configuration directory, e.g. /usr/local/etc under *BSD. These are both sh files; claka.conf is sourced by claka-control.sh in order to let you change settings without having to change the script.

The basic idea is for you to edit claka.conf to taste; if you uncomment the sucmd setting, then it is assumed to be something of the form "sudo -u claka", where "claka" in this case is the name of a user id you have created to run claka. If you don't do this, then leave sucmd commented out, but also note that the default places for e.g. the log file, are probably in directories that require root access to write into. If this won't work for you, then you must edit claka.conf (or hack something up yourself).

Claka wants to drop a pidfile, and perhaps a log file. It doesn't have to, but it would like to, and claka-control.sh knows how to find the pidfile using claka.conf's setting, so it's better all around if you just give in and make sure claka can write somewhere to drop a pidfile.

Finally, although claka is ultra-stable, bulletproof IndustrialWare(tm), it might be, via some errant gamma ray, that claka needs to dump core. It's nothing to be embarrassed about, we must all dump core from time to time... okay, it *is* something to be embarrassed about, but you should at least give claka a sanitary place to do it. Set mydir to be the directory where claka should run, so that any claka cores get dropped in a predictable place. Obviously, if this happens, I'd like to hear about it...

In any event, by default the directory that claka.conf assumes for this purpose will be something like /usr/local/var/claka (statedir/claka basically). If you do create a claka uid, then chown whatever directory that is to be owned by the claka user, and hack claka.conf to taste.

Everything else in claka.conf and claka-control.sh should be pretty self-explanatory.

MotD Subs

One of the only "cute" features that I've implemented is the ability to put tokens into the motd (message of the day) that will be substituted with the values of environment variables, e.g. if you do 

    $ WOOWOO="hi there" claka

and have the string %WOOWOO% in your motd.txt file, it will be substituted with "hi there" (sans quotes, obviously). The special token %STARTDATE% will be substituted with the date and time that claka was started. The default motd.txt file has several examples of this.

Privacy

Since c'laka is not meant to be used as a part of large, distributed IRC networks, I have taken a couple liberties, both pro-privacy and con-, depending on what side of the coin you're watching.

Pro: crackalaka reports everyone's hostname as "127.0.0.1", e.g. in /WHOIS output. We are all Pan's children, after all, and we are all also technically using 127.0.0.1, aren't we? Can't we all just get along?

Con: if you are a big-O oper, this restriction is lifted, and, furthermore, crackalaka will tell you all sorts of things via NOTICEs, that other IRC servers do not (like when people connect, or when someone tries to WHOIS you).

The idea is simple: a big-O oper in crackalaka.space is almost surely the owner of the machine on which the server runs, since why else would you be doing this? Hmm? So, since you own it, it's yours. There is no code to explicitly tap off non big-O users' communications and send them to the big O's, or anything like that, but, I mean, if you're really paranoid, you shouldn't be connecting to anyone else's IRC server for a variety of reasons. If the operator of the server jacks up the debug level, then everything that goes on will get dumped to the logs, anyway.

Some of what I've said here will clearly change in a future release, given my current plans, but I'll always provide a way to make crackalaka behave the way the 1.0.x release does in these regards. I promise.

There are a few other oddities in crackalaka that might raise your eyebrows if you are used to other IRC servers, but I'll leave them as treats for you to find. There are no backdoors or other kinds of stuff like that, although I encourage any and everyone to look the code over for sport.

MAXBUF/MAXOVER

In a weak attempt to protect against stupid DoSes, there are now two additional command-line options: --maxbuf and --maxover. Maxbuf sets the maximum size of any client request: if we attempt to buffer more than that many bytes on a client connection without at least one complete request appearing, we send the client a nastygram (424) and reset their buffer completely. Each time this happens, we increment a per-client counter, called the overflow counter. If more than maxover such events occur for a client, it is dropped; the idea is that the routine that does this (Server_dealWithMaliciousClient) will eventually have some platform-specific code to e.g. add a firewall rule for that IP to keep it from connecting at all for a certain period of time, or what have you. Right now, it just drops the client on the floor.

This could all be improved in many ways, but it keeps the obvious things from doing any damage, e.g.: 

  $ perl -e 'print "A" x 32767' | nc chat.clakaserver.com 6667

History

  13.Oct.2006   attila  1.0.19  Send back 368 in re MODE #foo b
  08.Oct.2006   attila  1.0.18  Really fix SQUERY and JOIN, damnit
  07.Oct.2006   attila  1.0.17  Fix potential problem in SQUERY command
  02.Oct.2006   attila  1.0.16  Plumber default_channel_modes, other stuff
  01.Oct.2006   attila  1.0.15  Plumber default_channel_topic
  28.Sep.2006   attila  1.0.14  Plumber default_channel option, JOIN fixes
  09.Sep.2006   attila  1.0.13  Added --enable-static for a potential user
  08.Jul.2004   attila  1.0.10  Fixed the inevitable post-release bugs,
                                thanks to Number Six: JOIN, PART and MODE
                                were a bit too zealous.
  04.Jul.2004   attila  1.0.9   Reworked internals for event model; fixed
                                many bugs, including wrong idle times.
  02.Sep.2003   attila  1.0.8   TOPIC numerics, long/short nick stupidity
  01.Sep.2003   attila  1.0.7   Lots of minor numeralia fixed
  25.Aug.2003   attila  1.0.6   Major bug fixes having to do with KILL, etc.
  14.Aug.2003   attila  1.0.4   1.0.1-1.0.3 were pretty much internal...
  12.Aug.2003   attila  1.0.0   Renamed to crackalaka - releasing 1.0.0
  11.Aug.2003   attila  0.4.0   Close to 1.0.x; removed grease dependency
  25.May.2003   attila  0.3.6   Few nits, beefed up this README
  13.May.2003   attila  0.3.5   Added maxbuf/maxover, fixed comma problems
  10.May.2003   attila  0.3.4   Some minor fixes
  08.May.2003   attila  0.3.3   Skipped a few releases...; MANY improvements
  19.Oct.2001   attila  0.2.5   Skipped 0.2.4.  This has patches for the
                                PART bug and implements AWAY.
  06.Oct.2001   attila  0.2.3   Patchlevel 3 for V0.2 is the first
                                really solid version.  Most stuff works.