Re: Daemon's Advocate article

[Michel Talon <talon@xxxxxxxxxxxxxxxx>]

Robert Garrett wrote:

> 
> I am a sysadmin.. I have had the responsibility of running a decent
> number of FreeBSD systems, and found there is no good way of dealing
> with Configuration Management issues, The installer knows how to
> configure things, and it should be able to be used to handle this task
> after installation is complete.. It should also be capable of maintaning
> configurations for more than itself, this to me includes DragonFlyBSD
> systems, Linux, Net, Open, FreeBSD, and hell I could see a cisco module
> being written for the design I have chosen. Basically what I am saying
> is for this task we need a powerfull mechanism, jumpstart capable, with
> highly configurable installs.

May i contribute a little bit here. In my opinion the first thing to do
is to try effectively a lot of different installers and see what one likes 
in them and dislike in them. In fact i have done just that, i have a pretty
powerful machine so i have installed vmware on it, and tried a lot of Linux
distros and other systems, even small distros like vectorlinux, rocklinux,
Knoppix, Mepis, and bigger ones like Mandrake, and of course NetBSD and
OpenBSD. Since my present machine runs Debian woody, the other machines in
the lab run Fedora and previously Redhat, and i have experience with
FreeBSD since 2.2.5, i have a fairly large panel of experience. I think it
would be foolish to try designing a new installer without getting oneself
into such an experience.

Some general remarks i have: i think the Fedora installer is at present
perhaps the most polished, the Mandrake installer being also nice. I have
helped our sysadmin to setup a kickstart network system for Fedora, so
that you boot on an etherboot floppy or through pxeboot, and half an hour
later, the machine is completely installed without any manual intervention.
This is really magical for large installs (you run many machines in
parallel) and incredibly easy with Fedora (there is even a GUI for writing
the kickstart file). However i know that there have been issues with our
main servers which have less standard configs like raid controllers, etc.
and that a lot of manual tweaking has been necessary in these cases.
As you know the Fedora installer is written in python (anaconda) and
displays through X running in framebuffer. It also capitalizes on Kudzu
which is written in C and explores all buses to discover what's in and load
appropriate kernel modules. This last aspect is less useful for *BSD where
the tradition is to load a complete kernel and leave the hardware discovery
to the probes appearing in kernel. Hence the net result of kudzu would be
here obtained by parsing dmesg. An issue i have seen with anaconda, is that
when a problem occurs, and this occurred on our raid servers, you are
completely in the black for understanding the cause of the problem.
Installation halts, nothing on the different screens allows to know why.

A completely different system has been introduced successfully first with
Knoppix, it is the autoconfigured live CDROM. The autoconfiguration uses
the same Kudzu that RedHat uses and is incredibly effective. In most cases
you end up running KDE, connected to the web etc. automagically. Then you
can install on hard disk by using the standard tools such as running fdisk
or cfdisk to partition the disk and copying the cdrom contents to the disk.
There is even a script which automates that. In some cases the X setup
doesn't work, and you are screwed (i have seen that once). However one can
still boot with knoppix vga=normal and proceed. All in one, this is an
extremely effective way to solve the installer problem, by removing it.
I understand that, at present Dragonfly follows this way. It may not be a
bad idea, and several Linux distros are now following the lead of Knoppix,
like Mepis. It may well be that for the individual install, the live cdrom
way is the best. On has only to concoct an easy to use install script,
which is order of magnitudes simpler than a full blown installer. However
that doesn't really solve the kickstart problem, it cannot compete with
a networked kickstart for mass installs.






-- 
Michel Talon