Entries tagged ipv6

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

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'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 enjoy the tilde.club site/community, and since I've just setup an IPv6-only host I was looking to do something similar.

Unfortunately my (working) code to clone github repositories into per-user directories fails - because github isn't accessible over IPv6.

That's a shame.

Oddly enough chromium, the browser packaged for wheezy, doesn't want to display IPv6-only websites either. For example this site fail to load http://ipv6.steve.org.uk/.

In the meantime I've got a server setup which is only accessible over IPv6 and I'm a little smug. (http://ipv6.website/).

(Yes it is true that I've used all the IPv4 addreses allocated to my VLAN. That's just a coincidence. Ssh!)

Tags: github, ipv6 | 6 comments

I recently setup a bunch of IPv6-only accessible hosts, which I mentioned in my previous blog post.

In the end I got them talking to the IPv4/legacy world via the installation of an OpenVPN server - they connect over IPv6 get a private 10.0.0.0/24 IP address, and that is masqueraded via the OpenVPN-gateway.

But the other thing I've been planning recently is how to configure my next desktop system. I generally do all development, surfing, etc, on one desktop system. I use virtual desktops to organize things, and I have a simple scripting utility to juggle windows around into the correct virtual-desktop as they're launched.

Planning a replacement desktop means installing a fresh desktop, then getting all the software working again. These days I'd probably use docker images to do development within, along with a few virtual machines (such as the pbuilder host I used to release all my Debian packages).

But there are still niggles. I'd like to keep the base system lean, with few packages, but you can't run xine remotely, similarly I need mpd/sonata for listening to music, emacs for local stuff, etc, etc.

In short there is always the tendency to install yet-another package, service, or application on the desktop, which makes migration a pain.

I'm not sure I could easily avoid that, but it is worth thinking about. I guess I could configure a puppet/slaughter/cfengine host and use that to install the desktop - but I've always done desktops "manually" and servers "magically" so it's a bit of a change in thinking.

Tags: debian, desktops, development, ipv6 | 2 comments