[Puppet Users] Packages on fedora19

[Tony G.]

Howdy!

Probably this is being worked but just throwing it out there as f19 is
already out, I guess the package for it will be soon available on
http://yum.puppetlabs.com/fedora/ ?

Thanks!

-- 
Tony
http://tonyskapunk.net

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet apache config for vhost

[Tony G.]

On Tue, Feb 28, 2012 at 5:06 AM, Danijel Krmar  wrote:

> Hi there puppeters :),
>
> I hope you can help me with a situation. Namely, I will use puppet to
> deploy many (I mean really many) nodes with Apache installed. The
> problem I have is that for now the only way to create a vhost with a
> specified ServerName is to issue the server name in the main
> puppetmaster file (site.pp). It looks something like this:
>
>case $::hostname {
>hostname1: {vhost_default { 'hostname1.domain': }}
>hostname2: {vhost_default { 'hostname2.domain': }}
>
> Is there a way of creating a vhost file without having to issue the
> name. Meaning, that the puppetmaster reads the hostname and writes it
> by itself into the template. The template looks as follows (only the
> important part):
>
> 
>ServerName <%= fqdn %>
>ServerAlias www.<%= fqdn %>
>
> And the init.pp for apache with the template portion:
> define vhost_default() {
>
>file { "/etc/apache2/sites-available/domain.conf":
>owner   => 'root',
>group   => 'root',
>mode=> 644,
>content => template( 'apache/default_vhost.erb' ),
>require => [ Package[ 'apache2' ] ]
>
> Thanks in advance.
>
> --
> 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.
>
>
You might want to use a parametrized class instead of the define, there is
a discussion in removing or not from future puppet releases[1]

so instead of the:
define vhost_default() {

you will have:
class vhost($name) {

And you will make reference to it as
class { "vhost": name => $fqdn }

You can put this into another more generic class and just include in your
node reference.
class vhost_default {
  class { "vhost": name => $fqdn }
}

node foo {
  include vhost_default
}

[1]
http://groups.google.com/group/puppet-users/browse_thread/thread/627731283dcc4a6b/f37ab68fa1797e6b

-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Chmoding files in directory with around 33000 files is slow

[Tony G.]

On Dec 2, 2011 4:03 PM, "Michael Stahnke"  wrote:
>
> On Fri, Dec 2, 2011 at 1:57 PM, Nigel Kersten 
wrote:
> >
> >
> > On Fri, Dec 2, 2011 at 7:41 AM, Idar Borlaug 
wrote:
> >>
> >> Hi
> >>
> >> Just wanted to know if anyhow has a great workaround for modifing user
> >> and group in a folder with 33000 files.
> >> It takes 5 minutes to chmod one file.
> >>
> >> file { "/some/dir" :
> >> ensure => directory,
> >> recurse => true,
> >> group => 'jboss',
> >> owner => 'jboss'
> >> }
> >>
> >> I am using puppet 2.6.4 on the server, might this be fixed in a later
> >> version?
> >
> >
> > So you're not concerned with the content at all?
> >
> > Puppet should be smarter about this, but does it help to add:
> >
> > checksum => none,
> >
> > to the resource?
> >
> >
> >>
> >>
> >> --
> >> Idar
> >>
> >> --
> >> 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.
> >>
> >
> >
> >
> > --
> > Nigel Kersten
> > Product Manager, 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.
>
> There is also a patch in the 2.7.8rc series that addresses some of
> these speed issues.
>
> http://projects.puppetlabs.com/issues/9671
>
> --
> 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.
>

Another option is to create a cronjob that takes care of the chown through
puppet, that way you reduce a lot the time, my 2¢.

--
Tony
http://www.tonyskapunk.net

-- 
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] undefined method `initvars'

[Tony G.]

Try enabling debug and trace on your agent, that will provide more details.

On Tue, Jul 26, 2011 at 11:17 AM, Sean Carolan  wrote:

> We are seeing this error in our log files on some clients:
>
> puppetd[15068]: Could not run Puppet configuration client: undefined
> method `initvars' for #
>
> Where do I begin troubleshooting this?  The client software versions are:
>
> ruby-1.8.5-5.el5_4.8.x86_64
> ruby-libs-1.8.5-5.el5_4.8.x86_64
> ruby-shadow-1.4.1-7.el5.x86_64
> facter-1.5.8-1.el5.noarch
> ruby-augeas-0.4.1-1.el5.x86_64
> puppet-0.25.5-1.el5.noarch
>
> And the server is running puppet 2.6.7.
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] syntax highlighting on emacs

[Tony G.]

On Tue, Jun 28, 2011 at 2:00 PM, Sylvain  wrote:

> Hi guys,
>
> I'm trying to install the syntax highlighting on emacs for Puppet.
> I'm using the configuration files provide on
> http://projects.reductivelabs.com/repositories/browse/puppet/ext/emacs
>
> When I open a .pp file I got this error:
> File mode specification error: (void-function puppet-mode)
>
Hi

The .el files must be in the library path or you can do something like this
in your ~.emacs file

;; Local Library Path
(add-to-list 'load-path "~/path/to/your/el/files")

then I autoload it with in my ~.emacs, that is almost the same as the
puppet-mode-init.el

;; Puppet mode
(autoload 'puppet-mode "puppet-mode" "Puppet Mode." t)
(add-to-list 'auto-mode-alist '("\\.pp\\'" . puppet-mode))
(add-to-list 'interpreter-mode-alist '("puppet" . puppet-mode))

Hope that helps.


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


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Classes not imported on a directory with the same module name.

[Tony G.]

On Tue, Apr 26, 2011 at 11:35 AM, Nan Liu  wrote:

> On Tue, Apr 26, 2011 at 6:52 AM, Tony G.  wrote:
> >
> >
> > On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
> >  wrote:
> >>
> >> Hi,
> >>
> >> On 04/22/2011 06:48 PM, Tony G. wrote:
> >> > Hi all,
> >> >
> >> > Found a situation on which all classes inside a directory are ignored,
> >> > this when the directory name is the same as a module name.
> >> >
> >> > err: Could not retrieve catalog from remote server: Error 400 on
> SERVER:
> >> > Could not find class bar at
> >> > /opt/puppet/test/nodes/gnucloud.tonyskapunk.net.pp:2 on node
> >> > gnucloud.tonyskapunk.net <http://gnucloud.tonyskapunk.net>
> >> >
> >> > Basically I have on site.pp an import of multiple classes inside a
> >> > directory with import "foo/*" and also a module called "foo"
> >>
> >> this is a strange requirement indeed. Can you shed any light on why you
> >> want such a structure? It sounds undesirable, even though it should
> >> still work.
> >
> > The idea behind this is to use modules as generic as possible to be
> > implemented by any other class, in this case directory 'foo' will contain
> > classes with specific modules, e.g. a server class which implements http,
> > mysql, and so.
> >>
> >> > Running debug on the master I see only the module is imported, this
> >> > looks like a ruby thing, but since I'm not good at ruby I better ask,
> >> > why is being ignored?
> >> >
> >> > debug: importing '/opt/puppet/test/modules/foo/manifests/init.pp' in
> >> > environment test
> >> >
> >> > Details:
> >> > Server/Client: 2.6.7
> >> > Node has: import bar
> >> > bar is a class inside "foo" directory that is imported in site.pp
> >>
> >> This should be "include bar" then.
> >>
> > Correct it was a typo, I'm using "include bar"
> >
> >>
> >> Import is a feature that should be considered deprecated.
> >> Try and organize everything into modules and exploit the autoloader,
> >> i.e. make another module "foo_module" with all the classes currently in
> >> disorganized .pp-files in your manifests/foo/ directory and only do
> >>
> >> include foo_module::bar
> >>
> >> without any import statements. There is less pain (and better
> >> performance I feel) down that road.
> >>
> > Agree, I should take advantage of autoloader, but how people handle those
> > classes where the implementation of multiple modules are required?
> > My concept of modules(including structure) is a source of generic
> reusable
> > classes by other specific classes that will be placed somewhere and thus
> > imported at some point.
>
> The classes are loaded from modules in modulepath in the order of
> their precedence.
>
> So modulepath=/path/a:/path/b
>
> If you have module foo in both /path/a/foo and /path/b/foo, include
> foo will load the module in /path/a and ignore /path/b.
>

Thanks Nan, this explains why the modules in my modulepath were loaded and
later when attempting to import in site.pp the other directory it was simply
ignored.


>
> > I'm curious about the performance part but mainly on how puppet and/or
> ruby
> > is loading those classes, as it seems to me like is ignoring my classes
> > inside the directory once a module with the same name is loaded.
>
> So if you want to take advantage of this behavior, put your class in a
> module, and put that module in a module path that have
> precedence/priority over the other modules with the same name.
>

Thanks,
>
> Nan
>

The other part I'm interested as well is the way to organize/structure
modules, I currently have modules very generic and configurable, to reuse
code as possible on other classes or in nodes, something like:

/path/to/environment/
  modules/
http/
  files/
  templates/
  manifests/
mysql
  files/
  templates/
  manifests/
ldap
  files/
  templates/
  manifests/

Then I have a directory for classes that represent type of servers making
use of the modules, for that I need to import the classes inside this
directory and I do that on site.pp(that's why I found this situation),
something like:

/path/to/environment/
  classes/
webserver.pp
dbserver.pp
ldapserver.pp
ldapclient.pp
etc...

If importing classes is not recomme

Re: [Puppet Users] Classes not imported on a directory with the same module name.

[Tony G.]

On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

> Hi,
>
> On 04/22/2011 06:48 PM, Tony G. wrote:
> > Hi all,
> >
> > Found a situation on which all classes inside a directory are ignored,
> > this when the directory name is the same as a module name.
> >
> > err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> > Could not find class bar at
> > /opt/puppet/test/nodes/gnucloud.tonyskapunk.net.pp:2 on node
> > gnucloud.tonyskapunk.net <http://gnucloud.tonyskapunk.net>
> >
> > Basically I have on site.pp an import of multiple classes inside a
> > directory with import "foo/*" and also a module called "foo"
>
> this is a strange requirement indeed. Can you shed any light on why you
> want such a structure? It sounds undesirable, even though it should
> still work.
>

The idea behind this is to use modules as generic as possible to be
implemented by any other class, in this case directory 'foo' will contain
classes with specific modules, e.g. a server class which implements http,
mysql, and so.

>
> > Running debug on the master I see only the module is imported, this
> > looks like a ruby thing, but since I'm not good at ruby I better ask,
> > why is being ignored?
> >
> > debug: importing '/opt/puppet/test/modules/foo/manifests/init.pp' in
> > environment test
> >
> > Details:
> > Server/Client: 2.6.7
> > Node has: import bar
> > bar is a class inside "foo" directory that is imported in site.pp
>
> This should be "include bar" then.
>
> Correct it was a typo, I'm using "include bar"


> Import is a feature that should be considered deprecated.
> Try and organize everything into modules and exploit the autoloader,
> i.e. make another module "foo_module" with all the classes currently in
> disorganized .pp-files in your manifests/foo/ directory and only do
>
> include foo_module::bar
>
> without any import statements. There is less pain (and better
> performance I feel) down that road.
>
> Agree, I should take advantage of autoloader, but how people handle those
classes where the implementation of multiple modules are required?

My concept of modules(including structure) is a source of generic reusable
classes by other specific classes that will be placed somewhere and thus
imported at some point.

I'm curious about the performance part but mainly on how puppet and/or ruby
is loading those classes, as it seems to me like is ignoring my classes
inside the directory once a module with the same name is loaded.

Thanks


Regards,
> Felix
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Classes not imported on a directory with the same module name.

[Tony G.]

Hi all,

Found a situation on which all classes inside a directory are ignored, this
when the directory name is the same as a module name.

err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find class bar at
/opt/puppet/test/nodes/gnucloud.tonyskapunk.net.pp:2 on node
gnucloud.tonyskapunk.net

Basically I have on site.pp an import of multiple classes inside a directory
with import "foo/*" and also a module called "foo"

Running debug on the master I see only the module is imported, this looks
like a ruby thing, but since I'm not good at ruby I better ask, why is being
ignored?

debug: importing '/opt/puppet/test/modules/foo/manifests/init.pp' in
environment test

Details:
Server/Client: 2.6.7
Node has: import bar
bar is a class inside "foo" directory that is imported in site.pp

Thanks.
-- 
Tony
http://blog.tonyskapunk.net

-- 
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: Mutliple custom facts not showing in facter

[Tony G.]

I tried with rc4, upgradec to rc5 and same behavior, which version you
tested out before, I recall testing on 1.5.7 too, with the same thing.

Thanks.

On Sun, Apr 10, 2011 at 8:42 PM, Cody Robertson  wrote:

> Er, I upgraded to Facter rc5*
>
>  --
> 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.
>



-- 
Tony
http://blog.tonyskapunk.net

-- 
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: Mutliple custom facts not showing in facter

[Tony G.]

Facter 1.5.9

Thanks

sent from my android

On Apr 10, 2011 4:09 PM, "Cody Robertson"  wrote:

Strange - in the example I used the file is named lvemanager_versions.rb
while the facts are lvemanager_version and lvecpanel_version.  Although it's
highly unlikely this is the problem I'm running facter 1.5.8 which is one
version you're not running..



-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group...

-- 
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: Mutliple custom facts not showing in facter

[Tony G.]

On Sun, Apr 10, 2011 at 1:56 PM, Cody Robertson  wrote:

> Can you invoke any custom facts at all? I suspect it facter might not be
> looking in the right directory for your puppet facts and thus it's not
> finding them when run it locally.
>
> I've confirmed no issue with defining multiple facts in a single file /
> calling them with facter locally:
>
> root@falcon [~]# facter --puppet lvecpanel_version
> lve-cpanel-plugin-0.2-1.el5.cloudlinux
>
> root@falcon [~]# facter --puppet lvemanager_version
> cpanel-lvemanager-0.3-2.el5.cloudlinux
>

This is interesting, what is the name of your fact?

I replied on a forked thread, puppet-users was not included, here my
response:

 [root@gnucloud facter]# echo $FACTERLIB

[root@gnucloud facter]# export
FACTERLIB=/opt/puppet/test/modules/foobar/lib/facter
[root@gnucloud facter]# echo $FACTERLIB
/opt/puppet/test/modules/foobar/lib/facter
[root@gnucloud facter]# facter -p foo
[root@gnucloud facter]# pwd
/opt/puppet/test/modules/foobar/lib/facter
[root@gnucloud facter]# ls
foobar.rb
[root@gnucloud facter]# cat foobar.rb
require 'facter'
Facter.add("foo") do
  setcode do
%x{/bin/date +%s}.chomp
  end
end
Facter.add("bar") do
  setcode do
%x{/bin/date +%s}.chomp
  end
end

My *guess* is that facter does not like having two facts in one fact, here I
simply created another fact:

[root@gnucloud facter]# cat onefact.rb
require 'facter'
Facter.add("onefact") do

  setcode do
%x{/bin/date +%s}.chomp
  end
end

[root@gnucloud facter]# facter -p onefact
1302309123

Working without issues..

Doing another test, this time I just renamed the file with the fact:

[root@gnucloud facter]# mv onefact.rb onefact2.rb
[root@gnucloud facter]# facter -p onefact
[root@gnucloud facter]# facter -p onefact2
[root@gnucloud facter]#

aha!, seems like facter is looking for the fact name that matches the file,
woot! is this ok? is this the expected behavior?

Then somehow my assumption was correct, facter is not able to pick facts
that the name of the file differs from the fact defined, anyway puppet
processes them correctly.

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



-- 
Tony
http://blog.tonyskapunk.net

-- 
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] $environment in File source not working

[Tony G.]

On Wed, Apr 6, 2011 at 9:18 PM, Nigel Kersten  wrote:

> On Wed, Apr 6, 2011 at 6:38 PM, Mohamed Lrhazi  wrote:
> > am I doing something wrong?
> >
> > this seems to never find my .$env file:
> >
> > source => [
> >"puppet:///modules/gu_puppet/puppet.conf.$fqdn",
> >"puppet:///modules/gu_puppet/puppet.conf.$environment",
> >"puppet:///modules/gu_puppet/puppet.conf.$operatingsystem",
> >"puppet:///modules/gu_puppet/puppet.conf"
> >]
> >
> > It does find the $fqdn version if I create one, but not the
> > $environment. and skips to the last version.
> > am using 2.6.3 master and 2.6.6 client.
>
> Not completely related, but I was under the impression that clients
shouldn't be higher than the masters, did that change on newer versions?

I'd add a notice and/or notify for $environment to check it's the
> value you're expecting it to be.
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Mutliple custom facts not showing in facter

[Tony G.]

Hi,

I've noticed that defining multiple facts in one file is possible, and
puppet can make use of them correctly, but when trying to call with facter
--puppet they are not shown, do I need something special to make them work
as any other single custom fact?

Master is running 2.6.7

This is a custom fact with two facts in it:
[modules/foobar/lib/facter/foobar.rb ]
require 'facter'
Facter.add("foo") do
  setcode do
%x{/bin/date +%s}.chomp
  end
end
Facter.add("bar") do
  setcode do
%x{/bin/date +%s}.chomp
  end
end

I used a simple notify in the node like this:  notify{ "custom_fact":
message => "foo:$foo bar:$bar"}

Tested with Puppet Agent 2.6.2 and 2.6.7

Pulling the fact and makes use of it:

# puppet agent -t --environment=test --pluginsync
info: Retrieving plugin
notice: /File[/var/lib/puppet/lib/facter/foobar.rb]/ensure: defined content
as '{md5}c28d8a783d44b9c15b7e61a6d90cf0e3'
notice: /File[/var/lib/puppet/lib/facter/utime.rb]/ensure: removed
info: Loading downloaded plugin /var/lib/puppet/lib/facter/foobar.rb
info: Loading facts in foobar
info: Loading facts in foobar
info: Caching catalog for squeeze.tonyskapunk.net
info: Applying configuration version '1302146930'
notice: foo:1302147318 bar:1302147318
notice: /Stage[main]//Node[squeeze.tonyskapunk.net]/Notify[custom_fact]/message:
defined 'message' as 'foo:1302147318 bar:1302147318'
notice: Finished catalog run in 0.07 seconds

But not able to call them with facter:

root@squeeze:~# facter --puppet foo
root@squeeze:~# facter --puppet bar
root@squeeze:~#

Tested with Facter 1.5.7 and 1.5.9

Thanks.

-- 
Tony
http://blog.tonyskapunk.net

-- 
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] facter --puppet does not report "environment"

[Tony G.]

It probably would be good idea to have a facter of the environment, guess
that could be a very quick way to know what environment the client/agent is
using.

On Fri, Jan 7, 2011 at 9:02 AM, Nigel Kersten  wrote:

> On Fri, Jan 7, 2011 at 6:07 AM, Mohamed Lrhazi  wrote:
> > Thanks  a lot Nigel... I do need to learn to create custom facts indeed.
>
> I should add that even without this custom fact, "$environment" is
> available to use as a variable in your Puppet manifests.
>
> It's just not a fact, it's exposed as a global variable.
>
> >
> >
> > On Thu, Jan 6, 2011 at 11:22 PM, Nigel Kersten 
> wrote:
> >> facter --puppet shows the facter facts, plus any that have been
> >> delivered by puppet and pluginsync.
> >>
> >> "environment" isn't a fact by default. You could make a fact that
> >> reported on the Puppet environment setting however.
> >>
> >> require 'puppet'
> >>
> >> Facter.add("environment) do
> >>  setcode do
> >>Puppet[:environment]
> >>  end
> >> end
> >>
> >> [1] - UNTESTED in anything other than a quick interactive session.
> >>
> >>>
> >
> > --
> > 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Plugin dependencies

[Tony G.]

Hi,

I'm attempting to move from 0.24.x to 2.6.x :) trying to fix all those parts
that have changed, and found that the use of plugins we are doing is
probably not the best approach hoping you can help me with comments
regarding this use case.

In our working 0.24.x environment we had to make use of plugins to add an
attribute in the package.rb, something like:
*newparam(:ignoredeps)*

Then on the rpm.rb a flag to add "--nodeps" was added.
* flags = []*
* if @resource[:ignoredeps]*
* flags << "--nodeps"*
* end*
* flags << "-e"*
* rpm flags, nvr*

All this because we needed to remove some packages without its dependencies.
We distributed it with the pluginsync enabled in our puppet.conf, and works
as expected.

What I don't like at all is that we have to export all the providers that
make use of the package.rb type, all this just for a small change like this,
since my experience with ruby is close to nothing I would like to know if it
would be possible to integrate such change without the need of importing all
the providers, or any alternative solution to my use case.

This is a simplified version of a class we are using, on which we need to
remove packages without its dependencies:
class ssh {
  $ssh_pkgs_in = $use_lpk ? {
true  => ["openssh-lpk", "openssh-lpk-clients", "openssh-lpk-server"],
false => ["openssh", "openssh-clients", "openssh-server"],
  }
  $ssh_pkgs_out = $use_lpk ? {
true   => ["openssh", "openssh-clients", "openssh-server"],
false  => ["openssh-lpk", "openssh-lpk-clients", "openssh-lpk-server"],
  }
  package {
$ssh_pkgs_in:
  ensure  => "latest",
  notify  => Service["sshd"],
  require => Package[$ssh_pkgs_out];
$ssh_pkgs_out:
  ensure => "absent",
  *ignoredeps* => true;
  }
}

The node definition then looks something like:
node "puppet.example.com" {
  $use_lpk = true
  include ssh
}

Thanks.

-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Realizing wrong ssh key for the wrong user

[Tony G.]

Tobias,

On Tue, Nov 9, 2010 at 1:11 PM, Tobias Lott  wrote:

> Hey Everyone
>
> I've defined my users in a class called 'user::virtual' and the included
> user::server1 class to realize the users for a nodegroup.
>
> Problem is puppet is trying to realize all keys for all the user.
> f.e. user peto gets key peto, tobi0 and tobi1 and user tobi gets peto,
> tobi0 and tobi1
>
> Manifests
> http://dpaste.com/273017/
>
> Error message
> http://dpaste.com/273018/
>
>
Looks like you need to make sure the homedirectory and your users exist for
before  attempting to  create its ssh_authorized keys.

Some metaparameters you might find useful are before, requrie.
http://docs.puppetlabs.com/references/2.6.2/metaparameter.html


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


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Override puppet environment at the command line

[Tony G.]

Kenneth,

On Tue, Oct 5, 2010 at 8:20 AM, Kenneth Holter wrote:

> Hi all.
>
>
> My puppet client has "environment = envA" defined in
> /etc/puppet/puppet.conf, but I'd like to override this manuall at the
> command line: "puppetd --server puppet.master.com --environment=envB".
> This doens't seem to work, so it always run code from envA. Is there a way
> to override the environment variable like this?
>
> It should work with --environment=envB..

Which version are you running?  Could you share the puppet.conf in your
master to see how you set the environments?

Once I had this issue and the settings were ok until I realized that in the
client there were two conf files in /etc/puppet those were puppet.conf and
puppetd.conf the latter was used in older versions of puppet.
http://groups.google.com/group/puppet-users/browse_thread/thread/95cf5a8552ba086a/8ca3447f3d35f128?lnk=gst&q=tonysk8#8ca3447f3d35f128

>
> Best regards,
> Kenneth Holter
>
> --
> 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.
>



-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Variables with class inheritance and templates

[Tony G.]

Darren,

On Tue, Sep 28, 2010 at 11:01 AM, Darren Worrall wrote:

> With a manifest like so:
>
> class base {
>  $myvar = '1234'
>  file {
>'/tmp/foo':
>  content => template('test.erb')
>  }
> }
>
> class newbase inherits base {
>  $myvar = '5678'
> }
>
> node default {
>  include newbase
> }
>
> And test.erb with <%= myvar %>
>
> /tmp/foo contains 1234, when I would expect it to contain 5678.
>
> Is this a bug, or a limitation of class inheritance? (ie, base classes
> are evaluated completely, and subclasses are only allowed to modify
> things after the fact?)
>
> Cheers :)
>

Is the way scoping works, you can take more complete explanation here
http://projects.puppetlabs.com/projects/puppet/wiki/Frequently_Asked_Questions#Class+Inheritance+and+Variable+Scope

Basically the value of the inner scope is the one being used and not
overridden as one might expect.


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


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] YUMREPO { productname => PowerEdge 2650}

[Tony G.]

Henry,


On Tue, Sep 28, 2010 at 9:12 AM, CraftyTech  wrote:

> Hello All,
>
> How do I specify a variable that has a space in it?  I'm trying
> to setup a yum repo that has two different baseurl's based on the
> product name ($productname).  Default goes one way, but if the product
> is "PowerEdge 2650" then is a different URL.  The thing is, that is
> only picking up the default.  How should I specify the value with the
> space in the middle?  I tried "PowerEdge 2650", "${PowerEdge 2650}",
> and 'PowerEdge 2650', and none have worked so far.  Do I need to use
> Regex for this, or is there a discreprancy in my syntax?
>
>
The baseurl you use has a white space on it? e.g. "
http://yourserver/somelocation/RPMS.poweredge 2650" ?

If that's not the case then you can simply do an assignment of the repo name
to whatever you have based on the productname(assuming this is provided by
facter) variable.

$reponame = $productname ? {
  "PowerEdge 2650" => "poweredge2650",
  "PowerEdge 2950" => "poweredge2950",
   default => "poweredge",
}

Then use it in the baseurl attribute of yumrepo:
baseurl => "http://yourserver/somelocation.RPMS.$reponame";

Hope that helps.


> Thanks,
>
> Henry
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] best way to include a variable in many modules ?

[Tony G.]

http://projects.puppetlabs.com/projects/1/wiki/Resolv_Conf_Patterns

On Thu, Sep 23, 2010 at 11:36 AM, Daniel Maher  wrote:

> Hello,
>
> I have two sites with a small number of machines at each.  Each site is
> functionally identical.  I would like to set up a bunch of templates for the
> various services at each site, with a handful of variables that indicate
> which site the service is configured for.  What would be "best practice" way
> to accomplish this in Puppet ?
>
> Consider :
>
> s...@abc$ facter | grep domain
> domain => abc.dom.ain
> s...@abc$ cat /etc/resolv.conf
> search abc.dom.ain
> 10.1.0.1
>
> s...@xyz$ facter | grep domain
> domain => xyz.dom.ain
> s...@abc$ cat /etc/resolv.conf
> search xyz.dom.ain
> 10.2.0.1
>
>
> Thus i would like a template "resolv.conf.erb" :
>
> search <%= site_name =>.dom.ain
> 10.<%= site_ip =>.0.1
>
>
> I _could_ put something like this into _every_ class :
>
> $site_name = $domain ? {
>  'abc.dom.ain' => 'abc',
>  'xyz.dom.ain' => 'xyz',
> }
> # etc...
>
> That works, but frankly it's offensive in every way.  There are clearly
> other ways to go about it, so i am curious : for Puppet, what is the best
> practice solution ?
>
> Thank you all for your time and consideration.
>
>
> --
> Daniel Maher 
> "The Internet is completely over." -- Prince
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Need advice on managing large Centos environment

[Tony G.]

Hi Lezz,

Another approach is to maintain your own repos by freezing them over time,
e.g. monthly pull the latest packages for your repos and put them as your
frozen repo, provide these frozen repos through puppet and once you have
validated all the updates in the frozen repos you can relase those to all
your servers.

Roll back is harder to maintain so you better make sure the updates in the
frozen repo works before pushing into production.  You don't have to list
each package in puppet but only those that you use/need and you can set them
to be "latest" this way the control relies on your repository.

Thanks.

On Wed, Sep 22, 2010 at 7:26 AM, Rob McBroom wrote:

> On Sep 22, 2010, at 8:06 AM, Leslie Giles wrote:
>
> We have an engineering environment of around 200 Centos servers, plus a
> production environment of roughly the same size. Currently, when we roll out
> a new server, we do a 'yum update' so the new server has the latest
> packages; however this means that just about every server has a different
> set of package versions - a system rolled out today will have different
> versions from one rolled out last month, and that will have different
> versions from one rolled out last year.
>
> This has bitten me in the past, where a feature developed on a recent
> system failed to run on an older server, so I'm looking for a solution. I am
> in the middle of rolling out Puppet, and we have private mirrors of the yum
> repos, so a solution could build on these.
>
>
> My understanding is that RHEL (and CentOS by extension) won't add or remove
> any features within a major release. I have a similar situation with ~100
> RHEL5 systems all at different versions of various RPMs and I've never had a
> problem with anything I'm doing in Puppet.
>
> The only thing that's ever caused problems for me was when Puppet and/or
> Augeas were updated in EPEL and a new system got the newer version before
> the rest of the environment was really set up for it. If you've got all
> these packages in a local repo (which is what I *should* be doing), you
> won't have to worry about that.
>
> --
> Rob McBroom
> 
>
>  --
> 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.
>



-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Documentation contribution opportunity - Please help!

[Tony G.]

I recall someone started a translation to Chinese, I'll be happy to help
with Spanish, and I've seen some French speakers into the list that might be
interested.

Thanks.

On Fri, Aug 27, 2010 at 5:39 PM, James Turnbull wrote:

> Tony G. wrote:
> > Is there any way to contribute translating the current docs into
> > different languages?
> >
>
> We'd love to see this.  What languages did you have in mind?
>
> Regards
>
> James Turnbull
>
> --
> Puppet Labs - http://www.puppetlabs.com
> C: 503-734-8571
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Documentation contribution opportunity - Please help!

[Tony G.]

Is there any way to contribute translating the current docs into different
languages?

Thanks.

On Fri, Aug 27, 2010 at 3:16 PM, James Turnbull wrote:

> Rob McBroom wrote:
> >
> > Sounds like it's mostly taken care of. Is there any need for someone to
> go through http://github.com/reductivelabs/puppet-docs ?
> >
>
> Totally!  Any improvements or additions to that would be gratefully
> received.  We'd also welcome people updating the existing Markdown
> references - source/references/* to more viable Markdown (fixing the
> tables for example).
>
> Regards
>
> James Turnbull
>
> --
> Puppet Labs - http://www.puppetlabs.com
> C: 503-734-8571
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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 puppet ssl certs for other applications

[Tony G.]

Hi Bob,

Doing the same for LDAP+TLS, it gives me the advantage of not creating
another set of cert/key per machine, besides they are distributed with
puppet, at the beginning I was tempted to use only symlnks to them but later
I decided to make a copy of them and I've started to use like that without
issues so far.

Thanks.

On Fri, Aug 6, 2010 at 9:47 AM, Bob Belnap  wrote:

> Hello,
>
> As I've been building up my puppet infrastructure, I've started using
> puppet certs for all of my services that require ssl.  Usually this is
> in the form of links:
>
>
>file {
>"/opt/syslog-ng/etc/ca.d/b2457b50.0":
>require => Package["syslog-ng"],
>ensure => link,
>target => "/var/lib/puppet/ssl/certs/ca.pem";
>}
>
> Or copying file contents:
>
>
>file { ["/var/lib/pgsql/data/server.crt",
>"/home/postgres/.postgresql/postgresql.crt",
>"/root/.postgresql/postgresql.crt",
>]:
>source  => "/var/lib/puppet/ssl/certs/$fqdn.pem",
>owner   => postgres,
>group   => postgres,
>mode=> 600,
>}
>
>file { ["/var/lib/pgsql/data/server.key",
>"/home/postgres/.postgresql/postgresql.key",
>"/root/.postgresql/postgresql.key",
>]:
>source  => "/var/lib/puppet/ssl/private_keys/$fqdn.pem",
>owner   => postgres,
>group   => postgres,
>mode=> 600,
>}
>
>file { "/var/lib/pgsql/data/root.crt":
>source  => "/var/lib/puppet/ssl/certs/ca.pem",
>owner   => postgres,
>group   => postgres,
>mode=> 600,
>}
>
> Now pretty much any time I have a service that uses ssl, I just use
> puppet certs/keys.
>
> The advantages I see:
> * It saves me from having to maintain my own separate CA system.
> * I don't have to store sensitive certs/keys in manifests
>
> Is anyone else doing this?  Is it a good idea?  What are the potential
> pitfalls?
>
> --Bob
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] a basic(?) mount resource

[Tony G.]

On Thu, Aug 5, 2010 at 7:41 AM, Rob McBroom wrote:

> On Aug 4, 2010, at 3:11 PM, Tony G. wrote:
>
> >> If I add `ensure => present`, the entry gets added, but according to the
> documentation, "if the filesystem is currently mounted, it will be
> unmounted".
> >>
> >> I don't want Puppet to unmount (or mount) it. I just want it defined in
> `fstab` so it can be easily mounted as needed. Can that be done?
> >
> > I sounds like the use case you are looking for is not supported, as you
> want it only in fstab but not perform any action, e.g. if mounted it should
> keep mounted, or if unmounted leave it unmounted.
>
> Yes, that appears to be the case. I tested the “present” value just to see
> the actual behavior because I thought the documentation must be wrong, but
> it does in fact unmount the thing:
>
>notice: //Mount[/unixteam]/ensure: ensure changed 'mounted' to 'present'
>
> I don’t understand this behavior. Why on Earth would I want to define
> something in `fstab` that is guaranteed to get unmounted at some random time
> in the next 30 minutes?
>
> Open a Feature Request if you find your use case required. :)



> --
> Rob McBroom
> <http://www.skurfer.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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] a basic(?) mount resource

[Tony G.]

On Wed, Aug 4, 2010 at 12:32 PM, Rob McBroom wrote:

> I'm trying to use the native `mount` type for the first time and I seem to
> have encountered a bug. Here's a simple test I put together:
>
>mount { "/unixteam":
>  device => "some_server:/vol/UnixTeam",
>  fstype => "nfs",
>  options => "_netdev,vers=3,tcp,rsize=8192,wsize=8192,noauto",
>}
>
> When Puppet runs, it sees the changes and acts like it's making them:
>
># puppet mount.pp
>notice: //Mount[/unixteam]/device: defined 'device' as
> 'some_server:/vol/UnixTeam'
>notice: //Mount[/unixteam]/fstype: defined 'fstype' as 'nfs'
>notice: //Mount[/unixteam]/options: defined 'options' as
> '_netdev,vers=3,tcp,rsize=8192,wsize=8192,noauto'
>notice: //Mount[/unixteam]/pass: defined 'pass' as '0'
>notice: //Mount[/unixteam]/dump: defined 'dump' as '0'
>notice: //Mount[/unixteam]: Refreshing self
>
>
Seems like *ensure* must be defined otherwise this behaviour is followed, I
was able to reproduce your results, here the output with debug and trace
filtered by mount.

debug: Prefetching parsed resources for mount
debug: //Node[foo.com]/Mount[/mnt]: Changing device,fstype,options,pass,dump
debug: //Node[foo.com]/Mount[/mnt]: 5 change(s)
notice: //Node[foo.com]/Mount[/mnt]/device: defined 'device' as 'bar.com:
/vol/test'
notice: //Node[foo.com]/Mount[/mnt]/fstype: defined 'fstype' as 'nfs'
notice: //Node[foo.com]/Mount[/mnt]/options: defined 'options' as
'rw,bg,hard,nfsvers=3,tcp,nointr,timeo=600'
notice: //Node[foo.com]/Mount[/mnt]/pass: defined 'pass' as '0'
notice: //Node[foo.com]/Mount[/mnt]/dump: defined 'dump' as '0'
debug: Flushing mount provider target /etc/fstab
notice: //Node[foo.com]/Mount[/mnt]: Refreshing self
debug: Puppet::Type::Mount::ProviderParsed: Executing '/bin/mount'

Running Puppet v0.24.8


> But the changes aren't made. If you run Puppet again, it will give the same
> output because the mount isn't actually defined in `/etc/fstab`. (If you add
> it by hand, Puppet will be silent because there’s nothing to change.) But
> you can see from looking at the first three lines of `fstab` that Puppet has
> touched it:
>
># HEADER: This file was autogenerated at Wed Aug 04 11:40:37 -0400 2010
># HEADER: by puppet.  While it can still be managed manually, it
># HEADER: is definitely not recommended.
>
> If I add `ensure => present`, the entry gets added, but according to the
> documentation, "if the filesystem is currently mounted, it will be
> unmounted".
>
> I don't want Puppet to unmount (or mount) it. I just want it defined in
> `fstab` so it can be easily mounted as needed. Can that be done?
>

I sounds like the use case you are looking for is not supported, as you want
it only in fstab but not perform any action, e.g. if mounted it should keep
mounted, or if unmounted leave it unmounted.


> Thanks.
>
> --
> Rob McBroom
> 
>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] Struggling with syntax

[Tony G.]

On Fri, Jul 23, 2010 at 7:22 AM, ScubaDude wrote:

> Can someone point me in the right direction, I've got two "source"
> files one 32bit, on 64bit
> I've got it to work using the ternary operator but get syntax errors
> if I try to use a case:
>
> Works:
>
> class audit {
>
>package {
>"audit":
>ensure  => present,
>name=> $operatingsystem ? {
>default => "auditd",
>},
>}
>
>file {
>"auditd.conf":
>owner   => "root",
>group   => "root",
>mode=> "640",
>require => Package["audit"],
>path=> $operatingsystem ? {
>default => "/etc/auditd.conf",
>},
>source  => "puppet://$server/modules/audit/
> auditd.conf",
>}
>
>file {
>"audit.rules":
>owner => "root",
>group => "root",
>mode  => "600",
>path  => $operatingsystem ? {
>  default => "/etc/audit.rules",
>},
>source => $hardwaremodel ? {
>"x86_64" => "puppet://$server/modules/
> audit/audit.rules.64",
>default  => "puppet://$server/modules/
> audit/audit.rules.32",
>},
>}
>
>service {
>"audit":
>enable=> "true",
>ensure=> "running",
>hasstatus => "true",
>require   => File["auditd.conf", "audit.rules"],
>subscribe => File["auditd.conf", "audit.rules"],
>name  => $operatingsystem ? {
>default => "auditd",
>},
>}
> }
>
> Syntax Error:
>
> Jul 23 13:20:43  puppetmasterd[14197]: Syntax error at 'case';
> expected '}' at /etc/puppet/modules/audit/manifests/init.pp:32 on node
> 
> Jul 23 13:20:43  puppetmasterd[14197]: Syntax error at 'case';
> expected '}' at /etc/puppet/modules/audit/manifests/init.pp:32 on node
> 
>
> class audit {
>
>package {
>"audit":
>ensure  => present,
>name=> $operatingsystem ? {
>default => "auditd",
>},
>}
>
>file {
>"auditd.conf":
>owner   => "root",
>group   => "root",
>mode=> "640",
>require => Package["audit"],
>path=> $operatingsystem ? {
>default => "/etc/auditd.conf",
>},
>source  => "puppet://$server/modules/audit/
> auditd.conf",
>}
>
>file {
>"audit.rules":
>owner => "root",
>group => "root",
>mode  => "600",
>path  => $operatingsystem ? {
>  default => "/etc/audit.rules",
>},
>case $hardwaremodel {
>"x86_64": { source => "puppet://
> $server/modules/audit/audit.rules.64" }
>default:  { source => "puppet://
> $server/modules/audit/audit.rules.32" }
>},
>}
>
>service {
>"audit":
>enable=> "true",
>ensure=> "running",
>hasstatus => "true",
>require   => File["auditd.conf", "audit.rules"],
>subscribe => File["auditd.conf", "audit.rules"],
>name  => $operatingsystem ? {
>default => "auditd",
>},
>}
> }
>

You might want to add the case statement out of the file resource and assign
to a variable for the source:

case $hardwaremodel {
 "x86_64": { $hw_source =
"puppet://$server/modules/audit/audit.rules.64" }
  default: { $hw_source =
"puppet://$server/modules/audit/audit.rules.32" }
  }

Then insinde the file resource only add the variable to the source:
source => $hw_source,

Seems like the parser does not allow case statements in the attributes of
the resources.

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


-- 
Tony
http://blog.tonyskapunk.net

-- 
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] apt-rpm package downgrade

[Tony G.]

Hi Antony

On Tue, Jul 13, 2010 at 6:53 AM, Antony Mayi  wrote:

> Hi,
>
> I am using apt-rpm provider and have following manifest for keeping some
> package at particular version
>
>   package { "somepackage":
> ensure => "1.0.0"
>   }
>
> however if from some reason the package gets upgraded to some higher
> version, puppet can't downgrade it because of following error:
>
> Jul 13 11:32:25 server puppetd[14095]:
> (//module/Package[somepackage]/ensure) change from 1.0.1 to 1.0.0 failed:
> Could not update: Execution of '/usr/bin/apt-get -q -y install
> somepackage=1.0.0' returned 100: Reading Package Lists... Building
> Dependency Tree... The following packages will be DOWNGRADED   somepackage
> E: There are problems and -y was used without --force-yes 0 upgraded, 0
> newly installed, 1 downgraded, 0 removed and 2 not upgraded. Need to get
> 0B/8361B of archives. After unpacking 50B disk space will be freed.  at
> /etc/puppet/modules/module/manifests/somepackage.pp:12
>
> is it possible to use the standard 'Package' resource for downgrading some
> package with apt-rpm provider?
>
> This is similar situation with yum provider
http://projects.reductivelabs.com/issues/2866

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



-- 
Tony
http://blog.tonyskapunk.net

-- 
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 package uninstall question

[Tony G.]

On Wed, Jun 16, 2010 at 12:02 PM, Roshan  wrote:
> This may be a really simple question. I have defined a package to
> ensure=>latest in one of my modules. In the nodes.pp, I have the
> module included, and the package installs fine.
>
> Now I want to remove the module/package from my server. Can't I just
> remove the include of the module from the nodes.pp and it should
> automatically uninstall the package?
>
(Un)Fortunately, No; you have to explicitly remove it with an ensure => absent

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



-- 
Tony

-- 
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: External Nodes

[Tony G.]

According to experience what's the pros/cons of those methods to store the
nodes?
Like ldap, DB, a library/framework like clusto/puppetdashboard/foreman etc.

Thanks


On Sat, May 15, 2010 at 5:22 PM, Silviu Paragina  wrote:

> On 15.05.2010 00:30, Baker, Luke Jefferson wrote:
>
>> Speaking of external nodes..
>>
>> Any decent tutorials out there for someone that has no idea where to
>> start? ;)
>>
>>
> External nodes are a way of looking up classes and vars to be applied to a
> node via an external application.
> http://docs.puppetlabs.com/guides/external_nodes.html - you may try a do
> it yourself script/application
>
> But you should try foreman, puppet dashboard or extlookup (I think there
> are other, but I don't know them). Each has a different setup process to
> long to explaing here. (do a few googles ;) )
>
> 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.
>
>


-- 
Tony

-- 
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: variable interpolation weirdness

[Tony G.]

On Wed, Apr 21, 2010 at 8:42 PM, Sukh Khehra  wrote:

> Forgot to mention that I am running version puppet-0.25.4-1 on both
> sides on centos 5.4.
>
> -Original Message-
> From: Sukh Khehra
> Sent: Wednesday, April 21, 2010 8:39 PM
> To: 'puppet-users@googlegroups.com'
> Subject: variable interpolation weirdness
>
> Can someone please explain what's happening here? Let me know if you
> need more info. Thanks in advance for your time.
>
> I have a module called abc. This is the init.pp for that module.
>
>
> ###
> $ cat modules/production/abc/manifests/init.pp
> # Puppet Module: abc
> #
>
> class abc {
>package { "maatkit": ensure => present }
> }
>
> class abc::base inherits abc {
>   exec { "testvars": command => "/bin/echo
> 'java_version=${java_version}'", logoutput => true; }
> }
>
> class abc::test {
>   $java_version = "jdk1.6.0_14"
>   include abc::base
> }
> ###
>
>
> I accidently assigned both the "abc" and "abc::test" class to a host and
> noticed that the variable "java_version" no longer gets interpolated.
> E.g. here's the puppet run log.
>
> # puppetd -t
> notice: Ignoring --listen on onetime run
> info: Retrieving plugin
> info: Caching catalog for abc1.staging.pp.com
> info: Applying configuration version '1271906581'
> notice: //abc::base/Exec[testvars]/returns: java_version=
> notice: //abc::base/Exec[testvars]/returns: executed successfully
> warning: Value of 'preferred_serialization_format' (pson) is invalid for
> report, using default (marshal)
> notice: Finished catalog run in 3.21 seconds
>
> Hi Sukh,

Both classes are included but the $java_version is defined in a different
scope than the include of abc on your node.

node
  |--include "abc" <-- in this scope $java_version has not been defined
  |--include "abc::test" <- $java_version is defined
  |-- include "abc" <-- The variable affects this scope, but is already
included, then not used again.


> But If I only assign the host the "abc::test" class, everything works ok
> like so:
>
> # puppetd -t
> notice: Ignoring --listen on onetime run
> info: Retrieving plugin
> info: Caching catalog for abc1.staging.pp.com
> info: Applying configuration version '1271906581'
> notice: //abc::base/Exec[testvars]/returns: java_version=jdk1.6.0_14
> notice: //abc::base/Exec[testvars]/returns: executed successfully
> warning: Value of 'preferred_serialization_format' (pson) is invalid for
> report, using default (marshal)
> notice: Finished catalog run in 3.21 seconds
>
> In here the abc::test class defines the $java_version and when the abc
class is included(only one time) the exec prints the value of the variable
that is in the same scope.

Here you will find a detailed explanation of variable scope and inheritance.
http://docs.puppetlabs.com/guides/troubleshooting.html#common_misconceptions

Hope that helps.


>
> So I obviously know what to do to fix the problem but would love to
> understand what's happening here.
>
> Regards,
> 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.
>
>


-- 
Tony

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

[Tony G.]

On Tue, Apr 13, 2010 at 7:57 PM, Scott Smith  wrote:

> On 4/13/10 3:26 PM, SyRenity wrote:
>
>> Hi.
>>
>> I asked this question in past on this list, and now working to set it
>> running.
>>
>> My idea is to have 2 Puppet servers, who are also the DNS servers.
>> Each one would have itself as the puppet hostname.
>> Both of the servers will pull the manifests from external git repo.
>>
>
> Just set up HAproxy and load balance them. Done.
>
> +1

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


-- 
Tony

-- 
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] Cron question

[Tony G.]

On Mon, Apr 12, 2010 at 2:54 PM, Darvin Denmian wrote:

> Hello,
>
> even removing one double quote I got the same error:
>
> "-":6: bad minute
> errors in crontab file, can't install.
>
> Thanks!
>
> On Mon, Apr 12, 2010 at 6:49 PM, Frank Sweetser  wrote:
> > On 04/12/2010 05:45 PM, Darvin Denmian wrote:
> >> Hello,
> >>
> >> Why the following lines doesn't work?
> >>
> >>cron { "app" :
> >>   command => ""nice -n -10 /usr/bin/php
> >
> > I'm not familiar with the cron type, but I'm betting that the pair of
> double
> > quotes before the nice command isn't helping any =)
> >
> > --
> > Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution
> that
> > WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL
> Mencken
> >GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC
> >
>
> --
> 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 don't see any time declaration, you have to define how often your cronjob
should run, it's not necessary to define '*' when you don't want to set a
particular attribute. e.g.

If you want to run every minute you define:

cron { "app" :
 command => ""nice -n -10 /usr/bin/php
/var/www/public_html/rotinas/rotinas.php 2>&1>> /var/log/app.log",
 environment => "PATH=$PATH",
 user=> root,
 minute=> "*/1"
}

And actually you can leave the time attributes all empty.  From the doc: *"All
fields except the command and the user are optional, although specifying no
periodic fields would result in the command being executed every minute."*

http://docs.puppetlabs.com/references/stable/type.html#cron

Hope that helps

-- 
Tony

-- 
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: Yum provider using version-release as version?

[Tony G.]

Didn't find a bug related to this, I have created:
http://projects.puppetlabs.com/issues/3538

Thanks

On Mon, Apr 12, 2010 at 7:00 AM, Michael DeHaan wrote:

> >> I think you're saying that Puppet isn't comparing installed packages
> >> quite the way yum does, and that yum would be able to find the match
> >> if executed with just the version and not the release, right?
> >
> > Yes this is correct. Its all about being less precise in your match.
> >
>
> Ok, I agree this is a bug.   Please file one if there isn't one already.
>
> I don't think we need a new regex matching parameter or anything, just
> that the internals of the provider do not seem to be correct when they
> don't work the same way as the yum CLI.
>
> --Michael
>
> --
> 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.
>
>


-- 
Tony

-- 
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: Yum provider using version-release as version?

[Tony G.]

Hi

On Sat, Apr 10, 2010 at 2:33 PM, Ken  wrote:

> > let's step back a moment before we discuss implementation or changes.
>
> There's little harm in being conceptual - especially when I won't have
> to implement it :-).
>
> > What package did you have installed before running the command (I
> > assume none, right?), and what packages are in your yum repo (full
> > name of package)?
>
> In both mine and Tony's case - the packages are already installed on
> the system (you can see this commented in Tony's post).
>

Actually both situations (not having the package installed _and_ having it
already installed) cause the Error. If the package is not installed, puppet
_will_ install it but at the time of validation it will print out the Error
as it does not match, if the package is already installed it will print out
the Error too as the "ensure" string(the version only) does not match the
version-release that puppet constructs in the query define of the rpm.rb.

>
> > I think you're saying that Puppet isn't comparing installed packages
> > quite the way yum does, and that yum would be able to find the match
> > if executed with just the version and not the release, right?
>
> Yes this is correct. Its all about being less precise in your match.
>
> ken.
>
> --
> 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.
>
>


-- 
Tony

-- 
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] Yum provider using version-release as version?

[Tony G.]

Hi,

I'm using yum as our package provider and having an issue. Puppet is
complaining of the version, this is the code I'm trying to implement:

$snmp_version = "5.3.2.2"
package { "net-snmp": ensure => "${snmp_version}"; }

On the client I got:
debug: //Node[client.example.com]/snmp::base/Package[net-snmp]: Changing
ensure
debug: //Node[client.example.com]/snmp::base/Package[net-snmp]: 1 change(s)
debug: Package[net-snmp](provider=yum): Ensuring => 5.3.2.2
debug: Puppet::Type::Package::ProviderYum: Executing '/usr/bin/yum -d 0 -e 0
-y install net-snmp-5.3.2.2' *(1)*
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q net-snmp
--nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION}
%{RELEASE} %{ARCH}
' *(2)*
err: //Node[client.example.com]/snmp::base/Package[net-snmp]/ensure: change
from 5.3.2.2-7.el5_4.2 to 5.3.2.2 failed: Could not update: Failed to update
to version *5.3.2.2*, got version *5.3.2.2-7.el5_4.2* instead at
/opt/git/development/modules/snmp/manifests/init.pp:26
notice: //Node[client.example.com]/snmp::base/File[/etc/snmp/snmpd.conf]:
Dependency package[net-snmp] has 1 failures
warning: 
//Node[labtest40-v3.ea-colo.ea.com]/snmp::base/File[/etc/snmp/snmpd.conf]:
Skipping because of failed dependencies

The package is installed*(1)* but the error is still shown at the time of
validation*(2)*.

Looking at the code I found:

in .../provider/package/yum.rb:
def install
 chop lines ---

*is = self.query*
unless is
raise Puppet::Error, "Could not find package %s" % self.name
end

# FIXME: Should we raise an exception even if should == :latest
# and yum updated us to a version other than @param_hash[:ensure] ?
if should && should != is[:ensure]
raise Puppet::Error, "Failed to update to version #{*should*}, got
version #{*is[:ensure]*} instead"
end

in .../provider/package/rpm.rb the query define comment says it will provide
the "version-release"
# Find the fully versioned package name and the version alone. Returns
# a hash with entries :instance => fully versioned package name, and
#* :ensure => version-release*
*def query*

The validation is made on what is provided in the ensure
attribute($snmp_version) against "version-release" installed.  I think it
makes sense when somebody defines something like ensure =>
"${snmp_version}-${snmp-release}", but not in my use case.

I would like to hear comments of my use case as it could probably would be a
valid feature request.

Thanks!

I'm Running(still) 0.24.8 on client and master.

-- 
Tony

-- 
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] Do not edit above this line policy

[Tony G.]

2010/4/3 Jesús M. Navarro 

> Hi, list:
>
> I'm on my first steps using Puppet.  Now that the easiest parts are somehow
> tamed more and more questions do arise.  But let's go one by one.
>
> For some computers/services we delegate some parts of their administration
> (i.e. development environments).  I'll take an easy example on the
> /etc/hosts
> file:
>
> There should be a '127.0.0.1 localhost' stanza and then one pointing the
> host's public IP to its FQDN.  But then, the "end user" should have to be
> free to add other entries as needed.
>
> I'm aware that I could go the path of forcing presence on a line by line
> fashion but is there any easier procedure for a "do not edit above this
> line"
> policy so puppet can manage by means of a template part of the file and
> then
> allow for hand-made modifications on the end part of it?
>
> TIA.
>
>
You might want to look at http://augeas.net/ It allows you to have specific
entries in a file, like /etc/hosts, end users can modify the file as needed
but you will have control of those specific entries with puppet+augeas.
http://projects.reductivelabs.com/projects/puppet/wiki/Puppet_Augeas

Hope that helps.

-- 
Tony

-- 
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] Directory structure?

[Tony G.]

I have same structure, but interested if there is any other out there.

On Mon, Mar 22, 2010 at 4:33 PM, Nigel Kersten  wrote:

> You should use 'lib' instead of 'plugins' for 0.25.x clients.
>
> Otherwise that's exactly how I have things laid out.
>
>
> On Mon, Mar 22, 2010 at 4:24 PM, Allan Marcus  wrote:
> > hello,
> >
> > Is this directory structure for modules still recommended, or is there a
> better way?
> >
> >
> http://projects.reductivelabs.com/projects/puppet/wiki/Module_Organisation
> >
> > We are thinking of having a directory for each environment, then broken
> down as recommended here:
> >
> >
> http://projects.reductivelabs.com/projects/puppet/wiki/Puppet_Best_Practice
> >
> > So in practice, it might look like
> >
> > Environments
> > /env1
> > /env1/manifests/site.pp
> > /env1/manifests/templates.pp
> > /env1/manifests/nodes.pp
> > /env1/modules/{modulename}/files/
> > /env1/modules/{modulename}/manifests/init.pp
> > /env1/modules/{modulename}/manifests/class1.pp
> > /env1/modules/{modulename}/manifests/definition1.pp
> > /env1/modules/{modulename}/manifests/class2.pp
> > /env1/modules/{modulename}/plugins/
> > /env1/modules/{modulename}/templates/
> >
> > /env2
> > ...
> > /env3
> > ...
> >
> > Does this look right?
> >
> > ---
> > Thanks,
> >
> > Allan Marcus
> > 505-667-5666
> >
> >
> >
> >
>
>
>
> --
> nigel
>
> --
> 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.
>
>


-- 
Tony

-- 
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] Behavior of Environments -- Bug?

[Tony G.]

Oh Ok, so what you are looking for is more like a feature to let you know
that the environment "foo" does not exist.

Does not sounds bad to me, if somebody uses tons of environments it will
reduce errors or at least will be easier to find them.


On Mon, Mar 22, 2010 at 11:14 AM, Paul Lathrop wrote:

> Tony,
>
> Sure, I understand that, but if the client is asking for a specific
> environment that the puppetmaster doesn't know about, I feel like that
> warrants a warning at minimum, probably an error and a refusal to
> compile. Would be interested if anyone has a counter-argument.
>
> --Paul
>
> On Mon, Mar 22, 2010 at 10:59 AM, Tony G.  wrote:
> > Hi Paul,
> >
> > How does your config file look like in the main section?
> >
> > There is a default one if no environment is defined, e.g.
> >
> > environments = production,testing,development
> > manifest = /opt/puppet/production/site.pp  <-- These are the
> > modulepath = /opt/puppet/production/modules  <-- default locations
> >
> > [production]
> > manifest = /opt/puppet/production/site.pp
> > modulepath = /opt/puppet/production/modules
> >
> > [testing]
> > manifest = /opt/puppet/testing/site.pp
> > modulepath = /opt/puppet/testing/modules
> >
> > [development]
> > manifest = /opt/puppet/development/site.pp
> > modulepath = /opt/puppet/development/modules
> >
> >
> > On Mon, Mar 22, 2010 at 10:27 AM, Paul Lathrop 
> > wrote:
> >>
> >> Over the weekend we noticed an interesting and unexpected behavior
> >> with environments. I made a change to the way our puppet.conf file is
> >> generated and distributed, which led to an environment which had been
> >> defined on a puppetmaster being no longer defined in puppet.conf.
> >> We'll call this the "core" environement. When clients checked in and
> >> asked for the "core" environment, the puppetmaster didn't know about
> >> it. I would have expected an error at this point. However, what
> >> happened instead was the puppetmaster passed out the configs for the
> >> "production" environment without complaint.
> >>
> >> IMHO this is a bug, but I can see how it might be by design. Any
> >> comments? Should I file it?
> >>
> >> --Paul
> >>
> >> --
> >> 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.
> >>
> >
> >
> >
> > --
> > Tony
> >
> > --
> > 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.
>
>


-- 
Tony

-- 
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] Behavior of Environments -- Bug?

[Tony G.]

Hi Paul,

How does your config file look like in the main section?

There is a default one if no environment is defined, e.g.

environments = production,testing,development*
manifest = /opt/puppet/production/site.pp  <-- These are the
modulepath = /opt/puppet/production/modules  <-- default locations*

[production]
manifest = /opt/puppet/production/site.pp
modulepath = /opt/puppet/production/modules

[testing]
manifest = /opt/puppet/testing/site.pp
modulepath = /opt/puppet/testing/modules

[development]
manifest = /opt/puppet/development/site.pp
modulepath = /opt/puppet/development/modules


On Mon, Mar 22, 2010 at 10:27 AM, Paul Lathrop wrote:

> Over the weekend we noticed an interesting and unexpected behavior
> with environments. I made a change to the way our puppet.conf file is
> generated and distributed, which led to an environment which had been
> defined on a puppetmaster being no longer defined in puppet.conf.
> We'll call this the "core" environement. When clients checked in and
> asked for the "core" environment, the puppetmaster didn't know about
> it. I would have expected an error at this point. However, what
> happened instead was the puppetmaster passed out the configs for the
> "production" environment without complaint.
>
> IMHO this is a bug, but I can see how it might be by design. Any
> comments? Should I file it?
>
> --Paul
>
> --
> 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.
>
>


-- 
Tony

-- 
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 Client using wrong environment.

[Tony G.]

Finally found the issue

I never looked into the /etc/puppet directory(my bad), there was the issue,
a strange one although but here is what happened, in there were two
files(wish I knew why there were that second if we use puppet 0.24.8):

puppet.conf
puppetd.conf

Same content, nothing different, I don't declare the environment in there as
I use it in /etc/sysconfig/puppet

[app02 ~]$ grep environment /etc/puppet/puppet.conf /etc/puppet/puppetd.conf

[app02 ~]$ diff /etc/puppet/puppet.conf /etc/puppet/puppetd.conf
[app02 ~]# /usr/sbin/puppetd -t --environment=*development*
info: Loading fact drac
info: Loading fact rhelver
info: Loading fact sserial
info: Retrieving plugins
info: Loading fact drac
info: Loading fact rhelver
info: Loading fact sserial
info: mount[localhost]: Mounted /
info: mount[modules]: Mounted
info: mount[plugins]: Mounted
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
info: Loading fact drac
info: Loading fact rhelver
info: Loading fact sserial
info: Sent transaction report in 1.47 seconds
notice: Finished catalog run in 16.85 seconds
[app02 ~]# grep -m2 -P "development|production"
/var/lib/puppet/localconfig.yaml
file: /opt/puppet/*production*/classes/yumrepos.pp
file: /opt/puppet/*production*/classes/yumrepos.pp

Fixing:
*[app02 ~]# rm /etc/puppet/puppetd.conf*
*rm: remove regular file `/etc/puppet/puppetd.conf'? y*

[app02 ~]# /usr/sbin/puppetd -t --environment=*development*
info: Loading fact drac
info: Loading fact rhelver
info: Loading fact sserial
info: Retrieving plugins
info: Loading fact drac
info: Loading fact rhelver
info: Loading fact sserial
info: mount[localhost]: Mounted /
info: mount[modules]: Mounted
info: mount[plugins]: Mounted
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
info: Loading fact drac
info: Loading fact rhelver
info: Loading fact sserial
notice: 
//Node[app02.example.com]/common::ldap/Sudo::Config[standard]/Package[sudo-ldap]/ensure:
removed
notice: 
//Node[app02.example.com]/common::ldap/Sudo::Config[standard]/Package[sudo]/ensure:
created
info: Sent transaction report in 0.37 seconds
notice: Finished catalog run in 18.09 seconds
[app02 ~]# grep -m2 -P "development|production"
/var/lib/puppet/localconfig.yaml
  file: /opt/puppet/*development*/site.pp
file: /opt/puppet/*development*/classes/common.pp

So what is doing puppetd is reading both files and for some reason ignoring
the --environment flag via command line or the flag in the
/etc/sysconfig/puppet when bringing up the daemon with the
/etc/init.d/puppet script.

Doing a strace I see both files are being opened with puppetd:
open("/etc/puppet/puppetd.conf", O_RDONLY) = 3
open("/etc/puppet/puppet.conf", O_RDONLY) = 4

I assume it attempts to read puppetd.conf as it was the old config file, but
should it ignore the environment flag as it's doing it?

Thanks


On Thu, Mar 18, 2010 at 10:24 AM, Tony G.  wrote:

> When no environment is defined it uses production, per my notes:
>
>
> environments = production,testing,development
> manifest = /opt/puppet/production/site.pp
> modulepath = /opt/puppet/production/modules
>
> This is part of [main].
>
>
>
> On Wed, Mar 17, 2010 at 5:00 PM, Rob McBroom wrote:
>
>> How is the environment determined when you don’t specify one? On my
>> systems, it seems that the `--environment` option is completely ignored. I
>> imagine this is because the external information (from LDAP in my case)
>> always takes precedence.
>>
>> --
>> Rob McBroom
>> <http://www.skurfer.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.
>>
>>
>
>
> --
> Tony
>



-- 
Tony

-- 
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 Client using wrong environment.

[Tony G.]

When no environment is defined it uses production, per my notes:

environments = production,testing,development
manifest = /opt/puppet/production/site.pp
modulepath = /opt/puppet/production/modules

This is part of [main].


On Wed, Mar 17, 2010 at 5:00 PM, Rob McBroom wrote:

> How is the environment determined when you don’t specify one? On my
> systems, it seems that the `--environment` option is completely ignored. I
> imagine this is because the external information (from LDAP in my case)
> always takes precedence.
>
> --
> Rob McBroom
> 
>
> --
> 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.
>
>


-- 
Tony

-- 
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 Client using wrong environment.

[Tony G.]

Hi,

I exposed few days ago this situation on the IRC, but unfortunately I
haven't found a way to solve it yet.

I run the Puppet Master with multiple environments, and everything is
working good but a couple of nodes that are causing me some troubles.

These nodes are pointing to my production environment and I need to point
them back to development to grab some changes I made.

I usually follow these steps on the clients once I've tested in my own
environment:
1. Stop puppet daemon.
2. Test the new config pointing to development environment.
3. Run puppetd pointing to development.
4. Verify change.
5. Start Puppet.

This is a test I did with a similar node:

Testing pointing to *development*:

[app03 ~]# /usr/sbin/puppetd --test -vt --*environment*=*development*
--snip--
notice: Finished catalog run in 30.42 seconds
[app03 ~]# grep -m2 -P "/development/|/production/"
/var/lib/puppet/localconfig.yaml
  file: /opt/puppet/*development*/site.pp
file: /opt/puppet/*development*/modules/ntp/manifests/init.pp

 Testing now pointing to *production*:

[app03 ~]# /usr/sbin/puppetd --test -vt --*environment*=*production*
--snip--
notice: Finished catalog run in 30.55 seconds
[eapp03 ~]# grep -m2 -P "/development/|/production/"
/var/lib/puppet/localconfig.yaml
  file: /opt/puppet/*production*/site.pp
file: /opt/puppet/*production*/classes/puppet.pp


When doing the same on the node I see the strange behavior this is what I
get:

[app01 ~]# /usr/sbin/puppetd --test -vt --environment=*development*
--snip--
[app01 ~]# grep -m2 -P "/development/|/production/"
/var/lib/puppet/localconfig.yaml
file: /opt/puppet/*production*/classes/yumrepos.pp
file: /opt/puppet/*production*/classes/yumrepos.pp

I've tried:

   - Removing the cache in the server
   ($vardir/yaml/{node,facts}/app01.example.com.yaml) and puppetca --clean
   app01.example.com
   - Restarted the server(using passenger).
   - Removed the client $vardir/*
   - Reinstalled puppet client.

All of them with the *same result.*

The nodes with these issues are being hosted with a third party hosting
company, don't think there is any relationship with this as communications
are made between the client/server, but seems like I can't find any other.

Any suggestion is appreciated,  Thanks for reading this.

This is what I use:

PuppetMaster 0.24.8
Puppetclients 0.24.8
passenger (2.2.4)

puppet.conf:
---snippet---
environments = production,testing,development
manifest = /opt/puppet/production/site.pp
modulepath = /opt/puppet/production/modules

[production]
manifest = /opt/puppet/production/site.pp
modulepath = /opt/puppet/production/modules

[testing]
manifest = /opt/puppet/testing/site.pp
modulepath = /opt/puppet/testing/modules

[development]
manifest = /opt/puppet/development/site.pp
modulepath = /opt/puppet/development/modules

---snippet---


-- 
Tony

-- 
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: Strange Problem with ldap Systems

[Tony G.]

Hi Rene,

I don't think there is a problem if the user is not in ldap.

Run the puppetd with --debug so you can see what command is being issued
before that notice is posted, that might give you a clue of what's doing
puppet.

On Thu, Mar 4, 2010 at 1:15 AM, Rene  wrote:

> Hi Tony
>
> Here my investigations for another user:
>
> For our storage user the following happens with puppet:
> notice: //Node[default]/netbackup/netbackup::general/users::storage/
> User[storage]/groups: groups changed 'log,log' to 'log'
>
> The user storage is not in ldap, but the group log. On ldap I have:
> log:*:126:user1,user2,user3,storage,user4
>
> Local I have:
> log:x:126:storage
>
> To get the information i always deleted the ldap or files entry in /
> etc/nsswitch.conf.
>
> I also have:
> only ldap in nsswitch.conf:
> # id storage
> uid=902(storage) gid=902(storage) groups=126(log),902(storage)
> only files in nsswitch.conf:
> id storage
> uid=902(storage) gid=902(storage) groups=126(log),902(storage)
>
> Do you have any other ideas?
>
> Do you think the problem could arise from that the user storage is not
> in ldap?
>
> On Mar 2, 7:50 pm, "Tony G."  wrote:
> > Hi Rene,
> >
> > I tried to replicate the behavior without luck.
> >
> > Reading again your email I noticed that you used getent passwd to pull
> the
> > LDAP data, but that does not guarantee you are pulling from LDAP as it
> > depends on the order in your nsswitch.conf file.
> >
> > Here nsswitch.conf has files before ldap(I created locally auser and
> agroup
> > as you)
> > $ id auser
> > uid=999(auser) gid=999(auser) groups=999(auser),666(agroup)
> > $ getent passwd auser
> > auser:*:999:999:Some user:/home/auser:/bin/bash
> >
> > Here ldap is before nsswitch.conf (I created in ldap auser and agroup)
> > $ id auser
> > uid=999(auser) gid=*888*(auser) groups=*888*(auser),666(agroup)
> > $ getent passwd auser
> > auser:*:999:*888*:auser test:/home/auser:/bin/bash
> >
> > So the change you see *changed 'agroup,agroup' to 'agroup' *sounds like
> > auser has two agroup groups(with diff gid) and changing to have only one
> > agroup.  I might be wrong with this, but the issue should be around
> there.
> >
> > I've tried to avoid having same groups/users in ldap and locally to avoid
> > similar issues.
> >
> > Hope that helps.
> >
> >
> >
> > On Tue, Mar 2, 2010 at 10:13 AM, Rene  wrote:
> > > Hi Tony
> >
> > > Thanks for the quick answer.
> >
> > > Yes the group is defined in the LDAP too with the same GID. And here
> > > the definition:
> > >@user { auser:
> > >comment =>  'Some user',
> > >ensure  =>  present,
> > >gid =>  somegid,
> > >uid =>  300,
> > >groups  =>  'agroup',
> > >home=>  '/application/home/auser',
> > >shell   =>  '/bin/bash',
> > >require =>  [ Group['auser'], Group['agroup'] ],
> > >}
> >
> > > I have no idea what is going wrong.
> >
> > > On Mar 2, 4:53 pm, "Tony G."  wrote:
> > > > Hi Rene,
> >
> > > > Couple of things you might check:
> >
> > > > Do you have the agroup defined in LDAP too?  If so that ldap group
> might
> > > > have a differente gid as the local one.
> >
> > > > How looks the definition of the user in users::db?
> >
> > > > On Tue, Mar 2, 2010 at 8:44 AM, Rene  wrote:
> > > > > On the System we have defined the user auser as:
> > > > > /etc/passwd:
> > > > > auser:x:300:300:auser User:/application/home/auser:/bin/bash
> > > > > /etc/group:
> > > > > agroup:x:126:auser
> >
> > > > > So id auser gives:
> > > > > uid=300(auser) gid=300(auser) groups=126(agroup),300(auser)
> >
> > > > > In the LDAP we have:
> > > > > #getent passwd auser
> > > > > auser:x:300:300:auser User:/application/home/auser:/bin/bash
> > > > > and
> > > > > #getent group agroup
> > > > > agroup:x:126:auser
> >
> > > > > Basically the same definition.
> >
> > > > > Now everytime I run puppet I get:
> > > > > notice: //Node[default]/oracle/users::db/User[auser]/groups:

Re: [Puppet Users] Re: Strange Problem with ldap Systems

[Tony G.]

Hi Rene,

I tried to replicate the behavior without luck.

Reading again your email I noticed that you used getent passwd to pull the
LDAP data, but that does not guarantee you are pulling from LDAP as it
depends on the order in your nsswitch.conf file.

Here nsswitch.conf has files before ldap(I created locally auser and agroup
as you)
$ id auser
uid=999(auser) gid=999(auser) groups=999(auser),666(agroup)
$ getent passwd auser
auser:*:999:999:Some user:/home/auser:/bin/bash

Here ldap is before nsswitch.conf (I created in ldap auser and agroup)
$ id auser
uid=999(auser) gid=*888*(auser) groups=*888*(auser),666(agroup)
$ getent passwd auser
auser:*:999:*888*:auser test:/home/auser:/bin/bash

So the change you see *changed 'agroup,agroup' to 'agroup' *sounds like
auser has two agroup groups(with diff gid) and changing to have only one
agroup.  I might be wrong with this, but the issue should be around there.

I've tried to avoid having same groups/users in ldap and locally to avoid
similar issues.

Hope that helps.

On Tue, Mar 2, 2010 at 10:13 AM, Rene  wrote:

> Hi Tony
>
> Thanks for the quick answer.
>
> Yes the group is defined in the LDAP too with the same GID. And here
> the definition:
>@user { auser:
>comment =>  'Some user',
>ensure  =>  present,
>gid =>  somegid,
>uid =>  300,
>groups  =>  'agroup',
>home=>  '/application/home/auser',
>shell   =>  '/bin/bash',
>    require =>  [ Group['auser'], Group['agroup'] ],
>}
>
> I have no idea what is going wrong.
>
>
> On Mar 2, 4:53 pm, "Tony G."  wrote:
> > Hi Rene,
> >
> > Couple of things you might check:
> >
> > Do you have the agroup defined in LDAP too?  If so that ldap group might
> > have a differente gid as the local one.
> >
> > How looks the definition of the user in users::db?
> >
> >
> >
> > On Tue, Mar 2, 2010 at 8:44 AM, Rene  wrote:
> > > On the System we have defined the user auser as:
> > > /etc/passwd:
> > > auser:x:300:300:auser User:/application/home/auser:/bin/bash
> > > /etc/group:
> > > agroup:x:126:auser
> >
> > > So id auser gives:
> > > uid=300(auser) gid=300(auser) groups=126(agroup),300(auser)
> >
> > > In the LDAP we have:
> > > #getent passwd auser
> > > auser:x:300:300:auser User:/application/home/auser:/bin/bash
> > > and
> > > #getent group agroup
> > > agroup:x:126:auser
> >
> > > Basically the same definition.
> >
> > > Now everytime I run puppet I get:
> > > notice: //Node[default]/oracle/users::db/User[auser]/groups: groups
> > > changed 'agroup,agroup' to 'agroup'
> > > This is really strange.
> >
> > > Does anybody know what the problem is here. Does Puppet Merge the
> > > groups from local and ldap?
> >
> > > Any hint is appreciated.
> >
> > > BR, Rene
> >
> > > --
> > > 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.
> >
> > --
> > Tony
>
> --
> 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.
>
>


-- 
Tony

-- 
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] Strange Problem with ldap Systems

[Tony G.]

Hi Rene,

Couple of things you might check:

Do you have the agroup defined in LDAP too?  If so that ldap group might
have a differente gid as the local one.

How looks the definition of the user in users::db?

On Tue, Mar 2, 2010 at 8:44 AM, Rene  wrote:

> On the System we have defined the user auser as:
> /etc/passwd:
> auser:x:300:300:auser User:/application/home/auser:/bin/bash
> /etc/group:
> agroup:x:126:auser
>
> So id auser gives:
> uid=300(auser) gid=300(auser) groups=126(agroup),300(auser)
>
> In the LDAP we have:
> #getent passwd auser
> auser:x:300:300:auser User:/application/home/auser:/bin/bash
> and
> #getent group agroup
> agroup:x:126:auser
>
> Basically the same definition.
>
> Now everytime I run puppet I get:
> notice: //Node[default]/oracle/users::db/User[auser]/groups: groups
> changed 'agroup,agroup' to 'agroup'
> This is really strange.
>
> Does anybody know what the problem is here. Does Puppet Merge the
> groups from local and ldap?
>
> Any hint is appreciated.
>
> BR, Rene
>
> --
> 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.
>
>


-- 
Tony

-- 
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] $servername when running standalone puppet

[Tony G.]

Have you tried with --server  ?

I have a Test Puppetmaster where I change configs and for testing I can run
on a client the new configuration with puppeetd --test --server
mytestserver.example.com ...

Hope that helps.

On Thu, Jan 28, 2010 at 1:23 PM, steve.majew...@gmail.com <
steve.majew...@gmail.com> wrote:

> We have a client-server puppetmaster  running puppetd and
> puppetmasterd,
> however I would like to test configurations locally before committing
> the changes
> on the puppetmaster.
>
> Running the puppet config locally with /usr/bin/puppet mostly works.
>
> The thing that fails ( which I have commented out on my local copy to
> test everything else )
> is a  erb template for puppet.conf that includes:
>
>server = <%= servername %>
>
> with the error:
>
> Failed to parse template puppet/puppet.conf.erb: Could not find value
> for 'servername'
>
> It makes sense that no longer running a puppetmasterd that servername
> is undefined.
> But is there any way I can define it so that I can run the same
> configuration files
> both locally standalone and client/server ?
>
> ( I tried "--servername=" but that's not a config variable so it
> doesn't like that. )
>
> Alternatively: is there a way to make part of the code conditional on
> running in stand
> alone mode.
>
> The point of all this is to be able to test my changes locally before
> committing them
> to subversion and updating them on the puppetmaster -- that would be
> more difficult
> if I have to maintain different versions of the same file.
>
> -- Steve Majewski / UVA Alderman Library
>
> --
> 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.
>
>


-- 
Tony

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

[Tony G.]

Hi, again,

I tried as much as possible to avoid installing this patch in prod but
unfortunately is necessary on my situation.

The problem now is that I'm not able to see the yum.rb change in the
clients, while in the Test environment works without issues.

My Test environment uses the same Repo as my other environments(Dev, Prod),
so I could see the client pick up the new changes and downgraded to what I
require.

--snipet--
0a1,2
> require 'puppet/util/package'
>
56a59
> operation = :install
65a69,74
>
> is = self.query
> if is && Puppet::Util::Package.versioncmp(should, is[:ensure])
< 0
> self.debug "Downgrading package #...@resource[:name]} from
version #{is[:ensure]} to #{should}"
> operation = :downgrade
> end
68c77
< output = yum "-d", "0", "-e", "0", "-y", :install, wanted
---
> output = yum "-d", "0", "-e", "0", "-y", operation, wanted
notice: /File[/var/lib/puppet/lib/puppet/provider/package/yum.rb]/checksum:
checksum changed '{md5}177e93a8fb936921a582ac9ddae93159' to
'{md5}14a80f5ee6a033ec568c617b08fd71db'
notice: /File[/var/lib/puppet/lib/puppet/provider/package/yum.rb]/source:
replacing from source puppet://
puppetclient.example.com/plugins/puppet/provider/package/yum.rb with
contents {md5}177e93a8fb936921a582ac9ddae93159

Then it downgrades the package:
--snipet--
notice: 
//Node[puppetclient.example.com]/common/common::nagios/Package[nrpe_custom]/ensure:
ensure changed '01.2-20' to '01.2-10'

My Test Env is using:
puppet-0.24.8-4.el5
puppet-server-0.24.8-4.el5

While Dev/Prod uses:
puppet-server-0.24.8-1.el5.1
puppet-0.24.8-4.el5

The yum.rb remains the same on the clients when getting in contact with the
puppetmaster.

On the Dev Env I've deleted the $vardir to pull the full content, but still
gets the old yum.rb

Any ideas of what might be going wrong?

Thanks!


On Wed, Dec 23, 2009 at 11:02 AM, Tony G.  wrote:

> I was able to perform the downgrade with the 
> patch<http://projects.reductivelabs.com/attachments/807/puppet-yum-downgrade.diff>provided
>  in the feature request #2866.
>
> Dec 23 10:28:00 puppetclient puppetd[17147]: (//Node[
> puppetclient.example.com]/common/common::nagios/Package[nrpe_custom]/ensure)
> ensure changed '01.2-20' to '01.1-10'
>
> Thanks
>
>
> On Wed, Dec 23, 2009 at 11:53 AM, Silviu Paragina wrote:
>
>> Hello,
>> On 23.12.2009 19:45, R.I.Pienaar wrote:
>> > hello,
>> >
>> > - "Silviu Paragina"  wrote:
>> >
>> >
>> >> AFAIK for apt/dpkg everything is fine as it is. But I might be wrong,
>> >> it wouldn't be the first time my mind plays tricks on me. :-)
>> >> Haven't used other package providers :">
>> >>
>> > downgrades fail on debian too.
>> >
>> >
>> hmmm, I thought I've done this. What can I say, except
>>
>> ups
>>
>>
>> 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.
>>
>>
>>
>
>
> --
> Tony
>



-- 
Tony
-- 

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

[Tony G.]

I was able to perform the downgrade with the
patchprovided
in the feature request #2866.

Dec 23 10:28:00 puppetclient puppetd[17147]: (//Node[
puppetclient.example.com]/common/common::nagios/Package[nrpe_custom]/ensure)
ensure changed '01.2-20' to '01.1-10'

Thanks

On Wed, Dec 23, 2009 at 11:53 AM, Silviu Paragina wrote:

> Hello,
> On 23.12.2009 19:45, R.I.Pienaar wrote:
> > hello,
> >
> > - "Silviu Paragina"  wrote:
> >
> >
> >> AFAIK for apt/dpkg everything is fine as it is. But I might be wrong,
> >> it wouldn't be the first time my mind plays tricks on me. :-)
> >> Haven't used other package providers :">
> >>
> > downgrades fail on debian too.
> >
> >
> hmmm, I thought I've done this. What can I say, except
>
> ups
>
>
> 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.
>
>
>


-- 
Tony

--

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

[Tony G.]

Thanks all for the comments, I noticed that there is an open request for
this: http://projects.reductivelabs.com/issues/2866

@John: both rpms are x86_64

Thanks

On Tue, Dec 22, 2009 at 8:27 AM, jcbollinger wrote:

>
>
> 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 <
> http://reductivelabs.com/trac/puppet/wiki/TypeReference#id70>(*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.
>
>
>


-- 
Tony

--

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

[Tony G.]

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
downgradenrpe_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 <http://reductivelabs.com/trac/puppet/wiki/TypeReference#id70>(*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?

Thanks!

On Fri, Dec 18, 2009 at 7:39 PM, Silviu Paragina  wrote:

> You may try to use the debug method I described here
>
> http://groups.google.com/group/puppet-users/browse_thread/thread/40a0cbdc8ade0d71/099af2828b89871e?lnk=gst&q=yum#099af2828b89871e
>
>
> Silviu
>
> Tony G. wrote:
> > Hi,
> >
> > On our organization we have custom npre packages distributed via yum,
> > few days ago a new test package was updated in the repository and new
> > nodes installed this version, the code looked like this:
> >
> > class common::nagios {
> >   package { "nrpe_custom": ensure => "installed" }
> > }
> >
> > To attempt to fix it I wanted to take control of which version we are
> > deploying by doing:
> > class common::nagios {
> >   $nrpe_version = "01.1-10"
> >   package { "nrpe_custom": ensure => $nrpe_version }
> > }
> >
> > The logs show that there was a problem updating(actually downgrading)
> > but does not give me a clue of what might be going wrong:
> > Dec 19 00:38:25 puppetclient puppetd[3759]:
> > (//Node[puppetclient.example.com
> > <http://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/test/classes/common.pp:61
> >
> > If on the client machine I attempt to downgrade via yum downgrade
> > nrpe_custom-01.1, the package get's downgraded correctly. I had the
> > understanding that package yum is versionable and I should be able to
> > do this kind of changes.
> >
> > Any suggestion that could help to solve this.
> >
> > Thanks
> > --
> > Tony
> >
> > --
> >
> > 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
> "Puppe

[Puppet Users] Downgrade package via yum

[Tony G.]

Hi,

On our organization we have custom npre packages distributed via yum, few
days ago a new test package was updated in the repository and new nodes
installed this version, the code looked like this:

class common::nagios {
  package { "nrpe_custom": ensure => "installed" }
}

To attempt to fix it I wanted to take control of which version we are
deploying by doing:
class common::nagios {
  $nrpe_version = "01.1-10"
  package { "nrpe_custom": ensure => $nrpe_version }
}

The logs show that there was a problem updating(actually downgrading) but
does not give me a clue of what might be going wrong:
Dec 19 00:38:25 puppetclient puppetd[3759]:
(//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/test/classes/common.pp:61

If on the client machine I attempt to downgrade via yum downgrade
nrpe_custom-01.1, the package get's downgraded correctly. I had the
understanding that package yum is versionable and I should be able to do
this kind of changes.

Any suggestion that could help to solve this.

Thanks
-- 
Tony

--

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] Timestamps need to be in sync on all puppetmasters?

[Tony G.]

I looked into the manifest and modules for any reference to manage the
checksum of /var/lib/puppet/lib/* and couldn't find anything.

Is there a way to find out where/why these directories are being
checksum'ed?

The state.yaml contains this info:

File[/var/lib/puppet/lib/puppet/parser/functions]:
  :checked: 2009-10-14 14:42:25.623364 +00:00
  :checksums:
:*ctime: "{mtime}Thu Oct 08 06:07:35 -0700 2009"*


That snippet corresponds to this log snippet:

Dec 11 20:18:00 puppetclient01 puppetd[31604]:
(/File[/var/lib/puppet/lib/puppet/parser/functions]/checksum) checksum
changed '*{mtime}Thu Oct 08 06:07:35 -0700 2009*' to '{mtime}Fri Dec 11
20:04:01 + 2009'


Thanks

On Tue, Dec 8, 2009 at 6:07 PM, Tony G.  wrote:

> The output is the same on both:
>
> puppetmaster:
> $ ruby -e 'puts Time.at(0)'
> Thu Jan 01 00:00:00 + 1970
>
> puppetclient:
>
> ruby -e 'puts Time.at(0)'
> Thu Jan 01 00:00:00 + 1970
>
> Then sometime else might be causing the checksum output.
>
> Thanks for the other suggestions and explanations.
>
>
> On Tue, Dec 8, 2009 at 5:59 PM, Silviu Paragina wrote:
>
>>  The output should give a clue if the timezone is wrong for ruby on the
>> client/server machine. If I use utc it will discard that info so it is:
>> ruby -e 'puts Time.at(0)'
>> and if all things are sane it should output
>> Thu Jan 01 00:00:00 +000 1970 (without +something or -something)
>> Not sure how much it can help, since there are a lot of other components
>> that could change the standard behavior depending on setup
>> (apache/nginx/passenger/mongrel etc)
>>
>>
>> Silviu
>>
>>
>> On 09.12.2009 03:53, Ohad Levy wrote:
>>
>> if you want utc, you should use:
>>
>> ruby -e 'puts Time.at(0).utc'
>>
>> cheers,
>> Ohad
>>
>>
>> On Wed, Dec 9, 2009 at 9:51 AM, Silviu Paragina wrote:
>>
>>>  Try this
>>> ruby -e 'puts Time.at(0)'
>>> In case ruby treats timezones different from how it should (how I think
>>> it should actually)
>>>
>>>
>>> Silviu
>>>
>>>
>>> On 09.12.2009 03:21, Tony G. wrote:
>>>
>>> Hi,
>>>
>>> They are supposed to have GMT:
>>> puppetmaster:
>>> $ date
>>> Wed Dec  9 00:59:02 *GMT* 2009
>>> puppetclient:
>>> $ date
>>> Wed Dec  9 00:58:59 *GMT* 2009
>>>
>>> But digging more I found this:
>>> puppetmaster:
>>> $ cat /etc/sysconfig/clock
>>> *ZONE="GMT"*
>>> *UTC=false*
>>> ARC=false
>>>
>>> puppetclient:
>>> $ cat /etc/sysconfig/clock
>>> *ZONE="US/Pacific"*
>>> *UTC=true*
>>> ARC=false
>>>
>>>
>>> But the timezone file in */etc/localtime* is the same on them:
>>> md5sum /usr/share/zoneinfo/* 2>/dev/null|grep $(md5sum /etc/localtime|cut
>>> -d" " -f1)
>>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT
>>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT0
>>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT-0
>>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT+0
>>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/Greenwich
>>>
>>> Could the /etc/sysconfig/clock file cause this?
>>>
>>> Thanks!
>>>
>>> On Tue, Dec 8, 2009 at 1:50 PM, Silviu Paragina wrote:
>>>
>>>> The log you posted looks like a bad date/time timezone conversion, are
>>>> all the clients/puppetmasters on the same timezone?
>>>> Notice that the dates are actually identical but one is in utc the other
>>>> US eastern (I think).
>>>>
>>>>
>>>> Silviu
>>>>
>>>> On 08.12.2009 22:43, Digant C Kasundra wrote:
>>>> > This is similar to what I'm talking about.  It looks like this
>>>> resource is specifically using modified time as the "checksum."  Is this
>>>> something you've configured or is this a default of those directories as
>>>> something internal to puppet.
>>>> >
>>>> > - "Tony G."  wrote:
>>>> >
>>>> >
>>>> >> I've see this very often but not sure if this is the issue you are
>>>> >> describing:
>>>> >>
>>>> >> Dec 4 03:36:19 puppetclient puppetd[16163]:
>>>> >> (/File[/var/

Re: [Puppet Users] Timestamps need to be in sync on all puppetmasters?

[Tony G.]

The output is the same on both:

puppetmaster:
$ ruby -e 'puts Time.at(0)'
Thu Jan 01 00:00:00 + 1970

puppetclient:
ruby -e 'puts Time.at(0)'
Thu Jan 01 00:00:00 + 1970

Then sometime else might be causing the checksum output.

Thanks for the other suggestions and explanations.

On Tue, Dec 8, 2009 at 5:59 PM, Silviu Paragina  wrote:

>  The output should give a clue if the timezone is wrong for ruby on the
> client/server machine. If I use utc it will discard that info so it is:
> ruby -e 'puts Time.at(0)'
> and if all things are sane it should output
> Thu Jan 01 00:00:00 +000 1970 (without +something or -something)
> Not sure how much it can help, since there are a lot of other components
> that could change the standard behavior depending on setup
> (apache/nginx/passenger/mongrel etc)
>
>
> Silviu
>
>
> On 09.12.2009 03:53, Ohad Levy wrote:
>
> if you want utc, you should use:
>
> ruby -e 'puts Time.at(0).utc'
>
> cheers,
> Ohad
>
>
> On Wed, Dec 9, 2009 at 9:51 AM, Silviu Paragina wrote:
>
>>  Try this
>> ruby -e 'puts Time.at(0)'
>> In case ruby treats timezones different from how it should (how I think it
>> should actually)
>>
>>
>> Silviu
>>
>>
>> On 09.12.2009 03:21, Tony G. wrote:
>>
>> Hi,
>>
>> They are supposed to have GMT:
>> puppetmaster:
>> $ date
>> Wed Dec  9 00:59:02 *GMT* 2009
>> puppetclient:
>> $ date
>> Wed Dec  9 00:58:59 *GMT* 2009
>>
>> But digging more I found this:
>> puppetmaster:
>> $ cat /etc/sysconfig/clock
>> *ZONE="GMT"*
>> *UTC=false*
>> ARC=false
>>
>> puppetclient:
>> $ cat /etc/sysconfig/clock
>> *ZONE="US/Pacific"*
>> *UTC=true*
>> ARC=false
>>
>>
>> But the timezone file in */etc/localtime* is the same on them:
>> md5sum /usr/share/zoneinfo/* 2>/dev/null|grep $(md5sum /etc/localtime|cut
>> -d" " -f1)
>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT
>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT0
>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT-0
>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT+0
>> fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/Greenwich
>>
>> Could the /etc/sysconfig/clock file cause this?
>>
>> Thanks!
>>
>> On Tue, Dec 8, 2009 at 1:50 PM, Silviu Paragina wrote:
>>
>>> The log you posted looks like a bad date/time timezone conversion, are
>>> all the clients/puppetmasters on the same timezone?
>>> Notice that the dates are actually identical but one is in utc the other
>>> US eastern (I think).
>>>
>>>
>>> Silviu
>>>
>>> On 08.12.2009 22:43, Digant C Kasundra wrote:
>>> > This is similar to what I'm talking about.  It looks like this resource
>>> is specifically using modified time as the "checksum."  Is this something
>>> you've configured or is this a default of those directories as something
>>> internal to puppet.
>>> >
>>> > - "Tony G."  wrote:
>>> >
>>> >
>>> >> I've see this very often but not sure if this is the issue you are
>>> >> describing:
>>> >>
>>> >> Dec 4 03:36:19 puppetclient puppetd[16163]:
>>> >> (/File[/var/lib/puppet/lib]/checksum) checksum changed '{mtime}Fri Oct
>>> >> 30 11:05:32 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 + 2009'
>>> >> Dec 4 03:36:20 puppetclient puppetd[16163]:
>>> >> (/File[/var/lib/puppet/lib/puppet]/checksum) checksum changed
>>> >> '{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
>>> >> + 2009'
>>> >> Dec 4 03:36:21 puppetclient puppetd[16163]:
>>> >> (/File[/var/lib/puppet/lib/puppet/type]/checksum) checksum changed
>>> >> '{mtime}Fri Oct 30 11:05:49 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
>>> >> + 2009'
>>> >> Dec 4 03:36:24 puppetclient puppetd[16163]:
>>> >> (/File[/var/lib/puppet/lib/puppet/parser]/checksum) checksum changed
>>> >> '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
>>> >> + 2009'
>>> >> Dec 4 03:36:29 puppetclient puppetd[16163]:
>>> >> (/File[/var/lib/puppet/lib/puppet/parser/functions]/checksum) checksum
>>> >

Re: [Puppet Users] Timestamps need to be in sync on all puppetmasters?

[Tony G.]

Hi,

They are supposed to have GMT:
puppetmaster:
$ date
Wed Dec  9 00:59:02 *GMT* 2009
puppetclient:
$ date
Wed Dec  9 00:58:59 *GMT* 2009

But digging more I found this:
puppetmaster:
$ cat /etc/sysconfig/clock
*ZONE="GMT"*
*UTC=false*
ARC=false

puppetclient:
$ cat /etc/sysconfig/clock
*ZONE="US/Pacific"*
*UTC=true*
ARC=false


But the timezone file in */etc/localtime* is the same on them:
md5sum /usr/share/zoneinfo/* 2>/dev/null|grep $(md5sum /etc/localtime|cut
-d" " -f1)
fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT
fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT0
fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT-0
fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/GMT+0
fcccbcf95c718cf2fdee557763e460be  /usr/share/zoneinfo/Greenwich

Could the /etc/sysconfig/clock file cause this?

Thanks!

On Tue, Dec 8, 2009 at 1:50 PM, Silviu Paragina  wrote:

> The log you posted looks like a bad date/time timezone conversion, are
> all the clients/puppetmasters on the same timezone?
> Notice that the dates are actually identical but one is in utc the other
> US eastern (I think).
>
>
> Silviu
>
> On 08.12.2009 22:43, Digant C Kasundra wrote:
> > This is similar to what I'm talking about.  It looks like this resource
> is specifically using modified time as the "checksum."  Is this something
> you've configured or is this a default of those directories as something
> internal to puppet.
> >
> > - "Tony G."  wrote:
> >
> >
> >> I've see this very often but not sure if this is the issue you are
> >> describing:
> >>
> >> Dec 4 03:36:19 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib]/checksum) checksum changed '{mtime}Fri Oct
> >> 30 11:05:32 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 + 2009'
> >> Dec 4 03:36:20 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet]/checksum) checksum changed
> >> '{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
> >> + 2009'
> >> Dec 4 03:36:21 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/type]/checksum) checksum changed
> >> '{mtime}Fri Oct 30 11:05:49 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
> >> + 2009'
> >> Dec 4 03:36:24 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/parser]/checksum) checksum changed
> >> '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
> >> + 2009'
> >> Dec 4 03:36:29 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/parser/functions]/checksum) checksum
> >> changed '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30
> >> 18:05:50 + 2009'
> >> Dec 4 03:36:29 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/provider]/checksum) checksum changed
> >> '{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:48
> >> + 2009'
> >> Dec 4 03:36:36 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/provider/package]/checksum) checksum
> >> changed '{mtime}Fri Oct 30 11:05:35 -0700 2009' to '{mtime}Fri Oct 30
> >> 18:05:48 + 2009'
> >> Dec 4 03:37:00 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/provider/sysctl]/checksum) checksum
> >> changed '{mtime}Fri Oct 30 11:05:48 -0700 2009' to '{mtime}Fri Oct 30
> >> 18:05:49 + 2009'
> >> Dec 4 03:37:01 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/provider/volumegroup]/checksum)
> >> checksum changed '{mtime}Fri Oct 30 11:05:34 -0700 2009' to
> >> '{mtime}Fri Oct 30 18:05:35 + 2009'
> >> Dec 4 03:37:06 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/provider/logicalvolume]/checksum)
> >> checksum changed '{mtime}Fri Oct 30 11:05:33 -0700 2009' to
> >> '{mtime}Fri Oct 30 18:05:34 + 2009'
> >> Dec 4 03:37:07 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/puppet/provider/physicalvolume]/checksum)
> >> checksum changed '{mtime}Fri Oct 30 11:05:34 -0700 2009' to
> >> '{mtime}Fri Oct 30 18:05:34 + 2009'
> >> Dec 4 03:37:15 puppetclient puppetd[16163]:
> >> (/File[/var/lib/puppet/lib/facter]/checksum) checksum changed
> >> '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Tue Nov 03 08:0

Re: [Puppet Users] Timestamps need to be in sync on all puppetmasters?

[Tony G.]

I've see this very often but not sure if this is the issue you are
describing:

Dec  4 03:36:19 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib]/checksum) checksum changed '{mtime}Fri Oct 30
11:05:32 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 + 2009'
Dec  4 03:36:20 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet]/checksum) checksum changed '{mtime}Fri
Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 + 2009'
Dec  4 03:36:21 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/type]/checksum) checksum changed
'{mtime}Fri Oct 30 11:05:49 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 +
2009'
Dec  4 03:36:24 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/parser]/checksum) checksum changed
'{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 +
2009'
Dec  4 03:36:29 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/parser/functions]/checksum) checksum
changed '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30
18:05:50 + 2009'
Dec  4 03:36:29 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/provider]/checksum) checksum changed
'{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:48 +
2009'
Dec  4 03:36:36 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/provider/package]/checksum) checksum
changed '{mtime}Fri Oct 30 11:05:35 -0700 2009' to '{mtime}Fri Oct 30
18:05:48 + 2009'
Dec  4 03:37:00 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/provider/sysctl]/checksum) checksum
changed '{mtime}Fri Oct 30 11:05:48 -0700 2009' to '{mtime}Fri Oct 30
18:05:49 + 2009'
Dec  4 03:37:01 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/provider/volumegroup]/checksum) checksum
changed '{mtime}Fri Oct 30 11:05:34 -0700 2009' to '{mtime}Fri Oct 30
18:05:35 + 2009'
Dec  4 03:37:06 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/provider/logicalvolume]/checksum) checksum
changed '{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30
18:05:34 + 2009'
Dec  4 03:37:07 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/puppet/provider/physicalvolume]/checksum)
checksum changed '{mtime}Fri Oct 30 11:05:34 -0700 2009' to '{mtime}Fri Oct
30 18:05:34 + 2009'
Dec  4 03:37:15 puppetclient puppetd[16163]:
(/File[/var/lib/puppet/lib/facter]/checksum) checksum changed '{mtime}Fri
Oct 30 11:05:50 -0700 2009' to '{mtime}Tue Nov 03 08:00:05 + 2009'
Dec  4 03:37:33 puppetclient puppetd[16163]: Starting catalog run
Dec  4 03:39:46 puppetclient puppetd[16163]: Finished catalog run in 133.44
seconds

 I've not been able to look on what is causing it, I belive it's coming
after we change the environment the puppetclient is pointing to, although we
use the same puppetmaster to use different environments(dev, prod).

Thoughts?

Thanks

On Thu, Dec 3, 2009 at 2:31 PM, Digant C Kasundra wrote:

> Hey guys,
>
> We're using multiple puppetmasters and I could have sworn I had uncovered
> an issue once where if a file had a different timestamp on two
> puppetmasters, clients would keep replacing the file depending on which
> puppetmaster they talked to because the clients thought the files were
> changing.  But I've been unable to reproduce this problem.  Is this only an
> issue in certain situations?  We're not using the checksum parameter to tell
> file resources to use timestamps and the type references seems to indicate
> that the default is md5 but I could have sworn I uncovered the
> aforementioned issue before but cannot for the life of me replicate it now.
>  Anyone else know what I'm talking about?
>
>
> --
> Digant C Kasundra 
> Technical Lead, ITS Unix Systems and Applications, Stanford University
>
> --
>
> 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.
>
>
>


-- 
Tony

--

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.