Re: [Puppet Users] Foreman 1.19 > Puppet (5.5.6) > Centos 7: "certificate has expired for /CN=Puppet CA".
On 28.09.22 23:52, JB SysAdmin wrote: I followed a combination of what I saw: On puppet master: rm -rf /etc/puppetlabs/puppetdb/ssl puppetserver ca generate --config /etc/puppetlabs/puppet/puppet.conf puppet master --no-daemonize --verbose puppet resource service puppetserver ensure=running puppet resource service puppet ensure=running From your descriptions it doesn't look like you actually restarted Puppetserver after regenerating the CA, so maybe try that first: "systemctl restart puppetserver" (as root). /opt/puppetlabs/server/apps/puppetdb/bin/puppetdb ssl-setup -f puppet resource service puppetdb ensure=running Similarly restart PuppetDB, "systemctl restart puppetdb". The "puppet resource ... ensure=running" commands don't restart any service. They would just start a service if it wasn't running. But on the master itself, and certainly a separate client/agent, there are any number or errors. Not sure if you did that already, but when regenerating the CA, as you have done, you'll need to issue new certificates to all Puppet agent nodes. On a Puppet agent node: rm -rf /etc/puppetlabs/puppet/ssl puppet agent -t --waitforcert 30 On the Puppetmaster (= Puppet CA server): puppetserver ca list puppetserver ca sign --certname Do that for all Puppet agent nodes. HTH, Andreas -- 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/17f87e97-4e57-6d76-c2ad-9570045ac0fb%40ptmx.org.
Re: [EXTERNAL] - [Puppet Users] Puppet agent is not applying changes
On 28.09.19 12:15, Martin Alfke wrote:
> Hi Dirk,
>
> you are including class accounts within node default classification.
> The accounts module does not do anything unless you add data to it.
>
> Please look at https://github.com/puppetlabs/puppetlabs-accounts and check if
> the following example is working:
It doesn't look like Dan is using the puppetlabs-accounts module. His
accounts module just creates a user and a group (copy/pasting the code
from the initial post):
# more
/etc/puppetlabs/code/environments/production/modules/accounts/manifests/init.pp
class accounts {
include accounts::groups
user { 'djc72uk':
ensure => present,
home=> '/home/djc72uk',
shell => '/bin/bash',
managehome => true,
gid => 'djc72uk',
}
}
# more
/etc/puppetlabs/code/environments/production/modules/accounts/manifests/groups.pp
class accounts::groups {
group { 'djc72uk':
ensure => present,
}
}
Andreas
--
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/f8268645-38fd-16c9-9485-60ca93debfaa%40ptmx.org.
signature.asc
Description: OpenPGP digital signature
Re: [EXTERNAL] - [Puppet Users] Puppet agent is not applying changes
On 27.09.19 18:11, Dan Crisp wrote:
> Thanks for the reply John,
>
> The issue still persists unfortunately.
>
> I've ensured that Selinux isn't enforcing on both the server side and
> client and then restarted the Puppet service on the master server. The
> server logs whilst running the agent read as follows:
Are you positive the user and group really haven't been created?
And have you changed
node 'default' { ... }
to
node default { ... }
i.e. without the single quotes, as suggested? And afterwards restarted
the Puppetserver process by means of, e.g. systemctl restart puppetserver?
If so, and this hasn't helped, you may want to try to narrow the problem
down by simplifying the default node manifest even more, by making
site.pp look like this (verbatim):
node default {
fail('Failing deliberately on default node manifest')
}
Don't forget to restart the Puppetserver after that to make sure the
change is picked up.
When you then run the Puppet agent on the troublesome node it should
fail hard with the message defined above. If it does then you know at
least that site.pp is read and a catalog is created and applied for that
node. If it does not then there must be something else amiss that is not
obvious from the information and details you posted.
HTH
Andreas
--
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/48f7aa63-ed60-d5c8-d36c-d302c01d4130%40ptmx.org.
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Re: troubleshooting collected resources, how to.
On Monday, 17 December 2018 21:20:12 UTC+1, Trey Ormsbee wrote: > > I'm having a problem with a node not collecting resources. I have never > really had any issues before so never needed to troubleshoot this and Im > not sure where to look. > > Issue: > I have a node that exports a resource with a specific tag, it is written > into puppetdb sql database so as far as I can tell that is good to go. The > node that is too collect that tag is not collecting it. > A simple explanation may be that the node that is supposed to collect these exported resources does not include the class that actually defines the resource collection. So you may need to take another look at which classes your collecting node includes, maybe you are missing one. Apart from that it is hard to say much without looking at the Puppet manifests in question. Andreas -- 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/1b935496-b534-4bfb-9487-3fc0bf5a86bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Is there a more elegant way of declaring this variable and its value?
On 2015-10-05 17:51, Fabien Delpierre wrote:
> Hey folks,
> I have something like this in a manifest:
>
> class foo(
> $python_pips = {
> pbr => { ensure => '1.3.0', install_args => ['-I'] },
> linecache2 => { ensure => '1.0.0', install_args => ['-I'] },
> elasticsearch => { ensure => '1.6.0', install_args => ['-I'] },
> },
> ) {
> require python
> create_resources('python::pip', $python_pips)
> }
>
> I'm using this module: https://github.com/stankevich/puppet-python
>
> I'm wondering if there's a more elegant way of telling the python::pip
> resource to use the -I flag when installing those three pip packages.
The create_resources function supports a third argument for just this
use case: a hash with defaults for each created resource
(https://docs.puppetlabs.com/references/3.stable/function.html#createresources).
This works just fine in Puppet 3.x.
In your case you would do:
```
$python_pips = {
pbr => { ensure => '1.3.0' },
linecache2 => { ensure => '1.0.0' },
elasticsearch => { ensure => '1.6.0' },
}
$python_pip_defaults = {
install_args => [ '-I' ],
}
require python
create_resources('::python::pip', $python_pips, $python_pip_defaults)
```
You can define that defaults hash in Hiera as well:
```
foo::python_pip_defaults:
install_args: [ '-I' ]
proxy: 'http://proxy.example.com:3128'
foo::python_pips:
"pbr":
ensure: 1.3.0
"linecache2":
ensure: 1.0.0
"elasticsearch":
ensure: 1.6.0
```
Then in your profile (or whatever kind of wrapper class you use):
```
$pips = hiera_hash('foo::python_pips', {})
$pip_defaults = hiera_hash('foo::python_pip_defaults', {})
create_resources('::python::pip', $pips, $pip_defaults)
```
We make use of this pattern extensively in our profile classes whenever
there are resources to create (usually defined or native types).
HTH Andreas
--
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/56146745.3080500%40pseudoterminal.org.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Access to apt.puppetlabs.com slow for some IP addresses
On 2014-08-06 11:11, Johannes Grassler wrote: Hello, we are currently creating and tearing down lots of VMs in our lab environment. This includes retrieving and installing Puppet from the Puppetlabs repository at apt.puppetlabs.com. Not an answer to your question directly, but for lab environments (or any kind of environment, really) it is probably a good idea to set up an APT cacher or some other kind of APT forward proxy. This will certainly speed up package downloads on your lab machines and the impact on the upstream repositories will be minimised. We run Apache Trafficserver as a forward proxy but there are other options, such as squid-deb-proxy which is probably what I'd use in a new lab environment. Easier to run than a real mirror and usually requires almost no maintenance at all. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Puppet 3.6.2: force manifests reload
On 2014-07-26 18:46, Sergey Arlashin wrote: Hi! I'm using webrick based puppetmaster. After upgrading to 3.6.x I noticed that when I alter some of my manifests or templates puppet continues to apply the old set of manifests. Puppet agents behave like there are no changes at all. It usually takes puppet 2-5 minutes to start shipping the new config. I can restart puppet master and then everything goes well. But I'd like to do without restarting puppet master. The documentation says that something like this can be achieved by touching site.pp . But I don't use site.pp any more due to 'import' deprecation, and touching all files in manifests folder doesn't solve the problem. So the question is - is it possible to force the reload of my manifests without restarting puppet master? Or may be switching to passenger based puppet can solve the problem ? Environments and their manifests are cached for three minutes by default so this is what you are seeing here. Have a look at http://docs.puppetlabs.com/puppet/latest/reference/environments.html#tuning-environment-caching and http://docs.puppetlabs.com/references/3.6.latest/configuration.html#environmenttimeout for more information and how to change the default behaviour. Switching to Apache and Passenger is definitely recommended though, for numerous reasons (http://docs.puppetlabs.com/guides/passenger.html). With Passenger getting the Puppetmaster to reload the cached environments is as easy as running service apache2 reload. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Facter resolved to an invalid value
On 2014-05-13 16:34, Viktor Jevdokimov wrote: On some CentOS servers we started to receive an error: Fact resolution fact='env', resolution='anonymous' resolved to an invalid value: Expected prod to be one of [Integer, Float, TrueClass, FalseClass, NilClass, String, Array, Hash], but was Symbol The error message is fairly self-explanatory, no? Facter needs facts to return strings, booleans, arrays or hashes. Your fact returns Ruby symbols, which Facter doesn't like. Change :dev, :prod and :default to dev, prod and default and it should work. HTH Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Hiera.yaml not interpolate variables
On 2014-05-08 17:21, Israel Calvete wrote:
Hi,
This is my hiera config.
/---/
/:backends: - yaml/
/:hierarchy: - %{::environment}/
/- common/
You must use double quotes when you want interpolation to work. See
http://docs.puppetlabs.com/hiera/1/variables.html#interpolation-tokens
In YAML files, any string containing an interpolation token must be
quoted in order to comply with the YAML spec. (Under Ruby 1.8,
interpolation tokens in unquoted strings will sometimes work anyway, but
this can’t be relied on.)
So that should be %{::environment}, instead of simply %{::environment}.
Andreas
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Overriding specific values within a Hiera hash
On 2014-05-02 23:57, Matthew Burgess wrote: Hi all, This is probably a real newbie question, but I'm having trouble overriding a value in Hiera that is defined in my common.yaml in a more specific role-based yaml file: [...] Is it possible to only override the size parameter of the var_vol entry? Sound like you want to install deep-merge (packaged by Puppetlabs for Debian as ruby-deep-merge and for RedHat as rubygem-deep-merge) on the Puppet master, set :merge_behavior: deeper in /etc/puppet/hiera.yaml (and/or /etc/hiera.yaml) and restart the Puppet master. You can find documentation about Hiera merge types and behaviour here: http://docs.puppetlabs.com/hiera/1/lookup_types.html#hash-merge HTH Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Overriding specific values within a Hiera hash
On 2014-05-03 00:40, Matthew Burgess wrote:
On 2 May 2014 23:04, Andreas Ntaflos d...@pseudoterminal.org
mailto:d...@pseudoterminal.org wrote:
Sound like you want to install deep-merge (packaged by Puppetlabs for
Debian as ruby-deep-merge and for RedHat as rubygem-deep-merge) on
the Puppet master, set :merge_behavior: deeper in
/etc/puppet/hiera.yaml (and/or /etc/hiera.yaml) and restart the Puppet
master.
Just googling a bit leads me to a really small nuance in the text in the
link you posted. The merge behaviour described on that page is for
'hash merge lookups' and not every Hiera lookup is that. In particular,
automated class parameter binding uses hiera() not hiera_hash() so
doesn't do a hash merge lookup. If I've read the code in lvm/init.pp
correctly, that appears to be the reason for what I'm seeing.
Right, hiera() does priority lookups, and does not merge data.
hiera_hash() and hiera_array() can and will merge data if
:merge_behavior is set to deeper and the deep-merge Gem is
installed. I think the documentation of Hiera
(http://docs.puppetlabs.com/hiera/1/index.html) covers these differences
and nuances nicely.
So, I guess there's 3 questions now:
1) Have I understood the code and documentation correctly and come to
the correct conclusion about why I'm seeing the behaviour I am?
I believe so, yes.
2) Is there a reason why the automatic class parameter binding uses
hiera() and not hiera_hash() when the parameter is a hash?
This is by design
(http://docs.puppetlabs.com/hiera/1/puppet.html#limitations), but I
don't know much about the reasons behind it.
3) Is there anything I can do to 'fix' this particular issue? I don't
mind carrying a local patch to puppetlabs/lvm if that's what's required,
or a config change. If not, I'll just have to resign myself to having
data duplication; the number of places we have to override the size of a
common filesystem is very low, as are the chances that the common
filesystem sizes will change in common.yaml.
This is usually a case for a profile class that calls hiera_hash() and
create_resources(). Here's one way to go about it (note that I don't
know or use the puppetlabs-lvm module myself, and the following is
untested):
# /etc/puppet/environment/production/modules/profile/manifests/lvm.pp
class profile::lvm {
include '::lvm'
$physical_volumes = hiera_hash('profile::lvm::physical_volumes', {})
create_resources('physical_volume', $physical_volumes)
$volume_groups = hiera_hash('profile::lvm::volume_groups', {})
create_resources('volume_group', $volume_groups)
$logical_volume = hiera_hash('profile::lvm::logical_volumes', {})
create_resources('logical_volume', $logical_volumes)
}
# /etc/puppet/hieradata/common.yaml
---
profile::lvm::physical_volumes:
'/dev/sda3':
ensure: present
profile::lvm::volume_groups:
'rootvg':
ensure: present
physical_volume: /dev/sda3
profile::lvm::logical_volumes:
root_vol:
size: 1G
volume_group: rootvg
mountpath: '/'
mountpath_require: true
var_vol:
size: 4G
volume_group: rootvg
mountpath: '/var'
mountpath_require: true
# /etc/puppet/hieradata/web.yaml
---
profile::lvm::logical_volumes:
var_vol:
size: 18G
The above defines a profile::lvm class which you can include on nodes
where you manage LVM. It uses hiera_hash() to look up hashes of data
that can be fed into the puppetlabs-lvm types physical_volume,
volume_group and logical_volume, and calls create_resources() on these
types with that data. See
http://docs.puppetlabs.com/references/latest/function.html#createresources
for details on create_resources().
In common.yaml we defined that data in the form of YAML hashes under the
lookup keys the profile::lvm class expects. In web.yaml we override the
size parameter for the var_vol LV, so a node that includes profile::lvm
and gets its data from the hierarchy level on which web.yaml resides
will have an 18GB LV named var_vol in the VG rootvg, mounted under /var.
A more complete, practical and real-world example of roles and profiles
with Hiera can be found here:
https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/.
It uses the same concepts as the profile::lvm class above.
Andreas
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] How to check a text file for a certain line?
On 2014-04-22 00:10, Joachim Schrod wrote: On 04/21/14 19:42, Kenton Brede wrote: Look into using file_line, it's part of stdlib. https://forge.puppetlabs.com/puppetlabs/stdlib Hmm, I don't detect any documentation of file_line at that URL. Could you post another link with documentation? Funny that it doesn't seem to be mentioned in the README anymore, but here is the code and the documentation: https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/type/file_line.rb Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Re: Can ERB templates be used to process hashes of arbitrary depth?
John,
thank you very much for the most informative reply.
On 2014-04-08 16:31, jcbollinger wrote:
Actually, no, sorting the keys is a primary concern because otherwise
the computed content may not be stable, which could cause Puppet to
needlessly update the file.
By that statement I meant that I am aware that we should sort hash keys
before using them, and I usually know how to do it :)
So, here's an attempt at an ERB template to produce that output from the
given input:
strongswan.conf.erb:
-
%
default_handler = Proc.new do |v|
% = %= v.to_s %
%
end
hash_handler = Proc,new do |v|
% {
%
v.sort_by { |k,v| k }.each do |pair|
%%= pair[0] %%
(v.is_a? Hash ? hash_handler : default_handler).call(v)
end
%
}
%
end
-%
charon %
hash_handler.call(@charon_config)
%
Thanks very much for this, I'll get to work on it as soon as we dealt
with the ramifications of CVE-2014-0160.
I've never tried using procs inside an ERB before, but I think it will
work, and I haven't come up with another means to handle recursion
inside a template. Do note, however, that the template is almost all
Ruby. That's a good sign that you would be better off writing it as a
custom function
(http://docs.puppetlabs.com/guides/custom_functions.html) to generate
the output.
A colleague suggested the same, sounds like a good approach.
Note, too, that the above ERB, if it works, leaves indentation as an
exercise for the reader. :-)
I think we can manage that :)
Thanks again!
Andreas
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Can ERB templates be used to process hashes of arbitrary depth?
Hi list,
I am in the process of writing a module to manage strongSwan, an IKE
keying daemon for IPsec VPNs on Linux [1]. The strongSwan daemon's
(charon) configuration file is basically formatted like a hash, with
sections containing key-value pairs that may themselves contain further
sections [2]. Sections may also be empty. I don't think there is a
maximum depth defined.
It seems to me that this kind of configuration file format is easily
modelled as a Puppet/Ruby hash, so now I am wondering how I can go about
rendering the configuration file from such a hash.
Is it feasibly to use an ERB template for this? You may notice that I am
(still) not much of a Ruby guy and I don't want to reinvent any wheels,
so I am asking: what are my options?
Can ERB templates in Puppet be used to render hashes of arbitrary depth?
Or should I look to something else? Can this even be done?
I'd appreciate any and all pointers and ideas.
Here is an example hash that I would supply as a parameter to my
strongswan class:
charon_config = {
ikesa_limit= '0',
install_virtual_ip = 'yes',
keep_alive = '20s',
host_resolver = {
max_threads = '3'
},
processor = {
priority_threads = {
high = '1',
medium = '4'
}
},
tls = {},
x509 = {}
}
This should result in the following configuration file content (sorting
the keys is only of secondary concern):
charon {
ikesa_limit = 0
install_virtual_ip = yes
keep_alive = 20s
host_resolver {
max_threads = 3
}
processor {
priority_threads {
high = 1
medium = 4
}
}
tls {
}
x509 {
}
}
Thanks in advance,
Andreas
[1] http://www.strongswan.org/
[2] http://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Announce: Facter 2.0.1
On 2014-04-02 11:02, DjE wrote: The issue (-d does not provide more informations) : facter -p undefined method `puppetversion' for Facter:Module Something like this can also happen when you have a custom fact (or function?) that calls the Facter API in a now defunct way. For example, we had this in a custom fact: if Facter.puppetversion.to_i = 3 ... Which had to be replaced with this (works in Facter 2.0.1, too): if Facter.value(:puppetversion).to_i = 3 ... This was kindly pointed out to me and fixed by Dominic Cleal in #puppet. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Puppet require - failure handling
On 2014-01-05 11:37, Jose Luis Ledesma wrote: There is not after or before when puppet applies a manifest if there are not dependencies explicitly declared. In the example you have written mysql and apache will be applied in no particular order between them, but will be implemented both before any other resource in the WordPress class. If you want mysql or apache implemented before the other, you can chain classes: Class['mysql']=Class['apache'] To be syntactically correct that should be Class['mysql'] - Class['apache'] with a - and not a =. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Puppet and scripts.
On 2013-11-21 19:08, Daniel Lyons wrote: We've got a decently complicated .sh script used to set up oracle database, inlcuding partioning and the like. If I attempt to run it through puppet the script will end after 300 seconds as timed out. To test a simpler case I just made a little script as such: Exec has a timeout parameter: http://docs.puppetlabs.com/references/latest/type.html#exec-attribute-timeout HTH Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Re: puppetdb, foreman, one particular node has a problem
On 2013-10-16 10:07, Steve Wray wrote: It turned out that there was an update to the foreman package which completely broke Puppets ability to enroll new nodes. Call me old fashioned, I've been a Debian sysadmin for over 10 years, but on a 'stable' system an apt-get upgrade is not supposed to break things. Thats one of the things Debian is famous for. Just so happens my server is running Ubuntu server 'long term support' version and I expected something similar there. I've spent some time now ripping Foreman out. Its too unreliable and I don't think the benefits outweigh the costs. Puppet *without* foreman is just fine. Bye bye, foreman, I'll hardly miss you. You are complaining on the wrong mailing list. If you have feedback for the Foreman developers please head over to https://groups.google.com/forum/#!forum/foreman-users and bring the topic up there. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Re: Packages for Ubuntu 13.04 (raring)
On 2013-06-14 01:49, Vlad wrote: Any news about the packages for Raring? I've opened a bug report for this: http://projects.puppetlabs.com/issues/21242 No feedback yet. Andreas signature.asc Description: OpenPGP digital signature
[Puppet Users] Packages for Ubuntu 13.04 (raring)
It seems there are no packages available for Ubuntu 13.04. There is a puppetlabs-release package for raring, but except for that the directory http://apt.puppetlabs.com/pool/raring/main/p/ is empty. I see no packages anywhere else for 13.04, only the ones in the official Ubuntu repos. This doesn't seem right, does it? Andreas -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet 3.2.1 default log level change?
On 27/05/13 11:20, Matthias Saou wrote: Hi, The replies to the 3.2.1 release announcement seem to indicate I'm not the only one to have been bitten by the change. I've opened an issue for this: http://projects.puppetlabs.com/issues/20919 Andreas -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Announce: Puppet 3.2.1 Available
On 24/05/13 11:43, Paul Tötterman wrote: Did something change in the way Puppet outputs messages? Until this morning we used the following to run Puppet from Cron on all our nodes: But as of 3.2.1 this produces output on every Puppet agent run and that output is mailed out, resulting in hundreds of messages which contain nothing of importance (see below). This had worked fine for almost two years now, with output only generated on errors and problems (such as DNS not available). I'm having the same issue. I couldn't find a bug report about this. There is --verbose and --debug, but not --silent or --quiet. Should we maybe use --logdest? Anyway the behaviour has changed from 3.1.1 We have always been using --logdest syslog, it is only with 3.2.1 that log messages now seem to go not only to syslog but also to stdout, which is why Cron generates annoying mail messages. Even more interesting: before 3.2.1 /var/log/syslog would only show the finished catalog run message when running Puppet from Cron with puppet agent -o --no-daemonize --logdest syslog: May 21 09:30:01 node01 CRON[14018]: (root) CMD (/usr/bin/puppet agent --onetime --no-daemonize --logdest syslog) May 21 09:30:38 node01 crontab[15379]: (root) LIST (root) May 21 09:30:38 node01 puppet-agent[14019]: Finished catalog run in 17.33 seconds Now it shows everything in /var/log/syslog: May 24 07:15:01 node01 CRON[23182]: (root) CMD (/usr/bin/puppet agent --onetime --no-daemonize --logdest syslog /dev/null 21) May 24 07:15:02 node01 puppet-agent[23183]: Retrieving plugin May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/postgres_default_version.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/corosync_mcastaddr.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/root_home.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/lvm_disk_usage.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/corosync_mcastport.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/libvirt_guests.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/libvirt_used_memory.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/has_libvirtd.rb May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in /var/lib/puppet/lib/facter/has_group_libvirtd.rb May 24 07:15:22 node01 puppet-agent[23183]: Caching catalog for dbb01.db01.prod.rz01.riseops.at May 24 07:15:24 node01 puppet-agent[23183]: Applying configuration version '1369362429' May 24 07:15:43 node01 crontab[24545]: (root) LIST (root) May 24 07:15:43 node01 puppet-agent[23183]: Finished catalog run in 20.11 seconds So, I am asking the Puppet devs: is this behaviour intended or a bug? Should I open a bug report? Andreas -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Announce: Puppet 3.2.1 Available
On 2013-05-22 21:54, Matthaus Owens wrote:
Puppet 3.2.1 is a bugfix release for the 3.x series of Puppet.
Did something change in the way Puppet outputs messages? Until this
morning we used the following to run Puppet from Cron on all our nodes:
cron { 'puppet_agent':
ensure = 'present',
command = '/usr/bin/puppet agent -o --no-daemonize --logdest syslog',
user= 'root',
minute = [ $min1, $min2, $min3, $min4 ],
}
But as of 3.2.1 this produces output on every Puppet agent run and that
output is mailed out, resulting in hundreds of messages which contain
nothing of importance (see below). This had worked fine for almost two
years now, with output only generated on errors and problems (such as
DNS not available).
We had to change the cron resource to this:
cron { 'puppet_agent':
ensure = 'present',
command = '/usr/bin/puppet agent -o --no-daemonize --logdest syslog
/dev/null 21',
user= 'root',
minute = [ $min1, $min2, $min3, $min4 ],
}
Is this behaviour change a bug or expected?
Andreas
Typical Puppet agent run output mailed by Cron as of Puppet 3.2.1:
[0;32mInfo: Retrieving plugin[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/lvm_disk_usage.rb[0m
[0;32mInfo: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/puppet_vardir.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/corosync_mcastport.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/libvirt_guests.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/concat_basedir.rb[0m
[0;32mInfo: Loading facts in /var/lib/puppet/lib/facter/has_libvirtd.rb[0m
[0;32mInfo: Loading facts in /var/lib/puppet/lib/facter/root_home.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/postgres_default_version.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/corosync_mcastaddr.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/has_group_libvirtd.rb[0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/libvirt_used_memory.rb[0m
[0;32mInfo: Caching catalog for devfw01.fw.rz01.riseops.at[0m
[0;32mInfo: Applying configuration version '1369264386'[0m
[mNotice: Finished catalog run in 17.63 seconds[0m
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Puppet agent exit code for monitoring script
On 04/12/12 16:40, Felix Müller wrote: Hello, I would like to build a script, which notifies me, when a production host notices, that there change on a host, based on the Puppet exit codes without executing it. Probably easier and more effective to examine /var/lib/puppet/state/last_run_summary.yaml. As obvious from the filename it contains information about the latest Puppet run in a simple YAML format. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] How to setup puppet 0.25.5-1 client in UBUNTU12.04 64 bit
On 06/11/12 12:24, WhiteB wrote: How to setup puppet 0.25.5-1 in ubuntu12.04, the normal updates taking me to higher version of puppet client. Puppet 0.25 has not been supported for a long time now and its use is not recommended. You will not find official packages for this very old version, certainly not in the Ubuntu repositories, but you can download the sources for old versions here: http://downloads.puppetlabs.com/puppet/ I have no idea, however, if or how well they will work on Ubuntu 12.04. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Upgrading puppet 2.7.19 to 3.0.1
On 2012-10-31 03:01, thinkwell wrote: So now I have puppet 3.0.1 installed from the puppetlabs debian repo and I thought I'd fought my way through the thicket, but I've hit a wall with this error When running puppet agent on the clients. I get the following error: Ruby (Rack) application could not be started Just an idea, are you using the config.ru file updated for 3.0, provided by the puppet-common package? Should be in /usr/share/puppet/ext/rack/files/config.ru or /usr/share/puppet/rack/puppetmasterd/config.ru. Andreas signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] How to set DNS on Ubuntu 12.04 clients?
On 11/09/12 16:00, Sandra Schlichting wrote:
Hi all =)
Does anyone know of a module that can configure the DNS on Ubuntu 12.04
clients?
This module works for CentOS and Ubuntu 12.04
http://forge.puppetlabs.com/saz/resolv_conf
but in Ubuntu 12.04 you can't just overwrite the /etc/resolv.conf
anymore. DNS have to be set in /etc/network/interfaces
Not necessarily. I have not tried this myself yet, but you can put
static DNS settings in /etc/resolvconf/resolv.conf.d/{head,base,tail}.
Afterwards call service resolvconf restart. See here for details:
http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/
You should be able to adapt the resolv_conf module accordingly, or write
your own.
Andreas
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Module critique
On 2012-09-04 17:26, Bai Shen wrote:
I've gotten an install of solr working, but it's pretty much a hack job
at the moment. If y'all could give me your thoughts on how to improve
my setup, I'd appreciate it. apache-tomcat is an rpm of Tomcat 7 that
references the oracle jdk instead of openjdk.
I don't know Solr so I am not exactly sure how it is set up and run, so
take the following only as guidelines, not as explicit instructions. It
seems Solr requires Tomcat, so you could either implicitly manage Tomcat
within your Solr module (bad), or have a separate Tomcat module with
which your Solr module can interface (good). You would then bring the
modules together in a separate profile or role class. Regardint that,
have a look at this insightful blog post by Craig Dunn:
http://www.craigdunn.org/2012/05/239/
class solr {
I recommend you follow best practices and not manage every aspect of
your Solr resource in a single class, but split it up into subclasses,
probably at least: solr::install (install.pp), solr::config (config.pp),
solr::service (service.pp). The solr class (init.pp) then includes all
subclasses and explicitly declares their dependencies among each other,
like so:
class solr {
include 'solr::install'
include 'solr::config'
include 'solr::service'
Class['solr::install']
- Class['solr::config']
~ Class['solr::service']
}
This makes it easier to manage and change later on.
service { 'iptables' :
ensure = stopped,
}
This is strange, as John has noted. Why should Solr have anything to say
about the iptables service on the machine? At most it should interface
with an iptables module to, e.g., open or close ports.
file { '/opt/apache-tomcat/conf/Catalina':
ensure = directory,
}
file { '/opt/apache-tomcat/conf/Catalina/localhost':
ensure = directory,
}
These directories are fairly standard for Tomcat, are they not? Thus
they should be created by your apache-tomcat package, not managed
explicitly by Puppet.
file { '/opt/apache-tomcat/conf/Catalina/localhost/solr.xml':
source = 'puppet:///modules/solr/solr.xml',
owner = 'tomcat',
group = 'tomcat',
mode = '644',
notify = Service['apache-tomcat'],
require = Package['apache-tomcat'],
}
This would go into solr::config.
It is better, IMHO, to use explicit dependencies here as well, i.e. not
notify and require, but something like this:
Package['apache-tomcat']
- File['/opt/apache-tomcat/conf/Catalina/localhost/solr.xml']
~ Service['apache-tomcat']
I guess that depends on your preferences.
But that points out the problem that your module mixes quite a few
resources, but not wholly implicitly. Again I refer you to the blog post
above.
file { '/opt/apache-tomcat/conf/server.xml':
source = 'puppet:///modules/solr/server.xml',
owner = 'tomcat',
group = 'tomcat',
mode = '644',
notify = Service['apache-tomcat'],
require = Package['apache-tomcat'],
}
Also something that should go into a config class. Either solr::config
or apache-tomcat::config.
file { '/opt/solr':
ensure = directory,
recurse = true,
purge = true,
source = 'puppet:///modules/solr/solr',
owner = 'tomcat',
group = 'tomcat',
mode = '644',
notify = Service['apache-tomcat'],
require = Package['apache-tomcat'],
}
file { '/opt/solr/solr.war':
ensure = 'link',
target = '/opt/solr/apache-solr-3.6.1.war',
}
file { '/solr':
ensure = directory,
owner = 'tomcat',
group = 'tomcat'
}
}
Again solr::config. Also, see above.
Well-designed modules are rare and take time and experience to create. I
myself have written around 60 modules over the past nine months but I
would never dare publish any of them on Puppetforge or even Github. It's
hard to make a module of publishable quality (i.e. one that can be used
by someone else without having to look at or change the code).
Andreas
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Facter 1.6.9 complains about No LSB modules are available.
Hi, it seems that Facter 1.6.9 complains that No LSB modules are available. on every run. This is on Ubuntu 10.04 and 12.04, probably others as well. This message (on stderr) usually comes from calling lsb_release -v when no additional LSB modules are installed. Facter apparently calls lsb_release -v -s in facter/lsbrelease.rb. This is neither fatal nor problematic, but very annoying because a typical puppet run used to be silent. Now my Cron mails are full of No LSB modules are available. I also don't quite understand the purpose of this lsbrelease fact. At least on a typical Ubuntu system lsb_release -v -s doesn't output anything other than this useless message. What information is supposed to be encoded in the lsbrelease fact? Is that fact even needed? Thanks, Andreas signature.asc Description: OpenPGP digital signature
