Date: Thu, 21 Jun 2012 08:26:49 -0700 From: Devin Teske <devin.teske@fisglobal.com> To: Vitaly Magerya <vmagerya@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities Message-ID: <45D784DF-DE4F-4455-979C-5F175D041231@fisglobal.com> In-Reply-To: <4FE2FD32.8070801@gmail.com> References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> <CAL409KxNKB=4aUksvWgthobo_sFkVXRHLM_qcfAZ73wfxWmNVw@mail.gmail.com> <4A5D7040-8623-4005-A5DF-D9E9211E4986@fisglobal.com> <4FE2FD32.8070801@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45D784DF-DE4F-4455-979C-5F175D041231>