|
> 3. Re: Xen Configuration Management, SVN? (Austin S. Hemmelgarn)
> 4. Re: xen 4.6 & dom0pvh (Roger Pau Monn?)
> 5. Re: xen 4.6 & dom0pvh (?li?s Tam?s)
> Message: 3
> > > > 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.
Yes, that sounds great. It would seem that etckeeper will manage the /etc config files and then the user spaces could be managed manually. Is that correct?
> > > > 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.
Ansible Tower is the only product listed on their website.
But, Debian shows it to be a package. Originally started in 2012, it has updates in 2015.
> >
> > > >
> > > > 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.
Yes, I like that idea.
Thanks for your time.
Ray
|
