[15975] in Kerberos_V5_Development
Re: Dynamic plugin modules and OS packages
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Tue Jul 13 17:03:30 2010
Date: Tue, 13 Jul 2010 16:07:51 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20100713210750.GE20713@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87eif79kjk.fsf@windlord.stanford.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, Jul 13, 2010 at 01:46:55PM -0700, Russ Allbery wrote:
> ghudson@MIT.EDU writes:
>
> > * We add "include" support to the profile library, and the OS adds
> > "include /etc/krb5.conf.d/*" to its standard krb5.conf. Each
> > plugin package supplies a profile fragment giving the location of
> > the dynamic object and an enable/disable boolean (which may
> > default to on or off depending on the packaging model and/or the
> > plugin).
>
> I prefer this approach. I've been wanting this for a long time for other
> reasons.
+1
Discovering plugins by shared object presence in a directory is
undesirable: it means you cannot disable a plugin without uninstalling
it, and you end up hoping that the plugins are packaged separately from
other functionality so that you can install/uninstall just the plugin.
Packaging is not a good enough hammer for this problem.
But discovering configuration by reading config file snippets from a
files in a ".d" directory is highly desirable as it means that there's
no need to script the editing of a single config file (which can be a
pain), and that there's no need to write a program to administer plugin
configuration (which to can be a pain).
Note that one might nonetheless use packaging to distribute these config
files.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
