[Puppet - Bug #4729] YAML Reports are only readable by root
Issue #4729 has been updated by Christian Patsch. We have forwarded this as Debian Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596792 No comment on the bug until now. I think that permissions on logfiles is basically a distro kind of problem, but on the other hand it would also be nice to be able to get configuration options for this in puppet itself. Bug #4729: YAML Reports are only readable by root http://projects.puppetlabs.com/issues/4729 Author: Christian Patsch Status: Needs design decision Priority: Normal Assignee: Nigel Kersten Category: reports Target version: Affected version: 2.6.0 Keywords: YAML,log,report Branch: I'm using Puppet 2.6 on a Debian Squeeze Host. After reporting Bug #4501, I digged deeper into YAML Reports. One Thing I encountered quite often is that I don't understand in which case reports are generated or not. Mostly reports are only available if puppet was able to parse all manifests, but even a small typo in a ressource only would generate errors on STDOUT. Is that the desired behaviour in 2.6 including the patch from Bug #4501 ? The more important issue is that reports are written to disk with the file ownerships puppet was called, which will naturally be the root account. Therefore my reports look like this: -rw-r- 1 rootroot7934 Sep 7 17:15 /var/log/puppet/hostname/201009071515.yaml The 640 permissions prevent another application from reading the logfiles. As far as I know, logfiles (especially in Debian) normally belong to the group 'adm' - therefore are readable to everyone in the admin group. -rw-r- 1 root adm 11033 Sep 7 12:31 /var/log/messages Could you please change this to make logfiles more usable ? If any testing or further investigation is required please don't hesitate to contact me. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4846] (Unreviewed) uninstalling packages gives failed dependencies errors
Issue #4846 has been reported by Benedikt Köppel.
Bug #4846: uninstalling packages gives failed dependencies errors
http://projects.puppetlabs.com/issues/4846
Author: Benedikt Köppel
Status: Unreviewed
Priority: Normal
Assignee:
Category: package
Target version:
Affected version: 0.25.5
Keywords:
Branch:
Hello
I want to ensure that a few packages are not installed on my machine. I have
defined this resource:
package { [
'php','php-gd','php-xmlrpc','php-cli','php-common','php-pdo','php-mbstring','php-mysql','php-pgsql'
]:
ensure = absent
}
I found, that puppet wants to remove each packet separately. This gives errors
such as:
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -e
php-common-5.1.6-27.el5.x86_64'
err: //httpd/Package[php-common]/ensure: change from 5.1.6-27.el5 to absent
failed: Execution of '/bin/rpm -e php-common-5.1.6-27.el5.x86_64' returned 1:
error: Failed dependencies:
php-common = 5.1.6-27.el5 is needed by (installed)
php-pdo-5.1.6-27.el5.x86_64
php-common = 5.1.6-27.el5 is needed by (installed)
php-mbstring-5.1.6-27.el5.x86_64
php-common = 5.1.6-27.el5 is needed by (installed)
php-xmlrpc-5.1.6-27.el5.x86_64
php-common = 5.1.6-27.el5 is needed by (installed)
php-pgsql-5.1.6-27.el5.x86_64
It would be more convenient if all packages are uninstalled in one run, then
the provider could decide how to handle the dependencies in between those
packages.
My system:
puppet --version: 0.25.5
ruby --version: ruby 1.8.5 (2006-08-25) [x86_64-linux]
cat /etc/redhat-release: Red Hat Enterprise Linux Server release 5.5
(Tikanga)
yum --version: 3.2.22
rpm --version: RPM version 4.4.2.3
Best Regards,
Benedikt Köppel
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4602] (Closed) TypeError with storeconfigs
Issue #4602 has been updated by Andrew Forgue. Status changed from Re-opened to Closed Re-closing ticket -- It appears that there was a 0.25.x puppet master connected to the same storeconfig database. Since upgrading that to 2.6.1 and re-creating the DB I have yet to see this problem in 2.6.1. Documenting my idiocy so others don't have to figure it out. You can look in the YAML file on the client for YAML::Object to see which resource is broken. Bug #4602: TypeError with storeconfigs http://projects.puppetlabs.com/issues/4602 Author: Ricky Zhou Status: Closed Priority: Normal Assignee: Category: Target version: Affected version: Keywords: Branch: I get the following traceback on a puppet server with storeconfigs enabled (using puppet-2.6.1-0.2.rc2.fc13.noarch.rpm from tmz's repo): pre /usr/lib/ruby/1.8/yaml.rb:391:in `emit' /usr/lib/ruby/1.8/yaml.rb:391:in `quick_emit' /usr/lib/ruby/1.8/yaml/types.rb:48:in `to_yaml' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/quoting.rb:31:in `quote' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/mysql_adapter.rb: 236:in `quote' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2992:in `attributes_with_quotes' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2983:in `each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2983:in `attributes_with_quotes' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2898:in `create_without_timestamps' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/timestamp.rb:53:in `create_without_callbacks' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/callbacks.rb:266:in `create' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2874:in `create_or_update_without_callbacks' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/callbacks.rb:250:in `create_or_update' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2538:in `save_without_validation' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/validations.rb:1078:in `save_without_dirty' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/dirty.rb:79:in `save_without_transactions' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:229:in `send' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:229:in `with_transaction_returning_status' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract/database_statements.rb:136:in `transaction' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:182:in `transaction' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:228:in `with_transaction_returning_status' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:196:in `save' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:208:in `rollback_active_record_state!' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/transactions.rb:196:in `save' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/has_many_association.rb:61:in `insert_record' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_proxy.rb:145:in `send' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_proxy.rb:145:in `send' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/autosave_association.rb:298:in `save_collection_association' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/autosave_association.rb:289:in `each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/autosave_association.rb:289:in `save_collection_association' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/autosave_association.rb:168:in `autosave_associated_records_for_param_values' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:180:in `evaluate_method' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:180:in `evaluate_method' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:180:in `instance_eval' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:180:in `evaluate_method' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:166:in `call' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:93:in `run' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:92:in `each' /usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/callbacks.rb:92:in `send'
[Puppet - Bug #4846] (Duplicate) uninstalling packages gives failed dependencies errors
Issue #4846 has been updated by Peter Meier.
Status changed from Unreviewed to Duplicate
this is related to #2198 and can only be fixed if puppet provides a way to
group various resources together.
Bug #4846: uninstalling packages gives failed dependencies errors
http://projects.puppetlabs.com/issues/4846
Author: Benedikt Köppel
Status: Duplicate
Priority: Normal
Assignee:
Category: package
Target version:
Affected version: 0.25.5
Keywords:
Branch:
Hello
I want to ensure that a few packages are not installed on my machine. I have
defined this resource:
package { [
'php','php-gd','php-xmlrpc','php-cli','php-common','php-pdo','php-mbstring','php-mysql','php-pgsql'
]:
ensure = absent
}
I found, that puppet wants to remove each packet separately. This gives errors
such as:
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -e
php-common-5.1.6-27.el5.x86_64'
err: //httpd/Package[php-common]/ensure: change from 5.1.6-27.el5 to absent
failed: Execution of '/bin/rpm -e php-common-5.1.6-27.el5.x86_64' returned 1:
error: Failed dependencies:
php-common = 5.1.6-27.el5 is needed by (installed)
php-pdo-5.1.6-27.el5.x86_64
php-common = 5.1.6-27.el5 is needed by (installed)
php-mbstring-5.1.6-27.el5.x86_64
php-common = 5.1.6-27.el5 is needed by (installed)
php-xmlrpc-5.1.6-27.el5.x86_64
php-common = 5.1.6-27.el5 is needed by (installed)
php-pgsql-5.1.6-27.el5.x86_64
It would be more convenient if all packages are uninstalled in one run, then
the provider could decide how to handle the dependencies in between those
packages.
My system:
puppet --version: 0.25.5
ruby --version: ruby 1.8.5 (2006-08-25) [x86_64-linux]
cat /etc/redhat-release: Red Hat Enterprise Linux Server release 5.5
(Tikanga)
yum --version: 3.2.22
rpm --version: RPM version 4.4.2.3
Best Regards,
Benedikt Köppel
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4848] (Unreviewed) puppetmaster should be able to report compile errors
Issue #4848 has been reported by Peter Meier. Feature #4848: puppetmaster should be able to report compile errors http://projects.puppetlabs.com/issues/4848 Author: Peter Meier Status: Unreviewed Priority: Normal Assignee: Category: compiler Target version: Affected version: Keywords: Branch: Currently the only way to know about compile errors is to parse the syslog. #3440 talks about integrating the information of a compile error into the dashboard. However, as compile errors are currently not reported the idea was not followed. But I think it's quite important to have that information in the dashboard or also somewhere else and it would be nice if the puppetmaster would also report compile errors. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4850] (Unreviewed) Schedule does not always work as expected when executed via puppetmaster/client
Issue #4850 has been reported by Chuck Schweizer.
Bug #4850: Schedule does not always work as expected when executed via
puppetmaster/client
http://projects.puppetlabs.com/issues/4850
Author: Chuck Schweizer
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected version: 2.6.1
Keywords:
Branch:
The following code works correctly when run on a puppet client via puppet
apply. But if the same code is used from a puppetmaster it does not follow
the schedule.
class mynotify {
$projects=TEST
schedule {
sched_15to20:
period = daily,
range = 15 - 20,
repeat = 48;
}
if ($projects) {
mynotify::myproject { $projects:
schedule = sched_15to20;
}
}
define myproject() {
notify { found $name: }
}
}
Here is the output when run from a puppet master
$ date
Mon Sep 27 11:12:44 CDT 2010
$ puppet apply -v --test
info: Retrieving plugin
info: Caching catalog for puppetcleint1
info: Applying configuration version '1285603757'
notice: found TEST
notice: /Stage[main]/Mynotify/Mynotify::Myproject[TEST]/Notify[found
TEST]/message: defined 'message' as 'found TEST'
notice: Finished catalog run in 7.65 seconds
This message does not produce output if run via puppet apply
- id131 !ruby/object:Puppet::Relationship
source: *id012
target: id017 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
file:
/var/opt/puppet/environments/os_test_env/modules/mynotify/manifests/init.pp
line: 9
parameters:
!ruby/sym range: 15 - 20
!ruby/sym repeat: 48
!ruby/sym period: daily
tags:
- schedule
- sched_15to20
- class
- mynotify
- node
- basenode
title: sched_15to20
type: Schedule
- id135 !ruby/object:Puppet::Relationship
source: *id012
target: id013 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
file:
/var/opt/puppet/environments/os_test_env/modules/mynotify/manifests/init.pp
line: 14
parameters:
!ruby/sym schedule: sched_15to20
tags:
- mynotify::myproject
- mynotify
- myproject
- test
- class
- node
- basenode
title: TEST
type: Mynotify::Myproject
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #2198] Install multiple package within a single call to the package manager
Issue #2198 has been updated by Nigel Kersten. ugh. How did this slip by for so long? Reminder being sent on dev list. Feature #2198: Install multiple package within a single call to the package manager http://projects.puppetlabs.com/issues/2198 Author: Stéphan Gorget Status: Needs design decision Priority: Normal Assignee: Stéphan Gorget Category: transactions Target version: unplanned Affected version: 0.25.0 Keywords: Branch: During the configuration applying process the package manager is called for each package installation. It is possible to reduce the number of calls to the package manager by gathering package installation and delayed some package installation. Naturally, this modification should not break the dependency graph. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4851] (Unreviewed) puppet agent --graph -t does not work on 2.6.1
Issue #4851 has been reported by Peter Meier. Bug #4851: puppet agent --graph -t does not work on 2.6.1 http://projects.puppetlabs.com/issues/4851 Author: Peter Meier Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected version: 2.6.1 Keywords: Branch: Having 2.6.1 installed I'm not able to produce a .dot file by running pre puppet agent -t --graph /pre also pre puppet agent -t --graph test.dot /pre does not produce anything. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4852] (Unreviewed) Vague/unclear dependency cycle error
Issue #4852 has been reported by Peter Meier. Bug #4852: Vague/unclear dependency cycle error http://projects.puppetlabs.com/issues/4852 Author: Peter Meier Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected version: Keywords: Branch: Having a dependency cycle in my manifests I get the following error message: pre /usr/lib/ruby/site_ruby/1.8/puppet/simple_graph.rb:204:in `topsort' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:281:in `prepare' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:130:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 err: Could not apply complete catalog: Found dependency cycles in the following relationships: Whit[Puppet::Client::Cron] = Whit[Puppet::Client::Cron]; try using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz /pre However there is no resource called @Whit[Puppet::Client::Cron]@ in my manifests nor do I get like that an idea what might create the dependency cycle. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4851] (Accepted) puppet agent --graph -t does not work on 2.6.1
Issue #4851 has been updated by James Turnbull. Category set to plumbing Status changed from Unreviewed to Accepted Priority changed from Normal to High Target version set to 2.6.2 Bug #4851: puppet agent --graph -t does not work on 2.6.1 http://projects.puppetlabs.com/issues/4851 Author: Peter Meier Status: Accepted Priority: High Assignee: Category: plumbing Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: Having 2.6.1 installed I'm not able to produce a .dot file by running pre puppet agent -t --graph /pre also pre puppet agent -t --graph test.dot /pre does not produce anything. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4852] (Accepted) Vague/unclear dependency cycle error
Issue #4852 has been updated by James Turnbull. Category set to plumbing Status changed from Unreviewed to Accepted Priority changed from Normal to High Target version set to 2.6.2 Bug #4852: Vague/unclear dependency cycle error http://projects.puppetlabs.com/issues/4852 Author: Peter Meier Status: Accepted Priority: High Assignee: Category: plumbing Target version: 2.6.2 Affected version: Keywords: Branch: Having a dependency cycle in my manifests I get the following error message: pre /usr/lib/ruby/site_ruby/1.8/puppet/simple_graph.rb:204:in `topsort' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:281:in `prepare' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:130:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 err: Could not apply complete catalog: Found dependency cycles in the following relationships: Whit[Puppet::Client::Cron] = Whit[Puppet::Client::Cron]; try using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz /pre However there is no resource called @Whit[Puppet::Client::Cron]@ in my manifests nor do I get like that an idea what might create the dependency cycle. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4852] Vague/unclear dependency cycle error
Issue #4852 has been updated by James Turnbull. Affected version set to 2.6.1 Bug #4852: Vague/unclear dependency cycle error http://projects.puppetlabs.com/issues/4852 Author: Peter Meier Status: Accepted Priority: High Assignee: Category: plumbing Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: Having a dependency cycle in my manifests I get the following error message: pre /usr/lib/ruby/site_ruby/1.8/puppet/simple_graph.rb:204:in `topsort' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:281:in `prepare' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:130:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 err: Could not apply complete catalog: Found dependency cycles in the following relationships: Whit[Puppet::Client::Cron] = Whit[Puppet::Client::Cron]; try using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz /pre However there is no resource called @Whit[Puppet::Client::Cron]@ in my manifests nor do I get like that an idea what might create the dependency cycle. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4852] Vague/unclear dependency cycle error
Issue #4852 has been updated by Peter Meier.
So the dependency cycle was actually due to the following reasons:
pre
class puppet::client::cron {
require cron
#[...]
}
/pre
What we actually want to do is to require the cron module here. 0.25.x didn't
yet produce a dependency cycle for that. 2.6.1 does, which is also correct and
the fix for that is:
pre
class puppet::client::cron {
require ::cron
#[...]
}
/pre
BUT the error message isn't really helpful, because I have for example no idea
that Whit is the (probably) internal representation of class dependencies.
Bug #4852: Vague/unclear dependency cycle error
http://projects.puppetlabs.com/issues/4852
Author: Peter Meier
Status: Accepted
Priority: High
Assignee:
Category: plumbing
Target version: 2.6.2
Affected version: 2.6.1
Keywords:
Branch:
Having a dependency cycle in my manifests I get the following error message:
pre
/usr/lib/ruby/site_ruby/1.8/puppet/simple_graph.rb:204:in `topsort'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:281:in `prepare'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:130:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute'
/usr/bin/puppet:4
err: Could not apply complete catalog: Found dependency cycles in the following
relationships: Whit[Puppet::Client::Cron] = Whit[Puppet::Client::Cron]; try
using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz
/pre
However there is no resource called @Whit[Puppet::Client::Cron]@ in my
manifests nor do I get like that an idea what might create the dependency cycle.
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4855] group resources on OS X may fail is group members are non-existant
Issue #4855 has been updated by Clay Caviness.
The workaround until Apple fixes the issue with dseditgroup is to use dscl to
modify the GroupMembership attributes directly, but ... ugh.
Bug #4855: group resources on OS X may fail is group members are non-existant
http://projects.puppetlabs.com/issues/4855
Author: Clay Caviness
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected version:
Keywords:
Branch:
The group provider on OS X uses dseditgroup to manage group membership. Due
to Apple bug 8481241 (dseditgroup can't remove unknown users from groups),
however, if the puppet group provider needs to remove a non-existant user from
a group it manages, it will fail.
To reproduce, first apply:
pre
group { testgroup: ensure = present, members = [testuser, root],
require = User[testuser] }
user { testuser: ensure = present }
[...]info: Applying configuration version '1285616257'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Users'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Users'
debug: User[testuser](provider=directoryservice): Executing '/usr/bin/dscl
-plist . -create /Users/testuser GeneratedUID
90209F1B-B066-4630-8BD0-5B19C640CBFF'
notice: /Stage[main]//User[testuser]/ensure: created
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Groups'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -read /Groups/testgroup'
debug: Group[testgroup](provider=directoryservice): Executing 'dseditgroup -o
edit -n . -a root testgroup'
notice: /Stage[main]//Group[testgroup]/members: members changed 'testuser' to
'testuser,root'
debug: Finishing transaction 2194047380
/pre
Delete the user via:
predscl . -delete /Users/testuser/pre
(Alternatively, the user can be deleted via puppet, though ordering may allow
this to be successful.)
Now try to apply a change to the group that would cause the testuser user to be
removed from group membership:
pre
group { testgroup: ensure = present, members = root}
[...]
info: Applying configuration version '1285616630'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Groups'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -read /Groups/testgroup'
debug: Group[testgroup](provider=directoryservice): Executing 'dseditgroup -o
edit -n . -d testuser testgroup'
err: /Stage[main]//Group[testgroup]/members: change from roottestuser to root
failed: Could not remove testuser from group: testgroup, Execution of
'dseditgroup -o edit -n . -d testuser testgroup' returned 200: Record was not
found.
debug: Finishing transaction 2190850540
/pre
**All** attempts to make changes to the group membership from this point will
fail, as dseditgroup cannot remove a user from a group if that user does not
exist.
Running puppet 2.6.1 on OS X 10.6.4.
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4851] puppet agent --graph -t does not work on 2.6.1
Issue #4851 has been updated by Nick Lewis. Assignee set to Nick Lewis I'm unable to reproduce this. Is the manifest you're trying to compile actually compiling successfully, or is it a manifest with an error? Do you get graphs with puppet apply, or with another manifest? Any other information would be helpful, thanks. Bug #4851: puppet agent --graph -t does not work on 2.6.1 http://projects.puppetlabs.com/issues/4851 Author: Peter Meier Status: Accepted Priority: High Assignee: Nick Lewis Category: plumbing Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: Having 2.6.1 installed I'm not able to produce a .dot file by running pre puppet agent -t --graph /pre also pre puppet agent -t --graph test.dot /pre does not produce anything. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4792] (Investigating) Duplicate definition since 2.6.1 upgrade
Issue #4792 has been updated by Jesse Wolfe.
Status changed from Needs more information to Investigating
Assignee changed from James Turnbull to Jesse Wolfe
Bug #4792: Duplicate definition since 2.6.1 upgrade
http://projects.puppetlabs.com/issues/4792
Author: James Turnbull
Status: Investigating
Priority: High
Assignee: Jesse Wolfe
Category: parser
Target version: 2.6.2
Affected version: 2.6.1
Keywords:
Branch:
Class, users::virtual which has all the user{} statements for all users. Then
have classes like users::cms and users::developers that inherit users::virtual
and then realize some of the users. This all worked perfectly fine in 2.5 but
since 2.6.1 runs now fail with:
pre
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: User[apen
ney] is already defined in file
/etc/puppet/modules/testing/users/manifests/virtual.pp at line 19; canno
t redefine at /etc/puppet/modules/testing/users/manifests/virtual.pp:19 on node
hlslinutil1.law.harvard.
edu
/pre
pre
realize(
User['user'],
)
}
# cat virtual.pp
class users::virtual {
##
## Sysadmins
##
@user { user:
ensure = present,
uid = 35421,
gid = 100,
groups = wheel,
comment = User Name,
home = /home/user,
shell = /bin/zsh,
password = password,
managehome = true,
}
}
/pre
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4852] Vague/unclear dependency cycle error
Issue #4852 has been updated by Nick Lewis. Assignee set to Nick Lewis Bug #4852: Vague/unclear dependency cycle error http://projects.puppetlabs.com/issues/4852 Author: Peter Meier Status: Accepted Priority: High Assignee: Nick Lewis Category: plumbing Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: Having a dependency cycle in my manifests I get the following error message: pre /usr/lib/ruby/site_ruby/1.8/puppet/simple_graph.rb:204:in `topsort' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:281:in `prepare' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:130:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 err: Could not apply complete catalog: Found dependency cycles in the following relationships: Whit[Puppet::Client::Cron] = Whit[Puppet::Client::Cron]; try using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz /pre However there is no resource called @Whit[Puppet::Client::Cron]@ in my manifests nor do I get like that an idea what might create the dependency cycle. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4772] Changes to puppet.spec file for conf/suse/puppet.spec (for 2.6.1)
Issue #4772 has been updated by Jacob Helwig. This has been posted to the mailing list, with some discussion [1]. Ben: Would you be able to answer some of the questions that have been raised on the list? [1] http://groups.google.com/group/puppet-dev/browse_thread/thread/f9a2621e1a371813 Feature #4772: Changes to puppet.spec file for conf/suse/puppet.spec (for 2.6.1) http://projects.puppetlabs.com/issues/4772 Author: Ben Kevan Status: Ready for Testing Priority: Normal Assignee: Category: Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: Here's a diff of some changes for puppet.spec for 2.6.1. I'm also going to try setting up checkproc to work correctly with puppet agent and puppet master and not puppetd and puppetmasterd. But I haven't had time to test right now. Major changes of the spec file for rpm building on this release was the version bump, the change to puppetlabs.com in source urls. Removal of client.init and server.init sources since those have since been moved info conf/suse, moved ruby required version from 1.8.2 to 1.8.1 since issues with 1.8.1 have been resolved and removal of the patches to replace /usr/bin/env ruby to /usr/bin/ruby and did it within the spec file. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4792] Duplicate definition since 2.6.1 upgrade
Issue #4792 has been updated by Jesse Wolfe.
Ohad, Stephan - when you're applying these classes to a node, what mechanism
are you using: the include keyword in a .pp file? the external node classifier?
foreman? dashboard?
Bug #4792: Duplicate definition since 2.6.1 upgrade
http://projects.puppetlabs.com/issues/4792
Author: James Turnbull
Status: Investigating
Priority: High
Assignee: Jesse Wolfe
Category: parser
Target version: 2.6.2
Affected version: 2.6.1
Keywords:
Branch:
Class, users::virtual which has all the user{} statements for all users. Then
have classes like users::cms and users::developers that inherit users::virtual
and then realize some of the users. This all worked perfectly fine in 2.5 but
since 2.6.1 runs now fail with:
pre
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: User[apen
ney] is already defined in file
/etc/puppet/modules/testing/users/manifests/virtual.pp at line 19; canno
t redefine at /etc/puppet/modules/testing/users/manifests/virtual.pp:19 on node
hlslinutil1.law.harvard.
edu
/pre
pre
realize(
User['user'],
)
}
# cat virtual.pp
class users::virtual {
##
## Sysadmins
##
@user { user:
ensure = present,
uid = 35421,
gid = 100,
groups = wheel,
comment = User Name,
home = /home/user,
shell = /bin/zsh,
password = password,
managehome = true,
}
}
/pre
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4851] puppet agent --graph -t does not work on 2.6.1
Issue #4851 has been updated by Peter Meier. this was related to #4852 and I think it wasn't during compile, it was after the catalog have been transferred to the client. I didn't try with puppet apply, though. I fixed my dependency cycle (see #4852), but you should be able to reproduce it by adding such a dependency cycle to some manifests your serving in a master/client setup. Bug #4851: puppet agent --graph -t does not work on 2.6.1 http://projects.puppetlabs.com/issues/4851 Author: Peter Meier Status: Accepted Priority: High Assignee: Nick Lewis Category: plumbing Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: Having 2.6.1 installed I'm not able to produce a .dot file by running pre puppet agent -t --graph /pre also pre puppet agent -t --graph test.dot /pre does not produce anything. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4852] (Ready for Testing) Vague/unclear dependency cycle error
Issue #4852 has been updated by Nick Lewis. Status changed from Accepted to Ready for Testing Branch set to http://github.com/nicklewis/puppet/tree/ticket%2F2.6.x%2F4852 Added a specific Whit#to_s method which pretends to be the class when printing, rather than exposing its whit-ness. Also added an exception in lib/puppet/reference/type.rb to prevent puppetdoc from generating documentation for the whit type. Bug #4852: Vague/unclear dependency cycle error http://projects.puppetlabs.com/issues/4852 Author: Peter Meier Status: Ready for Testing Priority: High Assignee: Nick Lewis Category: plumbing Target version: 2.6.2 Affected version: 2.6.1 Keywords: Branch: http://github.com/nicklewis/puppet/tree/ticket%2F2.6.x%2F4852 Having a dependency cycle in my manifests I get the following error message: pre /usr/lib/ruby/site_ruby/1.8/puppet/simple_graph.rb:204:in `topsort' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:281:in `prepare' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:130:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:103:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:37:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:171:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:35:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:114:in `onetime' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:88:in `run_command' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:397:in `exit_on_fail' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:300:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' /usr/bin/puppet:4 err: Could not apply complete catalog: Found dependency cycles in the following relationships: Whit[Puppet::Client::Cron] = Whit[Puppet::Client::Cron]; try using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz /pre However there is no resource called @Whit[Puppet::Client::Cron]@ in my manifests nor do I get like that an idea what might create the dependency cycle. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4792] (Needs more information) Duplicate definition since 2.6.1 upgrade
Issue #4792 has been updated by Jesse Wolfe.
Status changed from Investigating to Needs more information
Theorizing that this might only affect the external node classifier, I
attempted to reproduce the issue using Stefan's example, putting the classes in
modules as he described, and using a node classification script that assigned
both classes to the node.
I didn't get the error.
Is there anything I could be missing? Do any of you have a minimal manifest
that exhibits the problem that you could post?
Bug #4792: Duplicate definition since 2.6.1 upgrade
http://projects.puppetlabs.com/issues/4792
Author: James Turnbull
Status: Needs more information
Priority: High
Assignee: Jesse Wolfe
Category: parser
Target version: 2.6.2
Affected version: 2.6.1
Keywords:
Branch:
Class, users::virtual which has all the user{} statements for all users. Then
have classes like users::cms and users::developers that inherit users::virtual
and then realize some of the users. This all worked perfectly fine in 2.5 but
since 2.6.1 runs now fail with:
pre
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate definition: User[apen
ney] is already defined in file
/etc/puppet/modules/testing/users/manifests/virtual.pp at line 19; canno
t redefine at /etc/puppet/modules/testing/users/manifests/virtual.pp:19 on node
hlslinutil1.law.harvard.
edu
/pre
pre
realize(
User['user'],
)
}
# cat virtual.pp
class users::virtual {
##
## Sysadmins
##
@user { user:
ensure = present,
uid = 35421,
gid = 100,
groups = wheel,
comment = User Name,
home = /home/user,
shell = /bin/zsh,
password = password,
managehome = true,
}
}
/pre
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4629] (Closed) puppet run Error 403 on SERVER: Forbidden request
Issue #4629 has been updated by Matt Robinson. Status changed from Accepted to Closed 1. The unicode em-dash vs. “—” question - Resolved 2. Mohit’s namespaceauth.conf vs. auth.conf question namespaceauth.conf needs to be removed from consideration in the code and auth.conf used instead (ticket #4388). Mohit's workaround of creating the empty namespaceauth.conf and putting the path /run auth no # you may or may not want this depending on who you want to be able to trigger puppet runs allow server.name.com in auth.conf is a good one for now. 3. Joy’s original question - Joy had problems 1 and 2. Once he gets the dash figured out and updates his auth.conf with an empty namespaceauth.conf it should work. Joy, please reopen and update this ticket with details if you still have problems. Bug #4629: puppet run Error 403 on SERVER: Forbidden request http://projects.puppetlabs.com/issues/4629 Author: joy huang Status: Closed Priority: Normal Assignee: Category: plumbing Target version: 2.6.2 Affected version: 0.25.0 Keywords: Branch: puppet master release:puppet-2.6.1rc2 puppet client release:puppet--0.25.5 pre [r...@master ~]# puppetrun -p 10 --host ubunu910.dvmns.com Triggering ubunu910.dvmns.com Host ubunu910.dvmns.com failed: Error 403 on SERVER: Forbidden request: ctc92.dvmns.com(221.238.249.92) access to /run/ubunu910.dvmns.com [save] authenticated at line 0 ubunu910.dvmns.com finished with exit code 2 Failed: ubunu910.dvmns.com /pre Could someone tell me how to fix this ? mymail is: wto...@hotmail.com thanks joy -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4859] (Unreviewed) exec regression - shell negation doesn't work anymore
Issue #4859 has been reported by Jordan Sissel.
Bug #4859: exec regression - shell negation doesn't work anymore
http://projects.puppetlabs.com/issues/4859
Author: Jordan Sissel
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected version:
Keywords:
Branch:
In 0.25.5 and previous, you can no longer use shell negation on commands. I use
these in 'onlyif' statements for some.
Here's a sample reproduce case:
pre
class foo {
Exec {
path = [ /bin, /sbin, /usr/bin, /usr/sbin,
/usr/local/bin, /usr/local/sbin ],
}
exec {
echo hello world:
onlyif = ! false;
}
}
include foo
/pre
This works in previous versions (= 0.25.5). In 2.6.1, this does not work.
Specifically, this line causes the error:
pre
onlyif = ! false;
/pre
It also fails if the '!' appears first in the actually command name (like !
echo hello world).
Failure from 2.6:
pre
% puppet apply --verbose test.pp
info: Applying configuration version '1285645441'
err: /Stage[main]/Foo/Exec[echo hello world]: Could not evaluate: Could not
find command '!'
/pre
Success on 0.25.5:
pre
% puppet --verbose test.pp
info: Applying configuration version '1285645456'
/pre
There are workarounds, like adding `[ \$? -ne 0 ]` -
pre
onlyif = false; [ \$? -ne 0 ]
/pre
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4859] exec regression - shell negation doesn't work anymore
Issue #4859 has been updated by Jordan Sissel.
The original description should read:
In 2.6.1, you can no longer use shell negation on commands. This previously
worked in 0.25.5 and older versions. I use these in ‘onlyif’ statements for
some state checking.
Bug #4859: exec regression - shell negation doesn't work anymore
http://projects.puppetlabs.com/issues/4859
Author: Jordan Sissel
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected version:
Keywords:
Branch:
In 0.25.5 and previous, you can no longer use shell negation on commands. I use
these in 'onlyif' statements for some.
Here's a sample reproduce case:
pre
class foo {
Exec {
path = [ /bin, /sbin, /usr/bin, /usr/sbin,
/usr/local/bin, /usr/local/sbin ],
}
exec {
echo hello world:
onlyif = ! false;
}
}
include foo
/pre
This works in previous versions (= 0.25.5). In 2.6.1, this does not work.
Specifically, this line causes the error:
pre
onlyif = ! false;
/pre
It also fails if the '!' appears first in the actually command name (like !
echo hello world).
Failure from 2.6:
pre
% puppet apply --verbose test.pp
info: Applying configuration version '1285645441'
err: /Stage[main]/Foo/Exec[echo hello world]: Could not evaluate: Could not
find command '!'
/pre
Success on 0.25.5:
pre
% puppet --verbose test.pp
info: Applying configuration version '1285645456'
/pre
There are workarounds, like adding `[ \$? -ne 0 ]` -
pre
onlyif = false; [ \$? -ne 0 ]
/pre
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4859] exec regression - shell negation doesn't work anymore
Issue #4859 has been updated by Jordan Sissel.
Also, I am OK if this now-breaking-thing is an intentional change and not a
bug/regressions that just happened to work previously.
Bug #4859: exec regression - shell negation doesn't work anymore
http://projects.puppetlabs.com/issues/4859
Author: Jordan Sissel
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected version:
Keywords:
Branch:
In 0.25.5 and previous, you can no longer use shell negation on commands. I use
these in 'onlyif' statements for some.
Here's a sample reproduce case:
pre
class foo {
Exec {
path = [ /bin, /sbin, /usr/bin, /usr/sbin,
/usr/local/bin, /usr/local/sbin ],
}
exec {
echo hello world:
onlyif = ! false;
}
}
include foo
/pre
This works in previous versions (= 0.25.5). In 2.6.1, this does not work.
Specifically, this line causes the error:
pre
onlyif = ! false;
/pre
It also fails if the '!' appears first in the actually command name (like !
echo hello world).
Failure from 2.6:
pre
% puppet apply --verbose test.pp
info: Applying configuration version '1285645441'
err: /Stage[main]/Foo/Exec[echo hello world]: Could not evaluate: Could not
find command '!'
/pre
Success on 0.25.5:
pre
% puppet --verbose test.pp
info: Applying configuration version '1285645456'
/pre
There are workarounds, like adding `[ \$? -ne 0 ]` -
pre
onlyif = false; [ \$? -ne 0 ]
/pre
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4855] (Needs design decision) group resources on OS X may fail is group members are non-existant
Issue #4855 has been updated by James Turnbull.
Category set to OSX
Status changed from Unreviewed to Needs design decision
Assignee set to Nigel Kersten
Affected version set to 2.6.1
Bug #4855: group resources on OS X may fail is group members are non-existant
http://projects.puppetlabs.com/issues/4855
Author: Clay Caviness
Status: Needs design decision
Priority: Normal
Assignee: Nigel Kersten
Category: OSX
Target version:
Affected version: 2.6.1
Keywords:
Branch:
The group provider on OS X uses dseditgroup to manage group membership. Due
to Apple bug 8481241 (dseditgroup can't remove unknown users from groups),
however, if the puppet group provider needs to remove a non-existant user from
a group it manages, it will fail.
To reproduce, first apply:
pre
group { testgroup: ensure = present, members = [testuser, root],
require = User[testuser] }
user { testuser: ensure = present }
[...]info: Applying configuration version '1285616257'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Users'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Users'
debug: User[testuser](provider=directoryservice): Executing '/usr/bin/dscl
-plist . -create /Users/testuser GeneratedUID
90209F1B-B066-4630-8BD0-5B19C640CBFF'
notice: /Stage[main]//User[testuser]/ensure: created
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Groups'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -read /Groups/testgroup'
debug: Group[testgroup](provider=directoryservice): Executing 'dseditgroup -o
edit -n . -a root testgroup'
notice: /Stage[main]//Group[testgroup]/members: members changed 'testuser' to
'testuser,root'
debug: Finishing transaction 2194047380
/pre
Delete the user via:
predscl . -delete /Users/testuser/pre
(Alternatively, the user can be deleted via puppet, though ordering may allow
this to be successful.)
Now try to apply a change to the group that would cause the testuser user to be
removed from group membership:
pre
group { testgroup: ensure = present, members = root}
[...]
info: Applying configuration version '1285616630'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -list /Groups'
debug: Puppet::Type::Group::ProviderDirectoryservice: Executing '/usr/bin/dscl
-plist . -read /Groups/testgroup'
debug: Group[testgroup](provider=directoryservice): Executing 'dseditgroup -o
edit -n . -d testuser testgroup'
err: /Stage[main]//Group[testgroup]/members: change from roottestuser to root
failed: Could not remove testuser from group: testgroup, Execution of
'dseditgroup -o edit -n . -d testuser testgroup' returned 200: Record was not
found.
debug: Finishing transaction 2190850540
/pre
**All** attempts to make changes to the group membership from this point will
fail, as dseditgroup cannot remove a user from a group if that user does not
exist.
Running puppet 2.6.1 on OS X 10.6.4.
--
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://projects.puppetlabs.com/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-b...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4848] (Accepted) puppetmaster should be able to report compile errors
Issue #4848 has been updated by James Turnbull. Status changed from Unreviewed to Accepted Agreed - I thought there was a ticket for this but can't find it. Feature #4848: puppetmaster should be able to report compile errors http://projects.puppetlabs.com/issues/4848 Author: Peter Meier Status: Accepted Priority: Normal Assignee: Category: compiler Target version: Affected version: Keywords: Branch: Currently the only way to know about compile errors is to parse the syslog. #3440 talks about integrating the information of a compile error into the dashboard. However, as compile errors are currently not reported the idea was not followed. But I think it's quite important to have that information in the dashboard or also somewhere else and it would be nice if the puppetmaster would also report compile errors. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4845] (Accepted) unhelpful error message when config_version script fails
Issue #4845 has been updated by James Turnbull. Category set to plumbing Status changed from Unreviewed to Accepted Bug #4845: unhelpful error message when config_version script fails http://projects.puppetlabs.com/issues/4845 Author: Alan Barrett Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Affected version: 0.25.5 Keywords: Branch: If the config_version script on the puppetmaster fails, with messages printed to stderr, then puppetd on the client reports this error: pre # /usr/local/sbin/puppetd --onetime --test --noop err: Could not retrieve catalog from remote server: wrong header line format warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run /pre Extract from puppet.conf file: pre [puppetmasterd] config_version = /etc/puppet/scripts/puppetmaster/config_version /pre Contents of config_version script causing the unhelpful error message: pre #!/bin/sh echo ERROR 2 exit 1 /pre If the config_version script exits with an error status but does not print anything to stderr, then the error message is much more useful: Contents of config_version script causing a useful error message: pre #!/bin/sh exit 1 /pre Useful error message with the above config_version file: pre # /usr/local/sbin/puppetd --onetime --test --noop err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unable to set config_version: Execution of '/etc/puppet/scripts/puppetmaster/config_version' returned 1: on node mynode.domain.example /pre Desired behaviour: The useful error message should be printed whenever the config_version script fails. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #4845] unhelpful error message when config_version script fails
Issue #4845 has been updated by James Turnbull. Target version changed from 2.6.x to Statler Bug #4845: unhelpful error message when config_version script fails http://projects.puppetlabs.com/issues/4845 Author: Alan Barrett Status: Accepted Priority: Normal Assignee: Category: plumbing Target version: Statler Affected version: 0.25.5 Keywords: Branch: If the config_version script on the puppetmaster fails, with messages printed to stderr, then puppetd on the client reports this error: pre # /usr/local/sbin/puppetd --onetime --test --noop err: Could not retrieve catalog from remote server: wrong header line format warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run /pre Extract from puppet.conf file: pre [puppetmasterd] config_version = /etc/puppet/scripts/puppetmaster/config_version /pre Contents of config_version script causing the unhelpful error message: pre #!/bin/sh echo ERROR 2 exit 1 /pre If the config_version script exits with an error status but does not print anything to stderr, then the error message is much more useful: Contents of config_version script causing a useful error message: pre #!/bin/sh exit 1 /pre Useful error message with the above config_version file: pre # /usr/local/sbin/puppetd --onetime --test --noop err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unable to set config_version: Execution of '/etc/puppet/scripts/puppetmaster/config_version' returned 1: on node mynode.domain.example /pre Desired behaviour: The useful error message should be printed whenever the config_version script fails. -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4836] (Accepted) puppetd --disable improvements
Issue #4836 has been updated by James Turnbull. Category changed from unknown to error reporting Status changed from Unreviewed to Accepted Target version set to Statler Affected version set to 0.25.5 Feature #4836: puppetd --disable improvements http://projects.puppetlabs.com/issues/4836 Author: micah - Status: Accepted Priority: Low Assignee: Category: error reporting Target version: Statler Affected version: 0.25.5 Keywords: Branch: Occasionally I disable regular puppetd runs on a system by doing: pre # puppetd --disable /pre This works fine, except that it could be improved in two ways: 1. If it has been manually disabled, then when a run is attempted, it should print something more useful than this: pre notice: Run of Puppet configuration client already in progress; skipping /pre because well... that message isn't really true, its not in progress, rather it is currently disabled. 2. The something more useful that it could print could be either a default message notice: Puppet administratively disabled on this system; skipping, or a custom message that you can pass to the puppetd --disable, eg. puppetd --disable micah is fixing stunnel template would then print the following when a puppetd was running: notice: Puppet is administratively disabled because micah is fixing stunnel template; skipping run -- 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://projects.puppetlabs.com/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-b...@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
