Issue #2472 has been updated by Nigel Kersten.

• Status changed from Accepted to Ready for Checkin

http://github.com/nigelkersten/puppet/tree/tickets/0.25.x/2472
http://github.com/nigelkersten/puppet/commit/970e27912f6c1bc27821d4528e642e39fa5af4e6

Bug #2472: ralsh doesn't load facts from Facter automatically.

• Author: Nigel Kersten
• Status: Ready for Checkin
• Priority: Normal
• Assigned to: Nigel Kersten
• Category:
• Target version:
• Complexity: Unknown
• Affected version: 0.25.0
• Keywords:

Regression of bug: #1962

since moving to the application layer for ralsh in 0.25.0, we no longer have access to Facter facts when ralsh is invoked, posing a problem for providers that rely upon Facter values.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2464 has been updated by Luke Kanies.

If you want Puppet.warning to work, just modify the logging subsystem to do something like:

if defined?(Puppet::Type) and ...existing code... end

I.e., just check whether the class is defined yet.

Bug #2464: Puppet 0.25.x clients ignore the --reportserver option.

• Author: Nigel Kersten
• Status: Accepted
• Priority: High
• Assigned to: Nigel Kersten
• Category:
• Target version: 0.25.0
• Complexity: Unknown
• Affected version: 0.25.0
• Keywords:

Puppet 0.25.x clients don't look at the reportserver option at all, and simply send reports to the server no matter what.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2463 has been updated by Luke Kanies.

• Status changed from Unreviewed to Duplicate

We're not modifying 0.24.x at this point to be compatible with newer versions of Rails. If someone really needs a solution to this, please either provide a patch or contact us privately.

Bug #2463: Puppet 0.24.8 does not work with Rails 2.3.2

• Author: Evan Borgstrom
• Status: Duplicate
• Priority: Normal
• Assigned to:
• Category: Rails
• Target version:
• Complexity: Unknown
• Affected version: 0.24.8
• Keywords:

The system is a Gentoo system with Ruby 1.8.7. When running puppetmasterd with --trace the following is produced when it tries to initialize rails.

Downgrading to Rails 2.2.2 fixed the issue.

err: Rails is missing; cannot store configurations /usr/lib64/ruby/site_ruby/1.8/puppet/parser/interpreter.rb:43:in `initialize' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:80:in `new' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:80:in `create_interpreter' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:37:in `interpreter' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in `compile' /usr/lib64/ruby/site_ruby/1.8/puppet/util.rb:180:in `benchmark' /usr/lib64/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/core_ext/benchmark.rb:10:in `realtime' /usr/lib64/ruby/site_ruby/1.8/puppet/util.rb:179:in `benchmark' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:66:in `compile' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:21:in `find' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:210:in`find' /usr/lib64/ruby/site_ruby/1.8/puppet/indirector.rb:49:in `find' /usr/lib64/ruby/site_ruby/1.8/puppet/network/handler/master.rb:65:in `getconfig' /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `to_proc' /usr/lib64/ruby/site_ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `call' /usr/lib64/ruby/site_ruby/1.8/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /usr/lib64/ruby/site_ruby/1.8/puppet/network/xmlrpc/processor.rb:85:in `setup_processor' /usr/lib64/ruby/1.8/xmlrpc/server.rb:338:in `call' /usr/lib64/ruby/1.8/xmlrpc/server.rb:338:in `dispatch' /usr/lib64/ruby/1.8/xmlrpc/server.rb:325:in `each' /usr/lib64/ruby/1.8/xmlrpc/server.rb:325:in `dispatch' /usr/lib64/ruby/1.8/xmlrpc/server.rb:368:in `call_method' /usr/lib64/ruby/1.8/xmlrpc/server.rb:380:in `handle' /usr/lib64/ruby/site_ruby/1.8/puppet/network/xmlrpc/processor.rb:44:in `process' /usr/lib64/ruby/site_ruby/1.8/puppet/network/xmlrpc/webrick_servlet.rb:68:in `service' /usr/lib64/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/lib64/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/lib64/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/lib64/ruby/1.8/webrick/server.rb:162:in `start' /usr/lib64/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/lib64/ruby/1.8/webrick/server.rb:95:in `start' /usr/lib64/ruby/1.8/webrick/server.rb:92:in `each' /usr/lib64/ruby/1.8/webrick/server.rb:92:in `start' /usr/lib64/ruby/1.8/webrick/server.rb:23:in `start' /usr/lib64/ruby/1.8/webrick/server.rb:82:in `start' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:293:in `start' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:144:in `newthread' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:143:in `initialize' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:143:in `new' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:143:in `newthread' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:291:in `start' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:290:in `each' /usr/lib64/ruby/site_ruby/1.8/puppet.rb:290:in `start' /usr/bin/puppetmasterd:285 err: Rails is missing; cannot store configurations

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2464 has been updated by Nigel Kersten.

yeah, it seems more complicated than that though.

There seems to be more initialization that hasn't occurred at the config parsing stage.

Bug #2464: Puppet 0.25.x clients ignore the --reportserver option.

• Author: Nigel Kersten
• Status: Accepted
• Priority: High
• Assigned to: Nigel Kersten
• Category:
• Target version: 0.25.0
• Complexity: Unknown
• Affected version: 0.25.0
• Keywords:

Puppet 0.25.x clients don't look at the reportserver option at all, and simply send reports to the server no matter what.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2462 has been updated by Luke Kanies.

So what do you recommend as the actual behaviour here? Should the minute just default to '0' or something?

And I'd certainly accept a patch that treated '*' as absent, but that seems like mostly a documentation problem.

Bug #2462: cron resources default behaviour with no periods seems potentially dangerous

• Author: Simon Mudd
• Status: Needs design decision
• Priority: Normal
• Assigned to:
• Category: cron
• Target version:
• Complexity: Unknown
• Affected version: 0.24.8
• Keywords:

As per http://reductivelabs.com/trac/puppet/wiki/TypeReference#cron

"cron

Installs and manages cron jobs. All fields except the command and the user are optional, although specifying no periodic fields would result in the command being executed every minute. While the name of the cron job is not part of the actual job, it is used by Puppet to store and retrieve it."

I think this behaviour is dangerous as it means that default behaviour is a to run a minutely job. That means that if the period fields are not specified by mistake the effect will be to generate very frequent cron activity.

I used to configure my cron jobs like this:

cron {
'minutely_script':
command => '/path/to/minutely/script',
ensure => present,
hour => '*',
minute => '*',
}

However this generates extra logging, making it look like the configuration is incorrect (or not expected):

Wed Jul 29 15:45:17 +0200 2009 //Node[dc01mdb-01.mydomain.com]/s_db/s_db::config/Cron[db_config]/hour (notice): defined 'hour' as '*'
Wed Jul 29 15:45:19 +0200 2009 //Node[dc01mdb-01.mydomain.com]/s_db/s_db::cron/Cron[log_processlist]/minute (notice): defined 'minute' as '*'
Wed Jul 29 15:45:19 +0200 2009 //Node[dc01mdb-01.mydomain.com]/s_db/s_db::cron/Cron[log_processlist]/hour (notice): defined 'hour' as '*'

From my point of view the correct cron entries were being created.

A colleague of mine said:

"Nasty, if you forget the timings, you get the worst case of the most frequent run of your job. I would make the arguments required and not optional. Cron jobs that need to run every minute are rare in the real world so that shouldn't be the default."

I tend to agree. I would prefer that it's possible define '*' without getting special notifications, and perhaps even that if no period fields are specified that a warning is generated.

Also the documentation should say that it's possible to specify '*' for "all values in that period".

We are using a custom built rpm based on puppet-0.24.8-1 on centos4 and 5.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2469 has been updated by Luke Kanies.

• Status changed from Code Insufficient to Tests Insufficient

I like this much better; having a nil path makes sense. Are there existing tests for the filebucket type? My assumption is no. Could you add a couple of simple tests just to verify the settings propagate correctly?

Feature #2469: support filebucket to use the puppetmaster as default remote server

• Author: Till Maas
• Status: Tests Insufficient
• Priority: Normal
• Assigned to:
• Category: file
• Target version:
• Complexity: Unknown
• Affected version: 0.24.8
• Keywords:

The patch I attach adds the parameter "remote" to the filebucket type, which makes it possible to use the puppetmaster that is specified in the config as the default puppetmaster.

It should not disrupt existing configurations, but allows to use the filebucket from the remote puppetmaster server by default with this manifest:

filebucket { main: remote => true }

A more elegant solution would probably be to make the values of Puppet[:server] available as a fact/pre defined variable for the client, but I do not now how to do this and the only hints for predefined variables (servername, serverip) seem to be generated at the host. So if it is easily possible to create such a variable, e.g. $puppter_config_server that has the value of Puppet[:server] for puppetd.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2469 has been updated by Luke Kanies.

And, um, I have no idea on the problem with 'rake mail_patches'....

Feature #2469: support filebucket to use the puppetmaster as default remote server

• Author: Till Maas
• Status: Tests Insufficient
• Priority: Normal
• Assigned to:
• Category: file
• Target version:
• Complexity: Unknown
• Affected version: 0.24.8
• Keywords:

The patch I attach adds the parameter "remote" to the filebucket type, which makes it possible to use the puppetmaster that is specified in the config as the default puppetmaster.

It should not disrupt existing configurations, but allows to use the filebucket from the remote puppetmaster server by default with this manifest:

filebucket { main: remote => true }

A more elegant solution would probably be to make the values of Puppet[:server] available as a fact/pre defined variable for the client, but I do not now how to do this and the only hints for predefined variables (servername, serverip) seem to be generated at the host. So if it is easily possible to create such a variable, e.g. $puppter_config_server that has the value of Puppet[:server] for puppetd.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2470 has been updated by Luke Kanies.

• Category set to library
• Status changed from Unreviewed to Accepted

Bug #2470: interfaces fact has duplicate entries under Solaris

• Author: Nicolas Szalay
• Status: Accepted
• Priority: Normal
• Assigned to:
• Category: library
• Target version:
• Complexity: Unknown
• Keywords:

Running OpenSolaris and facter 1.5.6, the "interfaces" fact get lo0 2 times :

[solarisfiler:~] facter interfaces lo0,e1000g1,lo0

This is probably related with ifconfig showing lo0 in ipv4 & ipv6 :

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 e1000g1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 2 inet XXXXXXX netmask XXXXXXX broadcast XXXXXXXX lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128

/query nico if you need more informations

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2377 has been updated by Luke Kanies.

• Status changed from Ready for Testing to Ready for Checkin
• Assigned to changed from Brice Figureau to James Turnbull

Fixed in the tickets/master/2377 branch in my repo.

Feature #2377: Add a message in the client error handler if the error comes from the master

• Author: Brice Figureau
• Status: Ready for Checkin
• Priority: Normal
• Assigned to: James Turnbull
• Category: plumbing
• Target version: 0.25.0
• Complexity: Trivial
• Affected version: 0.24.8
• Keywords:

The idea is to reduce the number of round-trip in tickets and inform the user that the error originated in the master and not in the client.

Something along the line of:

here the original error messge
This error has occurred on the puppetmaster. If you want to get more useful information,
please have a look in your puppetmaster logs.
Running your puppetmaster with --trace will help the developer locate and fix the issue.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Issue #2473 has been updated by Luke Kanies.

• Status changed from Unreviewed to Rejected

These are pretty different kinds of information, generated from completely different sources.

See #2441 for a way to start linking these; the timestamp of data creation isn't a very good one.

Feature #2473: report time and yaml/node/HOST.yaml time should be the same

• Author: Dan Bode
• Status: Rejected
• Priority: Low
• Assigned to:
• Category:
• Target version:
• Complexity: Unknown
• Affected version: 0.24.8
• Keywords:

I was expecting that the report time would match with the node time. It could be useful at times to have a way of uniquely associating a report with a node.(especially for testing)

below is a code example:

node_file = Puppet[:yamldir]+"/node/"+client+".yaml" props = YAML::load_file( node_file ) puts "node and report time did not match: [#{ <at> node_time.to_s}] [#{self.time.to_s}]" unless <at> node_time.eql? self.time

node and report time did not match: [Fri Jul 31 09:24:36 +0200 2009] [Fri Jul 31 09:24:57 +0200 2009]

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To post to this group, send email to puppet-bugs <at> googlegroups.com
To unsubscribe from this group, send email to puppet-bugs+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---