Puppet remctl module

[Russ Allbery]

Remi Ferrand <remi.ferrand at cc.in2p3.fr> writes:

> Hi everyone,

> At CC-IN2P3, we've released a puppet module for remctl deployment.

> It is available from the puppet forge:
> http://www.puppetforge.com/ccin2p3/remctl.

> Hope this could help any puppet and remctl users in the audience.

> Feel free to comment and submit bug reports.

Hi Remi,

I'm sorry for not having gotten back to you about this module in a timely
fashion.  I'm glad that you went ahead and announced it and didn't block
on me.  My response speed is rather erratic at the moment.

Thank you for developing this!  It looks great.

The only place where I noticed a bit of a mismatch between the remctl
model and the Puppet module is around defining commands.  Due to the way
that Puppet handles unique resources, I don't think there's a way, using
that Puppet module, to define a command with multiple subcommands that
take different options or ACLs.  This is very common, at least for our
remctl command sets.  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

Note that not only do the options differ (logmask in paticular is a common
one to need to set per subcommand; stdin is another, which is underused by
our kadmin-remctl command definitions right now but will be used more
heavily later when I rewrite kadmin-remctl to use Net::Remctl::Backend)
but the ACLs differ, in this case for almost every command.

In the remctl world, a remctl command is identified uniquely by the
combination of command and subcommand.  This is sort of annoying to
represent in the Puppet world, where it's more natural to make those two
separate parameters, but that leaves you without a clear meaning for name
(particularly if you want to use name as the name of the file on disk).

Properly speaking, the model that we use here is that the file is named
after the command and contains an array of command definitions, each of
which have a command and subcommand, the path to the executable, some
number of options, and then some number of ACLs.  I'm not sure if it would
be too heavy in syntax to use that model for remctl::server::command.

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.)

* 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.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>