Puppet users - Nov 2012 - Overwriting a file provisioned by another module

I''m a newbie and I might be missing something... but let me try to
explain
what I want to accomplish and how I would like to do it. 

I''m installing ssh by using the saz::ssh
<https://github.com/saz/puppet-ssh>module. This module provision the
sshd_config file with the ssh
configuration. 

I need to tune the sshd_config file, so I have a module, say patxi::scstack 
that includes ssh and tries to overwrite the sshd_config by defining this 
file again:

class scstack_ssh {
  include ssh

  file { "/etc/ssh/sshd_config":
    content => template("scstack/sshd_config"),
  }
}

This approach fails as expected:

Duplicate declaration: File[/etc/ssh/sshd_config] is already declared in 
file /tmp/vagrant-puppet/modules-0/ssh/manifests/server/config.pp at line 
11; cannot redeclare at 
/tmp/vagrant-puppet/modules-0/scstack/manifests/scstack_ssh.pp:67

The alternative could be to fork the module saz::ssh and change the 
sshd_config file it provides to fit my needs. However, this seems odd to 
me. I want to use the ssh puppet module as is, without any modification, so 
as to be able to update this module if the original author makes changes to 
it. In my humble opinion having to modify modules to fit my needs limits 
reusing of puppet modules. 

My question is: how can I achieve what I want? I see different options but 
I would like to know how to do it "the puppet way":

   1. Modify the original ssh module to include my sshd_config file
   2. Modify the original ssh module to include a location parameter to use 
   as source ("puppet:///$location") for sshd (I don''t know
it parameters can
   be used in place for puppet:// urls)
   3. Provision the file in my module using another name and do an exec to 
   rename it, overwriting the one generated by the ssh module
   4. ...Any other option?

Thanks in advance,
Patxi.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/wriHqScyRNMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tuesday, November 13, 2012 3:18:36 AM UTC-6, Patxi Gortázar
wrote:
>
> I''m a newbie and I might be missing something... but let me try to
explain
> what I want to accomplish and how I would like to do it. 
>
> I''m installing ssh by using the
saz::ssh<https://github.com/saz/puppet-ssh>module. This module provision
the sshd_config file with the ssh
> configuration. 
>
> I need to tune the sshd_config file, so I have a module, say 
> patxi::scstack that includes ssh and tries to overwrite the sshd_config by 
> defining this file again:
>
> class scstack_ssh {
>   include ssh
>
>   file { "/etc/ssh/sshd_config":
>     content => template("scstack/sshd_config"),
>   }
> }
>
> This approach fails as expected:
>
> Duplicate declaration: File[/etc/ssh/sshd_config] is already declared in 
> file /tmp/vagrant-puppet/modules-0/ssh/manifests/server/config.pp at line 
> 11; cannot redeclare at 
> /tmp/vagrant-puppet/modules-0/scstack/manifests/scstack_ssh.pp:67
>
> The alternative could be to fork the module saz::ssh and change the 
> sshd_config file it provides to fit my needs. However, this seems odd to 
> me. I want to use the ssh puppet module as is, without any modification, so
> as to be able to update this module if the original author makes changes to
> it. In my humble opinion having to modify modules to fit my needs limits 
> reusing of puppet modules. 
>
> My question is: how can I achieve what I want? I see different options but 
> I would like to know how to do it "the puppet way":
>
>    1. Modify the original ssh module to include my sshd_config file
>    2. Modify the original ssh module to include a location parameter to 
>    use as source ("puppet:///$location") for sshd (I
don''t know it parameters
>    can be used in place for puppet:// urls)
>    3. Provision the file in my module using another name and do an exec 
>    to rename it, overwriting the one generated by the ssh module
>    4. ...Any other option?
>
>
Some modules accommodate local resource customization better than others, 
but are you certain that the module you are using does not already allow 
you to configure sshd as you would like?  If I were faced with that 
situation, *my* first inclination would be to look for a better module.  Is 
the module you''re using really so inflexible, or are you trying to do 
something unusual?  What does the module''s documentation have to say
about
it?

If you stick with the module you are using now, but it truly doesn''t 
support your use case, then you have a few reasonably good options.  Of 
those you suggested, I rate (1) ok, and (2) borderline.  Option (3) is 100% 
awful -- don''t go there.  You could also consider

  4. Create your own module containing a subclass of the appropriate class 
of the ssh module; in the subclass override the properties of 
File[''/etc/ssh/sshd_config''] as you like.

That has the advantage of leaving the original module unchanged, but it is 
at least a bit messy.  It is a lot messy if the class declaring the target 
File is not part of the module''s external interface.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/S3lCQ7CS-IYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks, John.

I think I would go through the 4th option (subclassing) as you suggested. 
However, I don''t know which are the interface classes of a module.

Patxi.

El martes, 13 de noviembre de 2012 15:16:10 UTC+1, jcbollinger
escribió:
>
>
>
> On Tuesday, November 13, 2012 3:18:36 AM UTC-6, Patxi Gortázar wrote:
>>
>> I''m a newbie and I might be missing something... but let me
try to
>> explain what I want to accomplish and how I would like to do it. 
>>
>> I''m installing ssh by using the
saz::ssh<https://github.com/saz/puppet-ssh>module. This module provision
the sshd_config file with the ssh
>> configuration. 
>>
>> I need to tune the sshd_config file, so I have a module, say 
>> patxi::scstack that includes ssh and tries to overwrite the sshd_config
by
>> defining this file again:
>>
>> class scstack_ssh {
>>   include ssh
>>
>>   file { "/etc/ssh/sshd_config":
>>     content => template("scstack/sshd_config"),
>>   }
>> }
>>
>> This approach fails as expected:
>>
>> Duplicate declaration: File[/etc/ssh/sshd_config] is already declared
in
>> file /tmp/vagrant-puppet/modules-0/ssh/manifests/server/config.pp at
line
>> 11; cannot redeclare at 
>> /tmp/vagrant-puppet/modules-0/scstack/manifests/scstack_ssh.pp:67
>>
>> The alternative could be to fork the module saz::ssh and change the 
>> sshd_config file it provides to fit my needs. However, this seems odd
to
>> me. I want to use the ssh puppet module as is, without any
modification, so
>> as to be able to update this module if the original author makes
changes to
>> it. In my humble opinion having to modify modules to fit my needs
limits
>> reusing of puppet modules. 
>>
>> My question is: how can I achieve what I want? I see different options 
>> but I would like to know how to do it "the puppet way":
>>
>>    1. Modify the original ssh module to include my sshd_config file
>>    2. Modify the original ssh module to include a location parameter to
>>    use as source ("puppet:///$location") for sshd (I
don''t know it parameters
>>    can be used in place for puppet:// urls)
>>    3. Provision the file in my module using another name and do an exec
>>    to rename it, overwriting the one generated by the ssh module
>>    4. ...Any other option?
>>
>>
> Some modules accommodate local resource customization better than others, 
> but are you certain that the module you are using does not already allow 
> you to configure sshd as you would like?  If I were faced with that 
> situation, *my* first inclination would be to look for a better module.  
> Is the module you''re using really so inflexible, or are you trying
to do
> something unusual?  What does the module''s documentation have to
say about
> it?
>
> If you stick with the module you are using now, but it truly
doesn''t
> support your use case, then you have a few reasonably good options.  Of 
> those you suggested, I rate (1) ok, and (2) borderline.  Option (3) is 100%
> awful -- don''t go there.  You could also consider
>
>   4. Create your own module containing a subclass of the appropriate class 
> of the ssh module; in the subclass override the properties of 
> File[''/etc/ssh/sshd_config''] as you like.
>
> That has the advantage of leaving the original module unchanged, but it is 
> at least a bit messy.  It is a lot messy if the class declaring the target 
> File is not part of the module''s external interface.
>
>
> John
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/B3FxSXfTM-wJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, November 15, 2012 9:20:25 AM UTC-6, Patxi Gortázar
wrote:
>
> Thanks, John.
>
> I think I would go through the 4th option (subclassing) as you suggested. 
> However, I don''t know which are the interface classes of a module.
>
>
The interface classes of a module are whatever its documentation says they 
are.  More often than not, the docs don’t explicitly designate interface 
classes, but they should identify the classes you are expected to use -- 
those are the interface classes.  Ideally for your case, the docs would 
specifically say that a particular one of the interface classes manages the 
file in question.

*Important*: do not attempt to subclass a parameterized class.  If the 
class that would need to be subclassed is parametrized, then option 4 is a 
non-starter.


John


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/1eNoMQi9Bd8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.