DragonFly kernel List (threaded) for 2003-08
Re: new sysinstall
Robert Clark wrote:
> Matthew Dillon wrote:
>> I would like a two-stage process, where everything you list is in the
>> second stage. The biggest problem with any install occurs when you go
>> through all the work of installing the system onto your disks, reboot,
>> and... nothing happens. The system doesn't boot or doesn't mount,
>> which means you have to go through the entire process all over again.
>> So the first thing I think an install should do is create a basic
>> slice and partition for /, swap, and /usr, copy the CD into it, and
>> reboot. And the very first option should be, with appropriate sanity
>> checks, a 'just do it and reboot' option.
>>1. Shell prompt
>>2. Reformat HD, install basic templates, and reboot before completing
>>3. Scan network for templates, install or query for selection,
>>and reboot before completing the procedure.
>> Once rebooted into the HD we can then proceed to do all the
>> time-consuming installation without worrying about having to start
>> over from scratch.
> If something like "Jail" or the Plex86 stuff or something like lpars
> ever become a part of the OS, it would be cool if step 3 could be used
> to setup an OS image for them.
> Also, if the install process could output a log that could be used to
> drive an exact reinstall, that would be nice.
Jail is part of the o.s. and yes the configuration management utility
should be able to generate usable jails.
let me see if i can describe where i'd like to take this.
One of the things that all of the BSD's and linux for that matter is
missing is a way to handle multiple system configs. Say you have 50
DragonFly boxes you have to manage the configs on .. quite simply it
gets to be a pain in the ass.. so rather than write a once only throw
it away after we have this thing working tool. I propose we write
somthing usefull outside of the sysinstall realm. Somthing that can
be used by sysinstall. This has to be intergrated into the package
system. What i'm thinking is a client/server model with the packaging
system using xml to tell us how to configure that package.
lets say a package needs to know what interfaces to bind to.
it can tell us that it needs a drop down list box of interfaces to
select from. Or whatever user input it needs. what i'm trying to
communicate is that the package will actually drive the user interface
with the cm system just displaying information, and collecting information.
done this way you could create modules for say controlling cisco devices.
just as easily as you could setting up BIND.
to replay an install, you could just replay the xml data, sent to the
packages back. fully customized install scripts would be very easy to
create. Packages could be built for ports that integrate fully with
the cm utility. so for once and for all managing a huge number of
opensource boxes wouldn't be a complete nightmare.