Re: [Puppet Users] puppet, mongel, nginx and new nodes

[Scott Smith]

Matthew Delves wrote:
>> Passenger does not require Apache.
> 
> Do you have a link to an article that explains how that is?
> 

http://www.modrails.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

[Matthew Delves]

> Passenger does not require Apache.

Do you have a link to an article that explains how that is?

The documentation on the puppet/reductivelabs website 
http://reductivelabs.com/trac/puppet/wiki/UsingPassenger shows a use of apache.

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] using 'define': modelling a file-like construction.

[Trevor Vaughan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not sure if this will work as I haven't tested it, but try setting
source and content to 'undef' (no quotes) instead of false.

Trevor

On 12/22/2009 08:00 AM, Daniel Pittman 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. :)
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksxdz8ACgkQyjMdFR1108DeswCeMoBu3E3/LeXuGzXqn9rUzVAF
u9AAoKwvA7MxlfhNAl9PD6pnFrQSB176
=q/Dw
-END PGP SIGNATURE-

--

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

[Scott Smith]

Matthew Delves wrote:
>> 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.
> 

Passenger does not require Apache.

-scott

--

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

[Len Rugen]

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  wrote:

> On Tue, Oct 20, 2009 at 8:45 PM, Ohad Levy  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.
>
>
>

--

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.1 Release, codenamed "Whoops!"

[Rein Henrichs]

Greeting Puppeteers,

It turns out that Rails REALLY DOES NOT LIKE resource uris that include a
'.', requiring an immediate patch to get nodes with dots in their fqdn
(which, basically, is all of them) to work properly. My bad. Bugfix release
0.2.1 is available from the download link (because I remembered to push the
tags).

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.

[Puppet Users] Re: monitoring puppet

[Adam Gibbins]

via nagios:
/usr/lib/nagios/plugins/check_file_age -f /var/lib/puppet/state/
state.yaml -w 5400 -c 7200

On Dec 17, 4:34 am, "Sukh Khehra"  wrote:
> Hi,
>
> I was wondering what people out there are doing to monitor puppetd in
> large environments. I'd love to hear what the best practices are around
> this.
>
> We have a few hundred hosts and are currently looking at the timestamps
> on the yaml files in /var/lib/puppet/yaml/facts/ on puppetmasters to
> make sure all clients are alive. Is it true that for a given client the
> fact file on the puppetmaster will always get updated on every one of
> its puppet runs? Or does it update only when facts change.
>
> Thanks,
>
> Sukh

--

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

[Matthew Delves]

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] puppet, mongel, nginx and new nodes

[Matthew Delves]

> 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] Announcing Puppet dashboard 0.2.0 Release

[Rein Henrichs]

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] per environment tagmail settings?

[Joe McDonagh]

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.

Re: [Puppet Users] Re: Facter 1.5.7 and operatingsystemrelease

[Kenton Brede]

On Tue, Oct 20, 2009 at 8:45 PM, Ohad Levy  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.

[Puppet Users] Re: Downgrade package via yum

[jcbollinger]

On Dec 22, 12:36 am, "Tony G."  wrote:
> 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

Do you have both i386 and x86_64 versions of the package installed?
Perhaps different versions of the two?  Puppet does not account very
well for packages that differ only in architecture.

In any case, if yum's response there is indeed erroneous then you
should work out your yum problems before continuing to wrangle Puppet.

> 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.

And if it is indeed a yum failure, then we can't be much help here.
Indeed, having followed the thread up to now, I don't think I need to
qualify that: there's not much we can do for you.  These are some of
the factors in play:

1) By default, yum does not support package downgrading.  You need to
install a plugin AND provide appropriate command line options to
persuade it to downgrade packages.

2) Regardless of your yum plugins, Puppet is not issuing the options
that would be needed to enable downgrading.

3) Downgrading isn't especially safe in general.

> 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.

Yes, I think you read too much into that.  I also think that Puppet
could provide better support than it currently does.  For instance, it
could perhaps add an "allow_downgrade" parameter to the package type
that, for the yum provider, would cause "--allow-downgrade" to be
added to the yum command line.  I'm not sure what that would have to
do for other versionable package providers, though.

>
> Wish I'll be wrong, but seems like I won't be able to downgrade packages via
> yum.

Supposing that you mean "via Puppet", I suspect you're right for now.
Perhaps you would consider filing a feature request ticket?

Best,

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-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

[Silviu Paragina]

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://: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] using 'define': modelling a file-like construction.

[R.I.Pienaar]

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"  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.

[Puppet Users] using 'define': modelling a file-like construction.

[Daniel Pittman]

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] Downgrade package via yum

[Matthew Hyclak]

On Tue, Dec 22, 2009 at 6:50 AM, R.I.Pienaar  wrote:
> hello,
>
> - "Matthew Hyclak"  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.
>

+1

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

[R.I.Pienaar]

hello,

- "Matthew Hyclak"  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.

Re: [Puppet Users] Downgrade package via yum

[Matthew Hyclak]

On Tue, Dec 22, 2009 at 1:36 AM, Tony G.  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] Foreman summary mail

[LOhit]

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  wrote:

> Yes, of course. Let's see how I fare. :)
>
> Thanks
> LOhit
>
>
> On Thu, Dec 17, 2009 at 6:15 PM, Ohad Levy  wrote:
>
>> http://theforeman.org/issues/show/135
>>
>> hopefully its a starting point
>>
>> cheers,
>> Ohad
>>
>>
>> On Thu, Dec 17, 2009 at 8:03 PM, LOhit  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  wrote:
>>>


 On Thu, Dec 17, 2009 at 7:12 PM, LOhit  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.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.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.
>>
>
>
>
> --
> 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