On Thursday 17 December 2009 18:58:50 Al @ Lab42 wrote:
> > > 7- PROPOSAL for general class configuration define (based on augeas or
> > > other inline modificators)
> > > define ssh::config ($value) {
> > >
> > > # Augeas version.
> > > augeas {
> > > "sshd_config_$name":
> > > context => $operatingsystem ? {
> > > default => "/files/etc/ssh/sshd_config",
> > > },
> > > changes => "set $name $value",
> > > onlyif => "get $name != $value",
> > > # onlyif => "match $name/*[.='$value'] size == 0",
> > > }
> > >
> > > # Davids' replaceline version (to fix)
> > > # replaceline {
> > > # "sshd_config_$name":
> > > # file => "/etc/ssh/sshd_config",
> > > # pattern => "$name",
> > > # replacement => "^$name $value",
> > > # }
> > > }
> > >
> > > This define can be used in a class like
> > > class ssh::eal4 {
> > >
> > > # Cripto settings
> > > ssh::config { Protocol:
> > > value => "2",
> > > }
> > >
> > > ssh::config { Ciphers:
> > > value => "3des-cbc",
> > > }
> > >
> > > # X11 forwarding (You MAY allow)
> > > ssh::config { X11Forwarding:
> > > value => "no",
> > > }
> > > [....]
> > > }
> >
> > This makes sense, one problem with that however is that this creates a
> > resource for each option. So AFAIK for augeas that means the code
> > (opening the file, trying and appying changes) will be executed as many
> > times as you have options.
> >
> > Perhaps when hashes are available using them to map (key, value) pairs to
> > augeas set commands would make sense.
>
> That's a point, but it actually doesn't affect the naming convention,
> but how singular lines modifications are implemented.
> At the moment I prefer to use augeas on a puppet generated file of
> "augeas commands", that is served as a file resource and subscribes an
> exec that runs augeas using that file as a "source" (this has the
> advantage that you can use augeas on a file in an arbitrary path,
> which is currently still not possibile, even if a patch on the augeas
> type for this is already done and ready the the next release).
> In any case, HOW you manage to get the line configured is not what I
> wanted to discuss (even if this is always a very interesting and
> challenging topic), I just seek for naming standards ;-)
Ah, yes, I got carried away there ;P Naming is definitely OK there, apart
from maybe using openssh instead of ssh (in this particular example) as per
your suggestion.
> > > 8- PROPOSAL (don't think it will be widely liked): Variables names
> > > needed for module configuration (the ones used in templates, for
> > > example) should have a my_ prefix, in order to easily distinguish them
> > > from fact variables.
> >
> > Yeah, not really ;) I do however use ${APPNAME}_ or ${CLASSNAME}_ prefix
> > for variables which a class treats as parameters.
>
> I retire my proposal.
> What you've written, and DavidS has confirmed, is probaly more
> suitable (and it's actually what I used to do, some time ago :-! )
Cool.
I mostly use it to prevent clashes with variables for other modules/classes
but I think it would most likely also handle facter variables.
**********************************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee and access to the email by anyone else
is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed in the governing client
engagement leter or contract.
If you have received this email in error please notify
supp...@henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
