Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities

On Jun 21, 2012, at 3:53 AM, Vitaly Magerya wrote:

> Devin Teske wrote:
>>> "Toggle Startup Services" dialog shows sendmail_enable and
>>> sendmail_msp_queue_enable variables, but doesn't seem to show
>>> sendmail_submit_enable and sendmail_outbound_enable. Is this
>>> by design?
>> 
>> What does the following produce:
>> 
>> 	service sendmail rcvar
>> 
>> Now what does this say:
>> 
>> 	grep sendmail /var/run/bsdconfig/startup_rcvar_map.cache
>> 
>> Do they agree?
> 
> OK, both list sendmail_enable and sendmail_msp_queue_enable only. It
> appears that /etc/rc.d/sendmail only registers sendmail_submit_enable
> and sendmail_outbound_enable if they are enabled (and enabling or
> disabling one of the four affects the status of others).
> 
> That behavior combined with the fact that bsdconfig does not recompute
> rcvars each time you make modifications means that you can't manipulate
> (i.e. disable) sendmail from bsdconfig.
> 

I wouldn't say that.

I'd say that because the output of "rcvar" is conditional, you can't [fully] manipulate sendmail. (i.e. you can't toggle "sendmail_outbound_enable" using bsdconfig).

BTW, if rcvar map cache was regenerated every time a variable got toggled, the menu would be unusable on my VM (which takes ~6-7 seconds to generate the cache -- passing "rcvar" to each rc.d script).


> I think the right thing to do is to fix /etc/rc.d/sendmail, but I don't
> know how: removing the conditions around sendmail_submit_enable and
> sendmail_outbound_enable parts fixes rcvar, but probably breaks other
> commands.
> 
> Any ideas how to fix this?
> 

I'll have a look at it, but the situation is thus:

Sysinstall's startup menu (replicated as-is in "bsdconfig startup_misc") is a hard-coded list with a hard-coded set of actions for each item.

I thought we could do better, and that's where "bsdconfig startup_rcvar" comes in.

I knew that startup_rcvar could not work perfectly because what's missing is a map of relational dependence between each of the rcvar's. In example, there's no way for me to know that toggling variable X will cause variables Y and Z to appear on the subsequent "rcvar" call to the rc.d script. Furthermore (and similarly), there's no way for me to tell if, while toggling a given service, that any other service should be toggled at the same time.

The former is a real issue, while the latter could perhaps be gleaned from reading the rcorder bits from the rc.d script to see if anything else needs to be toggled (ignoring the fake REQUIRES such as FILESYSTEMS, NETWORK, etc.).

Either way, I do feel that the initial offering is light years ahead of sysinstall(8)'s "Startup" menu even if it's not perfect.

Other options on the table are:
1. Change the rcvar output (of all scripts) to indicate dependency relationships
2. Change bsdconfig's startup_rcvar module to use a static list of variables (less desirable imho)
3. Fix sendmail's rcvar output to simply report all variables (haven't looked at the script yet to see how hard this will be -- but I'm leaning on this one first)


>> The nature of this bug is that if the item that you select in the
>> menu is evenly divisible by both 2 and 3 landing on a boundary,
>> the item works as expected, otherwise you can only toggle the item
>> ON (not off).
> 
> Sounds interesting; there must be some really hairy stuff inside
> bsdconfig if this is the kind of edge cases it has.

Well, it doesn't sound so hairy when I explain it…

dialog(1) (and Xdialog(1) too) support two different modes for menu-list widgets.

Item/Value pair's (this is the default)
and
Item/Value/Help triplets (enabled by passing "--item-help")

The latter functionality is used on the bsdconfig main menu as well as many of the menus in the "Startup" module to offer additional information at the bottom of the screen (or bottom of the window when using Xdialog).

The nature of the bug was that I was using f_dialog_menutag2item to translate the user's selection back into the value for said chosen-item. Problem was that this function expects item/value pairs, so I had to create a new API routine, f_dialog_menutag2item_with_help which does the same thing but expects item/value/help triplets.

So you can see why (when you're sending a list of sets-of-3 to a function that expects sets-of-2) the nature of the bug was that only the menu items that were evenly bounded worked as-expected while others did not.

Oh, and the reason for only being able to enable the broken items (but not disable) was because the fallback case for the mapped value was to to set to "YES" while we only set to "NO" when the mapped value has it's checkmark displayed (and since the mapped-value was NULL 2 out of 3 times, this resulted in not detecting the checkmark, defaulting to enabling the item).
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.