I have ranted on about the purported support for Gentoo in Amazon EC2; I would like to slightly defend Amazon on this matter saying something that some people might find inflammatory but, I think, we should acknowledge if we strive to improve: Gentoo suck as a guest OS! Now that I pointed at the elephant in the room, let me try to qualify and explain this statement, trying to see what we can do about it.
The first obvious problem is that the standard baselayout we ship with has no idea how to work with vservers and other virtualised environments; we have baselayout-vserver, but last I knew it was a bit behind in features. Actually, we have a very good support for guests in baselayout, version 2, based on OpenRC. Indeed one of the features that the new baselayout brought to the mix was supporting out of the box many different VPS implementations (xen, vserver proper, OpenVZ, and, lately, LXC thanks to Andrian). Unfortunately, almost two years after the addition of OpenRC to the tree, and over three and a half years after the introduction of the first alpha of what became the current situation, we still don’t have it stable, although we’re nearing that date, hopefully.
02 Oct 2006; Roy Marples
+baselayout-1.13.0_alpha1.ebuild:
First alpha cut from the 1.13 branch with BSD and VServer support.
svcdir is now forced – you cannot change it’s location.
If you downgrade back to 1.12 you’ll have to copy /lib/rcscripts/init.d
to your svcdir (/var/lib/init.d by default) and run depscan.sh -u
Even discounting this problem (I actually use OpenRC on all my production systems, and never, or almost never, got problems with that), there are still problems with a number of scripts and configurations that assume presence or work of various real-hardware components that (obviously) we don’t have.
For instance, take the default syslog-ng configuration: it uses the /dev/tty12 device for logging… it doesn’t check whether the device exists before opening it for write, and the end result is that it can create a standard file with the log printed on it if you don’t remember to disable it after install (yes I noticed this just the other day after months of having the vservers running, shame on me!). On the other hand, metalog (which requires an option to run in vservers, since it will fail to start if it cannot access the kernel, and it obviously cannot do that within a vserver — and only the currently-unstable version has the option to do that) uses /dev/tty10 by the default configuration… just to show that we can’t even agree on the devices to use!
And of course there is the one big issue: our system set is too big! This means we end up bringing in a lot of stuff that is definitely not useful on vservers by default (like the kernel sources) just because we need them for the default case of real hardware. I guess one solution here would be to reduce the system set and then use the additional sets available in Portage 2.2 to handle the real-hardware cases (in the default stage… and from that an emerge -C &x40;hwboot would give you a virtualizable-system)… but alas that’s something that never got enough momentum to become reality.
In general, though, Gentoo could become a much better OS to work as guest… we should all try to work on improving that step by step, bit by bit… remember: report whatever you feel is wrong with Gentoo packaging on our bugzilla after making sure there isn’t a report already. Don’t assume somebody else will see your problem, don’t assume that you’ll be the only one with that problem, *please report it*… just try to keep an open mind that maybe it’ll be marked as an invalid bug because you should have done some extra configuration… on the other hand, we really should make it easier to use Gentoo as a guest operating system.
Been a couple years since I even ran a vserver now. Still one would hope that Gentoo had made some progress both on hosted and as a host. Images can be hard to come by. Not all colocation offers it.You would have to have a binpkg host and compile separately. Wouldn’t need all that in a vps of course. Compiler, kernel, yada yadaSeems to me for all it’s ‘stale tree’ shouldn’t be hard to come up with a decent hardened lamp and support glsa updates. But years into glsa’s they are not considered ‘production ready’Then of course the majority of vps’s run Cpanel. That’s a whole can of worms in and of itself. Webmin meh not so much. In the end the user usually needs assistance.
Splitting up profiles (and thus system set) would definitely help a lot for virtualized system, and even so for host systems.Having a “runtime” and a “build” profile would be nice so that e.g. binpkg install could get much more lightweight.
Did you even manage to build your custom AMI? i tried for about two days to build an openrc enabled AMI, but i never got it booting, and the lack of proper debugging consoles/serial terminals just left me with anger and a 20$ EC2 bill.
@Bruno using only runtime dependencies is actually quite easy and I do that both for my VPS and the main gateway for my house, but certainly we could use more fine-grained sets in there.@Benedikt I was able to get the AMI working, using one of the Ubuntu’s kernels and copying over their own modules as well. It’s not pretty, it’s not nice and it’s not easy but it worked. And yes, that included a lot of set-start-fail… including EC2’s nasty thing of letting you wait for eternity before showing you the system log (and having to request it five/six time before getting it!).
Agree 100% with this post. It took us some massive hacking of our Gentoo system image to get it to run as an AMI on EC2. I don’t have all the details of what we did handy, but it wasn’t pretty.
Hi, actually, it is quite simple to build an client OS using Gentoo, particulary for OpenVZ. I do this on almost daily basis with the script (I use binary packages so it takes about 4 minutes, depending how big the system is):#!/bin/bashif [ $# -eq 2 ]; then builddir=”/home/buildve/” buildroot=”/real/” if [ -d /real ]; then emerge –root $buildroot glibc shadow baselayout openrc shadow findutils iputils util-linux gzip grep udev gawk net-tools nss_ldap pam_ldap dhcpcd openssh rsync bash apache -kavecho “Creating dirs…”mkdir $buildroot/procmkdir $buildroot/devmkdir $buildroot/storagersync -aH –delete $builddir/apache2/ $buildroot/etc/apache2/rsync -aH –delete $builddir/dev/ $buildroot/dev/#some other rsync herecd $buildroottar -zcf minimal.tar.gz * && mv minimal.tar.gz /vz/template/cache/elseecho “Create $buildroot first.”fielseecho “Usage: build-rc.sh [USERID] [VEID]”fiOnce the script finishes, one is able to make hundreds of guest Gentoo’s and once they’re fine migrate them to real host:for a in `seq 101 901`; do vzctl create $a –ostemplate minimal; donefor a in `seq 101 901`; do vzmigrate –online destinationhost $a; doneSometimes, I do modify the script to include this or that. Custom dirs contain only apache configuration and devices. Ldap.conf and some more scripts (not included here) performs authentication and authorization.My package.keywords includes only those lines (of course, I needed that)sys-apps/openrcsys-apps/baselayoutsys-apps/sysvinitAll is cool and fine, in the system I don’t even have ps, as I don’t have to.And that isn’t that big, as it takes approximately 236MB (~65 packages). That quick, was it? 🙂
But what if the reported problem seems to be ignored?Okay, this bug report is just a month and a few days old, but the problem should be clear and easy to solve…http://bugs.gentoo.org/show…