Re: Debian private repositories
Steven Williamson <steven43126@gmail.com> writes:
> I'd be personally interested in hearing how you handle distribution
> upgrades.
In the repositories, when a new stable version is released, we do
basically the same thing that Debian does:
1. Update the distributions file to no longer pull everything into the
previously testing, now stable distribution and switch it over to
the pull-stable rule.
2. Change the now-oldstable distribution over to the pull-oldstable rule.
3. Change the suite configuration in the distributions file to move the
stable and oldstable names.
4. Create a new distribution for the new testing, configure it with the
everything pull rule, and then do a reprepro pull to populate it from
unstable.
It's pretty trivial on the repository side. Most of the work is usually
in FAI to set it up to start building the new distribution (since we only
do FAI configurations for stable and oldstable and don't try to track
testing in FAI) and in Puppet for changes in configuration files or in
package names. We've started maintaining a Puppet configuration for the
current testing distribution and running that on a few dev systems so that
there's less work to do when it becomes the new stable.
For systems, our gold standard is that we don't do upgrades and instead
rebuild the system from scratch using FAI when we move it to the new
stable. We prefer that over doing a dist-upgrade because it ensures that
any old cruft on the system is cleared out, it tests our build system and
ensures that we've captured the complete system model in Puppet, and
removes any temporary changes or package installs and gives us a clean
slate. It also ensures that we know how the backups work and where all
the data is that has to be preserved.
It's somewhat more work in that we have to build a new system and then cut
things over to it, but it's usually not a huge hassle. And, of course, if
we're doing hardware replacement and the system isn't a VM, we have to do
this anyway, so it ensures that it's not a huge deal to do hardware
replacement (because we've been testing a clean rebuild periodically
anyway).
Incidentally, I'm personally a strong advocate of this sort of model of
system administration: if there's something that you want to ensure is
working properly, ensure that you use it regularly as part of your
standard processes. If you want to be sure your data backups work, do
periodic clean rebuilds of your systems and then restore the data that
needs to be preserved from the backups. If you want to know that the
system is modeled in Puppet properly, wipe it and rebuild it from scratch
using Puppet and make sure it works. If you want all of your team to know
how to make Debian packages, require that any script deployed on a system
be deployed via a Debian package, which forces them to use those skills
regularly. As much as possible, you want to build your cross-training,
disaster recovery and business continuity processes into your day-to-day
work, rather than having them be a side system that you set up and then
never use.
That said, sometimes we do dist-upgrades instead. For that, we don't
really do anything particularly special, just the normal Debian upgrade
process. Since we try to maintain our local repositories using the same
structure and versioning that Debian uses, unstable should have a newer
or equal version from stable, etc. This is the point where we do a sanity
check, though, and look in reprepro for the packages that system uses and
ensure that the versions are what we expect in the new distribution.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: