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

["Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>]

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
> time/dates.
>
> 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).
> Background:
> 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
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users