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
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
