From f6e245f2d1a614a87361a43e547e618af43698f7 Mon Sep 17 00:00:00 2001 From: Greg Hudson Date: Mon, 25 Jun 2012 15:26:24 -0400 Subject: [PATCH] Correctly document module setting in host_config The module variable must take the form modname:path, which was not reflected in the example or described in the text. --- doc/rst_source/krb_admins/host_config.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/doc/rst_source/krb_admins/host_config.rst b/doc/rst_source/krb_admins/host_config.rst index 26335490b0..706242c663 100644 --- a/doc/rst_source/krb_admins/host_config.rst +++ b/doc/rst_source/krb_admins/host_config.rst @@ -21,14 +21,15 @@ off registered or built-in modules. A plugin module takes the form of a Unix shared object (``modname.so``) or Windows DLL (``modname.dll``). If you have installed a third-party plugin module and want to register it, you do -so using the **module** directive in the appropriate subsection of the -[plugins] section. For example, to register a client -preauthentication plugin for one-time password authentication -installed at ``/path/to/otp.so``, you could write:: +so using the **module** relation in the appropriate subsection of the +[plugins] section. The value for **module** must give the module name +and the path to the module, separated by a colon. For example, to +register a client preauthentication module named ``otp`` installed at +``/path/to/otp.so``, you could write:: [plugins] clpreauth = { - module = /path/to/otp.so + module = otp:/path/to/otp.so } Many of the pluggable behaviors in MIT krb5 contain built-in modules -- 2.47.2