System time:  Thu/06/24 : 23:42:24

Check your basic groove comin' atcha loud and clear from fluctuator.
Setup httpd properly as opposed to the un-chrooted mess of a setup that was running as _lighttpd:_lighttpd before.

New webmail is in action, though - still with one or two bugs left to work out, but nothing major.

New mail server is live and processing messages. It has to be said, I learned a metric crap-ton playing around with vpopmail and trying to make it play nice with all the patching that was done.
It's comforting to know I'll probably never have to do anything to my mail-server ever again short of come up with a better way to allocate storage to the queues and imap mailboxes.

Best of all, everything is so much faster than it was before.
Good thing too, kinda makes it worthwhile.

I'll give things a week or so before I shut down and de-rack thallid.

In other news... hmm. Short of an unfortunate series of tragedies regarding co-workers, and above all else - friends, there isn't much. Besides, I can't really comment on the former here of all places.

Shine Shine

Added eight images to the gallery. Random findings in the West Fraser timber park on one of it's many secret trails.
This should help counter the large amount of random code and console snippets that have found their way on here.

OpenBSD's em driver performance under vmware is still a bit lacking it would seem. Maybe I just got my hopes up since some of the changelog's notes since 4.3

root@scrollrack:/tmp/memnarch_tmp # dd if=/dev/zero of=/tmp/memnarch_tmp/testfile bs=16k count=16384
16384+0 records in
16384+0 records out
268435456 bytes transferred in 26.807 secs (10013587 bytes/sec)
root@scrollrack:/tmp/memnarch_tmp # dd if=/dev/zero of=/tmp/memnarch_tmp/testfile bs=16k count=16384
root@scrollrack:/tmp/memnarch_tmp # dd if=/tmp/memnarch_tmp/testfile of=/dev/null bs=16k            
16384+0 records in
16384+0 records out
268435456 bytes transferred in 27.122 secs (9897256 bytes/sec)
root@scrollrack:/tmp #
root@cursedscroll:/home # dd if=/dev/zero of=/home/testfile bs=16k count=16384
16384+0 records in
16384+0 records out
268435456 bytes transferred in 88.335 secs (3038810 bytes/sec)
root@cursedscroll:~ # dd if=/home/testfile of=/dev/null bs=16k&
[1] 29127
root@cursedscroll:~ # kill -s INFO 29127
4009+0 records in
4009+0 records out
65683456 bytes transferred in 54.125 secs (1213550 bytes/sec)

Though this is a little over three times as fast with fluctuator than it was on thallid, it's still far, far less than I was hoping for.
It would also seem the memory leak on thallid is crushing read performance of it's nfs shares... funny, I would have expected read & write to be messed up equally. Oh-well.

Maybe the new vmt (4) driver will provide some joy.
I should probably sort this out before getting too much further with having sql, httpd, et al; on a separate virtualmachine... allthough, I suppose 80mbit/sec really isn't all that bad compared to 28, but It would be nice if I could get closer to the 400-550mbit/s I'm getting from the virtual disks at least.

<edit>Then again, maybe vmt will do nothing helpful.
vmt provides access to the host machines clock as a timedelta sensor.

One More Time

Well, spamassassin's in.

root@scrollrack:~/cat sample.txt | mail -s Testing!

From - Sun Jul 18 01:24:09 2010
X-Account-Key: account4
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <>
<strong>X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
X-Spam-Level: **************************************************
X-Spam-Status: Yes, score=1000.3 required=5.0 tests=AWL,GTUBE,NO_RELAYS
autolearn=no version=3.2.5
* -0.0 NO_RELAYS Informational: message was not relayed via SMTP
* 1000 GTUBE BODY: Generic Test for Unsolicited Bulk Email
*  0.3 AWL AWL: From: address is in the auto white-list</strong>
Received: (qmail 26581 invoked by uid 0); 18 Jul 2010 08:24:02 -0000
Date: 18 Jul 2010 08:24:02 -0000
Message-ID: <>
<strong>Subject: *****SPAM***** Testing!
X-Spam-Prev-Subject: Testing!</strong>

Subject: Test spam mail (GTUBE)
Message-ID: <>
Date: Wed, 23 Jul 2003 23:30:00 +0200
From: Sender <>
To: Recipient <>
Precedence: junk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Ugh. I've suddenly remembered why I've left clam until last... It needs maildrop :(
Maybe I'll just not bother right now.
At this point, I should be able to have copies of messages from the old mail virtualmachine forwarded to the new one for a semi-realistic test for a few days.

That really only leaves needing to build up the new memnarch virtualmachine, and move webmail, this blog, the sql database, et al; to it.
Then thallid can be retired!

So close, and yet so far.. ...1:30am? Huh. Bed time I suppose.

Shy Shy

Okay, qmail re-patched. The growing list of to-do's before I start running traffic through scrollrack is getting ever smaller.
Random notes from the last go 'round of stuff.
The swath of spamcontrol patches requires ucspi-ssl to be built.
Add the insane default install location to the qmail build.
For the moreipme, make sure #define MOREIPME in ipme.c and qmail-showctl.c aren't commented out.
Humm... what other problems did I run into...
Oh yes - patch qmail with spamcontrol *first*. Then add the other patches.
It just works better that way around. Fewer rejects to process.

Hurdles remaining in no particular order:
- Add clamav into the loop
- Re-compile in spamassassin support for vpopmail
- Install new version of roundcube, enable spamassassin

Then I think that should about do it.

And now for something completely different...

Londo: "This is like being nibbled to death by... um... pah! What are those Earth creatures called? Feathers. Long bill. Webbed feet. Go 'quack'."
Vir: "Oh, uh, Cats."
Londo: "Cats! I'm being nibbled to death by cats."

Things are only impossible until they're not

Modify LIBS in the vusaged 'Makefile' to get the linker to find libev.

LIBS = -L.. -lvpopmail <b>-L/usr/local/lib -lev</b> -pthread

Compiles A-OK.
Aaaaand best of all...

root@scrollrack:~ # /home/vpopmail/bin/vuserinfo | grep usage
usage:     16% (8192 byte(s) in 2 file(s))

root@scrollrack:~ # grep -A+2 -B+2 success:\ vdelivermail /var/log/qmail/current | tai64nlocal
2010-07-13 19:35:52.397371500 starting delivery 251: msg 78918 to local
2010-07-13 19:35:52.399831500 status: local 2/10 remote 0/20
2010-07-13 19:35:52.423654500 delivery 250: success: vdelivermail:_valiases_processed/did_0+0+1/
2010-07-13 19:35:52.427498500 status: local 1/10 remote 0/20
2010-07-13 19:35:52.431854500 end msg 78916

This just leaves re-patching qmail, rebuilding vpopmail to add spamassassin back in (heh), and getting clam rolling.


> And also trying to work out deliveries are being dropped into an empty file in ~/Maildir/ called '-u'.

root@scrollrack:~ # grep -B+15 -A+1 \\-u /usr/local/src/vpopmail-5.5.0/vdelivermail.c
      if ( limits.disable_spamassassin==0 && vpw!=NULL &&
           !(vpw->pw_gid & NO_SPAMASSASSIN) ) {

        if (!pipe(pim)) {
          pid = vfork();
          switch (pid) {
           case -1:
           case 0:
            dup2(pim[1], 1);
            if (execl(SPAMC_PROG, SPAMC_PROG, "-f", "-u",
                 address, NULL) == -1) {

Spamassassin support was the culprit here. I'll add that back in later once I get things running absolutely smoothly.
Otherwise... vpopmail's now processing messages & aliases properly! WOO!

Now, to start adding patches back into q-mail and seeing what else breaks.
Wonder if it's easier to roll clamav back in first though... hmm...

So I don't forget between now and tomorrow, cleaning up some more random glitches. tracked the connect errors to vusaged being missing. Compiling it after a few tweaks here and there has the linker complaining about undefined references to the defines in /usr/local/include/ev.h which is included in socket.c... bleah. So close...


So, one week wasted chasing down bugs in vpopmail... bleah.
For future reference, causes for:

failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)

Remove the recipient domain from /var/qmail/control/locals, otherwise it won't handoff to vpopmail. Wee!

Now I can get back to this stupid error.

success: client_connect:_connect_failed:_2/client_connect:_connect_failed:_2/

And also trying to work out deliveries are being dropped into an empty file in ~/Maildir/ called '-u'.


12 miles = 19.312128 kilometers

Plus a few more for the river front trail. Went for a bike ride along the following route on Tuesday. It's a little out of whack as Google Maps doesn't know about the bike trails, but that's more or less it.

View Larger Map

'Round the River trail downtown again Wednesday and today. Not much else to report on the ride itself really...

Work progresses on the new q-mail, vpopmail, build. Sorted out a few of the issues with vpopmail. Still one or two minor glitches to track down in the source, but the next challenge - work out how to stop the frigging spamcontrol patch from breaking
Aliases aren't being processed correctly either for some reason... bah!

Oh-well... those will have to wait until tomorrow - it's late now, but getting closer.

Gondolas, lab rats, Viva las vegas! Spe-e-e-d!

For some random reason, the errors spit out by my attempts at getting the new patched qmail build to process messages suddenly sparked the eccentric ramblings of <pLaGuE-DoG>.
Gosh. I suddenly have the urge to find a way to run Starsiege on something and rip his quotes... some of them were amazing.

Now, about that error...

@400000004c2ada070341e29c starting delivery 10: msg 78812 to local
@400000004c2ada070353d45c status: local 1/10 remote 0/20
@400000004c2ada072ab6789c delivery 10: success:

Ugh. Probably something simple, but after all the issues I had getting vpopmail to compile and link, maybe not.
Huh... upon reflection, the clock on the erorr is out of whack. 5:43am? I wonder where the heck that's coming from. Localtime and database time checkout... -8 hrs takes it the wrong direction.
Frick. And clam's choking on something, which is odd as it's not actually meant to process stuff yet. *twitch*
Happiness is a bunch of smokin' human steaks!

Hurt//Maim//Kill; Acknowledge//Submit

<edit>For the record, that error was simple. Make sure the idiot in charge of compiling qmail sets up tcprules *properly*, and what's more creates a /etc/tcp.smtp. weeee!</edit>

Breaking news!

Sudden outbreak of common sense!
Google's YouTube wins Viacom copyright case

Also, I for one, welcome our new bionic feline masters.
More of the kitty and his first generation feet here:

Incidentally, I managed to track down a copy of Windows server 2008 with five(!) CAL seats. Fingers crossed it turns out to be legit... should know come Tuesday.

Oi Oi Oi

Flipped back to the old theme... found some of those bugs I figured there'd be. Will probably change back if I can be bothered to fix them.

Random amusement:
Couldn't have said it better myself...

thallid 2.0 has arrived. Dubbed fluctuator for the time being.
Doesn't do a lot right now... VMWare ESXi is pretty much amazing though I've learned.

Now, I just need to patch and re-build qmail, install vpopmail, and clam among other things.
I still really, really need to fix apache. Nothing wrong with it so to speak, but let's just say it's not set-up properly.

Theme me up Scotty!

New theme. Nothing fancy, I'm sure there's bugs-a-plenty with it given it went together in about 10 minutes.
Probably wind up ditching it given the old one was so much better anyway.

Bring on teh funny!
Komputer Problemz
More Wally
Needz moar Bondo
Well THERE's your problem!