From owner-freebsd-rc@FreeBSD.ORG Sun May 8 12:17:39 2011 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CFB4106564A for ; Sun, 8 May 2011 12:17:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EEDB18FC08 for ; Sun, 8 May 2011 12:17:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloHAG6Jxk2DaFvO/2dsb2JhbAAuhCSTVI5ppnWOH5ADgSqDYIECBI9ljnk X-IronPort-AV: E=Sophos;i="4.64,334,1301889600"; d="scan'208";a="123737154" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 08 May 2011 07:59:12 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 455C0B40AE for ; Sun, 8 May 2011 07:59:12 -0400 (EDT) Date: Sun, 8 May 2011 07:59:12 -0400 (EDT) From: Rick Macklem To: rc@freebsd.org Message-ID: <1494617414.14981.1304855952145.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: Subject: rc script changes related to NFS client X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 12:17:39 -0000 Hi, I've updated the scripts in: http://people.freebsd.org/~rmacklem/rc.conf slightly. I have 2 verions of mountcritremote changes. mountcritremote.diff - Taking out all the nfs specific stuff (hinted at by the comment) that seems to work for me (on i386, which is all I have) mountcritremote.diff2 - The minimal 1 line change that fixes the bug caused by module renaming in r21124. The discussion seemed to say that the new NFS client should use vfs.nfs.xxx naming for sysctls and it didn't really matter what the old NFS client does. As such, I just made /etc/rc.d/nfsclient depend on the correct module. Then, after the sysctl naming changes, it should work ok. I have an nfsd that doesn't need the nfsserver script, but I'll leave that until the above is dealt with. rick From owner-freebsd-rc@FreeBSD.ORG Sun May 8 12:37:47 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97907106566C for ; Sun, 8 May 2011 12:37:47 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB688FC08 for ; Sun, 8 May 2011 12:37:47 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 4292335932A for ; Sun, 8 May 2011 14:37:46 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 2BEAE17376; Sun, 8 May 2011 14:37:46 +0200 (CEST) Date: Sun, 8 May 2011 14:37:46 +0200 From: Jilles Tjoelker To: freebsd-rc@FreeBSD.org Message-ID: <20110508123745.GA83320@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [PATCH] Use printf(1) builtin for hexprint function in etc/network.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 12:37:47 -0000 Now that printf(1) is a shell builtin, there is no need to emulate it anymore. It may be faster to use printf directly but the function is useful for compatibility. Index: etc/network.subr =================================================================== --- etc/network.subr (revision 220966) +++ etc/network.subr (working copy) @@ -1333,38 +1333,14 @@ # Echo decimal number $arg (single digit) in hexadecimal format. hexdigit() { - if [ $1 -lt 10 ]; then - echo $1 - else - case $1 in - 10) echo a ;; - 11) echo b ;; - 12) echo c ;; - 13) echo d ;; - 14) echo e ;; - 15) echo f ;; - esac - fi + printf '%x\n' "$1" } # hexprint arg # Echo decimal number $arg (multiple digits) in hexadecimal format. hexprint() { - local val str dig - val=$1 - str='' - dig=`hexdigit $((${val} & 15))` - str=${dig}${str} - val=$((${val} >> 4)) - - while [ ${val} -gt 0 ]; do - dig=`hexdigit $((${val} & 15))` - str=${dig}${str} - val=$((${val} >> 4)) - done - - echo ${str} + printf '%x\n' "$1" } is_wired_interface() -- Jilles Tjoelker From owner-freebsd-rc@FreeBSD.ORG Sun May 8 18:59:32 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6202F106566C for ; Sun, 8 May 2011 18:59:32 +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 2C7588FC08 for ; Sun, 8 May 2011 18:59:31 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p48IJtFA016418; Sun, 8 May 2011 13:19:55 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 13:20:03 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 13:19:54 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 13:19:54 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <20110508123745.GA83320@stack.nl> Date: Sun, 8 May 2011 11:19:52 -0700 Message-Id: References: <20110508123745.GA83320@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 18:19:54.0499 (UTC) FILETIME=[87746530:01CC0DAC] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-rc@FreeBSD.org Subject: Re: [PATCH] Use printf(1) builtin for hexprint function in etc/network.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 18:59:32 -0000 On May 8, 2011, at 5:37 AM, Jilles Tjoelker wrote: > Now that printf(1) is a shell builtin, there is no need to emulate it > anymore. Did you realize that when you committed printf(1) back to the sh(1) Makefil= e, you were about 28 hours away from the 9 year anniversary of when knu rem= oved it. knu removed printf(1) from the sh(1) makefile on Nov 20th, 2001, a= nd you brought it back on Nov 19th, 2010. According to: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/Makefile Hallelujah!! Thank you so much for bringing printf(1) back as a builtin! An= ytime you're near San Francisco, I'll buy you a beer (seriously... _thank_ = _you_). --=20 Cheers, Devin >=20 > It may be faster to use printf directly but the function is useful for > compatibility. >=20 > Index: etc/network.subr > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- etc/network.subr (revision 220966) > +++ etc/network.subr (working copy) > @@ -1333,38 +1333,14 @@ > # Echo decimal number $arg (single digit) in hexadecimal format. > hexdigit() > { > - if [ $1 -lt 10 ]; then > - echo $1 > - else > - case $1 in > - 10) echo a ;; > - 11) echo b ;; > - 12) echo c ;; > - 13) echo d ;; > - 14) echo e ;; > - 15) echo f ;; > - esac > - fi > + printf '%x\n' "$1" > } >=20 > # hexprint arg > # Echo decimal number $arg (multiple digits) in hexadecimal format. > hexprint() > { > - local val str dig > - val=3D$1 > - str=3D'' > - dig=3D`hexdigit $((${val} & 15))` > - str=3D${dig}${str} > - val=3D$((${val} >> 4)) > - > - while [ ${val} -gt 0 ]; do > - dig=3D`hexdigit $((${val} & 15))` > - str=3D${dig}${str} > - val=3D$((${val} >> 4)) > - done > - > - echo ${str} > + printf '%x\n' "$1" > } >=20 > is_wired_interface() >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" --=20 Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- _____________ 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Sun May 8 19:13:42 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D5D106564A; Sun, 8 May 2011 19:13:42 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA2AD8FC0A; Sun, 8 May 2011 19:13:41 +0000 (UTC) Received: by iyj12 with SMTP id 12so5480542iyj.13 for ; Sun, 08 May 2011 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :reply-to:mime-version:content-type:content-disposition :x-openpgp-key-id:x-openpgp-key-fingerprint:x-openpgp-key-url; bh=oCS9kbjB84EwxUSOi2uPIJRMOVm/u+Tom1oJo5h3ZwU=; b=B8WQH+jSLbuewH0zcxA7FZGpx+SQ2cTk/xQI4vum+MxGzR3B/97f76cmhugimVK7Fm AqJCom5i/cE9mbT0oAuK3kcnOvfAA5p8PrXybMl2VOIFv3bU9uFGsrERPj3yNnSKrldF Ud+pGWhAjzKycvWd9L04baTt4DciM+yPlxMmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=rh7ZMV1S4wV/a6VCvVzD3SvCx/BpeV6fth0srGhLO+N9m3gs25+It69RQMXsRBvVPj YwCPHRRTjQXgR/RAZ6s+iwAVpi5gvtJ0aSP7B5RzxUohCfO9N76c/+A3UX17geMHKWJF qpJKlmdfqRadTrpFT8TEYoPT01GACC4MZIiW4= Received: by 10.42.134.70 with SMTP id k6mr5286097ict.488.1304882021199; Sun, 08 May 2011 12:13:41 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2297255iby.6.2011.05.08.12.13.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 12:13:40 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48JDb5F006840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 15:13:37 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48JDagU006839; Sun, 8 May 2011 15:13:36 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 15:13:36 -0400 From: Jason Hellenthal To: freebsd-rc@freebsd.org Message-ID: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-rc@freebsd.org List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 19:13:42 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable List, - Please reply-to freebsd-rc@freebsd.org Recently I have been going over some changes in the configurations that=20 are possible with the rc subsystem and to my dismay I have found some=20 inconsistencies with in particular the way rc.conf.d directory is=20 processed and the arguments that are supplied to load_rc_config so I have= =20 patched it up... Let me explain: As determined by rc.subr load_rc_config, config's from=20 rc.conf.d are loaded by the scripts $name as an argument to load_rc_config= =20 and thus only the name being parsed is is available to be used in the=20 rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as= =20 the user has no direct way to know that a variable used by nfsd is also=20 needed by mountd or the same for various other scripts in the rc.d=20 directory. At this time these config's are explained to be available for=20 the user to utilize by rc.conf(5) but yet without much knowledge of the=20 inner workings of the rc subsystem it would be quite the feat to do. The attachment[1] keeps this functionality the same while introducing a=20 more convenient approach for the user to modularize their configuration=20 however they see fit within a couple constraints that work very well.=20 What does it do ?: As stated above, current functionality is undisturbed=20 while allowing the user to create config's by any name they so desire as=20 long as it has an extension of ".conf", also introducing the ability to=20 turn a configuration file off by using chmod(1). You can turn nfsc1.conf off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf Why ? Simple. How many times have you been bitten by disabling something=20 in the rc.conf file and left to discover what you just disabled was also=20 used by another daemon but that daemon is now not starting ? This is a way= =20 to virtualize your configuration allowing you to add multiple _enable=3D=20 lines to different configurations for different roles. For instance=20 rpcbind is used by both samba and nfs*. With this you can add=20 rpcbind_enable to both a configuration for samba and nfs and when you=20 disable one service you know that you have not disabled a dependent for=20 another. This is a small addition that fixes currently broken undesirable aspects=20 of the configuration system that deals with the rc.conf.d directory with a= =20 SysV style init approach that is just as flexible. This should apply=20 cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback= =20 has been received Ill update the manual page with any suggestions=20 regenerate the patch to accommodate and file a PR. 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch Thanks --=20 Regards, (jhell) Jason Hellenthal --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxutfAAoJEJBXh4mJ2FR+anYH/jwyA3ifRH5QAivOkYcj3bSD 4jQCZB8FLDT1U7jE9hBk+YprFdkjBi+bDSPrbNYL3cOohvrVuAziB9VG811IhaRE //A9krdIy7QxXdkDFhkmP5F+z0wcmKoriFcO7onsDKVAqGjgyv+YyW+EohLjy283 rUAAmlgmlUSqcdAFNh8mJzNFDtcO9rqcXC1GVIGMY5wqoDLVQdkLwXrlmvPZc9eA Fz3++ZBPq0orRCjQDeP2h+rnAtssgBTXxaZhIM6tyS8aMBbOgl2XSaT5i5w7Soa5 8OButlT1RQ5TinqMt7ebXB07ycabgmFFLIK2JYPKS6Vp+zYOSYKlf9bO2B0dmMk= =zfmQ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-rc@FreeBSD.ORG Sun May 8 20:26:42 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98157106566C for ; Sun, 8 May 2011 20:26:42 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9C58FC0A for ; Sun, 8 May 2011 20:26:42 +0000 (UTC) Received: by iwn33 with SMTP id 33so5468114iwn.13 for ; Sun, 08 May 2011 13:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=Xv/ViLyyDlfHTzQpsE4ZHI0v+FwHBOQ4MIGXF34dXNk=; b=vFAhS60duTGT+W+PBMMM3Ze8ztLcJIl0p5QpV537SPR7Jd9ENmyxbug14Mgp+PgrMl 1vEzORaFYgDgFpF9gb2nGyP/NIEQgF1PZzgdtal6Nwm2QnF5DWnpCpnEkpOehICc+XO5 VdDpsw0qJ6M+F6ft/y3hT71QfhONqIClmBvV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=CA2Ck6xu6UyRijHMjZWBF+Rtj+sJjQvpuFhukBELICW5GvBGrwYKPZqU2H+n5iJ3XW P1+yv32LqO3vzxI/soqn3tdrm6oZdaq7RNak0RYCsLqQ7I4Ps+TXg1LLZF6oHpkX1gWY 4FJy/mjFVhwq3F26lJIDO9aj8TNb9kWPbNRdU= Received: by 10.43.63.72 with SMTP id xd8mr4965599icb.215.1304886400833; Sun, 08 May 2011 13:26:40 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id e12sm2121861ics.7.2011.05.08.13.26.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 13:26:39 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48KQaTK010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 16:26:37 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48KQaiO010356; Sun, 8 May 2011 16:26:36 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 16:26:36 -0400 From: Jason Hellenthal To: Garrett Cooper Message-ID: <20110508202636.GF3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 20:26:42 -0000 --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garrett, On Sun, May 08, 2011 at 01:13:12PM -0700, Garrett Cooper wrote: > On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >=20 > >=20 > > List, - Please reply-to freebsd-rc@freebsd.org > >=20 > > Recently I have been going over some changes in the configurations that= =20 > > are possible with the rc subsystem and to my dismay I have found some= =20 > > inconsistencies with in particular the way rc.conf.d directory is=20 > > processed and the arguments that are supplied to load_rc_config so I ha= ve=20 > > patched it up... > >=20 > > Let me explain: As determined by rc.subr load_rc_config, config's from= =20 > > rc.conf.d are loaded by the scripts $name as an argument to load_rc_con= fig=20 > > and thus only the name being parsed is is available to be used in the= =20 > > rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient = as=20 > > the user has no direct way to know that a variable used by nfsd is also= =20 > > needed by mountd or the same for various other scripts in the rc.d=20 > > directory. At this time these config's are explained to be available fo= r=20 > > the user to utilize by rc.conf(5) but yet without much knowledge of the= =20 > > inner workings of the rc subsystem it would be quite the feat to do. > >=20 > >=20 > > The attachment[1] keeps this functionality the same while introducing a= =20 > > more convenient approach for the user to modularize their configuration= =20 > > however they see fit within a couple constraints that work very well.= =20 > >=20 > >=20 > > What does it do ?: As stated above, current functionality is undisturbe= d=20 > > while allowing the user to create config's by any name they so desire a= s=20 > > long as it has an extension of ".conf", also introducing the ability to= =20 > > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > >=20 > >=20 > > Why ? Simple. How many times have you been bitten by disabling somethin= g=20 > > in the rc.conf file and left to discover what you just disabled was als= o=20 > > used by another daemon but that daemon is now not starting ? This is a = way=20 > > to virtualize your configuration allowing you to add multiple _enable= =3D=20 > > lines to different configurations for different roles. For instance=20 > > rpcbind is used by both samba and nfs*. With this you can add=20 > > rpcbind_enable to both a configuration for samba and nfs and when you= =20 > > disable one service you know that you have not disabled a dependent for= =20 > > another. > >=20 > >=20 > > This is a small addition that fixes currently broken undesirable aspect= s=20 > > of the configuration system that deals with the rc.conf.d directory wit= h a=20 > > SysV style init approach that is just as flexible. This should apply=20 > > cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedba= ck=20 > > has been received Ill update the manual page with any suggestions=20 > > regenerate the patch to accommodate and file a PR. > >=20 > >=20 > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > Doing: >=20 > find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -perm= +111 | while read _modular_conf; do > debug "Sourcing $_modular_conf" > . "$_modular_conf" > done >=20 > might be better. There's some more magic that could ultimately be done t= o make this more secure/robust using "-print0" | xargs, but it's up to you = how you might want to go about solving that problem. > Also, I don't know if depending on a .conf file to be executable is nece= ssarily the best course of action. > Cheers! > -Garrett Yeah I see what you are getting at there and I came across thinking the=20 same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep=20 without using find(1). As for the security sense if someone has a way to write to that directory= =20 then most likely they are not going to be looking into placing anything in= =20 that directory as theyll have rights to change anything under the rc sun!= =20 plus anyting under most of the rest of the system. I do like the approach though. Thank you. --=20 Regards, (jhell) Jason Hellenthal --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxvx7AAoJEJBXh4mJ2FR+Sg8H/j1SFy+QKO9q/twKyAZKcu+v BLjH4RciB3SeSYX7BDZHM2mbxo81ITERT9D9ONe865AzA57rHOc3BxgdbI/NJ5aK oS4n0cJc/QTpg8g9boG+SIr5Ucq6U2eaQOnWafyvRsCIolqcoyvsqsy9UpTNRQYl lNf7Y1T8FpsG9CPq3+qrd18TM5pAq46gWIJpXy8AFZKjGqR3p7fuVPkfNApr7T+V 5zVtuCYkrS1aL+nBUF1Bihct1u694X9XUTiRL0oMM8JmVFAc7dY14Rb0wtq1LKYJ 7jHibCa7YoatMHdHMEVb7q7ClCFu752h3jL+F4z0ce2WK21J1QBfxN3R8uoXp4M= =DEMi -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- From owner-freebsd-rc@FreeBSD.ORG Sun May 8 20:37:49 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D820106566C for ; Sun, 8 May 2011 20:37:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D11708FC12 for ; Sun, 8 May 2011 20:37:48 +0000 (UTC) Received: by pvg11 with SMTP id 11so2768296pvg.13 for ; Sun, 08 May 2011 13:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=45LqKSVyC6ge9uYz1q/M/kFDQR1cTM/DC8baxMfW4Cs=; b=xX9zPeR8F1kf2ymkFEBtpMNLGfd6DE61g+CUxkoEiG+RnLNl+kq3Mx+HA6VJg1z0OE rCT2vc2XqtsXuNaRVU2jQk5qsmtvxiA5CQ5iWCFKhN5n42ngrQGXGeakXmVe4+yRfimn vyFt8Cz0GgZsedJ6CSLSbVF5dyuWC7GT97mMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=IXQBbWimptzUzpzm4IR0P0V+cht1cSnCRXyT8aRpkJn+9/TrXHQ5YnM8/nA3CcQR// BEfpEBZS5omu/KCX7fOBobTeFeiVyNnaZBJVd4Io1h7k1wWp8rxyFaRZBg51jhUr0qmY 6HxoXhPYFGR/veL8NLgiE1Ghb5Iba49Xmmdc4= Received: by 10.142.248.38 with SMTP id v38mr3300732wfh.15.1304885596479; Sun, 08 May 2011 13:13:16 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net [24.6.49.154]) by mx.google.com with ESMTPS id z10sm7152408wfj.12.2011.05.08.13.13.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 13:13:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20110508191336.GC3527@DataIX.net> Date: Sun, 8 May 2011 13:13:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110508191336.GC3527@DataIX.net> To: jhell X-Mailer: Apple Mail (2.1084) Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 20:37:49 -0000 On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >=20 > List, - Please reply-to freebsd-rc@freebsd.org >=20 > Recently I have been going over some changes in the configurations = that=20 > are possible with the rc subsystem and to my dismay I have found some=20= > inconsistencies with in particular the way rc.conf.d directory is=20 > processed and the arguments that are supplied to load_rc_config so I = have=20 > patched it up... >=20 > Let me explain: As determined by rc.subr load_rc_config, config's = from=20 > rc.conf.d are loaded by the scripts $name as an argument to = load_rc_config=20 > and thus only the name being parsed is is available to be used in the=20= > rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient = as=20 > the user has no direct way to know that a variable used by nfsd is = also=20 > needed by mountd or the same for various other scripts in the rc.d=20 > directory. At this time these config's are explained to be available = for=20 > the user to utilize by rc.conf(5) but yet without much knowledge of = the=20 > inner workings of the rc subsystem it would be quite the feat to do. >=20 >=20 > The attachment[1] keeps this functionality the same while introducing = a=20 > more convenient approach for the user to modularize their = configuration=20 > however they see fit within a couple constraints that work very well.=20= >=20 >=20 > What does it do ?: As stated above, current functionality is = undisturbed=20 > while allowing the user to create config's by any name they so desire = as=20 > long as it has an extension of ".conf", also introducing the ability = to=20 > turn a configuration file off by using chmod(1). You can turn = nfsc1.conf > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf >=20 >=20 > Why ? Simple. How many times have you been bitten by disabling = something=20 > in the rc.conf file and left to discover what you just disabled was = also=20 > used by another daemon but that daemon is now not starting ? This is a = way=20 > to virtualize your configuration allowing you to add multiple _enable=3D= =20 > lines to different configurations for different roles. For instance=20 > rpcbind is used by both samba and nfs*. With this you can add=20 > rpcbind_enable to both a configuration for samba and nfs and when you=20= > disable one service you know that you have not disabled a dependent = for=20 > another. >=20 >=20 > This is a small addition that fixes currently broken undesirable = aspects=20 > of the configuration system that deals with the rc.conf.d directory = with a=20 > SysV style init approach that is just as flexible. This should apply=20= > cleanly to current and stable/8 & 8.2-RELEASE systems. Once more = feedback=20 > has been received Ill update the manual page with any suggestions=20 > regenerate the patch to accommodate and file a PR. >=20 >=20 > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch Doing: find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 = -perm +111 | while read _modular_conf; do debug "Sourcing $_modular_conf" . "$_modular_conf" done might be better. There's some more magic that could ultimately = be done to make this more secure/robust using "-print0" | xargs, but = it's up to you how you might want to go about solving that problem. Also, I don't know if depending on a .conf file to be executable = is necessarily the best course of action. Cheers! -Garrett= From owner-freebsd-rc@FreeBSD.ORG Sun May 8 20:59:51 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39F92106564A for ; Sun, 8 May 2011 20:59:51 +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 F1EB78FC0A for ; Sun, 8 May 2011 20:59:50 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p48KxmqT019948; Sun, 8 May 2011 15:59:48 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 15:59:57 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 15:59:48 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 15:59:47 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: Date: Sun, 8 May 2011 13:59:40 -0700 Message-Id: <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> References: <20110508191336.GC3527@DataIX.net> To: Garrett Cooper X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 20:59:47.0758 (UTC) FILETIME=[DD7B8CE0:01CC0DC2] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 20:59:51 -0000 On May 8, 2011, at 1:13 PM, Garrett Cooper wrote: > On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >=20 >>=20 >> List, - Please reply-to freebsd-rc@freebsd.org >>=20 >> Recently I have been going over some changes in the configurations that= =20 >> are possible with the rc subsystem and to my dismay I have found some=20 >> inconsistencies with in particular the way rc.conf.d directory is=20 >> processed and the arguments that are supplied to load_rc_config so I hav= e=20 >> patched it up... >>=20 >> Let me explain: As determined by rc.subr load_rc_config, config's from= =20 >> rc.conf.d are loaded by the scripts $name as an argument to load_rc_conf= ig=20 >> and thus only the name being parsed is is available to be used in the=20 >> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient a= s=20 >> the user has no direct way to know that a variable used by nfsd is also= =20 >> needed by mountd or the same for various other scripts in the rc.d=20 >> directory. At this time these config's are explained to be available for= =20 >> the user to utilize by rc.conf(5) but yet without much knowledge of the= =20 >> inner workings of the rc subsystem it would be quite the feat to do. >>=20 >>=20 >> The attachment[1] keeps this functionality the same while introducing a= =20 >> more convenient approach for the user to modularize their configuration= =20 >> however they see fit within a couple constraints that work very well.=20 >>=20 >>=20 >> What does it do ?: As stated above, current functionality is undisturbed= =20 >> while allowing the user to create config's by any name they so desire as= =20 >> long as it has an extension of ".conf", also introducing the ability to= =20 >> turn a configuration file off by using chmod(1). You can turn nfsc1.conf >> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf >>=20 >>=20 >> Why ? Simple. How many times have you been bitten by disabling something= =20 >> in the rc.conf file and left to discover what you just disabled was also= =20 >> used by another daemon but that daemon is now not starting ? This is a w= ay=20 >> to virtualize your configuration allowing you to add multiple _enable=3D= =20 >> lines to different configurations for different roles. For instance=20 >> rpcbind is used by both samba and nfs*. With this you can add=20 >> rpcbind_enable to both a configuration for samba and nfs and when you=20 >> disable one service you know that you have not disabled a dependent for= =20 >> another. >>=20 >>=20 >> This is a small addition that fixes currently broken undesirable aspects= =20 >> of the configuration system that deals with the rc.conf.d directory with= a=20 >> SysV style init approach that is just as flexible. This should apply=20 >> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedbac= k=20 >> has been received Ill update the manual page with any suggestions=20 >> regenerate the patch to accommodate and file a PR. >>=20 >>=20 >> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > Doing: >=20 > find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -perm= +111 | while read _modular_conf; do > debug "Sourcing $_modular_conf" > . "$_modular_conf" > done >=20 > might be better. There's some more magic that could ultimately be done t= o make this more secure/robust using "-print0" | xargs, but it's up to you = how you might want to go about solving that problem. > Also, I don't know if depending on a .conf file to be executable is nece= ssarily the best course of action. >=20 First, let me add that I really like the idea. This makes it akin to our /u= sr/local/apache2/conf.d/ directory where we place our various configs by ma= ny names, but always ending in `.conf'. I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/rc.d/= bar.conf, each configuring multiple (likely unrelated) services. Better still, /etc/rc.d/jail1.conf, /etc/rc.d/jail2.conf, etc. etc. (I thin= k you just made my -- and everyone else whom uses jails -- day/week/month/y= ear). However, I agree with GC that depending on a .conf file to be executable is= a bit non-standard, even if it is sourced like a shell-script (though I ca= n understand the historical heritage as /usr/local/etc/rc.d/ used to requir= e both `.sh' suffix and executable bits; but that is not to condone treatin= g `rc.conf.d' like `rc.d' in any way). --=20 Cheers, Devin Teske -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -----BEGIN GEEK CODE BLOCK----- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB++++$ P++++@$ L++++$ = E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ = DI+ D+(++) G++ e>++++ h r+++ z+++ ------END GEEK CODE BLOCK------ http://www.geekcode.com/ -> END TRANSMISSION <- _____________ 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Sun May 8 21:19:21 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F4EF106566B for ; Sun, 8 May 2011 21:19:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1D508FC13 for ; Sun, 8 May 2011 21:19:20 +0000 (UTC) Received: by pwj8 with SMTP id 8so2784066pwj.13 for ; Sun, 08 May 2011 14:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=4ePErgkq4utqPBpdBo/eOMbAJfdF5e8AYfqszP95njA=; b=Y73QIlf2D9JROFJmmPvrnC+F/oNWaP+xOH2jkepR861X3U8hzYDsDAiWAEXyTkGhQ2 qkkkL0uLmIyVDjrfNaxT9696X/oNIwg9RnYaeALjroW2SleSv5ZI89LFqAPXNlgUvB0S 3PL7Fz8gIl5gJ2e4RgsUoLVo5fqx2mTCJSXTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nmScia9zDBnmJk0FFFOZ/44W7xWSwMTVOdNZoGNolC7AJx9WgfbmFqqcTS6nOCPeSS PH4OT8KBcOpi53mAVZter/N7+Vze5+2scTg01PLvmX48JH+7rRie5cWv1Rd5ACq+8mfR aXkqZsd+daE+CB5MJhfixb2hMk6h0hPK9vHsQ= Received: by 10.68.55.133 with SMTP id s5mr8726116pbp.56.1304889560306; Sun, 08 May 2011 14:19:20 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net [24.6.49.154]) by mx.google.com with ESMTPS id x6sm2663040pbx.86.2011.05.08.14.19.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 14:19:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20110508202636.GF3527@DataIX.net> Date: Sun, 8 May 2011 14:19:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110508191336.GC3527@DataIX.net> <20110508202636.GF3527@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 21:19:21 -0000 On May 8, 2011, at 1:26 PM, Jason Hellenthal wrote: >=20 > Garrett, >=20 > On Sun, May 08, 2011 at 01:13:12PM -0700, Garrett Cooper wrote: >> On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >>=20 >>>=20 >>> List, - Please reply-to freebsd-rc@freebsd.org >>>=20 >>> Recently I have been going over some changes in the configurations = that=20 >>> are possible with the rc subsystem and to my dismay I have found = some=20 >>> inconsistencies with in particular the way rc.conf.d directory is=20 >>> processed and the arguments that are supplied to load_rc_config so I = have=20 >>> patched it up... >>>=20 >>> Let me explain: As determined by rc.subr load_rc_config, config's = from=20 >>> rc.conf.d are loaded by the scripts $name as an argument to = load_rc_config=20 >>> and thus only the name being parsed is is available to be used in = the=20 >>> rc.conf.d directory. Why is this bad ? Its not! but it is = inconvenient as=20 >>> the user has no direct way to know that a variable used by nfsd is = also=20 >>> needed by mountd or the same for various other scripts in the rc.d=20= >>> directory. At this time these config's are explained to be available = for=20 >>> the user to utilize by rc.conf(5) but yet without much knowledge of = the=20 >>> inner workings of the rc subsystem it would be quite the feat to do. >>>=20 >>>=20 >>> The attachment[1] keeps this functionality the same while = introducing a=20 >>> more convenient approach for the user to modularize their = configuration=20 >>> however they see fit within a couple constraints that work very = well.=20 >>>=20 >>>=20 >>> What does it do ?: As stated above, current functionality is = undisturbed=20 >>> while allowing the user to create config's by any name they so = desire as=20 >>> long as it has an extension of ".conf", also introducing the ability = to=20 >>> turn a configuration file off by using chmod(1). You can turn = nfsc1.conf >>> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf >>>=20 >>>=20 >>> Why ? Simple. How many times have you been bitten by disabling = something=20 >>> in the rc.conf file and left to discover what you just disabled was = also=20 >>> used by another daemon but that daemon is now not starting ? This is = a way=20 >>> to virtualize your configuration allowing you to add multiple = _enable=3D=20 >>> lines to different configurations for different roles. For instance=20= >>> rpcbind is used by both samba and nfs*. With this you can add=20 >>> rpcbind_enable to both a configuration for samba and nfs and when = you=20 >>> disable one service you know that you have not disabled a dependent = for=20 >>> another. >>>=20 >>>=20 >>> This is a small addition that fixes currently broken undesirable = aspects=20 >>> of the configuration system that deals with the rc.conf.d directory = with a=20 >>> SysV style init approach that is just as flexible. This should apply=20= >>> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more = feedback=20 >>> has been received Ill update the manual page with any suggestions=20 >>> regenerate the patch to accommodate and file a PR. >>>=20 >>>=20 >>> 1). = http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >>=20 >> Doing: >>=20 >> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 = -perm +111 | while read _modular_conf; do >> debug "Sourcing $_modular_conf" >> . "$_modular_conf" >> done >>=20 >> might be better. There's some more magic that could ultimately = be done to make this more secure/robust using "-print0" | xargs, but = it's up to you how you might want to go about solving that problem. >> Also, I don't know if depending on a .conf file to be executable = is necessarily the best course of action. >=20 > Yeah I see what you are getting at there and I came across thinking = the=20 > same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep=20= > without using find(1). Yes, but the above method used avoids simple E2BIG problems. It just = doesn't properly deal with filenames that break on IFS, etc though = (that's part of where I was leading, but I said "security" instead. > As for the security sense if someone has a way to write to that = directory=20 > then most likely they are not going to be looking into placing = anything in=20 > that directory as theyll have rights to change anything under the rc = sun!=20 > plus anyting under most of the rest of the system. Yes that's true. BTW, what about $local_startup? > I do like the approach though. Thank you. Thanks :). -Garrett= From owner-freebsd-rc@FreeBSD.ORG Sun May 8 21:54:41 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9D8D106566C for ; Sun, 8 May 2011 21:54:41 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC648FC12 for ; Sun, 8 May 2011 21:54:41 +0000 (UTC) Received: by iwn33 with SMTP id 33so5507236iwn.13 for ; Sun, 08 May 2011 14:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=gR+wdfx0INHZlFKB05JEFQnLJ0OkBNhc21+nb6UAuCM=; b=brhbLVFY0Be2DfD5AcSF4igTXHKjPk6Msyh7P+R15xYupoI6MgonIO8TGcqoKhMjwY H/K7dy6SFYbnI+8T9GWxBpZaf1DmyOq9IA90gKATCB7L7E4amCDR2FRchlOBHMUkV7Ov XkNjVkmB1eurjrd/w6oAwO04XMu4VE630zQ6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=hznuZrMTZ+BWicJMOO5lHcWYYAruepVIcQf7Urls9yjqlpuX0WjINZMSWShyzjx78H dSfIfPmc3QMIij3mxgfU1tW1v/Hboud4SciAegvgWoawugTib6jOk12+llTrVKls1uwu XDpKgsWoNm1Mv6OHRHRarqzCOFAhiGSt3q5Co= Received: by 10.42.133.72 with SMTP id g8mr5566466ict.80.1304891680276; Sun, 08 May 2011 14:54:40 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id y10sm2346551iba.29.2011.05.08.14.54.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 14:54:39 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48LsYdj013411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 17:54:35 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48LsWu6013410; Sun, 8 May 2011 17:54:32 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 17:54:32 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110508215432.GG3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline In-Reply-To: <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Garrett Cooper , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 21:54:41 -0000 --ryJZkp9/svQ58syV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Sun, May 08, 2011 at 01:59:40PM -0700, Devin Teske wrote: >=20 > On May 8, 2011, at 1:13 PM, Garrett Cooper wrote: >=20 > > On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: > >=20 > >>=20 > >> List, - Please reply-to freebsd-rc@freebsd.org > >>=20 > >> Recently I have been going over some changes in the configurations tha= t=20 > >> are possible with the rc subsystem and to my dismay I have found some= =20 > >> inconsistencies with in particular the way rc.conf.d directory is=20 > >> processed and the arguments that are supplied to load_rc_config so I h= ave=20 > >> patched it up... > >>=20 > >> Let me explain: As determined by rc.subr load_rc_config, config's fro= m=20 > >> rc.conf.d are loaded by the scripts $name as an argument to load_rc_co= nfig=20 > >> and thus only the name being parsed is is available to be used in the= =20 > >> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient= as=20 > >> the user has no direct way to know that a variable used by nfsd is als= o=20 > >> needed by mountd or the same for various other scripts in the rc.d=20 > >> directory. At this time these config's are explained to be available f= or=20 > >> the user to utilize by rc.conf(5) but yet without much knowledge of th= e=20 > >> inner workings of the rc subsystem it would be quite the feat to do. > >>=20 > >>=20 > >> The attachment[1] keeps this functionality the same while introducing = a=20 > >> more convenient approach for the user to modularize their configuratio= n=20 > >> however they see fit within a couple constraints that work very well.= =20 > >>=20 > >>=20 > >> What does it do ?: As stated above, current functionality is undisturb= ed=20 > >> while allowing the user to create config's by any name they so desire = as=20 > >> long as it has an extension of ".conf", also introducing the ability t= o=20 > >> turn a configuration file off by using chmod(1). You can turn nfsc1.co= nf > >> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > >>=20 > >>=20 > >> Why ? Simple. How many times have you been bitten by disabling somethi= ng=20 > >> in the rc.conf file and left to discover what you just disabled was al= so=20 > >> used by another daemon but that daemon is now not starting ? This is a= way=20 > >> to virtualize your configuration allowing you to add multiple _enable= =3D=20 > >> lines to different configurations for different roles. For instance=20 > >> rpcbind is used by both samba and nfs*. With this you can add=20 > >> rpcbind_enable to both a configuration for samba and nfs and when you= =20 > >> disable one service you know that you have not disabled a dependent fo= r=20 > >> another. > >>=20 > >>=20 > >> This is a small addition that fixes currently broken undesirable aspec= ts=20 > >> of the configuration system that deals with the rc.conf.d directory wi= th a=20 > >> SysV style init approach that is just as flexible. This should apply= =20 > >> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedb= ack=20 > >> has been received Ill update the manual page with any suggestions=20 > >> regenerate the patch to accommodate and file a PR. > >>=20 > >>=20 > >> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch > >=20 > > Doing: > >=20 > > find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -pe= rm +111 | while read _modular_conf; do > > debug "Sourcing $_modular_conf" > > . "$_modular_conf" > > done > >=20 > > might be better. There's some more magic that could ultimately be done= to make this more secure/robust using "-print0" | xargs, but it's up to yo= u how you might want to go about solving that problem. > > Also, I don't know if depending on a .conf file to be executable is ne= cessarily the best course of action. > >=20 >=20 > First, let me add that I really like the idea. This makes it akin to our = /usr/local/apache2/conf.d/ directory where we place our various configs by = many names, but always ending in `.conf'. >=20 > I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/rc.= d/bar.conf, each configuring multiple (likely unrelated) services. >=20 > Better still, /etc/rc.d/jail1.conf, /etc/rc.d/jail2.conf, etc. etc. (I th= ink you just made my -- and everyone else whom uses jails -- day/week/month= /year). >=20 > However, I agree with GC that depending on a .conf file to be executable = is a bit non-standard, even if it is sourced like a shell-script (though I = can understand the historical heritage as /usr/local/etc/rc.d/ used to requ= ire both `.sh' suffix and executable bits; but that is not to condone treat= ing `rc.conf.d' like `rc.d' in any way). > I do agree with the -x bit concern yes. But thinking of the users to=20 enable disable a particular config without having to open a editor is=20 mainly why I have put that in place. It allows a lot of flexibility without= =20 a lot of extra work while also introducing the ability to check if a=20 particular configuration is enabled by checking the bit rather than=20 sourcing for a _enable. Since these are only config files there will/should never be a=20 config_enable for them as they are only config's, so providing a SysV init= =20 style way of enabling/disabling them at will is prime. using mv(1), rm(1)= =20 or possibly having to open a editor on multiple versions of the same=20 config to disable a certain portion is far from ideal. I really don't want to see the rc system subjected to a find(1) every time= =20 it needs to do a load_rc_config since it can be done quicker with in-shell= =20 testing. I think a lot of people would agree with this. I would suggest at least for those that doubt the SysV style way of=20 enabling disabling scripts give it a try for a couple weeks then report=20 back. If feed back is strong discouraging it then we can probably come to= =20 common ground and find a way to work with both those who would like it and= =20 those who don't by default. I do have a pretty good idea what would work=20 to make it happen both ways but I really would like to advocate this in=20 place as it is now first. Thanks you again Devin, Appreciate the feedback. --=20 Regards, (jhell) Jason Hellenthal --ryJZkp9/svQ58syV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxxEYAAoJEJBXh4mJ2FR+hSYH/2/h5KU+v/wqH46BKLqHDZbN iYygPjp4c3QI8ZDimL7t13XxCtg5zndvLEr09qsG5g085mvHuY3PMitPOlQ5rcX9 1Q0TH1+tlWl9X92qCEfRoSGDS3Rs3otvfsOzeeZbxMgBxy1bU5mNNdfylZ6l/A05 p80K+/gYZqN0U2BNOOeFy2bb1qCfBiVDuk3n0XaIKQJdUKs1vr4GMNKd54Ft5r/9 spr2R0FtDSgk2cFzH+s5tbuFmgH4Yyg3Z7n+0bL8mDr5vTNVVXZDTCEGdoGUihXp X6moaipShOBtXIew6oWt86lVNYUG2I80o40z/1Q59aGvKQ3Nt+JuPwDgxuFmCJM= =q7WR -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV-- From owner-freebsd-rc@FreeBSD.ORG Sun May 8 22:08:38 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F26C106564A for ; Sun, 8 May 2011 22:08:38 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 215A78FC12 for ; Sun, 8 May 2011 22:08:37 +0000 (UTC) Received: by iwn33 with SMTP id 33so5513228iwn.13 for ; Sun, 08 May 2011 15:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=9tGcRt02f19jMVxq/nIRbbUqeRZtXx+NSHXG5WcKMUA=; b=SCbvEB2qT34fB9enexSTArWiFavHXzQtoDpdWIGVCpjqGzmikUH+Fa1FEs+xpvKfi0 kxCThXTZuWOGWJEArymmIIi3lFFCGYox22goZsyHgbVOKNMlUhDP0eUKJK810k/XRXXt 1SlatKgcf4WfFgSwzMKXxKt6DXJwh82jAUz3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=rGGopenCtrj/MTwXHDWtYwTCAKykm8h9zs8K44cLtg4Jbzc+zMsqGk4ndeScHPiq6q n3KPDIC14tIrfCWKHjD6IzEJCQYl3jKqhu+2fi2FNISMuTSAzUlazT1+O6sc+z/FQOGW P5/ke2amwJOOoflLRhJe+A2H24QjmCcPZkta4= Received: by 10.42.53.77 with SMTP id m13mr5559162icg.444.1304892517307; Sun, 08 May 2011 15:08:37 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id 14sm2349346ibc.59.2011.05.08.15.08.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 15:08:35 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48M8WYB014224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 18:08:33 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48M8W6U014223; Sun, 8 May 2011 18:08:32 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 18:08:32 -0400 From: Jason Hellenthal To: Garrett Cooper Message-ID: <20110508220832.GH3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <20110508202636.GF3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pql/uPZNXIm1JCle" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 22:08:38 -0000 --Pql/uPZNXIm1JCle Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garrett, On Sun, May 08, 2011 at 02:19:17PM -0700, Garrett Cooper wrote: > On May 8, 2011, at 1:26 PM, Jason Hellenthal wrote: >=20 > >=20 > > Garrett, > >=20 > > On Sun, May 08, 2011 at 01:13:12PM -0700, Garrett Cooper wrote: > >> On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: > >>=20 > >>>=20 > >>> List, - Please reply-to freebsd-rc@freebsd.org > >>>=20 > >>> Recently I have been going over some changes in the configurations th= at=20 > >>> are possible with the rc subsystem and to my dismay I have found some= =20 > >>> inconsistencies with in particular the way rc.conf.d directory is=20 > >>> processed and the arguments that are supplied to load_rc_config so I = have=20 > >>> patched it up... > >>>=20 > >>> Let me explain: As determined by rc.subr load_rc_config, config's fr= om=20 > >>> rc.conf.d are loaded by the scripts $name as an argument to load_rc_c= onfig=20 > >>> and thus only the name being parsed is is available to be used in the= =20 > >>> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenien= t as=20 > >>> the user has no direct way to know that a variable used by nfsd is al= so=20 > >>> needed by mountd or the same for various other scripts in the rc.d=20 > >>> directory. At this time these config's are explained to be available = for=20 > >>> the user to utilize by rc.conf(5) but yet without much knowledge of t= he=20 > >>> inner workings of the rc subsystem it would be quite the feat to do. > >>>=20 > >>>=20 > >>> The attachment[1] keeps this functionality the same while introducing= a=20 > >>> more convenient approach for the user to modularize their configurati= on=20 > >>> however they see fit within a couple constraints that work very well.= =20 > >>>=20 > >>>=20 > >>> What does it do ?: As stated above, current functionality is undistur= bed=20 > >>> while allowing the user to create config's by any name they so desire= as=20 > >>> long as it has an extension of ".conf", also introducing the ability = to=20 > >>> turn a configuration file off by using chmod(1). You can turn nfsc1.c= onf > >>> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > >>>=20 > >>>=20 > >>> Why ? Simple. How many times have you been bitten by disabling someth= ing=20 > >>> in the rc.conf file and left to discover what you just disabled was a= lso=20 > >>> used by another daemon but that daemon is now not starting ? This is = a way=20 > >>> to virtualize your configuration allowing you to add multiple _enable= =3D=20 > >>> lines to different configurations for different roles. For instance= =20 > >>> rpcbind is used by both samba and nfs*. With this you can add=20 > >>> rpcbind_enable to both a configuration for samba and nfs and when you= =20 > >>> disable one service you know that you have not disabled a dependent f= or=20 > >>> another. > >>>=20 > >>>=20 > >>> This is a small addition that fixes currently broken undesirable aspe= cts=20 > >>> of the configuration system that deals with the rc.conf.d directory w= ith a=20 > >>> SysV style init approach that is just as flexible. This should apply= =20 > >>> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feed= back=20 > >>> has been received Ill update the manual page with any suggestions=20 > >>> regenerate the patch to accommodate and file a PR. > >>>=20 > >>>=20 > >>> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch > >>=20 > >> Doing: > >>=20 > >> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -p= erm +111 | while read _modular_conf; do > >> debug "Sourcing $_modular_conf" > >> . "$_modular_conf" > >> done > >>=20 > >> might be better. There's some more magic that could ultimately be don= e to make this more secure/robust using "-print0" | xargs, but it's up to y= ou how you might want to go about solving that problem. > >> Also, I don't know if depending on a .conf file to be executable is n= ecessarily the best course of action. > >=20 > > Yeah I see what you are getting at there and I came across thinking the= =20 > > same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep=20 > > without using find(1). >=20 > Yes, but the above method used avoids simple E2BIG problems. It just does= n't properly deal with filenames that break on IFS, etc though (that's part= of where I was leading, but I said "security" instead. >=20 > > As for the security sense if someone has a way to write to that directo= ry=20 > > then most likely they are not going to be looking into placing anything= in=20 > > that directory as theyll have rights to change anything under the rc su= n!=20 > > plus anyting under most of the rest of the system. >=20 > Yes that's true. BTW, what about $local_startup? I can do that. I can see why that would be an awesome aspect to provide.=20 If its available it would be nice if ports could just dump example configs= =20 in there un-enabled waiting to be edited. Ill get to that in a while. At least for the moment the same thing is=20 still possible through /etc/rc.conf.d/ for any port that uses the rc=20 subsystem as it works just like rc.conf. >=20 > > I do like the approach though. Thank you. >=20 --=20 Regards, (jhell) Jason Hellenthal --Pql/uPZNXIm1JCle Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxxRfAAoJEJBXh4mJ2FR+eroIAJ+ArcIPmOg/jHQpMTdq+hDW CBUeoKZBGWmbZFwwtB3jfBHMOAdsy4ehKyimnDQx/yv1BskEs+FiY+nmZcDEcW94 PKZzOoCOv+tz5hIxHj33m9d5QTBhFxst0Y1HMSZfr/zKDB7ho32RzE41FtsHDENF 0Gn6q6CZFW81OLEeoihrwwJ+iEjNdmSAUcASID3T1JLmDlNB3Zke/yELyP0/AfSe eG41WZHux/7IUOX+a/1a2D9Zmwhfet/w9PmHsFPiRqyWfvC1DAL9ZZl2S1618Gq5 D2f/S29HeSvfIncMh2v5+wwyyoBVN2xQrGBJPuDlfGLBQHvFiFDF+AL2+PKA2r4= =tbvP -----END PGP SIGNATURE----- --Pql/uPZNXIm1JCle-- From owner-freebsd-rc@FreeBSD.ORG Sun May 8 22:11:31 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BCA0106566C for ; Sun, 8 May 2011 22:11:31 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC4A8FC0A for ; Sun, 8 May 2011 22:11:31 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id C8A22359324; Mon, 9 May 2011 00:11:29 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id B397117400; Mon, 9 May 2011 00:11:29 +0200 (CEST) Date: Mon, 9 May 2011 00:11:29 +0200 From: Jilles Tjoelker To: Garrett Cooper Message-ID: <20110508221129.GA89657@stack.nl> References: <20110508191336.GC3527@DataIX.net> <20110508202636.GF3527@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jason Hellenthal , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 22:11:31 -0000 On Sun, May 08, 2011 at 02:19:17PM -0700, Garrett Cooper wrote: > >> Doing: > >> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -perm +111 | while read _modular_conf; do > >> debug "Sourcing $_modular_conf" > >> . "$_modular_conf" > >> done > >> might be better. There's some more magic that could ultimately be done to make this more secure/robust using "-print0" | xargs, but it's up to you how you might want to go about solving that problem. > >> Also, I don't know if depending on a .conf file to be executable is necessarily the best course of action. > > Yeah I see what you are getting at there and I came across thinking the > > same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep > > without using find(1). > Yes, but the above method used avoids simple E2BIG problems. It just > doesn't properly deal with filenames that break on IFS, etc though > (that's part of where I was leading, but I said "security" instead. I would say the opposite. jhell's original loop + for _modular_conf in /etc/rc.conf.d/*.conf; do + if [ -f "$_modular_conf" -a -x "$_modular_conf" ]; then + debug "Sourcing $_modular_conf" + . $_modular_conf + fi + done with a small change - . $_modular_conf + . "$_modular_conf" does not have any E2BIG problems, and also no problems with special characters. This is because the list of pathnames stays within sh; it is not passed to another program. If there is no matching file, the loop runs once for /etc/rc.conf.d/*.conf which does not exist and is therefore not sourced. Any 'while read...' loop will handle pathnames with newlines incorrectly, and the simple ones also handle backslashes and certain whitespace incorrectly. Also, the proposed pipeline does not even work as the while loop is executed in a subshell, so the assignments in the sourced files are lost. This post is not an endorsement of jhell's idea. I am not really convinced it is useful. For experimenting, the for command can be placed in /etc/rc.conf. -- Jilles Tjoelker From owner-freebsd-rc@FreeBSD.ORG Sun May 8 22:35:40 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA2B106564A for ; Sun, 8 May 2011 22:35:40 +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 C93E08FC08 for ; Sun, 8 May 2011 22:35:39 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p48MZc3Z018882; Sun, 8 May 2011 17:35:38 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 17:35:48 -0500 Received: from sbhfisltcgw01.FNFIS.COM ([10.132.248.121]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 17:35:37 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by sbhfisltcgw01.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 17:35:36 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: <20110508215432.GG3527@DataIX.net> Date: Sun, 8 May 2011 15:35:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 22:35:36.0504 (UTC) FILETIME=[40009380:01CC0DD0] Cc: Garrett Cooper , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 22:35:40 -0000 Jason, On May 8, 2011, at 2:54 PM, Jason Hellenthal wrote: >=20 > Devin, >=20 > On Sun, May 08, 2011 at 01:59:40PM -0700, Devin Teske wrote: >>=20 >> On May 8, 2011, at 1:13 PM, Garrett Cooper wrote: >>=20 >>> On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >>>=20 >>>>=20 >>>> List, - Please reply-to freebsd-rc@freebsd.org >>>>=20 >>>> Recently I have been going over some changes in the configurations tha= t=20 >>>> are possible with the rc subsystem and to my dismay I have found some= =20 >>>> inconsistencies with in particular the way rc.conf.d directory is=20 >>>> processed and the arguments that are supplied to load_rc_config so I h= ave=20 >>>> patched it up... >>>>=20 >>>> Let me explain: As determined by rc.subr load_rc_config, config's fro= m=20 >>>> rc.conf.d are loaded by the scripts $name as an argument to load_rc_co= nfig=20 >>>> and thus only the name being parsed is is available to be used in the= =20 >>>> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient= as=20 >>>> the user has no direct way to know that a variable used by nfsd is als= o=20 >>>> needed by mountd or the same for various other scripts in the rc.d=20 >>>> directory. At this time these config's are explained to be available f= or=20 >>>> the user to utilize by rc.conf(5) but yet without much knowledge of th= e=20 >>>> inner workings of the rc subsystem it would be quite the feat to do. >>>>=20 >>>>=20 >>>> The attachment[1] keeps this functionality the same while introducing = a=20 >>>> more convenient approach for the user to modularize their configuratio= n=20 >>>> however they see fit within a couple constraints that work very well.= =20 >>>>=20 >>>>=20 >>>> What does it do ?: As stated above, current functionality is undisturb= ed=20 >>>> while allowing the user to create config's by any name they so desire = as=20 >>>> long as it has an extension of ".conf", also introducing the ability t= o=20 >>>> turn a configuration file off by using chmod(1). You can turn nfsc1.co= nf >>>> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf >>>>=20 >>>>=20 >>>> Why ? Simple. How many times have you been bitten by disabling somethi= ng=20 >>>> in the rc.conf file and left to discover what you just disabled was al= so=20 >>>> used by another daemon but that daemon is now not starting ? This is a= way=20 >>>> to virtualize your configuration allowing you to add multiple _enable= =3D=20 >>>> lines to different configurations for different roles. For instance=20 >>>> rpcbind is used by both samba and nfs*. With this you can add=20 >>>> rpcbind_enable to both a configuration for samba and nfs and when you= =20 >>>> disable one service you know that you have not disabled a dependent fo= r=20 >>>> another. >>>>=20 >>>>=20 >>>> This is a small addition that fixes currently broken undesirable aspec= ts=20 >>>> of the configuration system that deals with the rc.conf.d directory wi= th a=20 >>>> SysV style init approach that is just as flexible. This should apply= =20 >>>> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedb= ack=20 >>>> has been received Ill update the manual page with any suggestions=20 >>>> regenerate the patch to accommodate and file a PR. >>>>=20 >>>>=20 >>>> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >>>=20 >>> Doing: >>>=20 >>> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -pe= rm +111 | while read _modular_conf; do >>> debug "Sourcing $_modular_conf" >>> . "$_modular_conf" >>> done >>>=20 >>> might be better. There's some more magic that could ultimately be done= to make this more secure/robust using "-print0" | xargs, but it's up to yo= u how you might want to go about solving that problem. >>> Also, I don't know if depending on a .conf file to be executable is ne= cessarily the best course of action. >>>=20 >>=20 >> First, let me add that I really like the idea. This makes it akin to our= /usr/local/apache2/conf.d/ directory where we place our various configs by= many names, but always ending in `.conf'. >>=20 >> I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/rc= .d/bar.conf, each configuring multiple (likely unrelated) services. >>=20 >> Better still, /etc/rc.d/jail1.conf, /etc/rc.d/jail2.conf, etc. etc. (I t= hink you just made my -- and everyone else whom uses jails -- day/week/mont= h/year). >>=20 >> However, I agree with GC that depending on a .conf file to be executable= is a bit non-standard, even if it is sourced like a shell-script (though I= can understand the historical heritage as /usr/local/etc/rc.d/ used to req= uire both `.sh' suffix and executable bits; but that is not to condone trea= ting `rc.conf.d' like `rc.d' in any way). >>=20 >=20 > I do agree with the -x bit concern yes. But thinking of the users to=20 > enable disable a particular config without having to open a editor is=20 What about: cd /etc/rc.conf.d mv myfoo.conf{,.bak} Simply renaming the file to not end in ".conf" should suffice. This should = counter the need for checking if the file is executable (which I still clai= m is a bit odd). > mainly why I have put that in place. It allows a lot of flexibility witho= ut=20 > a lot of extra work while also introducing the ability to check if a=20 > particular configuration is enabled by checking the bit rather than=20 > sourcing for a _enable. >=20 > Since these are only config files there will/should never be a=20 > config_enable for them as they are only config's, so providing a SysV ini= t=20 > style way of enabling/disabling them at will is prime. using mv(1), rm(1)= =20 > or possibly having to open a editor on multiple versions of the same=20 > config to disable a certain portion is far from ideal. Wouldn't it be easier to explain to a novice that "if the file ends in ``.c= onf''" (period) rather than "if the file ends in ``.conf'' and its executab= le bit is set"? I'd think the former is simpler than the latter and that the user can simpl= y use mv(1). >=20 > I really don't want to see the rc system subjected to a find(1) every tim= e=20 > it needs to do a load_rc_config since it can be done quicker with in-shel= l=20 > testing. I think a lot of people would agree with this. I didn't say anything about using find (that was GC). But while we're talki= ng about it... I agree on that point. I'd think this would be much faster (and be tolerant= of files with spaces in their name; though not newlines): ls /etc/rc.conf.d/*.conf | ( IFS=3D' ' while read file; do [ -f "$file" ] || continue . "$file" || exit $FAILURE done ) || debug "something went wrong" Keeping to ls(1) and shell builtins. >=20 > I would suggest at least for those that doubt the SysV style way of=20 > enabling disabling scripts give it a try for a couple weeks then report= =20 GC and I aren't arguing that the SysV style is not helpful (if I read GC's = post correctly). Just that these aren't wholly to-be considered SysV system= startup scripts, but instead "config files". If they had an interpreter sh= e-bang (e.g., #!/bin/sh), program-flow, or other logic, I'd not disagree wi= th the checking of the executable bit. But since these files are by-design = going to nearly always be KEY=3DVALUE pairs, I find it odd to think of them= as anything other than just regular text files. I think of the files in /etc/rc.conf.d/ as extensions of rc.conf(5) and the= notion that permissions might possibly matter on rc.conf(5) would be equal= ly foreign to me. I'm aware that both rc.conf(5), the local variant, and newly-conceived rc.c= onf.d/*.conf are really in-truth just shell scripts sourced into the curren= t interpreter. So in-reality they can contain any valid sh(1) syntax. Thoug= h in-practice the only script of its kind that routinely contains more than= just KEY=3DVALUE pairs is /etc/defaults/rc.conf (which defines the `source= _rc_confs' function). However, I find it to be more common that engineers and technicians think o= f rc.conf(5) as a flat text file, and thus will think of the `*.conf' files= in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection that = the any permission other than the read-bit be checked. > back. If feed back is strong discouraging it then we can probably come to= =20 > common ground and find a way to work with both those who would like it an= d=20 > those who don't by default. I do have a pretty good idea what would work= =20 > to make it happen both ways but I really would like to advocate this in= =20 > place as it is now first. I think that I could live with the read-bit being a toggle. However, the mo= re experienced user may scratch his head, rationalizing that `root' should = be able to read anything (that is, unless something explicitly prevents it = such as perhaps TrustedBSD MACs). Right now, I'm still thinking that the best solution is to: a. Put into packages: /etc/rc.conf.d/name.conf.sample b. User enablement: mv /etc/rc.conf.d/name.conf{.sample,} c. User disablement: mv /etc/rc.conf.d/name.conf{,.bak} That's at least how I tend to think/operate. I know I can't speak for all o= f the dozens of field engineers in our corporation, but I've at least witne= ssed this behavior as a standard while troubleshooting machines. > Thanks you again Devin, Appreciate the feedback. No problem. I always appreciate yours as well. --=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. _____________ From owner-freebsd-rc@FreeBSD.ORG Sun May 8 22:43:34 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC10E106564A for ; Sun, 8 May 2011 22:43:34 +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 839B08FC12 for ; Sun, 8 May 2011 22:43:34 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p48MhXx8011123; Sun, 8 May 2011 17:43:33 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 17:43:34 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 17:43:33 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 17:43:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: <20110508221129.GA89657@stack.nl> Date: Sun, 8 May 2011 15:43:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110508191336.GC3527@DataIX.net> <20110508202636.GF3527@DataIX.net> <20110508221129.GA89657@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 22:43:33.0112 (UTC) FILETIME=[5C152F80:01CC0DD1] Cc: Garrett Cooper , Jason Hellenthal , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 22:43:34 -0000 Jilles, On May 8, 2011, at 3:11 PM, Jilles Tjoelker wrote: > On Sun, May 08, 2011 at 02:19:17PM -0700, Garrett Cooper wrote: >>>> Doing: >=20 >>>> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -p= erm +111 | while read _modular_conf; do >>>> debug "Sourcing $_modular_conf" >>>> . "$_modular_conf" >>>> done >=20 >>>> might be better. There's some more magic that could ultimately be don= e to make this more secure/robust using "-print0" | xargs, but it's up to y= ou how you might want to go about solving that problem. >>>> Also, I don't know if depending on a .conf file to be executable is n= ecessarily the best course of action. >=20 >>> Yeah I see what you are getting at there and I came across thinking the= =20 >>> same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep=20 >>> without using find(1). >=20 >> Yes, but the above method used avoids simple E2BIG problems. It just >> doesn't properly deal with filenames that break on IFS, etc though >> (that's part of where I was leading, but I said "security" instead. >=20 > I would say the opposite. jhell's original loop >=20 > + for _modular_conf in /etc/rc.conf.d/*.conf; do NICE! I'm tucking that one away in the frontal lobes. I didn't know `for' could glob directory contents like that. Even works all the way back to FreeBSD-4.11. --=20 Cheers, Devin > + if [ -f "$_modular_conf" -a -x "$_modular_conf" ]; then > + debug "Sourcing $_modular_conf" > + . $_modular_conf > + fi > + done >=20 > with a small change > - . $_modular_conf > + . "$_modular_conf" >=20 > does not have any E2BIG problems, and also no problems with special > characters. This is because the list of pathnames stays within sh; it is > not passed to another program. If there is no matching file, the loop > runs once for /etc/rc.conf.d/*.conf which does not exist and is > therefore not sourced. >=20 > Any 'while read...' loop will handle pathnames with newlines > incorrectly, and the simple ones also handle backslashes and certain > whitespace incorrectly. Also, the proposed pipeline does not even work > as the while loop is executed in a subshell, so the assignments in the > sourced files are lost. >=20 > This post is not an endorsement of jhell's idea. I am not really > convinced it is useful. For experimenting, the for command can be placed > in /etc/rc.conf. >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" _____________ 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Sun May 8 22:52:11 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E3E91065670 for ; Sun, 8 May 2011 22:52:11 +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 555958FC12 for ; Sun, 8 May 2011 22:52:11 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p48Mq99V018524; Sun, 8 May 2011 17:52:10 -0500 Received: from sbhfisltcgw02.FNFIS.COM (Not Verified[10.132.248.122]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 17:52:11 -0500 Received: from SBHFISLTCGW07.FNFIS.COM ([10.132.248.135]) by sbhfisltcgw02.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 17:52:09 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW07.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 17:52:08 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: Date: Sun, 8 May 2011 15:52:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> To: Devin Teske X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 May 2011 22:52:09.0268 (UTC) FILETIME=[8FBC5740:01CC0DD2] Cc: Garrett Cooper , Jason Hellenthal , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 22:52:11 -0000 On May 8, 2011, at 3:35 PM, Devin Teske wrote: > Jason, >=20 > On May 8, 2011, at 2:54 PM, Jason Hellenthal wrote: >=20 >>=20 >> Devin, >>=20 >> On Sun, May 08, 2011 at 01:59:40PM -0700, Devin Teske wrote: >>>=20 >>> On May 8, 2011, at 1:13 PM, Garrett Cooper wrote: >>>=20 >>>> On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: >>>>=20 >>>>>=20 >>>>> List, - Please reply-to freebsd-rc@freebsd.org >>>>>=20 >>>>> Recently I have been going over some changes in the configurations th= at=20 >>>>> are possible with the rc subsystem and to my dismay I have found some= =20 >>>>> inconsistencies with in particular the way rc.conf.d directory is=20 >>>>> processed and the arguments that are supplied to load_rc_config so I = have=20 >>>>> patched it up... >>>>>=20 >>>>> Let me explain: As determined by rc.subr load_rc_config, config's fr= om=20 >>>>> rc.conf.d are loaded by the scripts $name as an argument to load_rc_c= onfig=20 >>>>> and thus only the name being parsed is is available to be used in the= =20 >>>>> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenien= t as=20 >>>>> the user has no direct way to know that a variable used by nfsd is al= so=20 >>>>> needed by mountd or the same for various other scripts in the rc.d=20 >>>>> directory. At this time these config's are explained to be available = for=20 >>>>> the user to utilize by rc.conf(5) but yet without much knowledge of t= he=20 >>>>> inner workings of the rc subsystem it would be quite the feat to do. >>>>>=20 >>>>>=20 >>>>> The attachment[1] keeps this functionality the same while introducing= a=20 >>>>> more convenient approach for the user to modularize their configurati= on=20 >>>>> however they see fit within a couple constraints that work very well.= =20 >>>>>=20 >>>>>=20 >>>>> What does it do ?: As stated above, current functionality is undistur= bed=20 >>>>> while allowing the user to create config's by any name they so desire= as=20 >>>>> long as it has an extension of ".conf", also introducing the ability = to=20 >>>>> turn a configuration file off by using chmod(1). You can turn nfsc1.c= onf >>>>> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf >>>>>=20 >>>>>=20 >>>>> Why ? Simple. How many times have you been bitten by disabling someth= ing=20 >>>>> in the rc.conf file and left to discover what you just disabled was a= lso=20 >>>>> used by another daemon but that daemon is now not starting ? This is = a way=20 >>>>> to virtualize your configuration allowing you to add multiple _enable= =3D=20 >>>>> lines to different configurations for different roles. For instance= =20 >>>>> rpcbind is used by both samba and nfs*. With this you can add=20 >>>>> rpcbind_enable to both a configuration for samba and nfs and when you= =20 >>>>> disable one service you know that you have not disabled a dependent f= or=20 >>>>> another. >>>>>=20 >>>>>=20 >>>>> This is a small addition that fixes currently broken undesirable aspe= cts=20 >>>>> of the configuration system that deals with the rc.conf.d directory w= ith a=20 >>>>> SysV style init approach that is just as flexible. This should apply= =20 >>>>> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feed= back=20 >>>>> has been received Ill update the manual page with any suggestions=20 >>>>> regenerate the patch to accommodate and file a PR. >>>>>=20 >>>>>=20 >>>>> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >>>>=20 >>>> Doing: >>>>=20 >>>> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -p= erm +111 | while read _modular_conf; do >>>> debug "Sourcing $_modular_conf" >>>> . "$_modular_conf" >>>> done >>>>=20 >>>> might be better. There's some more magic that could ultimately be don= e to make this more secure/robust using "-print0" | xargs, but it's up to y= ou how you might want to go about solving that problem. >>>> Also, I don't know if depending on a .conf file to be executable is n= ecessarily the best course of action. >>>>=20 >>>=20 >>> First, let me add that I really like the idea. This makes it akin to ou= r /usr/local/apache2/conf.d/ directory where we place our various configs b= y many names, but always ending in `.conf'. >>>=20 >>> I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/r= c.d/bar.conf, each configuring multiple (likely unrelated) services. >>>=20 >>> Better still, /etc/rc.d/jail1.conf, /etc/rc.d/jail2.conf, etc. etc. (I = think you just made my -- and everyone else whom uses jails -- day/week/mon= th/year). >>>=20 >>> However, I agree with GC that depending on a .conf file to be executabl= e is a bit non-standard, even if it is sourced like a shell-script (though = I can understand the historical heritage as /usr/local/etc/rc.d/ used to re= quire both `.sh' suffix and executable bits; but that is not to condone tre= ating `rc.conf.d' like `rc.d' in any way). >>>=20 >>=20 >> I do agree with the -x bit concern yes. But thinking of the users to=20 >> enable disable a particular config without having to open a editor is=20 >=20 > What about: >=20 > cd /etc/rc.conf.d > mv myfoo.conf{,.bak} >=20 > Simply renaming the file to not end in ".conf" should suffice. This shoul= d counter the need for checking if the file is executable (which I still cl= aim is a bit odd). >=20 >=20 >> mainly why I have put that in place. It allows a lot of flexibility with= out=20 >> a lot of extra work while also introducing the ability to check if a=20 >> particular configuration is enabled by checking the bit rather than=20 >> sourcing for a _enable. >>=20 >> Since these are only config files there will/should never be a=20 >> config_enable for them as they are only config's, so providing a SysV in= it=20 >> style way of enabling/disabling them at will is prime. using mv(1), rm(1= )=20 >> or possibly having to open a editor on multiple versions of the same=20 >> config to disable a certain portion is far from ideal. >=20 > Wouldn't it be easier to explain to a novice that "if the file ends in ``= .conf''" (period) rather than "if the file ends in ``.conf'' and its execut= able bit is set"? >=20 > I'd think the former is simpler than the latter and that the user can sim= ply use mv(1). >=20 >=20 >>=20 >> I really don't want to see the rc system subjected to a find(1) every ti= me=20 >> it needs to do a load_rc_config since it can be done quicker with in-she= ll=20 >> testing. I think a lot of people would agree with this. >=20 > I didn't say anything about using find (that was GC). But while we're tal= king about it... >=20 > I agree on that point. I'd think this would be much faster (and be tolera= nt of files with spaces in their name; though not newlines): >=20 > ls /etc/rc.conf.d/*.conf | ( IFS=3D' > ' > while read file; do > [ -f "$file" ] || continue > . "$file" || exit $FAILURE > done > ) || debug "something went wrong" >=20 > Keeping to ls(1) and shell builtins. Ignore that implementation. I second Jilles all-builtin solution using `for' globbing (no forking exter= nal processes or sub-shells). Slight modification for brevity: for _modular_conf in /etc/rc.conf.d/*.conf; do [ -f "$_modular_conf" -a -x "$_modular_conf" ] || continue debug "Sourcing $_modular_conf" . "$_modular_conf" done Though I still think it ought to be: for _modular_conf in /etc/rc.conf.d/*.conf; do [ -f "$_modular_conf" ] || continue debug "Sourcing $_modular_conf" . "$_modular_conf" done Tuppence. --=20 Cheers, Devin >=20 >=20 >>=20 >> I would suggest at least for those that doubt the SysV style way of=20 >> enabling disabling scripts give it a try for a couple weeks then report= =20 >=20 > GC and I aren't arguing that the SysV style is not helpful (if I read GC'= s post correctly). Just that these aren't wholly to-be considered SysV syst= em startup scripts, but instead "config files". If they had an interpreter = she-bang (e.g., #!/bin/sh), program-flow, or other logic, I'd not disagree = with the checking of the executable bit. But since these files are by-desig= n going to nearly always be KEY=3DVALUE pairs, I find it odd to think of th= em as anything other than just regular text files. >=20 > I think of the files in /etc/rc.conf.d/ as extensions of rc.conf(5) and t= he notion that permissions might possibly matter on rc.conf(5) would be equ= ally foreign to me. >=20 > I'm aware that both rc.conf(5), the local variant, and newly-conceived rc= .conf.d/*.conf are really in-truth just shell scripts sourced into the curr= ent interpreter. So in-reality they can contain any valid sh(1) syntax. Tho= ugh in-practice the only script of its kind that routinely contains more th= an just KEY=3DVALUE pairs is /etc/defaults/rc.conf (which defines the `sour= ce_rc_confs' function). >=20 > However, I find it to be more common that engineers and technicians think= of rc.conf(5) as a flat text file, and thus will think of the `*.conf' fil= es in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection tha= t the any permission other than the read-bit be checked. >=20 >=20 >> back. If feed back is strong discouraging it then we can probably come t= o=20 >> common ground and find a way to work with both those who would like it a= nd=20 >> those who don't by default. I do have a pretty good idea what would work= =20 >> to make it happen both ways but I really would like to advocate this in= =20 >> place as it is now first. >=20 > I think that I could live with the read-bit being a toggle. However, the = more experienced user may scratch his head, rationalizing that `root' shoul= d be able to read anything (that is, unless something explicitly prevents i= t such as perhaps TrustedBSD MACs). >=20 > Right now, I'm still thinking that the best solution is to: >=20 > a. Put into packages: /etc/rc.conf.d/name.conf.sample > b. User enablement: mv /etc/rc.conf.d/name.conf{.sample,} > c. User disablement: mv /etc/rc.conf.d/name.conf{,.bak} >=20 > That's at least how I tend to think/operate. I know I can't speak for all= of the dozens of field engineers in our corporation, but I've at least wit= nessed this behavior as a standard while troubleshooting machines. >=20 >=20 >> Thanks you again Devin, Appreciate the feedback. >=20 > No problem. I always appreciate yours as well. > --=20 > Devin >=20 > _____________ >=20 > The information contained in this message is proprietary and/or confident= ial. 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 awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. > _____________ > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" _____________ 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Sun May 8 23:25:15 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D071065674 for ; Sun, 8 May 2011 23:25:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3918FC18 for ; Sun, 8 May 2011 23:25:14 +0000 (UTC) Received: by vxc34 with SMTP id 34so7048612vxc.13 for ; Sun, 08 May 2011 16:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ybuaf+TStQmDwnzIItLToLrbTj8927XeluYGUjg2M2I=; b=r4ugD+uw+CUJ9kV5hgYbDozUlIDCOji+FxJQBVKUuUaiCeF4gv4/hXA2UiZRujeHa8 Xx6aYsgdEpt8O1Pmam6pLBicYFBu+Wv5JNo5HO5dN7UdE8sGW5s8B/eFEVR9AUStpTmq iSnANDw0s64rTuIHgSsVjL3RHMk7/pwNm/iFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P6Ge0gN6iRAlX4ubYs/iwh6mLlHAV1g+nJ4m2ZSZ55XMj4cyyBlkz+J0a54sATcOw1 j8ZOmttupS3EhpcVGYV8nmz5ULQSTJMS1lsj9peditbFcrZjI6yItkG7o5LbybUFhRO2 FpvgyjYLwP3Od87ugrytTMq8i+ePQwxgzzb8Q= MIME-Version: 1.0 Received: by 10.52.181.168 with SMTP id dx8mr2071867vdc.172.1304897114223; Sun, 08 May 2011 16:25:14 -0700 (PDT) Received: by 10.220.202.134 with HTTP; Sun, 8 May 2011 16:25:14 -0700 (PDT) In-Reply-To: <20110508221129.GA89657@stack.nl> References: <20110508191336.GC3527@DataIX.net> <20110508202636.GF3527@DataIX.net> <20110508221129.GA89657@stack.nl> Date: Sun, 8 May 2011 16:25:14 -0700 Message-ID: From: Garrett Cooper To: Jilles Tjoelker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 23:25:15 -0000 On Sun, May 8, 2011 at 3:11 PM, Jilles Tjoelker wrote: > On Sun, May 08, 2011 at 02:19:17PM -0700, Garrett Cooper wrote: >> >> =A0 =A0Doing: > >> >> find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -= perm +111 | while read _modular_conf; do >> >> =A0 =A0debug "Sourcing $_modular_conf" >> >> =A0 =A0. "$_modular_conf" >> >> done > >> >> =A0 =A0might be better. There's some more magic that could ultimately= be done to make this more secure/robust using "-print0" | xargs, but it's = up to you how you might want to go about solving that problem. >> >> =A0 =A0Also, I don't know if depending on a .conf file to be executab= le is necessarily the best course of action. > >> > Yeah I see what you are getting at there and I came across thinking th= e >> > same thing. Fortunately /etc/rc.conf.d/*.conf is only one level deep >> > without using find(1). > >> Yes, but the above method used avoids simple E2BIG problems. It just >> doesn't properly deal with filenames that break on IFS, etc though >> (that's part of where I was leading, but I said "security" instead. > > I would say the opposite. jhell's original loop > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for _modular_conf in /etc/rc.conf.d/*.conf;= do > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ -f "$_modular_conf" -a= -x "$_modular_conf" ]; then > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 debug "Sour= cing $_modular_conf" > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . $_modular= _conf > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fi > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 done > > with a small change > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . $_modular= _conf > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . "$_modula= r_conf" > > does not have any E2BIG problems, and also no problems with special > characters. This is because the list of pathnames stays within sh; it is > not passed to another program. If there is no matching file, the loop > runs once for /etc/rc.conf.d/*.conf which does not exist and is > therefore not sourced. Hmmm... ok. Didn't realize that. As a bonus point -- is that an extension of our shell, or is this standard behavior in all shells? > Any 'while read...' loop will handle pathnames with newlines > incorrectly, and the simple ones also handle backslashes and certain > whitespace incorrectly. Also, the proposed pipeline does not even work > as the while loop is executed in a subshell, so the assignments in the > sourced files are lost. Ah drat... I forgot that our shell does subshells with pipelines. Thanks Jilles for the correction ><.. > This post is not an endorsement of jhell's idea. I am not really > convinced it is useful. For experimenting, the for command can be placed > in /etc/rc.conf. -Garrett From owner-freebsd-rc@FreeBSD.ORG Mon May 9 00:23:56 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDF61065673 for ; Mon, 9 May 2011 00:23:56 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4958FC12 for ; Mon, 9 May 2011 00:23:56 +0000 (UTC) Received: by iyj12 with SMTP id 12so5620921iyj.13 for ; Sun, 08 May 2011 17:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=pghBJ5VXtC4JCoqqu8daQbSmlaHigInZAWiHFKldsOw=; b=mXG0TXNWnv1jf/m3+N75jw4DOk8AobynSGjyPBRY9ITqR3zAe3oAJs+aR9kZRWQiJu NrwLzLydZn7K5FsGQxkC1PMt+B1oE/9WbaU3M6VinrlrTT52x5VB208XbTwK3gDN6WGJ e+tDp+jl3XDTt63WDu8lqfABNF8stUBgVlkvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=KRx5ecJJTYAkTrBcdFcC4MqwIB+2HeH68UfxM/vMnJFYp9XsCSF05JqQTJmigMXQyp xu1FG4EsLEOR/z+usrwky9RFVcObirExElRrxaaCrlI41Txp6RGT65fJWe1Uo3VXfGiK 5tM7bWhyAaTgFqbqED/7M9cJ+NFLNUeLvU8ko= Received: by 10.231.181.211 with SMTP id bz19mr4033332ibb.107.1304900635770; Sun, 08 May 2011 17:23:55 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id d9sm2391642ibb.53.2011.05.08.17.23.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 17:23:54 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p490Np3C019454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 20:23:51 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p490NneV019453; Sun, 8 May 2011 20:23:49 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 20:23:49 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110509002349.GI3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vSsTm1kUtxIHoa7M" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Garrett Cooper , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 00:23:56 -0000 --vSsTm1kUtxIHoa7M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Sun, May 08, 2011 at 03:52:06PM -0700, Devin Teske wrote: >=20 > I second Jilles all-builtin solution using `for' globbing (no forking ext= ernal processes or sub-shells). >=20 > Slight modification for brevity: >=20 > for _modular_conf in /etc/rc.conf.d/*.conf; do > [ -f "$_modular_conf" -a -x "$_modular_conf" ] || continue > debug "Sourcing $_modular_conf" > . "$_modular_conf" > done >=20 > Though I still think it ought to be: >=20 > for _modular_conf in /etc/rc.conf.d/*.conf; do > [ -f "$_modular_conf" ] || continue > debug "Sourcing $_modular_conf" > . "$_modular_conf" > done >=20 Keeping with the examples of the rest of the style of rc.subr and plenty=20 of other shell scripts here. This would be a distortion of the=20 functionality that the original loop is doing and should be avoided. >=20 >=20 > >=20 > >=20 > >>=20 > >> I would suggest at least for those that doubt the SysV style way of=20 > >> enabling disabling scripts give it a try for a couple weeks then repor= t=20 > >=20 > > GC and I aren't arguing that the SysV style is not helpful (if I read G= C's post correctly). Just that these aren't wholly to-be considered SysV sy= stem startup scripts, but instead "config files". If they had an interprete= r she-bang (e.g., #!/bin/sh), program-flow, or other logic, I'd not disagre= e with the checking of the executable bit. But since these files are by-des= ign going to nearly always be KEY=3DVALUE pairs, I find it odd to think of = them as anything other than just regular text files. > >=20 In no way am I suggesting you are. That was a suggestion in general not=20 really pointed toward you but to everyone in general because workflow and= =20 feel with an unbiased opinion yields results. Sorry if I made that unclear, that is not always obvious as I am writing. > > I think of the files in /etc/rc.conf.d/ as extensions of rc.conf(5) and= the notion that permissions might possibly matter on rc.conf(5) would be e= qually foreign to me. > >=20 > > I'm aware that both rc.conf(5), the local variant, and newly-conceived = rc.conf.d/*.conf are really in-truth just shell scripts sourced into the cu= rrent interpreter. So in-reality they can contain any valid sh(1) syntax. T= hough in-practice the only script of its kind that routinely contains more = than just KEY=3DVALUE pairs is /etc/defaults/rc.conf (which defines the `so= urce_rc_confs' function). > >=20 > > However, I find it to be more common that engineers and technicians thi= nk of rc.conf(5) as a flat text file, and thus will think of the `*.conf' f= iles in /etc/rc.conf.d/ similarly, as text files. Thus it is my objection t= hat the any permission other than the read-bit be checked. > >=20 > >=20 > >> back. If feed back is strong discouraging it then we can probably come= to=20 > >> common ground and find a way to work with both those who would like it= and=20 > >> those who don't by default. I do have a pretty good idea what would wo= rk=20 > >> to make it happen both ways but I really would like to advocate this i= n=20 > >> place as it is now first. > >=20 > > I think that I could live with the read-bit being a toggle. However, th= e more experienced user may scratch his head, rationalizing that `root' sho= uld be able to read anything (that is, unless something explicitly prevents= it such as perhaps TrustedBSD MACs). Read and write bits being toggled is too strong in environments and has=20 long been proven to be disasterous. There are probably some grey beards =20 out here that could contest to that. ;) > >=20 > > Right now, I'm still thinking that the best solution is to: > >=20 > > a. Put into packages: /etc/rc.conf.d/name.conf.sample > > b. User enablement: mv /etc/rc.conf.d/name.conf{.sample,} > > c. User disablement: mv /etc/rc.conf.d/name.conf{,.bak} > >=20 These were things that were originally discussed with the way to handle=20 this type of situation which ultimately resulted in the way SysV init=20 scripts worked. There is alot more involved with mv(1) than just a=20 in-place chmod(1) and can become quite messy. People shouldnt be thinking= =20 of the executable bit as something bad to turn on/off and shouldnt be=20 confused with a type of security issue either. It is actually a quite=20 common convention used to determine if something should happen to a file=20 and any other bit used directly either effects writing or reading of a file. Again I am not against removing the -x but before that happens I would=20 like to get a greater amount of feedback as I also know of a way that it=20 could be turned on or off globally without too much adjustment as to not=20 inconveince the user. But this is a new way to look at configuration in=20 FreeBSD so the users have not been subjected to that yet and since we are= =20 not in a hurry this can be dealt with properly for the masses. --=20 Regards, (jhell) Jason Hellenthal --vSsTm1kUtxIHoa7M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxzQUAAoJEJBXh4mJ2FR+F+QIAJyN4q+KADqlML1x0dkWaQQ7 Yxcrzum/O26uUuV1dBohMT2f8enY1h2OGM9dNUCTyh3S2gQ8vuP8GWtaErEyKA1P CX4uhbeVl3BiDF8MGEY0BSO0uFETWTHdpSmpHXYhp6jI81eibXT+tb9Rdlg6lBz7 Cv5FRy0KPzzh8sn+gNL8aTVW6Pipd5vwAPv4eqSAEeY6puJm+veAaoPyY7+CRkER kLzgjDO+/wH7p65t7MZdROtyh8JWK986WpDuOwBy3YIqfyoABL8wmlwi1oCVmGsL KJvYznq/zWb1PM6jorlnz4V5RfUhLRB23awVL7pc4sNq12zbQlNZ5qRY8c124sA= =VJn4 -----END PGP SIGNATURE----- --vSsTm1kUtxIHoa7M-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 00:57:10 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B0ED106564A for ; Mon, 9 May 2011 00:57:10 +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 501558FC14 for ; Mon, 9 May 2011 00:57:10 +0000 (UTC) Received: from sbhfislrext02.fnfis.com ([192.168.249.140]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p490v8l5011473; Sun, 8 May 2011 19:57:08 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by sbhfislrext02.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Sun, 08 May 2011 19:57:17 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 19:57:08 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 May 2011 19:57:07 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <20110509002349.GI3527@DataIX.net> Date: Sun, 8 May 2011 17:57:05 -0700 Message-Id: <2E9FCA3F-79B7-4FE8-883E-EA1D45EECE56@vicor.com> References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> <20110509002349.GI3527@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 09 May 2011 00:57:08.0021 (UTC) FILETIME=[05573E50:01CC0DE4] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 00:57:10 -0000 On May 8, 2011, at 5:23 PM, Jason Hellenthal wrote: >=20 > Devin, >=20 > On Sun, May 08, 2011 at 03:52:06PM -0700, Devin Teske wrote: >>=20 >> I second Jilles all-builtin solution using `for' globbing (no forking ex= ternal processes or sub-shells). >>=20 >> Slight modification for brevity: >>=20 >> for _modular_conf in /etc/rc.conf.d/*.conf; do >> [ -f "$_modular_conf" -a -x "$_modular_conf" ] || continue >> debug "Sourcing $_modular_conf" >> . "$_modular_conf" >> done >>=20 >> Though I still think it ought to be: >>=20 >> for _modular_conf in /etc/rc.conf.d/*.conf; do >> [ -f "$_modular_conf" ] || continue >> debug "Sourcing $_modular_conf" >> . "$_modular_conf" >> done >>=20 >=20 > Keeping with the examples of the rest of the style of rc.subr and plenty= =20 > of other shell scripts here. This would be a distortion of the=20 > functionality that the original loop is doing and should be avoided. >=20 I've picked up this tid-bit over the years: 1. Since a conditional block causes all code within to be indented... 2. if you have a condition which can cause a continuance within a looping b= ock... 3. utilizing said conditional early-on can prevent unnecessary indentation = in the following lines. It's kind of moot for such a small example, but if you get to nesting 300+ = lines at multiple levels of nesting then it's worth re-evaluating the use o= f "early continuances". Here's the basic idea... for item in list; do : condition to continue : what the loop does done opposed to: for item in list; do if : condition to not continue; then : what the loop does fi done How about this half-and-half approach (actual code): for _modular_conf in /etc/rc.conf.d/*.conf; do if [ ! -f "$_modular_conf" ]; then continue fi debug "Sourcing $_modular_conf" . "$_modular_conf" done Of course, one's interpretation of the above syntax is conditional on memor= izing that "!" is pronounced "not" (just as my previous syntax hinges on me= morizing that "||" is pronounced "or"/"else" -- allowing either syntax to b= e read/interpreted with ease). Just thought I'd share my experiences. Not everyone develops the same style= (9) for every language. --=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. _____________ From owner-freebsd-rc@FreeBSD.ORG Mon May 9 01:33:25 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCBFB1065672 for ; Mon, 9 May 2011 01:33:25 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 820EE8FC2B for ; Mon, 9 May 2011 01:33:25 +0000 (UTC) Received: by iwn33 with SMTP id 33so5607058iwn.13 for ; Sun, 08 May 2011 18:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=SVy2gW8mPaK+ZzdDx6nd64rUyUpGfnQDFuHUqRvMrUM=; b=bYNSK+75vbJRaRwhtWvjxLtRpijRu67xqWkeID/oiWt5TqjgnDxhmkYYGTLr/42idG CchU2BESx9dgnzUummNS4lLgzybYnXzFdBIZW1mVVFvwWdUP3lolooKXrXTtzYu2wKCF /pIh2pmW+XVskZVbXrDkZRohxBnPZzO1kgA64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=CrqdXg+t88z6cUk05Shwd/W6LqeAt64k1S788I1imeYfgKwKyql0AUvIVuMOtKiIFF xbxf5aTGsYK004K0i5dgriltFjOjBa1RPPE2wAhVkQ/vW8RepmCsRdvT+CevP+R6ikU1 XVN7+NruaPX+m13Lr7jXrtg1VBmmIdvTLJr9E= Received: by 10.42.95.1 with SMTP id d1mr5626094icn.254.1304904804913; Sun, 08 May 2011 18:33:24 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id uf10sm2205533icb.17.2011.05.08.18.33.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 18:33:23 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p491XJvY022471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 21:33:19 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p491XIpo022470; Sun, 8 May 2011 21:33:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 21:33:17 -0400 From: Jason Hellenthal To: Jilles Tjoelker Message-ID: <20110509013317.GJ3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <20110508202636.GF3527@DataIX.net> <20110508221129.GA89657@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RwGu8mu1E+uYXPWP" Content-Disposition: inline In-Reply-To: <20110508221129.GA89657@stack.nl> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Garrett Cooper , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 01:33:25 -0000 --RwGu8mu1E+uYXPWP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jilles, & anyone in general, cherry-pick as needed. On Mon, May 09, 2011 at 12:11:29AM +0200, Jilles Tjoelker wrote: > I would say the opposite. jhell's original loop >=20 > + for _modular_conf in /etc/rc.conf.d/*.conf; do > + if [ -f "$_modular_conf" -a -x "$_modular_conf" ]; then > + debug "Sourcing $_modular_conf" > + . $_modular_conf > + fi > + done >=20 > with a small change > - . $_modular_conf > + . "$_modular_conf" Updated in changeset: 63:bf83c2313376, I missed that. Thanks for catching= =20 it. I actually thought about adding another check just to be sure the variable= =20 wasnt empty and adding some text to the debug line like "Sourcing modular= =20 config $_modular_conf" in case for some reason it was NULL but I don't=20 believe that will happen and if it did there is probably more serious=20 problems with the system before it even gets to this point. [ ! -n "$_modular_conf" ] && . "$_modular_conf" Just to be sure but have not updated it in that way yet. >=20 > does not have any E2BIG problems, and also no problems with special > characters. This is because the list of pathnames stays within sh; it is > not passed to another program. If there is no matching file, the loop > runs once for /etc/rc.conf.d/*.conf which does not exist and is > therefore not sourced. >=20 > Any 'while read...' loop will handle pathnames with newlines > incorrectly, and the simple ones also handle backslashes and certain > whitespace incorrectly. Also, the proposed pipeline does not even work > as the while loop is executed in a subshell, so the assignments in the > sourced files are lost. >=20 > This post is not an endorsement of jhell's idea. I am not really > convinced it is useful. For experimenting, the for command can be placed > in /etc/rc.conf. >=20 Just to note, using if statements and such within what is normally to be=20 determined as a config file can be quite unclean or messy or hard to=20 navigate for most that look for a way to shift configurations around. The= =20 original idea behind this for the motivation is jail,nfs,rpcbind etc. Where example:=20 /etc/rc.conf.d/nfsserver.conf can contain: * rpcbind_enable * nfsexample_enable * nfs_lockd_enable * nfs_statd_enable And: /etc/rc.conf.d/nfsserver_nolocking.conf can contain: * rpcbind_enable * nfsexample_enable And this is where the executable bit becomes handy that allows you to=20 quickly chmod(1) one of them and yet still have rpcbind enabled for the=20 other or chmod both and nolonger need rpcbind enabled. This can become=20 even more extensive for jail use and ifconfig configuration but that is=20 byond what could really be summed up on this thread. The current use of rc.conf.d is nearly broken from the users point of view= =20 since it requires working knowledge of the names exported by each rc.d=20 script in order to place the _enable values in the same name file under=20 the rc.conf.d directory and yet while some scripts may not always get that= =20 value if it is only available under the jail name config. Thats a really=20 rought way of handling it. Though I do see that exact facility as being=20 useful if a user wanted to dump in some type of shell script to do some=20 extra parsing or prestart work for a single instance that runs out of rc.d= =20 but this is not what rc.conf(5) suggests so it is quite misleading. And yes I agree! This is the FreeBSD Project and as of this thread the=20 modification made is solely that of myself and my view as I have witnessed= =20 it in the current configuration. And as which needs proper feedback from=20 the community & developers before action is taken. This in-turn though is= =20 an addition/contribution that doesnt impede or change the way=20 configuration is already done but to extend the options that are available= =20 to the end-user in a minimal constructive way.=20 Thank you Jilles I appreciate the feedback and I look forward to hearing=20 back from everyone. --=20 Regards, (jhell) Jason Hellenthal --RwGu8mu1E+uYXPWP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNx0RdAAoJEJBXh4mJ2FR+vc0IAIwvMGAVIRp+NwSp76TFiHbQ /YMwXMefuxc1oF8yE3Sec+bk/BpAvi3P+OZYK1wGcDOVaCCjOO6Cw0XFc7vULQpv oqoLegYtGbBn/Fgvb5Z+k+mGs6kgX9AqfC+mLWDSPLqHm3IxKbcob+gdoxnhallR dF2/mM0FqnabvRSttC7RFdBeQskBDMchhr3PDEMXS/y03l1tZMJ+Pfk3xVwCeWPE LHqpa63xlewmf/1Dcz33qH8lK5JZGaw0DoalRzFAu9OCzpKa6hm1BvRW2W47Vukx V9lFQsM65QaYmkNSlzE0YzEHdAiu7uAxh+hUGnT7UGYwZQ27Wy2gc3afKmby5CQ= =dbDp -----END PGP SIGNATURE----- --RwGu8mu1E+uYXPWP-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 01:49:46 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530481065702 for ; Mon, 9 May 2011 01:49:46 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE0D98FC19 for ; Mon, 9 May 2011 01:49:45 +0000 (UTC) Received: by yie12 with SMTP id 12so2085431yie.13 for ; Sun, 08 May 2011 18:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=mH/qv92a4Hz/gywIgSs30D61QXOoKeLbjvfTkq9XP+0=; b=MiNDovH4AJcAHMoWX4Z17TLUsDZSAcbkjgKNM1jdqcptI23nG+NXwAan9Y4352M6Bz esX6zw9hCLrJWRq3pigRF+wTKhwaF1vbDSpxTssjt7wetF9yKew9SoGtnXNPrtReE/CB OhBEogLfqjhSiqb8FEUNnOZrPKnZw83Pq3pMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=J5fUhalP1klqyQoywcie0TcV3FTQxA/2ugsoytf839TJtvzAQ2p6P5ha4BiUgQO/HK ubb5sKKywMp2CpyPfdUsMhP4yRyO2aMUlYy3eYLNpmC5NVMKonxlxXkgGHu1hhn9jY8o riXn3WjRLqC9VGuSpdTCTIlHgMpexgfMgTP4Y= Received: by 10.236.190.230 with SMTP id e66mr981489yhn.479.1304905785265; Sun, 08 May 2011 18:49:45 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id d46sm2408222yhn.74.2011.05.08.18.49.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 18:49:44 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p491nepr022990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 21:49:41 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p491nd3o022989; Sun, 8 May 2011 21:49:39 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 21:49:39 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110509014939.GK3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> <20110508215432.GG3527@DataIX.net> <20110509002349.GI3527@DataIX.net> <2E9FCA3F-79B7-4FE8-883E-EA1D45EECE56@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="boAH8PqvUi1v1f55" Content-Disposition: inline In-Reply-To: <2E9FCA3F-79B7-4FE8-883E-EA1D45EECE56@vicor.com> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Garrett Cooper , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 01:49:46 -0000 --boAH8PqvUi1v1f55 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Sun, May 08, 2011 at 05:57:05PM -0700, Devin Teske wrote: >=20 > On May 8, 2011, at 5:23 PM, Jason Hellenthal wrote: >=20 > >=20 > > Devin, > >=20 > > On Sun, May 08, 2011 at 03:52:06PM -0700, Devin Teske wrote: > >>=20 > >> I second Jilles all-builtin solution using `for' globbing (no forking = external processes or sub-shells). > >>=20 > >> Slight modification for brevity: > >>=20 > >> for _modular_conf in /etc/rc.conf.d/*.conf; do > >> [ -f "$_modular_conf" -a -x "$_modular_conf" ] || continue > >> debug "Sourcing $_modular_conf" > >> . "$_modular_conf" > >> done > >>=20 > >> Though I still think it ought to be: > >>=20 > >> for _modular_conf in /etc/rc.conf.d/*.conf; do > >> [ -f "$_modular_conf" ] || continue > >> debug "Sourcing $_modular_conf" > >> . "$_modular_conf" > >> done > >>=20 > >=20 > > Keeping with the examples of the rest of the style of rc.subr and plent= y=20 > > of other shell scripts here. This would be a distortion of the=20 > > functionality that the original loop is doing and should be avoided. > >=20 >=20 > I've picked up this tid-bit over the years: >=20 > 1. Since a conditional block causes all code within to be indented... > 2. if you have a condition which can cause a continuance within a looping= bock... > 3. utilizing said conditional early-on can prevent unnecessary indentatio= n in the following lines. >=20 > It's kind of moot for such a small example, but if you get to nesting 300= + lines at multiple levels of nesting then it's worth re-evaluating the use= of "early continuances". >=20 > Here's the basic idea... >=20 > for item in list; do > : condition to continue > : what the loop does > done >=20 > opposed to: >=20 > for item in list; do > if : condition to not continue; then > : what the loop does > fi > done >=20 > How about this half-and-half approach (actual code): >=20 > for _modular_conf in /etc/rc.conf.d/*.conf; do > if [ ! -f "$_modular_conf" ]; then > continue > fi > debug "Sourcing $_modular_conf" > . "$_modular_conf" > done >=20 > Of course, one's interpretation of the above syntax is conditional on mem= orizing that "!" is pronounced "not" (just as my previous syntax hinges on = memorizing that "||" is pronounced "or"/"else" -- allowing either syntax to= be read/interpreted with ease). >=20 > Just thought I'd share my experiences. Not everyone develops the same sty= le(9) for every language. Yeah Yeah! I agree its a very valid point but that is only about indenting= =20 for the most part. There isnt really a need for varience from the style=20 that is already in the script ;) Ill do the same type of things depending on the situation. I have also=20 been known to stretch the very fabric of time and space just to fit a=20 conditional statement to match style. ;) Think I am a little ADHD in the=20 sense that I am very picky about stuff matching. --=20 Regards, (jhell) Jason Hellenthal --boAH8PqvUi1v1f55 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNx0gzAAoJEJBXh4mJ2FR+A34H/0sNU6MrngqH3sV/jAm8iXGD dI/lnD5THG5s8lx7BO39S8gwFu6Hrx5ac2Lylow6xmrE4h+iVJt+ej2835lzGjnl Z7UrJPPm/8jI89Vz8sbhl7LEluahth+sYbMl9lnVrRE489l/u7qakC5bUS0MvHcj hHXIM2fWfiVBc5SNzLdgxHdrm64/zR8y0LC+4H/EQyuGahi9/Q3+HxQALE1CETJS P5+qWIQDZky37GXcuE6Luq0egMvY/9UyC9Ym+ajO/p8zwg7zi2UcrQos73cZP0Fe VMiLdiai8tL578hkzCOsbEIf9MZS2AxMKnjSnw83oAsx9xKR3lVGjcemitt/Cqg= =4uMH -----END PGP SIGNATURE----- --boAH8PqvUi1v1f55-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 03:50:37 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5031F1065670 for ; Mon, 9 May 2011 03:50:37 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3603C8FC12 for ; Mon, 9 May 2011 03:50:36 +0000 (UTC) Received: by pwj8 with SMTP id 8so2886576pwj.13 for ; Sun, 08 May 2011 20:50:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.48.195 with SMTP id o3mr877073pbn.429.1304911256321; Sun, 08 May 2011 20:20:56 -0700 (PDT) Received: by 10.68.58.3 with HTTP; Sun, 8 May 2011 20:20:56 -0700 (PDT) In-Reply-To: <20110508191336.GC3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> Date: Sun, 8 May 2011 20:20:56 -0700 Message-ID: From: Gordon Tetlow To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 03:50:37 -0000 On Sun, May 8, 2011 at 12:13 PM, Jason Hellenthal wrote: > > List, - Please reply-to freebsd-rc@freebsd.org > > Recently I have been going over some changes in the configurations that > are possible with the rc subsystem and to my dismay I have found some > inconsistencies with in particular the way rc.conf.d directory is > processed and the arguments that are supplied to load_rc_config so I have > patched it up... > > Let me explain: =A0As determined by rc.subr load_rc_config, config's from > rc.conf.d are loaded by the scripts $name as an argument to load_rc_confi= g > and thus only the name being parsed is is available to be used in the > rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as > the user has no direct way to know that a variable used by nfsd is also > needed by mountd or the same for various other scripts in the rc.d > directory. At this time these config's are explained to be available for > the user to utilize by rc.conf(5) but yet without much knowledge of the > inner workings of the rc subsystem it would be quite the feat to do. > > > The attachment[1] keeps this functionality the same while introducing a > more convenient approach for the user to modularize their configuration > however they see fit within a couple constraints that work very well. > > > What does it do ?: As stated above, current functionality is undisturbed > while allowing the user to create config's by any name they so desire as > long as it has an extension of ".conf", also introducing the ability to > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > > > Why ? Simple. How many times have you been bitten by disabling something > in the rc.conf file and left to discover what you just disabled was also > used by another daemon but that daemon is now not starting ? This is a wa= y > to virtualize your configuration allowing you to add multiple _enable=3D > lines to different configurations for different roles. For instance > rpcbind is used by both samba and nfs*. With this you can add > rpcbind_enable to both a configuration for samba and nfs and when you > disable one service you know that you have not disabled a dependent for > another. > > > This is a small addition that fixes currently broken undesirable aspects > of the configuration system that deals with the rc.conf.d directory with = a > SysV style init approach that is just as flexible. This should apply > cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback > has been received Ill update the manual page with any suggestions > regenerate the patch to accommodate and file a PR. > > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch The problem with this is you can have 2 files with conflicting statements: /etc/rc.conf.d/sshd: sshd_enable=3D"YES" /etc/rc.conf.d/aaa.conf: sshd_enable=3D"NO" It would probably be difficult to figure out that sshd will not start. It gets even more interesting when you look at the different failure modes (sshd starts in this case. Note the only difference is the sshd.conf vs sshd): /etc/rc.conf.d/sshd.conf: sshd_enable=3D"YES" /etc/rc.conf.d/aaa.conf: sshd_enable=3D"NO" Note if you named it zzz.conf, sshd would not start. This is due to the fact that the patch loads the files in name order. Also, you now have 2 different namespaces colliding in /etc/rc.conf.d: {name} and *.conf (with *.conf taking priority over {name}). Should I be naming my scripts /etc/rc.conf.d/ssd.conf or /etc/rc.conf.d/sshd? It's not clear. Also the fact that the behavior changes based on the +x bit is a nuance that probably shouldn't be added. We have no precedent for testing for the execute bit on a configuration file and I personally wouldn't want to start now. I think I generally am of the opinion that everything for service X should be in /etc/rc.conf.d/X rather than scattering it among a lot of files. The fundamental problem you describe is a legitimate one (service Y has a dependency on X, so autostart X). Perhaps there is another way to achieve the same results by having the startup for Y detecting that X is not running an issuing a onestart command to the service? Cheers, Gordon From owner-freebsd-rc@FreeBSD.ORG Mon May 9 11:07:13 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 944861065670 for ; Mon, 9 May 2011 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 82E5D8FC1B for ; Mon, 9 May 2011 11:07:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p49B7Dcf070728 for ; Mon, 9 May 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p49B7CBM070726 for freebsd-rc@FreeBSD.org; Mon, 9 May 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 May 2011 11:07:12 GMT Message-Id: <201105091107.p49B7CBM070726@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 11:07:13 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/154554 rc [rc.d] [patch] statd and lockd fail to start o conf/153666 rc [rc.d][patch] mount filesystems from fstab over zfs da o conf/153200 rc post-boot /etc/rc.d/network_ipv6 start can miss neighb o conf/153123 rc [rc] [patch] add gsched rc file to automatically inser o conf/152784 rc services provide himself instead providing class of se o conf/151063 rc [rc.subr] Verify network link and packet flow before s o conf/150752 rc [rc.subr] [patch] be not needed to eval $_pidcmd on re o conf/150474 rc [patch] rc.d/accounting: Add ability to set location o o conf/149867 rc [PATCH] rc.d script to manage multiple FIBS (kern opti o conf/149831 rc [PATCH] add support to /etc/rc.d/jail for delegating Z o conf/148656 rc rc.firewall(8): {oip} and {iip} variables in rc.firewa o conf/147685 rc [rc.d] [patch] new feature for /etc/rc.d/fsck o conf/147444 rc [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot o conf/146053 rc [patch] [request] shutdown of jails breaks inter-jail o conf/145445 rc [rc.d] error in /etc/rc.d/jail (bad logic) o conf/145440 rc [rc.d] [patch] add multiple fib support (setfib) in /e o conf/145399 rc [patch] rc.d scripts are unable to start/stop programs o conf/145344 rc [patch] Fix kitchen sink approach for rc.d scripts ins o conf/145009 rc [patch] rc.subr(8): rc.conf should allow mac label con o conf/144213 rc [rc.d] [patch] Disappearing zvols on reboot o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances o conf/143084 rc [jail] [patch]: fix rc.d/jail creating stray softlinks o conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141907 rc [rc.d] Bug if mtu (maybe others?) is set as first argu o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/141275 rc [request] dhclient(8) rc script should print something o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip o conf/138208 rc [rc.d] [patch] Making rc.firewall (workstation) IPv6 a o conf/137629 rc [rc.d] background_dhclient rc.conf option causing doub o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/137271 rc [rc.d] Cannot update /etc/host.conf when root filesyst o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/135338 rc [rc.d] pf startup order seems broken [regression] o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped p bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122968 rc [rc.d] /etc/rc.d/addswap: md swapfile multiplication a o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 92 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon May 9 13:46:24 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADEAF106564A for ; Mon, 9 May 2011 13:46:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 634CA8FC1C for ; Mon, 9 May 2011 13:46:24 +0000 (UTC) Received: by iwn33 with SMTP id 33so6127381iwn.13 for ; Mon, 09 May 2011 06:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=YaIx4huGMhiL+rKwdlIUrQRgAQDIHJ7l+kUNDlQ31ts=; b=YSx+2H0U1LnqOUSrk+aNvE6QYIf0znpzYb3t1BbWzj7abHyqf+Z1p6Y+OFH+t/okKr a2fLHLeqIogbdPiGS0yc8FXshkM3Ah9lNf/F0ymukpbfSqkPy0HIM4XAxiYwpgvKU1i3 UzWLsyduGOxiPEKBVkIFnc89IYckJLuCTsohM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=cA6bBzGmmCsR6yw/d1XVz3pBbE50lL0qTDJd+IbxsJqZSWLBwcKUJbS4dYssfha4hQ VwiaeqQibNka3mzVFUrAxGrR7HM1uoP4dYa0W3tYmvvaC8f9oRw43PkYqA6WOTrW+hTc 6AXzcquqUD5Vp3tWTVWT9OPiVL+PLHKZfRqik= Received: by 10.42.137.10 with SMTP id w10mr6765151ict.347.1304948783690; Mon, 09 May 2011 06:46:23 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id c16sm326117ibe.41.2011.05.09.06.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 06:46:22 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49DkI30075870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 09:46:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49DkHlo075869; Mon, 9 May 2011 09:46:17 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 09:46:17 -0400 From: Jason Hellenthal To: Gordon Tetlow Message-ID: <20110509134617.GA28036@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 13:46:24 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gordon, On Sun, May 08, 2011 at 08:20:56PM -0700, Gordon Tetlow wrote: > On Sun, May 8, 2011 at 12:13 PM, Jason Hellenthal wrot= e: > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > Recently I have been going over some changes in the configurations that > > are possible with the rc subsystem and to my dismay I have found some > > inconsistencies with in particular the way rc.conf.d directory is > > processed and the arguments that are supplied to load_rc_config so I ha= ve > > patched it up... > > > > Let me explain: =A0As determined by rc.subr load_rc_config, config's fr= om > > rc.conf.d are loaded by the scripts $name as an argument to load_rc_con= fig > > and thus only the name being parsed is is available to be used in the > > rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient = as > > the user has no direct way to know that a variable used by nfsd is also > > needed by mountd or the same for various other scripts in the rc.d > > directory. At this time these config's are explained to be available for > > the user to utilize by rc.conf(5) but yet without much knowledge of the > > inner workings of the rc subsystem it would be quite the feat to do. > > > > > > The attachment[1] keeps this functionality the same while introducing a > > more convenient approach for the user to modularize their configuration > > however they see fit within a couple constraints that work very well. > > > > > > What does it do ?: As stated above, current functionality is undisturbed > > while allowing the user to create config's by any name they so desire as > > long as it has an extension of ".conf", also introducing the ability to > > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > > > > > > Why ? Simple. How many times have you been bitten by disabling something > > in the rc.conf file and left to discover what you just disabled was also > > used by another daemon but that daemon is now not starting ? This is a = way > > to virtualize your configuration allowing you to add multiple _enable=3D > > lines to different configurations for different roles. For instance > > rpcbind is used by both samba and nfs*. With this you can add > > rpcbind_enable to both a configuration for samba and nfs and when you > > disable one service you know that you have not disabled a dependent for > > another. > > > > > > This is a small addition that fixes currently broken undesirable aspects > > of the configuration system that deals with the rc.conf.d directory wit= h a > > SysV style init approach that is just as flexible. This should apply > > cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedba= ck > > has been received Ill update the manual page with any suggestions > > regenerate the patch to accommodate and file a PR. > > > > > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > The problem with this is you can have 2 files with conflicting statements: >=20 > /etc/rc.conf.d/sshd: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > It would probably be difficult to figure out that sshd will not start. >=20 Note that this is not really a problem with multiple configuration files=20 that ``you'' create but more-so one that can happen in even the smallest of= =20 single configuration files. This gives you the ability to name the=20 configuration files what you want without restriction and organize them in= =20 a way that fits ``your'' needs. When a part of your configuration becomes= =20 large enough that you feel a need to separate that from the rest and name= =20 it appropriately then this enables you to do exactly that. > It gets even more interesting when you look at the different failure > modes (sshd starts in this case. Note the only difference is the > sshd.conf vs sshd): > /etc/rc.conf.d/sshd.conf: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > Note if you named it zzz.conf, sshd would not start. This is due to > the fact that the patch loads the files in name order. >=20 > Also, you now have 2 different namespaces colliding in /etc/rc.conf.d: > {name} and *.conf (with *.conf taking priority over {name}). Should I > be naming my scripts /etc/rc.conf.d/ssd.conf or /etc/rc.conf.d/sshd? > It's not clear. Also the fact that the behavior changes based on the > +x bit is a nuance that probably shouldn't be added. We have no > precedent for testing for the execute bit on a configuration file and > I personally wouldn't want to start now. >=20 > I think I generally am of the opinion that everything for service X > should be in /etc/rc.conf.d/X rather than scattering it among a lot of > files. >=20 I hope it wasn't implied anywhere that you should do anything other than=20 what you feel is best with your own configuration. > The fundamental problem you describe is a legitimate one (service Y > has a dependency on X, so autostart X). Perhaps there is another way > to achieve the same results by having the startup for Y detecting that > X is not running an issuing a onestart command to the service? >=20 That is just one small aspect of this but think service groups or profiles= =20 that when you would rather have one service configured in a way that=20 allows it to run different when on a home LAN than it does when your away. Dump you rc.conf to two place. home-lan.conf and away-lan.conf and use=20 chmod to turn one or the other off. You can still have a global set of=20 services enabled in rc.conf but still be able to choose a way for them to= =20 act by adding the _flags or even _enable rc_vars to each. Since this processes after rc.conf* you could treat those config's as just= =20 modifiers to get a certain behavior as they override what is in rc.conf*=20 in the same way that rc.conf overrides etc/defaults/rc.conf. How you name= =20 them can clearly depict what it does as well. This is one reason why I=20 mainly went with adding the -x bit because these can coexist with a full=20 rc.conf but be changed quickly when you want a certain behavior.=20 There is no one configuration that suits everyone, how you implement your= =20 configuration shouldn't be limited to the constraints of having to shell=20 script something out to get what you need. Thanks. --=20 Regards, (jhell) Jason Hellenthal --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNx/AoAAoJEJBXh4mJ2FR+tuUH/RZu2ynZpnX1qi7CCmIKWvqP QKvMWWVeGRE08SY29euvLjwa8fhwMrqhVvEsT/8ZaT8OiNlAwTo2QIxgDniMPrlu qbZ2kVGSQX+N9PeXl3Ah4wquAd1cQLrrFmleyVCEj+R3E2KyLT7FwOMskR4Otbx3 BGLAcI0HQRP3OQJINkwzpcthGkY5L9zmbQe3Xvvde0LUaFYk/+MMOy1H+oFnciWv Agw4jPGjYJERBdFMCiCfEqWItwXSOBSGnUsyQav+OPyq/ZAM3OjnYoMIBraOmwur MRh+kUKj+/fI7kSiW8qrMcqqC2Bo3QtxwsSW27OHU+RSA4wm3E6+ymiUBrjyRIE= =e4Sy -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 17:12:45 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ADFC106566B for ; Mon, 9 May 2011 17:12:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACDA8FC16 for ; Mon, 9 May 2011 17:12:45 +0000 (UTC) Received: from [10.30.101.52] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p49HBlp3007002 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 11:11:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110508123745.GA83320@stack.nl> Date: Mon, 9 May 2011 11:11:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92B456D2-9EF2-4F1A-8F06-8FFBB44F59B5@bsdimp.com> References: <20110508123745.GA83320@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 09 May 2011 11:11:49 -0600 (MDT) Cc: freebsd-rc@FreeBSD.org Subject: Re: [PATCH] Use printf(1) builtin for hexprint function in etc/network.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:12:45 -0000 Isn't printf located in /usr, and isn't /usr not guaranteed to be around = when these routines are used? Warner On May 8, 2011, at 6:37 AM, Jilles Tjoelker wrote: > Now that printf(1) is a shell builtin, there is no need to emulate it > anymore. >=20 > It may be faster to use printf directly but the function is useful for > compatibility. >=20 > Index: etc/network.subr > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- etc/network.subr (revision 220966) > +++ etc/network.subr (working copy) > @@ -1333,38 +1333,14 @@ > # Echo decimal number $arg (single digit) in hexadecimal format. > hexdigit() > { > - if [ $1 -lt 10 ]; then > - echo $1 > - else > - case $1 in > - 10) echo a ;; > - 11) echo b ;; > - 12) echo c ;; > - 13) echo d ;; > - 14) echo e ;; > - 15) echo f ;; > - esac > - fi > + printf '%x\n' "$1" > } >=20 > # hexprint arg > # Echo decimal number $arg (multiple digits) in hexadecimal = format. > hexprint() > { > - local val str dig > - val=3D$1 > - str=3D'' > - dig=3D`hexdigit $((${val} & 15))` > - str=3D${dig}${str} > - val=3D$((${val} >> 4)) > - > - while [ ${val} -gt 0 ]; do > - dig=3D`hexdigit $((${val} & 15))` > - str=3D${dig}${str} > - val=3D$((${val} >> 4)) > - done > - > - echo ${str} > + printf '%x\n' "$1" > } >=20 > is_wired_interface() >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-rc@FreeBSD.ORG Mon May 9 17:13:11 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B092106566B for ; Mon, 9 May 2011 17:13:11 +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 E8C5C8FC12 for ; Mon, 9 May 2011 17:13:10 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p49HD9mJ022010; Mon, 9 May 2011 12:13:09 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 12:13:21 -0500 Received: from sbhfisltcgw01.FNFIS.COM ([10.132.248.121]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 12:13:06 -0500 Received: from dtwin ([10.132.254.136]) by sbhfisltcgw01.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 12:13:05 -0500 From: "Devin Teske" To: "'Gordon Tetlow'" , References: <20110508191336.GC3527@DataIX.net> In-Reply-To: Date: Mon, 9 May 2011 10:12:24 -0700 Organization: Vicor, Inc. Message-ID: <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQEL1l7iLvsgf0B1IcBXW0H5UCQBs/JiEk4rlzRA= Content-Language: en-us X-OriginalArrivalTime: 09 May 2011 17:13:06.0129 (UTC) FILETIME=[5CB16C10:01CC0E6C] Cc: Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:13:11 -0000 > -----Original Message----- > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > On Behalf Of Gordon Tetlow > Sent: Sunday, May 08, 2011 8:21 PM > To: freebsd-rc@freebsd.org > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. >=20 > On Sun, May 8, 2011 at 12:13 PM, Jason Hellenthal wrot= e: > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > Recently I have been going over some changes in the configurations > > that are possible with the rc subsystem and to my dismay I have found > > some inconsistencies with in particular the way rc.conf.d directory is > > processed and the arguments that are supplied to load_rc_config so I > > have patched it up... > > > > Let me explain: =A0As determined by rc.subr load_rc_config, config's > > from rc.conf.d are loaded by the scripts $name as an argument to > > load_rc_config and thus only the name being parsed is is available to > > be used in the rc.conf.d directory. Why is this bad ? Its not! but it > > is inconvenient as the user has no direct way to know that a variable > > used by nfsd is also needed by mountd or the same for various other > > scripts in the rc.d directory. At this time these config's are > > explained to be available for the user to utilize by rc.conf(5) but > > yet without much knowledge of the inner workings of the rc subsystem it > would be quite the feat to do. > > > > > > The attachment[1] keeps this functionality the same while introducing > > a more convenient approach for the user to modularize their > > configuration however they see fit within a couple constraints that work very > well. > > > > > > What does it do ?: As stated above, current functionality is > > undisturbed while allowing the user to create config's by any name > > they so desire as long as it has an extension of ".conf", also > > introducing the ability to turn a configuration file off by using > > chmod(1). You can turn nfsc1.conf off/on by simply chmod [-/+]x > > etc/rc.conf.d/nfs1.conf > > > > > > Why ? Simple. How many times have you been bitten by disabling > > something in the rc.conf file and left to discover what you just > > disabled was also used by another daemon but that daemon is now not > > starting ? This is a way to virtualize your configuration allowing you > > to add multiple _enable=3D lines to different configurations for > > different roles. For instance rpcbind is used by both samba and nfs*. > > With this you can add rpcbind_enable to both a configuration for samba > > and nfs and when you disable one service you know that you have not > > disabled a dependent for another. > > > > > > This is a small addition that fixes currently broken undesirable > > aspects of the configuration system that deals with the rc.conf.d > > directory with a SysV style init approach that is just as flexible. > > This should apply cleanly to current and stable/8 & 8.2-RELEASE > > systems. Once more feedback has been received Ill update the manual > > page with any suggestions regenerate the patch to accommodate and file = a PR. > > > > > > 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch >=20 > The problem with this is you can have 2 files with conflicting statements: >=20 > /etc/rc.conf.d/sshd: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > It would probably be difficult to figure out that sshd will not start. Some time ago, I took it as a personal mission to write a script to help so= lve this very issue. Specifically, I wanted a script that could help me answer = this deceptively simple question (which parallels your inference): "Why isn't (insert name) starting?" When talking about RCNG scripts in the `rc.d' directories (either /etc/rc.d= or /usr/local/etc/rc.d), surely you are correct in identifying that multiple rc.conf(5) scripts can contain different ``*_enable'' values. The solution is to have a script that can tell you these two details: 1. What is the final value of ``*_enable'' 2. Which file assigns said final value If you have those two pieces of information, then unraveling a twisted configuration is easier. [Re-]welcome my sysrc(8) script: http://druidbsd.sourceforge.net/download/sysrc.txt Here's an example of how you [hypothetically] would use it to diagnose the = above situation (in which you have ``sshd_enable'' set to YES in /etc/rc.conf.d/s= shd and set to NO in /etc/rc.conf.d/aaa.conf): $ sysrc -v sshd_enable /etc/rc.conf.d/sshd: sshd_enable: YES NOTE: I say "hypothetically" above because [a] /etc/rc.conf.d/*.conf is currently not implemented yet, and [b] my sysrc(8) script does not yet sear= ch through `rc.conf.d'. What I'm proposing is that sysrc(8) could be expanded to support the new rc.conf.d standard, allowing you to solve the problem of "why is this start= ing" or "why is this not starting". >=20 > It gets even more interesting when you look at the different failure modes (sshd > starts in this case. Note the only difference is the sshd.conf vs sshd): > /etc/rc.conf.d/sshd.conf: > sshd_enable=3D"YES" >=20 > /etc/rc.conf.d/aaa.conf: > sshd_enable=3D"NO" >=20 > Note if you named it zzz.conf, sshd would not start. This is due to the f= act that the > patch loads the files in name order. >=20 I recommend sysrc(8) to help solve such confusions (though, admittedly the current version doesn't descend into rc.conf.d -- I'm waiting on some of th= is stuff to solidify before coding support for it). > Also, you now have 2 different namespaces colliding in /etc/rc.conf.d: > {name} and *.conf (with *.conf taking priority over {name}). Should I be naming > my scripts /etc/rc.conf.d/ssd.conf or /etc/rc.conf.d/sshd? > It's not clear. +1 I'm almost thinking that the proper thing to do would be to: 1. Modify the `load_rc_config' function of `/etc/rc.subr' to no longer chec= k for `/etc/rc.conf.d/$_name' 2. Modify the `source_rc_confs' function of `/etc/defaults/rc.conf' to load `/etc/rc.conf.d/*.conf' This would remove confusion over "/etc/rc.conf.d/sshd" versus "/etc/rc.conf.d/sshd.conf" > Also the fact that the behavior changes based on the > +x bit is a nuance that probably shouldn't be added. We have no > precedent for testing for the execute bit on a configuration file and I personally > wouldn't want to start now. +1 (again) > I think I generally am of the opinion that everything for service X shoul= d be in > /etc/rc.conf.d/X rather than scattering it among a lot of files. The scattering becomes a non-issue with sysrc(8) able to tell you where the= last effective assignment to a variable was. Doubly-so with this syntax: sysrc -av Which lists all non-default parameters and the files that they are configur= ed in (though, again admittedly, I need to add support for `rc.conf.d'). --=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. _____________ From owner-freebsd-rc@FreeBSD.ORG Mon May 9 17:19:50 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2785106564A for ; Mon, 9 May 2011 17:19:50 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id B6A308FC16 for ; Mon, 9 May 2011 17:19:50 +0000 (UTC) Received: by pvg11 with SMTP id 11so3217803pvg.13 for ; Mon, 09 May 2011 10:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.194 with SMTP id m2mr4390168pbm.228.1304961590134; Mon, 09 May 2011 10:19:50 -0700 (PDT) Received: by 10.68.58.3 with HTTP; Mon, 9 May 2011 10:19:50 -0700 (PDT) In-Reply-To: <20110509134617.GA28036@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <20110509134617.GA28036@DataIX.net> Date: Mon, 9 May 2011 10:19:50 -0700 Message-ID: From: Gordon Tetlow To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:19:50 -0000 On Mon, May 9, 2011 at 6:46 AM, Jason Hellenthal wrote: > Dump you rc.conf to two place. home-lan.conf and away-lan.conf and use > chmod to turn one or the other off. You can still have a global set of > services enabled in rc.conf but still be able to choose a way for them to > act by adding the _flags or even _enable rc_vars to each. > > Since this processes after rc.conf* you could treat those config's as just > modifiers to get a certain behavior as they override what is in rc.conf* > in the same way that rc.conf overrides etc/defaults/rc.conf. How you name > them can clearly depict what it does as well. This is one reason why I > mainly went with adding the -x bit because these can coexist with a full > rc.conf but be changed quickly when you want a certain behavior. For everything else in the proposal, I feel the use of the execute bit is incorrect. Nowhere else in the system is there a precedent of using the execute bit to toggle on and off a configuration file. You can no longer do a simple 'grep foo_enable *.conf' and see which active files have that set. I would prefer to use the pattern established by many 3rd parties and use the convention that you may mv the file out of the way so it no longer matches the *.conf glob. Something like 'mv foo.conf foo.conf.disable' is unambiguous and can easily be searched with a simple ls or grep command. Using the execute bit is less transparent, unprecedented, and confusing. Regards, Gordon From owner-freebsd-rc@FreeBSD.ORG Mon May 9 17:21:35 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08ECD106566B for ; Mon, 9 May 2011 17:21:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BCFF18FC08 for ; Mon, 9 May 2011 17:21:34 +0000 (UTC) Received: from [10.30.101.52] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p49HEEbu007032 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 11:14:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20110508123745.GA83320@stack.nl> Date: Mon, 9 May 2011 11:14:08 -0600 Content-Transfer-Encoding: 7bit Message-Id: <8F50A4FE-C2CC-4898-809E-A9A43F1C2079@bsdimp.com> References: <20110508123745.GA83320@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 09 May 2011 11:14:15 -0600 (MDT) Cc: freebsd-rc@FreeBSD.org Subject: Re: [PATCH] Use printf(1) builtin for hexprint function in etc/network.subr X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:21:35 -0000 Missed that it is now a shell built-in. N/m about my comments. Warner On May 8, 2011, at 6:37 AM, Jilles Tjoelker wrote: > Now that printf(1) is a shell builtin, there is no need to emulate it > anymore. > > It may be faster to use printf directly but the function is useful for > compatibility. > > Index: etc/network.subr > =================================================================== > --- etc/network.subr (revision 220966) > +++ etc/network.subr (working copy) > @@ -1333,38 +1333,14 @@ > # Echo decimal number $arg (single digit) in hexadecimal format. > hexdigit() > { > - if [ $1 -lt 10 ]; then > - echo $1 > - else > - case $1 in > - 10) echo a ;; > - 11) echo b ;; > - 12) echo c ;; > - 13) echo d ;; > - 14) echo e ;; > - 15) echo f ;; > - esac > - fi > + printf '%x\n' "$1" > } > > # hexprint arg > # Echo decimal number $arg (multiple digits) in hexadecimal format. > hexprint() > { > - local val str dig > - val=$1 > - str='' > - dig=`hexdigit $((${val} & 15))` > - str=${dig}${str} > - val=$((${val} >> 4)) > - > - while [ ${val} -gt 0 ]; do > - dig=`hexdigit $((${val} & 15))` > - str=${dig}${str} > - val=$((${val} >> 4)) > - done > - > - echo ${str} > + printf '%x\n' "$1" > } > > is_wired_interface() > > -- > Jilles Tjoelker > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" > > From owner-freebsd-rc@FreeBSD.ORG Mon May 9 17:32:19 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7F081065675 for ; Mon, 9 May 2011 17:32:19 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1698FC2C for ; Mon, 9 May 2011 17:32:19 +0000 (UTC) Received: by pxi11 with SMTP id 11so4496916pxi.7 for ; Mon, 09 May 2011 10:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.42.104 with SMTP id n8mr9855937pbl.496.1304962339010; Mon, 09 May 2011 10:32:19 -0700 (PDT) Received: by 10.68.58.3 with HTTP; Mon, 9 May 2011 10:32:18 -0700 (PDT) In-Reply-To: <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> References: <20110508191336.GC3527@DataIX.net> <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> Date: Mon, 9 May 2011 10:32:18 -0700 Message-ID: From: Gordon Tetlow To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:32:19 -0000 On Mon, May 9, 2011 at 10:12 AM, Devin Teske wrote: > The solution is to have a script that can tell you these two details: > > 1. What is the final value of ``*_enable'' > 2. Which file assigns said final value > > If you have those two pieces of information, then unraveling a twisted > configuration is easier. > > [Re-]welcome my sysrc(8) script: While this is a very cool script, I have to wonder how far we have strayed if we require another tool to tell us how the system is configured. Surely we should be aiming for simplicity in our implementation and not something incredibly complex. After Jason's proposal, we would have the following list of configuration files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc.conf.local /etc/rc.conf.d/{name} /etc/rc.conf.d/*.conf Personally, I think this is too many. Regards, Gordon From owner-freebsd-rc@FreeBSD.ORG Mon May 9 17:58:31 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E8C4106564A for ; Mon, 9 May 2011 17:58:31 +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 EC56D8FC18 for ; Mon, 9 May 2011 17:58:30 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p49HwUTO023670; Mon, 9 May 2011 12:58:30 -0500 Received: from SBHFISLTCGW07.FNFIS.COM (Not Verified[10.132.248.135]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 12:58:42 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by SBHFISLTCGW07.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 12:58:30 -0500 Received: from dtwin ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 12:58:28 -0500 From: "Devin Teske" To: "'Gordon Tetlow'" References: <20110508191336.GC3527@DataIX.net> <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> In-Reply-To: Date: Mon, 9 May 2011 10:57:45 -0700 Organization: Vicor, Inc. Message-ID: <00a401cc0e72$9f4ebd60$ddec3820$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQEL1l7iLvsgf0B1IcBXW0H5UCQBs/JiEAgK+meUB2K/ku5NsIHIw Content-Language: en-us X-OriginalArrivalTime: 09 May 2011 17:58:28.0869 (UTC) FILETIME=[B3929350:01CC0E72] Cc: freebsd-rc@freebsd.org Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:58:31 -0000 > -----Original Message----- > From: Gordon Tetlow [mailto:gordon@tetlows.org] > Sent: Monday, May 09, 2011 10:32 AM > To: Devin Teske > Cc: freebsd-rc@freebsd.org > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. > > On Mon, May 9, 2011 at 10:12 AM, Devin Teske wrote: > > The solution is to have a script that can tell you these two details: > > > > 1. What is the final value of ``*_enable'' > > 2. Which file assigns said final value > > > > If you have those two pieces of information, then unraveling a twisted > > configuration is easier. > > > > [Re-]welcome my sysrc(8) script: > > While this is a very cool script, I have to wonder how far we have strayed if we > require another tool to tell us how the system is configured. *cough* sysctl(8) *cough* > Surely we should be > aiming for simplicity in our implementation and not something incredibly > complex. I modeled sysrc(8) after sysctl(8). If you know how to use sysctl(8), you already know how to use sysrc(8). I can't make it any simpler. > After Jason's proposal, we would have the following list of configuration files: > > /etc/defaults/rc.conf > /etc/rc.conf > /etc/rc.conf.local > /etc/rc.conf.d/{name} I suggest we kill the single line above (/etc/rc.conf.d/{name}) in favor of the below. > /etc/rc.conf.d/*.conf > > Personally, I think this is too many. If we make the last line replace the previous declaration, then the list neither grows nor shrinks, yet becomes simplified. -- 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Mon May 9 18:02:50 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0530106564A for ; Mon, 9 May 2011 18:02:50 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5648E8FC15 for ; Mon, 9 May 2011 18:02:50 +0000 (UTC) Received: by iwn33 with SMTP id 33so6422289iwn.13 for ; Mon, 09 May 2011 11:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=VLDU04uFlDsuIRZbdIVFDkzV2R++PEVtlDdSRcncHRM=; b=caVIfXmsnflGchb2Q18p2cXwm7U7iR6vPO/MfOq3OeLqTZjXcbQddyuYU3IZ9879kf nMNCKQir+fQvUZ5BVibJCBEMxlbH5dQTr11D1iCC4ANhlfREwr3th1GP/T7BAVI/0xY2 31yB1FBzQ6pwSA4Mgu88Ye1VjCExaRtIdPSYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=m/qXbvYut6l8rN5/JV0OztvmurYRWJ9+MRdxdbmYLb7GhKyTJQN4ppzKzuS9aLi+Pd rNWVVDtjJIUmZHPBA6uenoKfNkmP38tw452uNtKUX9desMGXTSWbj2oRJ6EAGM4ma9hj xEzno1WnQBV/IRA+j9AQ4gBB7nLZbs9KgVYYU= Received: by 10.42.1.78 with SMTP id 14mr6353134icf.23.1304964169708; Mon, 09 May 2011 11:02:49 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id c16sm398556ibe.7.2011.05.09.11.02.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 11:02:48 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49I2jB2086966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 14:02:45 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49I2ioC086965; Mon, 9 May 2011 14:02:44 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 14:02:44 -0400 From: Jason Hellenthal To: Gordon Tetlow Message-ID: <20110509180243.GA82456@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <20110509134617.GA28036@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 18:02:50 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gordon, On Mon, May 09, 2011 at 10:19:50AM -0700, Gordon Tetlow wrote: > On Mon, May 9, 2011 at 6:46 AM, Jason Hellenthal wrote: > > Dump you rc.conf to two place. home-lan.conf and away-lan.conf and use > > chmod to turn one or the other off. You can still have a global set of > > services enabled in rc.conf but still be able to choose a way for them = to > > act by adding the _flags or even _enable rc_vars to each. > > > > Since this processes after rc.conf* you could treat those config's as j= ust > > modifiers to get a certain behavior as they override what is in rc.conf* > > in the same way that rc.conf overrides etc/defaults/rc.conf. How you na= me > > them can clearly depict what it does as well. This is one reason why I > > mainly went with adding the -x bit because these can coexist with a full > > rc.conf but be changed quickly when you want a certain behavior. >=20 > For everything else in the proposal, I feel the use of the execute bit > is incorrect. Nowhere else in the system is there a precedent of using > the execute bit to toggle on and off a configuration file. You can no > longer do a simple 'grep foo_enable *.conf' and see which active files > have that set. I would prefer to use the pattern established by many > 3rd parties and use the convention that you may mv the file out of the > way so it no longer matches the *.conf glob. Something like 'mv > foo.conf foo.conf.disable' is unambiguous and can easily be searched > with a simple ls or grep command. Using the execute bit is less > transparent, unprecedented, and confusing. >=20 Ok, I do agree with you on this. There is another route that I propose the= =20 same type of thing but in the style or sense of a lockfile. Not that it=20 actually locks anything but would make it visable enough to where it can=20 be disabled in-place rather than moved around. It would act similiar to this in shell: if [ -f $_modular_conf -a ! -f $_modular_conf.disable ]; then [...] Then to disable one config someone can still do so without cp/mv and just= =20 touch or rm /etc/rc.conf.d/my-conf.conf.disable How does that sound to you ? and everyone else ? --=20 Regards, (jhell) Jason Hellenthal --AqsLC8rIMeq19msA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyCxDAAoJEJBXh4mJ2FR+/N0H/i4D8VNLGeA1ustIFPYoY1E9 A48N8wBXHAe+kiib2PZmbgIcLddHxm83Mq9qX+yWCSfgj4gcptewb582JlrU0ULM 1QreyrH3oSKZaVLLyxMxMDr0OlHWugMxjgjb6mSBWTEaoRAtg2aqO+mXw5IzTZWk /keY0WADnT14wL33HmHc/74wZzqYO5sVoh4J6L5u1syy6xeuSwJ8DMt28MZnflkV KfEB9SJysg2384wmuSpnxBll1lNDWU15zeYcnb6JAHLY6ybQoYJxfT3r1GNLmGID CSVj9Jg9Un/fh2JMAuL+1S6NVubeGAPQyd1CO/qYaCB3zqntrOVTh4Axv8Zw/4k= =xe9T -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 18:50:48 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71A4E1065676 for ; Mon, 9 May 2011 18:50:48 +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 38CAF8FC0A for ; Mon, 9 May 2011 18:50:47 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p49IokNA016667; Mon, 9 May 2011 13:50:46 -0500 Received: from SBHFISLTCGW07.FNFIS.COM (Not Verified[10.132.248.135]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 13:50:48 -0500 Received: from sbhfisltcgw01.FNFIS.COM ([10.132.248.121]) by SBHFISLTCGW07.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 13:50:46 -0500 Received: from dtwin ([10.132.254.136]) by sbhfisltcgw01.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 13:50:44 -0500 From: "Devin Teske" To: "'Jason Hellenthal'" , "'Gordon Tetlow'" References: <20110508191336.GC3527@DataIX.net> <20110509134617.GA28036@DataIX.net> <20110509180243.GA82456@DataIX.net> In-Reply-To: <20110509180243.GA82456@DataIX.net> Date: Mon, 9 May 2011 11:50:06 -0700 Organization: Vicor, Inc. Message-ID: <006801cc0e79$ec6f98b0$c54eca10$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQEL1l7iLvsgf0B1IcBXW0H5UCQBs/JiEAgSeJRcCHI4rhgGEI6C8k13YfLA= Content-Language: en-us X-OriginalArrivalTime: 09 May 2011 18:50:44.0879 (UTC) FILETIME=[00C7B9F0:01CC0E7A] Cc: freebsd-rc@freebsd.org Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 18:50:48 -0000 > -----Original Message----- > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > On Behalf Of Jason Hellenthal > Sent: Monday, May 09, 2011 11:03 AM > To: Gordon Tetlow > Cc: freebsd-rc@freebsd.org > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. > > > Gordon, > > On Mon, May 09, 2011 at 10:19:50AM -0700, Gordon Tetlow wrote: > > On Mon, May 9, 2011 at 6:46 AM, Jason Hellenthal wrote: > > > Dump you rc.conf to two place. home-lan.conf and away-lan.conf and > > > use chmod to turn one or the other off. You can still have a global > > > set of services enabled in rc.conf but still be able to choose a way > > > for them to act by adding the _flags or even _enable rc_vars to each. > > > > > > Since this processes after rc.conf* you could treat those config's > > > as just modifiers to get a certain behavior as they override what is > > > in rc.conf* in the same way that rc.conf overrides > > > etc/defaults/rc.conf. How you name them can clearly depict what it > > > does as well. This is one reason why I mainly went with adding the > > > -x bit because these can coexist with a full rc.conf but be changed quickly > when you want a certain behavior. > > > > For everything else in the proposal, I feel the use of the execute bit > > is incorrect. Nowhere else in the system is there a precedent of using > > the execute bit to toggle on and off a configuration file. You can no > > longer do a simple 'grep foo_enable *.conf' and see which active files > > have that set. I would prefer to use the pattern established by many > > 3rd parties and use the convention that you may mv the file out of the > > way so it no longer matches the *.conf glob. Something like 'mv > > foo.conf foo.conf.disable' is unambiguous and can easily be searched > > with a simple ls or grep command. Using the execute bit is less > > transparent, unprecedented, and confusing. > > > > Ok, I do agree with you on this. There is another route that I propose the same > type of thing but in the style or sense of a lockfile. Not that it actually locks > anything but would make it visable enough to where it can be disabled in-place > rather than moved around. > > It would act similiar to this in shell: > > if [ -f $_modular_conf -a ! -f $_modular_conf.disable ]; then [...] > > Then to disable one config someone can still do so without cp/mv and just touch > or rm /etc/rc.conf.d/my-conf.conf.disable > > How does that sound to you ? and everyone else ? You could achieve what you want with symlinks, like Linux (ducks for flying fruit). E.g., putting your scripts somewhere like /etc/rc.conf.d-all and then creating symbolic links in /etc/rc.conf.d). Seriously... _don't_ do that (we're joking). Meanwhile, regarding your latest suggestion... it didn't take too well at the office (and unfortunately there weren't any alternative suggestions worth mentioning). What is so horrible about mv(1)? -- 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Mon May 9 19:04:49 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E863106566B for ; Mon, 9 May 2011 19:04:49 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4655C8FC0A for ; Mon, 9 May 2011 19:04:48 +0000 (UTC) Received: by gyg13 with SMTP id 13so2378260gyg.13 for ; Mon, 09 May 2011 12:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=AJoY9BtY6kgowjEgMYywq5/qXgaBvJJ8rV7CmRZhGgU=; b=a59qXWqJplD+0N+OWMRDqcYQiZGVHa2SMwr+iwtIn1PsEFYvJCEIGRast8q5MMW4yH sbNBshuSJdHlTg622USTRqZT7MJ0DGL4AdG/fgBnPRJ0FPg7AlBAVbX9hGW5liZN09ay RcLyCHd/2IoX+m5SemZc+ty/JQ8aTL4Qtb+ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=gCOYfjtofqGqeMrBO6exJhaWFbfTxU6fXC9uv/E8GayDMW0/04dyTIVM0hpGta4bZZ UJUYuAPKkQaftSs8f5bk7xuNBQjFNLJjaqK4S83gwCd3hQGt6nYep896XSLpeAiN0fCS zi0th7RS2azy4EbbMh9TF5TCAkEQTc6wFTJPU= Received: by 10.236.155.70 with SMTP id i46mr7686133yhk.125.1304967888235; Mon, 09 May 2011 12:04:48 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id h28sm132140yhm.97.2011.05.09.12.04.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 12:04:47 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49J4gur089509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 15:04:43 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49J4gA1089508; Mon, 9 May 2011 15:04:42 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 15:04:41 -0400 From: Jason Hellenthal To: Gordon Tetlow Message-ID: <20110509190441.GC82456@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:04:49 -0000 --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gordon, On Mon, May 09, 2011 at 10:32:18AM -0700, Gordon Tetlow wrote: > On Mon, May 9, 2011 at 10:12 AM, Devin Teske wrote: > > The solution is to have a script that can tell you these two details: > > > > 1. What is the final value of ``*_enable'' > > 2. Which file assigns said final value > > > > If you have those two pieces of information, then unraveling a twisted > > configuration is easier. > > > > [Re-]welcome my sysrc(8) script: >=20 > While this is a very cool script, I have to wonder how far we have > strayed if we require another tool to tell us how the system is > configured. Surely we should be aiming for simplicity in our > implementation and not something incredibly complex. >=20 > After Jason's proposal, we would have the following list of configuration= files: >=20 > /etc/defaults/rc.conf > /etc/rc.conf > /etc/rc.conf.local What seems to be lost here is that the below two are "optional" not=20 something that should be created by anything other than the user who needs= =20 that functionality. Yes having two of the below is a problem. Yes {name}=20 needs to go. But until there is something to replace it in a way that is=20 agreed on we cant get rid of the broken {name} implement. Hopefully noone is intending on breaking there system by creating=20 thousands of configs because that can be done easier by just spilling into= =20 rc.conf ;) This isnt a replacement and rc.conf.d isnt even available in the first=20 place unless end-user creates it. This wont replace rc.conf. > /etc/rc.conf.d/{name} > /etc/rc.conf.d/*.conf >=20 > Personally, I think this is too many. >=20 > Regards, > Gordon > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" --=20 Regards, (jhell) Jason Hellenthal --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyDrJAAoJEJBXh4mJ2FR+oxQH+wZSfEMXwWFPCoEwbJis1/e4 y3DFZLV9AzM9XNQ4rcNcKIlIwyfm5ixOMIk+7Ja9VNN4uztu0ZiGyXkvG8QGRskj 6+G6453t1HX4g9TECyRZWv5bFqLL1lJ2CLzPXbbuG/52fUd+R8oX7jbG0wmoHDD9 Mh+Uo47ngUVfFiNxf608NsjVd4r++v0XlDKF074HzjDegb2PIP7kynOrov55E2v7 GD8gkEWYBDISZ+XNrO9e/HXXyCnyNzg/UaLCwuRzXEUhDRHp8h3eM2mjePqb/yy4 dkrfq1jUhRJq2ddqQKtzZ0DygDvu+9jKg93GB18HFCobUSlOngb7ByHiWjkSetk= =/gMU -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 20:28:38 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A7E971065673 for ; Mon, 9 May 2011 20:28:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F02B01556AD; Mon, 9 May 2011 20:28:25 +0000 (UTC) Message-ID: <4DC84E68.1000203@FreeBSD.org> Date: Mon, 09 May 2011 13:28:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-rc@freebsd.org References: <20110508191336.GC3527@DataIX.net> In-Reply-To: <20110508191336.GC3527@DataIX.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Hellenthal Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 20:28:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with Gordon's analysis that this proposal adds a lot of potential for confusion with very little real benefit. Your post describes _what_ you want to do, but I'm confused about _why_ you would want to do it. Can you give a use case example? I also feel compelled to point out that if the functionality you want is "break certain common knobs for a subset of services out into their own configuration file" then this can already be achieved without any code changes by placing ". /path/file" in your rc.conf[.local] file(s). You can even put the code snippet you posted in there if you really feel that it's the right solution. And yes, I heard you say elsewhere in the thread that you don't like to put anything other than variables in rc.conf, but there is nothing actually wrong with doing it, and it works. In short, I've reviewed this whole thread to date and haven't yet seen a compelling reason to make this change. Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNyE5oAAoJEFzGhvEaGryEEgkH/017kcFm/NrechiizH1wAn6b 6bRZRX9H3xFZkquP70fkH4IzXHxFkTLDT9Zogr6cYx0Hxan79m+cWs99oLWDxOfL xKZaCtBrXd3g8BuYfL7+T5yDXftzCPEkqfAdpCqTcYBvW+iR2K7OaOYDzGBo0VnE kyYLQGPZ4/+PJnOYoF30OzapoNnFpxV0WTOQuDqXa0Niu3ym4opN8wweQvptFB7J mh6DApcLnaUkf7LqWsUdq/RYf7Ny0YWEyJmlnBs9q6TnT/fxpEXYYoEy4pYMPXrg sdzMg3k1Twt8Y7+uiu8pBQG146ZLmqXLnzNP7yd9IexGzERpe+8qGz+DymaN+Xc= =dW4E -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:01:55 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58898106566B for ; Mon, 9 May 2011 23:01:55 +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 216FE8FC18 for ; Mon, 9 May 2011 23:01:55 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p49N1ouP025149; Mon, 9 May 2011 18:01:50 -0500 Received: from SBHFISLTCGW07.FNFIS.COM (Not Verified[10.132.248.135]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 18:02:02 -0500 Received: from sbhfisltcgw02.FNFIS.COM ([10.132.248.122]) by SBHFISLTCGW07.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 18:01:50 -0500 Received: from dtwin ([10.132.254.136]) by sbhfisltcgw02.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 18:01:49 -0500 From: "Devin Teske" To: "'Doug Barton'" , References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> In-Reply-To: <4DC84E68.1000203@FreeBSD.org> Date: Mon, 9 May 2011 16:01:14 -0700 Organization: Vicor, Inc. Message-ID: <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQEL1l7iLvsgf0B1IcBXW0H5UCQI436VOk3zrl2A= Content-Language: en-us X-OriginalArrivalTime: 09 May 2011 23:01:50.0074 (UTC) FILETIME=[14560DA0:01CC0E9D] Cc: 'Jason Hellenthal' Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:01:55 -0000 > -----Original Message----- > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > On Behalf Of Doug Barton > Sent: Monday, May 09, 2011 1:28 PM > To: freebsd-rc@freebsd.org > Cc: Jason Hellenthal > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I agree with Gordon's analysis that this proposal adds a lot of potential for > confusion with very little real benefit. Your post describes _what_ you want to > do, but I'm confused about _why_ you would want to do it. Can you give a use > case example? > > I also feel compelled to point out that if the functionality you want is "break > certain common knobs for a subset of services out into their own configuration > file" then this can already be achieved without any code changes by placing ". > /path/file" in your rc.conf[.local] file(s). You can even put the code snippet you > posted in there if you really feel that it's the right solution. And yes, I heard you > say elsewhere in the thread that you don't like to put anything other than > variables in rc.conf, but there is nothing actually wrong with doing it, and it works. > > In short, I've reviewed this whole thread to date and haven't yet seen a > compelling reason to make this change. Hi Doug, First, let me say that we're on the same page, but I'd like to take a shot at a worthwhile use-case. Also, I know you were addressing jhell but I thought I'd chime-in because we (VICOR) feel that this feature would be very useful to us (envisioned use-case described below). Use Case: 1. One of many customers runs a site with, say, 35 servers and 89 workstations. 2. Each/every machine has a "role" which requires certain services to be enabled 3. Server "roles" enable NFS, SSH, FTP, as well as other services 4. Workstation "roles" have a wholly separate set of services (with some in-common) 5. Pedestals are yet another "role" 6. Machines can satisfy multiple roles 7. The roles are additive 8. There are separate roles for different products So if we need hardware-A to run products A and B in roles "A-Server" and "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" and "/etc/rc.conf.d/product-B-server.conf". Meanwhile, if we need hardware-B to run products A and B but in workstation roles, we'd install "/etc/rc.conf.d/product-A-workstation.conf" and "/etc/rc.conf.d/product-B-workstation.conf". Currently the way we solve this is by having a bootstrap script that determines what needs to be added to /etc/rc.conf by-way of reading the hostname (which of course can be overridden with a command-line argument). JHell's proposed idea of allowing one to place any number of well-named "*.conf" files to /etc/rc.conf.d would allow us to separate the roles into different files rather than having to augment them into a single file (or worse, have the directives scattered throughout /etc/rc.conf.d/${_name}). This is especially nice because we (as the makers of "Product-A" and "Product-B") are not the ones that maintain the system. The customers purchase equipment, use our bootstrap scripts to configure things like /etc/rc.conf et. al., and then proceed to run our software in the configured manner. One of the largest contentions in this scenario is that our product-based rc.conf(5) settings end up in the same file as the customer-based rc.conf(5) settings. Things that have nothing to do with our product are indistinguishable from others. I fully support JHells addition because it would immediately allow us to maintain static configs required to operate our product separately from the dynamic configs created by the customer. -- 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:27:56 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 551FF106566C for ; Mon, 9 May 2011 23:27:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 869E515358E; Mon, 9 May 2011 23:27:55 +0000 (UTC) Message-ID: <4DC8787A.9070003@FreeBSD.org> Date: Mon, 09 May 2011 16:27:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Devin Teske References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> In-Reply-To: <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Jason Hellenthal' , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:27:56 -0000 On 05/09/2011 16:01, Devin Teske wrote: > Hi Doug, > > First, let me say that we're on the same page, We're not, actually. > but I'd like to take a shot at a worthwhile use-case. > > Also, I know you were addressing jhell but I thought I'd chime-in because we > (VICOR) feel that this feature would be very useful to us (envisioned use-case > described below). > > Use Case: > > 1. One of many customers runs a site with, say, 35 servers and 89 workstations. > 2. Each/every machine has a "role" which requires certain services to be enabled > 3. Server "roles" enable NFS, SSH, FTP, as well as other services > 4. Workstation "roles" have a wholly separate set of services (with some > in-common) > 5. Pedestals are yet another "role" > 6. Machines can satisfy multiple roles > 7. The roles are additive > 8. There are separate roles for different products > > So if we need hardware-A to run products A and B in roles "A-Server" and > "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" and > "/etc/rc.conf.d/product-B-server.conf". You can already do this at least 2 different ways. The first is the method I outlined in my previous post. The second would be to have wrapper rc.d scripts in /usr/local/etc/rc.d that start the required services for either product; with or without correspondingly named config files in /etc/rc.conf.d. (Personally I would set the right values in the scripts themselves.) So, there are at least 2 different ways that you can achieve the same effect that already exist, and I strongly suspect that if I thought about it long enough I could come up with a couple more. I'm still willing to listen to a use case that can't be achieved without this change, but to be honest I'm dubious. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:28:33 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93570106564A for ; Mon, 9 May 2011 23:28:33 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 460858FC08 for ; Mon, 9 May 2011 23:28:33 +0000 (UTC) Received: by iyj12 with SMTP id 12so6780927iyj.13 for ; Mon, 09 May 2011 16:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=LlhBlWf7FAtcDJXPMnL2rrvuaaP0etvi5htdCflh8fI=; b=hh6sq/E0ggE+UEAh1My0bRrP7pJg3W0waMPSzitrWQ83n2c/sT8TJeb1A+FWiEPYl5 gCO+zEEtgg168DTKROmexICOryOWO/JR+p3rGvUbu9B0uc11/r+2y/tZ2MrQH7F/csme u7UWOsejBzGu2lWVxwp4KknJsIL+zWLgWuoII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=glDM0NUv2vgH6oKRVNaMEAo9+eb4qrsEpA2DPaApRlkFTaJXazscqTpDCxHIYxoIvX i4rf4hpTTTrMGQdEwPfyK5yogonCADxNG2nhksfRk6krdk6e5VWfgtKftYRoC0gRPeMk 5ppu6Oi3fc/e6GPrIgY7wL9WaQ3hM9nuEzaMs= Received: by 10.42.19.8 with SMTP id z8mr6523470ica.262.1304983712151; Mon, 09 May 2011 16:28:32 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id a1sm2584634ics.4.2011.05.09.16.28.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 16:28:31 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49NSQFO004093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 19:28:26 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49NSPXJ004092; Mon, 9 May 2011 19:28:25 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 19:28:25 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110509232825.GA2558@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <20110509134617.GA28036@DataIX.net> <20110509180243.GA82456@DataIX.net> <006801cc0e79$ec6f98b0$c54eca10$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <006801cc0e79$ec6f98b0$c54eca10$@vicor.com> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org, 'Gordon Tetlow' Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:28:33 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 11:50:06AM -0700, Devin Teske wrote: > > -----Original Message----- > > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > > On Behalf Of Jason Hellenthal > > Sent: Monday, May 09, 2011 11:03 AM > > To: Gordon Tetlow > > Cc: freebsd-rc@freebsd.org > > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > > etc/rc.conf.d/*.conf namespace. > >=20 > >=20 > > Gordon, > >=20 > > On Mon, May 09, 2011 at 10:19:50AM -0700, Gordon Tetlow wrote: > > > On Mon, May 9, 2011 at 6:46 AM, Jason Hellenthal w= rote: > > > > Dump you rc.conf to two place. home-lan.conf and away-lan.conf and > > > > use chmod to turn one or the other off. You can still have a global > > > > set of services enabled in rc.conf but still be able to choose a way > > > > for them to act by adding the _flags or even _enable rc_vars to eac= h. > > > > > > > > Since this processes after rc.conf* you could treat those config's > > > > as just modifiers to get a certain behavior as they override what is > > > > in rc.conf* in the same way that rc.conf overrides > > > > etc/defaults/rc.conf. How you name them can clearly depict what it > > > > does as well. This is one reason why I mainly went with adding the > > > > -x bit because these can coexist with a full rc.conf but be changed > quickly > > when you want a certain behavior. > > > > > > For everything else in the proposal, I feel the use of the execute bit > > > is incorrect. Nowhere else in the system is there a precedent of using > > > the execute bit to toggle on and off a configuration file. You can no > > > longer do a simple 'grep foo_enable *.conf' and see which active files > > > have that set. I would prefer to use the pattern established by many > > > 3rd parties and use the convention that you may mv the file out of the > > > way so it no longer matches the *.conf glob. Something like 'mv > > > foo.conf foo.conf.disable' is unambiguous and can easily be searched > > > with a simple ls or grep command. Using the execute bit is less > > > transparent, unprecedented, and confusing. > > > > >=20 > > Ok, I do agree with you on this. There is another route that I propose = the > same > > type of thing but in the style or sense of a lockfile. Not that it actu= ally > locks > > anything but would make it visable enough to where it can be disabled i= n-place > > rather than moved around. > >=20 > > It would act similiar to this in shell: > >=20 > > if [ -f $_modular_conf -a ! -f $_modular_conf.disable ]; then [...] > >=20 > > Then to disable one config someone can still do so without cp/mv and ju= st > touch > > or rm /etc/rc.conf.d/my-conf.conf.disable > >=20 > > How does that sound to you ? and everyone else ? >=20 > You could achieve what you want with symlinks, like Linux (ducks for flyi= ng > fruit). > E.g., putting your scripts somewhere like /etc/rc.conf.d-all and then cre= ating > symbolic links in /etc/rc.conf.d). >=20 Devin! you have hit a very good point here "archiving". Usually when I=20 want to turn a file off from being parsed I already use gzip(1) on the=20 file so its still pretty much in-place without having to be moved. Not=20 that I would expect everyone to follow that behavior but it gets rid of=20 the need in my case to use the -x bit or even a similiar type of lockfile= =20 semantic, mv(1). > Seriously... _don't_ do that (we're joking). >=20 After all it is really "what works for you" right ? ;)=20 > Meanwhile, regarding your latest suggestion... it didn't take too well at= the > office (and unfortunately there weren't any alternative suggestions worth > mentioning). >=20 Yeah I didn't think that would go over well ;) for the record I don't=20 really care for it either. > What is so horrible about mv(1)? Nothing. in-place files are nice though because you dont have to mv them=20 around but if it is general consensus I have no problem shifting direction= =20 and going with changeset 64:dcc5d3cb0d13 that gets rid of the -x bit. Still at the same location: http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch Anyway if anyone has some suggestions on the final patch that or some=20 other concerns please bring them up. I do have other idea's based around=20 this one that could make the configuration process straight forward=20 but I would like to fix what has partly broken functionality first. Thank you Devin --=20 Regards, (jhell) Jason Hellenthal --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyHiYAAoJEJBXh4mJ2FR++9UH/09GKYTt3fqXwCv67pkWFUur falnAQkxbJBVZkZq03qPIE635ph1yJr4BLygIm7QyJiH4aGv9HZvEHepBW4Co8E5 buoZh43rUqWRUtWgon6bN0WsdTY8q2mMfPV93HSyN3bsyOnzkYqkIkyCor7/5piL ojhswNLmkJdciGRiX7RjTVFM1h4zhnXINmfQ3VRJtFiri8k3qcXUmpBeepdTAdIQ ZnOTGJ+kBoA4TilpOggXkJ38F7BmWG0nvm1i3aLla64KJEQzJBDnahkoepc7eqQ0 nUwQpyGbqKi75GVZ+z5IJX0Byuxm8RYZE+kTmbhtBqhdoTKuyJ+OyZmiaR+7MJ4= =mBDH -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:38:31 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAB8B1065678; Mon, 9 May 2011 23:38:31 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62DBA8FC0C; Mon, 9 May 2011 23:38:30 +0000 (UTC) Received: by iwn33 with SMTP id 33so6735532iwn.13 for ; Mon, 09 May 2011 16:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=FMRzYZ7SKqi039WV+YPRHNaxext/O5v7915wffYXd1c=; b=Exnt/Emtzonfxam8ObWTLL17pFD4+DS2QkQHCGrHgFUdGii0nSJNO1FTo+iH2JBL6c lqYYKqcO0Ig1skiqhUe89NjZqQ9FZ69ENCa7d94cx+Eoy8cSn6QR0UY6HmsrntQR3gJw LtY1bnE7XH0362vvbz/KVDq0yMEcsIkkOXqdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=Tgc5DcU0yESv4pIR/r9nF18ZL27dKi8LEmAciIhJsk77kNJT+5y7nePf0F9s7C7zgU BKfBUKijpcg8Y+lQX5biKM0ylwiGUQFkB0vWhyOF39HojxBxr6DAbCWc4M85d76lPywd 6cbi0apnSXoKGSJMSMN6T2rDTxgS/IiDHL5h4= Received: by 10.42.132.66 with SMTP id c2mr6752107ict.194.1304984310589; Mon, 09 May 2011 16:38:30 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2822592iby.57.2011.05.09.16.38.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 16:38:29 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49NcQLH004447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 19:38:26 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49NcPoA004446; Mon, 9 May 2011 19:38:25 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 19:38:25 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110509233825.GB2558@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:38:31 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 04:01:14PM -0700, Devin Teske wrote: > > -----Original Message----- > > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > > On Behalf Of Doug Barton > > Sent: Monday, May 09, 2011 1:28 PM > > To: freebsd-rc@freebsd.org > > Cc: Jason Hellenthal > > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > > etc/rc.conf.d/*.conf namespace. > >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > >=20 > > I agree with Gordon's analysis that this proposal adds a lot of potenti= al for > > confusion with very little real benefit. Your post describes _what_ you= want > to > > do, but I'm confused about _why_ you would want to do it. Can you give = a use > > case example? > >=20 > > I also feel compelled to point out that if the functionality you want is > "break > > certain common knobs for a subset of services out into their own config= uration > > file" then this can already be achieved without any code changes by pla= cing ". > > /path/file" in your rc.conf[.local] file(s). You can even put the code = snippet > you > > posted in there if you really feel that it's the right solution. And ye= s, I > heard you > > say elsewhere in the thread that you don't like to put anything other t= han > > variables in rc.conf, but there is nothing actually wrong with doing it= , and > it works. > >=20 > > In short, I've reviewed this whole thread to date and haven't yet seen a > > compelling reason to make this change. >=20 > Hi Doug, >=20 > First, let me say that we're on the same page, but I'd like to take a sho= t at a > worthwhile use-case. >=20 > Also, I know you were addressing jhell but I thought I'd chime-in because= we > (VICOR) feel that this feature would be very useful to us (envisioned use= -case > described below). >=20 > Use Case: >=20 > 1. One of many customers runs a site with, say, 35 servers and 89 worksta= tions. > 2. Each/every machine has a "role" which requires certain services to be = enabled > 3. Server "roles" enable NFS, SSH, FTP, as well as other services > 4. Workstation "roles" have a wholly separate set of services (with some > in-common) > 5. Pedestals are yet another "role" > 6. Machines can satisfy multiple roles > 7. The roles are additive > 8. There are separate roles for different products >=20 > So if we need hardware-A to run products A and B in roles "A-Server" and > "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" and > "/etc/rc.conf.d/product-B-server.conf". >=20 > Meanwhile, if we need hardware-B to run products A and B but in workstati= on > roles, we'd install "/etc/rc.conf.d/product-A-workstation.conf" and > "/etc/rc.conf.d/product-B-workstation.conf". >=20 > Currently the way we solve this is by having a bootstrap script that dete= rmines > what needs to be added to /etc/rc.conf by-way of reading the hostname (wh= ich of > course can be overridden with a command-line argument). >=20 > JHell's proposed idea of allowing one to place any number of well-named "= *.conf" > files to /etc/rc.conf.d would allow us to separate the roles into differe= nt > files rather than having to augment them into a single file (or worse, ha= ve the > directives scattered throughout /etc/rc.conf.d/${_name}). >=20 > This is especially nice because we (as the makers of "Product-A" and > "Product-B") are not the ones that maintain the system. The customers pur= chase > equipment, use our bootstrap scripts to configure things like /etc/rc.con= f et. > al., and then proceed to run our software in the configured manner. One o= f the > largest contentions in this scenario is that our product-based rc.conf(5) > settings end up in the same file as the customer-based rc.conf(5) setting= s. > Things that have nothing to do with our product are indistinguishable from > others. >=20 > I fully support JHells addition because it would immediately allow us to > maintain static configs required to operate our product separately from t= he > dynamic configs created by the customer. Thank you again for reponding and calling more attention and adding some=20 more intuitive knowledge behind this. I would like to add a note to you on this though. I see one possible=20 problem with the way it is right now in the patch. It is procesed after=20 rc.conf, rc.conf.local so it does override those values. Should instead it= =20 be treated the opposite and process before rc.conf, rc.conf.local so it=20 can be overridden by a more centralized config ? I see a greater potential having it act as a user specified defaults than= =20 I do a rc.conf or rc.conf.local override. What do you think ? everyone=20 else ? Doug ? --=20 Regards, (jhell) Jason Hellenthal --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyHrxAAoJEJBXh4mJ2FR++LoH+gKzKTx7TWDKVOPKOYiqvAUS 91KVN4sqbdxBHNU0zV0XXuU2fRiJxYVoVqXxZOe50AHZbiBwxYKTzt5wSVoK4wYE Ga1ZvDuOXDAtmW3ZVuGFyrjGT/neA6ppnvMPTjX7+jZVUiS+2h72OceLRgf8AFmW vgzzWNLCsIvSXQLkwyAWKuZGRv1u1prG5YnHRMxQVcrsjAMqfWYJthRSSxVL2uA4 ww9Ng7Qkpn1uBO/8OC0gQvQyAClH+M+HNrnJBSpgTFyvy5uix06dAbdEU8Te7C2I dLWtrhPdwzrVOudV3cwpnbcX5UZlWlBN8VKQMqR8TSpTU/npDiS0qKKKhXngx6g= =TdGq -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:50:58 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 674FB106566C for ; Mon, 9 May 2011 23:50:58 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 48AD78FC08 for ; Mon, 9 May 2011 23:50:58 +0000 (UTC) Received: by pvg11 with SMTP id 11so3397804pvg.13 for ; Mon, 09 May 2011 16:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.200 with SMTP id g8mr11040581pbm.362.1304985057560; Mon, 09 May 2011 16:50:57 -0700 (PDT) Received: by 10.68.58.3 with HTTP; Mon, 9 May 2011 16:50:57 -0700 (PDT) In-Reply-To: <20110509190441.GC82456@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> <20110509190441.GC82456@DataIX.net> Date: Mon, 9 May 2011 16:50:57 -0700 Message-ID: From: Gordon Tetlow To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:50:58 -0000 On Mon, May 9, 2011 at 12:04 PM, Jason Hellenthal wrote: > > Gordon, > > On Mon, May 09, 2011 at 10:32:18AM -0700, Gordon Tetlow wrote: >> On Mon, May 9, 2011 at 10:12 AM, Devin Teske wrote: >> > The solution is to have a script that can tell you these two details: >> > >> > 1. What is the final value of ``*_enable'' >> > 2. Which file assigns said final value >> > >> > If you have those two pieces of information, then unraveling a twisted >> > configuration is easier. >> > >> > [Re-]welcome my sysrc(8) script: >> >> While this is a very cool script, I have to wonder how far we have >> strayed if we require another tool to tell us how the system is >> configured. Surely we should be aiming for simplicity in our >> implementation and not something incredibly complex. >> >> After Jason's proposal, we would have the following list of configuration files: >> >> /etc/defaults/rc.conf >> /etc/rc.conf >> /etc/rc.conf.local > > What seems to be lost here is that the below two are "optional" not > something that should be created by anything other than the user who needs > that functionality. Yes having two of the below is a problem. Yes {name} > needs to go. But until there is something to replace it in a way that is > agreed on we cant get rid of the broken {name} implement. The {name} implementation isn't broken, it just doesn't do what you want it to. I would be hesitant to remove the {name} implementation, it's been there since the 5.x days. It's hard to say how many installations rely on it being there. Gordon From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:57:54 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEC44106566B; Mon, 9 May 2011 23:57:54 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 66D028FC0C; Mon, 9 May 2011 23:57:54 +0000 (UTC) Received: by iyj12 with SMTP id 12so6801337iyj.13 for ; Mon, 09 May 2011 16:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=wT1oniIGp3HveG1o7KLwtt2dtrEs8r3JqgaKt+yqpAU=; b=DNgNdSS0B77/OGIM9eNFLpJKlSbiN833hMpt7DKQzIELk5pPzcccdRqtnkxVjaURDh rAoVyGU+gKFYyfHD5s9PA/VJInh5erTJXGjl15dJ+kfuGe9Frf5PpCQGh/aSEcjE0PiC L48hRdtN3JvtU7CtDgMSp2h2uSHyy8h0OmVAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=R8Q0T7gcdj3gGqFQSEOuHAEjreMH3odo9R/4BE30ojypKS3SuWsnBq650Gs/j0wAdi +7PB9CFCPqjapECukwki257PCmKSuzTNIXFhyhjpDvQI9tClQEe9S4wjBEi1LmoA+V3P An9c5g/9x2vxMy9z/auxckYx4Z5v3cudIZVbA= Received: by 10.42.123.15 with SMTP id p15mr6949418icr.93.1304985473646; Mon, 09 May 2011 16:57:53 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id c1sm2834093ibe.0.2011.05.09.16.57.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 16:57:52 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49Nvmrw005282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 19:57:48 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49Nvl9e005281; Mon, 9 May 2011 19:57:47 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 19:57:46 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20110509235746.GC2558@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline In-Reply-To: <4DC8787A.9070003@FreeBSD.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:57:54 -0000 --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug, On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: > On 05/09/2011 16:01, Devin Teske wrote: > > Hi Doug, > > > > First, let me say that we're on the same page, >=20 > We're not, actually. >=20 > > but I'd like to take a shot at a worthwhile use-case. > > > > Also, I know you were addressing jhell but I thought I'd chime-in becau= se we > > (VICOR) feel that this feature would be very useful to us (envisioned u= se-case > > described below). > > > > Use Case: > > > > 1. One of many customers runs a site with, say, 35 servers and 89 works= tations. > > 2. Each/every machine has a "role" which requires certain services to b= e enabled > > 3. Server "roles" enable NFS, SSH, FTP, as well as other services > > 4. Workstation "roles" have a wholly separate set of services (with some > > in-common) > > 5. Pedestals are yet another "role" > > 6. Machines can satisfy multiple roles > > 7. The roles are additive > > 8. There are separate roles for different products > > > > So if we need hardware-A to run products A and B in roles "A-Server" and > > "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" and > > "/etc/rc.conf.d/product-B-server.conf". >=20 > You can already do this at least 2 different ways. The first is the=20 > method I outlined in my previous post. The second would be to have=20 > wrapper rc.d scripts in /usr/local/etc/rc.d that start the required=20 > services for either product; with or without correspondingly named=20 > config files in /etc/rc.conf.d. (Personally I would set the right values= =20 > in the scripts themselves.) >=20 > So, there are at least 2 different ways that you can achieve the same=20 > effect that already exist, and I strongly suspect that if I thought=20 > about it long enough I could come up with a couple more. I'm still=20 > willing to listen to a use case that can't be achieved without this=20 > change, but to be honest I'm dubious. >=20 >=20 Sorry Doug but rc.conf.d is already laid out for the user to use as=20 mentioned by rc.conf(5) with a suggested use but unfortunately has quite a= =20 few side effects that I am not going to bother re-writing about again. In reply to your previous email here is one exercise that should point=20 out the broken functionality fairly clearly or at least I hope clearly=20 enough that you realize how a normal user would look at it. =46rom scratch, no rc.conf. Setup a NFS server with lockd, statd, mountd,= =20 rpcbind using only rc.conf.d/${_name} namespace and then try starting=20 these services using service(8) and /etc/rc.d/* files. Then read=20 rc.conf(5) and tell me the suggestion for jail makes sense. If you still disagree after doing this then please by all means eradicate= =20 rc.conf.d from rc.conf(5) and remove its functionality from rc.subr as it= =20 is less than adequate for anybody other than a developers natural use. I do not quite understand why you take such an opposition against=20 something that fixes this broken functionality but yet retains its=20 original use. --=20 Regards, (jhell) Jason Hellenthal --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyH96AAoJEJBXh4mJ2FR+ZRkH/2jP1C+HVzhnYGgd4LILopMr +GInX2Knn7K315AIy0JGpivUccUjpDpBRFfrGQgVYGpEdVjH2mCN8rSoBPKu07+J BREK2xMopNRzmzxbxo5jQJVL69FeXIjDmfDOOcjyZ8gAbKq1mlPllUNfFFx34D8K obLPi3SjuoqKf1c95t7oqimBWMtnddGaWUFmlRkM+b1/t3lCmWawnNv4dInSIEcT S4Np6CzSJTzYool3eX/KupVTtKXH3UhLi852ivo7+3Dy4/4m00SU85TBiy9ig295 qAjD5uM69GUDyZ7H+D+MNPTUPp98Bh00drX9lJYmRc6Qt67r955VpNVNcdRcQv0= =kGxu -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- From owner-freebsd-rc@FreeBSD.ORG Tue May 10 00:21:52 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E0D7106564A for ; Tue, 10 May 2011 00:21:52 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 354D18FC0C for ; Tue, 10 May 2011 00:21:51 +0000 (UTC) Received: by gwb15 with SMTP id 15so2487418gwb.13 for ; Mon, 09 May 2011 17:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=dy1ZIx9nHTob9fE7iMZLhDtqvoCIxXYXocSXEGPtKWw=; b=WU4zeWKnc5phoz4LFKVa7iK8oYFLFNdQWfTDYkeR8QbMB63iNyxSlucs7KTw6E6qlY Apvk0eRSzvk1YR2jGzHyfnmj36lo/Ow4XL9mzvja4QM3RslibJ6xCrJXxvXwTWxTSYT0 KViUwTcxSQFz6dc0RKxagsHGK+3sfYpDHjjig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=Op4blHF76NMbmkT1dXUWlLaOXrDvZWP4mSlAbd/fDDQwlZT9LjQcO4va7hxbje8e6K uoSWYGVyrSnCzlIOkB1z1VZFGcLC2+MtyBFBaT7K+0njtuezxoWkBSzUvkQVa39G6qtS r27LMyPQbp3zTuA5RXznUbUDPvZsEQB1djJZg= Received: by 10.236.19.100 with SMTP id m64mr8968753yhm.77.1304986911252; Mon, 09 May 2011 17:21:51 -0700 (PDT) Received: from DataIX.net ([99.190.84.116]) by mx.google.com with ESMTPS id e8sm1097961yhm.43.2011.05.09.17.21.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 17:21:50 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A0LjM6006407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 20:21:46 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A0Ljd6006406; Mon, 9 May 2011 20:21:45 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 20:21:45 -0400 From: Jason Hellenthal To: Gordon Tetlow Message-ID: <20110510002145.GD2558@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <01d201cc0e6c$47d4b180$d77e1480$@vicor.com> <20110509190441.GC82456@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 00:21:52 -0000 --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gordon, On Mon, May 09, 2011 at 04:50:57PM -0700, Gordon Tetlow wrote: > On Mon, May 9, 2011 at 12:04 PM, Jason Hellenthal wrot= e: > > > > Gordon, > > > > On Mon, May 09, 2011 at 10:32:18AM -0700, Gordon Tetlow wrote: > >> On Mon, May 9, 2011 at 10:12 AM, Devin Teske wrote: > >> > The solution is to have a script that can tell you these two details: > >> > > >> > 1. What is the final value of ``*_enable'' > >> > 2. Which file assigns said final value > >> > > >> > If you have those two pieces of information, then unraveling a twist= ed > >> > configuration is easier. > >> > > >> > [Re-]welcome my sysrc(8) script: > >> > >> While this is a very cool script, I have to wonder how far we have > >> strayed if we require another tool to tell us how the system is > >> configured. Surely we should be aiming for simplicity in our > >> implementation and not something incredibly complex. > >> > >> After Jason's proposal, we would have the following list of configurat= ion files: > >> > >> /etc/defaults/rc.conf > >> /etc/rc.conf > >> /etc/rc.conf.local > > > > What seems to be lost here is that the below two are "optional" not > > something that should be created by anything other than the user who ne= eds > > that functionality. Yes having two of the below is a problem. Yes {name} > > needs to go. But until there is something to replace it in a way that is > > agreed on we cant get rid of the broken {name} implement. >=20 > The {name} implementation isn't broken, it just doesn't do what you want = it to. >=20 > I would be hesitant to remove the {name} implementation, it's been > there since the 5.x days. It's hard to say how many installations rely > on it being there. >=20 Though I would like to I agree with that. You dint just introduce an=20 interface and remove it later down the road with a long winded deprecation= =20 process. This certainly could be the start of that deprecation process. "It just doesn't do what it is suggested to do" not what I want it to do=20 by rc.conf(5) which is part of the reason why this patch came into play.=20 You can't just provide a space to use and then suggest to the user that=20 they only use certain undocumented names that are provided by rc.d/*=20 scripts. It's a waste of their time thinking that they can just put for=20 instance 'jail, jail1, jail2' in rc.conf.d and it'll work. It does not=20 unless you start adding source this and that lines to the end of every=20 file and that would not be right to suggest to the end-user either. Though if it is documented well enough I do not see any fathomable reason= =20 why a user should not be allowed to make up a name that contains what they= =20 want to be in it. The rc.conf.d directory suggests its very use just as=20 anyone would believe about usr/local/etc/apache22/Includes/*.conf. Out of all the opposition yet I still have not seen a valid response of=20 "what is wrong with letting the user decide how they name a configuration= =20 file?". I keep seeing the opposite of well you can do this and you can do= =20 that with shell scripting options. That shocks me as this is like stated=20 before a user specified created and maintained directory. --=20 Regards, (jhell) Jason Hellenthal --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyIUYAAoJEJBXh4mJ2FR+t/sH/igSxUPV66powmaOT8XRtGa9 ZbOmz+eQwy5vr2+eGs3bhs4GmXdcKErcHG5Jvj7cLtI5F28VVtimKE9yiNO+3bKM 5I1LA6uF7TiU3tpZ8WuKgNZBCam3YU/DC4lFKdvwnmLYGIJzYWRU7ofljj7jB1ck mOUzXUyOndEJ88hUyDTsroay+mnap8RwSPqVTBWoxakNMCdMTPI1TyR1EKv75QtF 7nb9SmH/veEeFMJ5MiDT5qWJUQLPNObm1/5v5cpnOSOjfH4k/9e20PjD2U5jSku1 pmDCUoWbG8gsVzkIKB+k+wl4TuinZXYYMSp7YheP7V466IOSdUj38yLSqT14TUo= =0dti -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV-- From owner-freebsd-rc@FreeBSD.ORG Tue May 10 01:39:10 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434B9106566B; Tue, 10 May 2011 01:39:10 +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 0A6378FC14; Tue, 10 May 2011 01:39:09 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4A1d8CB006292; Mon, 9 May 2011 20:39:08 -0500 Received: from SBHFISLTCGW04.FNFIS.COM (Not Verified[10.132.248.123]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 20:39:08 -0500 Received: from sbhfisltcgw01.FNFIS.COM ([10.132.248.121]) by SBHFISLTCGW04.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 20:39:07 -0500 Received: from dtwin ([10.132.254.136]) by sbhfisltcgw01.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 20:39:07 -0500 From: "Devin Teske" To: "'Doug Barton'" References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> In-Reply-To: <4DC8787A.9070003@FreeBSD.org> Date: Mon, 9 May 2011 18:38:32 -0700 Organization: Vicor, Inc. Message-ID: <00df01cc0eb2$f9837010$ec8a5030$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQEL1l7iLvsgf0B1IcBXW0H5UCQI436VOAesjUfIBogAnmpNgq4dw Content-Language: en-us X-OriginalArrivalTime: 10 May 2011 01:39:07.0501 (UTC) FILETIME=[0D7B21D0:01CC0EB3] Cc: 'Jason Hellenthal' , freebsd-rc@freebsd.org Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:39:10 -0000 > -----Original Message----- > From: Doug Barton [mailto:dougb@FreeBSD.org] > Sent: Monday, May 09, 2011 4:28 PM > To: Devin Teske > Cc: freebsd-rc@freebsd.org; 'Jason Hellenthal' > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. > > On 05/09/2011 16:01, Devin Teske wrote: > > Hi Doug, > > > > First, let me say that we're on the same page, > > We're not, actually. In my locale, the phrase "we're on the same page" actually means "I agree with your last statements." Your response is taken as if you mean to say that I was wrong in agreeing with you. Wait, what? That doesn't rightly make much sense. I frankly don't understand the origin of this perceived hostility. > > but I'd like to take a shot at a worthwhile use-case. > > > > Also, I know you were addressing jhell but I thought I'd chime-in > > because we > > (VICOR) feel that this feature would be very useful to us (envisioned > > use-case described below). > > > > Use Case: > > > > 1. One of many customers runs a site with, say, 35 servers and 89 workstations. > > 2. Each/every machine has a "role" which requires certain services to > > be enabled 3. Server "roles" enable NFS, SSH, FTP, as well as other > > services 4. Workstation "roles" have a wholly separate set of services > > (with some > > in-common) > > 5. Pedestals are yet another "role" > > 6. Machines can satisfy multiple roles 7. The roles are additive 8. > > There are separate roles for different products > > > > So if we need hardware-A to run products A and B in roles "A-Server" > > and "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" > > and "/etc/rc.conf.d/product-B-server.conf". > > You can already do this at least 2 different ways. The first is the method I outlined > in my previous post. If by that you mean your suggestion to add ". /path/file" to rc.conf(5) et. al., that's non-copacetic as I forgot to mention that we (as a product vendor) do not control rc.conf(5), rather our customers do. In fact, we have an rc.d script that uses sup(1)/cvsup(1) to pull down rc.conf(5) from a central server, allowing central management of all machines. Currently, as it stands, rc.conf(5) is standardized across all hosts, and rc.conf.local is where we put the per-machine configurations. However, we'd really really like to instead relinquish rc.conf.local to the customers, instead moving our productized configs to rc.conf.d with role-specific filenames. Thus completing the trifecta that would allow: a. Our customers to maintain a site-wide rc.conf(5) b. Our customers to maintain a per-machine rc.conf.local c. Have rc.conf.d as the landing zone for our productized configs Where your suggestion of "just put ``. /path/file'' to rc.conf(5)" assumes that we control rc.conf(5), which as explained above, we assume that the customer has complete control over that file (and with JHell's addition, we can then also assume that the customer has complete control over rc.conf.local). > The second would be to have wrapper rc.d scripts in > /usr/local/etc/rc.d that start the required services for either product; with or > without correspondingly named config files in /etc/rc.conf.d. (Personally I would > set the right values in the scripts themselves.) I find this suggestion to be a gross perversion of the boot process. In the case where JHell's patch is put through and we're allowed /etc/rc.conf.d/*.conf, all that is needed is to add "*_enable=YES" to a file to effect whether that system is loaded. Contrast that with a /usr/local/etc/rc.d script which will have to do a lot more heavy lifting to accomplish the same task: a. Check if the daemon was started (this can range from simple to difficult, depending on the service details) b. If the daemon did not start, start it (again, this can be simple or difficult; if the service has a corresponding rc.d script, then simple, otherwise perhaps difficult) Compare the act of setting an environment variable at the appropriate point-in-time during the boot process with the act of performing checks and creating conditions in which you fire have to perform some action to bring up the service. It seems almost obvious that the [hypothetical] one-liner addition to /etc/rc.conf.d/product.conf is more efficient than the dozens-or-more lines required to achieve the same thing in an rc.d script which is running after-the-fact in which the [presumed] prior-executed rc.d script could have done the job for you had the "*_enable=YES" variable been set. > So, there are at least 2 different ways that you can achieve the same effect that > already exist, and I strongly suspect that if I thought about it long enough I could > come up with a couple more. I'm still willing to listen to a use case that can't be > achieved without this change, but to be honest I'm dubious. I'd like to hear more suggestions, but remain dubious that anything is going to top JHell's proposition. -- 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 01:55:20 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7635106566B; Tue, 10 May 2011 01:55:20 +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 8EF148FC15; Tue, 10 May 2011 01:55:20 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC01 (8.14.3/8.14.3) with ESMTP id p4A1tJi7027644; Mon, 9 May 2011 20:55:19 -0500 Received: from SBHFISLTCGW07.FNFIS.COM (Not Verified[10.132.248.135]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 20:55:19 -0500 Received: from sbhfisltcgw01.FNFIS.COM ([10.132.248.121]) by SBHFISLTCGW07.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 20:55:19 -0500 Received: from dtwin ([10.132.254.136]) by sbhfisltcgw01.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 20:55:18 -0500 From: "Devin Teske" To: "'Jason Hellenthal'" References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> In-Reply-To: <20110509233825.GB2558@DataIX.net> Date: Mon, 9 May 2011 18:53:43 -0700 Organization: Vicor, Inc. Message-ID: <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQEL1l7iLvsgf0B1IcBXW0H5UCQI436VOAesjUfICDojfbZNdU8YQ Content-Language: en-us X-OriginalArrivalTime: 10 May 2011 01:55:18.0674 (UTC) FILETIME=[50585F20:01CC0EB5] Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:55:20 -0000 Jason, > -----Original Message----- > From: J. Hellenthal [mailto:jhellenthal@gmail.com] On Behalf Of Jason Hellenthal > Sent: Monday, May 09, 2011 4:38 PM > To: Devin Teske > Cc: 'Doug Barton'; freebsd-rc@FreeBSD.org > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. > > > Devin, > > On Mon, May 09, 2011 at 04:01:14PM -0700, Devin Teske wrote: > > > -----Original Message----- > > > From: owner-freebsd-rc@freebsd.org > > > [mailto:owner-freebsd-rc@freebsd.org] > > > On Behalf Of Doug Barton > > > Sent: Monday, May 09, 2011 1:28 PM > > > To: freebsd-rc@freebsd.org > > > Cc: Jason Hellenthal > > > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > > > etc/rc.conf.d/*.conf namespace. > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > I agree with Gordon's analysis that this proposal adds a lot of > > > potential for confusion with very little real benefit. Your post > > > describes _what_ you want > > to > > > do, but I'm confused about _why_ you would want to do it. Can you > > > give a use case example? > > > > > > I also feel compelled to point out that if the functionality you > > > want is > > "break > > > certain common knobs for a subset of services out into their own > > > configuration file" then this can already be achieved without any code > changes by placing ". > > > /path/file" in your rc.conf[.local] file(s). You can even put the > > > code snippet > > you > > > posted in there if you really feel that it's the right solution. And > > > yes, I > > heard you > > > say elsewhere in the thread that you don't like to put anything > > > other than variables in rc.conf, but there is nothing actually wrong > > > with doing it, and > > it works. > > > > > > In short, I've reviewed this whole thread to date and haven't yet > > > seen a compelling reason to make this change. > > > > Hi Doug, > > > > First, let me say that we're on the same page, but I'd like to take a > > shot at a worthwhile use-case. > > > > Also, I know you were addressing jhell but I thought I'd chime-in > > because we > > (VICOR) feel that this feature would be very useful to us (envisioned > > use-case described below). > > > > Use Case: > > > > 1. One of many customers runs a site with, say, 35 servers and 89 workstations. > > 2. Each/every machine has a "role" which requires certain services to > > be enabled 3. Server "roles" enable NFS, SSH, FTP, as well as other > > services 4. Workstation "roles" have a wholly separate set of services > > (with some > > in-common) > > 5. Pedestals are yet another "role" > > 6. Machines can satisfy multiple roles 7. The roles are additive 8. > > There are separate roles for different products > > > > So if we need hardware-A to run products A and B in roles "A-Server" > > and "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" > > and "/etc/rc.conf.d/product-B-server.conf". > > > > Meanwhile, if we need hardware-B to run products A and B but in > > workstation roles, we'd install > > "/etc/rc.conf.d/product-A-workstation.conf" and "/etc/rc.conf.d/product-B- > workstation.conf". > > > > Currently the way we solve this is by having a bootstrap script that > > determines what needs to be added to /etc/rc.conf by-way of reading > > the hostname (which of course can be overridden with a command-line > argument). > > > > JHell's proposed idea of allowing one to place any number of well-named > "*.conf" > > files to /etc/rc.conf.d would allow us to separate the roles into > > different files rather than having to augment them into a single file > > (or worse, have the directives scattered throughout /etc/rc.conf.d/${_name}). > > > > This is especially nice because we (as the makers of "Product-A" and > > "Product-B") are not the ones that maintain the system. The customers > > purchase equipment, use our bootstrap scripts to configure things like > /etc/rc.conf et. > > al., and then proceed to run our software in the configured manner. > > One of the largest contentions in this scenario is that our > > product-based rc.conf(5) settings end up in the same file as the customer- > based rc.conf(5) settings. > > Things that have nothing to do with our product are indistinguishable > > from others. > > > > I fully support JHells addition because it would immediately allow us > > to maintain static configs required to operate our product separately > > from the dynamic configs created by the customer. > > Thank you again for reponding and calling more attention and adding some more > intuitive knowledge behind this. > > I would like to add a note to you on this though. I see one possible problem with > the way it is right now in the patch. It is procesed after rc.conf, rc.conf.local so it > does override those values. Should instead it be treated the opposite and > process before rc.conf, rc.conf.local so it can be overridden by a more centralized > config ? > > I see a greater potential having it act as a user specified defaults than I do a > rc.conf or rc.conf.local override. What do you think ? everyone else ? Doug ? I talked about this with our lead developers and we think we came up with something that has real significant potential. We suggest that your source the rc.cond.d/*.conf files: a. After /etc/rc.conf b. Before /etc/rc.conf.local Half our developers said that it would be nice if /etc/rc.conf.d/product.conf could override rc.conf(5) and the other half said it would be nice if it was the other way around. Then we thought about it for a moment, and we realized that if you sourced them in-between the two files, that you could accommodate both parties. In this setup, we'd have /etc/rc.conf be the initial override file that overrides /etc/defaults/rc.conf. Then /etc/rc.conf.d/product.conf would override that. And finally, /etc/rc.conf.local would be end-all-be-all of overrides. Nothing would be capable of overriding /etc/rc.conf.local (which seems to suit the name -- "local" should indicate that the "non-local" can be inherited from a master configuration, perhaps site-wide or pod-specific). What do you think? I think it would be the "happy median." -- 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. _____________ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 02:40:19 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BC70F1065672 for ; Tue, 10 May 2011 02:40:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 20F0515000D; Tue, 10 May 2011 02:40:18 +0000 (UTC) Message-ID: <4DC8A592.2090202@FreeBSD.org> Date: Mon, 09 May 2011 19:40:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jason Hellenthal References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <20110509235746.GC2558@DataIX.net> In-Reply-To: <20110509235746.GC2558@DataIX.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:40:19 -0000 On 05/09/2011 16:57, Jason Hellenthal wrote: > > Doug, > > On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: > Sorry Doug but rc.conf.d is already laid out for the user to use as > mentioned by rc.conf(5) with a suggested use but unfortunately has quite a > few side effects that I am not going to bother re-writing about again. I read what you have written to date, but I don't see anything other than "It doesn't work the way I want it to." I just re-read the description in rc.conf.5, and I think it's clear, but I wouldn't object to suggestions to improve it. > In reply to your previous email here is one exercise that should point > out the broken functionality fairly clearly or at least I hope clearly > enough that you realize how a normal user would look at it. > > From scratch, no rc.conf. No normal user would do that, so I reject your premise. :) > Setup a NFS server with lockd, statd, mountd, > rpcbind using only rc.conf.d/${_name} namespace and then try starting > these services using service(8) and /etc/rc.d/* files. Then read > rc.conf(5) and tell me the suggestion for jail makes sense. The various nfs-related options are a particularly pathological case, no one is disputing that. However, for the vast majority of purposes the one-name-at-a-time method works fine. And given that most users don't need anything even approaching the type of functionality that you're proposing, I still don't see a problem. > If you still disagree after doing this then please by all means eradicate > rc.conf.d from rc.conf(5) and remove its functionality from rc.subr as it > is less than adequate for anybody other than a developers natural use. I hope you'll understand if I politely decline your request. > I do not quite understand why you take such an opposition against > something that fixes this broken functionality but yet retains its > original use. Gordon has already stated it fairly eloquently, but I'll paraphrase. Too much potential for user confusion, for too little benefit. I realize that to you this sounds like a simple change, but the problem is that when you add knobs, users twist them. So every change to something as fundamental as the boot system needs to have really strong justification. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 02:52:57 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1DB44106566B for ; Tue, 10 May 2011 02:52:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 208DF14F303; Tue, 10 May 2011 02:52:55 +0000 (UTC) Message-ID: <4DC8A887.6060806@FreeBSD.org> Date: Mon, 09 May 2011 19:52:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Devin Teske References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <00df01cc0eb2$f9837010$ec8a5030$@vicor.com> In-Reply-To: <00df01cc0eb2$f9837010$ec8a5030$@vicor.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Jason Hellenthal' , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:52:57 -0000 On 05/09/2011 18:38, Devin Teske wrote: >> -----Original Message----- >> From: Doug Barton [mailto:dougb@FreeBSD.org] >> On 05/09/2011 16:01, Devin Teske wrote: >>> Hi Doug, >>> >>> First, let me say that we're on the same page, >> >> We're not, actually. > > In my locale, the phrase "we're on the same page" actually means "I agree with > your last statements." Your response is taken as if you mean to say that I was > wrong in agreeing with you. Wait, what? That doesn't rightly make much sense. > > I frankly don't understand the origin of this perceived hostility. I'm not going to debate the meaning of "on the same page" with you, so let be more clear. You and I do not agree. Oh, and there is no hostility. >>> but I'd like to take a shot at a worthwhile use-case. >>> >>> Also, I know you were addressing jhell but I thought I'd chime-in >>> because we >>> (VICOR) feel that this feature would be very useful to us (envisioned >>> use-case described below). >>> >>> Use Case: >>> >>> 1. One of many customers runs a site with, say, 35 servers and 89 > workstations. >>> 2. Each/every machine has a "role" which requires certain services to >>> be enabled 3. Server "roles" enable NFS, SSH, FTP, as well as other >>> services 4. Workstation "roles" have a wholly separate set of services >>> (with some >>> in-common) >>> 5. Pedestals are yet another "role" >>> 6. Machines can satisfy multiple roles 7. The roles are additive 8. >>> There are separate roles for different products >>> >>> So if we need hardware-A to run products A and B in roles "A-Server" >>> and "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" >>> and "/etc/rc.conf.d/product-B-server.conf". >> >> You can already do this at least 2 different ways. The first is the method I > outlined >> in my previous post. > > If by that you mean your suggestion to add ". /path/file" to rc.conf(5) et. al., > that's non-copacetic as I forgot to mention that we (as a product vendor) do not > control rc.conf(5), rather our customers do. Do you control /etc/defaults/rc.conf? If so, you can change rc_conf_files. (See?, I told you I could come up with more ways to do the same thing.) > In fact, we have an rc.d script that uses sup(1)/cvsup(1) to pull down > rc.conf(5) from a central server, allowing central management of all machines. I haven't seen anything yet which eliminates the idea of sourcing the additional conf files from rc.conf[.local]. You just add something like: # Vicor product configuration: . /path/product-a-file I realize that you'd like to give the users full control over both of those files though, which is why I suggested /etc/defaults/rc.conf might be another solution. >> The second would be to have wrapper rc.d scripts in >> /usr/local/etc/rc.d that start the required services for either product; with > or >> without correspondingly named config files in /etc/rc.conf.d. (Personally I > would >> set the right values in the scripts themselves.) > > I find this suggestion to be a gross perversion of the boot process. So don't use it. My feelings won't be hurt. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 03:07:25 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9110A106564A; Tue, 10 May 2011 03:07:25 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3909D8FC15; Tue, 10 May 2011 03:07:24 +0000 (UTC) Received: by iwn33 with SMTP id 33so6881246iwn.13 for ; Mon, 09 May 2011 20:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=5WBOYwC9coWhw42ZyVk3moeRF/0ZgkI+nmjyVqhnuqg=; b=AZ4fUvNLzKasMt6MlDpAl2tvllpe4tKRxR/8uZZuuAxV36kJr7j1n3enaFLyRX5a+S mNOqCOfAEpk5+iN00edPKU8Id5lOOohYMx4vZszfmXp+u1DIIHMsjYHsvbQpXn2CBqac UfUf8CPUZkHuSYC9ImviQfcVqjxkoT9jP11p8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=eJrvOf/6wOYXKRmtGpdscc14TC2/CXw2HIiLVACdfLYAiNILnaXMOWwCOFZXkDjCo3 o6DG9/Me1MLY8gtxbbnj7B9AZ9CJX0mcvq0yA/664bTxRYjPOIUktWiPD/VM/zAcDj5O tmPJWsj9f9IlHOjpVsKGjuyxMLwwvh10y1E0c= Received: by 10.42.161.193 with SMTP id u1mr3247751icx.20.1304996844558; Mon, 09 May 2011 20:07:24 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id jv9sm2657986icb.13.2011.05.09.20.07.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 20:07:23 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A37JTC019782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 23:07:20 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A37IQG019781; Mon, 9 May 2011 23:07:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 23:07:18 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110510030718.GA18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 03:07:25 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 06:53:43PM -0700, Devin Teske wrote: > Jason, >=20 > > rc.conf or rc.conf.local override. What do you think ? everyone else ? = Doug ? >=20 > I talked about this with our lead developers and we think we came up with > something that has real significant potential. >=20 > We suggest that your source the rc.cond.d/*.conf files: >=20 > a. After /etc/rc.conf > b. Before /etc/rc.conf.local >=20 > Half our developers said that it would be nice if /etc/rc.conf.d/product.= conf > could override rc.conf(5) and the other half said it would be nice if it = was the > other way around. Then we thought about it for a moment, and we realized = that if > you sourced them in-between the two files, that you could accommodate both > parties. >=20 > In this setup, we'd have /etc/rc.conf be the initial override file that > overrides /etc/defaults/rc.conf. Then /etc/rc.conf.d/product.conf would o= verride > that. And finally, /etc/rc.conf.local would be end-all-be-all of override= s. > Nothing would be capable of overriding /etc/rc.conf.local (which seems to= suit > the name -- "local" should indicate that the "non-local" can be inherited= from a > master configuration, perhaps site-wide or pod-specific). >=20 > What do you think? I think it would be the "happy median." >=20 I am somewhat sketchy of putting it between the two. Reason being is I=20 know quite a few people that already place anything that has to do with=20 ports(7) into rc.conf.local just to keep it seperate from the systems=20 rc.conf. I can see that raising a few eyebrows. As of right now its thought of that= =20 rc.conf and rc.conf.local get processed consecutively and would have to be= =20 explained quite rigorously how they actually fall in order. Only my=20 opinion though, its up for grabs. 1). If its sourced before then it can be considered user pre-defined=20 defaults.=20 2). If its sourced after then it becomes user defined overrides for=20 anything in rc.conf or rc.conf.local=20 3). If placed between then I feel it becomes an extension of rc.conf=20 leaving rc.conf.local to be the final say on all configs. This is=20 intentionally what rc.conf.local was meant for anyway. Really I personally do not object to either of the three listed above and= =20 can see a point of view from all three sides but if I was forced to vote=20 for one of them I would probably have to go with 3. User feedback for this= =20 type of thing is greatly needed & appreciated. --=20 ( python -c "import this" )=20 Regards, (jhell) Jason Hellenthal --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyKvlAAoJEJBXh4mJ2FR+sIcIAJaN/mcB2BY3PtiIhzV1zaeE QPmzKHPoCpVV9Jf/XfEC5N5htnNlDxOtf01DiO0i2NOL59CSTxnOeAdU5Mw521mW bY2uYsclz9Sjcrz1OMUdZ/0fxRXBSwjePsRUbqwlARS4qCXR3Se5jAywPUkFwXYl 9GeIGVXfQD2AJuNcOlWhL6Hx0TBt/4pVHMvKSZbiL3I5q/l13RxoE9kE6OwH0RoG KWmc8tjT1jsNY+S9mWAp03xMgYXRdAUP+RtkpQvVu7AM3i1whFU2yxPWQjDioPzY itF/YC5l2JfGo95M+/1vQ8ReAOxRblgJ0FuxbfnsHG03q+2rLqnOL/KxQUi6e2U= =8tIU -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-rc@FreeBSD.ORG Tue May 10 03:39:30 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE177106566C; Tue, 10 May 2011 03:39:30 +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 A8ABB8FC08; Tue, 10 May 2011 03:39:30 +0000 (UTC) Received: from SBHFISLREXT03 ([10.132.254.62]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p4A3dTbp005966; Mon, 9 May 2011 22:39:29 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by SBHFISLREXT03 with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 22:39:41 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:39:28 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:39:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Devin Teske In-Reply-To: <20110510030718.GA18435@DataIX.net> Date: Mon, 9 May 2011 20:39:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> <20110510030718.GA18435@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 May 2011 03:39:28.0227 (UTC) FILETIME=[DD5E7B30:01CC0EC3] Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 03:39:31 -0000 On May 9, 2011, at 8:07 PM, Jason Hellenthal wrote: >=20 > Devin, >=20 > On Mon, May 09, 2011 at 06:53:43PM -0700, Devin Teske wrote: >> Jason, >>=20 >>> rc.conf or rc.conf.local override. What do you think ? everyone else ? = Doug ? >>=20 >> I talked about this with our lead developers and we think we came up with >> something that has real significant potential. >>=20 >> We suggest that your source the rc.cond.d/*.conf files: >>=20 >> a. After /etc/rc.conf >> b. Before /etc/rc.conf.local >>=20 >> Half our developers said that it would be nice if /etc/rc.conf.d/product= .conf >> could override rc.conf(5) and the other half said it would be nice if it= was the >> other way around. Then we thought about it for a moment, and we realized= that if >> you sourced them in-between the two files, that you could accommodate bo= th >> parties. >>=20 >> In this setup, we'd have /etc/rc.conf be the initial override file that >> overrides /etc/defaults/rc.conf. Then /etc/rc.conf.d/product.conf would = override >> that. And finally, /etc/rc.conf.local would be end-all-be-all of overrid= es. >> Nothing would be capable of overriding /etc/rc.conf.local (which seems t= o suit >> the name -- "local" should indicate that the "non-local" can be inherite= d from a >> master configuration, perhaps site-wide or pod-specific). >>=20 >> What do you think? I think it would be the "happy median." >>=20 >=20 > I am somewhat sketchy of putting it between the two. Reason being is I=20 > know quite a few people that already place anything that has to do with= =20 > ports(7) into rc.conf.local just to keep it seperate from the systems=20 > rc.conf. >=20 > I can see that raising a few eyebrows. As of right now its thought of tha= t=20 > rc.conf and rc.conf.local get processed consecutively and would have to b= e=20 > explained quite rigorously how they actually fall in order. Only my=20 > opinion though, its up for grabs. >=20 > 1). If its sourced before then it can be considered user pre-defined=20 > defaults.=20 This sounds the most reasonable/desirable. In our hypothetical scenario whe= re the customer controls both rc.conf and rc.conf.local, we'd eventually co= me across the request from a customer to disable a product-wide feature on = a per-customer basis. In this case, adding something to their sup(1)/cvsup(= 1)-distributed rc.conf(5) would override the default. Support folks could g= o home and the override is in-place, problem solved. Conversely for either of the below scenarios, adding an override would then= become more difficult. Ultimately in our scenario, the ifconfig_* elements= are in /etc/rc.conf.local (and therefore cannot be distributed) and the si= te-wide specifics (NTP server specifics, etc.) are in the global /etc/rc.co= nf (distributed to all hosts in the site). So unless you source before the = rc_conf_files, the customer would be frustrated and end up throwing an /etc= /rc.conf.d/zzz.conf into their sup(1)/cvsup(1) distributed directory to ove= rride our /etc/rc.conf.d/product.conf files. Since we want to satisfy the customer, #1 becomes the only sensible approac= h. Sourcing /etc/rc.conf.d/*.conf before rc_conf_files. It then becomes a s= ort of shim to override /etc/defaults/rc.conf (but again, only if the direc= tory /etc/rc.conf.d exists, which it shouldn't by-default in any installed = distribution unless the owner/operator/developer adds one). I can then envision a package containing a /etc/rc.conf.d/product.conf -- p= erhaps to be used sparingly and only when the package is for a product that= takes control of a machine, IMHO >=20 > 2). If its sourced after then it becomes user defined overrides for=20 > anything in rc.conf or rc.conf.local=20 >=20 > 3). If placed between then I feel it becomes an extension of rc.conf=20 > leaving rc.conf.local to be the final say on all configs. This is=20 > intentionally what rc.conf.local was meant for anyway. >=20 >=20 > Really I personally do not object to either of the three listed above and= =20 > can see a point of view from all three sides but if I was forced to vote= =20 > for one of them I would probably have to go with 3. User feedback for thi= s=20 > type of thing is greatly needed & appreciated. It was upon second thought that I actually have to change my vote to be #1 = as the best option. That would make /etc/rc.conf.d two things: 1. /etc/rc.conf.d/NAME where NAME is /etc/rc.d/NAME or /usr/local/etc/rc.d/= NAME NAME files in /etc/rc.conf.d would be sourced anytime NAME RCNG script is u= tilized (and these files override both rc.conf and rc.conf.local if they ex= ist). 2. /etc/rc.conf.d/CUSTOM.conf where CUSTOM is anything you want. CUSTOM.conf files in /etc/rc.conf.d would be sourced before rc_conf_files (= which include /etc/rc.conf and /etc/rc.conf.local) in source_rc_confs of /e= tc/defaults/rc.conf. This would allow the files to similarly be sourced any= time NAME RCNG script is utilized (and these files override the defaults in= /etc/defaults/rc.conf). Is that a correct approximation of your proposed final implementation? --=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. _____________ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 03:58:08 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2EA1106564A; Tue, 10 May 2011 03:58:08 +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 7742F8FC12; Tue, 10 May 2011 03:58:08 +0000 (UTC) Received: from sbhfislrext01.fnfis.com ([192.168.249.167]) by SCSFISLTC02 (8.14.3/8.14.3) with ESMTP id p4A3w7tr022072; Mon, 9 May 2011 22:58:07 -0500 Received: from sbhfisltcgw01.FNFIS.COM (Not Verified[10.132.248.121]) by sbhfislrext01.fnfis.com with MailMarshal (v6, 5, 4, 7535) id ; Mon, 09 May 2011 22:58:07 -0500 Received: from SBHFISLTCGW04.FNFIS.COM ([10.132.248.123]) by sbhfisltcgw01.FNFIS.COM with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:58:06 -0500 Received: from [10.0.0.102] ([10.132.254.136]) by SBHFISLTCGW04.FNFIS.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 22:57:59 -0500 Mime-Version: 1.0 (Apple Message framework v1084) From: Devin Teske In-Reply-To: <4DC8A887.6060806@FreeBSD.org> Date: Mon, 9 May 2011 20:57:57 -0700 Message-Id: References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <00df01cc0eb2$f9837010$ec8a5030$@vicor.com> <4DC8A887.6060806@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 May 2011 03:58:00.0315 (UTC) FILETIME=[7439A4B0:01CC0EC6] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: 'Jason Hellenthal' , freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 03:58:08 -0000 On May 9, 2011, at 7:52 PM, Doug Barton wrote: > On 05/09/2011 18:38, Devin Teske wrote: >>> -----Original Message----- >>> From: Doug Barton [mailto:dougb@FreeBSD.org] >>>=20 >>>> but I'd like to take a shot at a worthwhile use-case. >>>>=20 >>>> Also, I know you were addressing jhell but I thought I'd chime-in >>>> because we >>>> (VICOR) feel that this feature would be very useful to us (envisioned >>>> use-case described below). >>>>=20 >>>> Use Case: >>>>=20 >>>> 1. One of many customers runs a site with, say, 35 servers and 89 >> workstations. >>>> 2. Each/every machine has a "role" which requires certain services to >>>> be enabled 3. Server "roles" enable NFS, SSH, FTP, as well as other >>>> services 4. Workstation "roles" have a wholly separate set of services >>>> (with some >>>> in-common) >>>> 5. Pedestals are yet another "role" >>>> 6. Machines can satisfy multiple roles 7. The roles are additive 8. >>>> There are separate roles for different products >>>>=20 >>>> So if we need hardware-A to run products A and B in roles "A-Server" >>>> and "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf" >>>> and "/etc/rc.conf.d/product-B-server.conf". >>>=20 >>> You can already do this at least 2 different ways. The first is the met= hod I >> outlined >>> in my previous post. >>=20 >> If by that you mean your suggestion to add ". /path/file" to rc.conf(5) = et. al., >> that's non-copacetic as I forgot to mention that we (as a product vendor= ) do not >> control rc.conf(5), rather our customers do. >=20 > Do you control /etc/defaults/rc.conf? If so, you can change rc_conf_files= . (See?, I told you I could come up with more ways to do the same thing.) If anything, we'd implement the patch to source_rc_confs to source /etc/rc.= conf.d/*.conf before rc_conf_files, which (if I understand correctly) is wh= at JHell's patch proposes to do. >=20 >> In fact, we have an rc.d script that uses sup(1)/cvsup(1) to pull down >> rc.conf(5) from a central server, allowing central management of all mac= hines. >=20 > I haven't seen anything yet which eliminates the idea of sourcing the add= itional conf files from rc.conf[.local]. You just add something like: >=20 > # Vicor product configuration: > . /path/product-a-file >=20 > I realize that you'd like to give the users full control over both of tho= se files though, which is why I suggested /etc/defaults/rc.conf might be an= other solution. Relinquishing control means not requiring them to have anything. The above = proposed solution requires at least a single line containing aforementioned= ". /path/product-a-file". Whether you inject it into their files with boot= strap scripts, mandate that someone add it with a text-editor, or if it get= s there by magic, any way you've not truly relinquished control, have you? Another argument is that if you instruct your customers to add ". /path/pro= duct-a-file" to their rc.conf[.local] file, then you'll inevitably be asked= what "." does (approximately 10 minutes after the first person forgets sai= d "."), at which point you've now opened a bag full of cats. Never would I = deny that rc.conf(5) accepts full sh(1) syntax, but also would I never go a= round advertising it to every person that touches a command-line within our= organization. It's often best left to have the majority think of it as a p= lain KEY=3DVALUE text file, rather than go about advertising with lines of = ". /path/product-a-file" allusions of grandeur to budding sh(1) enthusiasts. A view askew. Your mileage may vary. --=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. _____________ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 04:08:27 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 724E1106566B; Tue, 10 May 2011 04:08:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4FB8FC14; Tue, 10 May 2011 04:08:26 +0000 (UTC) Received: by iyj12 with SMTP id 12so6974577iyj.13 for ; Mon, 09 May 2011 21:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=tGGQTHxJDGsktMuhjz0WIzf4oA/nkEo19+KLljL87Sc=; b=g9UzQC0AkVzihVe+pxqhX84gG8jpzNHhAzr4kwB1l4VClyv6pH/IrBOCPIFP6hPdb8 zzuW640bfypfU4M/YjIWQZNeekouihuZCK7btcm+48LT6qKwTwtNPIIB+lyl3+5Nd0u/ tgjCkEo8KKvtvt0XjvDqAP3jYS5wIGgiEObyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=h5Ht+3rGI8sD2MJmdpkNw9Ny7iy0TpL14oxE9sMPx9fFd6aeKR+rIVuAZFcXGt0nVk 713QftKv/VkP7rmBwfeoui5GTL8PfBW2C5ICB87nviJSrz2Ctq8DOvgy8iWSiNzitvmd lO3MX8UPFC69JenEeoApj9qNyXg0jq5ZVFq+I= Received: by 10.42.54.82 with SMTP id q18mr6592901icg.311.1305000506455; Mon, 09 May 2011 21:08:26 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id jv9sm2687766icb.1.2011.05.09.21.08.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 21:08:25 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A48M8T028527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 00:08:22 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A48MHm028526; Tue, 10 May 2011 00:08:22 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 00:08:22 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20110510040822.GB18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <20110509235746.GC2558@DataIX.net> <4DC8A592.2090202@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <4DC8A592.2090202@FreeBSD.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 04:08:27 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Doug, On Mon, May 09, 2011 at 07:40:18PM -0700, Doug Barton wrote: > On 05/09/2011 16:57, Jason Hellenthal wrote: > > > > Doug, > > > > On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: >=20 > > Sorry Doug but rc.conf.d is already laid out for the user to use as > > mentioned by rc.conf(5) with a suggested use but unfortunately has quit= e a > > few side effects that I am not going to bother re-writing about again. >=20 > I read what you have written to date, but I don't see anything other=20 > than "It doesn't work the way I want it to." I just re-read the=20 > description in rc.conf.5, and I think it's clear, but I wouldn't object= =20 > to suggestions to improve it. >=20 > > In reply to your previous email here is one exercise that should point > > out the broken functionality fairly clearly or at least I hope clearly > > enough that you realize how a normal user would look at it. > > > > From scratch, no rc.conf. >=20 > No normal user would do that, so I reject your premise. :) >=20 Ok let me re-state that because you seem to have taken that litterally as= =20 absolutely no rc.conf. "A rc.conf but without the needed nfs related=20 parts" This is an example!. > > Setup a NFS server with lockd, statd, mountd, > > rpcbind using only rc.conf.d/${_name} namespace and then try starting > > these services using service(8) and /etc/rc.d/* files. Then read > > rc.conf(5) and tell me the suggestion for jail makes sense. >=20 > The various nfs-related options are a particularly pathological case, no= =20 > one is disputing that. However, for the vast majority of purposes the=20 > one-name-at-a-time method works fine. And given that most users don't=20 > need anything even approaching the type of functionality that you're=20 > proposing, I still don't see a problem. >=20 I was not asking your you opinion of the way it works. You asked for an=20 example and one was given and you seem to be all opposed to even going=20 through and testing out that example to see where the stumbling blocks are= =20 as you apparently have no recognition of them now. NFS is not the only case. > > If you still disagree after doing this then please by all means eradica= te > > rc.conf.d from rc.conf(5) and remove its functionality from rc.subr as = it > > is less than adequate for anybody other than a developers natural use. >=20 > I hope you'll understand if I politely decline your request. >=20 I was not expecting anything less than your typical response. > > I do not quite understand why you take such an opposition against > > something that fixes this broken functionality but yet retains its > > original use. >=20 > Gordon has already stated it fairly eloquently, but I'll paraphrase. Too= =20 > much potential for user confusion, for too little benefit. I realize=20 > that to you this sounds like a simple change, but the problem is that=20 > when you add knobs, users twist them. So every change to something as=20 > fundamental as the boot system needs to have really strong justification. >=20 Sadly at this point you still seem to not realize the complicated state=20 that rc.conf.d is in. This is not adding a new knob and you seem to miss=20 that part as well. This fixes that complication on the rc.conf.d directory= =20 and it could be properly implemented in a way that it should have been in= =20 the first place as the manual suggests. What do you propose to do with the manual page ? can you sum that up for=20 me please ? I would be quite interested in how you or anyone for that=20 matter explain properly how this is actually working. --=20 Regards, (jhell) Jason Hellenthal --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyLo1AAoJEJBXh4mJ2FR+Gj4IAKAPFBFn5gV1RJ+NU125EG1v zrOq9BXac/0I5dlIV5PzreEEmMU4GRHAMRBi9UZ2j0joip+CiWt5QumSKOkm7ABw 7CCpQUS/hjretxoph7anAiU0gXonc7tlIcXmW4c70ne/Z+2CWphqimSzm8CbkSaB 1F1jc2tia2kePNWUAfRHYi2k8m6CToGbQKKvK4Eii9DQoD0Vo7sQf3qH7ptcKhgh QPrOFDggWoUwjb96XAyVXLor4DAUKhxUgfc/F/LUYn3ddif+H7ltwq36bNAIjqgx UDSSR1wFEBcxMgq9DZ1IzkhexUzFmrhu2oKm7uYov2sgVKIApgAqxKWhiq6BOEc= =dmUL -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-rc@FreeBSD.ORG Tue May 10 04:55:12 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A9430106564A for ; Tue, 10 May 2011 04:55:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C632E160645; Tue, 10 May 2011 04:55:11 +0000 (UTC) Message-ID: <4DC8C52E.9040203@FreeBSD.org> Date: Mon, 09 May 2011 21:55:10 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jason Hellenthal References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <20110509235746.GC2558@DataIX.net> <4DC8A592.2090202@FreeBSD.org> <20110510040822.GB18435@DataIX.net> In-Reply-To: <20110510040822.GB18435@DataIX.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 04:55:12 -0000 This will be my last post on this topic unless something new arises. Please don't cc me on any more responses. On 05/09/2011 21:08, Jason Hellenthal wrote: > > Doug, > > On Mon, May 09, 2011 at 07:40:18PM -0700, Doug Barton wrote: >> On 05/09/2011 16:57, Jason Hellenthal wrote: >>> >>> Doug, >>> >>> On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: >> >>> Sorry Doug but rc.conf.d is already laid out for the user to use as >>> mentioned by rc.conf(5) with a suggested use but unfortunately has quite a >>> few side effects that I am not going to bother re-writing about again. >> >> I read what you have written to date, but I don't see anything other >> than "It doesn't work the way I want it to." I just re-read the >> description in rc.conf.5, and I think it's clear, but I wouldn't object >> to suggestions to improve it. >> >>> In reply to your previous email here is one exercise that should point >>> out the broken functionality fairly clearly or at least I hope clearly >>> enough that you realize how a normal user would look at it. >>> >>> From scratch, no rc.conf. >> >> No normal user would do that, so I reject your premise. :) >> > > Ok let me re-state that because you seem to have taken that litterally as > absolutely no rc.conf. "A rc.conf but without the needed nfs related > parts" This is an example!. Hence the smiley. >>> Setup a NFS server with lockd, statd, mountd, >>> rpcbind using only rc.conf.d/${_name} namespace and then try starting >>> these services using service(8) and /etc/rc.d/* files. Then read >>> rc.conf(5) and tell me the suggestion for jail makes sense. >> >> The various nfs-related options are a particularly pathological case, no >> one is disputing that. However, for the vast majority of purposes the >> one-name-at-a-time method works fine. And given that most users don't >> need anything even approaching the type of functionality that you're >> proposing, I still don't see a problem. >> > > I was not asking your you opinion of the way it works. You asked for an > example and one was given and you seem to be all opposed to even going > through and testing out that example to see where the stumbling blocks are > as you apparently have no recognition of them now. NFS is not the only case. To the extent I understand your paragraph above, I don't think you really understand where I'm coming from at all. I don't need to follow your suggestion, I already know that for the particular pathological case you described the rc.conf.d method is not appropriate. What you seem to be missing is that your suggestion is not necessary to solve the problem. To the extent that it is necessary to provide a solution to this at all, multiple solutions already exist. >>> I do not quite understand why you take such an opposition against >>> something that fixes this broken functionality but yet retains its >>> original use. >> >> Gordon has already stated it fairly eloquently, but I'll paraphrase. Too >> much potential for user confusion, for too little benefit. I realize >> that to you this sounds like a simple change, but the problem is that >> when you add knobs, users twist them. So every change to something as >> fundamental as the boot system needs to have really strong justification. >> > > Sadly at this point you still seem to not realize the complicated state > that rc.conf.d is in. I hope you'll understand if once again I respectfully disagree. > This is not adding a new knob I was using that in the colloquial sense. If you give users the chance to do something, some percentage of them will do it. > and you seem to miss > that part as well. This fixes that complication on the rc.conf.d directory > and it could be properly implemented in a way that it should have been in > the first place as the manual suggests. > > > What do you propose to do with the manual page ? What I'm saying is that IMO there is nothing in rc.conf.5 that is confusing, and if you believe that it needs to be clarified please feel free to submit suggestions. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-rc@FreeBSD.ORG Tue May 10 05:15:19 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B159106564A; Tue, 10 May 2011 05:15:19 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3D5A8FC08; Tue, 10 May 2011 05:15:18 +0000 (UTC) Received: by iwn33 with SMTP id 33so6964626iwn.13 for ; Mon, 09 May 2011 22:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=O2v5xW54aCLogi78+TGc4Iin4yAPzgCEQn2Bqy1F7js=; b=JbCSWnXbYay3a0Xzmu2isCtj2iKZmQTzKo5qx1OUg2LKULrrFknqxf08PJUoYm+Fxk nKA3AueeHueXBII18m2jlwjuKYHPrxENWAdDhmbPTjpYtGMVmIV7BWiFDZk3/4j7DOp0 K1883wSeeujMHgjf2M/URdoJLTfhqtXjGBIKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=K7eJz85ZiQbNDjm7kh9pel2K5O+h0QS3n7GUecojQmvMu4r5pseJWhs13M/oLkCHp/ VjLnwXxErARH06LrW2Eyq6p/pQzxofdDo4Nz/wW+0fpZJAba+BwMfwJ4BAPYEbhkCGTo Zqwj1ffOcsDVgysCylEo8fe6p9TxuLTdo2djY= Received: by 10.43.54.200 with SMTP id vv8mr7110872icb.378.1305004518325; Mon, 09 May 2011 22:15:18 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id t1sm2958207ibm.38.2011.05.09.22.15.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:15:17 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A5FEeI031464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 01:15:14 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A5FEdD031463; Tue, 10 May 2011 01:15:14 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 01:15:13 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110510051513.GC18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> <20110510030718.GA18435@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 05:15:19 -0000 --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 08:39:25PM -0700, Devin Teske wrote: >=20 > On May 9, 2011, at 8:07 PM, Jason Hellenthal wrote: >=20 > >=20 > > Devin, > >=20 > > On Mon, May 09, 2011 at 06:53:43PM -0700, Devin Teske wrote: > >> Jason, > >>=20 > >>> rc.conf or rc.conf.local override. What do you think ? everyone else = ? Doug ? > >>=20 > >> I talked about this with our lead developers and we think we came up w= ith > >> something that has real significant potential. > >>=20 > >> We suggest that your source the rc.cond.d/*.conf files: > >>=20 > >> a. After /etc/rc.conf > >> b. Before /etc/rc.conf.local > >>=20 > >> Half our developers said that it would be nice if /etc/rc.conf.d/produ= ct.conf > >> could override rc.conf(5) and the other half said it would be nice if = it was the > >> other way around. Then we thought about it for a moment, and we realiz= ed that if > >> you sourced them in-between the two files, that you could accommodate = both > >> parties. > >>=20 > >> In this setup, we'd have /etc/rc.conf be the initial override file that > >> overrides /etc/defaults/rc.conf. Then /etc/rc.conf.d/product.conf woul= d override > >> that. And finally, /etc/rc.conf.local would be end-all-be-all of overr= ides. > >> Nothing would be capable of overriding /etc/rc.conf.local (which seems= to suit > >> the name -- "local" should indicate that the "non-local" can be inheri= ted from a > >> master configuration, perhaps site-wide or pod-specific). > >>=20 > >> What do you think? I think it would be the "happy median." > >>=20 > >=20 > > I am somewhat sketchy of putting it between the two. Reason being is I= =20 > > know quite a few people that already place anything that has to do with= =20 > > ports(7) into rc.conf.local just to keep it seperate from the systems= =20 > > rc.conf. > >=20 > > I can see that raising a few eyebrows. As of right now its thought of t= hat=20 > > rc.conf and rc.conf.local get processed consecutively and would have to= be=20 > > explained quite rigorously how they actually fall in order. Only my=20 > > opinion though, its up for grabs. > >=20 > > 1). If its sourced before then it can be considered user pre-defined=20 > > defaults.=20 >=20 > This sounds the most reasonable/desirable. In our hypothetical scenario w= here the customer controls both rc.conf and rc.conf.local, we'd eventually = come across the request from a customer to disable a product-wide feature o= n a per-customer basis. In this case, adding something to their sup(1)/cvsu= p(1)-distributed rc.conf(5) would override the default. Support folks could= go home and the override is in-place, problem solved. >=20 > Conversely for either of the below scenarios, adding an override would th= en become more difficult. Ultimately in our scenario, the ifconfig_* elemen= ts are in /etc/rc.conf.local (and therefore cannot be distributed) and the = site-wide specifics (NTP server specifics, etc.) are in the global /etc/rc.= conf (distributed to all hosts in the site). So unless you source before th= e rc_conf_files, the customer would be frustrated and end up throwing an /e= tc/rc.conf.d/zzz.conf into their sup(1)/cvsup(1) distributed directory to o= verride our /etc/rc.conf.d/product.conf files. >=20 > Since we want to satisfy the customer, #1 becomes the only sensible appro= ach. Sourcing /etc/rc.conf.d/*.conf before rc_conf_files. It then becomes a= sort of shim to override /etc/defaults/rc.conf (but again, only if the dir= ectory /etc/rc.conf.d exists, which it shouldn't by-default in any installe= d distribution unless the owner/operator/developer adds one). >=20 > I can then envision a package containing a /etc/rc.conf.d/product.conf --= perhaps to be used sparingly and only when the package is for a product th= at takes control of a machine, IMHO >=20 >=20 >=20 > >=20 > > 2). If its sourced after then it becomes user defined overrides for=20 > > anything in rc.conf or rc.conf.local=20 > >=20 > > 3). If placed between then I feel it becomes an extension of rc.conf=20 > > leaving rc.conf.local to be the final say on all configs. This is=20 > > intentionally what rc.conf.local was meant for anyway. > >=20 > >=20 > > Really I personally do not object to either of the three listed above a= nd=20 > > can see a point of view from all three sides but if I was forced to vot= e=20 > > for one of them I would probably have to go with 3. User feedback for t= his=20 > > type of thing is greatly needed & appreciated. >=20 > It was upon second thought that I actually have to change my vote to be #= 1 as the best option. >=20 > That would make /etc/rc.conf.d two things: >=20 > 1. /etc/rc.conf.d/NAME where NAME is /etc/rc.d/NAME or /usr/local/etc/rc.= d/NAME >=20 > NAME files in /etc/rc.conf.d would be sourced anytime NAME RCNG script is= utilized (and these files override both rc.conf and rc.conf.local if they = exist). >=20 > 2. /etc/rc.conf.d/CUSTOM.conf where CUSTOM is anything you want. >=20 > CUSTOM.conf files in /etc/rc.conf.d would be sourced before rc_conf_files= (which include /etc/rc.conf and /etc/rc.conf.local) in source_rc_confs of = /etc/defaults/rc.conf. This would allow the files to similarly be sourced a= nytime NAME RCNG script is utilized (and these files override the defaults = in /etc/defaults/rc.conf). >=20 > Is that a correct approximation of your proposed final implementation? Not to break existing behavior the way they stand: [...] /etc/defaults/rc.conf /etc/rc.conf.d/CUSTOM /etc/rc.conf /etc/rc.conf.local /etc/rc.conf.d/NAME If I understood that correctly then yes. --=20 Regards, (jhell) Jason Hellenthal --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyMnhAAoJEJBXh4mJ2FR+dSYH/3isBPFBDTg2tVVq9VMiXl43 nz9Vwa9Ikkd8hNK/pPn6J32n1Yb6/Scq7qkt2Gud31ffyHtHRozk8TL4WxUtNh2s IjI+4rYScQuY8GweXBmat8u90GRErJ7fJxrZSIloXDg0TjkzLYRkZXGPao5aRhM8 GFpI9PlPn4hEGm9Q1ScBNxKkX131ztoRN5yWu2vAox+9/Lf7OiH0+zSBYnjkpd90 j8XAFX9vHsFGbEPWXfAnk2Mhsecqd9j7Cs5wwcNDGsRnHHAoKdssYRt+3KSc7Vfp BV0yJX7oUnMvitGT/gwTeGcba1mhijjJtEc3F0uu5Lz9J3TYc3I+KyO9J4HMxtI= =bDPs -----END PGP SIGNATURE----- --O3RTKUHj+75w1tg5-- From owner-freebsd-rc@FreeBSD.ORG Tue May 10 05:35:39 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271581065673; Tue, 10 May 2011 05:35:39 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C1E1A8FC1E; Tue, 10 May 2011 05:35:38 +0000 (UTC) Received: by iwn33 with SMTP id 33so6978059iwn.13 for ; Mon, 09 May 2011 22:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=M7X8puAIzoPXJyQ71JPPBVElIKON5sM3tLSgSi7QyfM=; b=bLODkbn1bIPSQKAxT1Pqi6DECQf7krs7yIckw02HLjoPaBHjzfpPNSIWjpwZthugSU dK7swtS3rnoy5Emc/09sHb1LoWUlPII/DTlcGktfO9ZT1UzlYRIAYovdnziMg9u2BEkt 4DdaMUaH/gwk2FtBuioUst8bQWpCwhAdq5oq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=P9DQf8EOBjLqcOSHSohF+kcjN+KbcxUwo44JBwmFiqSDw0zHyM0y9eRLylbX48BXEn Zm8inEcB7W4hUOYcDCQLBajjBWKDr4NqsM9szpV/dfTDF7DY9lKF4NzWopO1GIWwPp+0 XdyFO0m8in5EmagHJs+27Hu9bUhF1lQW4iBoQ= Received: by 10.42.159.65 with SMTP id k1mr7486094icx.174.1305005738117; Mon, 09 May 2011 22:35:38 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id uf10sm2719914icb.5.2011.05.09.22.35.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 22:35:37 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4A5ZYqi032171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 01:35:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4A5ZYSP032170; Tue, 10 May 2011 01:35:34 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 01:35:34 -0400 From: Jason Hellenthal To: Doug Barton Message-ID: <20110510053534.GD18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <20110509235746.GC2558@DataIX.net> <4DC8A592.2090202@FreeBSD.org> <20110510040822.GB18435@DataIX.net> <4DC8C52E.9040203@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp" Content-Disposition: inline In-Reply-To: <4DC8C52E.9040203@FreeBSD.org> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 05:35:39 -0000 --u65IjBhB3TIa72Vp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 09:55:10PM -0700, Doug Barton wrote: > This will be my last post on this topic unless something new arises.=20 > Please don't cc me on any more responses. >=20 > On 05/09/2011 21:08, Jason Hellenthal wrote: > > > > Doug, > > > > On Mon, May 09, 2011 at 07:40:18PM -0700, Doug Barton wrote: > >> On 05/09/2011 16:57, Jason Hellenthal wrote: > >>> > >>> Doug, > >>> > >>> On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote: > >> > >>> Sorry Doug but rc.conf.d is already laid out for the user to use as > >>> mentioned by rc.conf(5) with a suggested use but unfortunately has qu= ite a > >>> few side effects that I am not going to bother re-writing about again. > >> > >> I read what you have written to date, but I don't see anything other > >> than "It doesn't work the way I want it to." I just re-read the > >> description in rc.conf.5, and I think it's clear, but I wouldn't object > >> to suggestions to improve it. > >> > >>> In reply to your previous email here is one exercise that should point > >>> out the broken functionality fairly clearly or at least I hope clearly > >>> enough that you realize how a normal user would look at it. > >>> > >>> From scratch, no rc.conf. > >> > >> No normal user would do that, so I reject your premise. :) > >> > > > > Ok let me re-state that because you seem to have taken that litterally = as > > absolutely no rc.conf. "A rc.conf but without the needed nfs related > > parts" This is an example!. >=20 > Hence the smiley. >=20 > >>> Setup a NFS server with lockd, statd, mountd, > >>> rpcbind using only rc.conf.d/${_name} namespace and then try starting > >>> these services using service(8) and /etc/rc.d/* files. Then read > >>> rc.conf(5) and tell me the suggestion for jail makes sense. > >> > >> The various nfs-related options are a particularly pathological case, = no > >> one is disputing that. However, for the vast majority of purposes the > >> one-name-at-a-time method works fine. And given that most users don't > >> need anything even approaching the type of functionality that you're > >> proposing, I still don't see a problem. > >> > > > > I was not asking your you opinion of the way it works. You asked for an > > example and one was given and you seem to be all opposed to even going > > through and testing out that example to see where the stumbling blocks = are > > as you apparently have no recognition of them now. NFS is not the only = case. >=20 > To the extent I understand your paragraph above, I don't think you=20 > really understand where I'm coming from at all. I don't need to follow=20 > your suggestion, I already know that for the particular pathological=20 > case you described the rc.conf.d method is not appropriate. >=20 > What you seem to be missing is that your suggestion is not necessary to= =20 > solve the problem. To the extent that it is necessary to provide a=20 > solution to this at all, multiple solutions already exist. >=20 > >>> I do not quite understand why you take such an opposition against > >>> something that fixes this broken functionality but yet retains its > >>> original use. > >> > >> Gordon has already stated it fairly eloquently, but I'll paraphrase. T= oo > >> much potential for user confusion, for too little benefit. I realize > >> that to you this sounds like a simple change, but the problem is that > >> when you add knobs, users twist them. So every change to something as > >> fundamental as the boot system needs to have really strong justificati= on. > >> > > > > Sadly at this point you still seem to not realize the complicated state > > that rc.conf.d is in. >=20 > I hope you'll understand if once again I respectfully disagree. >=20 > > This is not adding a new knob >=20 > I was using that in the colloquial sense. If you give users the chance=20 > to do something, some percentage of them will do it. >=20 > > and you seem to miss > > that part as well. This fixes that complication on the rc.conf.d direct= ory > > and it could be properly implemented in a way that it should have been = in > > the first place as the manual suggests. > > > > > > What do you propose to do with the manual page ? >=20 > What I'm saying is that IMO there is nothing in rc.conf.5 that is=20 > confusing, and if you believe that it needs to be clarified please feel= =20 > free to submit suggestions. >=20 Unfortuneately at Doug's request this will not be CC'd, but this is also=20 the intention of this thread as well. As stated earlier in the thread with= =20 my proposal to tidy this up I also said that once it is laid out for=20 something that is agreed upon that I would update the manual accordingly.= =20 Doing this before the said seen needed fixes to uncomplicate the use of=20 rc.conf.d would be be a great loss of time as it would require documenting= =20 every rc.d script, the names that are exported from them and putting=20 together every combination of such. This type of complexity is what is=20 trying to be avoided while still allowing the user to create well named=20 organized custom configurations. --=20 Regards, (jhell) Jason Hellenthal --u65IjBhB3TIa72Vp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyM6lAAoJEJBXh4mJ2FR+MR0IAIByeg1uoH3xqXKpWdAuc8U2 yIleF39vTuxowgTjn8kyk42UbHjcsKkIF+rV2L1BFyG5TwK4HDwwVaKGJ10OURby gEIIYWyBDyTtODaBDGtFG6uHc3aAXJF1DoV6LgIP1VVMk0kBU7vupk+6Og+xLaZc S1dzYEbPoSiHcgjw+dKqCr6IDO1AJHuXlk2/nBCgF4ao2GASjVNoeoHpgHR+ik+I un9tSftb4XcYAFnZEPTRglLVb0Ms5IcEVmHuk81sCdWz9tf0OjpdW6DYsIutrrff I71CWyocluBp/0ghOkLNlPxhza+vyGsmofxEd4Nib82VaGEaLEdq7ObKXc0wjcU= =ekDW -----END PGP SIGNATURE----- --u65IjBhB3TIa72Vp-- From owner-freebsd-rc@FreeBSD.ORG Wed May 11 00:30:10 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68FF0106564A for ; Wed, 11 May 2011 00:30:10 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 47D758FC12 for ; Wed, 11 May 2011 00:30:10 +0000 (UTC) Received: by pxi11 with SMTP id 11so7028pxi.7 for ; Tue, 10 May 2011 17:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.200 with SMTP id g8mr13006600pbm.362.1305073809755; Tue, 10 May 2011 17:30:09 -0700 (PDT) Received: by 10.68.58.3 with HTTP; Tue, 10 May 2011 17:30:09 -0700 (PDT) In-Reply-To: <20110510051513.GC18435@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> <20110510030718.GA18435@DataIX.net> <20110510051513.GC18435@DataIX.net> Date: Tue, 10 May 2011 17:30:09 -0700 Message-ID: From: Gordon Tetlow To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-rc@freebsd.org, Doug Barton Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 00:30:10 -0000 On Mon, May 9, 2011 at 10:15 PM, Jason Hellenthal wrote: > Not to break existing behavior the way they stand: > [...] > /etc/defaults/rc.conf > /etc/rc.conf.d/CUSTOM.conf > /etc/rc.conf > /etc/rc.conf.local > /etc/rc.conf.d/NAME Having 2 files (well any number of *.conf files actually) sourced from the same directory at different times based solely on name is a bad idea. There isn't enough documentation that will adequately explain how that is supposed to work. I would consider it a major POLA violation. Also, if your stated goal was to allow ports to install sample or sensible defaults into /etc/rc.conf.d, it needs to live in /usr/local/etc instead of /etc. Ports writing data into /etc shouldn't happen. Regards, Gordon From owner-freebsd-rc@FreeBSD.ORG Wed May 11 00:56:01 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CA671065670; Wed, 11 May 2011 00:56:01 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB328FC20; Wed, 11 May 2011 00:56:00 +0000 (UTC) Received: by iwn33 with SMTP id 33so27078iwn.13 for ; Tue, 10 May 2011 17:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=UpfEaikIVTtxi4m0MCk1pv+D9+sR7U5WC0cXG+h6P64=; b=TTAI61C7MK2V/m/B8wMcYtqr4muVRwLv028u4/mjJxPTWcXzeng/8PGoOWU5babvMh NZL1GcrayQoXM0FS7pqTVgwOGpvUZHKychy3YfsAvvrrhawWDKJfQ+PZV9EQZoZxMWus BbuhqHk9SS4WnP6H4uhHvXX3CL4ydcupCLNuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=vjJYsqtArT7e14Xyu8/86jCu5mKu4bew4dwP5GiGlNbQCyc9GuZVmTE+XGYTJKqVdh hQ8HkfBPeC3Xk0zGIxG6RTZ/uiGQPvZIBhYfc5LOuOp7b6IAqykOCDFGOzd8bUeDbIil aVQ7wdEIoSujjknwtoO+eDDd4wPY5Ztd6KuQ0= Received: by 10.42.138.7 with SMTP id a7mr2331155icu.299.1305075360352; Tue, 10 May 2011 17:56:00 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id xe5sm3025778icb.10.2011.05.10.17.55.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 17:55:58 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4B0ttjO060120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2011 20:55:56 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4B0tsPu060119; Tue, 10 May 2011 20:55:54 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 10 May 2011 20:55:54 -0400 From: Jason Hellenthal To: Gordon Tetlow Message-ID: <20110511005554.GB67882@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <20110509233825.GB2558@DataIX.net> <010b01cc0eb5$3c6456e0$b52d04a0$@vicor.com> <20110510030718.GA18435@DataIX.net> <20110510051513.GC18435@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-rc@freebsd.org, Doug Barton Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 00:56:01 -0000 --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gordon, On Tue, May 10, 2011 at 05:30:09PM -0700, Gordon Tetlow wrote: > On Mon, May 9, 2011 at 10:15 PM, Jason Hellenthal wrot= e: > > Not to break existing behavior the way they stand: > > [...] > > /etc/defaults/rc.conf > > /etc/rc.conf.d/CUSTOM.conf > > /etc/rc.conf > > /etc/rc.conf.local > > /etc/rc.conf.d/NAME >=20 > Having 2 files (well any number of *.conf files actually) sourced from > the same directory at different times based solely on name is a bad > idea. There isn't enough documentation that will adequately explain > how that is supposed to work. I would consider it a major POLA > violation. >=20 I agree with that and sort of disagree. As stated before the behavior of=20 /etc/rc.conf.d/NAME leaves alot to be said and is quite a neusance to work= =20 with and would seriously be hard to document how to use in any effecient=20 way. So with that said I believe that the above example would work just=20 fine while the other /etc/rc.conf.d/NAME method just be scratched from=20 documentation and left for deprecation. Thinking more about this I would really like to here from some doc=20 comitters for the handbook and see we can get them to take a look at the=20 current state of rc.conf.d to get a real feel on how that would have to=20 look in an end result and how the new way would look. I think this would=20 give this a shining light on exactly how complex one is compared to the=20 other. Any reccomendations ? who we could contact ? > Also, if your stated goal was to allow ports to install sample or > sensible defaults into /etc/rc.conf.d, it needs to live in > /usr/local/etc instead of /etc. Ports writing data into /etc shouldn't > happen. >=20 For now this is just about /etc/rc.conf.d ports are in mind but that is=20 obviously one side of it. I would never suggest that ports install anyting= =20 into /etc. --=20 Regards, (jhell) Jason Hellenthal --CdrF4e02JqNVZeln Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyd6ZAAoJEJBXh4mJ2FR+S4QIAI6fbXHa799XdeeRXjFjf1Oe UTq+Kw7w/gF1J4gufNuYqC965Ml03vXI9GfHVRvUB6Qq67ZOdh2NifBkvOmv6OW0 T3gP5HxY5Hh0oV1xXckMzkGeOmze2HZe3T1HjBjGD2hRyY3EsATE+RQpAK47mTe0 7p9va0ISGji442AL680KdcD7BojxFv9zAmGChRq3OVwWXVYJmOz5lj9iOgnHK0eu K51RYIOFpSv0ypLlBzkW3sd0fUM4WhTtcxdIPFBIo9IZjaAcCfHhaxRXqQN4mE1w IZRHUnBznJ7WxwF2vXNGwlZ8Fq0TEFvUc3J/7AXH4WxcQP3frpu83Y/397PMXdY= =Xwsk -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-freebsd-rc@FreeBSD.ORG Fri May 13 10:34:22 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 880CC106566B; Fri, 13 May 2011 10:34:22 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 03A5B8FC19; Fri, 13 May 2011 10:34:21 +0000 (UTC) Received: by qwc9 with SMTP id 9so1618034qwc.13 for ; Fri, 13 May 2011 03:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4RrG6JR8DyOl1hB5I1Tk17zLteYgUvUDLkmCk1xRRyc=; b=hAEUZcRBicWDn5S+v+RSZQTgkXI4z3i5NCrIyVrqVGuu0PrF5GTDPZ8vohn9BxBRWN qdrBT9eeWZASBnSzq9cg3fIU1VUx2S0rdWzAGY60HxzyUynr/P5sJclvA3mcYkGSFnlX OKk1YdrPE/IJPUKQYkFy2fIXab/ThRqD3dhTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IhE/A+bzy0kCid8+JOmh5i6rXmitNwOZTCBjQrFFYcDAqXDe3GPJ6ICdWrPvpsvEst 0+P1zIoueGFIGH4mrL8/ek2oSigih4xTg1I2eNwfR9Ngfnq92PM6LO4B5e39T2FhqeBD 3DakFBV6wIuXq+OGt6YIp1WKdOLH6ZmtvyPhU= MIME-Version: 1.0 Received: by 10.229.127.81 with SMTP id f17mr1009062qcs.138.1305281525100; Fri, 13 May 2011 03:12:05 -0700 (PDT) Received: by 10.229.217.69 with HTTP; Fri, 13 May 2011 03:12:05 -0700 (PDT) In-Reply-To: <20110508191336.GC3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> Date: Fri, 13 May 2011 12:12:05 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 10:34:22 -0000 Hi, 2011/5/8 Jason Hellenthal > > List, - Please reply-to freebsd-rc@freebsd.org > > What does it do ?: As stated above, current functionality is undisturbed > while allowing the user to create config's by any name they so desire as > long as it has an extension of ".conf", also introducing the ability to > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > seams not to be included in your patch, unless you change the line (or i'm wrong): if [ -f "$_modular_conf" ]; then by if [ -x "$_modular_conf" ]; then > > > Why ? Simple. How many times have you been bitten by disabling something > in the rc.conf file and left to discover what you just disabled was also > used by another daemon but that daemon is now not starting ? This is a way > to virtualize your configuration allowing you to add multiple _enable= > lines to different configurations for different roles. For instance > rpcbind is used by both samba and nfs*. With this you can add > rpcbind_enable to both a configuration for samba and nfs and when you > disable one service you know that you have not disabled a dependent for > another. > i resolved that by making multiple files source the same conf file. today my biggest problem is bad rc.d script like apache22, postfix, clamd or haproxy who load_rc_config and after overwrite extra_commands variable. this prevent me to add extra commands from a /etc/rc.conf.d/$name file. From owner-freebsd-rc@FreeBSD.ORG Fri May 13 11:27:45 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E70106566B; Fri, 13 May 2011 11:27:44 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC528FC14; Fri, 13 May 2011 11:27:44 +0000 (UTC) Received: by iyj12 with SMTP id 12so2808957iyj.13 for ; Fri, 13 May 2011 04:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=7/LGFur01hlcyl97RqTGdE4WDo0qRTosBXigD5mkL1w=; b=T+xFJUKvCQxQSdxkmjO/YGgGR+yWgwFI684w2IUj9en3smhSFopHLg+kiOdyxoRYcj PF5V9BlnMp8Dsf4deSrajaGKLtXqqhmV0yco1VA7tP6iNBt3M2KQ97k0lkkG+yawnRRu QT249b/GZ6opZ+kj1WwHjMZf/JIaX2rL4QyJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=R7wlpZByJehQ/de+eZ2PbmUEhslBSldC7keU1QESksIW8leo0zQaoANLGUDoo9OdhJ Yk+nS1OBkYu3pl/IXXiGgmNvlfYz76q6ARpGREU/UIsIwWAi3JGCTef9Z40bGzggedXw EMUxUoYtOhCZdL7QeqT0yNblLwzWl0W+A/NP8= Received: by 10.42.157.67 with SMTP id c3mr1528648icx.95.1305286063703; Fri, 13 May 2011 04:27:43 -0700 (PDT) Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net [99.190.81.196]) by mx.google.com with ESMTPS id t1sm931523ibm.38.2011.05.13.04.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 04:27:42 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4DBRd9i004608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 07:27:39 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4DBRcPA004607; Fri, 13 May 2011 07:27:38 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Fri, 13 May 2011 07:27:38 -0400 From: Jason Hellenthal To: =?iso-8859-1?Q?Micka=EBl?= Maillot Message-ID: <20110513112738.GA2720@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-rc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 11:27:45 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Micka=EBl, On Fri, May 13, 2011 at 12:12:05PM +0200, Micka=EBl Maillot wrote: > Hi, >=20 > 2011/5/8 Jason Hellenthal >=20 > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > What does it do ?: As stated above, current functionality is undisturbed > > while allowing the user to create config's by any name they so desire as > > long as it has an extension of ".conf", also introducing the ability to > > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > > >=20 > seams not to be included in your patch, unless you change the line (or i'm > wrong): > if [ -f "$_modular_conf" ]; then > by > if [ -x "$_modular_conf" ]; then >=20 The one you downloaded here used to be this one: http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch?r=3Dbf83c= 231337642f925d6c732ba8c8b070480631e But since alot of slack was coming back on the use of the -x bit it was removed. >=20 > > > > > > Why ? Simple. How many times have you been bitten by disabling something > > in the rc.conf file and left to discover what you just disabled was also > > used by another daemon but that daemon is now not starting ? This is a = way > > to virtualize your configuration allowing you to add multiple _enable=3D > > lines to different configurations for different roles. For instance > > rpcbind is used by both samba and nfs*. With this you can add > > rpcbind_enable to both a configuration for samba and nfs and when you > > disable one service you know that you have not disabled a dependent for > > another. > > >=20 > i resolved that by making multiple files source the same conf file. >=20 > today my biggest problem is bad rc.d script > like apache22, postfix, clamd or haproxy who load_rc_config and after > overwrite extra_commands variable. > this prevent me to add extra commands from a /etc/rc.conf.d/$name file. --=20 Regards, (jhell) Jason Hellenthal --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNzRWpAAoJEJBXh4mJ2FR+dbEH/jCyY0qY5Mh2lke9bxeGrRPy qul0Bjy3RhSuREYNZnW3VgOxpzEatV6S1sz3USYutHIN0V6mOxRHxnBRe9D1Ri2k FCRXh9ZcIlRuAKgQeDit+RscwV9PIH8MFNuox4T1eRunNa/lOKb7jZqJkbe7mK+v J6egWqZL/QwEHt2mC1MrhnGpfWpGZYgRA+xTka5StRVgi16doAg7Bu15ncrBvUI0 UXc4VIuVO3Gl/cO59FRU4DxSp7MQ2wnIA96cRsJmnJC46k4EhyfKQWwBoPqUwUsi 3VKRtobNnrDMPHB1f8Oq/KNKPFokQhkD4qQKbJz56S3X3x9o+mlelOMQQtUQwWA= =Ztl4 -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/--