Stand-alone IRC server
C Shell Perl
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
Old
autoconf
docs
samples
web
Butler.c
ChangeLog
Channel.c
ClientConn.c
CommandLineArgs.c
Debug.c
Event.c
INSTALL
LICENSE
LineBuffer.c
Makefile.in
Member.c
Plumber.c
README
RELEASE
Request.c
Server.c
Service.c
TODO
User.c
VERSION
VERSION.h.in
aclocal.m4
auto_config.h
buf.c
buf.h
buf_int.h
claka-control.sh.in
claka.c
claka.conf
claka.h
claka.systrace
claka.systrace.in
cloxy.c
common.h
config.h.in
configure
configure.in
errors.h
foo.c
hash.c
hash.h
hash_int.h
llist.c
llist.h
llist_int.h
motd.txt
netutils.c
netutils.h
obj.c
obj.h
pushrel.sh
rats.out
run-test-server.gdb
run-test-server.sh
ssfetest.pl
template.c
test.c
testbot
testbot2
ualloc.c
ualloc.h
ualloc_int.h
util.c

README

                   Time-stamp: <2006-10-13 12:01:30 attila@stalphonsos.com>
  Copyright (c) 2001-2003 by attila@stalphonsos.com.  All Rights Reserved.
=={ Crackalaka - A simple, standalone IRC server }==========================
  This is the README file for crackalaka, an IRC server.
  If you are confused by the name, read:
    http://www.urbandictionary.com/define.php?term=crackalaka
  (definition 3, and quite possibly 2, depending...).
===[ CRACKALAKA ]===========================================================
  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:
  + The inter-server portions of the IRC protocol are not implemented (thus
"standalone");
  + The server does not attempt to protect itself against flooding, DoS
attacks, or any other of the garbage you see on real IRC networks (thus
"not trying to screw each other over").
  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 to 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?
  Crackalaka 1.0.x has been tested against the following clients:
  + xchat         (Linux,FreeBSD,OpenBSD)
  + sirc          (Linux,FreeBSD,OpenBSD,Win2k(cygwin))
  + zenirc        (Linux,FreeBSD,OpenBSD)
  + ircII         (Linux,FreeBSD,OpenBSD)
  + mIrc          (Win2k)
  + VIRC          (Win2k)
  + irssi         (FreeBSD)
  + ChatZilla     (FreeBSD,OpenBSD,Win2k)
  Crackalaka currently does not use a configuration file, though I plan to
to add support for something simple and easy to edit in the future (e.g. NOT
the standard irc O-line/K-line type nonsense).  For now, just do
  _$ claka --help_
  to see its options.  They should be self-explanatory.  Or not.  You might
want to read the section on SETUP, below.
====< 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 even if I want to, 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).
====< SIMPLICITY >==========================================================
  When I decided to take the toy that crackalaka started out as and turn it
into a useful server, one of my guiding principles was that it should be
pathetically easy to configure, at the expense of many doo-dads that other
IRC servers provide.  No K-lines.  No O-lines.  No any kind of lines
whatsoever.  A single big-O oper name and password should be good enough.
And so on.
  As a result, claka does not accept any kind of configuration file; to make
setting up claka a tad easier, I have written claka-control.sh, which makes
it possible, in effect, to configure crackalaka via a sh script that sets
variables used in the construction of the claka invocation.  Also, the MoTD
can be parameterized, as described in the section on "MOTD SUBS".
  Other than that, claka is as simple as I could make it.  If you want to
see things I want to add or change, check out the TODO file, which I keep
relatively current.
====< COMPLEXITY >==========================================================
  On the other hand, who am I kidding?  You always want your baby to fly,
and once it can fly why not strap on a couple laser canons and give those
pesky neighbors some real trouble!
  Alright, maybe not, but there are a lot of potential applications for an
extensible, simple messaging framework like crackalaka.  A pragmatic
approach has been adopted based on the idea of IRC services, e.g. the SQUERY
command.  Look at docs/services.txt for a description of clakas services and
how they can be used to build claka extensions in e.g. Perl.
====< SETUP >===============================================================
  Although crackalaka has no 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
that should be pretty obvious.  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
  _ $ perl -e 'print "A" x 32767' | nc chat.clakaserver.com 6667_
  from doing any serious damage.
====< THE FUTURE >==========================================================
  It is my intention to turn claka into a true p2p system, by adding a chat
client to it that allows anyone to be both a client and a server at the same
time, and adding parts of the IRC inter-server protocol necessary to glue
things together (with some extensions).  Furthermore, crypto will be
integrated (via libgcrypt), making it easy to set up ephemeral, encrypted
chat enclaves, which are still usable via normal GUI clients with no change
(the claka servent will, naturally, also be a proxy).
  I am also looking into adding IIP support, and thinking about how to make
that place nice with my servent plans.  Eventually, support for protocols
other than IRC will also be available.
====< BUG REPORTS, PATCHES, SUGGESTIONS, AND BEER >=========================
  Please send bug reports and/or patches and/or donations of beer to
attila@stalphonsos.com (same email address is also fine for PayPal'ing me in
the "beer" case...).  Or, if you're interested in what I'm doing with claka,
feel free to drop me a line.
  In all cases, please put [claka] or [crackalaka] in the subject of your
mail, or it will probably be thrown into my spamcan by bmf.  Alternatively,
signing your message with gnupg and encrypting it to my public key (keyID
4FFCBB9C fpr:A9A1 FD2A 2EFC 70B6 1036 F966 AFCF 222D 4FFC BB9C, on
keyservers near you) will also avoid my spamcan.  Gotta love that whacky
procmail magic.
  I hope you find this useful.  Constructive criticism and commentary is
always welcome.
  Pax,
                                -- attila <attila@stalphonsos.com>
                                   25 May, 2003
===[ VERSION ]==============================================================
  $Id: README,v 1.25 2006/07/13 21:01:26 attila Exp $
====< 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, JOIN fixes, ISON
  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.
============================================================================

Local variables:
mode: text
adaptive-fill-mode: nil
fill-column: 76
paragraph-start: "  \\|\\|=="
indent-tabs-mode: nil
fill-prefix: ""
sentence-end-double-space: t
End: