[Puppet Users] actual diff of changed files via email
Hi there, I currently get my puppet run reports via email, can I somehow get the actual diff of the changed files in those emails? I'd like to get the exact same output as if I'm running puppetd -t on the client. Is that possible? Best regards, Andreas Paul -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/NG4ooG6mhs0J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Issue with RPM dependency issue
On Nov 22, 8:43 am, TisMe russlav...@gmail.com wrote: I am running into an issue with perl-DBD-MySQL dependency with mysql in CentOS 5.7. I am trying to remove the mysql client and replace it with with percona version of the mysql client. It will not let me remove the mysql client because of that dependency. I have already defined perl-DBD-MySQL in a different class... I would rather not create an Exec[]. I would rather do that as a last resort. Anyone have any suggestions with this? It would be easier if I didn't have to guess at what the actual issue is, but I think I can at least talk in the right general direction: 1) CentOS 5 package perl-DBD-MySQL depends on at least one feature provided by package mysql, the distro's standard mysql client. Therefore, 2) your options depend on (a) whether you want to keep perl-DBD-MySQL and (b) whether the percona client provides all the features perl-DBD- MySQL normally gets from package mysql. Case 1: You don't need perl-DBD-MySQL or anything that depends on it In this case, you can cause puppet to remove the package, preferrably by declaring that resource with ensure = absent. You must then also set up Puppet relationships so that Package['perl-DBD-MySQL'] is applied *before* Package['mysql']. Case 2: You need to keep perl-DBD-MySQL, and Case 2a: the percona client provides all the resources perl-DBD-MySQL needs. In this case, set up relationships so that the percona package is installed before Package['mysql'] is removed. Alternatively, consider whether you need to remove Package['mysql'] at all -- perhaps you can have both clients installed side by side. If you need to remove the standard client and install the percona one in the same yum transaction, however, then you are probably stuck with using the yum shell via an Exec. Case 2b: the percona client does not provide all the resources perl- DBD-MySQL needs. In this case, your only possible option is to leave Package['mysql'] installed and install the percona client alongside it. If that doesn't work then you're hosed (and Puppet has nothing to do with it). John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Issue with RPM dependency issue
I've run into this before. The trick is to ensure that the Percona client is available and installed first and let *it* pull in perl-DBD-MySQL. If you install perl-DBD-MySQL first, it will often attempt to directly grab the RPM that best meets its requirements, which is the standard MySQL package. -Eric -- Eric Shamow Professional Services http://puppetlabs.com/ (c)631.871.6441 On Wednesday, November 23, 2011 at 9:25 AM, jcbollinger wrote: On Nov 22, 8:43 am, TisMe russlav...@gmail.com (http://gmail.com) wrote: I am running into an issue with perl-DBD-MySQL dependency with mysql in CentOS 5.7. I am trying to remove the mysql client and replace it with with percona version of the mysql client. It will not let me remove the mysql client because of that dependency. I have already defined perl-DBD-MySQL in a different class... I would rather not create an Exec[]. I would rather do that as a last resort. Anyone have any suggestions with this? It would be easier if I didn't have to guess at what the actual issue is, but I think I can at least talk in the right general direction: 1) CentOS 5 package perl-DBD-MySQL depends on at least one feature provided by package mysql, the distro's standard mysql client. Therefore, 2) your options depend on (a) whether you want to keep perl-DBD-MySQL and (b) whether the percona client provides all the features perl-DBD- MySQL normally gets from package mysql. Case 1: You don't need perl-DBD-MySQL or anything that depends on it In this case, you can cause puppet to remove the package, preferrably by declaring that resource with ensure = absent. You must then also set up Puppet relationships so that Package['perl-DBD-MySQL'] is applied *before* Package['mysql']. Case 2: You need to keep perl-DBD-MySQL, and Case 2a: the percona client provides all the resources perl-DBD-MySQL needs. In this case, set up relationships so that the percona package is installed before Package['mysql'] is removed. Alternatively, consider whether you need to remove Package['mysql'] at all -- perhaps you can have both clients installed side by side. If you need to remove the standard client and install the percona one in the same yum transaction, however, then you are probably stuck with using the yum shell via an Exec. Case 2b: the percona client does not provide all the resources perl- DBD-MySQL needs. In this case, your only possible option is to leave Package['mysql'] installed and install the percona client alongside it. If that doesn't work then you're hosed (and Puppet has nothing to do with it). John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] catalog compilation caching
Hello, just trying to understand the workload behind the compilation of catalogs puppet master is doing each time the client does a request to the master. I understand the clients send the facts to the master and the master based on the facts and the manifests compiles the catalog. I would expect that this can be optimized with some caching so if neither the manifest and the set of facts doesn't change the compilation of that catalog results to cache hit and that request is served significantly faster leaving lower load footprint then the first request or request after some changes in manifests or in facts. In reality I don't see any difference that would suggest some caching in the master, eg. eachtime the client contact the master the compilation takes about 6 seconds which seams be unbelievably long. can anyone please explain the way the master caches the catalogs or what are the reasons it doesn't? thanks, Antony. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] catalog compilation caching
On 23/11/11 19:27, Antony Mayi wrote: Hello, just trying to understand the workload behind the compilation of catalogs puppet master is doing each time the client does a request to the master. I understand the clients send the facts to the master and the master based on the facts and the manifests compiles the catalog. I would expect that this can be optimized with some caching so if neither the manifest and the set of facts doesn't change the compilation of that catalog results to cache hit and that request is served significantly faster leaving lower load footprint then the first request or request after some changes in manifests or in facts. In reality I don't see any difference that would suggest some caching in the master, eg. eachtime the client contact the master the compilation takes about 6 seconds which seams be unbelievably long. can anyone please explain the way the master caches the catalogs or what are the reasons it doesn't? The master doesn't cache any compiled catalogs. One of the reason is that the facts change for each run (yes, uptime I'm looking to you), and the master doesn't know which facts matters or not (regarding to change in the compiled catalog, which I believe is an hard problem). Check the Optimize Catalog Compilation section of this blog post for a workaround: http://www.masterzen.fr/2010/03/21/more-puppet-offloading/ -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: declare and include classes
Thanks Nan. Cheers, Arnau -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet 2.7.7: Thunderdome
Per our timed-release cycle process[1], we've entered the THUNDERDOME for 2.7.7rc series (Nov) vs 2.7.8 series (Dec). Two releases enter; one leaves. It was determined today that 2.7.8 has won the Thunderdome. (It was a gory battle where 2.7.8 kicked 2.7.7 in the face, 2.7.7 fought back with a weird behavior change, which is ultimately what cost it the battle) So, look for 2.7.8rc1 next week. The main reasons for holding back 2.7.7 were concerns around 'showdiff' option. 1. There is a feature that is a change in behavior if 'showdiff' is enabled. When enabled diffs will now be logged on disk (logs, reports, etc) 2. Showdiff is enabled by default when running 'puppet agent --test' 3. -noop will not modify the showdiff setting at all. (this needs to yet be fixed) Note: 2.7.7 was tagged in our github repository, but not really released. If you happened to have deployed it, we will absolutely still do our best to help you out, but 2.7.8 will have the behavior around showdiffs setup as desired. [1] http://groups.google.com/group/puppet-users/browse_thread/thread/3d703849246bd43f/c98d096d51ed221e Mike Stahnke Release Engineering Puppet Labs -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] is_virtual fact
Hi,
I've got a question regarding a fact. I'm trying to use the
'is_virtual' fact in a class manifest:
class io_scheduler {
if $is_virtual {
file { /etc/default/grub:
owner = root,
group = root,
mode= 0644,
source = puppet:///modules/io_scheduler/etc/default/grub,
}
}
}
However, on one of my physical systems:
$ facter | grep is_virtual
is_virtual = false
The file mentioned above gets installed:
Nov 23 14:22:50 hostname puppet-agent[1838]:
(/Stage[main]/Io_scheduler::Config/File[/etc/default/grub]/content)
content changed '{md5}01de0bd1b00e2ca04ebb873ace6f20fe' to
'{md5}a882618adcb31667cbab22731f8f16e2'
Any ideas what is wrong here?
Thanks for the help!
-matt zagrabelny
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] is_virtual fact
On 2011-11-23 12:49 , Matt Zagrabelny wrote:
Hi,
I've got a question regarding a fact. I'm trying to use the
'is_virtual' fact in a class manifest:
class io_scheduler {
if $is_virtual {
file { /etc/default/grub:
owner = root,
group = root,
mode= 0644,
source = puppet:///modules/io_scheduler/etc/default/grub,
}
}
}
However, on one of my physical systems:
$ facter | grep is_virtual
is_virtual = false
The file mentioned above gets installed:
Nov 23 14:22:50 hostname puppet-agent[1838]:
(/Stage[main]/Io_scheduler::Config/File[/etc/default/grub]/content)
content changed '{md5}01de0bd1b00e2ca04ebb873ace6f20fe' to
'{md5}a882618adcb31667cbab22731f8f16e2'
Any ideas what is wrong here?
Thanks for the help!
-matt zagrabelny
Facter facts are all strings, not true booleans. You'll need to check
for whether or not $is_virtual == 'true'.
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Puppet Windows: scheduled_task : TypeError
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
Another question I have is how do I schedule for every 30 minutes? or
every one hour?
Thanks a lot,
Mohamed.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] is_virtual fact
Facter facts are all strings, not true booleans. You'll need to check for whether or not $is_virtual == 'true'. Thanks for the prompt reply, Jacob! Things look good now. -mz -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Windows: scheduled_task : TypeError
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
Another question I have is how do I schedule for every 30 minutes? or
every one hour?
Thanks a lot,
Mohamed.
Since the scheduled_task type uses the v1 Windows API, being able to set
repetitions at resolutions more fine grained than the daily level isn't
possible, without creating multiple triggers to create the within a day
repetition manually.
If you know of a good Ruby interface to the newer Task Scheduler APIs,
which support this, then it would be possible for someone to write
another provider that supported this.
--
Jacob Helwig
http://about.me/jhelwig
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Puppet Windows: scheduled_task : TypeError
Thanks JacobDid that answer my TypeError as well?
Mohamed.
On Wed, Nov 23, 2011 at 5:28 PM, Jacob Helwig ja...@puppetlabs.com wrote:
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure = present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
Another question I have is how do I schedule for every 30 minutes? or
every one hour?
Thanks a lot,
Mohamed.
Since the scheduled_task type uses the v1 Windows API, being able to set
repetitions at resolutions more fine grained than the daily level isn't
possible, without creating multiple triggers to create the within a day
repetition manually.
If you know of a good Ruby interface to the newer Task Scheduler APIs,
which support this, then it would be possible for someone to write
another provider that supported this.
--
Jacob Helwig
http://about.me/jhelwig
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Windows: scheduled_task : TypeError
On 2011-11-23 15:53 , Mohamed Lrhazi wrote:
Thanks JacobDid that answer my TypeError as well?
No, a stack trace would help for that.
--
Jacob Helwig
http://about.me/jhelwig
Mohamed.
On Wed, Nov 23, 2011 at 5:28 PM, Jacob Helwig ja...@puppetlabs.com wrote:
On 2011-11-23 13:02 , Mohamed Lrhazi wrote:
am trying this:
scheduled_task { 'Puppet Run':
ensure= present,
enabled = true,
command = 'C:\\ruby187\\bin\\puppet.bat',
arguments = 'agent --verbose --logdest C:\\Temp\puppet.log',
trigger = {
schedule = daily,
#every = 2 # Defaults to 1
#start_date = '2011-08-31', # Defaults to 'today'
start_time = '16:00', # Must be specified
}
}
And getting this error:
err: /Stage[main]/Gu_splunk/Scheduled_task[Puppet Run]/ensure: change
from absent to present failed: Could not set 'present on ensure:
TypeError at /etc/puppet/
environments/windows/modules/gu_splunk/manifests/init.pp:84
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Re: Multiple nodes.pp files
Aside: do you perhaps mean
source = file(/home/$::realuser/puppet/files/smb.conf),
instead of
content = file(/home/$::realuser/puppet/files/smb.conf),
?
Do you have any lines like:
notice(the value of realuser is ${realuser} and ::realuser is
${::realuser} )
in your manifest to confirm what the variables might actually contain?
On 23 November 2011 05:53, Alexander Fortin alexander.for...@gmail.comwrote:
On 11/22/11 7:37 PM, Aaron Grewell wrote:
Curly braces perhaps?
content = file(/home/${realuser}/**puppet/files/smb.conf),
Tried both with ${realuser} and with ${::realuser}, no luck.
--
Alexander Fortin
http://about.me/**alexanderfortin/ http://about.me/alexanderfortin/
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@**
googlegroups.com puppet-users%2bunsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/**
group/puppet-users?hl=enhttp://groups.google.com/group/puppet-users?hl=en
.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
