Re: [Puppet Users] Foreman summary mail
Hello Ohad, I have added some CSS to summary.erb file. And added *content text/html to host_mailer.rb. This seems to be working fine. And Outlook seems to be happy. I tried pasting the resulting HTML in W3C website and it passed without any errors.* **I am attaching the file summary.erb file along with this email. I had to rename summary.text.html.erb to summary.erb for the CSS to work. Which is the expected behaviour. Please see if this can be patched into the main repo. PS: I am no developer, please feel free to point out any mistakes. I am willing to learn. Best regards, -LOhit On Thu, Dec 17, 2009 at 8:37 PM, LOhit lohi...@gmail.com wrote: Yes, of course. Let's see how I fare. :) Thanks LOhit On Thu, Dec 17, 2009 at 6:15 PM, Ohad Levy ohadl...@gmail.com wrote: http://theforeman.org/issues/show/135 hopefully its a starting point cheers, Ohad On Thu, Dec 17, 2009 at 8:03 PM, LOhit lohi...@gmail.com wrote: Hi Ohad, Thanks for the quick reply. Yes I agree with you on, most mail clients block content from external web sites, but it will still be nice to have this. As for the patches, I am not much of a developer. But, I do write perl/python scripts now and then to automate few of my day to day tasks. However, I would definitely try and see if I can contribute in any way to add this feature. Hmm, need to learn ruby first :) Best regards, -LOhit On Thu, Dec 17, 2009 at 5:19 PM, Ohad Levy ohadl...@gmail.com wrote: On Thu, Dec 17, 2009 at 7:12 PM, LOhit lohi...@gmail.com wrote: Hello, I have enabled summary emails from foreman and set up a cron job which sends me periodic summary emails. However, the mail's content is sort of plain text. Now this is more like a feature request rather than a problem, I am wondering if we could use some kind of HTML template and pass the values through this HTML template and then mail the output as a summary email to the administrator. Its already in HTML, and its already using an ERB template*1 - it probably needs to be improved :) In the HTML template we could perhaps play around highlighting failed nodes in RED and probably some graphs. etc..etc... yeah, but most mail clients are blocking content from external web sites, so it might work (or not). I remember doing this couple of years ago using perl and I used to get nice tabulated summary email of the output of my custom script(basically a log parser). patches are welcomed! :) [1] http://theforeman.org/repositories/entry/foreman/app/views/host_mailer/summary.text.html.erb? :) for future reference, you may want to open a feature request at http://theforeman.org cheers, Ohad -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- LOhit -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- LOhit -- LOhit -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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. summary.erb Description: Binary data
Re: [Puppet Users] Downgrade package via yum
On Tue, Dec 22, 2009 at 1:36 AM, Tony G. tony...@gmail.com wrote:
Thanks for the comments Silviu, here what I found:
I ran:
/usr/sbin/puppetd -vdt --fqdn `hostname` --environment=development --test
This is the excerpt of the output:
debug:
//Node[puppetclient.example.com]/common/common::nagios/Package[nrpe_custom]:
Changing ensure
debug:
//Node[puppetclient.example.com]/common/common::nagios/Package[nrpe_custom]:
1 change(s)
debug: Package[nrpe_custom](provider=yum): Ensuring = 01.1-10
debug: Puppet::Type::Package::ProviderYum: Executing '/usr/bin/yum -d 0 -e 0
-y install nrpe_custom-01.1-10'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q
nrpe_custom --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}|
%{VERSION} %{RELEASE} %{ARCH}'
err:
//Node[puppetclient.example.com]/common/common::nagios/Package[nrpe_custom]/ensure:
change from 01.2-20 to 01.1-10 failed: Could not update: Failed to update to
version 01.1-10, got version 01.2-20 instead at
/opt/puppet/development/classes/common.pp:61
Running it manually I got:
1. /usr/bin/yum -d 0 -e 0 -y install nrpe_custom-01.1-10
Package matching nrpe_custom-01.1-10.x86_64 already installed. Checking for
update.
Which is not true, but for some reason yum believes it is already
installed
2. /bin/rpm -q nrpe_custom --nosignature --nodigest --qf %{NAME}
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
nrpe_custom 0 01.2 20 x86_64
Then Puppet after matching the versions complains with the Error saying the
update didn't happen.
From my point of view this is an issue with yum that is not installing the
version defined in puppet.
As I previously said, if I do a /usr/bin/yum -d 0 -e 0 -y downgrade
nrpe_custom-01.1-10 it successfully installs the defined version.
My concern is that Puppet states that the handling of packages via yum is
versionable(The provider is capable of interrogating the package database
for installed version(s), and can select which out of a set of available
versions of a package to install if asked), which I assumed puppet will find
the way to exec yum to update *or downgrade* as in this case, but I guess I
took that too literal, and perhaps that is the definition of what a
versionable package handler as YUM does, but not exactly with Puppet.
Wish I'll be wrong, but seems like I won't be able to downgrade packages via
yum.
Comments?
Downgrade via yum is done by a plugin that comes with some caveats
(like how do you downgrade a post script that creates a user in
version 2, but not in version 1). This plugin is also not supported on
some earlier versions of yum.
It might be possible to modify the yum provider in puppet to check for
the existence of the plugin, and if the requested version is less than
the installed version, call yum with the downgrade option. My
recommendation would be to open a feature request in the bug tracker
and let someone more versed in ruby and the provider than I am
comment.
Matt
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] Downgrade package via yum
hello, - Matthew Hyclak hyc...@gmail.com wrote: Wish I'll be wrong, but seems like I won't be able to downgrade packages via yum. Downgrade via yum is done by a plugin that comes with some caveats (like how do you downgrade a post script that creates a user in version 2, but not in version 1). This plugin is also not supported on some earlier versions of yum. It might be possible to modify the yum provider in puppet to check for the existence of the plugin, and if the requested version is less than the installed version, call yum with the downgrade option. My recommendation would be to open a feature request in the bug tracker and let someone more versed in ruby and the provider than I am comment. automated, unattended and untested downgrading of packages is a recipe for disaster, I think puppet is right in by default not doing downgrades since while it might work for your package in this case, it certainly wont work for many, I've seen downgrades leaving machines very broken indeed due to post scripts not being written to support it as Matthew correctly points out. If we are to add support for downgrades I'd say it should come with an additional force = true style property on the package resource as it really is very dangerous. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] using 'define': modelling a file-like construction.
G'day.
I sometimes want to write a 'define' that wraps some higher level behaviour
around a low level 'file' statement, akin to this:
define example ($source = false, $content = false) {
file { /path/to/whatever/${name}:
ensure = file, source = $source, content = $content,
notify = Service[some-service],
etc, etc, etc
}
}
This is great, except it doesn't work. It returns an error that source is
nil, if I specify content, and that is that.
Instead, I get to write out the same file stanza twice, once with content and
once with source, as well as a third stanza that fails when neither is set.
Wouldn't it be wonderful if there was a standard way to express this idiom?
Daniel
...now someone is gonna tell me that I missed something obvious, but that is
fine with me: saving the time I waste on these is worth enough for me. :)
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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] using 'define': modelling a file-like construction.
hello,
You can use the ability to set defaults for resources:
define mfile($content = undef, $source = undef) {
if $content {
File[$name] {
content = $content
}
} else {
File[$name] {
source = $source
}
}
file{$name: }
}
- Daniel Pittman dan...@rimspace.net wrote:
G'day.
I sometimes want to write a 'define' that wraps some higher level
behaviour
around a low level 'file' statement, akin to this:
define example ($source = false, $content = false) {
file { /path/to/whatever/${name}:
ensure = file, source = $source, content = $content,
notify = Service[some-service],
etc, etc, etc
}
}
This is great, except it doesn't work. It returns an error that
source is
nil, if I specify content, and that is that.
Instead, I get to write out the same file stanza twice, once with
content and
once with source, as well as a third stanza that fails when neither is
set.
Wouldn't it be wonderful if there was a standard way to express this
idiom?
Daniel
...now someone is gonna tell me that I missed something obvious, but
that is
fine with me: saving the time I waste on these is worth enough for me.
:)
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401
155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To post to this group, send email to puppet-us...@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.
--
R.I.Pienaar
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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, mongel, nginx and new nodes
On 22.12.2009 06:34, Matthew Delves wrote: Sounds like mongrel or nginx might be generating an error message. Try pointing a web browser at https://your puppetmaster:8140 and see if you get anything helpful. The error I get is: Peer's certificate has an invalid signature. It would seem rather odd that the certificate has suddenly become invalid. Thanks, Matt Delves Why aren't you using passenger? afaik it works with nginx too? Just my 2 cents Silviu -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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: Facter 1.5.7 and operatingsystemrelease
On Tue, Oct 20, 2009 at 8:45 PM, Ohad Levy ohadl...@gmail.com wrote: Hi, I for one, thinks that the operatingsystemrelease fact should contain only the major number of the operating system, e.g. for Centos/Rehat 5.4 it should return just 5. the reason behind it is that I rarely use the full release version as a variable, and if I do, I use the lsb facts. this change is very annoying, as it requires to change your manifest again (we had the same issue between facter 1.38 and 1.5.0). I ended up having my own fact which is just a wrapper for the operatingsystem relase, as it one point of time I might have multiple facter version running around I searched through old messages and didn't see that this had been addressed. I can see people wanting facter to report the minor version and others wanting just the major release number. The way it stands I'll need to change every operatingystemrelease variable, each time a new minor version come out. That's a pain I don't need. So I'll work around this by creating my own fact. Having two variables for the OS release seems to me a good choice. Just my 2 cents. Kent -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] per environment tagmail settings?
JL wrote: Is it possible to disable tagmail reports for one environment but not another? For example, when I run 'puppetd --test -- environment=testing', I do not want to receive an email. I tried adding !testing to to tagmail.conf, but that didn't work. Alternatively, I would like to add a statement to the top of the reports that would state the environment, but I'm not sure how to do that. It looks like most of the puppet functions for logging (err, alert, critical, etc.) log to the server not the client. Thanks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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. I have a feature request in for this, feel free to thumbs-up it. -- Joe McDonagh Silent Penguin Services Operations Engineer AIM: YoosingYoonickz IRC: joe-mac on freenode Blog: www.colonfail.com -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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] Announcing Puppet dashboard 0.2.0 Release
Greetings Puppeteers, I'm pleased to announce the immediate release of Puppet Dashboard 0.2.0, codenamed Satria. You know why. Major new features in this release are a rake task for importing report YAML files into the Dashboard and a sample External Node script. See the README for more information. We probably won't be releasing next week (Christmas and all) but releases should resume shortly thereafter. Happy holidays. Code and installation instructions: http://github.com/reductivelabs/puppet-dashboard Download: http://github.com/reductivelabs/puppet-dashboard/downloads Tickets: http://projects.reductivelabs.com/projects/dashboard -- Rein Henrichs http://reductivelabs.com -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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, mongel, nginx and new nodes
Why aren't you using passenger? afaik it works with nginx too? Just my 2 cents My preference is for nginx over apache. I already have nginx hosting foreman on the same box so configuration is straight forward rather than having apache installed as well. Still no solution received on the problem. Is anyone aware of why the certificates are being rejected by the new nodes? All other nodes are behaving as expected. Thanks, Matt Delves -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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 and sles 11 node
Hey All, I seem to be getting errors when running puppet under sles 11. The first weird issue I'm seeing is that the node information isn't being sent through to puppet correctly as It doesn't pick up the $operatingsystem variable correctly and instead relies on the default setting. The puppet version I'm using is 0.25.1 The ruby version I'm using is 1.8.7 The puppet server is running 0.25.1 I've tested this with 2 different sles 11 nodes against 2 different puppet servers. Both of them fail. As for the puppet server setup I currently have 4 mongrel sessions sitting behind an nginx proxy. By using curl to connect to the server I can get the yaml for the node, though when using puppetd I get the error: No specified acceptable formats (*/*) are functional on this machine Thanks, Matt Delves -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@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: Facter 1.5.7 and operatingsystemrelease
I posted a question about the lsb prefixed facts a few weeks ago. lsbmaj may be what you're looking for. On Tue, Dec 22, 2009 at 9:17 AM, Kenton Brede kbr...@gmail.com wrote: On Tue, Oct 20, 2009 at 8:45 PM, Ohad Levy ohadl...@gmail.com wrote: Hi, I for one, thinks that the operatingsystemrelease fact should contain only the major number of the operating system, e.g. for Centos/Rehat 5.4 it should return just 5. the reason behind it is that I rarely use the full release version as a variable, and if I do, I use the lsb facts. this change is very annoying, as it requires to change your manifest again (we had the same issue between facter 1.38 and 1.5.0). I ended up having my own fact which is just a wrapper for the operatingsystem relase, as it one point of time I might have multiple facter version running around I searched through old messages and didn't see that this had been addressed. I can see people wanting facter to report the minor version and others wanting just the major release number. The way it stands I'll need to change every operatingystemrelease variable, each time a new minor version come out. That's a pain I don't need. So I'll work around this by creating my own fact. Having two variables for the OS release seems to me a good choice. Just my 2 cents. Kent -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.compuppet-users%2bunsubscr...@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-us...@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.
