theangryangel.co.uk

Until a few weeks ago my personal server was with a "little" company called UK2.net. After the monthly prices got hiked again for a 3 year old Pentium D box, I decided that it was time to move on.

The move went fine, and all was good; no further billing from UK2. Yet I still have access to the box. Now I'm not sure if I should be telling them how to do their job, but it does seem a bit insecure allowing access to something not being paid for. If I was a less honest person it could be quite a fun machine (answers on a postcard).

Naturally I had wiped all of my content, accounts, and effectively removed all additional packages that I'd installed, so perhaps they could've confused it with a clean system. However, this just isn't the case as the root and other account details were reset to something produced by pwgen.

I would like to say that I'm being unreasonable, but knowing the procedures that we take care of for even our smallest clients at work, I know that I'm not. As a generalisation people are not trustworthy and you cannot guarantee that once they leave they will not attempt to regain access, and potentially damage, a system.

If you've not got a working procedure for departing staff, customers, or equipment then I suggest you make one and stick to it religiously, ensuring that all departments are aware of what they need to communicate and when.

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.

It seems that I've only ever hinted to my current host naming scheme, and that was all the way back in 2007.

If you're not familiar with the concept of hostnames (for those non-techies out there), then a hostname is exactly what it sounds like. How we refer to a specific device on the network. You'll see lots of different schemes and there's not really a right or a wrong way of doing it in my opinion. It very much matters on your circumstances.

It was reading Geoff's post on hostnames that brought this up and made me smile for two reasons:

1. We both use a very similar scheme (elements from the periodic table)
2. He's got an extended scheme which helps him classify a host, based on the name.

Whilst I applaud the naming convention (mostly because I use it) and the shortening factor (which until now I really hadn't considered), I do wonder about the IP assignment. If you've not read the article it boils down to Geoff using the element's atomic number to define the host part of the IP address. For small networks assigning IPs in some sort of arrangement like this is fine. Especially in the context of a personal one. It's fun and easy to remember if you've got a periodic table handy. Or you just happen to be a complete element nut, know it off the top of your head.

But in the real world, it all seems a bit dirty. I've heard of all sorts of schemes that people use internally - from the host portion of IP addresses relating to rack and position within that rack, to using an entire /16 and arranging the addressing based on the role, with massive gaps between the assigned addresses. As nice as it seems on first glance, it can become painful when expanding. There are obvious benefits of splitting your address space - Geoff Huston has a great article on it - but it strikes me that you need to be careful that you don't take it a little bit too far. After all, who really enjoys renumbering a network?

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.

Ok so I'm quite late to the game on this one. In order to maximize my enjoyment of the film I'd gone out of my way of consuming anything about this film other than the trailers, and from these I wasn't holding out much hope; It seemed to be more action than Trek. Having come from a Trekkie family and being a Trekkie I must say that I wasn't disappointed, much to my surprise.

If you've not seen the film, then now is the time to stop reading as I might spoil a few things (I'm trying hard not to). But still; Go and see it and then come back.

The writers clearly knew what they were doing. In a single piece of epic comic-book-esque retconning they managed to breathe new life into the Trek franchise. One of the few things I'd heard about the film was the time travel. I had a few issues with that - it was badly done in Enterprise's Temporal Wars, and badly done in earlier series - effectively ending with a Dalas style "it was all a dream" (yes I'm looking at you Voyager writers especially). I'll conceed that there are a few issues, like all the characters we know and love just who happen to be on the Enterprise by the end of the film. However, it provided a fantastic platform that can now sustain the franchise for quite some time.

If you're a hardcore TNG fan then I can see the new Trek film being a bit of a let down (in terms of the apparent lack of meaningless over-the-top and unneccessary pseudo-technical babble), but I do feel that it was the right way to go. It was an exciting film and I didnt get bored or feel like it should hurry up and finish. If you've ever watched the original series then you'll have seen the nods. The characters were spot on in a lot of cases, which is precisely why it all worked. If you're going to alter the timeline, then alter as little else as possible so that it's less of a jarring experience. Karl Urban plays a brilliant Bones, which beside Zachary Quinto's Spock (which was equally as good) I feel may become, sadly, underrated. I think I'll reserve judgement for Simon Pegg's Scotty until the character progresses further.

All in all, I hope there's another film. I can't see the updated universe working on the small screen - yet. If you've still not seen it then I hope you do before it leaves the big screen. It's definitely worth it.

Today I was chastised by (whom I believe was the real) Brandon Butterworth, via email. He picked me up for not stripping out a couple of headers being sent out, on my personal email. On one hand that's pretty cool that he would take the time, but I also feel like such a noob :(

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);

1. Installed the Karmasphere client:perl -MCPAN -e 'install Mail::Karmasphere::Client'
2. 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)
3. 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

4. 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.

We use HyperV a lot at work, and for small scale Windows Server platform deployments I actually quite like it as our chosen virtualisation tech. However, backing up any virtual machine, regardless of platform, can be "fun" sometimes. We actually use a script that I put together using diskshadow (VSS) and a set of batch scripts, which works really well. However I hadn't actually really put much thought into what was happening and although I've done test restores for Windows machine I'm yet to do one for a *ix box.

How exactly does the virtual machine get to a state where it knows that it's being backed up? After all the last thing you want is a restore and the VM to believe it's the time when the backup occured (which would leave it in an inconsistant/messy state).

I went looking and came across a video from TechNet which, about half way through, has a high level technical explanation of what happens when you use VSS to backup VMs, and what happens when the guest OS isn't VSS aware. Certainly interesting and potentially worrying stuff.

We've got a few customers at work, including ourselves, who use Windows Server 2008. But only one was experiencing this problem. A "good" (i.e. quick) workaround was simply clearing the DNS cache. However, it was obviously not a decent solution.

After more investigation it looked like it only affects servers using root hints, in some form. If a server was using recursive queries more, then the problem wouldn't reoccur as often. As it was only happening every few weeks we didn't look into it too much. But, after quite some time since we came across it and finally resorting to periodically casting an eye over technet's blogs it looks like setting the DNS Max TTL to 2 days or so stops the problem from occuring (nice...).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\MaxCacheTtl=dword:2A300

I've got a bit of a love-hate relationship with Powershell, but in this case it's turned into a bit of love. Importing users with Powershell is relatively easy to do when combined with ActiveRoles Management Shell for Active Directory, from Quest, which adds a handful of rather useful functions. PSCX supposedly has something similar, but I'm obviously missing them completely.

1. Get someone to provide a spreadsheet with all users that they want for their new install (or export from an existing AD using CSVDE)
2. Fiddle with the file, remove any crap you don't want, add anything you might, and convert to a CSV. For a new install we tend to set the inital password to something based around the user's name (which you can automate creating with an Excel formula). My finished format is something like this: givenname,middlename,surname,company,displayname,samaccountname,password
3. Install Quest's ARM, and fire up the shell that it adds in your start menu
4. Now it's simply a case of running the following, replacing my.domain/Path/To/OU/Users with your actual domain and the path to where you want the users placed (you can, obviously, make this part of the CSV, if you want)import-csv C:\Path\To\Users.csv | foreach-object {
New-QADUser -FirstName $_.givenname `
-LastName $_.surname `
-SamAccountName $_.samaccountname `
-ParentContainer my.domain/Path/To/OU/Users `
-displayname $_.displayname `
-name $_.displayname `
| `
Set-QADUser -UserPassword $_.password | Enable-QADUser
}

5. Grab yourself a cuppa, or a beer, and tell the boss that you've been slaving all night (optional, of course)

Just to add an SBS 2008 twist to it, if you create your users in this manner you'll find that they show up in Active Directory Users and Computers, but not the SBS Console. The reason for this a special attribute on the object which doesn't get set. There's a nice article over at the SBS Blog which explains it for groups, but it's also applicable for users.

What it doesn't tell you is that for users, you can simply head into the SBS Console > Users, run the Change User Role for Accounts wizard, select Standard User, select your users (you'll need to select the checkbox to show all users), and then let it do it's magic. It'll setup your users Exchange mailboxes and shared folders in a jiffy.

By default Windows SBS 2008 has 2 shares setup - RedirectedFolders and UserShares, along with the various bits and bobs in the group policy to get it to work. Sadly they've placed the actual directories in the root of C:\. I don't like that. I'm fussy about file placement and it would be nice to move it to where we usually have the files (and have done since SBS 2000); D:\Data\..., which brings things into line with our standard setup that we tend to use at work.

Now you can just simply de-share the original directories, and move them to whereever you want. However this has the downside of causing issues (recreating the folders) if you create user accounts with the SBS 2008 console (since it also creates the various redirected folders for the user, and I know that several of our customers will be using this console).

Luckily there is provision to move these folders to another location. If you use the console you'll see that you can simply move it from drive to drive. However, if you delve into the registry you can see that 2 magic keys get created, which if you manually alter allows you to effectively place the directories where ever you like.

If you browse to
HLKM\SOFTWARE\Microsoft\SmallBusinessServer\Storage
You'll find that the following entries will either exist, or need to be created -
SharedRootPath
SharedRootName
FRRootPath
FRShareName


*RootPath specifies the location for the user shared and redirected folders, where as the *ShareName specify the actual name of the shares themselves. Handy.

Being the good little customer that I am, I tend to try and keep an eye on what upstream are doing. To that end I've been keeping an eye on VPS.net; UK2.net's newest business venture. I'm one of the lucky 80 or so that have gotten into the beta, and I've got to say, I'm really impressed with what the guys have put together so far.

Basically what they're providing is a fault tolerant, brilliantly easy to use virtual server infrastructure, based on Linux and Xen. Unlike most other (more traditional) VPS providers you simply don't buy a VPS and then manage it, you actually buy "nodes" or "slices" (they're actually refered to as both terms in the web interface at present), which you then assign to various virtual servers in any fashion you want, with the ability to reassign at a later date should things change.

There are a few cool things about the whole setup:

1. It's delightfully quick
2. It's absolutely fanastically easy to use
3. You can get console access direct through the web interface, along with all the other bits and bobs that you may need
4. You have the option for live backups and restores - very nice, very quick considering its all LVM, and makes reverting any stupid changes very easy (such as rm -rf'ing your root partition)

I'd love to see how things fare as the product launches, and it gets busier, but so far I'd be pretty happy to convert my physical server to a virtual VPS.net instance, should the circumstances arise.

coolepochcountdown.com says it all really. I think I might party myself silly and persuade my non-geeky housemates to partake.

What will you be doing?

Does the world really need multiple tutorials and howtos, where the only difference is that the title says it affects different distros? Especially when those distros are closely related?

Specifically the one that set me off was seeing yet another PowerDNS item appear in the HowToForge feed. Thinking that bloglines was having trouble I went off to have a look, but sure enough there are at least 3 guides. One for Debian Etch, one for Ubuntu 8.10 (Intrepid) and one for CentOS 5.2. Now I can sort of understand the one for CentOS to a point. HowToForge is potentially for a market that doesn't know that their package manager is yum, or apt (although if you're trying to setup a DNS server, I might dispute that you're not ready if you don't know this), or where that specific distro puts various config files. On that front its very useful not to clutter one big howto with lots of "and", "or"'s.

However, Debian and Ubuntu are pretty closely related, and from a quick scan I honestly can't see the difference between the instructions other than the title. Granted I don't know the back end behind HowToForge, or it's policies, but surely it's possible to assign something to multiple distros?

I'm not specifically having a go at the person writing these documents, and this is why I've not linked to the articles. These people do an exceptionally important job, one of which is largely thankless.

So I'd like to say thank you to all the documentation writers. But may you could make your lives a little easier?

Hoorah, and oh knackers.

jQuery 1.3 is out, but I've nearly finished a relatively long project at work involving jQuery (in part). I was kinda hoping to get back to hardcore sysadmin'ing, but I fear this may drag me back to development for a little bit, due to both inspiration and a few little bug fixes.