On Sun, Dec 11, 2011 at 7:50 PM, <ray_at_aarden.us> wrote:
> I am specifically looking at the Xen hypervisor but it may have broader
> applicability.
>
> I am in a personal workstation environment using Xen as a hypervisor
> managing a half dozen guest operating systems. I am planning on one of
> those to be an Apache/SVN server. There will be a variety of
> repositories. I am considering how I may implement a repository to
> track the versioning of guest images. I would like to keep version
> histories of the different guests; experimental perturbations, upgrades,
> etc. I like the SVN version graph and I am wondering about how much I
> can add notes to clarify the differences. Additionally, update the
> notes when in retrospect, more information is needed for historical
> entries.
>
> Since the binaries are large, I will probably need to extend the storage
> to a slower, cheaper media for the older versions. I want to keep fast
> response for new entries. I am wondering how I might have the best of
> both worlds and still be able to pull up a full historical graph.
Do *NOT* attempt to store image binaries. Seriuosly. You're asking for
pain, since each image will be profoundly distinct from all the
others.
If you have to do something like this, arrange to use a backup sytem
that backups the *filesystems* to a secondary storage device, and you
can compare contents from that. If you feel the need, you can add some
wrappers to grab boot loaders and partition indices. But storing the
entire disk image is like putting the apple tree in your refrigerator
to make sure the apples stay fresh: it's an amazing expenditure in
resources.
> I plan to use SVN both locally and over the Internet for personal use
> only; I am looking for comments/cogestions on setting up for this
> service.
>
> I would really like to hear comments and suggestions on implementing
> Apache/SVN on such a hosted service and any about overall system
> configuration.
I profoundly dislike the Apache/SVN setup, and have said so before.
This is partly because it's another layer of access control complexity
that is orthogonal to the pre-commit or other built-in access
configuration. The other, and more powerful reason, is that Linux and
UNIX clients for Subversion store the passwords, by default, as
plain-text in a well-known location in your home directory. It's
possible to set up more clever password storage schemes, such as Gnome
or KDE "wallets", but they remain awkward and difficult to use for
unattended behavior such as nightly auto-build systems.
So wherever feasible, I use svn+ssh. I've also seen reports that
Kerberized access can work well, but that would require even more work
to set up and could make a working setup even more difficult to access
than users will tolerate.
Received on 2011-12-13 06:45:03 CET