Skip to content

Entries tagged "ipv6".

IPv6 email

26th February 2011

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

 

I'm now deploying IPv6

7th January 2011

I've now gotten around to deploying IPv6 for my personal site(s) and machines. So potentially people visiting this blog are using IPv6 right now!

The Debian Administration website has been IPv6-connected and aware for a year or two now, although over 98% of users continue to connect via by IPv4.

Handling IPv6 & KVM wasn't too difficult at least, although I've done the simplest possible thing I could do, route a /64 to each guest and don't worry too much about it.

(The host machine has a /64 allocation of its own, and we've been granted an /48 allocation so we're not liable to run out. Ever.)

ObQuote: "You're not seriously gonna believe this man, are you? Are you? HE ISN'T EVEN FROM 'ROUND HERE! " - Hot Fuzz

Tags: ipv6, kvm-hosting. | 3 comments.

 

I am lightened, can we drop this?

16th February 2010

As part of some house-keeping I've been checking over my systems and ensuring they're all tickity-boo for the past couple of days.

One thing that I'm getting increasingly tempted by is converting my kvm guest to a 64-bit system.

I've not quite sold myself on the prospect of what will be a fair amount of downtime, but I'm 90% there.

I do think that a lot of my setup needs an overhaul, for example:

  • Running all my websites under www-data is beginning to worry me.
  • Running services as root is beginning to make me more and more paranoid.

One possible plan is to wipe my system, and then restore data from backups. A perhaps saner approach is divide my guest into two smaller ones, and migrate services over one by one (e.g. website1, website2, .. websiteN, email, etc).

For the moment I've taken a complete dump of my existing guest, and I'm running it with an IP in the 10.0.0.0/24 range on my desktop. That's at least given me a clear idea of the amount of work involved.

I'm still a little unclear on how best to manage running N websites with the intention they'll each run under their own UID. I guess it comes down to having a few instances of nginx/lighttpd/apache and then proxy from *:80 to the actual back-end. Precisely which mixture of services to use is a little overwhelming. Though at some point soon I need to start enabling IPv6 support, and that changes things a little.

(Not least because nginx has no IPv6 support present in the Lenny release - I've got a backported package which I run on the Debian Administration website.)

It's possible I could hack mod_vhost_alias to redirect/proxy to a local port based upon the virtual hostname present in the request - that's pretty trivial and I've already done something similar for work purposes. Though something like that should presumably already exist? I would expect a map of some form:

example.org: 127.0.0.1:8080
example.net: 127.0.0.1:9090

That has to be about the minimum necessary information to make the decision; a pair of vhost name & local destination.

/me googles some..

Update

OK quick update I've added local users for some of my sites, and now have them running under thttpd.

skx:/etc/thttpd# ls -ltr /home/www/ | tail -n 4
drwxr-sr-x  4 s-static   s-static   4096 Jan 15 01:41 static.steve.org.uk
drwxr-sr-x  5 s-openid   s-openid   4096 Feb 16 21:31 openid.steve.org.uk
drwxr-sr-x  6 s-images   s-images   4096 Feb 16 21:52 images.steve.org.uk
drwxr-sr-x  5 s-packages s-packages 4096 Feb 16 22:03 packages.steve.org.uk

That seems to work well, with a small wrapper script to start N instances of thttpd instead of a single one. Minor issues are that I'm using mod_proxy to forward requests to the thtpd instances running upon the loopback - and it was initially logging 127.0.0.1 as the source IP. A quick patch later all is well.

I'll leave it running a couple of the simple sites for the next few days and see if it kills children. If it does I'll convert the rest.

Probably will aim to have nginx in front of thttpd, instead of Apache, but this way I don't have to worry about mod_rewrite rules just yet.

ObFilm: Cruel Intentions

Tags: amd64, apache, arch, i386, ipv6, lenny, lighttpd, nginx. | 11 comments.