Re: Overwriting a file provisioned by another module

[jcbollinger]

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 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

[Patxi Gortázar]

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.

[jcbollinger]

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