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

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

On 2015-12-11 19:23, Ray wrote:
>  >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).
Git isn't generally too hard to learn if you have experience with other 
VCS software.  There are some different semantics in some cases, but 
most of the basic stuff is pretty much the same.  If you're doing 
individual users, you might consider just making the home directories 
VCS repositories as well.  I know a number of people who just have their 
home directory set up as a git repository, and then use the gitignore 
file to block off stuff like their Downloads directory, and any stuff 
that's in it's own repository already.
>  > > 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.
I think what you saw was the price for Ansible Tower, which is their web 
based management tool, or possibly one of their support contracts. 
Ansible itself is completely free (or at least, it had better be, 
they've got it under an FSF approved license).  In the case of Ansible 
at least (not 100% sure about Puppet and Chef), part of the idea is that 
you tell it how you want the systems to look, and it handles the 
details.  Stuff like only copying over a config file if it's newer on 
the source system is trivial to do.
>  > >
>  > > 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.
Most shells have an option that will let you run an arbitrary command 
before it displays a prompt.  Usually this is done through some 
environment variable (although I don't remember what it's called on any 
of them).  My suggestion would be to use that to just copy the history 
file somewhere, or add something to your logout script to do so.  I 
hadn't really meant to do any kind of parsing of it directly, just a 
simple copy.
As far as the GUI aspect, you may be able to find some screen recording 
software to keep track of that, but again, I don't really have much in 
the way of suggestions here.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users