date:20140520

[Puppet Users] Retrieve resource names of a given type without using the filesystem

2014-05-20 Thread Bruno Bieth


I'd like to do something like this


define mytype() {}

define delete_mytype() {}

mytype { 'a': }
mytype { 'b': }
mytype { 'c': }

$existing_mytypes = # something from facter

# but this doesn't work
$wanted_mytypes = Mytype <||>
  
Mytype<||> -> Delete_mytype<||>

delete_mytype { diff( $existing_mytypes, $wanted_mytypes ) }


I believe I could do something along those lines but it creates as many 
files as mytype invocation :


defined mytype() {
   # persist $name in the filesystem
}

class prepare_mytypes {
  # cleanup files created by previous invocation of mytype
}

Class['prepare_mytypes'] ->
  Mytype<||> -> 
Class['remove_old_mytypes']

class remove_old_mytypes {

  # look for files created by mytype
  # perform the same diff as explained above
}


Any idea?

-- 
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/82f28275-7bc8-4a9e-ac46-84dea0ffe26e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet 3.6.0 'issues'

2014-05-20 Thread Stefan Heijmans

Hi Josh,
 
Thanks for your email.
 
>>but isn't the facts loaded from both modulepath and var lib dir just a 
consequence of having pluginsync'd on the master?
I mentioned it, as this behaviour didn't happen with 3.4.3.
 
I'll wait for the 3.6.1 release before testing any further.
 
Stefan
 

-- 
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/d35a4c55-d780-4551-9475-24c47b986366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Yumrepo resource flapping

2014-05-20 Thread DjE


Hi all,

We find that the yumrepo resource is flapping on RedHat 6 Enterprise 
with the redhat.repo file since Puppet 3.4.x version (due to a change 
about attribute content control)


We have updated with the latest Puppet 3.6 server and agent, because we 
saw this commit : 
https://github.com/puppetlabs/puppet/commit/9c25f75febe4df7d900e553824c9379cb7367c76, 
but the resource continues to flap.


The resource we want to manage : Yumrepo[rhel-6-server-optional-rpms]
The Puppet change : enabled changed ' 1' to '1'

RedHat want : *"enabled= 1"*
Puppet want : "enable=1"

As we can see, there is a white space on original state (RedHat 
generated file).


The change occurs every 4 hour (with 30 minutes runtime interval agent), 
i did not looking for the process which generate the redhat.repo file.


rhsm (/etc/rhsm/rhsm.conf) manage the yum repo file :

# Manage generation of yum repositories for subscribed content:
manage_repos = 1

[rhsmcertd]
# Frequency of certificate refresh (in minutes):
certFrequency = 240

The certFrequency seems to match with the change which occurs every 4 
hours, i did not test it.


Djé

--
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/537B149B.6050009%40nosbox.net.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] ${name} returns class name instead of resource namevar

2014-05-20 Thread Francis Pereira

When using a custom resource to deploy java $name is not the name of the
resource but the name of the class in the below mentioned example

 java::setup { "${myapplication::params::app_username}-jdk_7u51":
...
cachedir  => "/var/lib/puppet/file_cache/${name}-working",

  }

Shouldn't $name = ${myapplication::params::app_username}-jdk_7u51 ?


Francis Pereira

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

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

2014-05-20 Thread Boyan Tabakov

Hi,

On Mon May 19 16:39:25 2014, jcbollinger wrote:
>
>
> On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote:
>
> Hi,
>
> The variable I want to access is not defined in a module/class.
> It's the
> globally defined $::environment. Since facts are also exposed as
> global
> variables, the server-defined $::environment gets overridden when
> there's a fact with the same name.
>
> So any ideas on how to avoid that? As it is, it looks like a module
> can't reliably detect environment, because a (potentially malicious)
> client can send an 'environment' fact with arbitrary value.
>
>
>
> If you do not trust your nodes to specify their own environment, then
> you should set up an ENC that specifies the correct environment for
> each node to Puppet.  That can be the only thing it does.  The
> environment specified by an ENC will be used instead of the one (if
> any) specified by the agent.
>
> More generally, you should avoid declaring global variables in your
> Puppet manifests, and especially you should avoid declaring globals
> that collide with facts or with variables provided by the master
> itself.  Such collisions /should/ cause catalog compilation to fail
> with an error message, but conceivably could fail silently instead.
> Puppet variables cannot be changed once set.

That is exactly what I try to do.

Still, this is what happens (puppetmaster 3.5.1, puppet agent 3.4.3):

Agent's configured environment is "agent_env". Agent also has a fact 
called "environment" with value "agent_env_fact". There is ENC, 
enforcing environment for that node to be "enc_env". The node's catalog 
gets compiled in the "enc_env", as it should. For example the node 
reports:

Local environment: "agent_env" doesn't match server specified node 
environment "enc_env", switching agent to "enc_env".

However if any of the modules use the $::environment variable, it's 
value is "agent_env_fact". So the agent's fact masks the real value and 
any modules/manifests that make decisions based on the environment can 
be fooled.

This means that any conditionals that are based on $::environment are 
not reliable. It would be totally fine, if that's documented and people 
are discouraged to use the $::environment variable, but I could not 
find anything like that. So, my original question still stands: is 
there a reliable way to find out the current node's environment in a 
module/manifest?

Cheers,
Boyan

signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Service stuck after updating puppet on Windows Server 2003

2014-05-20 Thread cko

Any idea?

On Saturday, May 10, 2014 12:22:46 PM UTC+2, cko wrote:
>
> After the puppet run the agent service is basically stopped.
>
> Although when i run "sc queryex puppet" the output is "STOP_PENDING" (not 
> stopped but not running either).
>
> So i have to run "taskkill /f /pid 1234" and then start the service again.
>
>
>
> On Friday, May 9, 2014 9:45:35 PM UTC+2, Rob Reynolds wrote:
>>
>> This error is somewhat of a misnomer: "The requested service has already 
>> been started."
>>
>> When you say it gets stuck, what do you mean exactly?
>>
>>
>> On Fri, May 9, 2014 at 8:08 AM, cko  wrote:
>>
>>> Hi,
>>>
>>> I'm using puppet to manage the puppet agent (package, config, service) 
>>> in my Windows Server 2003 boxes.
>>>
>>> Whenever I update the package, the puppet agent service gets stuck 
>>>  (STOP PENDING).
>>>
>>> The report returns:
>>>
>>> *Fri May 09 12:13:51 +0200 2014 
>>> /Stage[main]/puppet_agent::Windows::Service/Service[puppet] (err): Failed 
>>> to call refresh: Cannot start puppet, error was: Execution of 
>>> 'C:/WINDOWS/system32/net.exe start puppet' returned 2: The requested 
>>> service has already been started.*
>>> *More help is available by typing NET HELPMSG 2182.*
>>> *Fri May 09 12:13:51 +0200 2014 
>>> /Stage[main]/puppet_agent::Windows::Service/Service[puppet] (err): Cannot 
>>> start puppet, error was: Execution of 'C:/WINDOWS/system32/net.exe start 
>>> puppet' returned 2: The requested service has already been started.*
>>> *More help is available by typing NET HELPMSG 2182.*
>>>
>>> I use the same manifest for Windows Server 2008 nodes without runnning 
>>> into this problem.
>>>
>>> My manifest looks like this:
>>>
>>>
>>> *package { 'Puppet':*
>>> *   ensure  => "3.5.1",*
>>> *   source  => 
>>> "share\\puppet_agent\\windows\\puppet-3.5.1.msi",*
>>> *   provider=> windows,*
>>> *   install_options => { 'INSTALLDIR' => 'C:\puppet' } *
>>> *}*
>>>
>>> *file { 'C:\Documents and Settings\All Users\Application 
>>> Data\PuppetLabs\puppet\etc\puppet.conf':*
>>> *   content => template("base_puppet_agent/windows/puppet_windows.erb"), 
>>>   *
>>> *   notify  => Service['puppet'],*
>>> *   require => Package ['Puppet'],*
>>> *}*
>>>
>>> *service { 'puppet':*
>>> *   ensure   => running,*
>>> *   enable   => true,*
>>> *   require  => Package['Puppet'],*
>>> *}*
>>>
>>>
>>>  -- 
>>> 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/0a9a5b19-b44f-47b2-9749-5bfc38c8404e%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Rob Reynolds
>> Developer, Puppet Labs
>>
>> *Join us at **PuppetConf 2014 **, September 
>> 23-24 in San Francisco*
>> *Register by May 30th to take advantage of the Early Adopter discount 
>>  **—**save $349!*
>>  
>

-- 
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/0e98161c-af86-46d7-b89d-efac6d4a8ea0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Sergey Arlashin

Here is described 
http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html 
how idle timeout for jetty cat be configured . But I don't know how to apply 
this for puppetdb :( 

Does anybody have any ideas ? 



On May 20, 2014, at 9:43 AM, Sergey Arlashin  
wrote:

> 2014-05-20 05:34:36,684 INFO  [c.p.p.command] 
> [e806b0a2-7703-4a4a-8107-65cd2c0db9a8] [replace facts] prod1.site
> 2014-05-20 05:34:44,112 INFO  [c.p.p.command] 
> [e8cb3511-9734-4ba7-b040-96f663404c00] [replace facts] redmine.site
> 2014-05-20 05:34:45,387 INFO  [c.p.p.command] 
> [9026d779-3a43-4c06-a23d-aeefd4eb6e1f] [replace catalog] redmine.site
> 2014-05-20 05:34:47,487 INFO  [c.p.p.command] 
> [1234e95c-e254-4b1d-b46f-8ef5b07e9158] [replace facts] www-node1.site
> 2014-05-20 05:34:48,350 INFO  [c.p.p.command] 
> [56be0dc9-03b9-45b8-8b8a-527f1c25e057] [replace facts] dev01.site
> 2014-05-20 05:34:48,404 INFO  [c.p.p.command] 
> [17474841-6043-46cf-98a1-122f116d5cd6] [replace facts] parser1.site
> 2014-05-20 05:34:48,634 INFO  [c.p.p.command] 
> [44da2889-811f-4e80-8190-ad7313f0ca81] [replace facts] dev02.site
> 2014-05-20 05:34:48,942 INFO  [c.p.p.command] 
> [4080aa24-23c7-4f16-9011-2104a457e201] [replace catalog] www-node1.site
> 2014-05-20 05:34:51,429 INFO  [c.p.p.command] 
> [6b62c283-f306-44e7-8101-4948110e3d78] [replace catalog] dev01.site
> 2014-05-20 05:34:51,437 INFO  [c.p.p.command] 
> [55fb7348-3b36-4c5a-9265-61ca3c1f55c3] [replace catalog] dev02.site
> 2014-05-20 05:34:52,925 INFO  [c.p.p.command] 
> [9ace137e-f708-4656-829a-92de7722b388] [replace facts] lb-node1.site
> 2014-05-20 05:34:55,017 INFO  [c.p.p.command] 
> [0b6e6592-97f2-4b8a-8cc7-6d321793d2ed] [replace catalog] lb-node1.site
> 2014-05-20 05:34:58,285 INFO  [c.p.p.command] 
> [971285dd-b141-4f44-a6d0-375aa3af830a] [replace facts] lb-node2.site
> 2014-05-20 05:34:59,333 INFO  [c.p.p.command] 
> [3977fc34-aa41-43e7-8eb9-ef5398dc3567] [replace facts] www-node2.site
> 2014-05-20 05:35:01,625 INFO  [c.p.p.command] 
> [f095ef50-4b71-41d6-ba83-6dd4a0030fe2] [replace facts] parser2.site
> 2014-05-20 05:35:02,107 INFO  [c.p.p.command] 
> [539a78de-1743-4135-adeb-c5ed3b43cc24] [replace catalog] lb-node2.site
> 2014-05-20 05:35:02,379 INFO  [c.p.p.command] 
> [f4b7fc4d-cccd-4fb9-881e-da4007d57f6e] [replace facts] monitor.site
> 2014-05-20 05:35:03,945 INFO  [c.p.p.command] 
> [f49a6fcd-ca63-49eb-bbec-7712ba590675] [replace catalog] www-node2.site
> 2014-05-20 05:35:05,350 INFO  [c.p.p.command] 
> [6913aceb-0d60-4701-9d31-d84af8f92374] [replace facts] db-node1.site
> 2014-05-20 05:35:05,587 INFO  [c.p.p.command] 
> [bd9796df-e989-4788-addc-d31f2d2dda3a] [replace catalog] monitor.site
> 2014-05-20 05:35:05,848 INFO  [c.p.p.command] 
> [f9215b15-f646-403a-b4d3-21fd532e1c06] [replace facts] puppet.site
> 2014-05-20 05:35:05,871 INFO  [c.p.p.command] 
> [7820d545-1c5f-4b0f-a2e8-0dcbc12d4571] [replace facts] db-node2.site
> 2014-05-20 05:35:07,642 WARN  [o.e.j.s.HttpChannel] 
> /v3/commands?checksum=e51aa526e2236306cff22ef33c8cb4467166f9c0
> java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout 
> expired: 30002/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$verify_content_type$fn__10379.invoke(middleware.clj:128)
>  ~[na:na]
>   at com.puppetlabs.puppetdb.http.v3$v3_app$fn__11827.invoke(v3.clj:23) 
> ~[na:na]
>   at com.puppetlabs.puppetdb.http.v3$v3_app.invoke(v3.clj:21) ~[na:na]
>   at 
> com.puppetlabs.puppetdb.http.server$routes$fn__12370.invoke(server.clj:47) 
> ~[na:na]
>   at 
> net.cgrand.moustache$alter_request$fn__10771.invoke(moustache.clj:54) ~[na:na]
>   at com.puppetlabs.puppet

Re: [Puppet Users] ${name} returns class name instead of resource namevar

2014-05-20 Thread José Luis Ledesma

No, it is the current $name, not the resource one.

Regards,
El 20/05/2014 12:36, "Francis Pereira" 
escribió:

> When using a custom resource to deploy java $name is not the name of the
> resource but the name of the class in the below mentioned example
>
>  java::setup { "${myapplication::params::app_username}-jdk_7u51":
> ...
> cachedir  => "/var/lib/puppet/file_cache/${name}-working",
>
>   }
>
> Shouldn't $name = ${myapplication::params::app_username}-jdk_7u51 ?
>
>
> Francis Pereira
>
>  --
> 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/CABCZsNFgJ6GbK0UAmVdxhONb9D1rde1pnFXz-tjZmBj1BBMg9w%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/CAF_B3dcMF0u%2BXr%2BcACZPhZmXdiTaTuXAkS7_yaQ01X_TmOWp9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread José Luis Ledesma

But, who can run puppet?

I mean, most puppet configurations needs root, so if someone malicious is a
root which is the point of being able to cheat the environment? He can do
whatever wants.

Regards,
Hi,

On Mon May 19 16:39:25 2014, jcbollinger wrote:
>
>
> On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote:
>
> Hi,
>
> The variable I want to access is not defined in a module/class.
> It's the
> globally defined $::environment. Since facts are also exposed as
> global
> variables, the server-defined $::environment gets overridden when
> there's a fact with the same name.
>
> So any ideas on how to avoid that? As it is, it looks like a module
> can't reliably detect environment, because a (potentially malicious)
> client can send an 'environment' fact with arbitrary value.
>
>
>
> If you do not trust your nodes to specify their own environment, then
> you should set up an ENC that specifies the correct environment for
> each node to Puppet.  That can be the only thing it does.  The
> environment specified by an ENC will be used instead of the one (if
> any) specified by the agent.
>
> More generally, you should avoid declaring global variables in your
> Puppet manifests, and especially you should avoid declaring globals
> that collide with facts or with variables provided by the master
> itself.  Such collisions /should/ cause catalog compilation to fail
> with an error message, but conceivably could fail silently instead.
> Puppet variables cannot be changed once set.

That is exactly what I try to do.

Still, this is what happens (puppetmaster 3.5.1, puppet agent 3.4.3):

Agent's configured environment is "agent_env". Agent also has a fact
called "environment" with value "agent_env_fact". There is ENC,
enforcing environment for that node to be "enc_env". The node's catalog
gets compiled in the "enc_env", as it should. For example the node
reports:

Local environment: "agent_env" doesn't match server specified node
environment "enc_env", switching agent to "enc_env".

However if any of the modules use the $::environment variable, it's
value is "agent_env_fact". So the agent's fact masks the real value and
any modules/manifests that make decisions based on the environment can
be fooled.

This means that any conditionals that are based on $::environment are
not reliable. It would be totally fine, if that's documented and people
are discouraged to use the $::environment variable, but I could not
find anything like that. So, my original question still stands: is
there a reliable way to find out the current node's environment in a
module/manifest?

Cheers,
Boyan

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

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

2014-05-20 Thread Henrik Lindberg


On 2014-20-05 13:02, Boyan Tabakov wrote:

Hi,

On Mon May 19 16:39:25 2014, jcbollinger wrote:



On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote:

 Hi,

 The variable I want to access is not defined in a module/class.
 It's the
 globally defined $::environment. Since facts are also exposed as
 global
 variables, the server-defined $::environment gets overridden when
 there's a fact with the same name.

 So any ideas on how to avoid that? As it is, it looks like a module
 can't reliably detect environment, because a (potentially malicious)
 client can send an 'environment' fact with arbitrary value.



If you do not trust your nodes to specify their own environment, then
you should set up an ENC that specifies the correct environment for
each node to Puppet.  That can be the only thing it does.  The
environment specified by an ENC will be used instead of the one (if
any) specified by the agent.

More generally, you should avoid declaring global variables in your
Puppet manifests, and especially you should avoid declaring globals
that collide with facts or with variables provided by the master
itself.  Such collisions /should/ cause catalog compilation to fail
with an error message, but conceivably could fail silently instead.
Puppet variables cannot be changed once set.


That is exactly what I try to do.

Still, this is what happens (puppetmaster 3.5.1, puppet agent 3.4.3):

Agent's configured environment is "agent_env". Agent also has a fact
called "environment" with value "agent_env_fact". There is ENC,
enforcing environment for that node to be "enc_env". The node's catalog
gets compiled in the "enc_env", as it should. For example the node
reports:

 Local environment: "agent_env" doesn't match server specified node
environment "enc_env", switching agent to "enc_env".

However if any of the modules use the $::environment variable, it's
value is "agent_env_fact". So the agent's fact masks the real value and
any modules/manifests that make decisions based on the environment can
be fooled.

This means that any conditionals that are based on $::environment are
not reliable. It would be totally fine, if that's documented and people
are discouraged to use the $::environment variable, but I could not
find anything like that. So, my original question still stands: is
there a reliable way to find out the current node's environment in a
module/manifest?

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.


Typically, you benefit from setting up special environments when 
developing and testing and it becomes a horrible problem when the 
modules themselves have to be aware of an environment naming scheme.


Or put differently, logic inside your environment should not care what 
the name of the environment is.


- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
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/llfi8f%24e9n%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Apply class fail from hiera

2014-05-20 Thread jcbollinger

On Monday, May 19, 2014 9:18:37 AM UTC-5, mike wrote:
>
> Hi,
> I try configure the NTP Hiera class (
> http://docs.puppetlabs.com/hiera/1/complete_example.html) and run ok and 
> i dont have any errors in my node client. I believe that my error is a some 
> problem with the MySQL configuration Hiera Class (some variable, some 
> params).
>
>

Last try: you are not giving us the information we would need to diagnose 
your unusual problem.  Find out what the master is delivering to the agent, 
that the agent rejects as erroneous.  Also check your master's logs for 
Puppet and whatever container it is running in.  Moreover, turn on debug 
logging at both master and agent so as to glean as much information as 
possible from those logs.

You may be right that the problem is centered around some problem with your 
hiera data, but I don't see anything structurally wrong with what you 
presented, and the error you report is not indicative of an ordinary 
catalog compilation failure.

You could also check the versions of master and agent.  As a rule, the 
agent should not be a later Puppet version than the master is.  With a 
problem along those lines, however, the agent and master usually don't work 
together at all.

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/9400b7d7-c4c3-420e-b7c6-af464e88d53d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Ken Barber

We don't expose the idle timeout parameter for users to modify.

I am curious though, what happens when you increase max-threads in
your jetty.ini to something like 200?

ken.

On Tue, May 20, 2014 at 12:41 PM, Sergey Arlashin
 wrote:
> Here is described
> http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html
> how idle timeout for jetty cat be configured . But I don't know how to apply
> this for puppetdb :(
>
> Does anybody have any ideas ?
>
>
>
> On May 20, 2014, at 9:43 AM, Sergey Arlashin 
> wrote:
>
> 2014-05-20 05:34:36,684 INFO  [c.p.p.command]
> [e806b0a2-7703-4a4a-8107-65cd2c0db9a8] [replace facts] prod1.site
> 2014-05-20 05:34:44,112 INFO  [c.p.p.command]
> [e8cb3511-9734-4ba7-b040-96f663404c00] [replace facts] redmine.site
> 2014-05-20 05:34:45,387 INFO  [c.p.p.command]
> [9026d779-3a43-4c06-a23d-aeefd4eb6e1f] [replace catalog] redmine.site
> 2014-05-20 05:34:47,487 INFO  [c.p.p.command]
> [1234e95c-e254-4b1d-b46f-8ef5b07e9158] [replace facts] www-node1.site
> 2014-05-20 05:34:48,350 INFO  [c.p.p.command]
> [56be0dc9-03b9-45b8-8b8a-527f1c25e057] [replace facts] dev01.site
> 2014-05-20 05:34:48,404 INFO  [c.p.p.command]
> [17474841-6043-46cf-98a1-122f116d5cd6] [replace facts] parser1.site
> 2014-05-20 05:34:48,634 INFO  [c.p.p.command]
> [44da2889-811f-4e80-8190-ad7313f0ca81] [replace facts] dev02.site
> 2014-05-20 05:34:48,942 INFO  [c.p.p.command]
> [4080aa24-23c7-4f16-9011-2104a457e201] [replace catalog] www-node1.site
> 2014-05-20 05:34:51,429 INFO  [c.p.p.command]
> [6b62c283-f306-44e7-8101-4948110e3d78] [replace catalog] dev01.site
> 2014-05-20 05:34:51,437 INFO  [c.p.p.command]
> [55fb7348-3b36-4c5a-9265-61ca3c1f55c3] [replace catalog] dev02.site
> 2014-05-20 05:34:52,925 INFO  [c.p.p.command]
> [9ace137e-f708-4656-829a-92de7722b388] [replace facts] lb-node1.site
> 2014-05-20 05:34:55,017 INFO  [c.p.p.command]
> [0b6e6592-97f2-4b8a-8cc7-6d321793d2ed] [replace catalog] lb-node1.site
> 2014-05-20 05:34:58,285 INFO  [c.p.p.command]
> [971285dd-b141-4f44-a6d0-375aa3af830a] [replace facts] lb-node2.site
> 2014-05-20 05:34:59,333 INFO  [c.p.p.command]
> [3977fc34-aa41-43e7-8eb9-ef5398dc3567] [replace facts] www-node2.site
> 2014-05-20 05:35:01,625 INFO  [c.p.p.command]
> [f095ef50-4b71-41d6-ba83-6dd4a0030fe2] [replace facts] parser2.site
> 2014-05-20 05:35:02,107 INFO  [c.p.p.command]
> [539a78de-1743-4135-adeb-c5ed3b43cc24] [replace catalog] lb-node2.site
> 2014-05-20 05:35:02,379 INFO  [c.p.p.command]
> [f4b7fc4d-cccd-4fb9-881e-da4007d57f6e] [replace facts] monitor.site
> 2014-05-20 05:35:03,945 INFO  [c.p.p.command]
> [f49a6fcd-ca63-49eb-bbec-7712ba590675] [replace catalog] www-node2.site
> 2014-05-20 05:35:05,350 INFO  [c.p.p.command]
> [6913aceb-0d60-4701-9d31-d84af8f92374] [replace facts] db-node1.site
> 2014-05-20 05:35:05,587 INFO  [c.p.p.command]
> [bd9796df-e989-4788-addc-d31f2d2dda3a] [replace catalog] monitor.site
> 2014-05-20 05:35:05,848 INFO  [c.p.p.command]
> [f9215b15-f646-403a-b4d3-21fd532e1c06] [replace facts] puppet.site
> 2014-05-20 05:35:05,871 INFO  [c.p.p.command]
> [7820d545-1c5f-4b0f-a2e8-0dcbc12d4571] [replace facts] db-node2.site
> 2014-05-20 05:35:07,642 WARN  [o.e.j.s.HttpChannel]
> /v3/commands?checksum=e51aa526e2236306cff22ef33c8cb4467166f9c0
> java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout
> expired: 30002/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$verify_content_type$fn__10379.invoke(middleware.clj:128)
> ~[na:na]
> at com.puppetlabs.puppetdb.http.v3$v3_app$fn__11827.invoke(v3.clj:23)
> ~[na:na]
> at com.puppetlabs.puppetdb.http.v3$v3_app.invoke(v3.clj:21) ~[na:na]
> at
> com.puppetlabs.puppetdb.http.server$routes$fn__12370.invoke(server.clj:47)
> ~[na:na]
> at net.cgrand.moustache$alter_request$fn

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

2014-05-20 Thread Ken Barber

Also ... I'd be curious to know what exact version of the JVM you are running.

I'm cautious this is a jetty bug of some kind, perhaps we can ship a
new Jar with a later version of Jetty to you and see if that helps.

ken.

On Tue, May 20, 2014 at 2:03 PM, Ken Barber  wrote:
> We don't expose the idle timeout parameter for users to modify.
>
> I am curious though, what happens when you increase max-threads in
> your jetty.ini to something like 200?
>
> ken.
>
> On Tue, May 20, 2014 at 12:41 PM, Sergey Arlashin
>  wrote:
>> Here is described
>> http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html
>> how idle timeout for jetty cat be configured . But I don't know how to apply
>> this for puppetdb :(
>>
>> Does anybody have any ideas ?
>>
>>
>>
>> On May 20, 2014, at 9:43 AM, Sergey Arlashin 
>> wrote:
>>
>> 2014-05-20 05:34:36,684 INFO  [c.p.p.command]
>> [e806b0a2-7703-4a4a-8107-65cd2c0db9a8] [replace facts] prod1.site
>> 2014-05-20 05:34:44,112 INFO  [c.p.p.command]
>> [e8cb3511-9734-4ba7-b040-96f663404c00] [replace facts] redmine.site
>> 2014-05-20 05:34:45,387 INFO  [c.p.p.command]
>> [9026d779-3a43-4c06-a23d-aeefd4eb6e1f] [replace catalog] redmine.site
>> 2014-05-20 05:34:47,487 INFO  [c.p.p.command]
>> [1234e95c-e254-4b1d-b46f-8ef5b07e9158] [replace facts] www-node1.site
>> 2014-05-20 05:34:48,350 INFO  [c.p.p.command]
>> [56be0dc9-03b9-45b8-8b8a-527f1c25e057] [replace facts] dev01.site
>> 2014-05-20 05:34:48,404 INFO  [c.p.p.command]
>> [17474841-6043-46cf-98a1-122f116d5cd6] [replace facts] parser1.site
>> 2014-05-20 05:34:48,634 INFO  [c.p.p.command]
>> [44da2889-811f-4e80-8190-ad7313f0ca81] [replace facts] dev02.site
>> 2014-05-20 05:34:48,942 INFO  [c.p.p.command]
>> [4080aa24-23c7-4f16-9011-2104a457e201] [replace catalog] www-node1.site
>> 2014-05-20 05:34:51,429 INFO  [c.p.p.command]
>> [6b62c283-f306-44e7-8101-4948110e3d78] [replace catalog] dev01.site
>> 2014-05-20 05:34:51,437 INFO  [c.p.p.command]
>> [55fb7348-3b36-4c5a-9265-61ca3c1f55c3] [replace catalog] dev02.site
>> 2014-05-20 05:34:52,925 INFO  [c.p.p.command]
>> [9ace137e-f708-4656-829a-92de7722b388] [replace facts] lb-node1.site
>> 2014-05-20 05:34:55,017 INFO  [c.p.p.command]
>> [0b6e6592-97f2-4b8a-8cc7-6d321793d2ed] [replace catalog] lb-node1.site
>> 2014-05-20 05:34:58,285 INFO  [c.p.p.command]
>> [971285dd-b141-4f44-a6d0-375aa3af830a] [replace facts] lb-node2.site
>> 2014-05-20 05:34:59,333 INFO  [c.p.p.command]
>> [3977fc34-aa41-43e7-8eb9-ef5398dc3567] [replace facts] www-node2.site
>> 2014-05-20 05:35:01,625 INFO  [c.p.p.command]
>> [f095ef50-4b71-41d6-ba83-6dd4a0030fe2] [replace facts] parser2.site
>> 2014-05-20 05:35:02,107 INFO  [c.p.p.command]
>> [539a78de-1743-4135-adeb-c5ed3b43cc24] [replace catalog] lb-node2.site
>> 2014-05-20 05:35:02,379 INFO  [c.p.p.command]
>> [f4b7fc4d-cccd-4fb9-881e-da4007d57f6e] [replace facts] monitor.site
>> 2014-05-20 05:35:03,945 INFO  [c.p.p.command]
>> [f49a6fcd-ca63-49eb-bbec-7712ba590675] [replace catalog] www-node2.site
>> 2014-05-20 05:35:05,350 INFO  [c.p.p.command]
>> [6913aceb-0d60-4701-9d31-d84af8f92374] [replace facts] db-node1.site
>> 2014-05-20 05:35:05,587 INFO  [c.p.p.command]
>> [bd9796df-e989-4788-addc-d31f2d2dda3a] [replace catalog] monitor.site
>> 2014-05-20 05:35:05,848 INFO  [c.p.p.command]
>> [f9215b15-f646-403a-b4d3-21fd532e1c06] [replace facts] puppet.site
>> 2014-05-20 05:35:05,871 INFO  [c.p.p.command]
>> [7820d545-1c5f-4b0f-a2e8-0dcbc12d4571] [replace facts] db-node2.site
>> 2014-05-20 05:35:07,642 WARN  [o.e.j.s.HttpChannel]
>> /v3/commands?checksum=e51aa526e2236306cff22ef33c8cb4467166f9c0
>> java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout
>> expired: 30002/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.pupp

[Puppet Users] puppetlabs/java_ks modules and puppet:// uri paths

2014-05-20 Thread Juan Sierra Pons

Hi,

I am recently using the puppetlabs/java_ks module. The documentation
claims that the module supports puppet:// uri path for certificates:

from https://forge.puppetlabs.com/puppetlabs/java_ks:
"
certificate

An already-signed certificate to place in the keystore. Accepts local
file paths or puppet:// uri paths.
"

I am using the following code:

  java_ks {"$hostname-$certificate":
ensure   => latest,
certificate   => "puppet:///extra_files/certificates/mycert.org.crt",
target => hiera('java::keystore::path'),
password=> hiera('java::certificate::password'),
trustcacerts => true,
  }

But when I run the command, the following error appears:

Info: Applying configuration version 'd4944df'
Notice: /Stage[main]/Puppet::Agent::Config/Ini_setting[environment]/value:
value changed 'working_hashes' to 'keystore'
Error: Execution of 'keytool -importcert -noprompt -alias
myserver-mycert.org.crt.org.crt -file
/etc/puppet/files/certificates/mycert.org.crt -keystore /home/devops/
.keystore -trustcacerts' returned 1: Enter keystore password:
Re-enter new password: keytool error: java.io.FileNotFoundException:
/etc/puppet/files/certifi
cates/mycert.org.crt (No such file or directory)

It is referencing the path on the puppet client instead of using the
puppet:/// uri to download the certificate:
keytool -importcert -noprompt -alias myserver-mycert.org.crt.org.crt
-file /etc/puppet/files/certificates/mycert.org.crt -keystore
/home/devops/

Any Idea what I am doing wrong?

Best regards

--
Juan Sierra Pons j...@elsotanillo.net
Linux User Registered: #257202
Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00  6E66 E934 3406 A110 F4FE
--

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

[Puppet Users] Re: Retrieve resource names of a given type without using the filesystem

2014-05-20 Thread jcbollinger

On Tuesday, May 20, 2014 2:41:41 AM UTC-5, Bruno Bieth wrote:
>
>
> I'd like to do something like this
>
>
> define mytype() {}
>
> define delete_mytype() {}
>
> mytype { 'a': }
> mytype { 'b': }
> mytype { 'c': }
>
> $existing_mytypes = # something from facter
>
> # but this doesn't work
> $wanted_mytypes = Mytype <||>
>

No, it wouldn't.  I don't think collectors are rvalues, but if they were, 
they would probably evaluate to (1) an array of resource references, (2) in 
some unspecified order.  But the contents of a resource collection are 
evaluated very late, so as to ensure that all matching resources are 
included in it.  That's too late for the value to be used to declare other 
resources (else the purpose of late evaluation would not be served).

Additionally, facts are traditionally strings. In very recent Facter they 
can be arrays and hashes, too, but nowhere in there can you get resource 
references.  You can get resource names, however.

>   
> Mytype<||> -> Delete_mytype<||>
>
> delete_mytype { diff( $existing_mytypes, $wanted_mytypes ) }
>
>
> I believe I could do something along those lines but it creates as many 
> files as mytype invocation :
>
>

I don't understand.  That is, of course you get one resource per declared 
Mytype instance -- that's what you specify by declaring those resources.  
Why would you expect something different?

>
> defined mytype() {
># persist $name in the filesystem
> }
>
> class prepare_mytypes {
>   # cleanup files created by previous invocation of mytype
> }
>
> Class['prepare_mytypes'] ->
>   Mytype<||> -> 
> Class['remove_old_mytypes']
>
> class remove_old_mytypes {
>
>   # look for files created by mytype
>   # perform the same diff as explained above
> }
>
>
> Any idea?
>

So you are trying to remove unmanaged resources of the specified type?  
Puppet has built-in support for that for plugin resource types that meet a 
couple of fairly simple criteria.  You would even dispense with any need 
for facter to be involved if you wrote your type as a (custom) type / 
provider pair.

On the other hand, if you must do this with defined types, then you can 
probably follow an approach similar to what you are attempting.

The main issue here is with attempting to glean from the catalog under 
construction what instances of Mytype have been declared.  It is *always*poor 
form to base catalog-building decisions on what has already been added 
to the catalog, as doing so introduces evaluation-order dependence into 
your manifest set.  Evaluation order is not specified, so evaluation-order 
dependence makes the contents of the constructed catalog incompletely 
defined and subject to unexpected change.

Instead of querying the catalog, you should know independently what 
resources of your type are intended to be present.  An array of their names 
would be suitable.  These days, the recommendation would probably be to 
maintain that data in Hiera.  You then use that both to declare the wanted 
resources and to determine (based on the data from Facter) what unwanted 
resources are present.  Puppet doesn't have a built-in diff() function, but 
it shouldn't be too hard to write a custom function to do what you need.  
For prototyping, you could probably do it with a combination of 
inline_template() to perform the heavy lifting with split() to convert the 
template output from string to array.

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/ebcf6615-7d34-4060-822c-a6a4f947e007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Yumrepo resource flapping

2014-05-20 Thread jcbollinger



On Tuesday, May 20, 2014 3:38:51 AM UTC-5, DjE wrote:
>
>  Hi all, 
>
> We find that the yumrepo resource is flapping on RedHat 6 Enterprise with 
> the redhat.repo file since Puppet 3.4.x version (due to a change about 
> attribute content control)
>
> We have updated with the latest Puppet 3.6 server and agent, because we 
> saw this commit : 
> https://github.com/puppetlabs/puppet/commit/9c25f75febe4df7d900e553824c9379cb7367c76,
>  
> but the resource continues to flap.
>
> The resource we want to manage : Yumrepo[rhel-6-server-optional-rpms] 
> The Puppet change : enabled changed ' 1' to '1'
>
> RedHat want : *"enabled= 1"*
> Puppet want : "enable=1"
>
> As we can see, there is a white space on original state (RedHat generated 
> file).
>
> The change occurs every 4 hour (with 30 minutes runtime interval agent), i 
> did not looking for the process which generate the redhat.repo file.
>
> rhsm (/etc/rhsm/rhsm.conf) manage the yum repo file : 
>
> # Manage generation of yum repositories for subscribed content:
> manage_repos = 1
>
> [rhsmcertd]
> # Frequency of certificate refresh (in minutes):
> certFrequency = 240
>
> The certFrequency seems to match with the change which occurs every 4 
> hours, i did not test it.
>
>

The problem is that you are managing the same resource via two different 
services.  You are lucky that you are just flapping between two equivalent 
states.  Choose one system or the other to manage the configuration for 
that repo.


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/903782c7-828c-4fcb-9076-479c28650901%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: ${name} returns class name instead of resource namevar

2014-05-20 Thread jcbollinger



On Tuesday, May 20, 2014 5:36:40 AM UTC-5, Francis Pereira wrote:
>
> When using a custom resource to deploy java $name is not the name of the 
> resource but the name of the class in the below mentioned example
>
>  java::setup { "${myapplication::params::app_username}-jdk_7u51":
> ...
> cachedir  => "/var/lib/puppet/file_cache/${name}-working",
>
>   }
>
> Shouldn't $name = ${myapplication::params::app_username}-jdk_7u51 ?
>
>

No.  The situation is analogous to a function call: if the argument list 
contains a variable, the value passed is the value of the variable in the 
calling scope, not the value of any same-named local variable in the called 
function.


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/3866ded5-e517-478c-b876-ce821a5d2740%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread jcbollinger



On Tuesday, May 20, 2014 6:02:17 AM UTC-5, Boyan Tabakov wrote:
>
> Hi, 
>
> On Mon May 19 16:39:25 2014, jcbollinger wrote: 
> > 
> > 
> > On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote: 
> > 
> > Hi, 
> > 
> > The variable I want to access is not defined in a module/class. 
> > It's the 
> > globally defined $::environment. Since facts are also exposed as 
> > global 
> > variables, the server-defined $::environment gets overridden when 
> > there's a fact with the same name. 
> > 
> > So any ideas on how to avoid that? As it is, it looks like a module 
> > can't reliably detect environment, because a (potentially malicious) 
> > client can send an 'environment' fact with arbitrary value. 
> > 
> > 
> > 
> > If you do not trust your nodes to specify their own environment, then 
> > you should set up an ENC that specifies the correct environment for 
> > each node to Puppet.  That can be the only thing it does.  The 
> > environment specified by an ENC will be used instead of the one (if 
> > any) specified by the agent. 
> > 
> > More generally, you should avoid declaring global variables in your 
> > Puppet manifests, and especially you should avoid declaring globals 
> > that collide with facts or with variables provided by the master 
> > itself.  Such collisions /should/ cause catalog compilation to fail 
> > with an error message, but conceivably could fail silently instead. 
> > Puppet variables cannot be changed once set. 
>
> That is exactly what I try to do. 
>
> Still, this is what happens (puppetmaster 3.5.1, puppet agent 3.4.3): 
>
> Agent's configured environment is "agent_env". Agent also has a fact 
> called "environment" with value "agent_env_fact". There is ENC, 
> enforcing environment for that node to be "enc_env". The node's catalog 
> gets compiled in the "enc_env", as it should. For example the node 
> reports: 
>
> Local environment: "agent_env" doesn't match server specified node 
> environment "enc_env", switching agent to "enc_env". 
>
> However if any of the modules use the $::environment variable, it's 
> value is "agent_env_fact". So the agent's fact masks the real value and 
> any modules/manifests that make decisions based on the environment can 
> be fooled. 
>
> This means that any conditionals that are based on $::environment are 
> not reliable. It would be totally fine, if that's documented and people 
> are discouraged to use the $::environment variable, but I could not 
> find anything like that. So, my original question still stands: is 
> there a reliable way to find out the current node's environment in a 
> module/manifest? 
>
>

Per the 
docs,
 
the $::environment variable should do what you want.  That it is not doing 
so is a bug (at minimum, it is a documentation bug, but I think the 
behavior is wrong).  I recommend you file a 
ticket.  
I'm afraid I don't have a workaround to offer.


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/5d5a4d3e-6ecb-49af-8744-b6d6ffa41a4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread jcbollinger

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.

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/c8980729-9066-4490-9720-7dc65fd773d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread jcbollinger

On Tuesday, May 20, 2014 6:55:31 AM UTC-5, Jose Luis Ledesma wrote:
>
> But, who can run puppet?
>
> I mean, most puppet configurations needs root, so if someone malicious is 
> a root which is the point of being able to cheat the environment? He can do 
> whatever wants.
>

Yes, generally speaking, if the target node is compromised so that an 
attacker can compromise the node facts sent to the master, then the 
attacker can modify the node as he wants without going through Puppet.  
Mandatory access controls (e.g. SELinux) can factor into that, but the real 
risk here is that by spoofing the puppet environment, the attacker might be 
able to extract information about the organization that otherwise would not 
be available from the compromised node.  In some cases, he might also be 
able to cause damage or interfere with operations.

Generally, I'm inclined to say that sites employing environments should 
always assign nodes to environments centrally, rather than by relying on 
agents to declare their own.

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/fe0e28a3-bdcd-43ff-9ea5-d1fb6877a8b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Problem using Vagrant + Puppet

2014-05-20 Thread Rafaella Keury

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"],
}"

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.

[Puppet Users] Re: Creating a config file dynamically based on the group membership of a node

2014-05-20 Thread jcbollinger



On Monday, May 19, 2014 2:39:47 AM UTC-5, Grant Street wrote:
>
> Hi 
>
> First time poster to this forum. I'm in the process of doing a pilot to 
> convert a cfengine v2 install to puppet.
>
> I was wondering if any one had any ideas on the following. 
>
> I have machines that can be in any combination(ie 0  or more) of 10 
> groups, that can change. I need to create an access.conf based on the group 
> membership of the node. 
> I would like the file to be dynamically created with any redundant lines 
> removed. 
>
> I have had a look at augeus but  I can't see how to both add lines based 
> on the group as well as remove unwanted and unknown lines. 
> I have also had a look at templates but unsure how that would look like 
> when the you have 0-10 insertion points 
>
>

A template is probably the way to go.  The point to understand there is 
that you will be templating the entire contents of the file, not just the 
lines related to the 10 groups.  Supposing that you have an array of the 
names of the wanted groups, then, your template might look like this:

+:root:LOCAL
<% @wanted_groups.each do |g| -%>
+:(<%= g %>):ALL
<% end -%>
-:ALL:ALL


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/d7a86966-d1c9-4de5-9484-97494f0696d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet class require fails depending on declaration order

2014-05-20 Thread jcbollinger

On Monday, May 19, 2014 6:48:36 AM UTC-5, David Portabella wrote:
>
>  
>  
>
>> so, one specific example,
>>> someone (not me) implemented a class tomcat with parameters port and 
>>> ssl_port.
>>> I want to use that class, 
>>> and I want that the ssl_port is always port + 1 (I don't want this to be 
>>> configurable in hiera) 
>>>
>> so, in my hiera data, I will specify port, and then I have my class:   
>>>
>>
>>> class application ($port) {
>>>   class {tomcat:
>>> port => $port
>>> ssl_port => $port+1
>>>   }
>>>   class {nginx:
>>> ...
>>>   }
>>>   # configuration files...
>>> }
>>>
>>> how would you do this without using resource-like class declaration?
>>>
>>
>> At the present time, I think I would need to write a custom hiera back 
>> end that served keys 'tomcat::port' and 'tomcat::ssl_port' with values 
>> having the desired relationship, and to insert that into my hiera 
>> configuration at higher priority than the YAML back end.  The class 
>> 'application' then declares class 'tomcat' as "include 'tomcat'".  Really, 
>> though, that's a heck of a PITA for such a small constraint.  Why not just 
>> declare both parameters in the normal YAML back end, and verify the proper 
>> ports via functional testing?
>>
>
> that's the point. I don't think this is a "small" constraint. I often find 
> this dependency injection use case,
> and I don't see an easy solution with puppet.
>
>

Well, I suppose that you can always put enough constraints on the solutions 
you're willing to accept to make it difficult for whatever software you're 
targeting to handle.

In this case, you want to use an existing class that has more general 
parameterization than you actually want to allow, and that's really where 
your problem starts.  Then you're unwilling to rely on the parameter 
relationship you want to be maintained in the data for separate 
parameters.  I don't necessarily blame you for that, but it complicates 
your problem.

Finally, you (sensibly) want to avoid your declarations being sensitive to 
evaluation order.  I applaud that, but it does take a whole class of 
alternatives off the table.

The ultimate solution for dependency injection in Puppet is a custom Hiera 
back end, which I mentioned earlier.  Such a thing can solve your problem.  
One specific to this purpose would be pretty quick and easy to write, I 
think, but if there are more than one or two such constraints to serve then 
a separate back end for each is not such a great solution.  I can imagine a 
couple ways to build a more general rules-based back end, but that's 
suddenly a lot more work.  In the end, though, if you have a complicated 
problem then you are likely to need a complicated solution.

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/2dc885e7-27e3-46c9-91c8-2fe44d25e33f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Sergey Arlashin

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$verify_content_type$fn__10379.invoke(middleware.clj:128)
 ~[na:na]
at com.puppetlabs.puppetdb.http.v3$v3_app$fn__11827.invoke(v3.clj:23) 
~[na:na]
at com.puppetlabs.puppetdb.http.v3$v3_app.invoke(v3.clj:21) ~[na:na]
at 
com.puppetlabs.puppetdb.http.server$routes$fn__12370.invoke(server.clj:47) 
~[na:na]
at 
net.cgrand.moustache$alter_request$fn__10771.invoke(moustache.clj:54) ~[na:na]
at com.puppetlabs.puppetdb.http.server$routes.invoke(server.clj:47) 
~[na:na]
at 
ring.middleware.resource$wrap_resource$fn__12339.invoke(resource.clj:24) 
~[na:na]
at ring.middleware.params$wrap_params$fn__10714.invoke(params.clj:58) 
~[na:na]
at 
com.puppetlabs.middleware$wrap_with_authorization$fn__10346.invoke(middleware.clj:40)
 ~[na:na]
at 
com.puppetlabs.middleware$wrap_with_certificate_cn$fn__10350.invoke(middleware.clj:55)
 ~[na:na]
at 
com

Re: [Puppet Users] Using existing resource type via hiera without a class/module manifest.

2014-05-20 Thread David Schmitt


Hi,

On 19.05.2014 23:34, Kashyap Bhatt wrote:

I'm wondering if there is a third option that allows me to get the best
of both options:

  * No hardcoding in site.pp for my node name, catalog is decided via
hiera yaml config files.
  * No separate module/class manifest containing just a 'single liner'
resource declaration.


You might want to look into Crag Dunn's roles and profiles post at


http://www.craigdunn.org/2012/05/239/


for a very reasonable take on how to structure puppet manifests beyond 
the basic tactical modules.


A different take is my own repo at


https://github.com/DavidS/dasz-configuration/tree/master/manifests/nodes


where I do not shy away from putting one-off resources directly into the 
host's node file.



Regards, David

--
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/537B74AC.2090705%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] What is wrong with this? Could not match ${variablehere}

2014-05-20 Thread David Schmitt




On 19.05.2014 23:50, Zan Thorn wrote:

So I am just trying to create a file based off a template. I've done
this many times but am stumped. Maybe some silly syntax error I'm not
seeing?

I define the variable:

   $local_server_root = 'E:\LocalServer'

Then use it in the file type:

   file { 'LocalServer_conf':
 ensure   => file,
 path=> "${local_server_root}\\LocalServer.conf",
 content   => template('local_server/LocalServer.conf.erb'),
 require   => Package['local_server'],
 notify   => Service['local_server'],
   }


But I am still getting this error?! Any help is appreciated.

err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not match ${local_server_root}\\LocalServer.conf", at
/etc/puppetlabs/puppet/environments/test/modules/local_server/manifests/init.pp:45
on node node.local


Is this really the whole file you're showing? it looks as if somewhere 
you have missed closing a double quote BEFORE the part you're quoting.



Regards, David

--
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/537B7511.1020706%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Retrieve resource names of a given type without using the filesystem

2014-05-20 Thread Bruno Bieth

John, thanks for your detailed answer!

So you are trying to remove unmanaged resources of the specified type?  
> Puppet has built-in support for that for plugin resource types that meet a 
> couple of fairly simple criteria.  You would even dispense with any need 
> for facter to be involved if you wrote your type as a (custom) type / 
> provider pair.
>

That seems to be the solution i'm looking for.

 
>
> Instead of querying the catalog, you should know independently what 
> resources of your type are intended to be present.  An array of their names 
> would be suitable.  These days, the recommendation would probably be to 
> maintain that data in Hiera.  You then use that both to declare the wanted 
> resources and to determine (based on the data from Facter) what unwanted 
> resources are present.  Puppet doesn't have a built-in diff() function, but 
> it shouldn't be too hard to write a custom function to do what you need.  
> For prototyping, you could probably do it with a combination of 
> inline_template() to perform the heavy lifting with split() to convert the 
> template output from string to array.
>
>
I'm actually moving away from hiera. Just to give more context, I have a 
defined type to manage jenkins jobs that allows us amongst other things to 
 - version jobs in a minimalistic fashion (instead of versioning xml).
 - build many similar projects by querying stash (using custom functions)
 
My defined type is called 'job_shell' and as I just said can be called 
multiple times in various places.

Bruno 

-- 
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/b46f5b66-401a-4234-a619-a969e5295254%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Problem using Vagrant + Puppet

2014-05-20 Thread Felix Massem

HeyRafaella,

try this in your Vagrant File

# provisioning with puppet
server.vm.provision "puppet" do |puppet|
puppet.manifests_path = "manifests"
puppet.manifest_file = "db.pp"
puppet.module_path = "modules"
end

cheers felix

Am Dienstag, 20. Mai 2014 16:06:20 UTC+2 schrieb Rafaella Keury:
>
> 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"],
> }"
>
> 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/fac9a4b1-d20b-49c3-8d58-e47f539568c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread jcbollinger



On Monday, May 19, 2014 1:42:08 PM UTC-5, Jesse Cotton wrote:
>
> On Monday, May 19, 2014 10:18:11 AM UTC-4, jcbollinger wrote:
>>
>>
>>
>> On Friday, May 16, 2014 10:55:35 AM UTC-5, Jesse Cotton wrote:
>>>
>>> I work with Matt and am filling in for him since I posed this question 
>>> to him originally.
>>>
>>> Our confusion really lies around how you layout profiles for a 
>>> multi-function box. For example, suppose you have a role, "CMS App Server" 
>>> that will host various CMS like Wordpress, Drupal, and others. They are all 
>>> built on top of the same technologies, Apache, PHP, and MySQL. I don't 
>>> believe you can build a separate profile for each CMS b/c they will 
>>> conflict (at least within Puppet). Each will require a certain set of php 
>>> modules and settings, apache modules and settings, etc. So do you build a 
>>> single profile like profile::wordpress_drupal_cms3_cm4 or do you build a 
>>> profile::apachefpm profile? The later seems more logical to me however you 
>>> lose the ability to define profile specific hiera variables b/c 
>>> profile::apachefpm is generic.
>>>
>>>
>>
>> You can declare the same class multiple times, provided that you use the 
>> 'include' function or its cousins to do so.  That is a tremendously useful 
>> technique for managing configurations where multiple facilities share 
>> requirements on some of the same core resources.  Using 'include' instead 
>> of resource-like class declarations means you must feed data to your 
>> classes via hiera instead of via your manifests, but separating your data 
>> from your manifests is good practice anyway.  That's what Christopher Wood 
>> was pointing you toward, and it is good advice.
>>
>>
> We're aware of most of this and agree with most of this. However when you 
> always call include, you lose the ability to say a particular hiera 
> variable is attached to the profile. For example
>
> If you define:
>
> class profile::apache_phpfpm {
>   include ::apache
> }
>
> with the following in hiera:
>
> apache::keepalive = 1
>
> keepalive = 1 applies anywhere apache is included
>
> vs
>
> class profile::apache_phpfpm (
>   $keepalive = 1
> ) {
>   class { ::apache:
> keepalive => $keepalive
>   }
> }
>
> profile::apache_phpfpm::keepalive = 1
>
> So with the later you can build a somewhat self-contained profile. With 
> the former you have to set variables "globally" or on a node.
>


That is what your data hierarchy is for.  Hiera does not limit you to only 
global and per-node data.  You can define as many hierarchy levels as you 
need, each grouping your nodes in its own way (though it usually makes the 
most sense for the groups at each level to be subsets of the groups at the 
next lower level).

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.

 

>
>  
>
>> It is thus possible to find and/or write composable classes and modules 
>> for managing the components you want.  As David Schmitt observes, 
>> composability is not automatic, but I don't see why your particular case of 
>> an apache-based PHP app server with firewall rules and a specific 
>> collection of PHP and apache modules should present any special problem.
>>
>> Thus, the answer to your question is "neither."  You build a drupal 
>> profile, and a wordpress profile, etc., and you use them all together.
>>
>>
> So below is an example for Drupal. It could literally be cloned for 
> Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is 
> not composable.
>
> 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)
>   c

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

2014-05-20 Thread jcbollinger



On Monday, May 19, 2014 6:45:56 PM UTC-5, Brian Mathis wrote:
>
> I'm seeing this issue with the current version of stdlib.  When getting 
> numeric data from hiera, or performing math on a variable, validate_re() 
> fails when using the following regex:
> '[0-9]+'
>
>

Fascinating.

 

> Here are some test cases:
>
> Getting data from hiera
> # Hiera data:
> # ---
> # testvalue: 1234
>
> FAIL:
> $myvar = hiera('testvalue')
> validate_re( $myvar, '[0-9]+' )
>
> Performing math
> OK:
>$var = 1000
>validate_re( $var, '[0-9+]' )
>
> FAIL:
>$var2 = 2000 + 1
>validate_re( $var2, '[0-9+]' )
>
> I've had to resort to quoting variables in validate_re, like this:
> OK:
> $var3 = 3000 + 1
> validate_re( "${var3}", '[0-9+]' )
>
> However puppet-lint complains about having only a variable inside 
> double-quotes, so I'm considering solving this with the very ugly:
> validate_re( "X${var3}", 'X[0-9+]' )
>
>

Yet your solution using "${var3}" is perfectly good thing to do to convert 
a variable of uncertain type to a string.  I'd tell puppet-lint to go play 
in a clothes dryer.

Alternatively, you could try this instead:

if not is_integer(${var3}) or (${var3} < 0) {
  validate_re( ${var3}, '[0-9]+')
}


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/ff0438de-833c-4207-a605-5cc82c427efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Problem using Vagrant + Puppet

2014-05-20 Thread Rafaella Keury

Hi Felix!
Thanks a lot for your answer, but it still doesn't work and I get the same 
error.

Em terça-feira, 20 de maio de 2014 08h26min49s UTC-7, Felix Massem escreveu:
>
> HeyRafaella,
>
> try this in your Vagrant File
>
> # provisioning with puppet
> server.vm.provision "puppet" do |puppet|
> puppet.manifests_path = "manifests"
> puppet.manifest_file = "db.pp"
> puppet.module_path = "modules"
> end
>
> cheers felix
>
> Am Dienstag, 20. Mai 2014 16:06:20 UTC+2 schrieb Rafaella Keury:
>>
>> 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"],
>> }"
>>
>> 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/a5487105-5cb9-43b9-8f44-009f9bf8d8d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Service stuck after updating puppet on Windows Server 2003

2014-05-20 Thread Rob Reynolds

Using puppet to manage puppet upgrades to the agent has been an interesting
dilemma that sometimes has issues. OpenTable came out with this module:
https://forge.puppetlabs.com/opentable/puppetversion to help handle
upgrades. On Windows they set a scheduled task to manage the upgrade just
after the run is complete.


On Tue, May 20, 2014 at 6:30 AM, cko  wrote:

> Any idea?
>
>
> On Saturday, May 10, 2014 12:22:46 PM UTC+2, cko wrote:
>>
>> After the puppet run the agent service is basically stopped.
>>
>> Although when i run "sc queryex puppet" the output is "STOP_PENDING" (not
>> stopped but not running either).
>>
>> So i have to run "taskkill /f /pid 1234" and then start the service again.
>>
>>
>>
>> On Friday, May 9, 2014 9:45:35 PM UTC+2, Rob Reynolds wrote:
>>>
>>> This error is somewhat of a misnomer: "The requested service has already
>>> been started."
>>>
>>> When you say it gets stuck, what do you mean exactly?
>>>
>>>
>>> On Fri, May 9, 2014 at 8:08 AM, cko  wrote:
>>>
 Hi,

 I'm using puppet to manage the puppet agent (package, config, service)
 in my Windows Server 2003 boxes.

 Whenever I update the package, the puppet agent service gets stuck
  (STOP PENDING).

 The report returns:

 *Fri May 09 12:13:51 +0200 2014
 /Stage[main]/puppet_agent::Windows::Service/Service[puppet] (err): Failed
 to call refresh: Cannot start puppet, error was: Execution of
 'C:/WINDOWS/system32/net.exe start puppet' returned 2: The requested
 service has already been started.*
 *More help is available by typing NET HELPMSG 2182.*
 *Fri May 09 12:13:51 +0200 2014
 /Stage[main]/puppet_agent::Windows::Service/Service[puppet] (err): Cannot
 start puppet, error was: Execution of 'C:/WINDOWS/system32/net.exe start
 puppet' returned 2: The requested service has already been started.*
 *More help is available by typing NET HELPMSG 2182.*

 I use the same manifest for Windows Server 2008 nodes without runnning
 into this problem.

 My manifest looks like this:


 *package { 'Puppet':*
 *   ensure  => "3.5.1",*
 *   source  =>
 "share\\puppet_agent\\windows\\puppet-3.5.1.msi",*
 *   provider=> windows,*
 *   install_options => { 'INSTALLDIR' => 'C:\puppet' } *
 *}*

 *file { 'C:\Documents and Settings\All Users\Application
 Data\PuppetLabs\puppet\etc\puppet.conf':*
 *   content =>
 template("base_puppet_agent/windows/puppet_windows.erb"),
 *
 *   notify  => Service['puppet'],*
 *   require => Package ['Puppet'],*
 *}*

 *service { 'puppet':*
 *   ensure   => running,*
 *   enable   => true,*
 *   require  => Package['Puppet'],*
 *}*


  --
 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/0a9a5b19-b44f-47b2-9749-5bfc38c8404e%
 40googlegroups.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Rob Reynolds
>>> Developer, Puppet Labs
>>>
>>> *Join us at **PuppetConf 2014 **, September
>>> 23-24 in San Francisco*
>>> *Register by May 30th to take advantage of the Early Adopter discount
>>>  **--**save $349!*
>>>
>>  --
> 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/0e98161c-af86-46d7-b89d-efac6d4a8ea0%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Developer, Puppet Labs

*Join us at **PuppetConf 2014 **, September 23-24 in
San Francisco*
*Register by May 30th to take advantage of the Early Adopter discount
 **--**save $349!*

-- 
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/CAMJiBK6QsQGyGd1%2Bq%2BZKJiWFJ2%3DHw2iBKGzf

Re: [Puppet Users] Re: Problem using Vagrant + Puppet

2014-05-20 Thread Rob Reynolds

Here is a working example, try to see what you can pull from it -
https://github.com/ferventcoder/dayofdevops/tree/master/lab02-firehose

Also, unless you are using multi-machine configuration, there is no reason
to do config.vm.define.

Note this line to provide you more information:
  config.vm.provision :puppet, :options => ["--debug --trace --verbose"] do
|puppet|

If you are still running into problems, try setting the VAGRANT_LOG
variable for more information - see
http://docs.vagrantup.com/v2/other/debugging.html



On Tue, May 20, 2014 at 11:10 AM, Rafaella Keury
wrote:

> Hi Felix!
> Thanks a lot for your answer, but it still doesn't work and I get the same
> error.
>
> Em terça-feira, 20 de maio de 2014 08h26min49s UTC-7, Felix Massem
> escreveu:
>
>> HeyRafaella,
>>
>> try this in your Vagrant File
>>
>> # provisioning with puppet
>> server.vm.provision "puppet" do |puppet|
>> puppet.manifests_path = "manifests"
>> puppet.manifest_file = "db.pp"
>> puppet.module_path = "modules"
>> end
>>
>> cheers felix
>>
>> Am Dienstag, 20. Mai 2014 16:06:20 UTC+2 schrieb Rafaella Keury:
>>>
>>> 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"],
>>> }"
>>>
>>> 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/a5487105-5cb9-43b9-8f44-009f9bf8d8d5%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Developer, Puppet Labs

*Join us at **PuppetConf 2014 **, September 23-24 in
San Francisco*
*Register by May 30th to take advantage of the Early Adopter discount
 **--**save $349!*

-- 
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/CAMJiBK6%3DgGHn1EX_kv-ytEmT8KX8eKZ_Uzrf%2Byj9wxAQ9t0kJw%40mail.gmail.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

2014-05-20 Thread Brian Mathis

On Tue, May 20, 2014 at 11:59 AM, jcbollinger wrote:

>
>
> On Monday, May 19, 2014 6:45:56 PM UTC-5, Brian Mathis wrote:
>>
>> I'm seeing this issue with the current version of stdlib.  When getting
>> numeric data from hiera, or performing math on a variable, validate_re()
>> fails when using the following regex:
>> '[0-9]+'
>>
>>
>
> Fascinating.
>
>
>
>> Here are some test cases:
>>
>> Getting data from hiera
>> # Hiera data:
>> # ---
>> # testvalue: 1234
>>
>> FAIL:
>> $myvar = hiera('testvalue')
>> validate_re( $myvar, '[0-9]+' )
>>
>> Performing math
>> OK:
>>$var = 1000
>>validate_re( $var, '[0-9+]' )
>>
>> FAIL:
>>$var2 = 2000 + 1
>>validate_re( $var2, '[0-9+]' )
>>
>> I've had to resort to quoting variables in validate_re, like this:
>> OK:
>> $var3 = 3000 + 1
>> validate_re( "${var3}", '[0-9+]' )
>>
>> However puppet-lint complains about having only a variable inside
>> double-quotes, so I'm considering solving this with the very ugly:
>> validate_re( "X${var3}", 'X[0-9+]' )
>>
>>
>
> Yet your solution using "${var3}" is perfectly good thing to do to convert
> a variable of uncertain type to a string.  I'd tell puppet-lint to go play
> in a clothes dryer.
>
> Alternatively, you could try this instead:
>
> if not is_integer(${var3}) or (${var3} < 0) {
>   validate_re( ${var3}, '[0-9]+')
> }
>
>
> John
>
>>

I have decided to exclude these files from that puppet-lint test, so I can
use double-quotes only.  However, if validate_re() is expecting to only
operate on a string, it should be doing this internally and not forcing it
upon the user to make an explicit cast to a string.  This is a bug in
validate_re(), even though there is a workaround.


❧ 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/CALKwpEyxD7Y%3Deo%2BWVjghirYsqXXsHiXS1wDZooFk9t6CZc-X%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Christopher Wood

On Fri, May 16, 2014 at 11:12:15AM -0700, Ramin K wrote:
> On 5/15/2014 12:14 PM, Christopher Wood wrote:
> >(inline)
> >
> >On Thu, May 15, 2014 at 11:45:21AM -0700, Ramin K wrote:
> >>
> >>I'd also like to disagree slightly with Christopher who also
> >>posted in this thread. Your profile:: classes are the perfect place
> >>for all sorts of site specific nonsense including resources. In
> >>fact if you're not sufficiently embarrassed of your profile classes
> >>you're probably not taking full advantage of that abstraction
> >>layer. I wrote about how I use/abuse them here,
> >>https://ask.puppetlabs.com/question/5235/what-goes-in-the-profile-part-of-roleprofile/
> >
> >(I think I had this exact conversation when discussing profiles at
> >work.)
> >
> >This is usually where I say: If you have site-specific things you
> >should modularize those and add the relevant include statements and
> >chaining to the profile, with the data in hiera.
> >
> >For us that includes a site level in hiera so that hosts at different
> >sites get different puppetmasters (server not ca_server), ntp
> >servers, resolvers, and so on. This helps us use the mnemonic that
> >anything in node yaml indicates either an oddity or an error. This
> >will also let us quickly include a module if we need it somewhere
> >else.
> >
> >Of course, your mileage may vary, mine sure has at times.
> 
> Oh good, disagreement. I think much harder when that happens :-)
> 
>   We probably agree more than disagree, but the statement that
> bothered me was that profile was a place of pure includes and
> chains. Sure everything should be modularized, but often the time to
> do it is eventually and sometimes never. Generalization should only
> happen once you need more than one and fully understand the problem.
> Perhaps we could mimic Knuth and say "Premature generalization is a
> distraction from automating your production system."

There's a point. Though regardless of my level of understanding I definitely 
will need more than one (more below.)

>   I think there is a distinction between small systems and large ones
> which affect both our point of views. I run a smallish system that I
> own completely. Without dissenting opinions about what should be on
> servers I'm free to make sweeping changes to how we manage a daemon
> with hardly anyone noticing let alone caring. And because I'm
> manpower limited, I'm unlikely to do generalization unless
> absolutely needed.
>   In a larger system many sites, divisions, etc are going to do
> things differently and generalization is required much earlier and
> often. Also with a larger staff the additional code and complexity
> is worth it if it keeps everyone from reinventing the wheel.

I think you've hit the nail right on the head. My thinking is definitely 
influenced by the need to do things at (medium-ish) scale and I won't be 
interrupted by some random server's nagios tantrum. If it was a choice between 
perfect profiles and being able to get everything else done too I would 
definitely make your choice instead (as I have before). As long as it's in 
git/puppet somebody can read it later and figure out what I was up to.

> Ramin
> 
> -- 
> 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/537654FF.2000502%40badapple.net.
> 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/20140520171916.GA8659%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Yumrepo resource flapping

2014-05-20 Thread DjE

Le 20/05/2014 15:47, jcbollinger a écrit :

On Tuesday, May 20, 2014 3:38:51 AM UTC-5, DjE wrote:

Hi all,

We find that the yumrepo resource is flapping on RedHat 6
Enterprise with the redhat.repo file since Puppet 3.4.x version
(due to a change about attribute content control)

We have updated with the latest Puppet 3.6 server and agent,
because we saw this commit :

https://github.com/puppetlabs/puppet/commit/9c25f75febe4df7d900e553824c9379cb7367c76

,
but the resource continues to flap.

The resource we want to manage : Yumrepo[rhel-6-server-optional-rpms]
The Puppet change : enabled changed ' 1' to '1'

RedHat want : *"enabled= 1"*
Puppet want : "enable=1"

As we can see, there is a white space on original state (RedHat
generated file).

The change occurs every 4 hour (with 30 minutes runtime interval
agent), i did not looking for the process which generate the
redhat.repo file.

rhsm (/etc/rhsm/rhsm.conf) manage the yum repo file :

# Manage generation of yum repositories for subscribed content:
manage_repos = 1

[rhsmcertd]
# Frequency of certificate refresh (in minutes):
certFrequency = 240

The certFrequency seems to match with the change which occurs
every 4 hours, i did not test it.

The problem is that you are managing the same resource via two
different services. You are lucky that you are just flapping between
two equivalent states. Choose one system or the other to manage the
configuration for that repo.

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/903782c7-828c-4fcb-9076-479c28650901%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi,

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, it could be a nice thing that Puppet use
the same syntax.

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.

Djé

--
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/537B94C9.6000307%40nosbox.net.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Jesse Cotton


>
>
>>> We're aware of most of this and agree with most of this. However when 
>> you always call include, you lose the ability to say a particular hiera 
>> variable is attached to the profile. For example
>>
>> If you define:
>>
>> class profile::apache_phpfpm {
>>   include ::apache
>> }
>>
>> with the following in hiera:
>>
>> apache::keepalive = 1
>>
>> keepalive = 1 applies anywhere apache is included
>>
>> vs
>>
>> class profile::apache_phpfpm (
>>   $keepalive = 1
>> ) {
>>   class { ::apache:
>> keepalive => $keepalive
>>   }
>> }
>>
>> profile::apache_phpfpm::keepalive = 1
>>
>> So with the later you can build a somewhat self-contained profile. With 
>> the former you have to set variables "globally" or on a node.
>>
>
>
> That is what your data hierarchy is for.  Hiera does not limit you to only 
> global and per-node data.  You can define as many hierarchy levels as you 
> need, each grouping your nodes in its own way (though it usually makes the 
> most sense for the groups at each level to be subsets of the groups at the 
> next lower level).
>
>
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'. 


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.
 

>  
>
>>
>>  
>>
>>> It is thus possible to find and/or write composable classes and modules 
>>> for managing the components you want.  As David Schmitt observes, 
>>> composability is not automatic, but I don't see why your particular case of 
>>> an apache-based PHP app server with firewall rules and a specific 
>>> collection of PHP and apache modules should present any special problem.
>>>
>>> Thus, the answer to your question is "neither."  You build a drupal 
>>> profile, and a wordpress profile, etc., and you use them all together.
>>>
>>>
>> So below is an example for Drupal. It could literally be cloned for 
>> Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is 
>> not composable.
>>
>> 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 ...


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


How are others constructing their hierarchies when using the Role & Profile 
pattern? Are you assigning variables based on a nodes role or profiles? If 
so, how? Custom facts, parameterized classes as we've done in the example 
above?


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

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

2014-05-20 Thread Christopher Wood

On Tue, May 20, 2014 at 10:54:15AM -0700, Jesse Cotton wrote:
>We're aware of most of this and agree with most of this. However when
>you always call include, you lose the ability to say a particular
>hiera variable is attached to the profile. For example
>If you define:
>class profile::apache_phpfpm {
>  include ::apache
>}
>with the following in hiera:
>apache::keepalive = 1
>keepalive = 1 applies anywhere apache is included
>vs
>class profile::apache_phpfpm (
>  $keepalive = 1
>) {
>  class { ::apache:
>    keepalive => $keepalive
>  }
>}
>profile::apache_phpfpm::keepalive = 1
>So with the later you can build a somewhat self-contained profile.
>With the former you have to set variables "globally" or on a node.
> 
>  That is what your data hierarchy is for.  Hiera does not limit you to
>  only global and per-node data.  You can define as many hierarchy levels
>  as you need, each grouping your nodes in its own way (though it usually
>  makes the most sense for the groups at each level to be subsets of the
>  groups at the next lower level).
> 
>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'. 

It sounds like there's some generalizable rule where some hosts get certain 
settings (ex: keepalive) setting and some don't. Perhaps this could be broken 
out into another hiera layer? Cheapest possible example:

:hierarchy:
  - 'nodes/%{fqdn}'
  - 'roles/%{role}'
  - 'common'

There's this workflow:

puppetmaster uses ENC to get the node's role (named "mytype" here)
the role is used to name the class for hiera_include (role::mytype)
mytype.yaml is also a yaml file as part of that hiera level

Then in the yaml for "phpfpm" and "needkeepalive" you have "apache::keepalive: 
true" and in common.yaml you have "apache::keepalive: false".

>  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.
> 
> 
>   
> 
> 
> 
>  It is thus possible to find and/or write composable classes and
>  modules for managing the components you want.  As David Schmitt
>  observes, composability is not automatic, but I don't see why your
>  particular case of an apache-based PHP app server with firewall
>  rules and a specific collection of PHP and apache modules should
>  present any special problem.
> 
>  Thus, the answer to your question is "neither."  You build a drupal
>  profile, and a wordpress profile, etc., and you use them all
>  together.
> 
>So below is an example for Drupal. It could literally be cloned for
>Wordpress and Joomla. Unfortunately, b/c of the class declarations, it
>is not composable.
>class profile::drupal (
>  $apache_listen = ['80'],
>  $apache_name_virtual_hosts = ['*:80'],
>  $apache_modules = ['fastcgi'],
>  $apache_fastcgi_servers = {
>    'www' => {
>      host => '[1]127.0.0.1:9000',
>      faux_path => '/var/www/php.fcgi',
>      alias => '/php.fcgi',
>      file_type => 'application/x-httpd-php'
>    }
>  },
>  $phpfpm_pools = {
>    'www' => {
>      listen  => '[2]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

[Puppet Users] installing puppetdb on Debian 6 [wheezy]

2014-05-20 Thread Peter Berghold

Hi folks,

Attempting to install puppetdb on Debian 6 and have run into a bit of a
roadblock.

It's complaining that java7 is not on the system and yet:

:/usr/lib/jvm# java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

I suppose it is looking for a packaged called j2re1.7
or java7-runtime-headless.  Any way of faking this out so it works with the
Oracle version?



-- 

Peter L. Berghold   salty.cowd...@gmail.com

http://blog.berghold.net

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

Re: [Puppet Users] installing puppetdb on Debian 6 [wheezy]

2014-05-20 Thread Christopher Wood

What's the error message?

On Tue, May 20, 2014 at 03:22:24PM -0400, Peter Berghold wrote:
>Hi folks,
>Attempting to install puppetdb on Debian 6 and have run into a bit of a
>roadblock.
>It's complaining that java7 is not on the system and yet:
>:/usr/lib/jvm# java -version
>java version "1.7.0_51"
>Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
>Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
>I suppose it is looking for a packaged called j2re1.7
>or java7-runtime-headless.  Any way of faking this out so it works with
>the Oracle version?
>--
> 
>Peter L. Berghold   [1]salty.cowd...@gmail.com
> 
>[2]http://blog.berghold.net
> 
>--
>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 [3]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [4]https://groups.google.com/d/msgid/puppet-users/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%40mail.gmail.com.
>For more options, visit [5]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:salty.cowd...@gmail.com
>2. http://blog.berghold.net/
>3. mailto:puppet-users+unsubscr...@googlegroups.com
>4. 
> https://groups.google.com/d/msgid/puppet-users/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%40mail.gmail.com?utm_medium=email&utm_source=footer
>5. 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/20140520194150.GA9787%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] installing puppetdb on Debian 6 [wheezy]

2014-05-20 Thread Peter Berghold

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 puppetdb : Depends: java7-runtime-headless but it is not installable or
 j2re1.7 but it is not installable
E: Broken packages



On Tue, May 20, 2014 at 3:41 PM, Christopher Wood <
christopher_w...@pobox.com> wrote:

> What's the error message?
>
> On Tue, May 20, 2014 at 03:22:24PM -0400, Peter Berghold wrote:
> >Hi folks,
> >Attempting to install puppetdb on Debian 6 and have run into a bit of
> a
> >roadblock.
> >It's complaining that java7 is not on the system and yet:
> >:/usr/lib/jvm# java -version
> >java version "1.7.0_51"
> >Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> >Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> >I suppose it is looking for a packaged called j2re1.7
> >or java7-runtime-headless.  Any way of faking this out so it works
> with
> >the Oracle version?
> >--
> >
> >Peter L. Berghold   [1]salty.cowd...@gmail.com
> >
> >[2]http://blog.berghold.net
> >
> >--
> >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 [3]puppet-users+unsubscr...@googlegroups.com.
> >To view this discussion on the web visit
> >[4]
> https://groups.google.com/d/msgid/puppet-users/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%40mail.gmail.com
> .
> >For more options, visit [5]https://groups.google.com/d/optout.
> >
> > References
> >
> >Visible links
> >1. mailto:salty.cowd...@gmail.com
> >2. http://blog.berghold.net/
> >3. mailto:puppet-users+unsubscr...@googlegroups.com
> >4.
> https://groups.google.com/d/msgid/puppet-users/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%40mail.gmail.com?utm_medium=email&utm_source=footer
> >5. 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/20140520194150.GA9787%40iniquitous.heresiarch.ca
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Peter L. Berghold   salty.cowd...@gmail.com

http://blog.berghold.net

-- 
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/CAArvnv33Ydf%2Bt3EFdyXg-398qTcH-j3_TfdKjY2Sy1HMZVPctQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Debugging manifests with Future Parser

2014-05-20 Thread Jason Knudsen

Hey team,

Testing the waters with the new Future Parser functionality. 

I've enabled it in [main] and [master] with parser = future, in my 
puppet.conf, and am running puppet v3.5.1. Earlier versions of puppet 
(namely, 3.4.2) worked fine with this setting enabled and the exact same 
modules. I know a lot of changes went into 3.5.0 and I'm trying to track 
down why it's failing..

Puppet runs look like this:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Found 4 errors. Giving up in /opt/puppet/modules/nagios/manifests/init.pp 
on node 
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

With --debug and --verbose it fails similarly without any additional 
information. This is a big module so it's hard to determine exactly what's 
failing.

Any advice on how to debug the parser itself, or get additional output as 
to what those 4 errors could be?

Thanks,
Jason

-- 
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/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Debugging manifests with Future Parser

2014-05-20 Thread Christopher Wood

If you run your puppetmaster in the foreground with debug enabled it might tell 
you more. (You'll have to stop the usual daemon first, and run it as the usual 
user not root.)

puppet master --debug --no-daemonize 2>&1 | tee /var/tmp/pm1.log

Also use --config in there if you need it, of course.

On Tue, May 20, 2014 at 12:53:39PM -0700, Jason Knudsen wrote:
>Hey team,
>Testing the waters with the new Future Parser functionality. 
>I've enabled it in [main] and [master] with parser = future, in my
>puppet.conf, and am running puppet v3.5.1. Earlier versions of puppet
>(namely, 3.4.2) worked fine with this setting enabled and the exact same
>modules. I know a lot of changes went into 3.5.0 and I'm trying to track
>down why it's failing..
>Puppet runs look like this:
>Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
>Found 4 errors. Giving up in /opt/puppet/modules/nagios/manifests/init.pp
>on node 
>Warning: Not using cache on failed catalog
>Error: Could not retrieve catalog; skipping run
>With --debug and --verbose it fails similarly without any additional
>information. This is a big module so it's hard to determine exactly what's
>failing.
>Any advice on how to debug the parser itself, or get additional output as
>to what those 4 errors could be?
> 
>Thanks,
>Jason
> 
>--
>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 [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com?utm_medium=email&utm_source=footer
>3. 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/20140520200533.GA9929%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] ${name} returns class name instead of resource namevar

2014-05-20 Thread Johan De Wit

Hi,

I think you are mixing the 'define' a resource and 'use' resource type.

$name is an automatic variable that is set by puppet, and will be in the
case of a defined resource, the resource title you give it when 'using'
that defined resource

You can use the $name in the define { } , and in that scope
it will be given your example :
${myapplication::params::app_username}-jdk_7u51.

Outside the definition of your resource (the file beginning with define
{} ) the $name var contains the $name of the class you are
using your defined resource .

I hope i did not confuse you more now.

but read
http://docs.puppetlabs.com/puppet/latest/reference/lang_defined_types.html#title-and-name

especially the part about uniqueness.

An to make it much more difficult, one should start using $title in
defined resources instead of $name.

the why is explained in the same link I gave.

I hope it helps.

Grts
Jo

On 20/05/14 13:51, José Luis Ledesma wrote:

No, it is the current $name, not the resource one.

Regards,

El 20/05/2014 12:36, "Francis Pereira" > escribió:

When using a custom resource to deploy java $name is not the name
of the resource but the name of the class in the below mentioned
example

java::setup { "${myapplication::params::app_username}-jdk_7u51":
...
cachedir => "/var/lib/puppet/file_cache/${name}-working",

}

Shouldn't $name = ${myapplication::params::app_username}-jdk_7u51 ?

Francis Pereira

--
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/CABCZsNFgJ6GbK0UAmVdxhONb9D1rde1pnFXz-tjZmBj1BBMg9w%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/CAF_B3dcMF0u%2BXr%2BcACZPhZmXdiTaTuXAkS7_yaQ01X_TmOWp9A%40mail.gmail.com
.

For more options, visit https://groups.google.com/d/optout.

--
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer (805008667232363)
Puppet Certified Professional 2013/2014 (PCP006)
_

Open-Future Phone +32 (0)2/255 70 70

Zavelstraat 72 Fax +32 (0)2/255 70 71
3071 KORTENBERG Mobile+32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_

Next Events:
Linux Training | https://www.open-future.be/linux-training-5-till-9th-may
Puppet Introduction Course |
https://www.open-future.be/puppet-introduction-course-12th-may
Puppet Fundamentals Training |
https://www.open-future.be/puppet-fundamentals-training-13-till-15th-may
Zabbix Certified Specialist |
https://www.open-future.be/zabbix-certified-specialist-training-19-till-21th-may
Zabbix Certified Professional |
https://www.open-future.be/zabbix-certified-professional-training-22-till-23rd-may
Subscribe to our newsletter | http://eepurl.com/BUG8H

--
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/537BB7AC.6050004%40open-future.be.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Debugging manifests with Future Parser

2014-05-20 Thread Jason Knudsen

Thanks for the tip, worked like a charm. Turns out I had some variables 
with an uppercase first letter.

Got past that, but now I'm also dealing with something else unexpected.

Info: Retrieving pluginfacts
Info: Retrieving plugin
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Evaluation Error: Error while evaluating a Resource Statement, In 
Puppet::Pops::Types::PResourceType : Can not use a Hash where a String is 
expected at /opt/puppet/modules/nagios/manifests/init.pp:306:5 on node 

Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Basically, in the Nagios module we loop through a hash of servers we pull 
from our ENC's API:

serverLoop { $enc_api::servers: }

Has the behavior altered for define's?

Jason


On Tuesday, May 20, 2014 4:05:33 PM UTC-4, Christopher Wood wrote:
>
> If you run your puppetmaster in the foreground with debug enabled it might 
> tell you more. (You'll have to stop the usual daemon first, and run it as 
> the usual user not root.) 
>
> puppet master --debug --no-daemonize 2>&1 | tee /var/tmp/pm1.log 
>
> Also use --config in there if you need it, of course. 
>
> On Tue, May 20, 2014 at 12:53:39PM -0700, Jason Knudsen wrote: 
> >Hey team, 
> >Testing the waters with the new Future Parser functionality.  
> >I've enabled it in [main] and [master] with parser = future, in my 
> >puppet.conf, and am running puppet v3.5.1. Earlier versions of puppet 
> >(namely, 3.4.2) worked fine with this setting enabled and the exact 
> same 
> >modules. I know a lot of changes went into 3.5.0 and I'm trying to 
> track 
> >down why it's failing.. 
> >Puppet runs look like this: 
> >Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: 
> >Found 4 errors. Giving up in 
> /opt/puppet/modules/nagios/manifests/init.pp 
> >on node  
> >Warning: Not using cache on failed catalog 
> >Error: Could not retrieve catalog; skipping run 
> >With --debug and --verbose it fails similarly without any additional 
> >information. This is a big module so it's hard to determine exactly 
> what's 
> >failing. 
> >Any advice on how to debug the parser itself, or get additional 
> output as 
> >to what those 4 errors could be? 
> > 
> >Thanks, 
> >Jason 
> > 
> >-- 
> >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 [1]puppet-users...@googlegroups.com . 
> >To view this discussion on the web visit 
> >[2]
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com.
>  
>
> >For more options, visit [3]https://groups.google.com/d/optout. 
> > 
> > References 
> > 
> >Visible links 
> >1. mailto:puppet-users+unsubscr...@googlegroups.com  
> >2. 
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com?utm_medium=email&utm_source=footer
>  
> >3. 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/cef444e1-3c74-4e75-b1ef-e23d54b21088%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] installing puppetdb on Debian 6 [wheezy]

2014-05-20 Thread Christopher Wood

In your situation, I'd file a bug with puppetlabs about this, at least because 
this makes puppetdb not trivially installable in squeeze. From the control 
files for the last two puppetdb packages:

Package: puppetdb
Version: 2.0.0-1puppetlabs1
Architecture: all
Maintainer: Puppet Labs 
Installed-Size: 24176
Depends: java7-runtime-headless | j2re1.7, adduser, puppet (>= 2.7.12)

Package: puppetdb
Version: 1.6.3-1puppetlabs1
Architecture: all
Maintainer: Puppet Labs 
Installed-Size: 23732
Depends: java7-runtime-headless | j2re1.7 | java6-runtime-headless, adduser, 
puppet (>= 2.7.12)

That said, openjdk-7-jre-headless exists in wheezy (provided by 
openjdk-7-jre-headless) and you'll probably do less work if you build your 
hosts in wheezy. I personally would go for the less-work version.

Apart from that, you could try one of these:

create and install a stub java7-runtime-headless deb just to get it in the 
installed packages list
use apt pinning to install an earlier puppetdb (but 
http://docs.puppetlabs.com/puppetdb/latest/puppetdb-faq.html#which-versions-of-java-are-supported
 if you have issues later)
import openjdk-7-jre-headless and dependencies from wheezy to your squeeze repo 
and see if it installs/functions cleanly
repackage puppetdb without that dependency (now I'm getting ridiculous)

On Tue, May 20, 2014 at 03:50:51PM -0400, Peter Berghold wrote:
>The following information may help to resolve the situation:
>The following packages have unmet dependencies:
> puppetdb : Depends: java7-runtime-headless but it is not installable or
>                     j2re1.7 but it is not installable
>E: Broken packages
> 
>On Tue, May 20, 2014 at 3:41 PM, Christopher Wood
><[1]christopher_w...@pobox.com> wrote:
> 
>  What's the error message?
>  On Tue, May 20, 2014 at 03:22:24PM -0400, Peter Berghold wrote:
>  >    Hi folks,
>  >    Attempting to install puppetdb on Debian 6 and have run into a bit
>  of a
>  >    roadblock.
>  >    It's complaining that java7 is not on the system and yet:
>  >    :/usr/lib/jvm# java -version
>  >    java version "1.7.0_51"
>  >    Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
>  >    Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
>  >    I suppose it is looking for a packaged called j2re1.7
>  >    or java7-runtime-headless.  Any way of faking this out so it works
>  with
>  >    the Oracle version?
>  >    --
>  >
>  >    Peter L. Berghold  
>  [1][2]salty.cowd...@gmail.com
>  >
>  >    [2][3]http://blog.berghold.net
>  >
>  >    --
>  >    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 [3][4]puppet-users+unsubscr...@googlegroups.com.
>  >    To view this discussion on the web visit
>  >  
>   
> [4][5]https://groups.google.com/d/msgid/puppet-users/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%40mail.gmail.com.
>  >    For more options, visit [5][6]https://groups.google.com/d/optout.
>  >
>  > References
>  >
>  >    Visible links
>  >    1. mailto:[7]salty.cowd...@gmail.com
>  >    2. [8]http://blog.berghold.net/
>  >    3. mailto:[9]puppet-users+unsubscr...@googlegroups.com
>  >    4.
>  
> [10]https://groups.google.com/d/msgid/puppet-users/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%40mail.gmail.com?utm_medium=email&utm_source=footer
>  >    5. [11]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 [12]puppet-users+unsubscr...@googlegroups.com.
>  To view this discussion on the web visit
>  
> [13]https://groups.google.com/d/msgid/puppet-users/20140520194150.GA9787%40iniquitous.heresiarch.ca.
>  For more options, visit [14]https://groups.google.com/d/optout.
> 
>--
> 
>Peter L. Berghold   [15]salty.cowd...@gmail.com
> 
>[16]http://blog.berghold.net
> 
>--
>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 [17]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [18]https://groups.google.com/d/msgid/puppet-users/CAArvnv33Ydf%2Bt3EFdyXg-398qTcH-j3_TfdKjY2Sy1HMZVPctQ%40mail.gmail.com.
>For more options, visit [19]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:christopher_w...@pobox.com
>2. mailto:salty.cowd...@gmail.com
>3. http://blog.berghold.net/
>4. mailto:puppet-u

Re: [Puppet Users] Debugging manifests with Future Parser

2014-05-20 Thread Christopher Wood

Sorry, I've stayed at 3.4.3 so that the exciting things can happen to other 
people for a while.

Were I debugging this, I'd check my data to make sure that everything was the 
same as from 3.4.2 and then try to reproduce using the simplest pp file I could 
(then maybe file a bug).

On Tue, May 20, 2014 at 01:20:37PM -0700, Jason Knudsen wrote:
>Thanks for the tip, worked like a charm. Turns out I had some variables
>with an uppercase first letter.
>Got past that, but now I'm also dealing with something else unexpected.
> 
>Info: Retrieving pluginfacts
>Info: Retrieving plugin
>Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
>Evaluation Error: Error while evaluating a Resource Statement, In
>Puppet::Pops::Types::PResourceType : Can not use a Hash where a String is
>expected at /opt/puppet/modules/nagios/manifests/init.pp:306:5 on node
>
>Warning: Not using cache on failed catalog
>Error: Could not retrieve catalog; skipping run
>Basically, in the Nagios module we loop through a hash of servers we pull
>from our ENC's API:
>serverLoop { $enc_api::servers: }
>Has the behavior altered for define's?
>Jason
>On Tuesday, May 20, 2014 4:05:33 PM UTC-4, Christopher Wood wrote:
> 
>  If you run your puppetmaster in the foreground with debug enabled it
>  might tell you more. (You'll have to stop the usual daemon first, and
>  run it as the usual user not root.)
> 
>  puppet master --debug --no-daemonize 2>&1 | tee /var/tmp/pm1.log
> 
>  Also use --config in there if you need it, of course.
> 
>  On Tue, May 20, 2014 at 12:53:39PM -0700, Jason Knudsen wrote:
>  >    Hey team,
>  >    Testing the waters with the new Future Parser functionality. 
>  >    I've enabled it in [main] and [master] with parser = future, in my
>  >    puppet.conf, and am running puppet v3.5.1. Earlier versions of
>  puppet
>  >    (namely, 3.4.2) worked fine with this setting enabled and the exact
>  same
>  >    modules. I know a lot of changes went into 3.5.0 and I'm trying to
>  track
>  >    down why it's failing..
>  >    Puppet runs look like this:
>  >    Error: Could not retrieve catalog from remote server: Error 400 on
>  SERVER:
>  >    Found 4 errors. Giving up in
>  /opt/puppet/modules/nagios/manifests/init.pp
>  >    on node 
>  >    Warning: Not using cache on failed catalog
>  >    Error: Could not retrieve catalog; skipping run
>  >    With --debug and --verbose it fails similarly without any
>  additional
>  >    information. This is a big module so it's hard to determine exactly
>  what's
>  >    failing.
>  >    Any advice on how to debug the parser itself, or get additional
>  output as
>  >    to what those 4 errors could be?
>  >
>  >    Thanks,
>  >    Jason
>  >
>  >    --
>  >    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 [1][1]puppet-users...@googlegroups.com.
>  >    To view this discussion on the web visit
>  >  
>   
> [2][2]https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com.
>  >    For more options, visit [3][3]https://groups.google.com/d/optout.
>  >
>  > References
>  >
>  >    Visible links
>  >    1. mailto:[4]puppet-users+unsubscr...@googlegroups.com
>  >    2.
>  
> [5]https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com?utm_medium=email&utm_source=footer
>  >    3. [6]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 [7]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [8]https://groups.google.com/d/msgid/puppet-users/cef444e1-3c74-4e75-b1ef-e23d54b21088%40googlegroups.com.
>For more options, visit [9]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. javascript:
>2. 
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com
>3. https://groups.google.com/d/optout
>4. javascript:
>5. 
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com?utm_medium=email&utm_source=footer
>6. https://groups.google.com/d/optout
>7. mailto:puppet-users+unsubscr...@googlegroups.com
>8. 
> https://groups.google.com/d/msgid/puppet-users/cef444e1-3c74-4e75-b1ef-e23d54b21088%40googlegroups.com?utm_medium=email&utm_source=footer
>9. https://groups.google.

Re: [Puppet Users] puppetlabs/java_ks modules and puppet:// uri paths

2014-05-20 Thread Morgan Haskel

Juan,

Are you exporting extra_files as a mountpoint in fileserver.conf?  If not
and extra_files is in a module then the path should be
puppet:///modules//extra_files/certificates/mycert.org.crt

The documentation at
http://docs.puppetlabs.com/guides/file_serving.htmlmight help.

Morgan


On Tue, May 20, 2014 at 9:30 AM, Juan Sierra Pons wrote:

> Hi,
>
> I am recently using the puppetlabs/java_ks module. The documentation
> claims that the module supports puppet:// uri path for certificates:
>
> from https://forge.puppetlabs.com/puppetlabs/java_ks:
> "
> certificate
>
> An already-signed certificate to place in the keystore. Accepts local
> file paths or puppet:// uri paths.
> "
>
> I am using the following code:
>
>   java_ks {"$hostname-$certificate":
> ensure   => latest,
> certificate   => "puppet:///extra_files/certificates/mycert.org.crt",
> target => hiera('java::keystore::path'),
> password=> hiera('java::certificate::password'),
> trustcacerts => true,
>   }
>
> But when I run the command, the following error appears:
>
> Info: Applying configuration version 'd4944df'
> Notice: /Stage[main]/Puppet::Agent::Config/Ini_setting[environment]/value:
> value changed 'working_hashes' to 'keystore'
> Error: Execution of 'keytool -importcert -noprompt -alias
> myserver-mycert.org.crt.org.crt -file
> /etc/puppet/files/certificates/mycert.org.crt -keystore /home/devops/
> .keystore -trustcacerts' returned 1: Enter keystore password:
> Re-enter new password: keytool error: java.io.FileNotFoundException:
> /etc/puppet/files/certifi
> cates/mycert.org.crt (No such file or directory)
>
> It is referencing the path on the puppet client instead of using the
> puppet:/// uri to download the certificate:
> keytool -importcert -noprompt -alias myserver-mycert.org.crt.org.crt
> -file /etc/puppet/files/certificates/mycert.org.crt -keystore
> /home/devops/
>
> Any Idea what I am doing wrong?
>
> Best regards
>
>
> --
> Juan Sierra Pons j...@elsotanillo.net
> Linux User Registered: #257202
> Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
> GPG key = 0xA110F4FE
> Key Fingerprint = DF53 7415 0936 244E 9B00  6E66 E934 3406 A110 F4FE
>
> --
>
> --
> 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/CABS%3Dy9smEYZNWrH82J2n3JEyEa-UFkrKtneVT2v_Yzg%3D4FEohw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Morgan Haskel
mor...@puppetlabs.com
Module Engineer

*Join us at PuppetConf 2014, September 23-24 in San Francisco -
http://puppetconf.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/CA%2BFnDv06c8__o%2BwF7pFM8bpSMFdQpRA%3D%3DKFn5H_V3sfSpaf5Eg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Debugging manifests with Future Parser

2014-05-20 Thread Jason Knudsen

Hah, indeed. 3.5.0 has introduced some fun changes ;-) Thanks for your help!

On Tuesday, May 20, 2014 4:42:04 PM UTC-4, Christopher Wood wrote:
>
> Sorry, I've stayed at 3.4.3 so that the exciting things can happen to 
> other people for a while. 
>
> Were I debugging this, I'd check my data to make sure that everything was 
> the same as from 3.4.2 and then try to reproduce using the simplest pp file 
> I could (then maybe file a bug). 
>
> On Tue, May 20, 2014 at 01:20:37PM -0700, Jason Knudsen wrote: 
> >Thanks for the tip, worked like a charm. Turns out I had some 
> variables 
> >with an uppercase first letter. 
> >Got past that, but now I'm also dealing with something else 
> unexpected. 
> > 
> >Info: Retrieving pluginfacts 
> >Info: Retrieving plugin 
> >Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: 
> >Evaluation Error: Error while evaluating a Resource Statement, In 
> >Puppet::Pops::Types::PResourceType : Can not use a Hash where a 
> String is 
> >expected at /opt/puppet/modules/nagios/manifests/init.pp:306:5 on 
> node 
> > 
> >Warning: Not using cache on failed catalog 
> >Error: Could not retrieve catalog; skipping run 
> >Basically, in the Nagios module we loop through a hash of servers we 
> pull 
> >from our ENC's API: 
> >serverLoop { $enc_api::servers: } 
> >Has the behavior altered for define's? 
> >Jason 
> >On Tuesday, May 20, 2014 4:05:33 PM UTC-4, Christopher Wood wrote: 
> > 
> >  If you run your puppetmaster in the foreground with debug enabled 
> it 
> >  might tell you more. (You'll have to stop the usual daemon first, 
> and 
> >  run it as the usual user not root.) 
> > 
> >  puppet master --debug --no-daemonize 2>&1 | tee /var/tmp/pm1.log 
> > 
> >  Also use --config in there if you need it, of course. 
> > 
> >  On Tue, May 20, 2014 at 12:53:39PM -0700, Jason Knudsen wrote: 
> >  >Hey team, 
> >  >Testing the waters with the new Future Parser functionality.  
> >  >I've enabled it in [main] and [master] with parser = future, 
> in my 
> >  >puppet.conf, and am running puppet v3.5.1. Earlier versions of 
> >  puppet 
> >  >(namely, 3.4.2) worked fine with this setting enabled and the 
> exact 
> >  same 
> >  >modules. I know a lot of changes went into 3.5.0 and I'm 
> trying to 
> >  track 
> >  >down why it's failing.. 
> >  >Puppet runs look like this: 
> >  >Error: Could not retrieve catalog from remote server: Error 
> 400 on 
> >  SERVER: 
> >  >Found 4 errors. Giving up in 
> >  /opt/puppet/modules/nagios/manifests/init.pp 
> >  >on node  
> >  >Warning: Not using cache on failed catalog 
> >  >Error: Could not retrieve catalog; skipping run 
> >  >With --debug and --verbose it fails similarly without any 
> >  additional 
> >  >information. This is a big module so it's hard to determine 
> exactly 
> >  what's 
> >  >failing. 
> >  >Any advice on how to debug the parser itself, or get 
> additional 
> >  output as 
> >  >to what those 4 errors could be? 
> >  > 
> >  >Thanks, 
> >  >Jason 
> >  > 
> >  >-- 
> >  >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 [1][1]puppet-users...@googlegroups.com. 
> >  >To view this discussion on the web visit 
> >  >   
> >   [2][2]
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com.
>  
>
> >  >For more options, visit [3][3]
> https://groups.google.com/d/optout. 
> >  > 
> >  > References 
> >  > 
> >  >Visible links 
> >  >1. 
> > mailto:[4]puppet-users+unsubscr...@googlegroups.com 
> >  >2. 
> >  [5]
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googlegroups.com?utm_medium=email&utm_source=footer
>  
> >  >3. [6]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 [7]puppet-users...@googlegroups.com . 
> >To view this discussion on the web visit 
> >[8]
> https://groups.google.com/d/msgid/puppet-users/cef444e1-3c74-4e75-b1ef-e23d54b21088%40googlegroups.com.
>  
>
> >For more options, visit [9]https://groups.google.com/d/optout. 
> > 
> > References 
> > 
> >Visible links 
> >1. javascript: 
> >2. 
> https://groups.google.com/d/msgid/puppet-users/00afc037-6239-4678-b17d-cd3720d1ce63%40googleg

Re: [Puppet Users] Re: Yumrepo resource flapping

2014-05-20 Thread Johan De Wit

the yumrepo resource creates a *.repo file for every resource. 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.

I did not test it in puppet3.x, but maybe it could work : still on 2.7,
and reworking our rep module is just sitting on the todo.

in redhat.rep, set enabled to 0 for all repos (augeas ?)
manage the redhat subscribed repos/channels with puppet

we do mirror all subscribes RH repos with mrepo, and point all or RH to
the local repos.
also we register our systems using the subscription manager, to our
local SAM (subscription asset manager ...)

SAM does not work with rhn, so maybe moving to the subscription thing is
not a bad idea.

something to look at ... maybe ?

grts

On 20/05/14 19:45, DjE wrote:

Le 20/05/2014 15:47, jcbollinger a écrit :

On Tuesday, May 20, 2014 3:38:51 AM UTC-5, DjE wrote:

Hi all,

We find that the yumrepo resource is flapping on RedHat 6
Enterprise with the redhat.repo file since Puppet 3.4.x version
(due to a change about attribute content control)

We have updated with the latest Puppet 3.6 server and agent,
because we saw this commit :

https://github.com/puppetlabs/puppet/commit/9c25f75febe4df7d900e553824c9379cb7367c76

,
but the resource continues to flap.

The resource we want to manage :
Yumrepo[rhel-6-server-optional-rpms]
The Puppet change : enabled changed ' 1' to '1'

RedHat want : *"enabled= 1"*
Puppet want : "enable=1"

As we can see, there is a white space on original state (RedHat
generated file).

The change occurs every 4 hour (with 30 minutes runtime interval
agent), i did not looking for the process which generate the
redhat.repo file.

rhsm (/etc/rhsm/rhsm.conf) manage the yum repo file :

# Manage generation of yum repositories for subscribed content:
manage_repos = 1

[rhsmcertd]
# Frequency of certificate refresh (in minutes):
certFrequency = 240

The certFrequency seems to match with the change which occurs
every 4 hours, i did not test it.

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/903782c7-828c-4fcb-9076-479c28650901%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi,

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, it could be a nice
thing that Puppet use the same syntax.

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.

Djé
--
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/537B94C9.6000307%40nosbox.net
.

For more options, visit https://groups.google.com/d/optout.

--
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer (805008667232363)
Puppet Certified Professional 2013/2014 (PCP006)
_

Open-Future Phone +32 (0)2/255 70 70

Zavelstraat 72 Fax +32

[Puppet Users] Raring has been removed from apt.puppetlabs.com

2014-05-20 Thread Matthaus Owens

As previously announced[1], Raring has now been removed from our
public apt repositories, as it had reached end of life.

[1] - 
https://groups.google.com/forum/#!msg/puppet-users/YEG0C3OtWfE/Nq6AUGCv5kQJ

-- 
Matthaus Owens
Puppet Labs

Join us at PuppetConf 2014, September 22-24 in San Francisco
Register by May 30th to take advantage of the Early Adopter discount —save $349!

-- 
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/CACD%3DwAd0sYkFYkAw8i%2BR8XVoP3U7DsWZVfpHdF%2BSe-68UwRkCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Profiling catalog compilation

2014-05-20 Thread Wolf Noble

Hey guys,

I wrote a post on how to profile your puppet catalog compilations (3.4+) to 
find resource hogs

Hope this helps someone

http://www.wolfspyre.com/2014/05/profiling-puppet-catalog-compilations/

-- 
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/1BC4D944-B31F-4FBC-8376-BA52FBE95B8C%40wolfspyre.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] installing puppetdb on Debian 6 [wheezy]

2014-05-20 Thread Ken Barber

The control file was modified in particular to be compatible with the
make-jpkg created packages to work around older releases like Debian 6
squeeze:

https://wiki.debian.org/JavaPackage

Unfortunately this was the closest we could find to a standard way of
supporting a dependency against a Debian 6 built JDK 7 package. Its
unfortunate openjdk 7 was never back-ported to squeeze, but these
decisions are beyond us mere mortals.

So as long as your package is built using the standard make-jpkg
instructions, this should work for you. In our tests we've created a
repo of a make-jpkg package for ourselves and it adequately works
during our acceptance tests, so it should work for others in theory -
(unless the package name was customised I suppose).

If it doesn't work, provide the details of the created package and
I'll take a look.

ken.

On Tue, May 20, 2014 at 8:22 PM, Peter Berghold  wrote:
> Hi folks,
>
> Attempting to install puppetdb on Debian 6 and have run into a bit of a
> roadblock.
>
> It's complaining that java7 is not on the system and yet:
>
> :/usr/lib/jvm# java -version
> java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
>
> I suppose it is looking for a packaged called j2re1.7 or
> java7-runtime-headless.  Any way of faking this out so it works with the
> Oracle version?
>
>
>
> --
>
> Peter L. Berghold   salty.cowd...@gmail.com
>
> http://blog.berghold.net
>
> --
> 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/CAArvnv07%3DfCFnUfJ1LAZUjpHbVYXYx_0PQSCJZgqOpGg1pLM1A%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/CAE4bNT%3D68T5gQQmbN0U7vRzBKCoOLmFUiNoSVc-WgrEJToqjWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2014-05-20 Thread Jakov Sosic


On 05/16/2014 12:34 PM, Ugo Bellavance wrote:


Do I need the puppet concat module to do that?  I am on  puppet version
2.6 (using EPEL repo, "upgrading" to 2.7 soon.  I know it is not what
this group recommends, but it's the best for me right now).


Yes, you do if you use the code I provided.

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

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

2014-05-20 Thread Ugo Bellavance

On Tuesday, May 20, 2014 8:47:58 PM UTC-4, Jakov Sosic wrote:
>
> On 05/16/2014 12:34 PM, Ugo Bellavance wrote: 
>
> > Do I need the puppet concat module to do that?  I am on  puppet version 
> > 2.6 (using EPEL repo, "upgrading" to 2.7 soon.  I know it is not what 
> > this group recommends, but it's the best for me right now). 
>
> Yes, you do if you use the code I provided. 
>
> Thanks,

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.

-- 
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/8faad397-8954-48a4-9873-7600f4efd84f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Creating a config file dynamically based on the group membership of a node

2014-05-20 Thread Grant Street



On Wednesday, May 21, 2014 12:31:59 AM UTC+10, jcbollinger wrote:
>
>
>
> On Monday, May 19, 2014 2:39:47 AM UTC-5, Grant Street wrote:
>>
>> Hi 
>>
>> First time poster to this forum. I'm in the process of doing a pilot to 
>> convert a cfengine v2 install to puppet.
>>
>> I was wondering if any one had any ideas on the following. 
>>
>> I have machines that can be in any combination(ie 0  or more) of 10 
>> groups, that can change. I need to create an access.conf based on the group 
>> membership of the node. 
>> I would like the file to be dynamically created with any redundant lines 
>> removed. 
>>
>> I have had a look at augeus but  I can't see how to both add lines based 
>> on the group as well as remove unwanted and unknown lines. 
>> I have also had a look at templates but unsure how that would look like 
>> when the you have 0-10 insertion points 
>>
>>
>
> A template is probably the way to go.  The point to understand there is 
> that you will be templating the entire contents of the file, not just the 
> lines related to the 10 groups.  Supposing that you have an array of the 
> names of the wanted groups, then, your template might look like this:
>
> +:root:LOCAL
> <% @wanted_groups.each do |g| -%>
> +:(<%= g %>):ALL
> <% end -%>
> -:ALL:ALL
>
>
> John
>
>  Hi John 

Thanks a lot for the guidance my solution would have been a whole lot more 
messy. 

I was able to massage your example so that I could use a hash to specify 
the user and origin like this
+:root:LOCAL
<% pam_access.each_pair do |user,origin| -%>
+:<%= user %>:<%= origin %>
<% end -%>
-:ALL:ALL

Now what is the best way to dynamically create the array/hash? I am doing a 
hash merge at the moment  is there a better/more puppet way?

Thanks

 

-- 
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/75b1fcd4-4315-40b0-9924-38557eece79d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Creating a config file dynamically based on the group membership of a node

2014-05-20 Thread Garrett Honeycutt

On 5/21/14, 12:40 AM, Grant Street wrote:
> 
> 
> On Wednesday, May 21, 2014 12:31:59 AM UTC+10, jcbollinger wrote:
> 
> 
> 
> On Monday, May 19, 2014 2:39:47 AM UTC-5, Grant Street wrote:
> 
> Hi
> 
> First time poster to this forum. I'm in the process of doing a
> pilot to convert a cfengine v2 install to puppet.
> 
> I was wondering if any one had any ideas on the following.
> 
> I have machines that can be in any combination(ie 0  or more) of
> 10 groups, that can change. I need to create an access.conf
> based on the group membership of the node.
> I would like the file to be dynamically created with any
> redundant lines removed.
> 
> I have had a look at augeus but  I can't see how to both add
> lines based on the group as well as remove unwanted and unknown
> lines.
> I have also had a look at templates but unsure how that would
> look like when the you have 0-10 insertion points
> 
> 
> 
> A template is probably the way to go.  The point to understand there
> is that you will be templating the entire contents of the file, not
> just the lines related to the 10 groups.  Supposing that you have an
> array of the names of the wanted groups, then, your template might
> look like this:
> 
> +:root:LOCAL
> <% @wanted_groups.each do |g| -%>
> +:(<%= g %>):ALL
> <% end -%>
> -:ALL:ALL
> 
> 
> John
> 
>  Hi John
> 
> Thanks a lot for the guidance my solution would have been a whole lot
> more messy.
> 
> I was able to massage your example so that I could use a hash to specify
> the user and origin like this
> +:root:LOCAL
> <% pam_access.each_pair do |user,origin| -%>
> +:<%= user %>:<%= origin %>
> <% end -%>
> -:ALL:ALL
> 
> Now what is the best way to dynamically create the array/hash? I am
> doing a hash merge at the moment  is there a better/more puppet way?
> 
> Thanks
> 
>  
> 
> -- 
> 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/75b1fcd4-4315-40b0-9924-38557eece79d%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

Hi Grant,

I have a puppet module[1] for PAM that manages access.conf. You can
specify an array in Hiera with the key pam::allowed_users. Currently it
uses a parameterized class which will look up the value in Hiera and
stop on the first match. The code could be changed to allow for the use
of the hiera_array[2] function which would return all instances found in
Hiera. So if your groups are defined at multiple levels of the
hierarchy, you would want that functionality. Here's an example[3] of
how you might add it. I would be happy to work with you on a pull request.


[1] - https://github.com/ghoneycutt/puppet-module-pam

[2] - http://docs.puppetlabs.com/references/latest/function.html#hieraarray

[3] -
https://github.com/ghoneycutt/puppet-module-ssh/blob/master/manifests/init.pp#L534-544

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

[Puppet Users] Re: Profiling catalog compilation

2014-05-20 Thread William Leese

Great stuff, thanks for this. Would be nice to get this kind of 
troubleshooting in the official docs somewhere.

-- 
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/0e014a92-d52c-4bcc-a5ca-f4b79a2cf138%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetlabs/java_ks modules and puppet:// uri paths

2014-05-20 Thread Juan Sierra Pons

Hi Morgan,

Yes, I have configured [extra_files] and it is working ok with other
module. The isue here is that instead of downloading the file
mycert.org.crt and using it while running the local command it
references it as if the certificate were already on the client and
using the [extra_files] actual path (on the puppetmaster)

This is the command (as seen on debug)
keytool -importcert -noprompt -alias myserver-mycert.org.crt.org.crt
-file /etc/puppet/files/certificates/mycert.org.crt -keystore
/home/devops/

/etc/puppet/files/certificates/mycert.org.crt is the actual path but
on the puppetmaster.

BTW: there is an open bug about this:
https://tickets.puppetlabs.com/browse/MODULES-559

Thanks for your time

Best regards
--
Juan Sierra Pons j...@elsotanillo.net
Linux User Registered: #257202
Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00  6E66 E934 3406 A110 F4FE
--


2014-05-20 22:55 GMT+02:00 Morgan Haskel :
> Juan,
>
> Are you exporting extra_files as a mountpoint in fileserver.conf?  If not
> and extra_files is in a module then the path should be
> puppet:///modules//extra_files/certificates/mycert.org.crt
>
> The documentation at http://docs.puppetlabs.com/guides/file_serving.html
> might help.
>
> Morgan
>
>
> On Tue, May 20, 2014 at 9:30 AM, Juan Sierra Pons 
> wrote:
>>
>> Hi,
>>
>> I am recently using the puppetlabs/java_ks module. The documentation
>> claims that the module supports puppet:// uri path for certificates:
>>
>> from https://forge.puppetlabs.com/puppetlabs/java_ks:
>> "
>> certificate
>>
>> An already-signed certificate to place in the keystore. Accepts local
>> file paths or puppet:// uri paths.
>> "
>>
>> I am using the following code:
>>
>>   java_ks {"$hostname-$certificate":
>> ensure   => latest,
>> certificate   => "puppet:///extra_files/certificates/mycert.org.crt",
>> target => hiera('java::keystore::path'),
>> password=> hiera('java::certificate::password'),
>> trustcacerts => true,
>>   }
>>
>> But when I run the command, the following error appears:
>>
>> Info: Applying configuration version 'd4944df'
>> Notice: /Stage[main]/Puppet::Agent::Config/Ini_setting[environment]/value:
>> value changed 'working_hashes' to 'keystore'
>> Error: Execution of 'keytool -importcert -noprompt -alias
>> myserver-mycert.org.crt.org.crt -file
>> /etc/puppet/files/certificates/mycert.org.crt -keystore /home/devops/
>> .keystore -trustcacerts' returned 1: Enter keystore password:
>> Re-enter new password: keytool error: java.io.FileNotFoundException:
>> /etc/puppet/files/certifi
>> cates/mycert.org.crt (No such file or directory)
>>
>> It is referencing the path on the puppet client instead of using the
>> puppet:/// uri to download the certificate:
>> keytool -importcert -noprompt -alias myserver-mycert.org.crt.org.crt
>> -file /etc/puppet/files/certificates/mycert.org.crt -keystore
>> /home/devops/
>>
>> Any Idea what I am doing wrong?
>>
>> Best regards
>>
>>
>> --
>> Juan Sierra Pons j...@elsotanillo.net
>> Linux User Registered: #257202
>> Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
>> GPG key = 0xA110F4FE
>> Key Fingerprint = DF53 7415 0936 244E 9B00  6E66 E934 3406 A110 F4FE
>>
>> --
>>
>> --
>> 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/CABS%3Dy9smEYZNWrH82J2n3JEyEa-UFkrKtneVT2v_Yzg%3D4FEohw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Morgan Haskel
> mor...@puppetlabs.com
> Module Engineer
>
> Join us at PuppetConf 2014, September 23-24 in San Francisco -
> http://puppetconf.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/CA%2BFnDv06c8__o%2BwF7pFM8bpSMFdQpRA%3D%3DKFn5H_V3sfSpaf5Eg%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

59 matches

Mail list logo