>From: "Austin S. Hemmelgarn"
>To: xen-users@xxxxxxxxxxxxx
>Subject: Re: [Xen-users] Xen Configuration Management, SVN?
> 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.
Austin,
Thank you for the detailed responses.
etckeeper site does not list SVN as one of its VCSs. I should probably be learning git anyway.
The challenge I have is it only manages /etc. While that is an import config location, I regulary have problems in the user spaces under /home.
Do you know it there is a way to have it manage other directories?
Or, maybe I should not be configuring users instead of system wide. But the directions I follow from often direct configuration to the user space. All user are me. Sometimes I 'break a user' so I will add another to trouble shoot from rather than doing everything as root. So lately, I add a couple users so I can readily log on and start back to work. I am reluctant to alter directions that direct me to the user space to change to the system. If I break it, it would be more difficult to recover (I typically rebuild from scratch).
> > 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 like the idea of the management tool on one machine, the $5,000 price is more than the cost of both of my systems. The puppet and chef seem to be configuration control applications that constrain changes to user/admin defined properties. These are more than what I was looking for but they might also be able to perform the limited action I am looking for such record the system configuration state.
> >
> > 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.
While I use the GUI a lot, most of the actual configuration is through CLI. I like the idea of using the CLI history, but I haven't figured out how to do that effectively or efficiently. I am guessing there are probably grep and awk ways of doing this, I have not found one. Just now it seems like I could be tagging my CLI action with key words for searching. But I could image a GUI that would provide a method with less of a learning curve.
Ray
