sysinstall as a post-install tool

[Nathan Whitehorn]

On 01/03/12 22:25, Lawrence Stewart wrote:
> On 01/04/12 14:27, Ron McDowell wrote:
>>
>>
>> Devin Teske wrote:
>>>
>>> On Jan 3, 2012, at 6:57 PM, Eitan Adler wrote:
>>>
>>>> On Tue, Jan 3, 2012 at 9:50 PM, Ron McDowell <rcm at fuzzwad.org
>>>> <mailto:rcm at fuzzwad.org>> wrote:
>>>>> I [Ron] just added myself to the sysinstall list.
>>>>
>>>> Good
>>>>>
>>>>> What I envision is a text based system administration suite that will
>>>>> [hopefully] do everything that the "Configure" option on the top
>>>>> level of
>>>>> the sysinstall menu does. I see it as being part of the base OS,
>>>>> such that
>>>>> once one has rebooted from HD after the install and logged in as
>>>>> root [or
>>>>> user+su], a menu can be brought up by entering "sysadmin" or such. 
>>>>> Does
>>>>> "sysadmin" work for a name? I kinda like it.
>>>>
>>>> Do you plan on this tool being run "late in the game" after the system
>>>> has been used for a while or this is a "welcome new user" only tool?
>>>>
>>>>> I plan on basically going through the sysinstall post-configuration
>>>>> menu:
>>>>
>>>> [snip configure menu]
>>>>
>>>> Do you plan on making this a C based program or a shell script?
>>>
>>> If he plans on making it sh(1) based, then I wonder if he would be
>>> interested in starting with host-setup as a very solid and robust
>>> substrate.
>>>
>>> I was just about to start building the port Makefile and getting
>>> host-setup to fill this exact need.
>>>
>>> We @vicor have been working on this exact thing for years now.
>>>
>>> I feel that it would be a *very* simple task to add the remaining
>>> [missing] menu items considering how hard it was to simply get this 
>>> far.
>>>
>>> host-setup ... (we can change the name; I'll have to sleep on
>>> "sysadmin" -- leaning more toward perhaps "sysconfig" ... it's the
>>> logical name considering we're taking the "Config[uration]" menu from
>>> "sys[install]", so the name ought to perhaps be "sysconfig") ... is a
>>> multi-thousand-line shell script that uses a very full-proof approach
>>> to solving the problem. It's unbreakable in its current form and has
>>> undergone hundreds of hours of testing (it's current version is 4.0.1).
>>>
>>> Oh, and it's BSD Licensed.
>>>
>>> Oh, and it's FreeBSD specific (originally works on both Linux and
>>> FreeBSD, but we've stripped the Linux stuff to make it FreeBSD-clean).
>>>
>>>
>>>>
>>>>> and as close as reasonable, stick to the same task flow. I plan on
>>>>> writing
>>>>> it against 10-current and look at back-porting to 9 after it's 
>>>>> somewhat
>>>>> stable.
>>>>
>>>
>>> If you use host-setup as a substrate, it works on FreeBSD-4.x up to
>>> 10-CURRENT (tested 4.8, 4.11, 8.1, 9-CURRENT and 10-CURRENT).
>>>
>>>
>>>> I'd like to work with you on this, especially w.r.t to ensuring that
>>>> it meets the requirements for entering the base system.
>>>>
>>>
>>> I too would like to work with you on this, regardless of language used
>>> or whether you use host-setup as a substrate or not.
>>>
>>> We also maintain a custom version of sysinstall in-house. So we're
>>> intimately involved with all of the code.
>>>
>>>
>>>>> One new, important, and not-so-difficult task will be: on exiting,
>>>>> check the
>>>>> sanity of /etc/rc.conf and complain if needed, but allow the user to
>>>>> override the safety-switch if foot-shooting is really requested. :)
>>>>> I'm a
>>>>> firm believer of not disallowing anything.
>>>
>>>> Good on both counts.
>>>
>>> host-setup actually leverages the power and safety of my sysrc(8)
>>> utility (just added to ports tree as sysutils/sysrc).
>>>
>>> In fact, sysrc was written as a test-script solely to feed back into
>>> host-setup so that we could replace sysinstall's Configure menu. We're
>>> just not there with all the menu items (but we've got the most
>>> important ones -- IMHO -- and made them rock-stable).
>>> -- 
>>> Devin
>>>
>>> Links:
>>> http://druidbsd.sourceforge.net/
>>> http://druidbsd.sourceforge.net/download/host-setup.txt
>>> http://druidbsd.sourceforge.net/download/sysrc.txt
>>
>> Devin, thanks, this looks very intriguing, pulling it down now. And
>> sysconfig is a good name, better than sysadmin.
>
> I like how all this is sounding, and if host-setup turns out to be a 
> good base (which it certainly sounds like it could be), this could all 
> come together quite quickly.
>
> Whilst thinking about all the constraints and required/desired 
> features, do keep in mind Marcel's concern and one of Nathan's aims 
> with bsdinstall, which is that we need to be platform agnostic. 
> powerpc and sparc64 at a minimum should be considered, even if only in 
> so much as putting stubs in appropriate places for people who use 
> those platforms to fill in later.
>
> Perhaps getting in touch with key platform maintainers to get a list 
> of things that generally differ between x86 and that specific platform 
> would help inform the process, so you get an idea where additional 
> design discussion may be required...
>
> Onwards!

Hopefully, sysconfig won't do anything very platform specific (setting 
up partition tables, etc.), so this shouldn't be too much of an issue. 
But please do check in if you have doubts.

One brief comment I have on your code is with the giant table of driver 
name -> description. I realize this was copied from sysinstall, but you 
can get this in a much easier way by doing:
sysctl -n dev.$(echo $IF | sed -E 
's/([[:alpha:]]*)([[:digit:]]*)/\1.\2/g').%desc
-Nathan