Entries posted in February 2011

So previously I talked about pictures. Having spent a while playing with some new lighting ideas I'll present three recent images:

• Two empty glasses.
• Two full glasses.
• My drink is on fire.

Now that's out of the way lets talk software. There are two specific things I think would be useful to me right now:

Opportunistic "cron"

I've got a few jobs that don't take long to run, and I schedule for once a day when my systems are idle.

It'd be nice to have some long-running daemon which could trigger these odd-jobs (which do things like update my list of mutt mailboxes) when the system has been idle for >30 minutes, or some similar criterion.

Ideally I'd say "Run this job when the system is idle, but if the system is never idle run it once a day, or once an hour regardless".

Content-aware tracking software

I use rsync to archive images across a number of systems.

Imagine I rename a few images locally, I have to re-rsync even though ideally all I need to do is rename the contents remotely. The issue is remembering what I've changed.

So given:

~/Images/Stolen-Souls/2011.02/
~/Images/Stolen-Souls/2011.02/02-Borcsa
~/Images/Stolen-Souls/2011.02/02-Camilla
~/Images/Stolen-Souls/2011.02/06-Indigo
~/Images/Stolen-Souls/2011.02/07-Rosa

If I rename "06-Indigo" then it's trivial to ssh to the remote host and do the same job. But what if I rename a bunch of individual files?

Ideally I'd be able to run something like:

~$ tool --snapshot ~/Images/
~$ mv Images/old.jpg Images/new.jpg
~$ tool --show-changes ~/Images
mv Images/old.jpg Images/new.jpg

I half believe git can do something like this, but it seems like you should be able to index the filename+SHA1+size to ~/.snapshot, then later do the same thing and output a list of "mv" commands.

Anyway; I'm drunk. I'm probably not making sense, and I need to sleep. Goodnight.

ObQuote: "Hello Mr. Svenning how have you been?" - Mallrats

Tags: software which should exist, stolen-souls | 13 comments

Rather than waiting for a few months, as I typically do, I decided to be brave and upgrade my main virtual machine from Lenny to Squeeze. That host runs QPSMTPD, Apache, thttpd, and my blogspam server; nothing too complex or atypical.

The upgrade was mostly painless; I was interrupted several times by debconf asking me if I wished to replace configuration files I'd modified, but otherwise there were only two significant messages in the process:

crm114

crm114 warned me that its spam database and/or configuration files had changed and would most likely result in brokenness, post-upgrade, and I should do something to stop avoiding lost mail.

Happily this was expected.

sysv-rc

It transpired I had a couple of local init scripts which didn't have dependency information succesfully encoded into them; so I couldn't migrate to dependency-based bootup.

Given that this server gets a reboot maybe once every six months that wasn't really worth telling me about; but nevermind. No harm done.

That aside there were no major surprises; all services seemed to start normally and my use of locally-compiled backports meant that custom services largely upgraded in a clean fashion. The only exception was my patched copy of mutt which was replaced unexpectedly. That meant my lovely mutt-sidebar was horribly full of mailboxes, rather than showing only new messages. I created a hasty backported mutt package for Squeeze and made it available. (This patch a) enables the side-bar, and b) allows you to toggle between the display of all mailboxes and those with only new mail in them. It is buggy if you're using IMAP; but works for me. I would not choose to live without it.)

Now that I've had a quick scan over the machine the only other significant change was an upgrade of the mercurial revision control system, the updated templates broke my custom look & feel and also required some Apache mod_rewrite updates to allow simple clones via HTTP. (e.g. "hg clone http://asql.repository.steve.org.uk/").

So in conclusion:

• The upgrade from Lenny to Squeeze (i386) worked well.
• Before you begin running "iptables -I INPUT -p tcp --dport 25 -j REJECT" will avoid some potential surprises
  • There are probably other services worth neutering, but I tend to only do this for SMTP.
• Keeping notes of updated template files will be useful if you make such system-wide changes. (e.g. hgwebdir templates)

ObQuote - "Hmm, upgrades " - The Matrix Reloaded (shudder).

Tags: debian, lenny, mutt, squeeze | 2 comments

Some projects have historically sucked; they've been incomplete, they've been hard to use, they've had poor documentation, or they've had regular security issues.

Over time projects that started off a little poorly can, and often do, improve. But their reputation is usually a long time in improving.

For me? Personally? PHPMyAdmin is a security nightmare. So while it is nice to read about it gaining the ability to be themed, and even receiving submissiosn from users (a rare thing for projects to receive such external contributions) I just find it hard to care.

I see PHPMyAdmin written in a blog, in a news article, or on a users machine and I just think :

• "PHPMyAdmin? That's that thing that has security problems."

Harsh. Unfair. Possibly no longer true. But I do tend to stick to such judgements, and I'm sure I'm not alone.

Ideally people wouldn't be dogmatic, would be open-minded about re-evaluation situations. In practise I'm probably not such a unique little snowflake, and there are probably a great many people to this day who maintain views which that are based on historical situations than the current-day reality:

• Java is slow and verbose.
• Perl is line-noise.
• Sendmail is an insecure mess.
• ...

Anyway. PHPMyAdmin? I'm sorry for singling you out, even with your fancy themes, language translations, and other modern updates. It's just a name that conjours deamons for me. Though I'm sure there are a great number of people who love it to pieces.

ObQuote: "You don't want to know my name. I don't want to know your name. " - Spartacus

Tags: phpmyadmin, security | 7 comments

One of the reasons I like Scotland is the fun that Scottish people have with language. I'm going to use two examples to illustrate my point:

• "Mind" is often used as "Remember"
• "How" is often used as "why".

The last one is particularly fun when you use questions such as "How no?" - meaning roughly "Why not?".

Languages, and idioms, vary wildly in different parts of the world, even when you restrict yourself to English-speaking languages. I'll not even get started on Accents. The UK is tiny compared to many other countries, yet we have a wide array of accents - Australia, by contrast is huge, but I can think of only two accents across the country. (Rationally I expect that there are many accents in different parts of Australia, and I'm merely ignorant.)

In conclusion languages are fun, and some places this is more evident than in others. I will most likely contintue to say "The shop is open from 9 while 4" rather than the more typical "From 9 til 4" - I'm allowed to do that, having grown up in Yorkshire!

(PS. PHP still sucks - Even if you post it upon a PHP-powered blog. ;)

ObQuote: "People take you for granted, you know. We gotta make people miss you." - Hancock

Tags: edinburgh, languages, misc, random | 3 comments

I've been slowly moving towards full IPv6 usage on my main machines for the past few months. My main servers all have IPv6 setup and appropriate DNS records in place.

This weekend I configured my mailserver, which is based upon QPSMTPD & exim4, to be available on IPv6 too. Previously it would send mail via IPv6 where appropriate, but only receive mail via IPv4.

QPSMTPD I've written about a lot in the past, and indeed I did commercial things with it for a year or two, but in short it is more of an SMTP framework than an actual mailserver.

These days I use a small collection of plugins which test incoming mail in various ways, and either:

• Reject the mail at SMTP time, causing a bounce, and store a copy of the rejected mail in a quarantine.
• Accept the mail, and pass it on to exim4 for (local) delivery.

My plugins are pretty simple, but I've made a few changes for the brave new IPv6 world:

• Breakdown reverse-DNS checks into IPv4 & IPv6 flavours.
• Avoid using DNSBL for IPv6 addresses.

I reject (+ archive) about 8,000 SPAM messages a day. So far I've seen precisely zero SPAM mails be received via IPv6; though I'm sure that won't last for long!

My reject archive looks like this:

steve@steve:~$ tree -d -L 2 /spam/
/spam/
|-- 23
|   |-- debian-administration.org
|   |-- mail-scanning.com
|   `-- steve.org.uk
|-- 24
|   |-- debian-administration.org
|   `-- steve.org.uk
|-- 25
|   |-- debian-administration.org
|   |-- mail-scanning.com
|   `-- steve.org.uk
...
|-- 55
|   |-- debian-administration.org
|   |-- mail-scanning.com
|   |-- steve.org.uk
|   `-- stolen-souls.com
|-- 56
|   |-- debian-administration.org
|   |-- steve.org.uk
|   `-- stolen-souls.com
|-- today -> /spam/56
`-- yesterday -> /spam/55

(Here "N" is the day of the year - Think of this as "date +%j". I rotate such that I keep 32 days of past SPAM mail, for reference/amusement/mistake-catching.)

ObQuote: "I am already grown up, I just get older. " - Leon

Tags: ipv6, ms-lite, spam | No comments