I run about 17 servers. Of those about six are very personal and the rest are a small cluster which are used for a single website. (Partly because the code is old and in some ways a bit badly designed, partly because "clustering!", "high availability!", "learning!", "fun!" - seriously I had a lot of fun putting together a fault-tolerant deployment with haproxy, ucarp, etc, etc. If I were paying for it the site would be both retired and static!)
I've started the process of upgrading to stretch by picking a bunch of hosts that do things I could live without for a few days - in case there were big problems, or I needed to restore from backups.
So far I've upgraded:
master.steve- This is a puppet-master, so while it is important killing it wouldn't be too bad - after all my nodes are currently setup properly, right?
- Upgrading this host changed the puppet-server from 3.x to 4.x.
- That meant I had to upgrade all my client-systems, because puppet 3.x won't talk to a 4.x master.
- Happily
jessie-backportscontains a recent puppet-client. - It also meant I had to rework a lot of my recipes, in small ways.
builder.steve- This is a host I use to build packages upon, via
pbuilder. - I have chroots setup for
wheezy,jessie, andstretch, each in i386 and amd64 flavours.
- This is a host I use to build packages upon, via
git.steve- This is a host which stores my git-repositories, via gitbucket.
- While it is an important host in terms of functionality, the software it needs is very basic:
nginxproxies to a java application which runs onlocalhost:XXXX, with some caching magic happening to deal with abusive clients. - I do keep considering using
gitlab, because I like its runners, etc. But that is pretty resource intensive. - On the other hand If I did switch I could drop my
builder.stevehost, which might mean I'd come out ahead in terms of used resources.
leave.steve- Torrent-box.
- Upgrading was painless, I only run
rtorrent, and a simple object storage system of my own devising.
All upgrades were painless, with only one real surprise - the attic-backup software was removed from Debian.
Although I do intend to retry using Larss' excellent obnum in the near future pragmatically I wanted to stick with what I'm familiar with. Borg backup is a fork of attic I've been aware of for a long time, but I never quite had a reason to try it out. Setting it up pretty much just meant editing my backup-script:
s/attic/borg/g
Once I did that, and created some new destinations all was good:
[email protected] ~ $ borg init /backups/git.steve.org.uk.borg/
[email protected] ~ $ borg init /backups/master.steve.org.uk.borg/
[email protected] ~ $ ..
Upgrading other hosts, for example my website(s), and my email-box, will be more complex and fiddly. On that basis they will definitely wait for the formal stretch release.
But having a couple of hosts running the frozen distribution is good for testing, and to let me see what is new.