Very well put Ed.
I had numerous issues with Fedora during our testing. Ubuntu is fine, but
the packages can be slightly stale. Gentoo here.
On Oct 10, 2012 10:36 AM, "Ed W" <firstname.lastname@example.org> wrote:
> On 06/09/2012 09:33, Tor Rune Skoglund wrote:
> Personally, I am used to Gentoo, and the vserver system works perfectly.
>> However, in our use case, we might need to avoid a Gentoo due the need of
>> quicker updates than what is possible by a source code based distro like
>> Any comments appreciated.
> I use Gentoo on a whole bunch of vservers. My solution is:
> - extensive use of custom "profiles". eg I have
> - template vservers which are kept mostly up to date. Use these as rsync
> build targets to create new images from
> - nearly all vservers are close to identical (got a few 32bit wierd ones,
> but that's all).
> - set portage to create binary packages (and mount the shared package dir
> on guests)
> - mount the shared package directory differently on
> host/guest/wierd-guests. This means you can mainly keep all binary packages
> for a given large class of systems.
> - update using "emerge -uvDkp --newuse world". The --newuse ensures that
> a binary package is rebuilt if necessary due to changed USE flags from the
> ones used in the binary package, -k uses binary packages if they are
> available (-K to mandate only binary packages, no builds allowed)
> Mainly I can then update the template servers, and updating the rest is
> then 90% from binary packages. I have only some wierdness with eg, mysql
> in that I build the whole server for two instances, but minimal client
> tools for everything else - probably I should do some magic in the package
> location, but mainly I just order the updates to reduce rebuilds of that
> It helps to sync things like PHP flags across servers to reduce rebuilds
> (or get clever with binary package locations). eg I might not need "spell"
> on every instance, but it saves rebuilds just to keep the binary instances
> the same (security gurus are not inhibited from making their own choice
> here though)
> Additionally I mount my data separately from the OS (I use
> /vserver/images/ and /vserver/shared/), and this makes it simple to
> snapshot the OS, and fire it up pointing at the live data (mount the shared
> data in both images - obviously be careful that this is valid, eg don't
> mount a mysql db twice, but for example www files or mail spools are often
> fine to be served from two servers at once)
> This process above could be used to rebuild a test image first before you
> update the live image, and in fact if you needed near instant switching
> then simply update the test image, test it, then stop both and switch out
> the image directories and restart (takes 5 seconds or so?). You could even
> use IP switching or iptables to have basically instant swapouts if a few
> seconds is too long? (eg fire up a pool of vservers, each mounting shared
> data files and use some load balancer to take out machines individually as
> you update them - relatively easy under vserver)
> Finally: Daniel very kindly added some features to "vsomething" command
> and you can use --mark on multiple marks. I mark up my vservers based on
> their class (more than one mark per server), eg www, test, live, mysql,
> dont-break-me-be-really-**careful. Then I can use vsomething to run
> emerge on all servers which meet certain criteria, eg every dev server
> running, except the ones marked dont-break-me. Very handy
> Good luck
> Ed W
Received on Wed Oct 10 19:30:46 2012