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=