Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions
On Wednesday, June 17, 2015 at 2:12:31 PM UTC-5, Eric Sorenson wrote: On Thu, 7 May 2015, jcf wrote: I don't think that reflects a firm grasp of the nature of the problem. The issue is that the new thing here is not the thing that the package's version number should be describing in the first place. I don't care about the newness of AIO layout and packaging, and I don't expect many others will either. People don't install Puppet for its packaging. I do care about the versions of various components of the system, but not everyone will, and anyway, we have already established that an AIO package's version number is not a good vehicle for communicating information about versions of auxilliary components. Focus on what's important. To your audience. I am also pretty baffled that this is considered hard, or even a matter for debate. Principle of Least Surprise, or just have the contents match the tin. FWIW I find this argument pretty compelling and would like to advance the version number of the next release of puppet-agent to '4.something'. Our current thinking is that this will be a matched to the puppet version, with an extra digit on the end of the version number that indicates component revisions other than Puppet itself. So specifically, the next release will be puppet-agent-4.2.0.0; a hypothetical rev to include a not-very-hypothetical openssl update would be included in a puppet-agent-4.2.0.1 package. (We can't use the release field as suggested up-thread, because some packaging systems don't view numbers not part of the 'version' field to be an upgrade.) Does that align more closely with the least-surprising thing, to you? I approve. I don't consider it a complete or ideal solution, but it's much better than what is offered now. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b9586a20-02bf-4e1d-b4a5-8f897c4b99ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet ignoring hiera
I'm sure I've forgotten something here, but in a Vagrant VM I have set up a
test environment to test some stuff before bringing into my Puppet
environment.
Here's my puppet.conf file. Very minimal:
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
hiera_config = /etc/puppet/hiera.yaml
[master]
# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
Here is the hiera.yaml file:
---
:backends:
- yaml
:hierarchy:
- defaults
- nodes/%{fqdn}
- %{clientcert}
- %{environment}
- global
:yaml:
# datadir is empty here, so hiera uses its defaults:
# - /var/lib/hiera on *nix
# - %CommonAppData%\PuppetLabs\hiera\var on Windows
# When specifying a datadir, make sure the directory exists.
:datadir: /etc/puppet/hiera
and here is the global.yaml
---
classes:
- puppet::agent
Pretty simple stuff. However the puppet::agent class is not being applied
to any of the hosts during agent run.
So... what am I missing here?
--
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/CAArvnv2y58pdpxcsvbozrnieig%3D9yqz-bWEispH7sFxact1Xhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppet ignoring hiera
On Thu, Jun 18, 2015 at 4:34 PM, Peter Berghold salty.cowd...@gmail.com wrote:
So... what am I missing here?
hiera_include('classes') in site.pp?
--
Enviatics | Automation and configuration management
http://www.enviatics.com | @Enviatics
Puppet Training http://www.enviatics.com/training/
--
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/CACxdKhH8_pNJtCNqYXH_XEUMa3YUJQud4newy8eqxCnvnXHa%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: what is actually undefined method 'include?' for nil:NilClass on node error?
My co-worker said he got lucky on a google search a couple months ago and suggested that I look at that directory. when I saw a one to one correspondence between the short files and the systems not working it was a quick fix. We suspect that the disk ran out of room before a scheduled clean up ran and caused the truncated files. On Wednesday, June 17, 2015 at 2:46:43 PM UTC-4, Tom Noonan wrote: Good catch. Out of curiosity, what lead you to look at file sizes in /var/lib/puppet/yaml/node? Based on your initial problem description that is not where I would have been looking to troubleshoot. On Wed, 17 Jun 2015 07:11:09 -0700 (PDT) Ed Deloye ede...@gmail.com javascript: wrote: Discovered truncated yaml files on the puppet master in /var/lib/puppet/yaml/node for the 24 systems. Identified as each one was 4096 bytes. After deleting those files puppet runs successfully on the nodes. On Thursday, May 29, 2014 at 3:57:49 PM UTC-4, Sans wrote: I have two identical nodes - serv106 and serv107 - one of which is working just fine but the other one failing with these error message: err: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method `include?' for nil:NilClass on node warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run running puppet master in the foreground, I see these on the screen: err: undefined method `include?' for nil:NilClass on node err: undefined method `include?' for nil:NilClass on node debug: Received report to process from serv106.syst.local debug: Processing report from serv106.syst.local with processor Puppet::Reports::Store debug: Processing report from serv106.syst.local with processor Puppet::Reports::Http err: Report processor failed: Connection refused - connect(2) debug: Processing report from serv106.syst.local with processor Puppet::Reports::Log err: //serv106.syst.local/Puppet: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method `include?' for nil:NilClass on node warning: //serv106.syst.local/Puppet: Not using cache on failed catalog err: //serv106.syst.local/Puppet: Could not retrieve catalog; skipping run a bit if google-search suggested that removing certificates from both master and the agent (and recreating afterwards) is the solution to this issue. Which did but no joy so far. Has any one ever seen this error before or know what's I'm doing wrong here. Any help/pointer would be greatly appreciated. Best! -- 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/56789a11-231a-4901-937c-065a92cc1340%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Concat params along a node.
Le 12/06/2015 à 07:06:49-0700, jcbollinger a écrit
You don't. If you were willing to write a custom function or possibly to
That' sucks ...
engage in some ruby-fu inan inline template then you could extract a list of
the titles of all Things::Addthing resources declared to that point during
catalog building, but that's not necessarily the same thing, as instances may
have been declared elsewhere, too.
Exactly.
More generally, it is never a good idea for your manifests to rely on
extracting data from the catalog under construction. The result of any such
inquiry is necessarily dependent on the order in which Puppet evaluates your
In fact the order don't matters for me.
manifests, which is difficult to predict. Instead, focus on data first, and
code second. For example, if you want a list of the Thing::Addthings, then
start with that, and use it to make your declarations, instead of making your
declarations and after the fact trying to determine what you declared (which
in
truth you already know anyway):
class my_service {
include ::things
$thinglist = [ 'first', 'second', 'third' ]
things::addthing { $thinglist: }
}
It's shorter, too.
Well, I can do that, but that's become really hard to read if for each
thing they are lots of parameters.
In fact I event don't how to do that with lots of parameters. Let's say I
want do what you say, how can I factorise
things:addthing { 'first':
'param1' = 'value1',
'param10' = 'value10',
}
things:addthing { 'second':
'param1' = 'value1',
'param10' = 'value10',
}
things:addthing { 'third':
'param1' = 'value1',
'param10' = 'value10',
}
(actually it's not 10 but 9).
How can I use a array ?
Thanks for your answer.
Regards.
JAS
--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
xmpp: j...@obspm.fr
Heure local/Local time:
jeu 18 jui 2015 16:05:23 CEST
--
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/20150618141445.GB36278%40pcjas.obspm.fr.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions
FWIW I find this argument pretty compelling and would like to advance the version number of the next release of puppet-agent to '4.something'. Our current thinking is that this will be a matched to the puppet version, with an extra digit on the end of the version number that indicates component revisions other than Puppet itself. So specifically, the next release will be puppet-agent-4.2.0.0; a hypothetical rev to include a not-very-hypothetical openssl update would be included in a puppet-agent-4.2.0.1 package. sounds good to me. - Thomas -- 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/a3c3f8ab-4189-4a87-8d85-e92ed8b3f062%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: Puppet Enterprise 3.8.1 is available
Dear Puppet Enterprise Users, Puppet Enterprise 3.8.1 is now available. This is a bug-fix and security release of Puppet Enterprise. All users of Puppet Enterprise 3.x are encouraged to upgrade when possible to Puppet Enterprise 3.8.1 Puppet Enterprise 3.8.1 includes fixes to address security vulnerabilities in OpenSSL, PostgreSQL, ActiveMQ, RubyGems, and the Puppet Enterprise Certificate Authority Reverse Proxy. Puppet Enterprise 3.8.1 also includes a number of other bug fixes. For additional information on the fixes in this release, please see https://puppetlabs.com/security and https://docs.puppetlabs.com/pe/latest/release_notes.html. As a current Puppet Enterprise user, you can upgrade to this new version as part of your annual subscription. If upgrading, it is recommended to upgrade your master and console servers first. As always, we want to hear about your experiences with Puppet Enterprise. If you have any questions about upgrading, be sure to get in touch with Puppet Labs Support. Geoff Nichols Release Engineer, Puppet Labs *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. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CADjnYBzxsUzwDo8YiU14un3hicGTpNrDFibLsgHeB99BhqTv%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] debugging catalog issue for one client after upgrade
All- I'm using puppet (open source) 3.7.5 on our master (RHEL6.6, x86_64) and all clients (RHEL 5.x, RHEL 6.x, RHEL 7.x). I'm refreshing the hardware on our puppet master, and wanted to take the opportunity to switch the master to RHEL 7 (and therefore new Ruby and some ruby libraries). I'm sticking with puppet 3.7.5 during the hardware/OS refresh. I've been through upgrades on the puppet master before, and have found the Option 1: spin up a temporary master section of https://docs.puppetlabs.com/guides/install_puppet/upgrading.html to be very useful. After copying /etc/puppet (including our version-controlled modules) and /var/lib/puppet/ssl from the production RHEL 6 master to the replacement RHEL 7 master, and starting puppet on the new master as recommended: puppet master --no-daemonize --verbose I've gone through every one of our puppet clients and run puppet agent --test --noop # against current production puppet agent --test --noop --server new-master Both the old master and the new master return identical catalogs for every client ... except one. On one client, it appears that the *client* may be closing the connection very shortly after supplying facts to the new master. I've run both the new master and the client with --debug, and there's no obvious error messages or output that would indicate what the source of the problem is. The client only says: $ sudo puppet agent --test --noop --server new-server Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Broken pipe Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run This client happens to be our largest, as far as # of resources (about 1700, mostly because of a bunch of web proxy lines added to a httpd config file via a define() and concat). The old master takes a while to compile the catalog (so much so that I sometimes have to specify --configtimeout=300 on the client when communicating with the old master), but it does reliably compile and deliver the catalog. The communication between the client and the new master breaks very quickly (within a few seconds), so it's not the same timeout causing the issue. Any suggestions for how I proceed with debugging this issue? I can provide the output from --debug for both the new master and the client, if anyone is interested in looking through it. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
[Puppet Users] Re: Suggestion for PE 3.7 Agent Errors (RHEL 5, 32-bit) Regarding curl -k
thanks.. this solved my problem.. On Saturday, November 22, 2014 at 4:00:03 PM UTC-5, David Waters wrote: My previous PE 3.2 installation was great...then I moved to PE 3.7 and lost hours of sleep. If you follow the PE Agent installation guide for RHEL 5 (32-bit) while the Master runs RHEL 6 (64-bit): *Scenario 2*: The OS/architecture of the Puppet master and the agent node are different. [other steps skipped] curl -k https://puppet.yourdomain.com:8140/packages/current/install.bash | [sudo] bash * # sudo is unnecessary if you are root!* and you get a curl error on the agent that looks like: curl: (35) Unknown SSL protocol error in connection to puppet.yourdomain.com:8140 Try using the following command instead: # curl --insecure --tlsv1 https://puppet.yourdomain.com:8140/packages/current/install.bash https://cm-elite311-01.mba.lan:8140/packages/current/install.bash | bash However, I have yet to get the agent on the RHEL5 box to report to the master on RHEL6. Also, I'm still trying to resolve failures of MCollective on the Windows7 agent (16 failures related to MCollective) but 72 other resources run fine. -- 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/c3a03439-0d69-4f4a-bd7f-62e2db351ae0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: Puppet Server 2.1.1 and 1.1.1 available!
We're pleased to announce that Puppet Server 2.1.1 and 1.1.1 are both now available! Both of these releases are backwards compatible bug fix and security releases in their respective Semantic Versioning http://semver.org/ major versions. This email is a combined announcement for 2.1.1 and 1.1.1. Puppet Server 2.1.1 This release updates the included JRuby from 1.7.20 to 1.7.20.1 and its embedded Rubygems from 2.4.6 to 2.4.8 to address CVE-2015-4020. CVE-2015-4020 is related to wildcard matching of hostnames in the Rubygems client and is also closely related to CVE-2015-3900. More information on CVE-2015-3900 is available at http://blog.rubygems.org/2015/05/14/CVE-2015-3900.html. This release also includes some changes needed for forward compatibility with Native Facter (Facter 3) which will be included in a forthcoming puppet-agent release. In addition, the following bugs have been resolved in Puppet Server 2.1.1: - SERVER-297 - Consolidate environment variable handling behaviors - SERVER-646 - /certificate_status(es) implementation is too strict about Content-Type - SERVER-692 - Use hard-coded defaults for master-*-dir settings not specified in puppetserver.conf - SERVER-723 - Error responses to some CA requests mangle Content-Type - SERVER-759 - Legacy routes service breaks usage of CA-disabled service See the complete release notes for details about these changes: https://docs.puppetlabs.com/puppetserver/2.1/release_notes.html For a list of all changes in this release, check out the JIRA page: https://tickets.puppetlabs.com/browse/SERVER/fixforversion/13612 Puppet Server 1.1.1 This release updates the included JRuby from 1.7.20 to 1.7.20.1 and its embedded Rubygems from 2.4.6 to 2.4.8 to address CVE-2015-4020. CVE-2015-4020 is related to wildcard matching of hostnames in the Rubygems client and is also closely related to CVE-2015-3900. More information on CVE-2015-3900 is available at http://blog.rubygems.org/2015/05/14/CVE-2015-3900.html. In addition, the following issues have been resolved in Puppet Server 1.1.1: - SERVER-646 - /certificate_status(es) implementation is too strict about Content-Type - SERVER-721 - Consolidate environment variable handling behaviors - SERVER-723 - Error responses to some CA requests mangle Content-Type See the complete release notes for details about these changes: https://docs.puppetlabs.com/puppetserver/1.1/release_notes.html For a list of all changes in this release, check out the JIRA page: https://tickets.puppetlabs.com/browse/SERVER/fixforversion/13613 EOF -- 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/e7d4bc9c-0e0b-44a0-b049-ecdccfd80ae8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions
This is better than what is currently being used, but I'm strongly in the AIO idea to be stupid. Split it into multiple packages and use proper dependencies like every other sane packaging system has done for a long, long time. If all you do is bump the version of facter, then only have me download and install the meta package that depends on the new facter, and the new facter package, not everything. rant I'm only planning on using AIO packages on the server side and stick with the gem packages on the client side. With multiple client types (multiple versions of OS X, multiple versions and distributions of Linux, various architectures), I know the gem packages can be handled the same way on all of them.When I'm adding a node to the network, I like being able to do type gem install puppet, set up the key, then let puppet take care of the rest. With the AIO packages, I have to start out doing puppets job and add a repo and refresh my package manager before I can get to the step of installing puppet. Not to mention praying that the platform is even supported by the AIO packages. /rant On Wednesday, June 17, 2015 at 12:12:31 PM UTC-7, Eric Sorenson wrote: On Thu, 7 May 2015, jcf wrote: I don't think that reflects a firm grasp of the nature of the problem. The issue is that the new thing here is not the thing that the package's version number should be describing in the first place. I don't care about the newness of AIO layout and packaging, and I don't expect many others will either. People don't install Puppet for its packaging. I do care about the versions of various components of the system, but not everyone will, and anyway, we have already established that an AIO package's version number is not a good vehicle for communicating information about versions of auxilliary components. Focus on what's important. To your audience. I am also pretty baffled that this is considered hard, or even a matter for debate. Principle of Least Surprise, or just have the contents match the tin. FWIW I find this argument pretty compelling and would like to advance the version number of the next release of puppet-agent to '4.something'. Our current thinking is that this will be a matched to the puppet version, with an extra digit on the end of the version number that indicates component revisions other than Puppet itself. So specifically, the next release will be puppet-agent-4.2.0.0; a hypothetical rev to include a not-very-hypothetical openssl update would be included in a puppet-agent-4.2.0.1 package. (We can't use the release field as suggested up-thread, because some packaging systems don't view numbers not part of the 'version' field to be an upgrade.) Does that align more closely with the least-surprising thing, to you? Eric Sorenson - eric.s...@puppetlabs.com javascript: - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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/ecec4c5e-3b0b-41f5-a126-3cdc08716369%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Check service running with flag file
Hi,
Found a solution:
Create ruby script in:
root@foreman]# cat
/etc/puppet/environments/production/modules/customfacts/lib/facter/check_file_exsist.rb
Facter.add('check_nails_exsist') do
setcode do
File.exists?('/etc/NONAILS')
end
end
We are checking if /etc/NONAILS exist, if yes return true else false.
Create puppet manifest to ensure the service running, if file exist stop
the server:
[root@foreman]# cat
/etc/puppet/environments/production/modules/check_service/manifests/init.pp
# Class: check_service
class check_service {
if $check_nails_exsist == 'true' {
service { 'nails':
ensure = stopped,
enable = false,
hasstatus = false,
hasrestart = false,
}
}
else {
service { 'nails':
ensure = running,
enable = true,
hasstatus = false,
hasrestart = true,
}
}
}
Hope it helped.
On Thursday, June 11, 2015 at 4:06:53 PM UTC+3, jcbollinger wrote:
On Thursday, June 11, 2015 at 7:24:57 AM UTC-5, Eddie Mashayev wrote:
Thanks, do you have any other suggestion how can I do it properly?
I want “nails” process to be running only if there is no /etc/NONAILS
flag in my OS.
The canonical way to inform the catalog compiler about node state is via
node facts. It should be pretty straightforward to create a custom fact
that simply reports on the presence or absence of one file; then you put
the Service resource in a conditional block that depends on the value of
that fact.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/728e087f-16c5-4f95-8663-cd181b7dd7dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
