Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8)

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?
>>=20
>> What does the following produce:
>>=20
>> 	service sendmail rcvar
>>=20
>> Now what does this say:
>>=20
>> 	grep sendmail /var/run/bsdconfig/startup_rcvar_map.cache
>>=20
>> Do they agree?
>=20
> 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).
>=20
> 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.
>=20

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" us=
ing 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 t=
he 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.
>=20
> Any ideas how to fix this?
>=20

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" co=
mes in.

I knew that startup_rcvar could not work perfectly because what's missing i=
s a map of relational dependence between each of the rcvar's. In example, t=
here'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. Furthe=
rmore (and similarly), there's no way for me to tell if, while toggling a g=
iven 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, et=
c.).

Either way, I do feel that the initial offering is light years ahead of sys=
install(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 relation=
ships
2. Change bsdconfig's startup_rcvar module to use a static list of variable=
s (less desirable imho)
3. Fix sendmail's rcvar output to simply report all variables (haven't look=
ed at the script yet to see how hard this will be -- but I'm leaning on thi=
s 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).
>=20
> 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=85

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

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 th=
e 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 transla=
te the user's selection back into the value for said chosen-item. Problem w=
as that this function expects item/value pairs, so I had to create a new AP=
I routine, f_dialog_menutag2item_with_help which does the same thing but ex=
pects item/value/help triplets.

So you can see why (when you're sending a list of sets-of-3 to a function t=
hat expects sets-of-2) the nature of the bug was that only the menu items t=
hat 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 t=
o "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 resul=
ted in not detecting the checkmark, defaulting to enabling the item).
--=20
Devin

_____________
The information contained in this message is proprietary and/or confidentia=
l. If you are not the intended recipient, please: (i) delete the message an=
d all copies; (ii) do not disclose, distribute or use the message in any ma=
nner; and (iii) notify the sender immediately. In addition, please be aware=
 that any message addressed to our domain is subject to archiving and revie=
w by persons other than the intended recipient. Thank you.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"