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

Search Discussions

  • Jcbollinger at Nov 13, 2012 at 2:16 pm

    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.
  • Patxi Gortázar at Nov 15, 2012 at 3:26 pm
    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.
  • Jcbollinger at Nov 15, 2012 at 3:57 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 13, '12 at 9:36a
activeNov 15, '12 at 3:57p
posts4
users2
websitepuppetlabs.com

2 users in discussion

Patxi Gortázar: 2 posts Jcbollinger: 2 posts

People

Translate

site design / logo © 2021 Grokbase