Thanks for feedback,
> > 3- FROM WIKI: Operating system differences should be specified in
> > variables in a case at the start of the module, as follows:
> > class ssh::server {
> > case $operatingsystem {
> > "freebsd","openbsd": {
> > $sshservice = "sshd"
> > }
> > debian: {
> > $sshservice = "ssh"
> > }
> > }
> > # use a constant title to facilitate stable relations
> > service { "ssh::server":
> > name => $sshservice,
> > ensure => running,
> > enable => true,
> > }
> > }
>
> +1, that's what I use usually
>
> > I personally prefer something like (not avoid unnecessary internal
> > variables in modules):
> > class ssh::server {
> > service { "ssh::server":
> > name => $operatingsystem ? {
> > debian => "ssh",
> > default => "sshd",
> > }
> > ensure => running,
> > enable => true,
> > }
> > }
>
> > but that affects the class internals and is not relevant for the name
> > itself.
>
> I still prefer the former as OS differences are encapsulated in one place.
> This one may be better for really small differences.
Well, you generally have different values for package/service names
and configuration files paths.
When differences are wide enough (IE: apache) point 4 is definitively
the best, but in most cases I find the above variations more clear if
defined where they are used.
But this is really a matter of taste, and doesn't affect the general
logic (no need for separated modules when differences are few).
> > 5- Specific variations on the normal behaviour of an application
> > should be specified as subclasses (IE: samba::pdc or samba::ldap)
>
> How does that relate to ::server and ::client above? E.g. if samba::pdc
> implies samba::server wouldn't it be better if it was samba::server::pdc?
Ya, you're are right. If there is a samba::server there should be a
samba::server::pdc.
> > 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 ;-)
> > 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 :-! )
All the best
al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
