Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new parameter to set httpd module identifier string #1

Open
knowshan opened this issue Sep 28, 2012 · 8 comments
Open

Add new parameter to set httpd module identifier string #1

knowshan opened this issue Sep 28, 2012 · 8 comments

Comments

@knowshan
Copy link
Owner

The apache module identifier string is used by LoadModule directive while loading the module. Many modules follow convention of setting it as "$modulename_module", however, there are few exceptions. Hence, it should be a configurable parameter with default as "$modulename_module".

knowshan added a commit that referenced this issue Sep 28, 2012
This changeset will allow users to set custom module identifier string similar
to module package name and module library name. For example, module identifier
string for shibboleth can be set as:

    $mod_identifiers        = {
      'shibboleth'  => 'mod_shib',
    }

See github #1 for details.
knowshan added a commit that referenced this issue Oct 2, 2012
…d resource parameter.

See github #1 for details.
@lboynton
Copy link

I get this with your changes: Error 400 on SERVER: Invalid parameter identifier at /etc/puppet/modules/apache/manifests/mod.pp:40

On CentOS 6.3.

@knowshan
Copy link
Owner Author

@lboynton Sorry for the late reply.

I couldn't replicate this issue on my CentOS 6.3 system with Puppet 2.7.19. I am using revision eb1d004 with following entries in default node manifest.

class {'apache':  }
class {'apache::mod::ssl': }
apache::mod { 'xsendfile':
  package => 'mod_xsendfile',
 }
apache::mod { 'shibboleth': }

The 'identifier' parameter is defined in lib/puppet/type/a2mod.rb, so I am not sure why it's complaining. Can you provide Puppet version and apache module's git revision number?

@andyshinn
Copy link

I'm having the same issue on puppetlabs/puppetlabs-apache@eb1d004. I am using CentOS 6.3 and Puppet 3.0.1-1 RPMs from Puppetlabs yum repo. I'm trying to do some debugging to figure out what might be happening.

@knowshan
Copy link
Owner Author

knowshan commented Nov 8, 2012

I haven't got any problems with Puppet 2.7. I am on vacation with limited connectivity, so I can debug it further with Puppet 3.0 after couple of weeks. Sorry for the inconvenience.

@lboynton
Copy link

The issue went away for me, I don't know if something was cached perhaps.

@andyshinn
Copy link

@lboynton, You haven't changed any other modules or Puppet version since the problem? Can you let me know which commit you are using as your module and Puppet version?

@knowshan
Copy link
Owner Author

@andyshinn I tried it on a fresh CentOS 6.3 install with Puppet 3.0.1, Ruby 1.8.7 and following module revisions:

c26e6af where this commit was introduced: No errors like 'Error 400 on SERVER: Invalid parameter identifier'
eb1d004 which you had mentioned earlier: No errors like 'Error 400 on SERVER: Invalid parameter identifier'
4ffb572 latest revision as of now: it returned following error related to validate_bool, but not invalid parameter identifier

....
Dec 11 02:05:29 localhost puppet-master[3416]: Unknown function validate_bool at /etc/puppet/modules/apache/manifests/init.pp:29 on node localhost.localdomain
Dec 11 02:05:29 localhost puppet-agent[5535]: Could not retrieve catalog from remote server: Error 400 on SERVER: Unknown function validate_bool at /etc/puppet/modules/apache/manifests/init.pp:29 on node localhost.localdomain
....

I will try to look into this again, but I am not seeing errors right now.

@andyshinn
Copy link

I finally tracked down my issue to this upstream bug http://projects.puppetlabs.com/issues/12173 - just in case someone else was having a similar issue which reared its head from this module. It isn't actually any fault of this Apache module! Not sure if @lboynton was running in to the same thing... This issue can probably be closed since the changes do actually work.

knowshan pushed a commit that referenced this issue Jul 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants