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