Issue #2681 has been updated by James Turnbull.

• Status changed from Ready for Testing to Code Insufficient
• Assigned to set to Markus Roberts

Bug #2681: "Duplicate generated resource;skipping" for each managed resource

• Author: Marc Fournier
• Status: Code Insufficient
• Priority: Normal
• Assigned to: Markus Roberts
• Category: plumbing
• Target version: 0.25.1
• Affected version: 0.25.1rc1
• Keywords:
• Branch: http://github.com/MarkusQ/puppet/tree/ticket/master/2681

I've noticed a new warning emitted on clients with 0.25.0 or 0.25.1rc1:

info: /Host[localhost.localdomain]: Duplicate generated resource;skipping info: /Host[test.example.com]: Duplicate generated resource; skipping

This message comes from lib/puppet/transaction.rb:362 in
generate_additional_resources()

The manifest on the server side:

node 'test.example.com' { resources { "host": purge => true, } host { "$fqdn": ip => $ipaddress, alias => $hostname, } host { "localhost.localdomain": ip => "127.0.0.1", alias => "localhost", } }

This happens for every resource managed by "resource".

NB: this warning doesn't occur when running puppet against a file containing the same resources. It only happens when puppetd fetches them from the puppetmaster.

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 #2686 has been updated by Markus Roberts.

This is a serialization issue; it only happens with json.

Bug #2686: metaparameters cause failures with ActiveRecord >= 2.3.3

• Author: Darrell Fuhriman
• Status: Accepted
• Priority: Normal
• Assigned to: Markus Roberts
• Category: plumbing
• Target version: 0.25.1
• Affected version: 0.25.1rc1
• Keywords:
• Branch:

In testing for the update to 0.25.x, I ran across a problem where the following error was generated on metaparameters:

err: Could not run Puppet configuration client: Parameter notify failed: No title provided and title '{"title"=>"smb", "type"=>"Service", "builtin_type"=>nil}' is not a valid resource reference

(see posting from me on puppet-users).

i stuck some debugging code in Puppet::Resource::Reference#initialize

When it works, it gives:
argtype: "Service[smb]", argtitle: , class: String, is_a? false

On AR >=2.3.3, I get something like:
argtype: {"title"=>"/home/projectdx/projectdx-pdxrails", "type"=>"File", "builtin_type"=>nil}, argtitle: , class: Hash, is_a? false

This seems to be the case regardless of whether or not storedconfig is set to true.

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 #2686 has been updated by Markus Roberts.

And here's the new in active support 2.3.3 code change that's breaking it:

+# Hack to load json gem first so we can overwrite its to_json. +begin + require 'json' +rescue LoadError +end +

Oh sweet irony.

Bug #2686: metaparameters cause failures with ActiveRecord >= 2.3.3

• Author: Darrell Fuhriman
• Status: Accepted
• Priority: Normal
• Assigned to: Markus Roberts
• Category: plumbing
• Target version: 0.25.1
• Affected version: 0.25.1rc1
• Keywords:
• Branch:

In testing for the update to 0.25.x, I ran across a problem where the following error was generated on metaparameters:

err: Could not run Puppet configuration client: Parameter notify failed: No title provided and title '{"title"=>"smb", "type"=>"Service", "builtin_type"=>nil}' is not a valid resource reference

(see posting from me on puppet-users).

i stuck some debugging code in Puppet::Resource::Reference#initialize

When it works, it gives:
argtype: "Service[smb]", argtitle: , class: String, is_a? false

On AR >=2.3.3, I get something like:
argtype: {"title"=>"/home/projectdx/projectdx-pdxrails", "type"=>"File", "builtin_type"=>nil}, argtitle: , class: Hash, is_a? false

This seems to be the case regardless of whether or not storedconfig is set to true.

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 #2690 has been reported by Klavs Klavsen.

Bug #2690: puppet insists on /etc/puppet/manifests being a folder

• Author: Klavs Klavsen
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category:
• Target version:
• Affected version: 0.24.8
• Keywords:
• Branch:

I have puppet files in svn - but because there's also files in the top-dir /etc/puppet - I have to have the entire dir in svn.

However I also have differing versions of /etc/puppet/puppet.conf - so that file can't and IMHo shouldn't be in svn.

I moved /etc/puppet to /usr/src/puppet-svn and symlinked the relevant files and folders to /etc/puppet to fix the problem of svn status complaining about the unknown /etc/puppet/puppet.conf file.

Whenever I restart puppetmaster it removes the symlink /etc/puppet/manifests (pointing to /usr/src/puppet-svn/manifests) - even if I have set the symlink immutable :(

As I see no reason for puppetmaster to need to control if manifests folder is a folder, or a symlink to one - I consider this a bug - although a small one :)

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 #2691 has been reported by Marc Fournier.

Bug #2691: "Could not retrieve catalog: HTTP-Error: 500 Internal Server Error" with tagged exported resources

• Author: Marc Fournier
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category:
• Target version:
• Affected version: 0.25.1rc1
• Keywords:
• Branch:

The problem happens with this sort of manifest (in fact, this simple example works fine):

node a { <at> <at> file { "/tmp/foo": content => "fjskfjs\n", tag => "foofile", } } node b { File <<| tag == 'foofile' |>> }

In my case, I have a about 20 nodes, each one having:

<at> <at> nagios_host { $fqdn: tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "a": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "b": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "c": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "d": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "e": tag => "nagiosserver.domain.tld", ... }

I suspect the problem occurs when many exported resources are involved (if 20x5 can be considered many).

The problem happens when running puppet on a node containing:

Nagios_host <<| tag == "nagiosserver.domain.tld" |>> Nagios_service <<| tag == nagiosserver.domain.tld" |>>

On the puppetmaster, one ruby process consumes 100% CPU during a few minutes, then the client says:

err: Could not call puppetmaster.getconfig: #<RuntimeError: HTTP-Error: 500 Internal Server Error> err: Could not retrieve catalog: HTTP-Error: 500 Internal Server Error

the ruby process continues running at 100%, and after a while we get this backtrace:

[ pid=3338 file=ext/apache2/Hooks.cpp:547 time=2009-10-01 11:16:46.189 ]: Backend process 3465 did not return a valid HTTP response. It returned no data. *** Exception Errno::EPIPE in Passenger RequestHandler (Broken pipe) (process 3465): from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/request_handler.rb:83:in `write' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/request_handler.rb:83:in `process_request' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_request_handler.rb:203:in `main_loop' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:110:in `run' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:67:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/utils.rb:181:in `safe_fork' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:60:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:45:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:158:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:282:in `handle_spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `__send__' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `main_loop' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:187:in `start_synchronously' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/bin/passenger-spawn-server:61

The problem can be produced with 0.24.8 and 0.25.0 clients, and 0.25.0 as well as 0.25.1rc1 server, with passenger and these gems installed:

activerecord (2.3.2)
activesupport (2.3.2)
fastthread (1.0.7)
passenger (2.2.2)
rack (1.0.0)
rake (0.8.7)

It should be noted that this works fine:

Nagios_host <<| |>> Nagios_service <<| |>>

I've also noticed the following error from time to time on 0.25.0. But I'm unable to reproduce it, and never seen it with 0.25.1rc1, so I'm not sure it's related:

/srv/puppet/lib/puppet/util/settings/file_setting.rb:19:in `group=' /srv/puppet/lib/puppet/util/settings/setting.rb:44:in `send' /srv/puppet/lib/puppet/util/settings/setting.rb:44:in `initialize' /srv/puppet/lib/puppet/util/settings/setting.rb:38:in `each' /srv/puppet/lib/puppet/util/settings/setting.rb:38:in `initialize' /srv/puppet/lib/puppet/util/settings.rb:398:in `new' /srv/puppet/lib/puppet/util/settings.rb:398:in `newsetting' /srv/puppet/lib/puppet/util/settings.rb:533:in `setdefaults' /srv/puppet/lib/puppet/util/settings.rb:518:in `each' /srv/puppet/lib/puppet/util/settings.rb:518:in `setdefaults' /srv/puppet/lib/puppet/reports/store.rb:15:in `mkclientdir' /srv/puppet/lib/puppet/reports/store.rb:35:in `process' /srv/puppet/lib/puppet/network/handler/report.rb:66:in `process' /srv/puppet/lib/puppet/network/handler/report.rb:59:in `each' /srv/puppet/lib/puppet/network/handler/report.rb:59:in `process' /srv/puppet/lib/puppet/network/handler/report.rb:33:in `report' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `to_proc' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:52:in `call' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:85:in `setup_processor' /usr/lib/ruby/1.8/xmlrpc/server.rb:336:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:336:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:323:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:323:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:366:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:378:in `handle' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:44:in `process' /srv/puppet/lib/puppet/network/http/rack/xmlrpc.rb:35:in `process' /srv/puppet/lib/puppet/network/http/rack.rb:48:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/request_handler.rb:81:in `process_request' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_request_handler.rb:203:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:110:in `run' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:67:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/utils.rb:181:in `safe_fork' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:60:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:45:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:158:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:282:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `__send__' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:187:in `start_synchronously' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/bin/passenger-spawn-server:61

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 #2691 has been updated by Marc Fournier.

I've tried running the puppetmasterd binary with "--no-daemonize --debug --trace" instead of with passenger, and the problem doesn't occur.

But I noticed that much more time is needed to compile the catalog on nodes where tagged exported resources are collected. It takes about 5 minutes to collect my ~100 tagged resources, where normal hosts usually need only 10-15 seconds to compile the catalog.

I suppose the error previously described are the consequence of some sort of timeout inside passenger or apache.

I have another server with 0.24.8 and passenger, with a node collecting about 300 tagged exported resources, and the catalog gets compiled as fast as on any other node.

Maybe this issue can be renamed something like "performance regression with tagged exported resources" ?

Bug #2691: "Could not retrieve catalog: HTTP-Error: 500 Internal Server Error" with tagged exported resources

• Author: Marc Fournier
• Status: Unreviewed
• Priority: Normal
• Assigned to:
• Category:
• Target version:
• Affected version: 0.25.1rc1
• Keywords:
• Branch:

The problem happens with this sort of manifest (in fact, this simple example works fine):

node a { <at> <at> file { "/tmp/foo": content => "fjskfjs\n", tag => "foofile", } } node b { File <<| tag == 'foofile' |>> }

In my case, I have a about 20 nodes, each one having:

<at> <at> nagios_host { $fqdn: tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "a": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "b": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "c": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "d": tag => "nagiosserver.domain.tld", ... } <at> <at> nagios_service { "e": tag => "nagiosserver.domain.tld", ... }

I suspect the problem occurs when many exported resources are involved (if 20x5 can be considered many).

The problem happens when running puppet on a node containing:

Nagios_host <<| tag == "nagiosserver.domain.tld" |>> Nagios_service <<| tag == nagiosserver.domain.tld" |>>

On the puppetmaster, one ruby process consumes 100% CPU during a few minutes, then the client says:

err: Could not call puppetmaster.getconfig: #<RuntimeError: HTTP-Error: 500 Internal Server Error> err: Could not retrieve catalog: HTTP-Error: 500 Internal Server Error

the ruby process continues running at 100%, and after a while we get this backtrace:

[ pid=3338 file=ext/apache2/Hooks.cpp:547 time=2009-10-01 11:16:46.189 ]: Backend process 3465 did not return a valid HTTP response. It returned no data. *** Exception Errno::EPIPE in Passenger RequestHandler (Broken pipe) (process 3465): from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/request_handler.rb:83:in `write' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/request_handler.rb:83:in `process_request' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_request_handler.rb:203:in `main_loop' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:110:in `run' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:67:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/utils.rb:181:in `safe_fork' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:60:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:45:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:158:in `spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:282:in `handle_spawn_application' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `__send__' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `main_loop' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:187:in `start_synchronously' from /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/bin/passenger-spawn-server:61

The problem can be produced with 0.24.8 and 0.25.0 clients, and 0.25.0 as well as 0.25.1rc1 server, with passenger and these gems installed:

activerecord (2.3.2)
activesupport (2.3.2)
fastthread (1.0.7)
passenger (2.2.2)
rack (1.0.0)
rake (0.8.7)

It should be noted that this works fine:

Nagios_host <<| |>> Nagios_service <<| |>>

I've also noticed the following error from time to time on 0.25.0. But I'm unable to reproduce it, and never seen it with 0.25.1rc1, so I'm not sure it's related:

/srv/puppet/lib/puppet/util/settings/file_setting.rb:19:in `group=' /srv/puppet/lib/puppet/util/settings/setting.rb:44:in `send' /srv/puppet/lib/puppet/util/settings/setting.rb:44:in `initialize' /srv/puppet/lib/puppet/util/settings/setting.rb:38:in `each' /srv/puppet/lib/puppet/util/settings/setting.rb:38:in `initialize' /srv/puppet/lib/puppet/util/settings.rb:398:in `new' /srv/puppet/lib/puppet/util/settings.rb:398:in `newsetting' /srv/puppet/lib/puppet/util/settings.rb:533:in `setdefaults' /srv/puppet/lib/puppet/util/settings.rb:518:in `each' /srv/puppet/lib/puppet/util/settings.rb:518:in `setdefaults' /srv/puppet/lib/puppet/reports/store.rb:15:in `mkclientdir' /srv/puppet/lib/puppet/reports/store.rb:35:in `process' /srv/puppet/lib/puppet/network/handler/report.rb:66:in `process' /srv/puppet/lib/puppet/network/handler/report.rb:59:in `each' /srv/puppet/lib/puppet/network/handler/report.rb:59:in `process' /srv/puppet/lib/puppet/network/handler/report.rb:33:in `report' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `to_proc' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:52:in `call' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:52:in `protect_service' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:85:in `setup_processor' /usr/lib/ruby/1.8/xmlrpc/server.rb:336:in `call' /usr/lib/ruby/1.8/xmlrpc/server.rb:336:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:323:in `each' /usr/lib/ruby/1.8/xmlrpc/server.rb:323:in `dispatch' /usr/lib/ruby/1.8/xmlrpc/server.rb:366:in `call_method' /usr/lib/ruby/1.8/xmlrpc/server.rb:378:in `handle' /srv/puppet/lib/puppet/network/xmlrpc/processor.rb:44:in `process' /srv/puppet/lib/puppet/network/http/rack/xmlrpc.rb:35:in `process' /srv/puppet/lib/puppet/network/http/rack.rb:48:in `call' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/request_handler.rb:81:in `process_request' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_request_handler.rb:203:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:110:in `run' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:67:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/utils.rb:181:in `safe_fork' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:60:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/rack/application_spawner.rb:45:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:158:in `spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/spawn_manager.rb:282:in `handle_spawn_application' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `__send__' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:337:in `main_loop' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/lib/phusion_passenger/abstract_server.rb:187:in `start_synchronously' /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/bin/passenger-spawn-server:61

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 #2690 has been updated by James Turnbull.

• Category set to server
• Status changed from Unreviewed to Needs design decision
• Assigned to set to Luke Kanies

I guess this is in the same broad scope as #2442. Luke?

Bug #2690: puppet insists on /etc/puppet/manifests being a folder

• Author: Klavs Klavsen
• Status: Needs design decision
• Priority: Normal
• Assigned to: Luke Kanies
• Category: server
• Target version:
• Affected version: 0.24.8
• Keywords:
• Branch:

I have puppet files in svn - but because there's also files in the top-dir /etc/puppet - I have to have the entire dir in svn.

However I also have differing versions of /etc/puppet/puppet.conf - so that file can't and IMHo shouldn't be in svn.

I moved /etc/puppet to /usr/src/puppet-svn and symlinked the relevant files and folders to /etc/puppet to fix the problem of svn status complaining about the unknown /etc/puppet/puppet.conf file.

Whenever I restart puppetmaster it removes the symlink /etc/puppet/manifests (pointing to /usr/src/puppet-svn/manifests) - even if I have set the symlink immutable :(

As I see no reason for puppetmaster to need to control if manifests folder is a folder, or a symlink to one - I consider this a bug - although a small one :)

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 #2689 has been updated by James Turnbull.

• Status changed from Unreviewed to Needs design decision
• Assigned to set to Markus Roberts

Bug #2689: Running puppet as non-root => getting rid of all those ownership warnings

• Author: Brian Ferris
• Status: Needs design decision
• Priority: Normal
• Assigned to: Markus Roberts
• Category: file
• Target version:
• Affected version: 0.25.1rc1
• Keywords:
• Branch:

I'm using puppet to manage configs on machines where I don't have root access. Whenever I use a File resource where the source is a puppet:// resource, I get tons of warnings when I run puppet that look like:

Cannot manage ownership unless running as root

True enough, I'm not running as root. However, these warnings seem to appear whether I omit the owner parameter or if I include the owner parameter (set to my current user account). I'm using something like:

file { "${my_target_directory}":
ensure => directory,
recurse => true,
source => "puppet://$puppet_server/path/to/source/dir"
}

Adding "owner => myUserId" doesn't help. Also, I've confirmed that file owner on the puppetmaster server already matches my user account. These warnings tend to pile up and make it difficult to see more informative messages from puppet about what has actually changed when
updating.

As a solution, I propose modifying the logic in lib/puppet/type/file/owner.rb, specifically the insync message. I propose moving the check for root access AFTER the check for ownership has concluded that something needs to be changed. This has the effect of only warning you about root access if an ownership change actually needs to be made. See the following code for an example, and also the supplied patch.

def insync?(current) if <at> should == nil return true end # <at> should.each do |value| if value =~ /^\d+$/ uid = Integer(value) elsif value.is_a?(String) fail "Could not find user %s" % value unless uid = uid(value) else uid = value end return true if uid == current end unless Puppet::Util::SUIDManager.uid == 0 warning "Cannot manage ownership unless running as root" return true end return false end

Note that I had to add a nil check as well, since I found some cases where the owner property was applied even when I didn't specifically mention owner in my recipe.

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 #2690 has been updated by Luke Kanies.

• Status changed from Needs design decision to Duplicate

Bug #2690: puppet insists on /etc/puppet/manifests being a folder

• Author: Klavs Klavsen
• Status: Duplicate
• Priority: Normal
• Assigned to: Luke Kanies
• Category: server
• Target version:
• Affected version: 0.24.8
• Keywords:
• Branch:

I have puppet files in svn - but because there's also files in the top-dir /etc/puppet - I have to have the entire dir in svn.

However I also have differing versions of /etc/puppet/puppet.conf - so that file can't and IMHo shouldn't be in svn.

I moved /etc/puppet to /usr/src/puppet-svn and symlinked the relevant files and folders to /etc/puppet to fix the problem of svn status complaining about the unknown /etc/puppet/puppet.conf file.

Whenever I restart puppetmaster it removes the symlink /etc/puppet/manifests (pointing to /usr/src/puppet-svn/manifests) - even if I have set the symlink immutable :(

As I see no reason for puppetmaster to need to control if manifests folder is a folder, or a symlink to one - I consider this a bug - although a small one :)

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 #1915 has been updated by Teyo Tyree.

• Keywords set to Problem #85

I have a workaround, but it's horrible.

SETUP:

1. ln -s foo bar
   run puppet on the following test.pp:
   $filename = "/Users/jbarratt/bar"
   file { "$filename":
   ensure => file,
   links => manage,
   replace => true,
   content => "well, crap.",
   force => true,
   }

And you fail on the error:

debug: //File[/Users/jbarratt/bar]/checksum: Initializing checksum hash
debug: //File[/Users/jbarratt/bar]/checksum: Not checksumming symlink
err: //File[/Users/jbarratt/bar]: Failed to retrieve current state of resource: Could not read /Users/jbarratt/bar: No such file or directory - /Users/jbarratt/bar
debug: Finishing transaction 16030800 with 0 changes

The workaround is to add an extra exec { }:

$filename = "/Users/jbarratt/bar"

exec { "uglyhack$filename":
command => "/bin/rm -f $filename",
onlyif => "/bin/test -L $filename",
}
file { "$filename":
ensure => file,
links => manage,
replace => true,
content => "well, crap.",
force => true,
require => Exec["uglyhack$filename"],
}

Which works, but is horrible and hackish.

debug: //File[/Users/jbarratt/bar]/require: requires Exec[uglyhack/Users/jbarratt/bar]
debug: //Exec[uglyhack/Users/jbarratt/bar]: Skipping automatic relationship with File[/Users/jbarratt/bar]
debug: //Exec[uglyhack/Users/jbarratt/bar]: Executing check '/bin/test -L /Users/jbarratt/bar'
debug: Executing '/bin/test -L /Users/jbarratt/bar'
debug: //Exec[uglyhack/Users/jbarratt/bar]: Changing returns
debug: //Exec[uglyhack/Users/jbarratt/bar]: 1 change(s)
debug: //Exec[uglyhack/Users/jbarratt/bar]: Executing '/bin/rm -f /Users/jbarratt/bar'
debug: Executing '/bin/rm -f /Users/jbarratt/bar'
notice: //Exec[uglyhack/Users/jbarratt/bar]/returns: executed successfully
debug: //File[/Users/jbarratt/bar]: File does not exist
debug: //File[/Users/jbarratt/bar]: Changing ensure
debug: //File[/Users/jbarratt/bar]: 1 change(s)
debug: //File[/Users/jbarratt/bar]/checksum: Initializing checksum hash
debug: //File[/Users/jbarratt/bar]: Creating checksum {md5}b670e3a1c7408e76521f9a4edeaa822a
notice: //File[/Users/jbarratt/bar]/ensure: content changed '{md5}b670e3a1c7408e76521f9a4edeaa822a' to '{md5}b670e3a1c7408e76521f9a4edeaa82

If puppet is managing a canonical resource on a filesystem, it should be able to specify and modify any attribute of that resource.

Ideally,

file { "/path/name":
content => "...",
ensure => file,
}

should be all I need to do. Puppet's job would be to transform my system to match the way the resources are modeling it's reality.

Bug #1915: File resources fail when original is a dangling symlink

• Author: micah -
• Status: Accepted
• Priority: Normal
• Assigned to:
• Category: file
• Target version:
• Affected version: 0.24.7
• Keywords: Problem #85
• Branch:

If before puppet has run, my host has the following dangling symlink:

$ ls -l /etc/motd lrwxrwxrwx 1 root root 13 2006-09-26 23:46 /etc/motd -> /var/run/motd $ ls -ld /var/run/motd ls: cannot access /var/run/motd: No such file or directory

Then I define a file resource for this host as follows:

file{"/etc/motd": content => ("foo"), owner => root, group => 0, mode => 0644; }

Puppet then files to create that file, due to the dangling symlink:

err: //motd::client/File[/etc/motd]: Failed to retrieve current state of resource: Could not read /etc/motd: No such file or directory - /etc/motd

I've tried various parameters to the file resource to override this such as backup => false, link => ignore, force => true and they all fail.

It seems like puppet should just remove the dangling symlink and replace it with what should be there, rather than error when the current state of the resource is in error.

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