Puppet remctl module

[Remi Ferrand]

On 11/04/2014 11:10, Russ Allbery wrote:
> For example, for kadmin-remctl, our local remctl
> configuration is:
>
> kadmin change_passwd /usr/sbin/kadmin-backend logmask=3,4 \
>     ANYUSER
> kadmin check_passwd  /usr/sbin/kadmin-backend logmask=3 \
>     /etc/remctl/acl/kadmin-examine /etc/remctl/acl/its-idg
> kadmin create        /usr/sbin/kadmin-backend logmask=3 \
>     /etc/remctl/acl/kadmin-create
> kadmin delete        /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-delete
> kadmin disable       /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-enable
> kadmin enable        /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-enable
> kadmin examine       /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-examine /etc/remctl/acl/its-idg \
>     /etc/remctl/acl/security /etc/remctl/acl/data-admin \
>     /etc/remctl/acl/data-view
> kadmin help          /usr/sbin/kadmin-backend \
>     ANYUSER
> kadmin instance      /usr/sbin/kadmin-backend logmask=5 \
>     /etc/remctl/acl/kadmin-instance
> kadmin reset_passwd  /usr/sbin/kadmin-backend logmask=3 \
>     /etc/remctl/acl/kadmin-reset
> kadmin check_expire  /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-check-expire
> kadmin expiration    /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-expiration
> kadmin pwexpiration  /usr/sbin/kadmin-backend \
>     /etc/remctl/acl/kadmin-expiration

Hi Russ and thanks for your remarks !
I've just created and released version 1.1.0 (available at
https://forge.puppetlabs.com/ccin2p3/remctl).

> A few other, more minor points I noticed:
>
> * You define the remctl port in /etc/services to be whatever the port
>   parameter passed to the remctl::server class is.  I don't think this is
>   formally correct.  The only officially-registered port for remctl is
>   4373, and that's really the only thing that should be added to
>   /etc/services.  It's quite possible someone would want to run remctld on
>   a non-standard port but still have that port properly associated with
>   some other service.
>
>   Instead, I would add the remctl port to /etc/services if and only if it
>   is set to 4373, and otherwise use type = UNLISTED in the xinetd
>   configuration so that it will work without an /etc/services entry.
>   That's what our internal Puppet model does.  (It's otherwise not as
>   useful because it assumes a lot of Stanford-specific things.)

You're absolutely right, thanks for raising this, v1.1.0 should have
fixed this.

>
> * If the remctl port definition is missing from /etc/services, you
>   currently add it for both tcp and udp.  The dual registration is an
>   artifact of the IANA port registration process.  I can pretty much
>   guarantee that there will never be a remctl UDP service, so when adding
>   the service to /etc/services on systems that don't have it listed, I
>   would only bother adding TCP.


> * Just for completion's sake, it would be nice to have a remctl::client
>   class that installs the package needed for the client.  That would be
>   fairly trivial: just remctl on Red Hat and remctl-client on Debian.
>



Unfortunately I had to break our interface for class
remctl::server::command by introducing a new mandatory parameter
"command" that now allow to write any of the configuration you pasted above.

For fun', I've tried to write some of them:

# kadmin change_passwd /usr/sbin/kadmin-backend logmask=3,4 \
#     ANYUSER

# kadmin examine       /usr/sbin/kadmin-backend \
#     /etc/remctl/acl/kadmin-examine /etc/remctl/acl/its-idg \
#     /etc/remctl/acl/security /etc/remctl/acl/data-admin \
#     /etc/remctl/acl/data-view

could be obtained from this puppet manifest:

$_remctl_acl_its_idg = "file:${remctl::server::acldir}/its-idg"
$_remctl_acl_security = "file:${remctl::server::acldir}/security"

remctl::server::command { 'kadmin_change_passwd':
    command             => 'kadmin',
    subcommand          => 'change_passwd',
    executable          => '/usr/sbin/kadmin-backend',
    options             => {
        'logmask'   => '3,4'
    },
    acls                => ['ANYUSER']
}

remctl::server::command { 'kadmin_examine':
    command             => 'kadmin',
    subcommand          => 'examine',
    executable          => '/usr/sbin/kadmin-backend',
    acls                => [
        "file:${remctl::server::acldir}/kadmin-examine",
        "${_remctl_acl_its_idg}",
        "${_remctl_acl_security}",
        "file:${remctl::server::acldir}/data-admin",
        "file:${remctl::server::acldir}/data-view"
    ]
}


The way the module is coded (and also the way puppet works) makes it
more easy for me to explode every subcommand in a dedicated file.
In the example above, file "/etc/remctl/conf.d/kadmin_examine" will be
created and its content will describe "examine" subcommand of command
"kadmin".

I agree that this will result in multiple small files but:
* (for what I know) puppet handles more easily small dedicated files
(like in /etc/yum.repos.d) than one monolithic file.
* defining each subcommand as a separate "remctl::server::command"
"puppet object" allow to factorize some declarations ("subcommand_1" and
"subcommand_2" could be declared; and "subcommand_1" could be defined on
host A but not on host B for instance).

The only way I know to create a single file per command with many
subcommands would be to do something like this:

remctl::server::command { 'kadmin':
    subcommand => [
        {
            'name'            => 'change_passwd',
            'executable'    => '/usr/sbin/kadmin-backend',
            'options'          => { 'logmask' => '3,4' }
            'acls'               => ['ANYUSER']
        },

        {
            'name'            => 'examine',
            ...
        }
    ]
}

I don't like this "pass a Hash or Dict" approach because when using
puppet "defined types",  all the checks and intelligence has to be
written in templates which is something that I try to avoid.


I hope that this new version will be closer to the "remctl subcommand
model".

Cheers

Rémi