On Aug 14, 2013, at 2:13 PM, jcbollinger wrote:
> On Tuesday, August 13, 2013 9:59:22 PM UTC-5, Ygor wrote:
> I have a problem with variables in defined types.
>
> I have dug a hole consisting of three levels of nested defines as in
>
> ------- snip ------------------------------------
>
> The problem is in how I manipulate the array of option parameters as I go
> down the levels ( user_options , key_options , ssh_options ) and the contents
> of the array created with the “concat” function persists and accumulates
> (snowballs!!) at the bottom level as the "users::restricted_ssh_user" defined
> type in instantiated many times. The parameters were all called “options” at
> one point, and I made them different, hoping that would work.
>
> Is there a way to isolate the variables declared in a defined type instance ?
> Or do I need to trash this design and start over ?
>
>
> I'm not sure I understand the problem(s).
>
> With respect to the $local_options arrays generated via concat(), these are
> each assigned as resource parameters, so Puppet must retain them all until it
> finishes compiling the catalog. The point appears to be that the options may
> vary from user to user, so if you have many users then many of these option
> strings must accumulate during catalog compilation. How do you imagine it
> could be different?
>
> However, it does look like in some cases you are creating temporary arrays
> that you do not need. It could be that Puppet retains these for the duration
> of catalog compilation, even though it shouldn't need to do. If that's the
> case, then you might be able to lighten the load a bit by dropping the
> temporaries. For instance, you could avoid the $canned_options,
> $command_string, and $option_string variables in the 'roleA' case by writing
> the option array like this:
>
> $local_options = [
> 'no-port-forwarding',
> 'no-agent-forwarding',
> 'no-X11-forwarding',
> 'no-pty',
> "command=\"/usr/local/${role_name}/local/bin/commandA --user=${username}\""
> ]
>
> I don't know whether that will really gain you anything, though, especially
> inasmuch as you cannot do the same for the default case.
>
> You might also achieve a bit of savings by merging users::restricted_ssh_user
> back into users::role_user_keys. As you present those, I don't see what you
> gain by separating them.
>
> Ultimately, though, I don't think your option arrays grossly outweigh
> everything else declared per-user. If you are experiencing a capacity
> problem, then you may need to take an altogether different approach, such as
> managing ~/.ssh/authorized_keys as a whole, via a template, instead of
> declaring thousands of Ssh_authorized_key resources.
>
>
> John
Thanks for staring your opinion and thoughts, John.
I think part of the problem is feature creep.
It started with just creating user accounts
Then I added ssh keys
Then I added role accounts
Then I added ssh keys for role accounts
The whole mess needs refactoring.
I will try your idea of eliminating the temporaries and see how far I get.
One thing I found about the ssh_authorized_key type is that is does not work
with :
resource { ‘ssh_authorized_key’: purge => true, }
so I have to explicitly un-manage the keys
When you say "managing ~/.ssh/authorized_keys as a whole, via a template”, do
you mean as a separate class rather than as a facet of my “users” class ?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
