Re: [Puppet Users] puppet in epel

2018-04-08 Thread Poil

Hello ?

Don't use EPEL, use the official Puppet repository


Le 05/04/2018 à 16:27, Michael Di Domenico a écrit :
does anyone know who or how puppet gets into epel? the packages for 
puppet/facter in epel are woefully out of date.

--
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/02d95b7e-2cb9-49a8-95f7-d2a1985d622b%40googlegroups.com 
.

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



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2ad6a3e7-f52d-8cc6-2b37-a4ea1276511c%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] General performance questions in Puppetserver 2.8

2018-02-11 Thread Poil
Here at Claranet France, when we've switched to Puppet4, we've made 
several mistake
First, the environment cache wasn't enable, and the performance with 
Puppet4 is very bad when it's not.
Second, when we've reached 3000 nodes (we have 4 master nodes, 48 core, 
64GB, behind 2 HaProxy) the catalog application (not compute) became 
slow and slower. we tried to increase the number of JRuby instances from 
4 (max in auto mode) to 12 but we had very high load and crashes. The 
problem is that the JVM memory is shared between all JRuby Instance, so 
just increase th xmx/xms to 1GB per JRuby instance seems to have 
resolved all our performance problem.


Now our catalog application time is about 50% faster than on our old 
Puppet3 infrastructures (we've also switch all our agent to Puppet4).


Best regards,

Le 11/02/2018 à 02:39, Ramin K a écrit :
tos 6 running Puppet 3.8.x. Ruby 1.8.7 so no http multiplexing. 50% of 
agents on Centos 7 w/



--
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/e6229fd1-1486-9619-9bd5-dfa001f545c6%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Active - passive Puppetserver setup with puppet5.1

2018-01-31 Thread Poil

Hey,

Puppet is scalable don't do this !

Use DNS SRV records to balance around your Puppet Servers
Use a version control software like GIT for managing and deploying your 
code between your Puppet Servers. You can search for R10K


This documentation haven't been rewrited for Puppet4 but is still valid.
https://docs.puppet.com/puppet/3/scaling_multiple_masters.html

Best regards

Le 30/01/2018 à 11:52, Mathew Jose a écrit :
I want to setup 2 centos servers to act as puppetservers with 
active-passive mode.


I am not sure  the below plan is good to go , can any of you have a 
look in to it and suggest me ?



  * One puppet server is the CA master  (Uses the Name :puppet )
  * A second Puppet master  ( Name :Puppet-passive ) using the CA
master (Name:puppet) for SSL

  * Each puppet master has a cron to regularly do a 'git pull' of the
puppet environment git repos to /etc/puppetlabs/code/environments
so all agents use the same code.

On the first puppetmaster (puppet)  that will also be the CA master

a)Install puppetserver

b) In its /etc/puppetlabs/puppet/puppet.conf [main] section:

  o server = 
  o ca_server = 
  * Startup puppetserver on it
  * Put  code into /etc/puppetlabs/code/environments
  * Configure it to be an agent to itself and ensure it successfully
runs before proceeding

On other master ( puppet-passive ):

  * Install puppetserver
  * Setup the git repos into /etc/puppetlabs/code/environments as you
did for the CA master
  * In its /etc/puppetlabs/puppet/puppet.conf [main] section:
  o server = 
  o ca_server = 
  * In its [agent] section, make its 'server' be the CA master and set
the correct environment
  * Run the agent successfully (against the CA master), then make
'server' be its own FQDN, then run it successfully again

But I am not sure how to failover from the active master server to 
passive one in case of a requirement.




--
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/6fcffed5-ed0f-432e-b953-cc01c0da7d1e%40googlegroups.com 
.

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



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/64eb1763-13ae-03c8-90f6-ffcb3fd5cc68%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppet5 upgrade performance issues

2018-01-10 Thread Poil

Hey,

Are you sure that you have environment cache enabled on your Puppet5 
installation ? (because x10 is what we have here when we disable it)


ref. https://www.example42.com/2017/03/27/environment_caching/

Best regards,

Le 09/01/2018 à 04:31, chris smith a écrit :

Hi there,

I recently did an upgrade from puppetserver 2.7.2 to puppetserver 5.0 
and performance has bottomed out pretty terribly. Agents and puppetdb 
also got updated. Compiling the catalog on the server used to take 
10-20 seconds, now they are taking 90-150 seconds and agent runs are 
taking 30+ minutes (used to be a couple of minutes).


The architecture is distributed, with:
 * a central ca, running puppetserver, puppetdb, postgres 9.6
 * separate puppetservers replicated in other datacentres. These are 
also running puppetdb, pointing writes to the central ca, but reads go 
to a locally replicated database


Other servers (agents) point to the replicated puppetservers to do all 
of the work.


The puppetservers were tuned (upped jvm memory, set max-instances).

The architecture hasn't changed since the upgrade.

The puppetservers are still running hiera3 configs, they haven't been 
converted yet (it's on the list, but from what I read it wasn't a 
showstopper). We have a reasonable amount of encrypted yaml files 
(using hiera-eyaml-gpg), though this was the same as pre-upgrade and 
hasn't changed significantly.


Since the upgrade, I've tried re-tuning the jvm settings, changing 
max-instances and not having much luck at all. I found the 
experimental dashboard on the puppetservers and they show that there 
are no free jruby's, but there has to be something I'm missing that's 
causing that to happen.


I'm lost on what to look at next, is there an easy way to peak inside 
jruby to see what's taking so long?


Any suggestions would be great.

Cheers,
Chris.

--
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/4d0dc37f-c07e-4f8c-8323-44a90d68b208%40googlegroups.com 
.

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



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b90ba6c6-d3fa-dcff-dfe9-aac05523c01d%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Unable to bootstrap modern Puppet-agent versions via cloud-config. How to set "certname=%i.%f"?

2017-11-07 Thread Poil

Hey,

Why not just create a symlink ?

Also you should open a bug report https://launchpad.net/cloud-init

Best regards,

Le 07/11/2017 à 18:04, Martijn a écrit :

Hi all,

We deploy Ubuntu 14.04 and 16.04 instances in AWS and use cloud-init 
to bootstrap them. Specifically we pass them user-data in 
'cloud-config' yaml format (one of the formats that cloud-init 
understands).


Now that we've migrated to Puppet 4.10+ I'm having trouble finding the 
correct syntax to dynamically set the certname for the agent. I'd like 
the certname to contain the instance-id and the fqdn. It seems the 
Cloud-config format was never updated to deal with modern Puppet versions.


Previously, with Puppet 3.x we used the following:

|

fqdn: test01.example.com
|apt:
  sources:
    puppetlabs.list:
      source: "deb http://apt.puppetlabs.com $RELEASE main dependencies"
      keyid: 6F6B15509CF8E59E6E469F327F438280EF8D349F|
apt_update: true
apt_upgrade: true
packages:
 - puppet
puppet:
  conf:
    agent:
      server: "puppet.example.com"
      certname: "%i.%f"
|

The last hash (puppet.conf.agent) would generate a file 
/etc/puppet/puppet.conf containing a line like 
certname=i-197f2394.test01.example.com which was fine for Puppet 3, 
but not 4 or 5.


For Puppet 4 the correct path is|/etc/puppetlabs/puppet/puppet.conf 
but cloud-init doesn't appear to know that so I came up with the 
following new cloud-config that simply writes the correct file:|


|

fqdn: test01.example.com
apt:
  sources:
    puppetlabs-pc1.list:
      source: "deb http://apt.puppetlabs.com $RELEASE PC1"
      keyid: 6F6B15509CF8E59E6E469F327F438280EF8D349F
package_update: true
package_upgrade: true
packages:
  - puppet-agent
write_files:
  - path: /etc/puppetlabs/puppet/puppet.conf
    content:
        [agent]
        certname="%i.%f"
        server=puppet.insiders.nl
|

Unfortunately, the %i and %f variables are never replaced by the 
instance-id and fqdn, as they were previously. I've tried half a dozen 
variations, but none appear to work. Variable interpolation appears to 
be limited to the old "puppet.conf.agent" style.


How do *you* bootstrap your Puppet nodes on AWS?
How do you dynamically set the certname these days?

Thanks, Martijn
--
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/68494e23-bc06-43e2-9329-d308c6fdb1c4%40googlegroups.com 
.

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



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ac5eac2d-04db-21e1-b51b-d305db825722%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetServer 2.8 resource Leak

2017-10-18 Thread Poil

The Trocla leak seems to be in the trocla-hiera-backend

diff --git a/lib/puppet/functions/trocla_lookup_key.rb 
b/lib/puppet/functions/trocla_lookup_key.rb
index d377ec8..f61df46 100644
--- a/lib/puppet/functions/trocla_lookup_key.rb
+++ b/lib/puppet/functions/trocla_lookup_key.rb
@@ -33,6 +33,8 @@ Puppet::Functions.create_function(:trocla_lookup_key) do
   trocla_hierarchy(trocla_key, format, opts)
 end
 
+@trocla.close

+
 context.not_found unless res
 context.cache(key, res)
   end


Le 18/10/2017 à 10:01, Poil a écrit :

Hi,

There still a leak on Trocla database connections (latest 
gem/module/hiera backend).


I've installed a puppetserver, with only a node connected on; after 5 
days, there is 240 opened connections.


Best regards,


Le 16/10/2017 à 09:44, Poil a écrit :

Hi,

We have upgrade to Hiera Backend v5 (and to the new trocla v5 backend)

There still a leak but it seems to be very very low.

I've also switched in our site.pp all hiera/hiera_hash/hiera_array 
call to lookup. We still have some hiera* function call in some 
module, I'm asking myself if the leak is not in these functions.


Best regards,


Le 06/10/2017 à 12:40, Poil a écrit :

Hi,

The database connections leak remains after upgrading trocla.
Also after 2 days the catalog computation times start to increase 
again.
I'm going to install newrelic on a puppetserver and if I see nothing 
I will try to analyze via your blog article.


Best regardsLe 4 oct. 2017 10:58, Poil <p...@quake.fr> a écrit :

Hi,

Thanks !

We had Trocla 0.2.3, and module 0.2.2 I'm upgrading to Trocla 0.3.0 
and

latest module code

Best regards,


Le 04/10/2017 à 08:27, Peter Meier a écrit :

We are on hiera v3, we only tuned "max-requests-per-instance: 5000"
because of a databases connection leak with our Trocla library.
This is fixed with the trocla module 1.0.1 [1] are you on that 
version?


best

~pete

[1]
https://github.com/duritong/puppet-trocla/commit/bbedb788a7951e2f69c1c2815a5c3c669ff02ae6 




--
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/675be630-3ef4-e316-6d05-d6000eaadd6c%40quake.fr.

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/a1bca6b3-5824-b97f-117f-95f22c7588ab%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetServer 2.8 resource Leak

2017-10-18 Thread Poil

Hi,

There still a leak on Trocla database connections (latest 
gem/module/hiera backend).


I've installed a puppetserver, with only a node connected on; after 5 
days, there is 240 opened connections.


Best regards,


Le 16/10/2017 à 09:44, Poil a écrit :

Hi,

We have upgrade to Hiera Backend v5 (and to the new trocla v5 backend)

There still a leak but it seems to be very very low.

I've also switched in our site.pp all hiera/hiera_hash/hiera_array 
call to lookup. We still have some hiera* function call in some 
module, I'm asking myself if the leak is not in these functions.


Best regards,


Le 06/10/2017 à 12:40, Poil a écrit :

Hi,

The database connections leak remains after upgrading trocla.
Also after 2 days the catalog computation times start to increase again.
I'm going to install newrelic on a puppetserver and if I see nothing 
I will try to analyze via your blog article.


Best regardsLe 4 oct. 2017 10:58, Poil <p...@quake.fr> a écrit :

Hi,

Thanks !

We had Trocla 0.2.3, and module 0.2.2 I'm upgrading to Trocla 0.3.0 and
latest module code

Best regards,


Le 04/10/2017 à 08:27, Peter Meier a écrit :

We are on hiera v3, we only tuned "max-requests-per-instance: 5000"
because of a databases connection leak with our Trocla library.
This is fixed with the trocla module 1.0.1 [1] are you on that 
version?


best

~pete

[1]
https://github.com/duritong/puppet-trocla/commit/bbedb788a7951e2f69c1c2815a5c3c669ff02ae6 




--
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/675be630-3ef4-e316-6d05-d6000eaadd6c%40quake.fr.

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/17920f2d-5028-04c7-d389-c093be441ea5%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetServer 2.8 resource Leak

2017-10-16 Thread Poil

Hi,

We have upgrade to Hiera Backend v5 (and to the new trocla v5 backend)

There still a leak but it seems to be very very low.

I've also switched in our site.pp all hiera/hiera_hash/hiera_array call 
to lookup. We still have some hiera* function call in some module, I'm 
asking myself if the leak is not in these functions.


Best regards,


Le 06/10/2017 à 12:40, Poil a écrit :

Hi,

The database connections leak remains after upgrading trocla.
Also after 2 days the catalog computation times start to increase again.
I'm going to install newrelic on a puppetserver and if I see nothing I will try 
to analyze via your blog article.

Best regardsLe 4 oct. 2017 10:58, Poil <p...@quake.fr> a écrit :

Hi,

Thanks !

We had Trocla 0.2.3, and module 0.2.2 I'm upgrading to Trocla 0.3.0 and
latest module code

Best regards,


Le 04/10/2017 à 08:27, Peter Meier a écrit :

We are on hiera v3, we only tuned  "max-requests-per-instance: 5000"
because of a databases connection leak with our Trocla library.

This is fixed with the trocla module 1.0.1 [1] are you on that version?

best

~pete

[1]
https://github.com/duritong/puppet-trocla/commit/bbedb788a7951e2f69c1c2815a5c3c669ff02ae6


--
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/675be630-3ef4-e316-6d05-d6000eaadd6c%40quake.fr.
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/ed396e6a-1201-8b85-3a56-c3d67da0819d%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetServer 2.8 resource Leak

2017-10-06 Thread Poil
Hi,

The database connections leak remains after upgrading trocla. 
Also after 2 days the catalog computation times start to increase again.
I'm going to install newrelic on a puppetserver and if I see nothing I will try 
to analyze via your blog article. 

Best regardsLe 4 oct. 2017 10:58, Poil <p...@quake.fr> a écrit :
>
> Hi, 
>
> Thanks ! 
>
> We had Trocla 0.2.3, and module 0.2.2 I'm upgrading to Trocla 0.3.0 and 
> latest module code 
>
> Best regards, 
>
>
> Le 04/10/2017 à 08:27, Peter Meier a écrit : 
> >> We are on hiera v3, we only tuned  "max-requests-per-instance: 5000" 
> >> because of a databases connection leak with our Trocla library. 
> > This is fixed with the trocla module 1.0.1 [1] are you on that version? 
> > 
> > best 
> > 
> > ~pete 
> > 
> > [1] 
> > https://github.com/duritong/puppet-trocla/commit/bbedb788a7951e2f69c1c2815a5c3c669ff02ae6
> >  
> > 
>
> -- 
> 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/675be630-3ef4-e316-6d05-d6000eaadd6c%40quake.fr.
>  
> 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/201710061040.v96AePwT024560%40smtp5.infomaniak.ch.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetServer 2.8 resource Leak

2017-10-04 Thread Poil

Hi,

Thanks !

We had Trocla 0.2.3, and module 0.2.2 I'm upgrading to Trocla 0.3.0 and 
latest module code


Best regards,


Le 04/10/2017 à 08:27, Peter Meier a écrit :

We are on hiera v3, we only tuned  "max-requests-per-instance: 5000"
because of a databases connection leak with our Trocla library.

This is fixed with the trocla module 1.0.1 [1] are you on that version?

best

~pete

[1]
https://github.com/duritong/puppet-trocla/commit/bbedb788a7951e2f69c1c2815a5c3c669ff02ae6



--
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/675be630-3ef4-e316-6d05-d6000eaadd6c%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetServer 2.8 resource Leak

2017-10-03 Thread Poil

Hi,

We have PuppetServer 2.8 on RHEL7.

After some days computation of the catalog become slower and slower; the 
load average of the compute nodes increased and the compute goes in timeout.


All our 4 computes nodes have 48 cores, only 10% of each core is used 
when the timeout occured.


We are on hiera v3, we only tuned  "max-requests-per-instance: 5000" 
because of a databases connection leak with our Trocla library.


Only 150 nodes are connected to our PuppetServer.

We never had this problem with Puppet3 (with more than 3000 nodes)

Anyone have already see this or have a tips to resolv this ?

Best regards,

--
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/c6a457e9-5caf-f048-68b7-9dbdc867a5bb%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] stop service after install

2017-05-17 Thread Poil
I'm agree with "Debian is just by design stupid, thinks starting all 
services"
All other integration are really fine, but  auto-starting after install 
is terrible for all configuration management :
Change a path (mysql binary log for example), a mount point (a LV for 
mysql) before installing : Nope you can't
You have to write a hack to remove all autostart from the package before 
installing it that's incredible.


I dream about a Debian mix with RedHat, RPM, no auto-start but all the 
configuration system from Debian (splited-conf for apache php ... and 
tools to manage your modules)



Le 17/05/2017 à 19:21, John Gelnaw a écrit :

On Monday, May 15, 2017 at 8:16:38 AM UTC-4, R.I. Pienaar wrote:


debian will not overwrite configs on package install - suggest you
put a
config down that does what you want first.


Or, I dunno, maybe he could could tie the service to the config file, 
and restart apache when the config file changes, and "require" the 
apache2 class as part of his nginx setup.


So Puppet would install apache (starting the service), install the 
config file (restarting apache), and then install nginx.


|
classapache2 {

  $pkglist =['apache2','apache2-dev',]

package{$pkglist:
ensure=>latest,
alias=>'apache2'
}
  file {'/etc/apache2/conf.d/ports.conf':
content =>'Listen 127.0.0.1:80',
require=>Package['apache2'],
notify =>Service['apache2']
}
  service {'apache2':
ensure=>running,
refreshonly =>true
}
}

classnginx {

requireapache2

package{...}

  service {...}

}
|

That's just off the top of my head, and isn't really The Right Way, 
but it's got all the components.


Debian is just by design stupid, thinks starting all services
unconfigured on install is a good idea, suggest you use a OS
designed to
be used on servers and not peoples basements.


That is probably the single worst piece of advice I've seen on this 
forum.  It's hostile, short-sighted, and not terribly useful.


Debian has been a better "server" OS for years, in that it supports 
in-place upgrades, and makes it easier to control which packages are 
installed from which repositories.


Our environment has about 200 web and database servers, about 60% of 
which are Red Hat, and the rest are Debian.  They're both perfectly 
good operating systems for production servers, but they do require the 
admin be open-minded enough to actually learn the differences between 
the two paradigms-- otherwise, you might as well run Windows.


--
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/a3979ccc-0761-4a26-8a3d-26d38ff7f6bb%40googlegroups.com 
.

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



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f8810064-75c6-ee73-5e45-4384b7ab471f%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] stop service after install

2017-05-14 Thread Poil

Why do you want to stop it ? I think you want to change the listen port.

So I think something like this will do the job :

package { 'apache2': ensure => installed, }

service { 'apache2':
  ensure => running,
  enable => true,
}

file { '/etc/apache2/conf.d/listen_port.conf':
  content => "your_template.conf.erb",
  require => Package['apache2'],
  notify => Service['apache2'], # Refresh apache after the listen_port 
is changed

}

package {'nginx':
  ensure => installed,
  require => Service['apache2'], # Install nginx after apache have been 
restarted with another config

}


Le 13/05/2017 à 11:45, Anton Gorlov a écrit :

Hi.

I need stop service (apache) after it install from puppet.
platform is debian 9 and puppet version is 4.8.2

I my class i wrote:


class webpackages {

exec { 'apachechk':
 command => "/bin/systemctl stop apache2;",
 onlyif => "/bin/grep -c 'Listen 80' /etc/apache2/ports.conf",
}

package { 'libapache2-mpm-itk':
ensure => latest,
}

package { 'apache2':
require => Exec['apachechk'],
ensure => latest,
}

package { 'apache2-dev':
ensure => latest,
}
package { 'apache2-suexec-pristine':
ensure => latest,
}
package { 'apache2-utils':
ensure => latest,
}
package { 'apache2-bin':
ensure => latest,
}
package { 'apachetop':
ensure => latest,
}
package { 'libapache2-mod-rpaf':
ensure => latest,
}
package { 'nginx-light':
require => Exec['apachechk'],
ensure => latest,
}

}
===

but apache not stopping and install nginx is fail because port is busy
by apache

May 13 12:21:29 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
[::]:8…se)
May 13 12:21:29 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
0.0.0.…se)
May 13 12:21:29 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
[::]:8…se)
May 13 12:21:30 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
0.0.0.…se)
May 13 12:21:30 debian9-lab3 nginx[19538]: nginx: [emerg] listen() to
[::]:8…se)
May 13 12:21:30 debian9-lab3 nginx[19538]: nginx: [emerg] still could
not bind()

What is wrong and what is right way to do it?



--
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/7f0333ac-2aff-d936-3337-d1fb143019ae%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Puppet4 $facts syntax

2017-03-10 Thread Poil

@all, thanks :)

Le 10/03/2017 à 14:10, R.I.Pienaar a écrit :


On Fri, Mar 10, 2017, at 14:06, Dirk Heinrichs wrote:

Am 10.03.2017 um 14:02 schrieb R.I.Pienaar:


the first is just wrong

OTOH, I mostly use $::facts['fact_name'].

this is not needed.

The reason you use $::foo is because of the problem here:

   $foo = "top"
   class x($foo="class") {
 notice($foo)
 notice($::foo)
   }

   include x

this produce:

Notice: Scope(Class[X]): class
Notice: Scope(Class[X]): top

you need to guard against the accidental $foo which used to be much
worse with dynamic scope, so the code got littered with all this ::
rubbish.

$facts is globally reserved

   class x {
 $facts = {}
   }

   include x

Error: Evaluation Error: Error while evaluating a '=' expression,
Attempt to assign to a reserved variable name: 'facts'

You can never cause the problem that raised the need for $::facts to
exist, you can just use $facts and it's all sweet and

In general with Puppet 4 the needs for all the :: stuff is almost all
gone



--
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/d9f72063-37a3-9cbd-679d-161e8ab9e90e%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Puppet4 $facts syntax

2017-03-10 Thread Poil

Hi,

In the style guide we have $facts[::operatingsystem]

In all others documentation we have $facts['fact_name']

So which one is the good one ? Do we really need to scope inside 
$facts[::scope] ?


Best regards,

--
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/a36da126-c413-0487-2bd6-e978e3f70ca3%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Announce: Facter 2.4.5 Available

2016-01-22 Thread Poil

"Bug fix: Use public IP address for the |ipaddress| fact"

This is the most stupid things you did !


Le 22/01/2016 19:27, Hailee Kenney a écrit :
Facter 2.4.5 is a backwards-compatible bug-fix release in the Facter 2 
series.


This release includes minor bug fixes to several different facts.

To download Facter, follow the instructions here: 
http://docs.puppetlabs.com/puppet/3.8/reference/pre_install.html


Release notes are available here: 
https://docs.puppetlabs.com/facter/2.4/release_notes.html#facter-245
A complete list of issues fixed in the release is available here: 
https://tickets.puppetlabs.com/browse/FACT-380?filter=17113
We're tracking bugs with an "Affected Version" of "2.4.5" here: 
https://tickets.puppetlabs.com/browse/FACT-1316?filter=17114


--
Hailee Kenney
hai...@puppetlabs.com 
Software Developer, Puppet Labs
--
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/CALdYGa9Uez2X_Udcp-N6Zrm72gCkvne%2Bgjbj5W0fWi85Zo4jPA%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/56A2A494.60002%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] best practice for multiple Puppet masters and external CAs in AWS?

2015-10-20 Thread Poil

Hi,

You can use incron+scp or a daemon like csync2  to synchronize your 
certificates folder
Or if you are in US just use an EFS (you can also use s3fs but it's 
unstable)
For AutoScaling, I use a generic certificate and I force the node_name 
to the Tag "Name" (example : https://gist.github.com/ahpook/1182243)


Cu

Le 19/10/2015 22:08, Erik Kennedy a écrit :
However, I still need to either have one system serve as the 
certificate authority which reintroduces the SPOF or I need to sort 
out how best to use an external CA with Puppet. A


--
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/5625DDEE.1010201%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Announce: Puppet 3.8.1 available

2015-05-26 Thread Poil

Hi,

PUP-1208 is not included :( ?

Best regards,

Le 27/05/2015 01:44, Kylo Ginsberg a écrit :


Puppet 3.8.1 is a bug fix release (with future parser changes) in the 
Puppet 3.8 series. It’s first official open source release in the 3.8 
series.



The main focus of this release is to make sure the 3.8 future parser 
is forward-compatible with the Puppet language as of Puppet 4.1. It 
also fixes several bugs.



Check out the release notes for more information:

https://docs.puppetlabs.com/puppet/3.8/reference/release_notes.html#puppet-381


You can see the full list of changes on the release's JIRA page:

https://tickets.puppetlabs.com/secure/ReleaseNote.jspa?version=13116styleName=projectId=10102


If you're installing Puppet for the first time, follow the 
Installation Guide: 
https://docs.puppetlabs.com/guides/install_puppet/pre_install.html



--
Kylo Ginsberg | k...@puppetlabs.com mailto:k...@puppetlabs.com | 
irc: kylo | twitter: @kylog

*
*
*PuppetConf 2015 http://2015.puppetconf.com/ is coming to Portland, 
Oregon! Join us October 5-9.*
/Register now to take advantage of the Early Adopter discount 
https://www.eventbrite.com/e/puppetconf-2015-october-5-9-tickets-13115894995?discount=EarlyAdopter 
//—//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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CALsUZFHNOBN-W7rzHxat2vdVVPW5Ed1szVNXsEZHc6ytfeiUSA%40mail.gmail.com 
https://groups.google.com/d/msgid/puppet-users/CALsUZFHNOBN-W7rzHxat2vdVVPW5Ed1szVNXsEZHc6ytfeiUSA%40mail.gmail.com?utm_medium=emailutm_source=footer.

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/55655BD4.4080902%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Facter : no operatingsystemrelease on CentOS 7

2015-05-26 Thread Poil

If you install from an ISO, redownload it

Le 26/05/2015 20:28, Claude a écrit :
I just found out about the source of the bug : 
https://tickets.puppetlabs.com/browse/FACT-893.


Indeed a yum update solves the problem but since I must run puppet 
before that, I found the following workaroud is also valid:


ln -s -f /etc/centos-release /etc/redhat-release

Thanks

Le mardi 26 mai 2015 14:06:48 UTC-4, Poil a écrit :

Hi,


http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html
http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html

https://tickets.puppetlabs.com/browse/FACT-893
https://tickets.puppetlabs.com/browse/FACT-893

Just run yum update



Le 26/05/2015 18:32, Claude a écrit :

Hi,

I'm testing the Openstack CentOS 7 image with Puppet 3.7.5. My
problem is with Facter not identifying correctly the operating
system :

[root@test2 vendor_ruby]# facter --version
2.4.4

[root@test2 vendor_ruby]# ruby --version
ruby 2.0.0p598 (2014-11-13) [x86_64-linux]

[root@test2 vendor_ruby]# cat /etc/redhat-release
Derived from Red Hat Enterprise Linux 7.1 (Source)

[root@test2 vendor_ruby]# uname -a
Linux centos2 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux

[root@test2 vendor_ruby]# facter operatingsystemrelease -d
Confine raised NoMethodError undefined method `[]' for nil:NilClass
Found no suitable resolves of 1 for operatingsystemrelease
value for operatingsystemrelease is still nil

[root@test2 ~]# facter os
{name=RedHat, family=RedHat}

I noticed that the CentOS image doesn't contain the command
lsb_release so I installed it (with yum install redhat-lsb-core)
and ran the test again : now I get more detail in the os variable
but operatingsystemrelease is always empty:

[root@test2 ~]# facter operatingsystemrelease -d
Confine raised NoMethodError undefined method `[]' for nil:NilClass
Found no suitable resolves of 1 for operatingsystemrelease
value for operatingsystemrelease is still nil

[root@test2 ~]# facter os -d
{name=RedHat, family=RedHat,
lsb={distcodename=Core, distid=CentOS,
distdescription=CentOS Linux release 7.1.1503 (Core) ,
release=:core-4.1-amd64:core-4.1-noarch,
distrelease=7.1.1503, majdistrelease=7,
minordistrelease=1}}


-- 
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 javascript:.
To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-users/01686988-6848-463a-a35b-cda9de0c5d8d%40googlegroups.com

https://groups.google.com/d/msgid/puppet-users/01686988-6848-463a-a35b-cda9de0c5d8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f4445f4b-d9d6-4364-85e3-5292ea59ec39%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/f4445f4b-d9d6-4364-85e3-5292ea59ec39%40googlegroups.com?utm_medium=emailutm_source=footer.

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/5564BDAC.5090501%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Facter : no operatingsystemrelease on CentOS 7

2015-05-26 Thread Poil

Hi,


http://lists.centos.org/pipermail/centos-announce/2015-April/021010.html

https://tickets.puppetlabs.com/browse/FACT-893

Just run yum update



Le 26/05/2015 18:32, Claude a écrit :

Hi,

I'm testing the Openstack CentOS 7 image with Puppet 3.7.5. My problem 
is with Facter not identifying correctly the operating system :


[root@test2 vendor_ruby]# facter --version
2.4.4

[root@test2 vendor_ruby]# ruby --version
ruby 2.0.0p598 (2014-11-13) [x86_64-linux]

[root@test2 vendor_ruby]# cat /etc/redhat-release
Derived from Red Hat Enterprise Linux 7.1 (Source)

[root@test2 vendor_ruby]# uname -a
Linux centos2 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 
x86_64 x86_64 x86_64 GNU/Linux


[root@test2 vendor_ruby]# facter operatingsystemrelease -d
Confine raised NoMethodError undefined method `[]' for nil:NilClass
Found no suitable resolves of 1 for operatingsystemrelease
value for operatingsystemrelease is still nil

[root@test2 ~]# facter os
{name=RedHat, family=RedHat}

I noticed that the CentOS image doesn't contain the command 
lsb_release so I installed it (with yum install redhat-lsb-core) and 
ran the test again : now I get more detail in the os variable but 
operatingsystemrelease is always empty:


[root@test2 ~]# facter operatingsystemrelease -d
Confine raised NoMethodError undefined method `[]' for nil:NilClass
Found no suitable resolves of 1 for operatingsystemrelease
value for operatingsystemrelease is still nil

[root@test2 ~]# facter os -d
{name=RedHat, family=RedHat, lsb={distcodename=Core, 
distid=CentOS, distdescription=CentOS Linux release 7.1.1503 
(Core) , release=:core-4.1-amd64:core-4.1-noarch, 
distrelease=7.1.1503, majdistrelease=7, 
minordistrelease=1}}



--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/01686988-6848-463a-a35b-cda9de0c5d8d%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/01686988-6848-463a-a35b-cda9de0c5d8d%40googlegroups.com?utm_medium=emailutm_source=footer.

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/5564B620.8070306%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Re: Facts which depend on (not-yet-installed) packages

2015-03-17 Thread Poil

Hi,

You can write something that will lookup in the dpkg/yum cache (but I 
don't like this), so you will have the future installed version at the 
1st run


Exemple here : 
https://github.com/fsalum/puppet-redis/blob/master/lib/facter/redis_version.rb


Best regards,

Le 16/03/2015 17:07, jcbollinger a écrit :



On Sunday, March 15, 2015 at 2:04:53 PM UTC-5, Jan S. wrote:

Hello,

I have the following use case: For a custom class/type I need to
know which php_version is installed on the machine. So I wrote a
custom fact like this:

Facter.add('php_version') do
   setcode do
 Facter::Util::Resolution.exec('/usr/bin/php -i | /bin/egrep -e ^PHP Version | 
/usr/bin/head -n 1 | /usr/bin/cut -d   -f 4 | /usr/bin/cut -d - -f 1')
   end
end

It works great. Except: When php is not yet installed (there is a
Package['php'] definition, too). Then it will return an empty string.

Thus I have to run puppet two times to get the expected result.

I am sure that this is expected behavior of puppet. How do I
handle such case?



Fact values are computed before any part of the catalog is built, and 
they reflect the state of the machine before Puppet applies any 
changes.  If PHP is not initially installed, then that's a plausible, 
valid state that your fact value should reflect and your manifests 
should accommodate.  In the worst case, your manifests could 
accommodate absence of PHP by requiring two Puppet runs to converge to 
a final configuration. That's what you have now, evidently.


Consider carefully, however, what that fact value is telling you: what 
version of PHP, if any, is installed /before/ the run.  If the target 
configuration depends in any way on PHP version, then what you 
probably want is the PHP version that will be present /after/ the 
run.  If there is any chance that the run will ever update PHP to a 
new version, then even when PHP is already installed, your manifests 
rely on an unsafe assumption that the version present before the run 
will be the same as the version present after.


Possibly what you want is a different (or additional) fact: not the 
version of PHP currently installed, but the latest version available 
from the configured repositories.  This is the version that will be 
present after a successful run if you have ...


package { 'php': ensure = 'latest' }

... it is also the version that will be present after the run if PHP 
is not initially installed and you have ...


package { 'php': ensure = 'present' }

... provided that the package repository configuration is not changed 
so as to affect which PHP packages are available.  Given that, if you 
ensure that the PHP package is managed before anything that depends on 
PHP version (as you should already be doing) then all should be good.


If you want maximum reliability, however, you need to recognize that 
if indeed what you want to know is which version of PHP will be 
present on the machine after a successful catalog run, then your nodes 
simply cannot provide that information.  It depends on data they do 
not have.  You need to some mechanism other than (or in addition to) 
node facts to ascertain that.



John

--
You received this message because you are subscribed to the Google 
Groups Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7f0ccfaa-108b-44c3-a9d1-cbca6c0bde22%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/7f0ccfaa-108b-44c3-a9d1-cbca6c0bde22%40googlegroups.com?utm_medium=emailutm_source=footer.

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/5507D612.2070204%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] custom fact not working when running via puppet on RHEL5

2015-01-13 Thread Poil

 lsof when running puppet - /sys/class/net/eth0/operstate is open 2 times :

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
...
puppet  9952 root4r   REG0,0 4096 5043 
/sys/class/net/eth0/operstate
puppet  9952 root5r   REG0,0 4096 5043 
/sys/class/net/eth0/operstate


lsof when running facter -p - /sys/class/net/eth0/operstate seem to be 
open only a time


facter 10657 root3r   REG0,0 4096   5043 
/sys/class/net/eth0/operstate



Le 13/01/2015 20:09, Poil a écrit :

hi,

Some more debug ...

strace  puppet agent -t

open(./interfaces_duplex.rb, O_RDONLY) = 5
close(5)= 0
open(./interfaces_duplex.rb, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2ba70b807000

read(5, fstate = File.open(File.join..., 4096) = 439
read(5, , 4096)   = 0
close(5)= 0
munmap(0x2ba70b807000, 4096)= 0
open(/sys/class/net/eth0/operstate, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2ba70b807000

lseek(5, 0, SEEK_CUR)   = 0
clock_gettime(CLOCK_MONOTONIC, {2364700, 310033350}) = 0
select(6, [5], [], [], {119, 998511}





Le 13/01/2015 14:34, Benjamin DUPUIS a écrit :

Hi,

I've this custom fact,
- it's working fine when running via puppet on Debian 6-7, Centos/Rhel 6
- it's going on timeout when running via puppet on Rhel5. Warning: 
Could not load fact file 
/var/lib/puppet/lib/facter/interfaces_duplex.rb: execution expired

- it's working fine when I get it via facter -p on all my Linux

Is anyone have an idea why ? All my nodes are running puppet 3.6.2 
(package from puppetlabs)



cat /var/lib/puppet/lib/facter/interfaces_duplex.rb
if Facter.value(:kernel) == 'Linux' and Facter.value(:virtual) =~ 
/^(physical|vmware|xen0)/

  Dir.glob('/sys/class/net/{eth,em}?').each do |iface|
fstate = File.open(File.join(iface,'operstate'))
state = fstate.read
if state.strip() == 'up'
  Facter.add(duplex_ + File.basename(iface)) do
confine :kernel = 'Linux'
setcode do
  fduplex = File.open(File.join(iface,'duplex'))
  if fduplex
duplex = fduplex.read
duplex.strip()
  end
end
  end
  Facter.add(speed_ + File.basename(iface)) do
confine :kernel = 'Linux'
setcode do
  fspeed = File.open(File.join(iface,'speed'))
  if fspeed
speed = fspeed.read
speed.strip()
  end
end
  end
end
  end
end

Best regards,
Benjamin
--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54B51EF0.707%40quake.fr https://groups.google.com/d/msgid/puppet-users/54B51EF0.707%40quake.fr?utm_medium=emailutm_source=footer.

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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54B56D7B.4070205%40quake.fr 
https://groups.google.com/d/msgid/puppet-users/54B56D7B.4070205%40quake.fr?utm_medium=emailutm_source=footer.

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/54B56F78.3030706%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] custom fact not working when running via puppet on RHEL5

2015-01-13 Thread Poil

hi,

Some more debug ...

strace  puppet agent -t

open(./interfaces_duplex.rb, O_RDONLY) = 5
close(5)= 0
open(./interfaces_duplex.rb, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x2ba70b807000

read(5, fstate = File.open(File.join..., 4096) = 439
read(5, , 4096)   = 0
close(5)= 0
munmap(0x2ba70b807000, 4096)= 0
open(/sys/class/net/eth0/operstate, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x2ba70b807000

lseek(5, 0, SEEK_CUR)   = 0
clock_gettime(CLOCK_MONOTONIC, {2364700, 310033350}) = 0
select(6, [5], [], [], {119, 998511}





Le 13/01/2015 14:34, Benjamin DUPUIS a écrit :

Hi,

I've this custom fact,
- it's working fine when running via puppet on Debian 6-7, Centos/Rhel 6
- it's going on timeout when running via puppet on Rhel5. Warning: 
Could not load fact file 
/var/lib/puppet/lib/facter/interfaces_duplex.rb: execution expired

- it's working fine when I get it via facter -p on all my Linux

Is anyone have an idea why ? All my nodes are running puppet 3.6.2 
(package from puppetlabs)



cat /var/lib/puppet/lib/facter/interfaces_duplex.rb
if Facter.value(:kernel) == 'Linux' and Facter.value(:virtual) =~ 
/^(physical|vmware|xen0)/

  Dir.glob('/sys/class/net/{eth,em}?').each do |iface|
fstate = File.open(File.join(iface,'operstate'))
state = fstate.read
if state.strip() == 'up'
  Facter.add(duplex_ + File.basename(iface)) do
confine :kernel = 'Linux'
setcode do
  fduplex = File.open(File.join(iface,'duplex'))
  if fduplex
duplex = fduplex.read
duplex.strip()
  end
end
  end
  Facter.add(speed_ + File.basename(iface)) do
confine :kernel = 'Linux'
setcode do
  fspeed = File.open(File.join(iface,'speed'))
  if fspeed
speed = fspeed.read
speed.strip()
  end
end
  end
end
  end
end

Best regards,
Benjamin
--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54B51EF0.707%40quake.fr 
https://groups.google.com/d/msgid/puppet-users/54B51EF0.707%40quake.fr?utm_medium=emailutm_source=footer.

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/54B56D7B.4070205%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] custom fact not working when running via puppet on RHEL5

2015-01-13 Thread Poil

I think I've got it

https://www.ruby-forum.com/topic/92722


Le 13/01/2015 20:18, Poil a écrit :
 lsof when running puppet - /sys/class/net/eth0/operstate is open 2 
times :


COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
...
puppet  9952 root4r   REG0,0 4096 5043 
/sys/class/net/eth0/operstate
puppet  9952 root5r   REG0,0 4096 5043 
/sys/class/net/eth0/operstate


lsof when running facter -p - /sys/class/net/eth0/operstate seem to be 
open only a time


facter 10657 root3r   REG0,0 4096   5043 
/sys/class/net/eth0/operstate



Le 13/01/2015 20:09, Poil a écrit :

hi,

Some more debug ...

strace  puppet agent -t

open(./interfaces_duplex.rb, O_RDONLY) = 5
close(5)= 0
open(./interfaces_duplex.rb, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=439, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2ba70b807000

read(5, fstate = File.open(File.join..., 4096) = 439
read(5, , 4096)   = 0
close(5)= 0
munmap(0x2ba70b807000, 4096)= 0
open(/sys/class/net/eth0/operstate, O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2ba70b807000

lseek(5, 0, SEEK_CUR)   = 0
clock_gettime(CLOCK_MONOTONIC, {2364700, 310033350}) = 0
select(6, [5], [], [], {119, 998511}





Le 13/01/2015 14:34, Benjamin DUPUIS a écrit :

Hi,

I've this custom fact,
- it's working fine when running via puppet on Debian 6-7, Centos/Rhel 6
- it's going on timeout when running via puppet on Rhel5. Warning: 
Could not load fact file 
/var/lib/puppet/lib/facter/interfaces_duplex.rb: execution expired

- it's working fine when I get it via facter -p on all my Linux

Is anyone have an idea why ? All my nodes are running puppet 3.6.2 
(package from puppetlabs)



cat /var/lib/puppet/lib/facter/interfaces_duplex.rb
if Facter.value(:kernel) == 'Linux' and Facter.value(:virtual) =~ 
/^(physical|vmware|xen0)/

  Dir.glob('/sys/class/net/{eth,em}?').each do |iface|
fstate = File.open(File.join(iface,'operstate'))
state = fstate.read
if state.strip() == 'up'
  Facter.add(duplex_ + File.basename(iface)) do
confine :kernel = 'Linux'
setcode do
  fduplex = File.open(File.join(iface,'duplex'))
  if fduplex
duplex = fduplex.read
duplex.strip()
  end
end
  end
  Facter.add(speed_ + File.basename(iface)) do
confine :kernel = 'Linux'
setcode do
  fspeed = File.open(File.join(iface,'speed'))
  if fspeed
speed = fspeed.read
speed.strip()
  end
end
  end
end
  end
end

Best regards,
Benjamin
--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54B51EF0.707%40quake.fr 
https://groups.google.com/d/msgid/puppet-users/54B51EF0.707%40quake.fr?utm_medium=emailutm_source=footer.

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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54B56D7B.4070205%40quake.fr 
https://groups.google.com/d/msgid/puppet-users/54B56D7B.4070205%40quake.fr?utm_medium=emailutm_source=footer.

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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54B56F78.3030706%40quake.fr 
https://groups.google.com/d/msgid/puppet-users/54B56F78.3030706%40quake.fr?utm_medium=emailutm_source=footer.

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/54B59B26.6040704%40quake.fr.
For more options

Re: [Puppet Users] Re: if tagged scope and autoconfig module

2014-12-08 Thread Poil

Hey thanks,

I don't understand : in template we can use classes that contain all 
defined classes.

Is it a good idea to add

if defined(Class['::apache']) {
  require apache;
  include collectd::apache
}

Or is a class is like other ressource, only defined when parsed ? (so 
could be randomly defined when playing collectd::autoconfig)


For the moment I've invert my code
I have a class apache::collectd which call collectd::apache with an hash 
as parameter


Best regards,


Le 01/12/2014 16:15, jcbollinger a écrit :



On Monday, December 1, 2014 2:21:01 AM UTC-6, Poil wrote:

Hi,

I try to write an autoconfigure module (collectd) that depends on
other modules included for my node.



If you mean you are writing a module containing declarations that are 
conditioned on whether other classes or modules have been assigned to 
the target node's catalog, then my first and best advice is to abandon 
that idea altogether.  As a general rule, such declarations do not 
work reliably or well because the results of the necessary conditional 
tests depend on the order in which they are evaluated relative to 
other declarations in other manifests, and that order is very 
difficult to predict.  Instead, use Hiera or an ENC to dynamically 
specify the needed classes for each node.



So I've this class autoloaded for all my nodes :



In Puppet jargon term autoloading refers to the mechanism by which 
the catalog compiler locates the manifest file in which the definition 
of a given class or defined type resides (supposing that you have 
followed the layout conventions that allow it to do so).  That doesn't 
seem to be what /you/ mean by the term, so if your meaning matters to 
the question then it would be to your advantage to explain.



class collectd::client::autoconfig {
  require collectd::client

  if tagged('apache') {
require apache
include collectd::client::plugin::apache
  }
  if tagged('memcached') {
require memcached
include collectd::client::plugin::memcached
  }
(...)
}

But sometimes, on my old nodes, collectd is manually configured
(for an historical bad/good reason); so, for my old_node1 I have
include collectd::client::plugin::apache but I don't have the
apache module included; in this case my autoloader will detect
the tag apache in my class include
collectd::client::plugin::*apache* ...

It does not seem possible to use ::apache in the tagged function
? Am I right ?
Have you got any idea for my case ? (I can add a parameter to
disable my autoconfig, but I'm looking for a better solution if it
exists.)



I haven't used tagged() much (or at all, really), but I don't think it 
does what you seem to think it does. The docs say it tells you 
whether the current container is tagged with the specified tags, 
where the usual meaning of container in Puppet is a class, node, or 
catalog, so that function will not inform directly about whether a 
class other than the one in which the function call appears is tagged 
with the specified tag. Because objects inherit tags from their 
containers, however, it will indirectly inform about whether the 
object in which the call appears is declared by a class bearing the 
specified tag (recursively).  Classes can be declared multiple times 
in multiple places, however, so I cannot see how the function result 
could fail to be evaluation-order dependent.


In any case, be aware that classes are automatically tagged with every 
segment of their own qualified names, so yes, class 
collectd::client:plugin::apache will always bear the tags collectd, 
client, plugin, and apache (among others) as will every object 
declared by that class.  I wouldn't expect the tagged() function to 
reject the tag ::apache, but that particular tag won't be present on 
any object unless you've set it explicitly.  None of that should not 
directly affect class collectd::client::autoconfig, though.  The only 
way it should see a tag 'apache' is if it is declared within a 
container bearing that tag.  Do you mean to say that class 
collectd::client:plugin::apache declares class 
collectd::client::autoconfig?  If so, why?



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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1f68a3ab-4976-470b-828c-2c36981d66f4%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/1f68a3ab-4976-470b-828c-2c36981d66f4%40googlegroups.com?utm_medium=emailutm_source=footer.

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

[Puppet Users] if tagged scope and autoconfig module

2014-12-01 Thread Poil

Hi,

I try to write an autoconfigure module (collectd) that depends on other 
modules included for my node.


So I've this class autoloaded for all my nodes :

class collectd::client::autoconfig {
  require collectd::client

  if tagged('apache') {
require apache
include collectd::client::plugin::apache
  }
  if tagged('memcached') {
require memcached
include collectd::client::plugin::memcached
  }
(...)
}

But sometimes, on my old nodes, collectd is manually configured (for an 
historical bad/good reason); so, for my old_node1 I have include 
collectd::client::plugin::apache but I don't have the apache module 
included; in this case my autoloader will detect the tag apache in my 
class include collectd::client::plugin::*apache* ...


It does not seem possible to use ::apache in the tagged function ? Am 
I right ?
Have you got any idea for my case ? (I can add a parameter to disable my 
autoconfig, but I'm looking for a better solution if it exists.)


Best regards,
Poil

--
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/547C24D5.9010708%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Hash of hashes to file template

2014-10-05 Thread Poil

Hi,

Something like this :

|%if  @ospf and @||ospf!=  -%
%@||ospf.sort.mapdo  |iname,instance| -%|
|   |protocol ospf % iname =%:
(...)

But I think you can probably use create_resource()

Best regards,


Le 06/10/2014 00:55, Ciro Iriarte a écrit :
Hi!, I'm starting to work with hiera and file templates, how would be 
the best way to transform this hiera output:


myanycast::bird::ospf:
  myinstance:
tick: 2
rfc1583compat: 'yes'
export: 'all'
area:
  990:
stub: 'no'
interface:
  eth0:
hello: 10
retransmit: 6
cost: 10
transmit_delay: 5
dead_count: 5
dead: 40
wait: 50
type: 'broadcast'

To this in the final configuration file using templates?:

protocol ospf myinstance:
  tick 2;
  rfc1583compat yes;
  export all;
  area 990 {
stub no;
interface eth0 {
  hello 10;
  retransmit 6;
  cost 10;
  transmit delay 5;
  dead count 5;
  dead 40;
  wait 50;
  type broadcast;
  };
  };
}

There can be many areas per instance, and many interfaces per area.

Also, something that I noticed about hashes is that each hiera query 
(at least by hand) gives me the same data in different order. Can this 
trigger a different md5 for the file and force a service reload each 
30 minutes even there are no configuration changes?


Regards,
Ciro

--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ee60bb31-1cc7-4b92-8030-f9a6bc14fd20%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/ee60bb31-1cc7-4b92-8030-f9a6bc14fd20%40googlegroups.com?utm_medium=emailutm_source=footer.

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/54322DC3.1080102%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Best method to query role specific data when using roles/profiles + hiera as an ENC

2014-09-09 Thread Poil

Hi,

I think this is what you want : 
https://docs.puppetlabs.com/hiera/1/hierarchy.html Data Source Resolution


We are replacing our ENC with this full hiera method

Best regards

Le 09/09/2014 11:34, JeremyCampbell a écrit :
 We are implementing the profiles/roles pattern with hiera and using 
hiera to assign roles i.e. hiera_include('classes'). Current hierarchy:


|
:hierarchy:
-%{clientcert}
-%{environment}
-global
|

We have several roles which require their own configuration data. e.g. 
Firewall role, VPN role (each include several profiles). For example, 
using the logrotate module we need to add different defines for the 
Firewall role and the VPN role.


 The most obvious solution is to create a new hierarchy level e.g. 
%{role} but then we need to assign machines to a role outside of 
hiera. I'm guessing the best way to do this is with a custom fact 
during the initial provisioning but I'm not sure.


What would be the best solution for looking up role specific data 
using the roles/profiles pattern with hiera?


Thank you for your time!


--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6510ddf4-2a0b-4a1e-abb8-8d0244ba48f3%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/6510ddf4-2a0b-4a1e-abb8-8d0244ba48f3%40googlegroups.com?utm_medium=emailutm_source=footer.

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/540F3AE2.9090303%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Best method to query role specific data when using roles/profiles + hiera as an ENC

2014-09-09 Thread Poil
You have 2 hierarchies, one flat that is the classifier that contains 
fqdn.yaml; each fqdn.yaml defined what is the role of the current fqdn.
This hierarchy is filled when you deploy a server (via a webservice, 
manually or what you want)


The 2nd hierarchy is what you have today.

Le 09/09/2014 23:02, JeremyCampbell a écrit :
I believe I understand 'Data Source Resolution' but it doesn't address 
our issue unless I'm missing something. The question is how to assign 
a role to a server so that we can use a new role level in our hierarchy.


On Tuesday, September 9, 2014 7:37:51 PM UTC+2, Poil wrote:

Hi,

I think this is what you want :
https://docs.puppetlabs.com/hiera/1/hierarchy.html
https://docs.puppetlabs.com/hiera/1/hierarchy.html Data Source
Resolution

We are replacing our ENC with this full hiera method

Best regards

Le 09/09/2014 11:34, JeremyCampbell a écrit :

 We are implementing the profiles/roles pattern with hiera and
using hiera to assign roles i.e. hiera_include('classes').
Current hierarchy:

|
:hierarchy:
-%{clientcert}
-%{environment}
-global
|

We have several roles which require their own configuration data.
e.g. Firewall role, VPN role (each include several profiles). For
example, using the logrotate module we need to add different
defines for the Firewall role and the VPN role.

 The most obvious solution is to create a new hierarchy level
e.g. %{role} but then we need to assign machines to a role
outside of hiera. I'm guessing the best way to do this is with a
custom fact during the initial provisioning but I'm not sure.

What would be the best solution for looking up role specific data
using the roles/profiles pattern with hiera?

Thank you for your time!


-- 
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 javascript:.
To view this discussion on the web visit

https://groups.google.com/d/msgid/puppet-users/6510ddf4-2a0b-4a1e-abb8-8d0244ba48f3%40googlegroups.com

https://groups.google.com/d/msgid/puppet-users/6510ddf4-2a0b-4a1e-abb8-8d0244ba48f3%40googlegroups.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b4b53515-8858-4419-be07-5d7aee9720dd%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/b4b53515-8858-4419-be07-5d7aee9720dd%40googlegroups.com?utm_medium=emailutm_source=footer.

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/540F6D41.1090204%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Hierarchy and Structured Facts

2014-08-30 Thread Poil

Hi,

I've go a fact cfn_roles that is an array
Is it possible to use it in hierarchy ?

For exemple :

* my fact :
cfn_roles:
  - apache
  - mysql

And my hierarchy

|:hierarchy:
  - %{::roles}|

hiera will try each entry of cfn_roles ?

Best regards,

--
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/5401A6DB.4090406%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Style - hiera/params/puppet/template

2014-08-30 Thread Poil

Hi,

//I use params_lookup (lib from puppi) 
https://github.com/example42/puppi/blob/master/lib/puppet/parser/functions/params_lookup.rb

it lookup in this order (first match is returned)
- Hiera backend (if present) for modulename_varname
- Hiera backend (if present) for varname (if second argument is 'global')
 - Top Scope Variable ::modulename_varname
 - Top Scope Variable ::varname (if second argument is 'global')
 - Module default: ::modulename::params::varname

So all my classes are based on this tpl :

class my_class::params {
$config_param = 'default value'
}

class my_class (
$config_param = params_lookup('config_param'),
$global_param = params_lookup('global_param','global')
) inherits my_class::params {
...
}

Best regards,

Le 30/08/2014 18:23, Sirtaj Singh Kang a écrit :

Greetings all,

In the pre-hiera days, it was commonly recommended to write classes 
with params like this:


class my_class::params {
$config_param = 'default value'
}

class my_class (
$config_param = $myclass:params::config_param
) inherits myclass::params {
...
}

However, now that much overriding, customising etc has moved into 
Hiera, this ends up being very verbose, redundant and error-prone, 
especially if there are a lot of parameters (to go into a config 
template, for example). The same parameter name may end up in four 
different places in common cases: hiera, params, class decl and the 
config template.


So I would like to know if people are still doing this as much as 
possible. What is the remaining benefit in declaring defaults in 
params rather than in the class declaration directly? Is there a more 
up to date style guide that does away with the verbosity and 
duplication, or is the old params class style still widely recommended?


Thanks for any suggestions,

-Taj.



--
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/54021880.3090505%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Augeas hates me!!!

2014-08-14 Thread Poil

Hi,

I think you can use file_line from stdlib 
https://forge.puppetlabs.com/puppetlabs/stdlib#file_line

It's really more simple than Augeas and it works better.

For multi-line I also use editfile a custom module, but you need to be 
good with regex =) https://github.com/mstrauss/puppet-editfile


Best regards,

Le 12/08/2014 22:22, randal cobb a écrit :

Hello, all!

I am trying to add some new modules to an openSuse 13.1 host with 
Puppet and Augeas with no luck.  The modules themselves are already 
installed by the example42/apache module, but I can't get the 
apache::module syntax to properly add the modules to the proper 
openSuse config files.  So, I'm opting for Augeas to do the 
dirty-work.  I have the following definition in the server's manifest 
(dev-apache.pp) file (the apache::module command are still there, but 
don't work, so the augeas section is the brute-force attempt; I just 
included them both so you can see the current state of this class 
manifest):


|
...

apache::module{'status':}
apache::module{'asis':}
apache::module{'auth_digest':}
apache::module{'headers':}
apache::module{'proxy':}
apache::module{'proxy_http':}
apache::module{'rewrite':}
apache::module{'vhost_alias':}
apache::module{'authz_default':}
apache::module{'proxy_balancer':}

augeas {'apache2':
context =/files/etc/sysconfig/apache2,
lens =sysconfig.lns,
incl ='/usr/share/augeas/lenses/dist/',
changes =
'set APACHE_MODULES actions alias auth_basic authn_file
authz_host authz_groupfile authz_user autoindex cgi dir env
expires include log_config mime negotiation setenvif ssl userdir
reqtimeout authn_core authz_core status asis auth_digest headers
proxy proxy_http rewrite vhost_alias authz_default proxy_balancer',
}
...
|


When running the agent in --debug --verbose --test, I get this debug 
output from augeas:


|
Debug:Augeas[apache2](provider=augeas):Openingaugeas withroot /,lens 
path ,flags 64

Debug:Augeas[apache2](provider=augeas):Augeasversion 1.0.0isinstalled
Debug:Augeas[apache2](provider=augeas):Willattempt to save andonly run 
iffiles changed
Debug:Augeas[apache2](provider=augeas):sending command 
'set'withparams[/files/etc/sysconfig/apache2/APACHE_MODULES,actions 
alias auth_basic authn_file authz_host authz_groupfile authz_user 
autoindex cgi dir env expires include log_config mime negotiation 
setenvif ssl userdir reqtimeout authn_core authz_core status asis 
auth_digest headers proxy proxy_http rewrite vhost_alias authz_default 
proxy_balancer]
Debug:Augeas[apache2](provider=augeas):Skippingbecause nofiles were 
changed

Debug:Augeas[apache2](provider=augeas):Closedthe augeas connection
|


No errors, but the file is marked as unchanged.

Before the puppet run, /etc/sysconfig/apache2 contains this line:
APACHE_MODULES=foo
and obviously, it's the same afterwards.

Any insight into what I may be doing wrong?

--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3d666f47-8b6e-436a-8791-a15e50ab9771%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/3d666f47-8b6e-436a-8791-a15e50ab9771%40googlegroups.com?utm_medium=emailutm_source=footer.

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/53EC545D.1000709%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] EC2 autoscaling reusing hostnames

2014-05-28 Thread Poil

Hi

I use this solution (one certs) : 
https://gist.github.com/ahpook/1182243, I deploy the certificate via 
cfn-init and I've a pre-script for settings the hostname of the server 
via a reverse dns query on my AutoScale group.


Best regards


Le 24/05/2014 07:54, Bad Tux a écrit :
So I'm using Amazon's amazing EC2 autoscaling service and hey, this is 
pretty cool. Traffic on the web site constellation goes up, Amazon 
slowly spawns new instances of our web application to handle the 
traffic and attaches them to the load balancer for our site. Puppet 
runs, pulls in the application from the PuppetMaster (which was 
designated at scaling group creation time), spins it up, load balancer 
asks it hey are you there, the application says yep, and traffic 
starts getting split out to the new instance. Traffic goes back down, 
after a while Amazon slowly spins the excess instances back down.


So I sit there for a few weeks watching traffic yoyo up and down and 
watching the scaling notifications crawl across my inbox, then 
suddenly my Nagios alarms go off telling me that the application is 
offline. WTF? There's instances up there! I attach an elastic IP to 
the ssh gateway instance and log into a couple of the application 
instances via ssh and sure enough, no Tomcat is installed or running, 
nevermind the web app that Tomcat is supposed to be running. Okay, is 
my puppetmaster offline? Nope, it's online and listening. So I 
manually run puppet on one of the instances and... invalid 
certificate for this hostname.


Wha?

Then I realize: Amazon gave this instance the same IP address and 
hostname as a prior instance that'd been part of the constellation! 
Which is inevitable when you're running inside a VPC (Virtual Private 
Cloud), because you have only a /16 to play with, which must be 
divided between multiple availability groups and multiple security 
zones. And the puppetmaster's SSL sez, nope, no way, I seen you 
before and you had a different certificate, go away.


Uhm, okay. So I need to solve this problem so that my new instances 
can get deployed. Only thing I can think of is to trash the ssl 
directories on both the puppet master and all of the clients, and then 
run puppet again. Note that all the instances and puppet are in a 
puppet network security group that was created by CloudFormation, 
and instances not part of the puppet security group cannot connect 
to the puppet master, so we *know* that we're talking to the puppet 
master, and the puppet master *knows* we're actual hosts that can talk 
to it, and besides all of these instances are inside a virtual private 
cloud that is inaccessible to the wider Internet except via port 8080 
between the load balancer and the application instances (again 
enforced by the security groups mechanism) so there's no way an 
outsider could talk to the puppet server anyhow, but... puppet insists 
on validating these SSL certificates before letting the instances talk 
to it. Even though that's a totally useless exercise given that 
Amazon's enforcing the ACL's at the virtual network (firewall) layer 
to prevent anybody unauthorized from getting anywhere near that puppet 
port or puppet IP address.


Am I missing a configuration option in the manual to somehow disable 
SSL certificate validation? Does everybody add a cron job to their 
puppet master to stop the puppetmaster daemon and blow away its SSL 
directory then restart it at exactly 12:00AM every day, and the same 
on the instances at exactly 12:02AM every day? Or are we the only 
people on the planet who actually use Amazon's auto-scaling feature 
*plus* use Puppet at the same time? Curious penguins are... curious!




--
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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a43e189b-61c0-498c-b687-56d216c375aa%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/a43e189b-61c0-498c-b687-56d216c375aa%40googlegroups.com?utm_medium=emailutm_source=footer.

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/53857BC8.5010501%40quake.fr.
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-16 Thread Poil

Hi,

I was a little wrong yesterday, you can use hiera, but also you can use 
a hash in your nodes.pp



class lsync ($sync) {
}

$localsync = {
  instance1 = {
'source' = 'toto',
'host' = 'titi',
  },
  instance2 = {
'source' = 'tutu',
'host' = 'tata',
  },
}

class {'lsync':
  sync = $localsync
}


Le 15/05/2014 22:40, Poil a écrit :

Hi,

You can use hiera (here a yaml)

sync:
  instance1:
source: toto
host: titi
 instance2:
source: toto
host: titi

And in your template juste loop on it
% @sync.each_pair do |name, value| -%
%= name %
   source = %= value['source'] %,
   host   = %= value['host'] %
% end %

Le 15/05/2014 21:25, Ugo Bellavance a écrit :

Hi,

I wrote my first puppet module and it is for lsyncd.  I know that 
there is already a module for that but I think it was written to 
manage lsyncd and csync2 syncs and I don't really understand 
everything it it so I can't really use it or learn from it.  I have 
been able to create a simple module, below is the code from init.pp 
(I know, I should modularize it so that init.pp calls ::install and 
::config, but I'll do that once the module works as I want).  It is 
actually working, but only allows for one sync to be configured.  I'd 
like it to be able to configure more than one sync, but since all the 
configs for lsyncd is in one file, I wouldn't know how to do it 
unless I add some variables like $method, $source2, $dest2, 
$desthost2, $append2 and $method, $source3, $dest3, $desthost3, 
$append3, $method, $sourcex, $destx, $desthostx, $appendx. I think 
someone here would know how to do it.


Code for init.pp:

class lsyncd ($method, $source, $dest, $desthost, $append) {

package { 'lsyncd':
ensure = installed,
}

file { 'lsyncd.conf':
ensure  = present,
path  = '/etc/lsyncd.conf',
owner = root,
group = root,
mode  = '0644',
content = template('lsyncd/lsyncd.conf.erb')
}

service { 'lsyncd':
ensure  = running,
enable  = true,
hasrestart  = true,
hasstatus = true,
require = [Package['lsyncd'], File['lsyncd.conf']],
subscribe =
File[
'lsyncd.conf'
],
}

}


This is the code for the erb template (feel free to let me know if I 
you find errors):


settings {
   logfile= /var/log/lsyncd.log,
   statusFile = /tmp/lsyncd.status,
   inotifyMode = CloseWrite or Modify,
   delay   = 1
}

sync {
   %= @method %,
   source = %= source %,
   host   = %= desthost %,
   targetdir  = %= dest %,

% if @append -%
   rsync  = {
  _extra = {--append}
   }
% end -%
}

Here is how I'd like to have my config file:

settings {
   logfile= /var/log/lsyncd.log,
   statusFile = /tmp/lsyncd.status,
   inotifyMode = CloseWrite or Modify,
   delay   = 1
}

sync {
 default.rsyncssh,
   source = /var/www/test/src,
   host   = www.example.com,
   targetdir  = /var/www/test/dst,

   rsync  = {
  _extra = {--append}
   }
}

sync {
 default.rsyncssh,
   source = /var/www/,
   host   = www.example.com,
   targetdir  = /var/www/test/dst1,

   rsync  = {
  _extra = {--append}
   }
}

sync {
 default.rsyncssh,
   source = /var/log/,
   host   = www.example.com,
   targetdir  = /var/www/test/dst2,

   rsync  = {
  _extra = {--append}
   }
}

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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a63e58f0-1da9-40ef-bb4c-b5e99f3b0365%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/a63e58f0-1da9-40ef-bb4c-b5e99f3b0365%40googlegroups.com?utm_medium=emailutm_source=footer.

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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5375265A.6070702%40quake.fr 
https://groups.google.com/d/msgid/puppet-users/5375265A.6070702%40quake.fr?utm_medium=emailutm_source=footer.

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/5375B1C8.8020600%40quake.fr.
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-15 Thread Poil

Hi,

You can use hiera (here a yaml)

sync:
  instance1:
source: toto
host: titi
 instance2:
source: toto
host: titi

And in your template juste loop on it
% @sync.each_pair do |name, value| -%
%= name %
   source = %= value['source'] %,
   host   = %= value['host'] %
% end %

Le 15/05/2014 21:25, Ugo Bellavance a écrit :

Hi,

I wrote my first puppet module and it is for lsyncd.  I know that 
there is already a module for that but I think it was written to 
manage lsyncd and csync2 syncs and I don't really understand 
everything it it so I can't really use it or learn from it.  I have 
been able to create a simple module, below is the code from init.pp (I 
know, I should modularize it so that init.pp calls ::install and 
::config, but I'll do that once the module works as I want).  It is 
actually working, but only allows for one sync to be configured.  I'd 
like it to be able to configure more than one sync, but since all the 
configs for lsyncd is in one file, I wouldn't know how to do it unless 
I add some variables like $method, $source2, $dest2, $desthost2, 
$append2 and $method, $source3, $dest3, $desthost3, $append3, $method, 
$sourcex, $destx, $desthostx, $appendx. I think someone here would 
know how to do it.


Code for init.pp:

class lsyncd ($method, $source, $dest, $desthost, $append) {

package { 'lsyncd':
ensure = installed,
}

file { 'lsyncd.conf':
ensure  = present,
path= '/etc/lsyncd.conf',
owner   = root,
group   = root,
mode= '0644',
content = template('lsyncd/lsyncd.conf.erb')
}

service { 'lsyncd':
ensure  = running,
enable  = true,
hasrestart  = true,
hasstatus = true,
require = [Package['lsyncd'], File['lsyncd.conf']],
subscribe =
File[
'lsyncd.conf'
],
}

}


This is the code for the erb template (feel free to let me know if I 
you find errors):


settings {
   logfile= /var/log/lsyncd.log,
   statusFile = /tmp/lsyncd.status,
   inotifyMode = CloseWrite or Modify,
   delay   = 1
}

sync {
   %= @method %,
   source = %= source %,
   host   = %= desthost %,
   targetdir  = %= dest %,

% if @append -%
   rsync  = {
  _extra = {--append}
   }
% end -%
}

Here is how I'd like to have my config file:

settings {
   logfile= /var/log/lsyncd.log,
   statusFile = /tmp/lsyncd.status,
   inotifyMode = CloseWrite or Modify,
   delay   = 1
}

sync {
   default.rsyncssh,
   source = /var/www/test/src,
   host   = www.example.com,
   targetdir  = /var/www/test/dst,

   rsync  = {
  _extra = {--append}
   }
}

sync {
   default.rsyncssh,
   source = /var/www/,
   host   = www.example.com,
   targetdir  = /var/www/test/dst1,

   rsync  = {
  _extra = {--append}
   }
}

sync {
   default.rsyncssh,
   source = /var/log/,
   host   = www.example.com,
   targetdir  = /var/www/test/dst2,

   rsync  = {
  _extra = {--append}
   }
}

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 
mailto:puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a63e58f0-1da9-40ef-bb4c-b5e99f3b0365%40googlegroups.com 
https://groups.google.com/d/msgid/puppet-users/a63e58f0-1da9-40ef-bb4c-b5e99f3b0365%40googlegroups.com?utm_medium=emailutm_source=footer.

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/5375265A.6070702%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Policy-Based Autosigning

2014-03-17 Thread Poil

Hi,

I'm trying to have Policy-Based Autosigning working with puppet 3.4.3; 
but my script is never called


# /etc/puppet/puppet.conf
[master]
autosign = /usr/local/bin/autosign.sh

# ls -l /usr/local/bin/autosign.sh
puppet.puppet rwxr-xr-x /usr/local/bin/autosign.sh

# cat /usr/local/bin/autosign.sh
echo $@  /var/tmp/debugme
exit 0

/var/tmp/debugme remain empty

Anyone have any idea? I'm on for more than 6 hours ... (I've tried to 
run --no-daemonize --debug, strace -f ... There is no call to the 
script, no reference ...)


Best regards,

--
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/5327537E.1070703%40quake.fr.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Noop some classes/ressources

2013-12-10 Thread Poil

Hi,

I would like to set to noop some classes (not all) for some server 
groups. (For example, we can have 2 types of modules, IT and Middleware, 
IT must be in no-noop and Middleware must be in noop)


Today my idea is to have a parameters (via ENC or hiera, 
!noop_state=true/false) and add a noop=$noop_state on all ressources of 
theses classes.


Is there a better way to do this ? Any comment ?

I use puppet 3.2.*

Best regards,

--
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/52A763F7.7010607%40quake.fr.
For more options, visit https://groups.google.com/groups/opt_out.