Entries tagged stretch

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-backports contains 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, and stretch, each in i386 and amd64 flavours.
• 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: nginx proxies to a java application which runs on localhost: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.steve host, 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:

borg@rsync.io ~ $ borg init /backups/git.steve.org.uk.borg/
borg@rsync.io ~ $ borg init /backups/master.steve.org.uk.borg/
borg@rsync.io ~ $ ..

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.

Tags: backups, debian, stretch | 1 comment