From owner-freebsd-current@FreeBSD.ORG Thu Jun 21 15:27:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D004F1065670 for ; Thu, 21 Jun 2012 15:27:45 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5978FC08 for ; Thu, 21 Jun 2012 15:27:45 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.4/8.14.4) with ESMTP id q5LFRIV3004767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Jun 2012 10:27:38 -0500 Received: from [10.0.0.105] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 21 Jun 2012 10:27:01 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <4FE2FD32.8070801@gmail.com> Date: Thu, 21 Jun 2012 08:26:49 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <45D784DF-DE4F-4455-979C-5F175D041231@fisglobal.com> References: <9B5B97C3-A795-4A16-8381-B0FED87E3053@fisglobal.com> <4A5D7040-8623-4005-A5DF-D9E9211E4986@fisglobal.com> <4FE2FD32.8070801@gmail.com> To: Vitaly Magerya X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-06-21_03:2012-06-21, 2012-06-21, 1970-01-01 signatures=0 Cc: freebsd-current@freebsd.org Subject: Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 15:27:45 -0000 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.