[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen Configuration Management, SVN?

  • To: xen-users@xxxxxxxxxxxxx
  • From: "Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>
  • Date: Fri, 11 Dec 2015 08:38:07 -0500
  • Delivery-date: Fri, 11 Dec 2015 13:39:45 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

On 2015-12-11 07:47, Ray wrote:
As I regularly break the OSs I work on, I would like to be able to more
systematically plan, assess, modify and recover my system(s).  I would
like to keep track of changes that I make to the system and have a
straight forward method to roll back any one or group of configuration
files and see the change versions of binaries.

It would seem there should be a way to do this with SVN.  But I don't
see how to set up an architecture/tool stack.

The goals would include:

1) Track the Xen installation.

2) Track the dom0 installation.

3) Track and catalogue each domU.

The requirements would seem to include:

1) Identify configuration files changes that occurred between any two

2) Compare the differences of each of those files.

3) Facilitate roll back of any one file or more files.
My personal suggestion would be to use something like etckeeper (https://etckeeper.branchable.com). It was designed for Git, but it does support other VCS software (not sure if it has support for SVN or not, but it would surprise me if it doesn't). That will simplify the usage of version control for system configuration (one of the really nice things is that it has hooks to integrate with the package manger, so that when you install a package, the included config files get committed to the VCS automatically). The other option if you are willing to take the time to set it up would be to use BTRFS and ZFS and do regular snapshots of your system, but that takes more effort to set up, and doesn't allow you to easily annotate the changes. For the installation tracking, you'll need some further tools (see comments below about Ansible), and probably have to do something with xenstore.

With these capabilities, it would be valuable to use the results to
define a recovery plan and associated test/validation plan, plan
execution tracking and results/performance recording.  This might use
something like Trac.
I can't really give much advice on what to use here for planning, but as far as recovery goes, keep the following in mind: 1. Test your backups. The last thing that you want is to find out when you actually need them that they won't work. 2. Simple is usually the best option. The more complicated something is, the more ways it can fail, and usually the harder it is to fix when it does fail. 3. Use something that's relatively portable for your backup format. The top two options here are a compressed tar archive, and a zip archive. Portability means that you don't need a special setup to get files out of your backup, which can be very important in a recovery situation.

One of the challenges I see is to build this, I do not want to disrupt
my dom0.  So it would seem to be appropriate to somehow build a system
to do this as a vm and either run it as a vm or a docker.  But I don't
know what the coordination issues are for the development vm to access
the Xen and dom space.
My suggestion here would be to look into something like Ansible (http://www.ansible.com). It's designed for large scale management of lots of systems, but works very well for small scale stuff as well. The big advantage of Ansible over similar software like Puppet or Chef is that you only need Python and SSH on the systems you're managing, and only need to install Ansible itself on the system you're doing the management from. I use it myself for managing many of my systems, and it's worked very well for my usage (about a dozen VM's, the host system, and a handful of other non-virtualized systems, although I run it from dom0 instead of a dedicated VM, because then I only have to log into one system instead of logging into dom0 to log into a domU to manage things).

I have installed Jessie on the target desktop which I will use as a work
station for both local and remote access from a laptop which I have also
installed Jessie and Xen.  Being new to Linux, every step I take is an
experiment and some of the steps fail and through the help of others
online, I eventually recover.  But this means my dom0 is probably full
of things that are no longer used, or poorly patched.  I have rebuilt
both of these system from scratch 6 to 8 times due to unrecoverable
errors.  I have defaulted to rebuilding rather than a recovery disk because:
I have not figured out how to build and use a recovery disk (especially
on the laptop with no removable drive but with USB ports).
I have accepted this failing as I learn a lot through repetition.
If your new to Linux, my suggestion would be to use some pre-built recovery solution like SystemRescueCD (http://sysresccd.org) (it started as a CD-ROM image, but it's useable a number of different ways including USB drives and even network booting). It's Gentoo based instead of Debian based, so some of the commands might be different from what you're used to, but it's one of the best free system recovery tools out there.

If I had a method to record all these activities, I am sure I would
learn better.  I have all sorts of notes that I keep online so system
failures won't disrupt my records. But my records are not organized very
well as I started without a clear understanding of where I was going.
If you're doing most of this from the command line, you could regularly save copies of your shell's command history. I don't really have any suggestions for GUI usage, as most of my management activities are done solely from the command line.

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.