[36028] in Kerberos
Re: Puppet remctl module
daemon@ATHENA.MIT.EDU (Russ Allbery)
Fri Apr 11 20:34:22 2014
From: Russ Allbery <eagle@eyrie.org>
To: Remi Ferrand <remi.ferrand@cc.in2p3.fr>
In-Reply-To: <534807D6.5090702@cc.in2p3.fr> (Remi Ferrand's message of "Fri,
11 Apr 2014 17:18:46 +0200")
Date: Fri, 11 Apr 2014 17:34:03 -0700
Message-ID: <87wqev5qtg.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Remi Ferrand <remi.ferrand@cc.in2p3.fr> writes:
> 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).
That certainly does make it easier. On some of our hosts, it would create
a hundred tiny little files for every command, which would make it
annoying to find things when reviewing the remctl configuration by hand.
But I can see both sides of that tradeoff.
> 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',
> ...
> }
> ]
> }
Yeah, that's the sort of syntax that I'd expect you to have to use.
And...
> 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.
...yes, that's the problem, without writing a bunch of Ruby code to add
new functions. So it makes sense to me for you to do it the way that you
did it.
--
Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
