Lone Coder: VirtualBox on Vista with a Gentoo Guest
CLIFFORD ILKAY
clifford_ilkay-biY6FKoJMRdBDgjK7y7TUQ at public.gmane.org
Tue Oct 20 20:00:28 UTC 2009
Lennart Sorensen wrote:
> I don't consider gentoo a good learning tool. I believe you learn a
> lot more by poking at a well designed distribution and learning how a
> really good design works and how it manages packages and keeps track
> of everything.
That wouldn't/didn't teach me a thing about how to do bootstrap
installations.
> Watching a compiler and make do it's thing teaches you
> nothing useful. It is quite boring in fact.
Agreed, that part wasn't a particularly useful learning exercise.
However, getting Gentoo to the point where I could boot a Gentoo kernel
was a worthwhile learning experience for me. Much of the complexity of
installation is hidden behind tui or gui interfaces in most other
distros (and that's a good thing) but it was useful to learn what goes
on behind the scenes.
>> Debootstrap in a virtual machine is an excellent way of deploying Debian
>> or its derivatives. That how we deploy both in Xen and OpenVZ virtual
>> machines in our hosting environment.
>>
>> Gentoo and Debian fans criticize Red Hat and derivatives because it
>> (supposedly) can't be upgraded in situ as Gentoo and Debian (supposedly)
>> can be. I've upgraded Fedora servers but I prefer to "nuke 'n pave",
>> especially since it's so trivially easy to do with Cobbler
>> <https://fedorahosted.org/cobbler/>. I've upgraded Debian and Ubuntu
>> servers where I typically don't install X and a desktop manager or such
>> and it worked as advertised. Desktop machines are a different story, no
>> matter what the distro. With the big changes in KDE, for example,
>> upgrading really doesn't get you much since there is no way to migrate
>> some (many?) of the config files anyway.
>
> Funny claim. I have never reinstalled a debian machine. It has never
> been necesary. My oldest currently running install was done in 1999.
> I don't even know how many debian releases it has been through by now.
>
> To me a reinstall is a sign of a very flawed distribution that isn't
> well tested and isn't well designed. With a proper system you can
> upgrade the system while in use and most of the time the users of that
> system won't even notice it happening.
With a "proper" system, the cost of reinstalling won't be so high that
you think that "rolling updates/upgrades" are The One True Way. Having
the option, but not the obligation, to do repeatable, fresh installs is
a very good thing. That shouldn't preclude you from doing in situ
updates and upgrades.
>> Let me just expand on Cobbler. Last week, I was at a client where I
>> demonstrated a hands-off, bare metal installation of CentOS 5.3, over
>> PXE. From selecting the PXE menu option to having a machine that was
>> ready for use, it was about 20 minutes, and that included creating
>> filesystems on a 1TB disk presented by hardware RAID. (The RAID set had
>> been created prior to the installation. It was left running over the
>> weekend building the array.)
>>
>> Once we had the working CentOS machine, to create another CentOS
>> installation in a Xen virtual machine was a matter of running "koan" and
>> pulling a kickstart installation from the Cobbler server. That took
>> another 10 minutes. By contrast, the first Xen installation I did back
>> in 2005, took me a *week*.
>>
>> I believe the Cobbler approach, particularly if it's used in conjunction
>> with a configuration management system like bcfg2, cfengine, puppet,
>> chef, etc., is a far better solution to systems management than doing in
>> situ upgrades and ad hoc systems administration that often accompanies
>> that practice. If the cost of recreating the environment is so high that
>> you value in situ major upgrades over bare metal installations, you have
>> a problem. You most likely have an environment that can't be replicated
>> in a reasonable amount of time, if it can be replicated at all, which
>> does not bode well for disaster recovery.
>
> Being able to do multiple installs from a template is nice. It is no
> excuse for not making upgrades just work though. Using it as an excuse
> for why you don't have to support upgrades properly is simply crap.
It isn't "an excuse for why you don't have to support upgrades
properly". You can still do in situ updates/upgrades with yum, just like
you can with apt-get. Cobbler helps manage that. I can wake up a machine
across the network and do a repeatable install or update without
touching that machine. I know about and have done preseed installations
for Debian/Ubuntu and aside from the fact that they're more complex and
not as well documented as kickstart, I don't know of a tool like Cobbler
for Debian/Ubuntu. If one exists, we'd use it because we happily use
Debian and derivatives, too and we need something like it there.
The creators of Red Hat and derivatives have made more effort addressing
manageability than the creators of Debian and derivatives, which isn't
surprising given that Red Hat targets and is used by organizations that
are bound to have such problems to address. I think Debian is used in
some large compute clusters where the manageability problems are
similar, hence debootstrap, but there are capabilities missing in
debootstrap that tools like Cobbler and Spacewalk are attempting to
address. Ubuntu, despite what Canonical may claim, isn't really ready
for "the enterprise". We have a client with a Canonical support
contract. It's a waste of money as far as I can tell because the moment
you stray away from what they consider to be "the standard", e.g.
deploying PHP apps via fcgi vs. mod_php, they throw up their hands and
say, "Oh, we can't provide support for that."
--
Regards,
Clifford Ilkay
Dinamis
1419-3266 Yonge St.
Toronto, ON
Canada M4N 3P6
<http://dinamis.com>
+1 416-410-3326
--
The Toronto Linux Users Group. Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
More information about the Legacy
mailing list