From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Fri 15 Oct 2004 - 20:36:13 BST
> > Anyways, the general principle here is being able to commoditize the
> > server, while retaining the flexibility to be able to configure and and
> > patch systems as needed. Which is basically what I'm trying to do with
> > StrongBox <plug,plug> ;)
>
> Do you have a link to go with the plug?
Sure: http://www.strongboxlinux.com. I've just put up a beta iso image
there. The site is going to have a serious facelift over the next week,
and a lot more information put on it... but, you can link to the beta
there, and try it out.
> I still have one problem with your scenario - time. Over the years,
> the overlay will basically contain the complete server fs, as every
> single file from the original will be replaced. So you end up with
> the same situation as if you didn't have unionmount/cowlinks in the
> first place.
Absolutely. But, I'm assuming that the underlying filesystem is going to
be replaced periodically with an upgrade. This has it's own issues: in
that you have to take down a vserver in order to upgrade it effectively.
The net advantage is easy versioning and change control -> you know
exactly what should be there, so detecting changes becomes trivial. And,
you can limit changes to only certain parts of the filesystem in a more
"hard" way. For instance, your complaint about union mounts is that only
root can do it, preventing users from being able to do it. My complaint
about cow links is that users can do it, and shouldn't be able to. Mind
you, this is the "you will be assimilated" theory of computing, rather
than the "user empowerment" theory of computing.
> First variant is what I usually do. Might take a while, but I usually
> don't care. Second would be an optimization that should be just as
> efficient (if not more) as moving the unionfs overlay. Both variants
> are more flexible as the two machines don't need the same snapshot.
> But then again, I'm biased. ;)
I'm biased too... you can think of me as Mr. Anti-Flexibility ;)
But, I feel I've got some relatively good reasons for it. If you like,
I've got a little ditty I've written on the subject:
http://strongboxlinux.com/newsite/PEC_Manifesto.php
I'm also Mr. Reproducibility. If you have your total assimilation of
separate systems, then you have certain other types of flexibility: E.G.
for redundancy. For instance, I can reliably build in failover between
two systems by having them share a small set of configuration
information, plus whatever data a program uses. You can get systems
running quickly from backups. Plus, you can easily implement change
control systems that allow you to log _all_ changes that are made to a
server. And you don't have to spend every night running checksums on all
your binaries to see if someone's broken into your system yet...
If you're managing one computer, then, I agree with you, flexibility is
key. If you're managing 100+, it's an absolute nightmare.
Cheers,
Liam
>
> Jörn
>
-- Liam Helmer <linuxlists_at_thevenue.org>_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver