On Sunday, June 22, 2014 12:43:20 AM UTC-5, treydock wrote:
>
> I'm attempting to use puppetlabs-apache with all my classes defined via
> Foreman (1.5.1) with Puppet 3.4.3. Servers are all CentOS 6.5.
>
> With puppetlabs-apache-1.0.1 when I applied both the apache class and
> apache::mod::ssl class in Foreman I received this error on the server:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> undefined method `>=' for :undef:Symbol at
> /etc/puppet/environments/production/modules/apache/manifests/mod/ssl.pp:36
> on node web01.brazos.tamu.edu
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
>
That error is simply complaining that one of the items being compared
(presumably the $apache_version variable) was not numeric. Note in
particular that '2.2.0' is not numeric, whereas '2.2' is.
> I found the commit that changed how "apache_version" was handled and
> deployed that and then I get:
>
>
Version numbers simply should not be compared via numeric comparison
operators, so fixing the module to avoid that is certainly the right thing
to do. I have no clue what change you actually made, however.
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Failed to parse template apache/mod/ssl.conf.erb:
> Filepath: /usr/lib/ruby/site_ruby/1.8/puppet/util/package.rb
> Line: 4
> Detail: private method `scan' called for nil:NilClass
> at
> /etc/puppet/environments/production/modules/apache/manifests/mod/ssl.pp:51
> on node web01.brazos.tamu.edu
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> This time the "@apache_version" variable in the template is being passed
> the to versoncmp function, producing that error.
>
>
That seems to be saying that the $apache_version variable does not exist /
has no value in the context where the template is being evaluated. Did you
run the module's tests after modifying it? (And before?) I'm inclined to
think you broke it (worse than it was already).
> I don't know if this is a symptom of using an ENC
>
Not in a general sense, no, but possibly this particular ENC or the
particular way you are using it.
> , or a bug in the apache module
>
There was a bug, now there's a different one.
> , but the class parameters in apache::mod::ssl reference the apache class
> and despite the class being defined, the variables are all 'undef'.
>
>
That sounds like an evaluation-order issue. Class 'apache::mod::ssl' is
depending on class 'apache' to be evaluated first. If you are relying
exclusively on Hiera for data binding (i.e. not Foreman) then it is safe to
address that issue by putting "include 'apache'" at the top of the body of
'apache::mod::ssl'. PL cannot do that in the stock version, however,
because it's not safe when class parameters are bound to 'apache' via ENC
or resource-like declarations.
> I also ran into this same issue when I applied the apache::mod::wsgi class:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Invalid relationship: File[wsgi.conf] { before => File[undef] }, because
> File[undef] doesn't seem to be in the catalog
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> In that case the fix was easier, just add "include ::apache" to the top of
> the class.
>
It sounds like the problem there as another evaluation-order issue, just
like in apache::mod::ssl. If that fix worked for mod wsdl, then it should
work also for mod ssl. Did you try that?
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/88895d38-8735-414b-9b53-cec03b8e8166%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
