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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
