Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases

[Felix Frank]

On 05/20/2014 07:16 PM, Brian Mathis wrote:
> This is a bug in validate_re(), even though there is a workaround.

Arguably so.

One could also argue, on the other hand, that regular expressions are
matched by *strings* and nothing else. Sure, we've been spoiled by bash
and perl which don't give damn and implicitly convert to string every
chance they get. But that isn't a universal truth. Point in fact

irb(main):001:0> puts "it works!" if 5 =~ /[0-9]+/
=> nil

I agree that it *is* inconvenient to check for two cases "is numeric" or
"contains a number" when logically the former implies the latter. I also
think that implicit string conversion would be a beneficial feature for
validate_re. But it is not necessarily a bug.

Cheers,
Felix

-- 
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/537C63ED.2060109%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[Boyan Tabakov]

On 20.5.2014, 17:05, jcbollinger wrote:
> 
> 
> On Tuesday, May 20, 2014 7:36:31 AM UTC-5, Henrik Lindberg wrote:
> 
> This suggests a design that is somewhat inside-out, the idea is that
> what is *in* the environment defines what you want, not that you inside
> the environment make decisions based on the name of the environment.
> 
> 
> 
> Agreed, and therein may be the workaround that I couldn't come up with.
> 
> Nevertheless, the observed value of $::environment differs from what the
> docs say it should be in the OP's case.  The only plausible reason for
> Puppet to provide the $::environment variable at all is so that its
> value can influence catalog building, whether directly in manifests or
> by interpolation into hiera hierarchy definitions, or whatever.  It's
> not reasonable to say the variable shouldn't be used according to its
> docs for its apparent intended purpose.
> 
> 

Exactly. As suggested, I'll open a bug report and see what opinions will
there be.



signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Module for lsyncd - multiple syncs to be configured, but only one config file

[Ugo Bellavance]

>
> I have finally been able to get what I wanted.  I open a issue (
> https://github.com/axkibe/lsyncd/issues/275) on the github project 
> website and the main developper of lsyncd gave me a few lines of code to 
> put in my main config file to have any file in a given directory to be 
> imported in the main config file.  Then I created a module, based on a 
> simple apache vhost module that was given as a sample in the "Pro Puppet" 
> book.  It works for now, I have to test it more and implement it.  If 
> someone would like to have the module I can provide the code, but it may 
> not be good-looking or fully compliant with the highest standards...
>
> Thanks for all your help.
>

By the way, I'd like to say that this community is fantastic.  The support 
has been provided by many different persons around the clock, no matter the 
version I use or my knowledge level about puppet.  I don't think that there 
is even one of our vendors (that we pay $) that matches that.  Even though 
I did help a lot in the past, I don't have much time right now, but I'm 
glad to see that this kind of support exists in the open-source software.

-- 
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/7bd9e8d1-52dc-432c-8ad1-d8b0d9139c51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] failed to submit 'replace facts' command for puppetmaster.domain.com to puppetDB

[Kamjar Gerami]

Hello,

I have a separate
1. master running apache+passenger,
2. puppetDB on a separate server running postgresql
3. dashboard on a separate server.

Total of 3 servers - Master, puppetdb. dashboard.

This is the error message I get when I run puppet agent from any of the 
servers.

## I have changed the hostnames in the output below ##

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Failed to submit 'replace facts' command for puppetmaster.domain.com to 
PuppetDB at puppetDB.domain.com:8081: [400 Bad Request] Missing required 
query parameter 'payload'
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

[server ~]# nc -v puppetdb.domain.com 8081
Connection to puppetdb.domain.com 8081 port [tcp/tproxy] succeeded!

>From the messages file on the master (after I've run puppet agent -t --noop 
--debug) I see this :


May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
(/File[/var/lib/puppet/lib]) Failed to generate additional resources using 
'eval_generate': Connection refused - connect(2)
May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
(/File[/var/lib/puppet/lib]) Could not evaluate: Could not retrieve file 
metadata for puppet://puppetdb.domain.com/plugins: Connection refused - 
connect(2)
May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
(/File[/var/lib/puppet/lib]) Wrapped exception:
May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
(/File[/var/lib/puppet/lib]) Connection refused - connect(2)
May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: Could not 
retrieve catalog from remote server: Connection refused - connect(2)
May 21 10:55:23 <3.5> puppetmaster.domain.com puppet-agent[8158]: Using 
cached catalog
May 21 10:55:23 <3.6> puppetmaster.domain.com puppet-agent[8158]: Applying 
configuration version '1399548635'
May 21 10:55:23 <3.5> puppetmaster.domain.com puppet-agent[8158]: Finished 
catalog run in 0.02 seconds
May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: Could not 
send report: Connection refused - connect(2)

the /var/lib/puppet/lib directory is empty on both the master and the 
puppetdb server.


Please let me know what configurational files you require to help me solve 
this issue.

Thank you.

-- 
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/869f0625-b870-4f5f-bfb8-85560c244fa8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] failed to submit 'replace facts' command for puppetmaster.domain.com to puppetDB

[Ken Barber]

This is almost always because you've upgraded the terminus to 2.0.0,
but the PuppetDB instance has not been upgraded properly - this could
be because you haven't installed the package, or the process has not
restarted correctly.

If you believe you've installed the puppetdb 2.0.0 package correctly
... try restarting the process for PuppetDB, forcefully if you have to
and attempt to restart with 2.0.0.

ken.

On Wed, May 21, 2014 at 12:37 PM, Kamjar Gerami  wrote:
> Hello,
>
> I have a separate
> 1. master running apache+passenger,
> 2. puppetDB on a separate server running postgresql
> 3. dashboard on a separate server.
>
> Total of 3 servers - Master, puppetdb. dashboard.
>
> This is the error message I get when I run puppet agent from any of the
> servers.
>
> ## I have changed the hostnames in the output below ##
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Failed to submit 'replace facts' command for puppetmaster.domain.com to
> PuppetDB at puppetDB.domain.com:8081: [400 Bad Request] Missing required
> query parameter 'payload'
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> [server ~]# nc -v puppetdb.domain.com 8081
> Connection to puppetdb.domain.com 8081 port [tcp/tproxy] succeeded!
>
> From the messages file on the master (after I've run puppet agent -t --noop
> --debug) I see this :
>
>
> May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]:
> (/File[/var/lib/puppet/lib]) Failed to generate additional resources using
> 'eval_generate': Connection refused - connect(2)
> May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]:
> (/File[/var/lib/puppet/lib]) Could not evaluate: Could not retrieve file
> metadata for puppet://puppetdb.domain.com/plugins: Connection refused -
> connect(2)
> May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]:
> (/File[/var/lib/puppet/lib]) Wrapped exception:
> May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]:
> (/File[/var/lib/puppet/lib]) Connection refused - connect(2)
> May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: Could not
> retrieve catalog from remote server: Connection refused - connect(2)
> May 21 10:55:23 <3.5> puppetmaster.domain.com puppet-agent[8158]: Using
> cached catalog
> May 21 10:55:23 <3.6> puppetmaster.domain.com puppet-agent[8158]: Applying
> configuration version '1399548635'
> May 21 10:55:23 <3.5> puppetmaster.domain.com puppet-agent[8158]: Finished
> catalog run in 0.02 seconds
> May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: Could not
> send report: Connection refused - connect(2)
>
> the /var/lib/puppet/lib directory is empty on both the master and the
> puppetdb server.
>
>
> Please let me know what configurational files you require to help me solve
> this issue.
>
> Thank you.
>
> --
> 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/869f0625-b870-4f5f-bfb8-85560c244fa8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAE4bNTmCuRHaHed8DDBwmjr3Lc6hvagiJScCtZK%2Bvo9gXm6MtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] failed to submit 'replace facts' command for puppetmaster.domain.com to puppetDB

[Kamjar Gerami]

Thank you for the reply Ken,

This is what my PuppetDB is running : 

rpm -qa | grep puppet

puppet-3.5.1-1.el6.noarch
puppetdb-1.6.3-1.el6.noarch
puppetdb-terminus-1.6.3-1.el6.noarch


This is what my master is running : 

pm -qa | grep puppet
puppetlabs-release-6-10.noarch
puppet-server-3.5.1-1.el6.noarch
puppetdb-terminus-2.0.0-1.el6.noarch
puppet-3.5.1-1.el6.noarch

Thank you - I will try to upgrade and see if that resolves my issues.


Den onsdagen den 21:e maj 2014 kl. 15:02:55 UTC+2 skrev Ken Barber:
>
> This is almost always because you've upgraded the terminus to 2.0.0, 
> but the PuppetDB instance has not been upgraded properly - this could 
> be because you haven't installed the package, or the process has not 
> restarted correctly. 
>
> If you believe you've installed the puppetdb 2.0.0 package correctly 
> ... try restarting the process for PuppetDB, forcefully if you have to 
> and attempt to restart with 2.0.0. 
>
> ken. 
>
> On Wed, May 21, 2014 at 12:37 PM, Kamjar Gerami 
> > 
> wrote: 
> > Hello, 
> > 
> > I have a separate 
> > 1. master running apache+passenger, 
> > 2. puppetDB on a separate server running postgresql 
> > 3. dashboard on a separate server. 
> > 
> > Total of 3 servers - Master, puppetdb. dashboard. 
> > 
> > This is the error message I get when I run puppet agent from any of the 
> > servers. 
> > 
> > ## I have changed the hostnames in the output below ## 
> > 
> > Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: 
> > Failed to submit 'replace facts' command for puppetmaster.domain.com to 
> > PuppetDB at puppetDB.domain.com:8081: [400 Bad Request] Missing 
> required 
> > query parameter 'payload' 
> > Warning: Not using cache on failed catalog 
> > Error: Could not retrieve catalog; skipping run 
> > 
> > [server ~]# nc -v puppetdb.domain.com 8081 
> > Connection to puppetdb.domain.com 8081 port [tcp/tproxy] succeeded! 
> > 
> > From the messages file on the master (after I've run puppet agent -t 
> --noop 
> > --debug) I see this : 
> > 
> > 
> > May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
> > (/File[/var/lib/puppet/lib]) Failed to generate additional resources 
> using 
> > 'eval_generate': Connection refused - connect(2) 
> > May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
> > (/File[/var/lib/puppet/lib]) Could not evaluate: Could not retrieve file 
> > metadata for puppet://puppetdb.domain.com/plugins: Connection refused - 
> > connect(2) 
> > May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
> > (/File[/var/lib/puppet/lib]) Wrapped exception: 
> > May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: 
> > (/File[/var/lib/puppet/lib]) Connection refused - connect(2) 
> > May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: Could 
> not 
> > retrieve catalog from remote server: Connection refused - connect(2) 
> > May 21 10:55:23 <3.5> puppetmaster.domain.com puppet-agent[8158]: Using 
> > cached catalog 
> > May 21 10:55:23 <3.6> puppetmaster.domain.com puppet-agent[8158]: 
> Applying 
> > configuration version '1399548635' 
> > May 21 10:55:23 <3.5> puppetmaster.domain.com puppet-agent[8158]: 
> Finished 
> > catalog run in 0.02 seconds 
> > May 21 10:55:23 <3.3> puppetmaster.domain.com puppet-agent[8158]: Could 
> not 
> > send report: Connection refused - connect(2) 
> > 
> > the /var/lib/puppet/lib directory is empty on both the master and the 
> > puppetdb server. 
> > 
> > 
> > Please let me know what configurational files you require to help me 
> solve 
> > this issue. 
> > 
> > Thank you. 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/869f0625-b870-4f5f-bfb8-85560c244fa8%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/698a9896-67f0-41e9-bd7e-c625923886ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms

[Ken Barber]

Catalogue size might be a factor, as templates get stored in the catalogue.

On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
 wrote:
> I encountered this same issue yesterday, and unfortunately haven't found a
> fix either.
>
> The error seems to be happening whenever I use the php::fpm::conf resource
> (with ensure => present) from https://forge.puppetlabs.com/thias/php.
> Removing that resource, or setting ensure to abset makes everything work
> fine. That resource is essentially only creating a file resource from a
> large template
> (https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
>
> I tried setting max-threads to 200 as well without any luck.
>
> On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
>>
>> Unfortunately setting max-threads to 200 did not help.
>>
>> # java -version
>> java version "1.7.0_55"
>> OpenJDK Runtime Environment (IcedTea 2.4.7)
>> (7u55-2.4.7-1ubuntu1~0.12.04.2)
>> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>>
>> # dpkg -l |grep -i java
>> ii  ca-certificates-java 20110912ubuntu6
>> Common CA certificates (JKS keystore)
>> ii  java-common  0.43ubuntu2
>> Base of all Java packages
>> ii  libjs-jquery 1.7.1-1ubuntu1
>> JavaScript library for dynamic web applications
>> ii  openjdk-7-jre-headless   7u55-2.4.7-1ubuntu1~0.12.04.2
>> OpenJDK Java runtime, using Hotspot JIT (headless)
>> ii  tzdata-java  2014c-0ubuntu0.12.04
>> time zone and daylight-saving time data for use by java runtimes
>>
>>
>> This is a fresh output in logs:
>>
>> 2014-05-20 15:21:52,331 INFO  [p.t.s.w.jetty9-service] Initializing web
>> server.
>> 2014-05-20 15:21:52,403 INFO  [p.t.s.w.jetty9-service] Starting web
>> server.
>> 2014-05-20 15:21:52,406 INFO  [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
>> 2014-05-20 15:21:52,436 INFO  [o.e.j.s.ServerConnector] Started
>> ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
>> 2014-05-20 15:21:52,504 INFO  [o.e.j.s.ServerConnector] Started
>> ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
>>
>> 2014-05-20 15:21:52,563 INFO  [c.p.p.c.services] PuppetDB version 2.0.0
>> 2014-05-20 15:21:52,704 INFO  [c.p.p.c.services] Starting broker
>> 2014-05-20 15:21:53,581 WARN  [o.a.a.b.BrokerService] Store limit is
>> 10 mb, whilst the data directory: /var/lib/puppetdb/mq/localhost/KahaDB
>> only has 63697 mb of usable space
>> 2014-05-20 15:21:53,582 INFO  [c.p.p.c.services] Starting 4 command
>> processor threads
>> 2014-05-20 15:21:53,602 INFO  [c.p.p.c.services] Starting query server
>> 2014-05-20 15:21:53,605 WARN  [o.e.j.s.h.ContextHandler] Empty contextPath
>> 2014-05-20 15:21:53,617 INFO  [o.e.j.s.h.ContextHandler] Started
>> o.e.j.s.h.ContextHandler@31771aa1{/,null,AVAILABLE}
>> 2014-05-20 15:21:53,643 INFO  [c.p.p.c.services] Starting sweep of stale
>> reports (threshold: 14 days)
>> 2014-05-20 15:21:53,667 INFO  [c.p.p.c.services] Finished sweep of stale
>> reports (threshold: 14 days)
>> 2014-05-20 15:21:53,667 INFO  [c.p.p.c.services] Starting database garbage
>> collection
>> 2014-05-20 15:21:53,698 INFO  [c.p.p.c.services] Finished database garbage
>> collection
>> 2014-05-20 15:22:05,832 INFO  [c.p.p.command]
>> [ce2e1e6e-5bc8-4f0a-bb20-e1edd153038d] [replace facts] prod1.site
>> 2014-05-20 15:22:36,859 WARN  [o.e.j.s.HttpChannel]
>> /v3/commands?checksum=7b886250b6f4ff03643ca1a82ff38476b015ec02
>> java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout
>> expired: 3/3 ms
>> at
>> org.eclipse.jetty.util.BlockingCallback.block(BlockingCallback.java:101)
>> ~[puppetdb.jar:na]
>> at
>> org.eclipse.jetty.server.HttpInputOverHTTP.blockForContent(HttpInputOverHTTP.java:62)
>> ~[puppetdb.jar:na]
>> at
>> org.eclipse.jetty.server.HttpInput$1.waitForContent(HttpInput.java:392)
>> ~[puppetdb.jar:na]
>> at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:161)
>> ~[puppetdb.jar:na]
>> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
>> ~[na:1.7.0_55]
>> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
>> ~[na:1.7.0_55]
>> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
>> ~[na:1.7.0_55]
>> at java.io.InputStreamReader.read(InputStreamReader.java:184)
>> ~[na:1.7.0_55]
>> at java.io.BufferedReader.fill(BufferedReader.java:154)
>> ~[na:1.7.0_55]
>> at java.io.BufferedReader.read(BufferedReader.java:175)
>> ~[na:1.7.0_55]
>> at clojure.core$slurp.doInvoke(core.clj:6396) ~[puppetdb.jar:na]
>> at clojure.lang.RestFn.invoke(RestFn.java:410) ~[puppetdb.jar:na]
>> at ring.util.request$eval10113$fn__10114.invoke(request.clj:30)
>> ~[na:na]
>> at clojure.lang.MultiFn.invoke(MultiFn.java:227)
>> ~[puppetdb.jar:na]
>> at
>> com.puppetlabs.middleware$payload_to_body_string$fn__10429.invoke(middleware.clj:273)
>> ~[na:na]
>> at
>> com.puppetlabs.middleware$

[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts

[jcbollinger]

On Tuesday, May 20, 2014 12:54:15 PM UTC-5, Jesse Cotton wrote:
>
>
> Understood. However without creating a custom fact, I am not aware of a 
> way to say 'apache::keepalive = 1' only applies when a node has the profile 
> 'profile::apache_phpfpm'. 
>
>

There is no good way to say that to Puppet.  It reflects a non-idiomatic 
thought process.  Moreover, it's unlikely to be what you really want to say 
-- you might in the future want other nodes to have keepalive enabled, 
too.  You should instead consider how to assign apache::keepalive: 1 to 
exactly those nodes that get profile::apache_phpfpm.

There are at least two ways you could approach that problem:

   1. If you are using hiera to assign roles and/or profiles to nodes then 
   it should be entirely straightforward to override apache::keepalive at the 
   same hierarchy level where you assign profile::apache_phpfpm.
   2. You can perform a resource parameter override in 
   profile::apache_phpfpm.

If it is viable, the former is preferable to the latter.  A resource 
parameter override is a bit messy because it relies on implementation 
details of module 'apache'.  (It does not work to override class 
parameters; you must instead override one or more parameters of a bona fide 
resource, which can be of either defined or native type.)

 

>
> And the foregoing is based on using only the built-in YAML back end.  
>> Hiera supports pluggable back ends, usable together or separately.  A 
>> custom back end can employ whatever lookup or computation you want to serve 
>> whichever data you choose.
>>
>>
> We're really trying to avoid this.
>


I don't blame you.  A custom back-end should certainly be a last resort.  
As you keep that alternative in reserve, however, don't forget that such a 
custom component does not necessarily need to replace the YAML back-end; 
hiera can use two (or more) at the same time.

 

>
>>> class profile::drupal (
>>>   $apache_listen = ['80'],
>>>   $apache_name_virtual_hosts = ['*:80'],
>>>   $apache_modules = ['fastcgi'],
>>>   $apache_fastcgi_servers = {
>>> 'www' => {
>>>   host => '127.0.0.1:9000',
>>>   faux_path => '/var/www/php.fcgi',
>>>   alias => '/php.fcgi',
>>>   file_type => 'application/x-httpd-php'
>>> }
>>>   },
>>>   $phpfpm_pools = {
>>> 'www' => {
>>>   listen  => '127.0.0.1:9000',
>>>   user => 'apache',
>>>   pm_max_requests => 500,
>>>   catch_workers_output => 'no',
>>>   php_admin_value => {},
>>>   php_value => {}
>>> }
>>>   },
>>>   $php_modules = [],
>>>   $firewall_rules = {},
>>>   $backup_jobs = {},
>>>   $cron_jobs = {}
>>> ) {
>>>
>>>   include ::apache
>>>   ::apache::listen { $apache_listen: }
>>>   ::apache::namevirtualhost { $apache_name_virtual_hosts: }
>>>   ::apache::mod { $apache_modules: }
>>>   create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
>>>
>>>   include ::php::fpm::daemon
>>>   create_resources(::php::fpm::conf, $phpfpm_pools)
>>>   ::php::module { $php_modules: } ~> Service['php-fpm']
>>>
>>>   # So the apache user is created before
>>>   # php-fpm starts
>>>   Class['::apache'] -> Class['::php::fpm::daemon']
>>>
>>>   create_resources(firewall, $firewall_rules)
>>>   create_resources(::duplicity::job, $backup_jobs)
>>>   create_resources(::cron::job, $cron_jobs)
>>> }
>>>  
>>>
>>
>>
>> Either you're missing something or I am.  I see nothing in that class 
>> that would inherently preclude it being composed.  In particular, the two 
>> class declarations it contains both use 'include', not the resource-like 
>> class declaration syntax.  If there is a barrier to composition it would be 
>> related to composition with another class that declares some of the same 
>> resources.  That problem has a solution, however: factor out the 
>> multiply-declared resources into their own class or classes, which the 
>> then-composable classes declare instead of declaring the resources directly.
>>
>>
> Duplicate declaration: Apache::Listen[80] is already declared in file ...
>
>
>

As I said, a duplicate resource.  As I said, factor it (and the others) 
out.  I think it's excellent practice to avoid resource declarations 
directly in profile classes, unless possibly of resources that are 
assuredly specific to the profile in which they appear.

 

> Yes, the class could be broken into separate classes but this only 
> exacerbates the issue of assigning variables based on the profile.
>
>
>

But that's just it: you don't *want* to assign data based (strictly) on 
profile.  Or if you do, then understand that it is inherently inconsistent 
with composable profiles.  Since the node characteristic that determines 
the combination of profiles in use is its role, it is on that basis that 
you want to assign data.  Indeed, that's what you already said with respect 
to apache::keepalive.  Note that with hiera, that doesn't mean you must 
avoid assigning data based on profile; it just means you must (also) be 
able to

Re: [Puppet Users] Re: Yumrepo resource flapping

[jcbollinger]

On Tuesday, May 20, 2014 12:45:45 PM UTC-5, DjE wrote:
>
>
> I agree with you about this potential conflict, but it's a default RedHat 
> configuration with rhsm, and it does not manage exactly the same thing.
>
> Puppet enable the "rhel-6-server-optional-rpms"  which is not by enabled 
> default, and we never said rhsm to enable it (redhat subscription side), so 
> rhsm respect the local decision made via Puppet with the Yumrepo, so it's 
> just a syntax conflict,
>


No, it's not.  rhsm is modifying the repository configuration file, even if 
it is modifying it to a form that is equivalent from Yum's perspective.  If 
rhsm may change the file in any way, then it's managing the file.

 

>   it could be a nice thing that Puppet use the same syntax.
>
>

That might solve your particular issue, but Puppet cannot match the syntax 
details of every piece of software that might conceivably manage Yum 
repository files.  And it's not worthwhile to try, because the underlying 
problem is not a syntax conflict, it's that you have established 
overlapping management responsibilities on your system.

 

> Puppet manage the rhsm.conf file so i tried to disable the manage_repos 
> option, but the redhat.repo file has been destroyed by the rhsmcertd 
> service, and disabled all RedHat repositories.
> Then Puppet creates the /etc/yum.repos.d/rhel-6-server-optional-rpms.repo 
> file with just the "enabled=1" parameter currently define by the Yumrepo 
> resource.
> We don't want to (re)define all the redhat repository urls one by one with 
> the YumRepo resource, maybe there is a better solution.
>
>

You have the alternative of managing repo configuration files via a File 
resource instead of via a Yumrepo resource.  You can control every detail 
of the file's puppet-asserted content that way.  If you want to do that for 
multiple repo config files then you could consider creating a defined type 
for the purpose.  That's a little more limited than the Yumrepo resource 
type, however, because Yumrepo can manage existing repository definitions 
in whatever file they appear, whereas a File resource must manage a 
specific file.


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/cf31517f-f377-402b-94ef-e093d068a4e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Problem using Vagrant + Puppet

[Nikola Petrov]

On Tue, May 20, 2014 at 07:06:20AM -0700, Rafaella Keury wrote:
> Hello,
> I'm using Vagrant and i'm trying to use Puppet as a tool for provisioning 
> one of my virtual machines.
> I created a folder named 'manifests' in the same directory of my 
> VagrantFile. Inside the 'manifests' folder I created a file named db.pp 
> with the following content:
> "exec { "apt-update":
> command => "/usr/bin/apt-get update"
> }
> package { "mysql-server":
> ensure => installed,
> require => Exec["apt-update"],
> }"

You will need to wrap that in 

node default {
}

The  file that you give as manifest_file to vagrant should be a
manifest with node definitions

> 
> My VagrantFile looks like this:
> "VAGRANTFILE_API_VERSION = "2"
> Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
> config.vm.box = "hashicorp/precise32"
> config.vm.define :db do |db_config|
> db_config.vm.network :private_network, :ip => "192.168.33.10"
> db_config.vm.provision "puppet" do |puppet|
> puppet.manifest_file = "db.pp"
> end
> end"
> 
> But when I type vagrant up db on command line, I receive the following 
> error message:
> "The configured puppet manifest is missing. Please specify a path to an 
> existing manifest"
> Does anyone know what is it?
> My OS is Windows 7.
> Thanks a lot!
> 
> -- 
> 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/40e0040c-7634-4f6c-865c-f31357ff8cb3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/20140521144229.GB26275%40nikolavp-desktop.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts

[Jesse Cotton]

>
> But that's just it: you don't *want* to assign data based (strictly) on 
> profile.  Or if you do, then understand that it is inherently inconsistent 
> with composable profiles.  Since the node characteristic that determines 
> the combination of profiles in use is its role, it is on that basis that 
> you want to assign data.  Indeed, that's what you already said with respect 
> to apache::keepalive.  Note that with hiera, that doesn't mean you must 
> avoid assigning data based on profile; it just means you must (also) be 
> able to assign data based on role, with the role-based data having higher 
> priority.


I understand this better now however the problem we were really struggling 
with was how to assign variables based on role or profile. Ie, how do you 
incorporate the the role or profile into the hierarchy so a variable only 
applies to nodes that have a particular role or profile. Your first 
suggestion is good although thats not how we're currently assigning classes.

On Wednesday, May 21, 2014 10:03:33 AM UTC-4, jcbollinger wrote:
>
>
>
> On Tuesday, May 20, 2014 12:54:15 PM UTC-5, Jesse Cotton wrote:
>>
>>
>> Understood. However without creating a custom fact, I am not aware of a 
>> way to say 'apache::keepalive = 1' only applies when a node has the profile 
>> 'profile::apache_phpfpm'. 
>>
>>
>
> There is no good way to say that to Puppet.  It reflects a non-idiomatic 
> thought process.  Moreover, it's unlikely to be what you really want to say 
> -- you might in the future want other nodes to have keepalive enabled, 
> too.  You should instead consider how to assign apache::keepalive: 1 to 
> exactly those nodes that get profile::apache_phpfpm.
>
> There are at least two ways you could approach that problem:
>
>1. If you are using hiera to assign roles and/or profiles to nodes 
>then it should be entirely straightforward to override apache::keepalive 
> at 
>the same hierarchy level where you assign profile::apache_phpfpm.
>2. You can perform a resource parameter override in 
>profile::apache_phpfpm.
>
> If it is viable, the former is preferable to the latter.  A resource 
> parameter override is a bit messy because it relies on implementation 
> details of module 'apache'.  (It does not work to override class 
> parameters; you must instead override one or more parameters of a bona fide 
> resource, which can be of either defined or native type.)
>
>  
>
>>
>> And the foregoing is based on using only the built-in YAML back end.  
>>> Hiera supports pluggable back ends, usable together or separately.  A 
>>> custom back end can employ whatever lookup or computation you want to serve 
>>> whichever data you choose.
>>>
>>>
>> We're really trying to avoid this.
>>
>
>
> I don't blame you.  A custom back-end should certainly be a last resort.  
> As you keep that alternative in reserve, however, don't forget that such a 
> custom component does not necessarily need to replace the YAML back-end; 
> hiera can use two (or more) at the same time.
>
>  
>
>>
 class profile::drupal (
   $apache_listen = ['80'],
   $apache_name_virtual_hosts = ['*:80'],
   $apache_modules = ['fastcgi'],
   $apache_fastcgi_servers = {
 'www' => {
   host => '127.0.0.1:9000',
   faux_path => '/var/www/php.fcgi',
   alias => '/php.fcgi',
   file_type => 'application/x-httpd-php'
 }
   },
   $phpfpm_pools = {
 'www' => {
   listen  => '127.0.0.1:9000',
   user => 'apache',
   pm_max_requests => 500,
   catch_workers_output => 'no',
   php_admin_value => {},
   php_value => {}
 }
   },
   $php_modules = [],
   $firewall_rules = {},
   $backup_jobs = {},
   $cron_jobs = {}
 ) {

   include ::apache
   ::apache::listen { $apache_listen: }
   ::apache::namevirtualhost { $apache_name_virtual_hosts: }
   ::apache::mod { $apache_modules: }
   create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)

   include ::php::fpm::daemon
   create_resources(::php::fpm::conf, $phpfpm_pools)
   ::php::module { $php_modules: } ~> Service['php-fpm']

   # So the apache user is created before
   # php-fpm starts
   Class['::apache'] -> Class['::php::fpm::daemon']

   create_resources(firewall, $firewall_rules)
   create_resources(::duplicity::job, $backup_jobs)
   create_resources(::cron::job, $cron_jobs)
 }
  

>>>
>>>
>>> Either you're missing something or I am.  I see nothing in that class 
>>> that would inherently preclude it being composed.  In particular, the two 
>>> class declarations it contains both use 'include', not the resource-like 
>>> class declaration syntax.  If there is a barrier to composition it would be 
>>> related to composition with another class that declares some of the same 
>>> resources.  That problem has a solution, however: fa

Re: [Puppet Users] Re: Yumrepo resource flapping

[jcbollinger]

On Tuesday, May 20, 2014 4:24:01 PM UTC-5, Johan De Wit wrote:
>
>  the yumrepo resource creates a *.repo file for every resource.
>


Yes, if the repo definition does not already exist.  If it does exist then 
Puppet manages it in whatever file contains it.  Or it should do, and used 
to do.  I thought I had seen a ticket about a regression in that area, but 
I'm having trouble finding it now.

 

>   The redhat thing just puts all repos in one big file. 
> and if you remove the redhat.repo, on a subscribed system, this file will 
> be recreated depending on the subscribed channel.
>
>

One file or several should not be a problem for Puppet.

If the file continues to flap, however, instead of just flapping once, then 
something very strange is going on.  Puppet should not be modifying the 
file if all the managed properties are already in the correct target state, 
even if the location or formatting details are not what Puppet would use.  
That would indeed be a bug that should be reported.


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/9e0648f1-aa50-4b1c-8bc6-e09d0051886a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] could not retrieve information from environment development source(s) file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh

[Supriya Uppalapati]

Hi,
 
I am having an error could not retrieve information development source 
*file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh*

 
Please help me

 
I have a code in 
*/etc/puppetlabs/puppet/modules/java_versions/manifests/init.pp*
 







*class java_versions {# $::var_java_ver = '1.7.0_42'  file 
{'/usr/local/sbin/java_path.sh': source => 
'/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh',  
owner => root,  group => root,  mode  => '0700',}*













*if versioncmp($::var_java_ver, $java_version) < 0 { notify {"using 
concatenated files, java version ${java_version}":; }} else { # work with 
java   notify {"using java, java version ${java_version}":; }}# file 
{'/usr/local/sbin/java.sh': # source => 
'/etc/puppetlabs/puppet/modules/java_versions/scripts/java.sh',  #owner => 
root,  #group => root,  #mode  => '700',#} if $java_version == 'notexit' {*


*warning('java versions are not available ($java_version)')}}*
And script in /
*etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh* 

*$cat java_path.shrunuser -l oracle -c 
'/u01/app/oracle/product/jdk1.7.0_25/bin/java -version'*
 
*Ruby code 
:/etc/puppetlabs/puppet/modules/java_versions/lib/facter/java_path.rb*
 
*$vi  java_path.rbrequire 'facter'*







*Facter.add(:java_path) do  setcode do
Facter::Util::Resolution.exec('/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh')
  
endend*
 
 
 

-- 
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/dfa17004-6c33-4fe0-b7a1-88ffaab40362%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: could not retrieve information from environment development source(s) file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh

[Supriya Uppalapati]

On Wednesday, May 21, 2014 11:05:25 AM UTC-4, Supriya Uppalapati wrote:
>
> Hi,
>  
> I am having an error could not retrieve information development source 
> *file:/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh*
>
>  
> Please help me
>
>  
> I have a code in 
> */etc/puppetlabs/puppet/modules/java_versions/manifests/init.pp*
>  
>
>
>
>
>
>
>
> *class java_versions {# $::var_java_ver = '1.7.0_42'  file 
> {'/usr/local/sbin/java_path.sh': source => 
> '/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh',  
> owner => root,  group => root,  mode  => '0700',}*
>
>
>
>
>
>
>
>
>
>
>
>
>
> *if versioncmp($::var_java_ver, $java_version) < 0 { notify {"using 
> concatenated files, java version ${java_version}":; }} else { # work with 
> java   notify {"using java, java version ${java_version}":; }}# file 
> {'/usr/local/sbin/java.sh': # source => 
> '/etc/puppetlabs/puppet/modules/java_versions/scripts/java.sh',  #owner => 
> root,  #group => root,  #mode  => '700',#} if $java_version == 'notexit' {*
>
>
> *warning('java versions are not available ($java_version)')}}*
> And script in /
> *etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh* 
>
> *$cat java_path.shrunuser -l oracle -c 
> '/u01/app/oracle/product/jdk1.7.0_25/bin/java -version'*
>  
> *Ruby code 
> :/etc/puppetlabs/puppet/modules/java_versions/lib/facter/java_path.rb*
>  
> *$vi  java_path.rbrequire 'facter'*
>
>
>
>
>
>
>
> *Facter.add(:java_path) do  setcode do
> Facter::Util::Resolution.exec('/etc/puppetlabs/puppet/modules/java_versions/scripts/java_path.sh')
>   
> endend*
>  
>  
>  
>

-- 
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/0ef933e4-050f-423a-9d83-ececc9c385a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet dashboard Pending statistics always 0

[Rudy Gevaert]

Hi, 

I've set up puppet dashboard and my puppet master 3.6.0 is sending its 
reports. 

However, when i run an agent in noop mode, the Pending column on the 
dashboard for that node remains 0.  While it should not be 0. 

The nodes pending stats on the left side are always 0 too. 

Any ideas how to troubleshoot this? 

Thanks, 

Rudy 

-- 
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/2d29c7c4-a9b3-433b-b8a4-35fc64f363f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] First time using template... Is this correct?

[Keith Shannon]

Hello everyone and thank you for taking the time to ready this.

I have been creating my first puppet module for a chatserver we run. The 
chatserver is basically just a perl script & its' not too hard to setup. 
Our previous setup was with CFEngine so I'm porting everything over. 
Setting the files in place was easy but we are moving from inittab to 
Upstart (/etc/init instead of /etc/inittab).

Each server runs 7 instances of the chatserver on 7 different ports for 2 
different sites.

Before I had two separate scripts that kept everything writing.

First chat_server_start.conf calls chat_server with the following:

start on runlevel [345]

task

script
start chat_server PORT="5000" SITE="ffadult"
start chat_server PORT="5001" SITE="ffadult"
start chat_server PORT="5002" SITE="ffadult"
start chat_server PORT="5003" SITE="ffadult"
start chat_server PORT="5004" SITE="ffadult"
start chat_server PORT="6600" SITE="getiton"
start chat_server PORT="6601" SITE="getiton"
end script


Then chat_server.conf runs...

# Respawn and start rules for chat_server.pl

stop on runlevel [06]
respawn
instance $PORT

exec /site/bin/chat/chat_server.pl $SITE $PORT >> 
/var/log/chat_server/chat_server_${SITE}_${PORT}.log 2>&1

Simple enough... So here's where I'm unsure if I've done it right. In my 
git repo for puppet my modules is in /home/user/puppet/modules/chatserver

In files I have chat_server.conf & ffadult_chatserver_start.conf (we have 
multiple clusters it's running on & it's called via a variable in the other 
file to call specific roles)

So now, I have created a template called chatserver_start.conf.erb and it 
looks like the following:

start on runlevel [345]

task

script
<% @chats.each do |site_port| -%>
start chat_server PORT="<%= port %>" SITE="<%= site %>"
<% end -%>
end script

I haven't put the contents of all related files here... So if you see are 
wondering about something being called just let me know. I then put the 
different port-site variations in hiera.

---
classes:
  - ffn_logrotate::chat_server
  - ffn_cron::cron_clean_chat_tmp
  - ffn_cron::cron_chat_server_cleanup
  - ffn::chatserver
  - chatserver::chats:
ffadult: '5000'
ffadult: '5001'
ffadult: '5002'
ffadult: '5003'
ffadult: '5004'
getiton: '6000'
getiton: '6001'

Did I do this correctly? Any help would be appreciated. Even just pointing 
to the proper documentation would be much appreciated. Our resident puppet 
expert is out for the week and I'm trying to get this done before then.

Thanks again!

-- 
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/e330f72e-6b8a-4548-a44d-c06a9ccbec1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] On code organization and the deprecation of include

[Andre Nathan]

Hello

I have a fairly large repository (~100 modules, ~50 classes, ~200 nodes). 
It is currently organized like this:

modules/
apache2/
  manifests/
  files/
  templates/
iptables/
  manifests/
  files/
  templates/
postfix/
  manifests/
  files/
  templates/
...
manifests/
classes/
webserver.pp
webserver/
apache2.pp
iptables.pp
mta/
postfix.pp
iptables.pp
...
nodes/
webserver.pp
webserver/
web1.pp
web2.pp
...
mta.pp
mta/
mta1.pp
mta2.pp
...

Subclasses in the modules directory are found via the autoloader, and as 
long as I follow the file naming conventions, that works fine. For classes 
and nodes, I have to use import. For example, in classes/webserver.pp I 
have "import webserver/*.pp" so that I can access classes 
webserver::apache2, webserver::iptables and so on. The same is done for 
nodes. I usually have a "generic node" where I set variables that are 
common for that class of nodes, and then the nodes themselves which inherit 
the generic node and set their own variables. To make that work, I use 
import in the same way as described above.

I understand that with the deprecation of "include", this will not work 
anymore. I can work around this for my classes by adding a new directory to 
the modulepath and then converting the directory structure to the 
manifests/files/templates structure with an init.pp file. However, what can 
I do about the nodes? The new feature of setting the manifest to a 
directory does not support subdirectories. Will I be forced to have all my 
nodes in the same directory and then rely on file names for organization? 
This is far from optimal in my opinion. What other alternatives do I have? 
If at all possible, I'd like to avoid using ENCs and keep using puppet 
files for node definitions.

Thanks in advance,
Andre

-- 
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/7eabce0e-edf6-488a-8182-41ba41e09f0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] On code organization and the deprecation of include

[Garrett Honeycutt]

On 5/21/14, 11:45 AM, Andre Nathan wrote:
> Hello
> 
> I have a fairly large repository (~100 modules, ~50 classes, ~200
> nodes). It is currently organized like this:
> 
> modules/
> apache2/
>   manifests/
>   files/
>   templates/
> iptables/
>   manifests/
>   files/
>   templates/
> postfix/
>   manifests/
>   files/
>   templates/
> ...
> manifests/
> classes/
> webserver.pp
> webserver/
> apache2.pp
> iptables.pp
> mta/
> postfix.pp
> iptables.pp
> ...
> nodes/
> webserver.pp
> webserver/
> web1.pp
> web2.pp
> ...
> mta.pp
> mta/
> mta1.pp
> mta2.pp
> ...
> 
> Subclasses in the modules directory are found via the autoloader, and as
> long as I follow the file naming conventions, that works fine. For
> classes and nodes, I have to use import. For example, in
> classes/webserver.pp I have "import webserver/*.pp" so that I can access
> classes webserver::apache2, webserver::iptables and so on. The same is
> done for nodes. I usually have a "generic node" where I set variables
> that are common for that class of nodes, and then the nodes themselves
> which inherit the generic node and set their own variables. To make that
> work, I use import in the same way as described above.
> 
> I understand that with the deprecation of "include", this will not work
> anymore. I can work around this for my classes by adding a new directory
> to the modulepath and then converting the directory structure to the
> manifests/files/templates structure with an init.pp file. However, what
> can I do about the nodes? The new feature of setting the manifest to a
> directory does not support subdirectories. Will I be forced to have all
> my nodes in the same directory and then rely on file names for
> organization? This is far from optimal in my opinion. What other
> alternatives do I have? If at all possible, I'd like to avoid using ENCs
> and keep using puppet files for node definitions.
> 
> Thanks in advance,
> Andre
> 

Hi Andre,

I believe you mean the deprecation of 'import'. The easiest way to fix
this is to cat all of your files together into one site.pp file.

Your usage of a base node that other nodes inherit is an anti-pattern
though and will cause you grief as you grow. Recommend reading about
Craig Dunn's roles and profiles pattern and hiera_include for
classifying nodes.

Best regards,
-g

-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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/537CD0E7.5050206%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms

[Ken Barber]

So one thing I'm sure about - is that there was no idle timeout
defined in 1.6.3 at all. I can connect idle for quite some time for
example. Its quite possible that there is another delay/lag somewhere
causing the connection to be idle in the first place - but with 1.6.3
this would not have surfaced for example as a server error, because
there was no idle handling.

ken.

On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
 wrote:
> Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
> The template is only 20K, so large here is probably somewhat relative.
>
> Any other thoughts?
>
> Just for reference, I'm running the same version of Java as Sergey:
> java version "1.7.0_55"
> OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>
>
>
> On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:
>>
>> Catalogue size might be a factor, as templates get stored in the
>> catalogue.
>>
>> On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
>>  wrote:
>> > I encountered this same issue yesterday, and unfortunately haven't found
>> > a
>> > fix either.
>> >
>> > The error seems to be happening whenever I use the php::fpm::conf
>> > resource
>> > (with ensure => present) from https://forge.puppetlabs.com/thias/php.
>> > Removing that resource, or setting ensure to abset makes everything work
>> > fine. That resource is essentially only creating a file resource from a
>> > large template
>> > (https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
>> >
>> > I tried setting max-threads to 200 as well without any luck.
>> >
>> > On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
>> >>
>> >> Unfortunately setting max-threads to 200 did not help.
>> >>
>> >> # java -version
>> >> java version "1.7.0_55"
>> >> OpenJDK Runtime Environment (IcedTea 2.4.7)
>> >> (7u55-2.4.7-1ubuntu1~0.12.04.2)
>> >> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>> >>
>> >> # dpkg -l |grep -i java
>> >> ii  ca-certificates-java 20110912ubuntu6
>> >> Common CA certificates (JKS keystore)
>> >> ii  java-common  0.43ubuntu2
>> >> Base of all Java packages
>> >> ii  libjs-jquery 1.7.1-1ubuntu1
>> >> JavaScript library for dynamic web applications
>> >> ii  openjdk-7-jre-headless   7u55-2.4.7-1ubuntu1~0.12.04.2
>> >> OpenJDK Java runtime, using Hotspot JIT (headless)
>> >> ii  tzdata-java  2014c-0ubuntu0.12.04
>> >> time zone and daylight-saving time data for use by java runtimes
>> >>
>> >>
>> >> This is a fresh output in logs:
>> >>
>> >> 2014-05-20 15:21:52,331 INFO  [p.t.s.w.jetty9-service] Initializing web
>> >> server.
>> >> 2014-05-20 15:21:52,403 INFO  [p.t.s.w.jetty9-service] Starting web
>> >> server.
>> >> 2014-05-20 15:21:52,406 INFO  [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
>> >> 2014-05-20 15:21:52,436 INFO  [o.e.j.s.ServerConnector] Started
>> >> ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
>> >> 2014-05-20 15:21:52,504 INFO  [o.e.j.s.ServerConnector] Started
>> >> ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
>> >>
>> >> 2014-05-20 15:21:52,563 INFO  [c.p.p.c.services] PuppetDB version 2.0.0
>> >> 2014-05-20 15:21:52,704 INFO  [c.p.p.c.services] Starting broker
>> >> 2014-05-20 15:21:53,581 WARN  [o.a.a.b.BrokerService] Store limit is
>> >> 10 mb, whilst the data directory:
>> >> /var/lib/puppetdb/mq/localhost/KahaDB
>> >> only has 63697 mb of usable space
>> >> 2014-05-20 15:21:53,582 INFO  [c.p.p.c.services] Starting 4 command
>> >> processor threads
>> >> 2014-05-20 15:21:53,602 INFO  [c.p.p.c.services] Starting query server
>> >> 2014-05-20 15:21:53,605 WARN  [o.e.j.s.h.ContextHandler] Empty
>> >> contextPath
>> >> 2014-05-20 15:21:53,617 INFO  [o.e.j.s.h.ContextHandler] Started
>> >> o.e.j.s.h.ContextHandler@31771aa1{/,null,AVAILABLE}
>> >> 2014-05-20 15:21:53,643 INFO  [c.p.p.c.services] Starting sweep of
>> >> stale
>> >> reports (threshold: 14 days)
>> >> 2014-05-20 15:21:53,667 INFO  [c.p.p.c.services] Finished sweep of
>> >> stale
>> >> reports (threshold: 14 days)
>> >> 2014-05-20 15:21:53,667 INFO  [c.p.p.c.services] Starting database
>> >> garbage
>> >> collection
>> >> 2014-05-20 15:21:53,698 INFO  [c.p.p.c.services] Finished database
>> >> garbage
>> >> collection
>> >> 2014-05-20 15:22:05,832 INFO  [c.p.p.command]
>> >> [ce2e1e6e-5bc8-4f0a-bb20-e1edd153038d] [replace facts] prod1.site
>> >> 2014-05-20 15:22:36,859 WARN  [o.e.j.s.HttpChannel]
>> >> /v3/commands?checksum=7b886250b6f4ff03643ca1a82ff38476b015ec02
>> >> java.io.IOException: java.util.concurrent.TimeoutException: Idle
>> >> timeout
>> >> expired: 3/3 ms
>> >> at
>> >>
>> >> org.eclipse.jetty.util.BlockingCallback.block(BlockingCallback.java:101)
>> >> ~[puppetdb.jar:na]
>> >> at
>> >>
>> >> org.eclipse.jetty.server.HttpInputOverHTTP.blockForContent(HttpInputOverHTTP.java:62)
>> >> ~[pupp

Re: [Puppet Users] On code organization and the deprecation of include

[Andre Nathan]

On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote:
>
> I believe you mean the deprecation of 'import'.


Woops, indeed.
 

> The easiest way to fix 
> this is to cat all of your files together into one site.pp file. 
>

Now that's even worse than having all node files in a single directory.
 

> Your usage of a base node that other nodes inherit is an anti-pattern 
> though and will cause you grief as you grow.


Why is it an anti-pattern? Isn't variable inheritance supported? Why can't 
I organize my nodes in sub-directories? It's something simple that greatly 
enhances code organization.

Best,
Andre

-- 
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/3be8fcd1-0626-4947-bf2b-d9d63475f470%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] On code organization and the deprecation of include

[Doug Forster]

It may be worth it to look more at hiera and adjust your codebase there.
For example my site.pp has one line: hiera_include('classes').

I organize my setup so that hiera looks for my nodes under
hieradata/nodes/certname.yaml I see no reason not to allow further nesting
if needed.

That being said it may be a good time to look into an ENC (External Node
Classifier) like Foreman. I haven't done this yet as I work on a team and
have to take baby steps so everyone keeps up.


On Wed, May 21, 2014 at 10:44 AM, Andre Nathan  wrote:

> On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote:
>>
>> I believe you mean the deprecation of 'import'.
>
>
> Woops, indeed.
>
>
>> The easiest way to fix
>> this is to cat all of your files together into one site.pp file.
>>
>
> Now that's even worse than having all node files in a single directory.
>
>
>> Your usage of a base node that other nodes inherit is an anti-pattern
>> though and will cause you grief as you grow.
>
>
> Why is it an anti-pattern? Isn't variable inheritance supported? Why can't
> I organize my nodes in sub-directories? It's something simple that greatly
> enhances code organization.
>
> Best,
> Andre
>
>  --
> 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/3be8fcd1-0626-4947-bf2b-d9d63475f470%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOwhAcq4oYFwk_%3DStwBcftk%2BOMTVWXYrjWLiZUp8%3D5hCwO8saQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] On code organization and the deprecation of include

[Andre Nathan]

On Wednesday, May 21, 2014 1:59:09 PM UTC-3, Doug_F wrote:
>
> I organize my setup so that hiera looks for my nodes under 
> hieradata/nodes/certname.yaml I see no reason not to allow further nesting 
> if needed. 
>

It may be the only solution for me, but I'd rather not use YAML files as 
the risk of someone doing an edit and messing up with the indentation is 
high.

That being said it may be a good time to look into an ENC (External Node 
> Classifier) like Foreman. I haven't done this yet as I work on a team and 
> have to take baby steps so everyone keeps up. 
>

This would remove the nodes from version control, which I'd rather not do 
either...

Thanks,
Andre

-- 
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/a0e9c129-5867-4931-95e1-653a5d8c8835%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases

[Brian Mathis]

On Wed, May 21, 2014 at 4:29 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

> On 05/20/2014 07:16 PM, Brian Mathis wrote:
> > This is a bug in validate_re(), even though there is a workaround.
>
> Arguably so.
>
> One could also argue, on the other hand, that regular expressions are
> matched by *strings* and nothing else. Sure, we've been spoiled by bash
> and perl which don't give damn and implicitly convert to string every
> chance they get. But that isn't a universal truth. Point in fact
>
> irb(main):001:0> puts "it works!" if 5 =~ /[0-9]+/
> => nil
>
> I agree that it *is* inconvenient to check for two cases "is numeric" or
> "contains a number" when logically the former implies the latter. I also
> think that implicit string conversion would be a beneficial feature for
> validate_re. But it is not necessarily a bug.
>
> Cheers,
> Felix
>


If validate_re() is only effective on strings, then, in a dynamically typed
language such as ruby/puppet, it better make sure it's casting to a string
inside the function.  Forcing the use of quotes is a workaround for
something that it should be doing and creates inconsistency in the
interface.  Forcing the user to be aware of the internals of the function
in order to use it defeats the point of using functions.

One of the big problems here is that sometimes it works and sometimes it
doesn't for the same data, depending on where you got it and what you did
with it, which is clearly a bug.  I'm not sure how else you can define a
bug other than "actual behavior does not match expected behavior", when the
expectation is merely that the function performs in a predictable way.


❧ Brian Mathis
@orev

-- 
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/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Resources overridden using Hiera

[Danny Roberts]

I currently have a custom module that applies our companies' standard 
server config across all servers using Hiera. This includes a class called 
company::sshkeys that has various 'user' resource types (the standard 
puppet type) defined for all of our admins, for example:

class company::sshkeys {

  user {  "jane.doe":
ensure  => present,
gid => "company",
home=> "/home/jane.doe",
managehome => true,
shell => "/bin/bash",
require => Group["company"]
}

}

This is a slight simplification as the same class also includes our SSH 
public keys hence the name.

I now find myself in the situation where I need to deny access to certain 
admins on a single server. We use Hiera in our set-up as much as possible 
and I would like to use Hiera to in the case of a single server tell Puppet 
to not create certain user accounts. I have tried many ways to do this but 
I am unsure on how to call the base resource types even though they are 
embedded in a custom class or even if such a thing is possible.

Any thoughts on the cleanest way to exclude certain users from getting an 
account?

-- 
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/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms

[Ken Barber]

Phil,

Do you happen to have a tcpdump I can look at, one where this problem
is replicated? I know its SSL - but I'm primarily interested in seeing
when (and _IF_) the network connection goes idle - so packet timing is
more important to me then content. I'm trying to prove/disprove that
idletimeout is doing the correct thing here or not. It could be that
the idling is caused by something else, and the timeout is valid - or
it could be that the idletimeout is not actually paying attention to
traffic (which I can't prove locally at least for cleartext - it seems
fine).

There is also a chance the idling could be after traffic is submitted,
which would make things even more interesting. Either way I'd like
some external confirmation of this reported 'idling' and the best way
is probably via tcpdump's. If we can prove the idle timeout is correct
in its behaviour, we can stop looking at Jetty as the cause, which
helps us a lot.

If you want to chat I'm on Freenode in #puppet (ken_barber).

My colleague in the meantime is trying to upgrade us to Jetty 9.1.5
(from 9.1.0), its a non-trivial upgrade though, which sucks when under
duress. We're also looking at introducing the idle-timeout setting so
we can play with that also, potentially as a work-around for now.

ken.

On Wed, May 21, 2014 at 5:29 PM, Ken Barber  wrote:
> So one thing I'm sure about - is that there was no idle timeout
> defined in 1.6.3 at all. I can connect idle for quite some time for
> example. Its quite possible that there is another delay/lag somewhere
> causing the connection to be idle in the first place - but with 1.6.3
> this would not have surfaced for example as a server error, because
> there was no idle handling.
>
> ken.
>
> On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
>  wrote:
>> Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
>> The template is only 20K, so large here is probably somewhat relative.
>>
>> Any other thoughts?
>>
>> Just for reference, I'm running the same version of Java as Sergey:
>> java version "1.7.0_55"
>> OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
>> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>>
>>
>>
>> On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:
>>>
>>> Catalogue size might be a factor, as templates get stored in the
>>> catalogue.
>>>
>>> On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
>>>  wrote:
>>> > I encountered this same issue yesterday, and unfortunately haven't found
>>> > a
>>> > fix either.
>>> >
>>> > The error seems to be happening whenever I use the php::fpm::conf
>>> > resource
>>> > (with ensure => present) from https://forge.puppetlabs.com/thias/php.
>>> > Removing that resource, or setting ensure to abset makes everything work
>>> > fine. That resource is essentially only creating a file resource from a
>>> > large template
>>> > (https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
>>> >
>>> > I tried setting max-threads to 200 as well without any luck.
>>> >
>>> > On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
>>> >>
>>> >> Unfortunately setting max-threads to 200 did not help.
>>> >>
>>> >> # java -version
>>> >> java version "1.7.0_55"
>>> >> OpenJDK Runtime Environment (IcedTea 2.4.7)
>>> >> (7u55-2.4.7-1ubuntu1~0.12.04.2)
>>> >> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>>> >>
>>> >> # dpkg -l |grep -i java
>>> >> ii  ca-certificates-java 20110912ubuntu6
>>> >> Common CA certificates (JKS keystore)
>>> >> ii  java-common  0.43ubuntu2
>>> >> Base of all Java packages
>>> >> ii  libjs-jquery 1.7.1-1ubuntu1
>>> >> JavaScript library for dynamic web applications
>>> >> ii  openjdk-7-jre-headless   7u55-2.4.7-1ubuntu1~0.12.04.2
>>> >> OpenJDK Java runtime, using Hotspot JIT (headless)
>>> >> ii  tzdata-java  2014c-0ubuntu0.12.04
>>> >> time zone and daylight-saving time data for use by java runtimes
>>> >>
>>> >>
>>> >> This is a fresh output in logs:
>>> >>
>>> >> 2014-05-20 15:21:52,331 INFO  [p.t.s.w.jetty9-service] Initializing web
>>> >> server.
>>> >> 2014-05-20 15:21:52,403 INFO  [p.t.s.w.jetty9-service] Starting web
>>> >> server.
>>> >> 2014-05-20 15:21:52,406 INFO  [o.e.j.s.Server] jetty-9.1.z-SNAPSHOT
>>> >> 2014-05-20 15:21:52,436 INFO  [o.e.j.s.ServerConnector] Started
>>> >> ServerConnector@2557ce03{HTTP/1.1}{localhost:8080}
>>> >> 2014-05-20 15:21:52,504 INFO  [o.e.j.s.ServerConnector] Started
>>> >> ServerConnector@253e73c6{SSL-HTTP/1.1}{puppet.site:8081}
>>> >>
>>> >> 2014-05-20 15:21:52,563 INFO  [c.p.p.c.services] PuppetDB version 2.0.0
>>> >> 2014-05-20 15:21:52,704 INFO  [c.p.p.c.services] Starting broker
>>> >> 2014-05-20 15:21:53,581 WARN  [o.a.a.b.BrokerService] Store limit is
>>> >> 10 mb, whilst the data directory:
>>> >> /var/lib/puppetdb/mq/localhost/KahaDB
>>> >> only has 63697 mb of usable space
>>> >> 2014-05-20 15:21:53,582 

Re: [Puppet Users] Puppet Resources overridden using Hiera

[Doug Forster]

Try getting your user list from hiera. Then it will easily be overridden on
a server basis.

class company::sshkeys ( users, ) {

  users.each |$my_user| {
user {  $my_user:
  ensure  => present,
  gid => "company",
  home=> "/home/${my_user}",
  managehome => true,
  shell => "/bin/bash",
  require => Group["company"]
}
  }
}



On Wed, May 21, 2014 at 11:21 AM, Danny Roberts <
dannyroberts.perso...@googlemail.com> wrote:

> I currently have a custom module that applies our companies' standard
> server config across all servers using Hiera. This includes a class called
> company::sshkeys that has various 'user' resource types (the standard
> puppet type) defined for all of our admins, for example:
>
> class company::sshkeys {
>
>   user {  "jane.doe":
> ensure  => present,
> gid => "company",
> home=> "/home/jane.doe",
> managehome => true,
> shell => "/bin/bash",
> require => Group["company"]
> }
>
> }
>
> This is a slight simplification as the same class also includes our SSH
> public keys hence the name.
>
> I now find myself in the situation where I need to deny access to certain
> admins on a single server. We use Hiera in our set-up as much as possible
> and I would like to use Hiera to in the case of a single server tell Puppet
> to not create certain user accounts. I have tried many ways to do this but
> I am unsure on how to call the base resource types even though they are
> embedded in a custom class or even if such a thing is possible.
>
> Any thoughts on the cleanest way to exclude certain users from getting an
> account?
>
> --
> 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/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOwhAcpHVbBHBB6N_rzCo3GFBed6kY6%2BBsUJt8xv4nWhiwSqog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Resources overridden using Hiera

[Danny Roberts]

For some reason my Puppet install doesn't like that:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Syntax error at 'users'; expected ')' at 
/etc/puppet/modules/company/manifests/sshkeys.pp:1 on node puppetmaster
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

On Wednesday, 21 May 2014 18:44:00 UTC+1, Doug_F wrote:
>
> Try getting your user list from hiera. Then it will easily be overridden 
> on a server basis. 
>
> class company::sshkeys ( users, ) {
>   
>   users.each |$my_user| {
> user {  $my_user:
>   ensure  => present,
>   gid => "company",
>   home=> "/home/${my_user}",
>   managehome => true,
>   shell => "/bin/bash",
>   require => Group["company"]
> }
>   }
> }
>
>
>
> On Wed, May 21, 2014 at 11:21 AM, Danny Roberts <
> dannyrober...@googlemail.com > wrote:
>
>> I currently have a custom module that applies our companies' standard 
>> server config across all servers using Hiera. This includes a class called 
>> company::sshkeys that has various 'user' resource types (the standard 
>> puppet type) defined for all of our admins, for example:
>>
>> class company::sshkeys {
>>
>>   user {  "jane.doe":
>> ensure  => present,
>> gid => "company",
>> home=> "/home/jane.doe",
>> managehome => true,
>> shell => "/bin/bash",
>> require => Group["company"]
>> }
>>
>> }
>>
>> This is a slight simplification as the same class also includes our SSH 
>> public keys hence the name.
>>
>> I now find myself in the situation where I need to deny access to certain 
>> admins on a single server. We use Hiera in our set-up as much as possible 
>> and I would like to use Hiera to in the case of a single server tell Puppet 
>> to not create certain user accounts. I have tried many ways to do this but 
>> I am unsure on how to call the base resource types even though they are 
>> embedded in a custom class or even if such a thing is possible.
>>
>> Any thoughts on the cleanest way to exclude certain users from getting an 
>> account?
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/2cd3f157-32d3-453e-9a5c-66a1c0ed5a86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases

[Robin Bowes]

I thought hiera always returns strings? ie. $myvar = hiera('testvalue')
should return a string, and validate_re( $myvar, '[0-9]+' ) should work
just fine?

Regardless, this is inconsistent:

OK:
   $var = 1000
   validate_re( $var, '[0-9+]' )

FAIL:
   $var2 = 2000 + 1
   validate_re( $var2, '[0-9+]' )

In the first case, the number is cast as a string. In the second, it is not.

The inconsistency makes this a bug, IMHO.

R.


On 21 May 2014 18:19, Brian Mathis  wrote:

> On Wed, May 21, 2014 at 4:29 AM, Felix Frank <
> felix.fr...@alumni.tu-berlin.de> wrote:
>
>> On 05/20/2014 07:16 PM, Brian Mathis wrote:
>> > This is a bug in validate_re(), even though there is a workaround.
>>
>> Arguably so.
>>
>> One could also argue, on the other hand, that regular expressions are
>> matched by *strings* and nothing else. Sure, we've been spoiled by bash
>> and perl which don't give damn and implicitly convert to string every
>> chance they get. But that isn't a universal truth. Point in fact
>>
>> irb(main):001:0> puts "it works!" if 5 =~ /[0-9]+/
>> => nil
>>
>> I agree that it *is* inconvenient to check for two cases "is numeric" or
>> "contains a number" when logically the former implies the latter. I also
>> think that implicit string conversion would be a beneficial feature for
>> validate_re. But it is not necessarily a bug.
>>
>> Cheers,
>> Felix
>>
>
>
> If validate_re() is only effective on strings, then, in a dynamically
> typed language such as ruby/puppet, it better make sure it's casting to a
> string inside the function.  Forcing the use of quotes is a workaround for
> something that it should be doing and creates inconsistency in the
> interface.  Forcing the user to be aware of the internals of the function
> in order to use it defeats the point of using functions.
>
> One of the big problems here is that sometimes it works and sometimes it
> doesn't for the same data, depending on where you got it and what you did
> with it, which is clearly a bug.  I'm not sure how else you can define a
> bug other than "actual behavior does not match expected behavior", when the
> expectation is merely that the function performs in a predictable way.
>
>
> ❧ Brian Mathis
> @orev
>
>
>  --
> 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/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJGKfwCBtVtBtUezvzy42vuXas%2BWFs1W9jkC_VeLXo3GSZoY1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Resources overridden using Hiera

[Doug Forster]

My apology the .each functionality is only available if parser=future.
http://docs.puppetlabs.com/puppet/latest/reference/experiments_future.html


On Wed, May 21, 2014 at 12:58 PM, Danny Roberts <
dannyroberts.perso...@googlemail.com> wrote:

> For some reason my Puppet install doesn't like that:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Syntax error at 'users'; expected ')' at
> /etc/puppet/modules/company/manifests/sshkeys.pp:1 on node puppetmaster
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> On Wednesday, 21 May 2014 18:44:00 UTC+1, Doug_F wrote:
>>
>> Try getting your user list from hiera. Then it will easily be overridden
>> on a server basis.
>>
>> class company::sshkeys ( users, ) {
>>
>>   users.each |$my_user| {
>> user {  $my_user:
>>   ensure  => present,
>>   gid => "company",
>>   home=> "/home/${my_user}",
>>   managehome => true,
>>   shell => "/bin/bash",
>>   require => Group["company"]
>> }
>>   }
>> }
>>
>>
>>
>> On Wed, May 21, 2014 at 11:21 AM, Danny Roberts > googlemail.com> wrote:
>>
>>> I currently have a custom module that applies our companies' standard
>>> server config across all servers using Hiera. This includes a class called
>>> company::sshkeys that has various 'user' resource types (the standard
>>> puppet type) defined for all of our admins, for example:
>>>
>>> class company::sshkeys {
>>>
>>>   user {  "jane.doe":
>>> ensure  => present,
>>> gid => "company",
>>> home=> "/home/jane.doe",
>>> managehome => true,
>>> shell => "/bin/bash",
>>> require => Group["company"]
>>> }
>>>
>>> }
>>>
>>> This is a slight simplification as the same class also includes our SSH
>>> public keys hence the name.
>>>
>>> I now find myself in the situation where I need to deny access to
>>> certain admins on a single server. We use Hiera in our set-up as much as
>>> possible and I would like to use Hiera to in the case of a single server
>>> tell Puppet to not create certain user accounts. I have tried many ways to
>>> do this but I am unsure on how to call the base resource types even though
>>> they are embedded in a custom class or even if such a thing is possible.
>>>
>>> Any thoughts on the cleanest way to exclude certain users from getting
>>> an account?
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/puppet-users/5d0c1ae8-4c26-4135-b7b0-1146d97c9e53%
>>> 40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> 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/2cd3f157-32d3-453e-9a5c-66a1c0ed5a86%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOwhAcrTVZGeQA_HuzxW6MHrxJdVk82ES0Jmwt-X%2BGzdRjBTYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms

[Ken Barber]

Phil and I have been conversing offline ... we found that downgrading
the terminus to 1.6.3 (not PuppetDB) fixes the issue. So far we can
see that a submission occurs but the server does not respond. This is
synonymous with a bad Content-Length, and certainly I'm able to
replicate this with some basic tests ... but we're still looking for
the ultimate cause of this.

For now can everyone who is seeing this issue, try downgrading their
puppetdb-terminus package to 1.6.3, and see if it solves it?

ken.

On Wed, May 21, 2014 at 6:41 PM, Ken Barber  wrote:
> Phil,
>
> Do you happen to have a tcpdump I can look at, one where this problem
> is replicated? I know its SSL - but I'm primarily interested in seeing
> when (and _IF_) the network connection goes idle - so packet timing is
> more important to me then content. I'm trying to prove/disprove that
> idletimeout is doing the correct thing here or not. It could be that
> the idling is caused by something else, and the timeout is valid - or
> it could be that the idletimeout is not actually paying attention to
> traffic (which I can't prove locally at least for cleartext - it seems
> fine).
>
> There is also a chance the idling could be after traffic is submitted,
> which would make things even more interesting. Either way I'd like
> some external confirmation of this reported 'idling' and the best way
> is probably via tcpdump's. If we can prove the idle timeout is correct
> in its behaviour, we can stop looking at Jetty as the cause, which
> helps us a lot.
>
> If you want to chat I'm on Freenode in #puppet (ken_barber).
>
> My colleague in the meantime is trying to upgrade us to Jetty 9.1.5
> (from 9.1.0), its a non-trivial upgrade though, which sucks when under
> duress. We're also looking at introducing the idle-timeout setting so
> we can play with that also, potentially as a work-around for now.
>
> ken.
>
> On Wed, May 21, 2014 at 5:29 PM, Ken Barber  wrote:
>> So one thing I'm sure about - is that there was no idle timeout
>> defined in 1.6.3 at all. I can connect idle for quite some time for
>> example. Its quite possible that there is another delay/lag somewhere
>> causing the connection to be idle in the first place - but with 1.6.3
>> this would not have surfaced for example as a server error, because
>> there was no idle handling.
>>
>> ken.
>>
>> On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
>>  wrote:
>>> Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
>>> The template is only 20K, so large here is probably somewhat relative.
>>>
>>> Any other thoughts?
>>>
>>> Just for reference, I'm running the same version of Java as Sergey:
>>> java version "1.7.0_55"
>>> OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
>>> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>>>
>>>
>>>
>>> On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:

 Catalogue size might be a factor, as templates get stored in the
 catalogue.

 On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
  wrote:
 > I encountered this same issue yesterday, and unfortunately haven't found
 > a
 > fix either.
 >
 > The error seems to be happening whenever I use the php::fpm::conf
 > resource
 > (with ensure => present) from https://forge.puppetlabs.com/thias/php.
 > Removing that resource, or setting ensure to abset makes everything work
 > fine. That resource is essentially only creating a file resource from a
 > large template
 > (https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
 >
 > I tried setting max-threads to 200 as well without any luck.
 >
 > On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
 >>
 >> Unfortunately setting max-threads to 200 did not help.
 >>
 >> # java -version
 >> java version "1.7.0_55"
 >> OpenJDK Runtime Environment (IcedTea 2.4.7)
 >> (7u55-2.4.7-1ubuntu1~0.12.04.2)
 >> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
 >>
 >> # dpkg -l |grep -i java
 >> ii  ca-certificates-java 20110912ubuntu6
 >> Common CA certificates (JKS keystore)
 >> ii  java-common  0.43ubuntu2
 >> Base of all Java packages
 >> ii  libjs-jquery 1.7.1-1ubuntu1
 >> JavaScript library for dynamic web applications
 >> ii  openjdk-7-jre-headless   7u55-2.4.7-1ubuntu1~0.12.04.2
 >> OpenJDK Java runtime, using Hotspot JIT (headless)
 >> ii  tzdata-java  2014c-0ubuntu0.12.04
 >> time zone and daylight-saving time data for use by java runtimes
 >>
 >>
 >> This is a fresh output in logs:
 >>
 >> 2014-05-20 15:21:52,331 INFO  [p.t.s.w.jetty9-service] Initializing web
 >> server.
 >> 2014-05-20 15:21:52,403 INFO  [p.t.s.w.jetty9-service] Starting web
 >> server.
 >> 2014-05-20 15:21:52,406 INFO  [o.e.j.s.Serv

Re: [Puppet Users] Puppet Resources overridden using Hiera

[jcbollinger]

On Wednesday, May 21, 2014 1:58:22 PM UTC-5, Danny Roberts wrote:
>
> For some reason my Puppet install doesn't like that:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Syntax error at 'users'; expected ')' at 
> /etc/puppet/modules/company/manifests/sshkeys.pp:1 on node puppetmaster
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
>
As Doug acknowledged, that requires turning on the future parser, which PL 
does not recommend for production systems.  But no sweat, you can do this 
with the conventional parser almost as easily.  You need to grease the 
wheels with a defined type:

define company::user ($ensure = 'present') {
  user { $title:
ensure  => $ensure,
gid => "company",
home=> "/home/${title}",
managehome => true,
shell => "/bin/bash",
require => Group["company"]
  }
}

Then you can do this:

class company::sshkeys ( users, ) {
  company::user { $users: }
}


That's as far as your example suggested you wanted to go, but do note that 
it does nothing to remove previously configured users that you no longer 
want.  If that's a concern to you then you could consider purging unmanaged 
users via a Resources meta-resource.


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/5f9a945a-8473-490c-9166-38163c561e17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] using storeconfigs and exported resources

[Ritesh Nanda]

Hello ,

I am designing a multi-node deployment env with Puppet. Scenario i have is 
once one machine is created   it will have its hostname allocated 
dynamically , that hostname has to be used by another machine when it runs 
it manifest on it . 
I can get that fqdn of that machine save it in puppetdb and ask another 
machine to get that hostname using exported resource Is that correct?

Another scenerio in case simultaneously two users runs that module , first 
machine save its hostname , same time again that module is intiated by 
another user , now the latest machine would overwrite the entry in puppetdb.

What would be the better way of doing that.

Regards,
Ritesh


-- 
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/9cbc3680-06bf-4975-ace6-8cacd8add57a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: On code organization and the deprecation of include

[jcbollinger]

On Wednesday, May 21, 2014 10:45:03 AM UTC-5, Andre Nathan wrote:
 

> what can I do about the nodes? The new feature of setting the manifest to 
> a directory does not support subdirectories. Will I be forced to have all 
> my nodes in the same directory and then rely on file names for 
> organization? This is far from optimal in my opinion. What other 
> alternatives do I have? If at all possible, I'd like to avoid using ENCs 
> and keep using puppet files for node definitions.
>
>

You can continue to use import for the time being, as deprecation is not 
the same as deletion.  Meanwhile, you can file a feature request for 
recursive traversal of the manifest directory, or for Puppet to support 
multiple manifest directories for a single environment.

Alternatively, you can coalesce each of your nodes/ subdirectories into a 
single file in the main manifest directory (e.g. webserver.pp containing 
your webserver base node plus all of your webN nodes).  That will leave you 
with a logical organization pretty similar to what you have now, and it 
won't clash with your local classes because you'll be moving those to 
modules (where really they should have been already).

Or you could move away from node blocks toward node classes, which would 
then be organized in a module instead of in your manifest directory.  There 
would be no particular reason to have any node blocks at all in that case; 
you could instead assign node classes via a top-level case statement or via 
hiera (or, indeed, via a simple ENC).


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/33d46124-8b19-457a-9191-1097d58e616a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] On code organization and the deprecation of include

[jcbollinger]

On Wednesday, May 21, 2014 11:44:43 AM UTC-5, Andre Nathan wrote:
>
> On Wednesday, May 21, 2014 1:14:31 PM UTC-3, Garrett Honeycutt wrote:
>  
>
>> Your usage of a base node that other nodes inherit is an anti-pattern 
>> though and will cause you grief as you grow.
>
>
> Why is it an anti-pattern? Isn't variable inheritance supported? Why can't 
> I organize my nodes in sub-directories? It's something simple that greatly 
> enhances code organization.
>
>

Limited node inheritance is OK if you really understand what you're doing.  
Most people don't: node inheritance doesn't work the way they expect.  The 
OO meaning of "inheritance" leads them in the wrong direction.

Multiple levels of node inheritance are a particularly precarious: in 
addition to inheritance likely not working as you expect or want, a node 
inheritance hierarchy locks you into a single principle node taxonomy.  Few 
real sites are well modeled by such a regime.


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/14d69a52-b2dc-40cf-b291-5a3b90adae75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb 2 : Idle timeout expired: 30000/30000 ms

[Sergey Arlashin]

Yesterday I downgraded both puppet to 3.5.1 and pupetdb to 1.6.3, and the 
problem disappeared. Unfortunately this is production infrastructure and I 
don't have an ability to test it further :( 


On May 21, 2014, at 11:54 PM, Ken Barber  wrote:

> Phil and I have been conversing offline ... we found that downgrading
> the terminus to 1.6.3 (not PuppetDB) fixes the issue. So far we can
> see that a submission occurs but the server does not respond. This is
> synonymous with a bad Content-Length, and certainly I'm able to
> replicate this with some basic tests ... but we're still looking for
> the ultimate cause of this.
> 
> For now can everyone who is seeing this issue, try downgrading their
> puppetdb-terminus package to 1.6.3, and see if it solves it?
> 
> ken.
> 
> On Wed, May 21, 2014 at 6:41 PM, Ken Barber  wrote:
>> Phil,
>> 
>> Do you happen to have a tcpdump I can look at, one where this problem
>> is replicated? I know its SSL - but I'm primarily interested in seeing
>> when (and _IF_) the network connection goes idle - so packet timing is
>> more important to me then content. I'm trying to prove/disprove that
>> idletimeout is doing the correct thing here or not. It could be that
>> the idling is caused by something else, and the timeout is valid - or
>> it could be that the idletimeout is not actually paying attention to
>> traffic (which I can't prove locally at least for cleartext - it seems
>> fine).
>> 
>> There is also a chance the idling could be after traffic is submitted,
>> which would make things even more interesting. Either way I'd like
>> some external confirmation of this reported 'idling' and the best way
>> is probably via tcpdump's. If we can prove the idle timeout is correct
>> in its behaviour, we can stop looking at Jetty as the cause, which
>> helps us a lot.
>> 
>> If you want to chat I'm on Freenode in #puppet (ken_barber).
>> 
>> My colleague in the meantime is trying to upgrade us to Jetty 9.1.5
>> (from 9.1.0), its a non-trivial upgrade though, which sucks when under
>> duress. We're also looking at introducing the idle-timeout setting so
>> we can play with that also, potentially as a work-around for now.
>> 
>> ken.
>> 
>> On Wed, May 21, 2014 at 5:29 PM, Ken Barber  wrote:
>>> So one thing I'm sure about - is that there was no idle timeout
>>> defined in 1.6.3 at all. I can connect idle for quite some time for
>>> example. Its quite possible that there is another delay/lag somewhere
>>> causing the connection to be idle in the first place - but with 1.6.3
>>> this would not have surfaced for example as a server error, because
>>> there was no idle handling.
>>> 
>>> ken.
>>> 
>>> On Wed, May 21, 2014 at 5:01 PM, Phil Fenstermacher
>>>  wrote:
 Running tcpdump filtering on port 8081 renders a pcap file of about ~350K.
 The template is only 20K, so large here is probably somewhat relative.
 
 Any other thoughts?
 
 Just for reference, I'm running the same version of Java as Sergey:
 java version "1.7.0_55"
 OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
 OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
 
 
 
 On Wednesday, May 21, 2014 9:53:42 AM UTC-4, Ken Barber wrote:
> 
> Catalogue size might be a factor, as templates get stored in the
> catalogue.
> 
> On Wed, May 21, 2014 at 2:45 PM, Phil Fenstermacher
>  wrote:
>> I encountered this same issue yesterday, and unfortunately haven't found
>> a
>> fix either.
>> 
>> The error seems to be happening whenever I use the php::fpm::conf
>> resource
>> (with ensure => present) from https://forge.puppetlabs.com/thias/php.
>> Removing that resource, or setting ensure to abset makes everything work
>> fine. That resource is essentially only creating a file resource from a
>> large template
>> (https://github.com/thias/puppet-php/blob/master/manifests/fpm/conf.pp).
>> 
>> I tried setting max-threads to 200 as well without any luck.
>> 
>> On Tuesday, May 20, 2014 11:27:05 AM UTC-4, Sergey Arlashin wrote:
>>> 
>>> Unfortunately setting max-threads to 200 did not help.
>>> 
>>> # java -version
>>> java version "1.7.0_55"
>>> OpenJDK Runtime Environment (IcedTea 2.4.7)
>>> (7u55-2.4.7-1ubuntu1~0.12.04.2)
>>> OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
>>> 
>>> # dpkg -l |grep -i java
>>> ii  ca-certificates-java 20110912ubuntu6
>>> Common CA certificates (JKS keystore)
>>> ii  java-common  0.43ubuntu2
>>> Base of all Java packages
>>> ii  libjs-jquery 1.7.1-1ubuntu1
>>> JavaScript library for dynamic web applications
>>> ii  openjdk-7-jre-headless   7u55-2.4.7-1ubuntu1~0.12.04.2
>>> OpenJDK Java runtime, using Hotspot JIT (headless)
>>> ii  tzdata-java  2014c-0ubuntu0.12.04
>>> time zone and 

[Puppet Users] Re: Can't get puppetmaster working with passenger

[suman Gtm]

Hey John 
Did you get into bottom of this?

I am having similar issue, works fine with webrick...running with passenger 
will throw Error: Could not retrieve catalog from remote server: Error 400 
on SERVER: Could not find class errror.

Thanks
Suman

On Tuesday, 8 April 2014 07:29:24 UTC+10, John Pyeatt wrote:
>
> Tried to convert from webrick to passenger today. Failed.
>
> When I run
>
> puppet agent -tv
>
> I get two things that are troubling.
>
> 1)
> I get this message:
> Notice: with older puppet master. To remove this notice, please upgrade 
> your master(s) 
> Notice: to Puppet 3.3 or newer.
>
> Even though in my webrick days we are running puppet 3.4 on the 
> puppetmaster.
>
> 2)
> I also get these messages.
>
> Warning: Local environment: "dev" doesn't match server specified node 
> environment "production", switching agent to "production".
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Could not find class bastion for 10.0.11.83 on node 
>
> My /etc/puppet/puppet.conf is configured correctly because it was working 
> in the webbrick world. Additionally, I know it is getting some information 
> from my  puppet.conf file because it is correctly executing my ENC script 
> defined in external_nodes=
>
> It just doesn't seem to be recognizing my extra modulepath= and manifest= 
> values for my [dev] stanza. I've checked file/directory permissions and the 
> apache user www-data has read permissions to those directories.
>
> Any ideas???
> -- 
> John Pyeatt
> Singlewire Software, LLC
> www.singlewire.com
> --
> 608.661.1184
> john@singlewire.com  
>

-- 
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/383b2d3c-7f70-4197-b8bb-f77f7d27c730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.