Remi Ferrand <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
