Re: Daemon's Advocate article

[Robert Garrett <rg70@xxxxxxxxxxxxx>]

Michel Talon wrote:
> 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.


Yes, this is true, my current plans have jumpstart capabilities in the 
second revision of the installer. It will connect to a management system 
and grab the config from there, The jumpstart file will be created using 
the same tools you would use to setup a single system, so you can 
duplicate configurations quickly and easily.

Robert Garrett