- Jul 13, 2009 by the_angry_angel
- Geek, Unix-like, Windows, Personal and Mindless Hatred
I use my work Macbook Pro for personal stuff as well, and quite frankly if you don't want kids in the future, it's the laptop to use on your lap. And deity forbid that you want to use a demanding program; you might as well forget about using your legs for a week afterwards. To combat this I've been toying with getting a netbook for over a year now, and since last week was my birthday, I got myself a Compaq 702EA as a present.
Sadly I wasn't impressed with the 702EA. I knew going into it that it would be low powered. That was what I wanted. Sadly I wasn't prepared for just how poor the performance was of the unit. At minimum I expect a laptop of the current generation, to be able to cope with a "standard" flash banner and scrolling the webpage. Sadly this wasn't the case under XP or any flavour of Linux (current versions of fedora, ubuntu and ubuntu netbook remix) or Solaris (nexenta and opensolaris) that I tried. Having used MBPs for the best part of 2 or so years, I fear that I've become somewhat spoilt.
Having decided to return the device I was faced with the prospect of returning it to factory defaults. Fairly simple with a normal laptop, but as this was a netbook, not so much. In the end I ended up cheating, resizing the partition back, using the XP Home safe mode to remove the users and data I'd added and using sysprep on the provided disk to reseal the Windows installation. Interestingly until now I wasn't aware that sysprep needs to run in Safe Mode with Networking in order to function. If you run without networking it states that the version of sysprep doesn't match the version of Windows.
So will I be joining the netbook revolution again? Given the cost of netbooks, no. The only reason I'd gone for the 702EA was because it was available for £200 from ebuyer. All other netbooks are too near the cost of a regular laptop and I can't jusify it, quite frankly.
The crunchpad still looks interesting though.
- Jul 09, 2009 by the_angry_angel
- Geek, Unix-like, Personal and Work
Initially I saw a few blog posts from Stuart Langridge about CouchDb on the desktop and I just thought:
- That's pretty cool, and
- Why? Because you can...?
Then I thought about it some more. It does make sense, and not just for us geeks.
Gary Fleming makes a comment asking why, when users don't care about this sort of thing, but I just think that's not true. I deal with regular users every day and although I'm still constantly baffled by things that they ask about, I honestly believe that people don't want to sync things like bookmarks, tomboy notes, etc. between computers because they think it's hard. And they're right, it can be a pain in the bum on the desktop.
For corporate environments some are aware that data replication and high availability is something that can be solved, but still even the users who know this aren't thinking about syncing personal data between multiple machines. Which is a shame. Perhaps it's the fault of us system administrators giving out the wrong vibes[1].
Despite this, there is proof that there is a market for these sorts of products. Just look at Windows Live Sync, MobileMe, UbuntuOne, FoxMarks and so on.
My point is that at the end of the day we need people like Stuart doing the cool things and using existing tools in new and exciting ways to show regular users that things like data replication aren't just a server-side thing; It's something that they really do want. They just don't know it yet.
To all of those working on these sorts of projects, I salute you[2]!
[1] Which goes to show why most (sys|net)admins make bad sales people, I suppose
[2] But you'll have a hard time ripping my beloved rsync scripts from me ;)
- Jun 28, 2009 by the_angry_angel
- Geek, Unix-like and Personal
Seeing things like the free Ksplice Uptrack service for Ubuntu, I'm really starting to wonder if I'm using the right distro, on servers. Debian is my current preference, and has been for quite a while.
Ksplice is a product/project I've been interested in for quite sometime, but I've always had a bit of a problem with the implementation. I try and keep on top of vulns for as many as the products that I support at work, and personally, but inevitably I do miss things. The Uptrack service seems to solve this, but as an individual I couldn't justify what I suspect is a non-trivial cost for my Debian boxes.
So, as Ubuntu is Debian based, and the Canonical server team seems to hold a lot of the same values as the Debian team and myself, am I still using the right distro for the times? More importantly, is Debian destined to be nothing more than "meta-distro"[1] in the future[2]?
[1] A distro from which other distros are built.
[2] Given the number of distros which now depend on Debian, and the size and number of skilled people who contribute it, I don't believe that Debian will be going away any time in the future, nor can I see it's usage as a standalone distro diminishing to 0, I can see it shrinking with time. Especially if we keep seeing free/low cost, integrated, collateral services.
- Jun 02, 2009 by the_angry_angel
- Geek, Unix-like, Personal and Projects
I've been using Apache longer and across more platforms, than almost any other single item of software. However, as I'm going through the process of moving server provider I thought that I'd give LigHTTPD (lighty) a go. After all it's an interesting bit of code that's gaining some use.
The main problem was, unsurprisingly, letting go of my Apache-isms. The configuration styles are radically different, and whilst I do like the LigHTTPD style something about it seems a bit... well messy. I expect the lighty hordes to blast me now, and I suppose thats sort of what I deserve. After all on initial inspection the lighty config is much shorter and arguably much more concise.
Or is it? Given the scripted-like nature of it's config you can acheive the same configuration in a number of different ways, some which appear (I've no solid numbers at all to back this up, it's all down to my perception for now) to have better performance than others.
I'll carry on with lighty for now on my personal server, and delve into how it all fits together. But after spending an evening with it, I'm not exactly sure that we've clicked.
- Apr 06, 2009 by the_angry_angel
- Geek, Unix-like and Personal
I've rambled on about Karmasphere in the past, but I've not actually done anything with it since mentioning it.
Sadly today was the day when spam started getting through my crazy system. This clearly was a signal from the gods themselves; to take the next step. The dreaded DNSBL. You might be surprised, but I don't like DNSBLs. In the past they've made my life hard at work - especially when we've inherited an IP that was previously used by spammers, in some way, shape or form. You see the thing is that some are actually on the ball and will check out and change their lists easily. Others won't. The problem is that maintaining your knowledge of the good 'uns and the bad 'uns is... well boring.
Karmasphere is supposed to take this hassle and make it easier; you can aggregate results from multiple sources, not just DNSBLs, and let Karmasphere decide for you. So if one or two don't keep up.. well that won't matter so much. In theory.
At the moment I'm adding headers to my mails and not rejecting, just to see how things fare, however in the future (assuming all goes well) I'd actually like to see this in real use. Perhaps even at work, in conjunction with our other spam filtering solutions.
So how did I do it (remember this is just logging, not actively rejecting)? Pretty easily, it must be said (I'm not going into detail);
- Installed the Karmasphere client:
perl -MCPAN -e 'install Mail::Karmasphere::Client' - Created an SysV init script to run the karmad server on startup:
#! /bin/sh
#
# Starts KarmaSphere Daemon
#
set -e
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
NAME=karmad-exim
DAEMON=/usr/local/bin/$NAME
DESC="KarmaSphere Daemon"
KUSR=INSERT YOUR USERNAME HERE
KPWD=INSERT YOUR PASSWORD HERE
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
case "$1" in
start)
echo -n "Starting $DESC: $NAME"
nohup $DAEMON --feedset=karmasphere.email-sender-ip --username=$KUSR --password=$KPWD --socketuser=Debian-exim 2>/dev/null 1>/dev/null &
echo "."
;;
stop)
echo "Stopping $DESC: $NAME."
killall -9 $NAME &> /dev/null
;;
restart)
echo "Restarting $DESC: $NAME."
$0 stop && sleep 1
$0 start
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart}" >&2
exit 1
;;
esac
exit 0(and then created the relevant symlinks using update-rc.d) - Created and added the following to /etc/exim4/conf.d/acl/10_karmad-exim (which is pretty much line for line what you can find on Karmasphere's website):
karma_rcpt_acl:
# Check envelope sender
warn set acl_m9 = ${readsocket{/tmp/karmad}\
{ip=$sender_host_address\nhelo=$sender_helo_name\
\nsender=$sender_address\n\n}{20s}{\n}{socket failure}}
# Continue quietly on socket error
accept condition = ${if eq{$acl_m9}{socket failure}{yes}{no}}
message = Cannot connect to karmad
# Prepare answer and get results
warn set acl_m9 = ${sg{$acl_m9}{\N=(.*)\n\N}{=\"\$1\" }}
set acl_m8 = ${extract{value}{$acl_m9}{$value}{unknown}}
set acl_m7 = ${extract{data}{$acl_m9}{$value}{}}
# Check for fail
# Once happy with testing, replace with deny & condition - or perhaps do filtering into Junk as part of ~/.forward?
warn message = X-Karma: $acl_m8: $acl_m7
accept
- Added the following to my CHECK_RCPT_LOCAL_ACL_FILE (one of the magic Debian macros for adding your own RCPT TO checks):
deny !acl = karma_rcpt_acl
If you're not aware of what's going on here, then I'd suggest reading the Debian Exim4 split config documentation, and also the Karmasphere docs - you could break your mail server.
What this will now do is mark all of my mails, if it can talk to karmad, with X-Karma: 0: Comment. The lower the number, the more likely it is to be spam. -1000 to 1000 is the range, with it defaulting to 0 for neutral/unknown.
The only thing that would need to be altered is to add my whitelisting acl, if I do go live with it, and to decide whether or not I do filtering in ~/.forward or during SMTP rejection.