[15979] in Kerberos_V5_Development
Re: Dynamic plugin modules and OS packages (Russ Allbery)
daemon@ATHENA.MIT.EDU (Lee Hinman)
Wed Jul 14 14:00:28 2010
From: Lee Hinman <lhinman@wareonearth.com>
To: krbdev@mit.edu
Date: Wed, 14 Jul 2010 12:59:21 -0500
In-Reply-To: <mailman.439.1279123543.21538.krbdev@mit.edu>
(krbdev-request@mit.edu's message of "Wed, 14 Jul 2010 12:05:43
-0400")
Message-ID: <m2eif6c5c6.fsf@wareonearth.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
> Message: 2
> Date: Tue, 13 Jul 2010 13:46:55 -0700
> From: Russ Allbery <rra@stanford.edu>
> Subject: Re: Dynamic plugin modules and OS packages
> To: krbdev@mit.edu
> Message-ID: <87eif79kjk.fsf@windlord.stanford.edu>
> Content-Type: text/plain; charset=us-ascii
>
> 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.
>
> This enables using the Debian Apache packaging approach for enabling or
> disabling plugins, where the plugin configuration files are installed in a
> separate location and selectively symlinked into the include directory for
> krb5.conf using a tool that adds or removes the symlinks to enable or
> disable the plugins.
I think this approach has another advantage as well. It would map onto
the Windows registry idea pretty easily. That would make it easier for
the Windows port to find any plugins.
--
Lee Hinman
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
