[Puppet - Feature #2198] Install multiple package within a single call to the package manager
Issue #2198 has been updated by Stéphan Gorget. I need someone to review the patch and tell me what have to be improved or rethink to make it acceptable. I have not resend it on the mailing list it is already there : http://groups.google.com/group/puppet-dev/browse_thread/thread/424b7cbfe52ccfd0 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 Assigned to: 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 #3133] On a failed request puppet error message is not very helpful
Issue #3133 has been updated by Glenn Aaldering. Hi guys, Im not exactly sure if my problem is related to bug 3133 but it was the only bug that shows the same error as i am seeing. We have a custom made module, with a custom fact in it. This specific fact seems to create very long URL's. My setup is build on nginx using mongrel instead of webrick. This is the error im receiving: err: Could not retrieve catalog from remote server: wrong status line: HTML warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run According to bug 3133 this will be fixed in version 0.25.5. After trying the latest source code via git, the problem still exists. Although the bug was accepted, I managed to fix my problem because in my case, it was an nginx issue. According to nginx documentation the default setting which gives me the error is: large_client_header_buffers 4 4k/8k I solved my problem by adding a line in /etc/nginx/nginx.conf file at the http section: large_client_header_buffers 8 16k And reloading nginx. Thanks, Glenn Bug #3133: On a failed request puppet error message is not very helpful http://projects.puppetlabs.com/issues/3133 Author: Peter Meier Status: Accepted Priority: Normal Assigned to: Category: Target version: 0.25.5 Affected version: 0.25.4 Keywords: Branch: After upgrading to 0.25.4 my OpenBSD clients failed to get the catalog. The error I received was: pre err: Could not retrieve catalog from remote server: wrong status line: html /pre The @--trace@@ looks like: pre info: Loading facts in xen /usr/local/lib/ruby/1.8/net/http.rb:2031:in `read_status_line' /usr/local/lib/ruby/1.8/net/http.rb:2018:in `read_new' /usr/local/lib/ruby/1.8/net/http.rb:1059:in `request' /usr/local/lib/ruby/1.8/net/http.rb:1046:in `request' /usr/local/lib/ruby/1.8/net/http.rb:547:in `start' /usr/local/lib/ruby/1.8/net/http.rb:1044:in `request' /usr/local/lib/ruby/1.8/net/http.rb:781:in `get' /usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:69:in `find' /usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in `find' /usr/local/lib/ruby/site_ruby/1.8/puppet/indirector.rb:51:in `find' /usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:106:in `retrieve_catalog' /usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark' /usr/local/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/local/lib/ruby/1.8/benchmark.rb:307:in `realtime' /usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark' /usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:105:in `retrieve_catalog' /usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:162:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run' /usr/local/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:134:in `with_client' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run' /usr/local/sbin/puppetd:159 err: Could not retrieve catalog from remote server: wrong status line: html /pre After debugging a while I found out that using webrick it works, hence I thought that the problem is related to my fronted proxy nginx. And yeah looks like I encounter the famous 414 Request URI too long. However this was only noted in the nginx-logs. I think puppet should a) at least print the status code it received (414) and b) maybe be more verbose, so one could find the error earlier and the error message makes more sense. -- 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 #3133] On a failed request puppet error message is not very helpful
Issue #3133 has been updated by Peter Meier. Im not exactly sure if my problem is related to bug 3133 but it was the only bug that shows the same error as i am seeing. We have a custom made module, with a custom fact in it. This specific fact seems to create very long URL's. My setup is build on nginx using mongrel instead of webrick. This is rather related to #2668 Bug #3133: On a failed request puppet error message is not very helpful http://projects.puppetlabs.com/issues/3133 Author: Peter Meier Status: Accepted Priority: Normal Assigned to: Category: Target version: 0.25.5 Affected version: 0.25.4 Keywords: Branch: After upgrading to 0.25.4 my OpenBSD clients failed to get the catalog. The error I received was: pre err: Could not retrieve catalog from remote server: wrong status line: html /pre The @--trace@@ looks like: pre info: Loading facts in xen /usr/local/lib/ruby/1.8/net/http.rb:2031:in `read_status_line' /usr/local/lib/ruby/1.8/net/http.rb:2018:in `read_new' /usr/local/lib/ruby/1.8/net/http.rb:1059:in `request' /usr/local/lib/ruby/1.8/net/http.rb:1046:in `request' /usr/local/lib/ruby/1.8/net/http.rb:547:in `start' /usr/local/lib/ruby/1.8/net/http.rb:1044:in `request' /usr/local/lib/ruby/1.8/net/http.rb:781:in `get' /usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:69:in `find' /usr/local/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:195:in `find' /usr/local/lib/ruby/site_ruby/1.8/puppet/indirector.rb:51:in `find' /usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:106:in `retrieve_catalog' /usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark' /usr/local/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/local/lib/ruby/1.8/benchmark.rb:307:in `realtime' /usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark' /usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:105:in `retrieve_catalog' /usr/local/lib/ruby/site_ruby/1.8/puppet/configurer.rb:162:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run' /usr/local/lib/ruby/1.8/sync.rb:229:in `synchronize' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:53:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:134:in `with_client' /usr/local/lib/ruby/site_ruby/1.8/puppet/agent.rb:51:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/application/puppetd.rb:103:in `onetime' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail' /usr/local/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run' /usr/local/sbin/puppetd:159 err: Could not retrieve catalog from remote server: wrong status line: html /pre After debugging a while I found out that using webrick it works, hence I thought that the problem is related to my fronted proxy nginx. And yeah looks like I encounter the famous 414 Request URI too long. However this was only noted in the nginx-logs. I think puppet should a) at least print the status code it received (414) and b) maybe be more verbose, so one could find the error earlier and the error message makes more sense. -- 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 #3533] (Unreviewed) Fix inefficient transaction cleanup
Issue #3533 has been reported by Peter Meier. Bug #3533: Fix inefficient transaction cleanup http://projects.puppetlabs.com/issues/3533 Author: Peter Meier Status: Unreviewed Priority: High Assigned to: Category: transactions Target version: 0.25.5 Affected version: 0.25.5rc1 Keywords: Branch: As discussed in http://groups.google.com/group/puppet-dev/browse_thread/thread/aea82ebc860285b2 the cleanup of transactions is inefficient and should be improved. -- 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 Dashboard - Bug #3534] (Unreviewed) Return parameter as array via puppet-dashboard/bin/external_node
Issue #3534 has been reported by Stefan Goethals. Bug #3534: Return parameter as array via puppet-dashboard/bin/external_node http://projects.puppetlabs.com/issues/3534 Author: Stefan Goethals Status: Unreviewed Priority: Normal Assigned to: Category: Target version: Keywords: Branch: When assigning a parameter on a node as an array, the external node tool returns it, escaped, as a string, # /usr/local/puppet-dashboard/bin/external_node node --- name: node parameters: arraytest: [ \one\, \two\ ] classes: - puppet::server ... -- 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 Dashboard - Feature #3535] (Unreviewed) Show an extra state beside success or failed, modified
Issue #3535 has been reported by Stefan Goethals. Feature #3535: Show an extra state beside success or failed, modified http://projects.puppetlabs.com/issues/3535 Author: Stefan Goethals Status: Unreviewed Priority: Normal Assigned to: Category: Target version: Keywords: Branch: In the list there are now 2 states, failed or modified. It would be useful to get a different status with a yellow/orange bullet if anything was changed at all by the 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.
[Puppet Dashboard - Feature #3536] (Unreviewed) See if a node is reporting within the expected timeperiod
Issue #3536 has been reported by Stefan Goethals. Feature #3536: See if a node is reporting within the expected timeperiod http://projects.puppetlabs.com/issues/3536 Author: Stefan Goethals Status: Unreviewed Priority: Normal Assigned to: Category: Target version: Keywords: Branch: It might be useful to have a 'delayed' status. This would be displayed if a node has not reported within a configurable delay. As the normal runs happen every 30 minutes by default, i would configure this for example at 2 hours. Any node not reported in that period should be flagged as such. -- 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 #3537] (Unreviewed) It should be possible to trigger (exec) resources with require
Issue #3537 has been reported by Kjetil Torgrim Homme.
Feature #3537: It should be possible to trigger (exec) resources with require
http://projects.puppetlabs.com/issues/3537
Author: Kjetil Torgrim Homme
Status: Unreviewed
Priority: Normal
Assigned to:
Category:
Target version:
Affected version: 0.25.4
Keywords:
Branch:
When an Exec has conditions associated with it (unless, creates, onlyif), it
can be useful to be state prerequisites which are only run when the exec itself
is run.
Consider this simple example::
exec { prereq:
command = /bin/echo prereq,
refreshonly = true
}
exec { main:
command = /bin/echo main,
onlyif = /bin/grep foobar /etc/issue,
require = Exec[prereq]
}
Here, the refreshonly will cause prereq to never run, since a require isn't
enough to trigger it. Without refreshonly, it will run every time, but the
desired behaviour is that prereq is run iff the onlyif command succeeds.
Obviously the behaviour of refreshonly = true can't change, and I can't
think of a good name for a tri-state alternative -- refreshonly =
'requires-too' ? allevents may be more workable.
My prefered solution would be a new parameter requireonly. Perhaps slightly
misleading name, since before should trigger execution, too, but I think most
people will understand that require/before are inherently intertwined. This
could later be generalised into a metaparameter to work for more types, e.g.
you could have a parent File which is only checked/updated/created when some
other File requires it.
--
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.
[Facter - Feature #3367] Path to ssh key
Issue #3367 has been updated by Mark Plaksin.
Here's the fact we use to find the verison. It assumes you're running the most
recent version (of the versions installed), which we always are:
pre
Facter.add(tww_ssh_version) do
setcode do
unless Dir.glob('/opt/TWWfsw/openssh*').empty?
Dir.new('/opt/TWWfsw').find{|d|
/openssh/.match(d)}.sort.last.delete('openssh')
end
end
end
/pre
Feature #3367: Path to ssh key
http://projects.puppetlabs.com/issues/3367
Author: Mark Plaksin
Status: Needs more information
Priority: Normal
Assigned to:
Category: library
Target version:
Keywords:
Branch:
It would be great if we could specify the location(s) that facter looks for
ssh keys.
Currently ssh.rd looks for ssh keys in these directories:
[/etc/ssh,/usr/local/etc/ssh,/etc,/usr/local/etc]
This works great on our Linux boxes but we use thewrittenword.com's SSH on
our Solaris and HP-UX boxes. The key is in /etc/opt/TWWfsw/openssh47 and,
of course, the version changes sometimes so it might be in
/etc/opt/TWWfsw/openssh52, etc.
Thanks!
--
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.
[Facter - Feature #3403] Fact for query vlans
Issue #3403 has been updated by Jonas Genannt. Branch set to http://github.com/hggh/facter/commit/7dd8ca90c024b50ad3fb3ba40ff6a07552ea1db0 This fact works on Linux. I have added an confine. I have also written an spec for that fact. http://github.com/hggh/facter/commit/7dd8ca90c024b50ad3fb3ba40ff6a07552ea1db0 Feature #3403: Fact for query vlans http://projects.puppetlabs.com/issues/3403 Author: Jonas Genannt Status: Code Insufficient Priority: Normal Assigned to: Category: library Target version: Keywords: vlan,interface,network Branch: http://github.com/hggh/facter/commit/7dd8ca90c024b50ad3fb3ba40ff6a07552ea1db0 I have written an little fact to get the active vlans on an server. This fact works on debian lenny and etch. Feel free to include it into facter. -- 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 #3538] (Unreviewed) Yum provider using version-release to validate installation.
Issue #3538 has been reported by Tony Garcia.
Bug #3538: Yum provider using version-release to validate installation.
http://projects.puppetlabs.com/issues/3538
Author: Tony Garcia
Status: Unreviewed
Priority: Normal
Assigned to:
Category:
Target version: unplanned
Affected version: 0.25.4
Keywords:
Branch:
When using yum provider Puppet complains(error output) when using only the
version(string) of the package to install or installed at the time of
verification.
$snmp_version = 5.3.2.2
package { net-snmp: ensure = ${snmp_version}; }
Client output:
debug: //Node[client.example.com]/snmp::base/Package[net-snmp]: Changing
ensure
debug: //Node[client.example.com]/snmp::base/Package[net-snmp]: 1 change(s)
debug: Package[net-snmp](provider=yum): Ensuring = 5.3.2.2
**(1)** debug: Puppet::Type::Package::ProviderYum: Executing '/usr/bin/yum -d 0
-e 0 -y install net-snmp-5.3.2.2'
**(2)** debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q
net-snmp --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}|
%{VERSION} %{RELEASE} %{ARCH}
'
err: //Node[client.example.com]/snmp::base/Package[net-snmp]/ensure: change
from 5.3.2.2-7.el5_4.2 to 5.3.2.2 failed: Could not update: Failed to update to
version 5.3.2.2, got version 5.3.2.2-7.el5_4.2 instead at
/opt/git/development/modules/snmp/manifests/init.pp:26
notice: //Node[client.example.com]/snmp::base/File[/etc/snmp/snmpd.conf]:
Dependency package[net-snmp] has 1 failures
warning:
//Node[labtest40-v3.ea-colo.ea.com]/snmp::base/File[/etc/snmp/snmpd.conf]:
Skipping because of failed dependencies
The package is installed **(1)** but the error is still shown at the time of
validation **(2)**, same situation if package is already installed.
in .../provider/package/yum.rb:
pre
def install
chop lines ---
is = self.query
unless is
raise Puppet::Error, Could not find package %s % self.name
end
# FIXME: Should we raise an exception even if should == :latest
# and yum updated us to a version other than @param_hash[:ensure] ?
if should should != is[:ensure]
raise Puppet::Error, Failed to update to version #{should}, got
version #{is[:ensure]} instead
end
/pre
The error arises as **should** is not equal to **is[:ensure]**
in .../provider/package/rpm.rb the query define comment says it will provide
the **version-release**
pre
# Find the fully versioned package name and the version alone. Returns
# a hash with entries :instance = fully versioned package name, and
# :ensure = version-release
def query
/pre
The validation is made in the ensure attribute($snmp_version) string against
version-release installed. It makes sense when somebody defines something
like ensure = ${snmp_version}-${snmp-release}, but not in this use case.
Tested in 0.24.8 but reported also on 0.25.4.
rpm.rb and yum.rb are not behaving in the same way as yum cli behaves.
--
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 #3539] (Unreviewed) Ability to accept skel directory in user management
Issue #3539 has been reported by William Valadez. Feature #3539: Ability to accept skel directory in user management http://projects.puppetlabs.com/issues/3539 Author: William Valadez Status: Unreviewed Priority: Normal Assigned to: Category: Target version: Affected version: 0.25.4 Keywords: Branch: I would like to request a feature within the user type to enable the use of a local skeleton directory. This would be similar to the --skel flag in useradd. I'm not wanting to keep the files sync'd over time, only to populate some initial file stubs when a user account is created. For instance, create a ~$user/.my.cnf file that has some default values, but that the user can overwrite if they want to. The idea being that we could manage the contents of skel in the puppet repository and when local user accounts are created they get these file stubs from the skel directory. -- 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.
[Facter - Feature #3403] (Accepted) Fact for query vlans
Issue #3403 has been updated by James Turnbull. Status changed from Code Insufficient to Accepted Target version set to 1.5.8 Feature #3403: Fact for query vlans http://projects.puppetlabs.com/issues/3403 Author: Jonas Genannt Status: Accepted Priority: Normal Assigned to: Category: library Target version: 1.5.8 Keywords: vlan,interface,network Branch: http://github.com/hggh/facter/commit/7dd8ca90c024b50ad3fb3ba40ff6a07552ea1db0 I have written an little fact to get the active vlans on an server. This fact works on debian lenny and etch. Feel free to include it into facter. -- 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 #3520] (Rejected) removing maillist uses huge amount of memory
Issue #3520 has been updated by Peter Meier. Status changed from Needs design decision to Rejected I'm closing that one as I think I have found the actual problem and will open a new bug report with the appropriate description Bug #3520: removing maillist uses huge amount of memory http://projects.puppetlabs.com/issues/3520 Author: Peter Meier Status: Rejected Priority: Normal Assigned to: Category: maillist Target version: Affected version: 0.25.5rc1 Keywords: Branch: Setting a maillist resource to absent causes to puppet to use a huge amount of memory (up to 1G and then my server was often knocked out or I remembered that bug and terminated puppet). My guess is that this seems to happen because maillist removes the archive directories etc. which can be pretty huge. But if I remove first the archive directories by hand and then run puppet it removes a maillist immediately and as it should. So somewhere in calling @rmlist@ there is something that causes to allocate that much memory. Unfortunately if you run it it with --debug --verbose etc. it won't tell you anything it just hangs at the same position where it would hang in normal mode. -- 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 #3540] (Unreviewed) Maillist removing broken
Issue #3540 has been reported by Peter Meier.
Bug #3540: Maillist removing broken
http://projects.puppetlabs.com/issues/3540
Author: Peter Meier
Status: Unreviewed
Priority: Normal
Assigned to:
Category: maillist
Target version: 0.25.5
Affected version: 0.25.5rc1
Keywords:
Branch:
Given the following manifest:
pre
maillist{'foo':
ensure = absent,
admin = 'foo...@example.com',
mailserver = 'lists.example.com',
password = 'foobar',
webserver = 'example.com'
}
/pre
We get the following stracktrace:
pre
info: Applying configuration version '1271107469'
debug: //Maillist[foo]: Changing ensure
debug: //Maillist[foo]: 1 change(s)
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:414:in `set_absent'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:109:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:109:in `call_valuemethod'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:298:in `set'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:363:in `sync'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction/change.rb:54:in `go'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction/change.rb:72:in `forward'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:120:in `apply_changes'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:113:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:113:in `apply_changes'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:85:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:253:in
`eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/benchmark.rb:10:in
`realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:252:in
`eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:207:in `eval_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:298:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/benchmark.rb:10:in
`realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:297:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:291:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:291:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppet.rb:132:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/bin/puppet:71
err: //Maillist[foo]/ensure: change from present to absent failed: Could not
set absent on ensure: undefined method `destroy' for #Puppet::Type:
:Maillist:0x2aab5d14b670 at /root/foo.pp:7
/pre
While setting the @absent = purged@ works.
Patch following...
--
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 #3540] Maillist removing broken
Issue #3540 has been updated by Peter Meier.
Branch set to http://github.com/duritong/puppet/tree/tickets/0.25.x/3540
Bug #3540: Maillist removing broken
http://projects.puppetlabs.com/issues/3540
Author: Peter Meier
Status: Unreviewed
Priority: Normal
Assigned to:
Category: maillist
Target version: 0.25.5
Affected version: 0.25.5rc1
Keywords:
Branch: http://github.com/duritong/puppet/tree/tickets/0.25.x/3540
Given the following manifest:
pre
maillist{'foo':
ensure = absent,
admin = 'foo...@example.com',
mailserver = 'lists.example.com',
password = 'foobar',
webserver = 'example.com'
}
/pre
We get the following stracktrace:
pre
info: Applying configuration version '1271107469'
debug: //Maillist[foo]: Changing ensure
debug: //Maillist[foo]: 1 change(s)
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:414:in `set_absent'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:109:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:109:in `call_valuemethod'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:298:in `set'
/usr/lib/ruby/site_ruby/1.8/puppet/property.rb:363:in `sync'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction/change.rb:54:in `go'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction/change.rb:72:in `forward'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:120:in `apply_changes'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:113:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:113:in `apply_changes'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:85:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:253:in
`eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/benchmark.rb:10:in
`realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:252:in
`eval_children_and_apply_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:207:in `eval_resource'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:298:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:418:in `thinmark'
/usr/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/benchmark.rb:10:in
`realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:417:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:297:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:291:in `collect'
/usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:291:in `evaluate'
/usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:142:in `apply'
/usr/lib/ruby/site_ruby/1.8/puppet/application/puppet.rb:132:in `main'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `send'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:226:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:217:in `run'
/usr/bin/puppet:71
err: //Maillist[foo]/ensure: change from present to absent failed: Could not
set absent on ensure: undefined method `destroy' for #Puppet::Type:
:Maillist:0x2aab5d14b670 at /root/foo.pp:7
/pre
While setting the @absent = purged@ works.
Patch following...
--
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.
[Facter - Bug #3541] Ruby 1.9: broken unittest, unexpected invocation: Process.waitall()
Issue #3541 has been updated by Jos Backus. File bug-3541.diff added Bug #3541: Ruby 1.9: broken unittest, unexpected invocation: Process.waitall() http://projects.puppetlabs.com/issues/3541 Author: Jos Backus Status: Unreviewed Priority: Normal Assigned to: Category: library Target version: Keywords: Branch: When running the Facter unit tests, the following failure is seen: Facter::Util::Resolution when returning the value and the code is a block -- should waitall to avoid zombies if the timeout is exceeded (FAILED - 1) 1) Mocha::ExpectationError in 'Facter::Util::Resolution when returning the value and the code is a block should waitall to avoid zombies if the timeout is exceeded' unexpected invocation: Process.waitall() satisfied expectations: - allowed any number of times, already invoked once: #Facter::Util::Resolution:0x98cb5b8.warn(any_parameters) - expected exactly once, already invoked once: Thread.new(any_parameters) - expected exactly once, already invoked once: Process.waitall(any_parameters) -- 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.
[Facter - Bug #3541] Ruby 1.9: broken unittest, unexpected invocation: Process.waitall()
Issue #3541 has been updated by Jos Backus. Target version set to 1.5.8 Note that I'm stumped as to why the suggested patch fixes the issue. Bug #3541: Ruby 1.9: broken unittest, unexpected invocation: Process.waitall() http://projects.puppetlabs.com/issues/3541 Author: Jos Backus Status: Unreviewed Priority: Normal Assigned to: Category: library Target version: 1.5.8 Keywords: Branch: When running the Facter unit tests, the following failure is seen: Facter::Util::Resolution when returning the value and the code is a block -- should waitall to avoid zombies if the timeout is exceeded (FAILED - 1) 1) Mocha::ExpectationError in 'Facter::Util::Resolution when returning the value and the code is a block should waitall to avoid zombies if the timeout is exceeded' unexpected invocation: Process.waitall() satisfied expectations: - allowed any number of times, already invoked once: #Facter::Util::Resolution:0x98cb5b8.warn(any_parameters) - expected exactly once, already invoked once: Thread.new(any_parameters) - expected exactly once, already invoked once: Process.waitall(any_parameters) -- 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.
[Facter - Bug #3542] (Unreviewed) Ruby 1.9: broken unittest, String#each no longer exists
Issue #3542 has been reported by Jos Backus. Bug #3542: Ruby 1.9: broken unittest, String#each no longer exists http://projects.puppetlabs.com/issues/3542 Author: Jos Backus Status: Unreviewed Priority: Normal Assigned to: Category: Target version: 1.5.8 Keywords: Branch: When running the Facter unit tests under Ruby 1.9, the following failure is seen: 1) NoMethodError in 'Facter when warning should warn if debugging is enabled' undefined method `each' for foo:String /home/josb/src/facter/spec/unit/facter.rb:147:in `block (3 levels) in top (required)' -- 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.
[Facter - Bug #3542] Ruby 1.9: broken unittest, String#each no longer exists
Issue #3542 has been updated by Jos Backus. File bug-3542.diff added Bug #3542: Ruby 1.9: broken unittest, String#each no longer exists http://projects.puppetlabs.com/issues/3542 Author: Jos Backus Status: Unreviewed Priority: Normal Assigned to: Category: Target version: 1.5.8 Keywords: Branch: When running the Facter unit tests under Ruby 1.9, the following failure is seen: 1) NoMethodError in 'Facter when warning should warn if debugging is enabled' undefined method `each' for foo:String /home/josb/src/facter/spec/unit/facter.rb:147:in `block (3 levels) in top (required)' -- 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.
[Facter - Bug #2614] Ruby 1.9 support - remove any deprecated/gone library calls
Issue #2614 has been updated by Jos Backus. Fwiw, file.c in 1.9.2 trunk as of today still has: define_filetest_function(exist?, rb_file_exist_p, 1); define_filetest_function(exists?, rb_file_exist_p, 1); Do we still want to do this? The specs pass on 1.9. Bug #2614: Ruby 1.9 support - remove any deprecated/gone library calls http://projects.puppetlabs.com/issues/2614 Author: Paul Nasrat Status: Accepted Priority: Normal Assigned to: Paul Nasrat Category: Target version: 1.6.0 Keywords: Branch: From discussion on list AFAIK, FileTest.exists? goes away in ruby1.9 and should be FileTest.exist? Make sure facter and tests run clean on 1.9.x -- 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.
[Facter - Bug #2609] install.rb will not run on ruby 1.9.1 due to ftools being deprecated
Issue #2609 has been updated by Jos Backus. Why not simply use FileUtils always? It should work with both 1.8 and 1.9. Bug #2609: install.rb will not run on ruby 1.9.1 due to ftools being deprecated http://projects.puppetlabs.com/issues/2609 Author: Al Hoang Status: Accepted Priority: Low Assigned to: Paul Nasrat Category: Target version: 1.6.0 Keywords: Branch: Hi, Due to ftools being deprecated in Ruby 1.9.1 (See http://redmine.ruby-lang.org/issues/show/1401), install.rb for facter will not run properly without modifications. Attached is a patch that should let facter use ftools if it is available or use fileutils if ftools cannot be found. I have tested installing facter 1.5.6 with this patch using Ruby 1.9.1p243 on a Debian Lenny box -- 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.
[Facter - Bug #2609] install.rb will not run on ruby 1.9.1 due to ftools being deprecated
Issue #2609 has been updated by Jos Backus. File bug-2609.diff added The patch also fixes a mode issue in the man directories (was 0644, should probably be 0755). Bug #2609: install.rb will not run on ruby 1.9.1 due to ftools being deprecated http://projects.puppetlabs.com/issues/2609 Author: Al Hoang Status: Accepted Priority: Low Assigned to: Paul Nasrat Category: Target version: 1.6.0 Keywords: Branch: Hi, Due to ftools being deprecated in Ruby 1.9.1 (See http://redmine.ruby-lang.org/issues/show/1401), install.rb for facter will not run properly without modifications. Attached is a patch that should let facter use ftools if it is available or use fileutils if ftools cannot be found. I have tested installing facter 1.5.6 with this patch using Ruby 1.9.1p243 on a Debian Lenny box -- 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 #3543] (Unreviewed) undefined method `each' for nil:NilClass
Issue #3543 has been reported by micah -. Bug #3543: undefined method `each' for nil:NilClass http://projects.puppetlabs.com/issues/3543 Author: micah - Status: Unreviewed Priority: Normal Assigned to: Category: Target version: Affected version: 0.25.4 Keywords: Branch: I'm running with 0.25.4, with the dbconnections configuration variable fix (#2568) cherry-picked in. I've been getting some logs on my puppetmaster as follows: pre puppetmasterd[25058]: undefined method `each' for nil:NilClass at /etc/puppet/modules/runlevel/manifests/init.pp:67 on node xxx puppetmasterd[25086]: undefined method `each' for nil:NilClass on node puppetmasterd[25114]: undefined method `each' for nil:NilClass at /etc/puppet/modules/nagios/manifests/base.pp:80 on node xxx.riseup.net /pre I was getting these in a previous release, but they were fixed by #2863, however they have come back. I checked the code that was changed in #2863, and it still exists, so that wasn't removed. I have been having difficulties recently with storedconfig connections to the database causing catalog compiles to either take thousands of seconds, or spit out an error like this: pre Apr 12 18:14:05 puppetmaster puppetmasterd[11219]: could not obtain a database connection within 5 seconds. The max pool size is currently 5; consider increasing it. /pre I added the dbconnections bit so I could increase that value, but quickly went from setting it to 10, to now 40 and I am still getting the error (although the max pool size is reported as 40 now, instead of 5 of course). I dont know if the nil:NilClass errors are caused when that happens, or if they are different issues. -- 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 #3523] Unit test error: test_data_parsing_and_generating(TestMailaliasAliasesProvider): Puppet::DevError: No fakedata matching /usr/share/test/data/types/mailalias/*
Issue #3523 has been updated by Mathias Gug. In ubuntu the test suite is packaged as a separate binary package. The goal is to be able to run the test suite on a system with the puppet packages installed. All of the test suite is installed in /usr/share/puppet-testsuite/ - see http://packages.ubuntu.com/lucid/all/puppet-testsuite/filelist There are some assumptions in the test code about the location of the base test directory (the test string is hardcoded). So we need to patch the test code to pick up the correct location of the base test directory. One option could be to make the base test directory configurable (ex: run_test --base-dir=/usr/share/puppet-testsuite). Bug #3523: Unit test error: test_data_parsing_and_generating(TestMailaliasAliasesProvider): Puppet::DevError: No fakedata matching /usr/share/test/data/types/mailalias/* http://projects.puppetlabs.com/issues/3523 Author: Mathias Gug Status: Needs more information Priority: Normal Assigned to: Category: testing Target version: Affected version: 0.25.4 Keywords: Branch: While trying to run the puppet unittest on Ubuntu Lucid the following error was thrown: 7) Error: test_data_parsing_and_generating(TestMailaliasAliasesProvider): Puppet::DevError: No fakedata matching /usr/share/test/data/types/mailalias/* /usr/share/puppet-testsuite/lib/puppettest/support/utils.rb:160:in `fakedata' ./ral/providers/mailalias/aliases.rb:50:in `test_data_parsing_and_generating' /usr/lib/ruby/1.8/mocha/integration/test_unit/ruby_version_186_and_above.rb:19:in `__send__' /usr/lib/ruby/1.8/mocha/integration/test_unit/ruby_version_186_and_above.rb:19:in `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.
[Puppet - Feature #3537] (Rejected) It should be possible to trigger (exec) resources with require
Issue #3537 has been updated by Luke Kanies.
Status changed from Unreviewed to Rejected
Can't you just use 'subscribe' here instead of require?
If I'm missing something, please reopen the ticket.
Feature #3537: It should be possible to trigger (exec) resources with require
http://projects.puppetlabs.com/issues/3537
Author: Kjetil Torgrim Homme
Status: Rejected
Priority: Normal
Assigned to:
Category:
Target version:
Affected version: 0.25.4
Keywords:
Branch:
When an Exec has conditions associated with it (unless, creates, onlyif), it
can be useful to be state prerequisites which are only run when the exec itself
is run.
Consider this simple example::
exec { prereq:
command = /bin/echo prereq,
refreshonly = true
}
exec { main:
command = /bin/echo main,
onlyif = /bin/grep foobar /etc/issue,
require = Exec[prereq]
}
Here, the refreshonly will cause prereq to never run, since a require isn't
enough to trigger it. Without refreshonly, it will run every time, but the
desired behaviour is that prereq is run iff the onlyif command succeeds.
Obviously the behaviour of refreshonly = true can't change, and I can't
think of a good name for a tri-state alternative -- refreshonly =
'requires-too' ? allevents may be more workable.
My prefered solution would be a new parameter requireonly. Perhaps slightly
misleading name, since before should trigger execution, too, but I think most
people will understand that require/before are inherently intertwined. This
could later be generalised into a metaparameter to work for more types, e.g.
you could have a parent File which is only checked/updated/created when some
other File requires it.
--
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 #3533] (Ready for Testing) Fix inefficient transaction cleanup
Issue #3533 has been updated by Luke Kanies. Status changed from Unreviewed to Ready for Testing Assigned to set to Markus Roberts Branch set to luke/tickets/0.25.x/3533-no_transaction_cleanup I've pushed code to my tickets/0.25.x/3533-no_transaction_cleanup branch that does exactly this. Bug #3533: Fix inefficient transaction cleanup http://projects.puppetlabs.com/issues/3533 Author: Peter Meier Status: Ready for Testing Priority: High Assigned to: Markus Roberts Category: transactions Target version: 0.25.5 Affected version: 0.25.5rc1 Keywords: Branch: luke/tickets/0.25.x/3533-no_transaction_cleanup As discussed in http://groups.google.com/group/puppet-dev/browse_thread/thread/aea82ebc860285b2 the cleanup of transactions is inefficient and should be improved. -- 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 #3529] (Accepted) Impossible to add multiple entries for the same host
Issue #3529 has been updated by Luke Kanies.
Status changed from Needs design decision to Accepted
This is basically not possible with how keys are managed, at least for as long
as Puppet only supports a single primary key.
Isn't this doable by just adding the IP address as a second alias to the host?
E.g.:
pre
server.corp.example.com,192.168.67.62,192.168.67.60 ssh-rsa
B3NzaC1yc2EBIwAAAQEAzsg+BglE1A7y9Dw6aiCEB3F8SJxXpd+AJ8DvTmk/Vr00fRO8zL1cY2Nggj6WD+YcjuXWpzbsc/kE3HCjXe7kHInx2Hz4aTVtNO9h2pi7n3hFWRjdN/4D3nsmPy+xxJGQ4AIRjf1+t1npCltvqS4qOhMybl4f92IyeuIETD3IGpBU3T0bQJRCZqQ8ggkalXbREHJcEN49IsHzzJcf4VBEaOMuJKVXx+T7cL4KyfYxNCbmFA6Ezdx+C65fB+g3PKfs9neAbdk1vnFCV3NXHbloSN3USNOe3hhTO4QBzSh1WjXA6q6Zoe9NLwIHXhrQOcltH4DJ/J5ob0qxyUrwB3SvRw==
/pre
Note I haven't tried it, I just think it works.
Bug #3529: Impossible to add multiple entries for the same host
http://projects.puppetlabs.com/issues/3529
Author: Andrew Pollock
Status: Accepted
Priority: Normal
Assigned to: Luke Kanies
Category: ssh
Target version:
Affected version: 0.25.4
Keywords:
Branch:
In deployment, we have a server that resolves to different IP addresses in
different locations (via a DNS view).
We'd like to be able to add the SSH host key of both IP addresses to
/etc/ssh/ssh_known_hosts, but can't because of the way the sshkey type is
currently implemented.
Here's an example of what we want to get:
pre
server.corp.example.com,192.168.67.62 ssh-rsa
B3NzaC1yc2EBIwAAAQEAzsg+BglE1A7y9Dw6aiCEB3F8SJxXpd+AJ8DvTmk/Vr00fRO8zL1cY2Nggj6WD+YcjuXWpzbsc/kE3HCjXe7kHInx2Hz4aTVtNO9h2pi7n3hFWRjdN/4D3nsmPy+xxJGQ4AIRjf1+t1npCltvqS4qOhMybl4f92IyeuIETD3IGpBU3T0bQJRCZqQ8ggkalXbREHJcEN49IsHzzJcf4VBEaOMuJKVXx+T7cL4KyfYxNCbmFA6Ezdx+C65fB+g3PKfs9neAbdk1vnFCV3NXHbloSN3USNOe3hhTO4QBzSh1WjXA6q6Zoe9NLwIHXhrQOcltH4DJ/J5ob0qxyUrwB3SvRw==
server.corp.example.com,192.168.128.60 ssh-rsa
B3NzaC1yc2EBIwAAAQEAu/bQRbOuUL1cllXy+2TGT2YIhjlxZxXDWXtcFs994n95LgACvjOY7ZNFlF3QXy3WeIsdM+Y4+tlV5UCgneMU7m9NdsBejJMIHBucWcx3gx/yuLfUR0Bd4D/gDAPTGpcFE+KPxCP3i/IMOyG3cCJWHv1iBfbIV2QQI1m8LwsLbmgoVwv6QwetJw+6GamV8xKrgQMWnAwQx1nIaRjWYJAeZDBY/vZEnYwtpsju8c3VUqaw3J59hYMg0IE3dMDOEtbBn31/RNIwoM87XLzHrQrRNyADjxy4OI2gIOzOrjYzBtP+v2JLvEGyVc/xupxBh0gewhx4otHHA5Bk/u8AJcpMjQ==
/pre
Here's how I'm trying to do it:
pre
sshkey { server.corp.example.com:
alias = [server.corp.example.com, 192.168.67.62],
key=
B3NzaC1yc2EBIwAAAQEAzsg+BglE1A7y9Dw6aiCEB3F8SJxXpd+AJ8DvTmk/Vr00fRO8zL1cY2Nggj6WD+YcjuXWpzbsc/kE3HCjXe7kHInx2Hz4aTVtNO9h2pi7n3hFWRjdN/4D3nsmPy+xxJGQ4AIRjf1+t1npCltvqS4qOhMybl4f92IyeuIETD3IGpBU3T0bQJRCZqQ8ggkalXbREHJcEN49IsHzzJcf4VBEaOMuJKVXx+T7cL4KyfYxNCbmFA6Ezdx+C65fB+g3PKfs9neAbdk1vnFCV3NXHbloSN3USNOe3hhTO4QBzSh1WjXA6q6Zoe9NLwIHXhrQOcltH4DJ/J5ob0qxyUrwB3SvRw==,
type = rsa,
ensure = present,
}
sshkey { server.site1.corp.example.com:
alias = [server.corp.example.com, 192.168.128.60],
key=
B3NzaC1yc2EBIwAAAQEAu/bQRbOuUL1cllXy+2TGT2YIhjlxZxXDWXtcFs994n95LgACvjOY7ZNFlF3QXy3WeIsdM+Y4+tlV5UCgneMU7m9NdsBejJMIHBucWcx3gx/yuLfUR0Bd4D/gDAPTGpcFE+KPxCP3i/IMOyG3cCJWHv1iBfbIV2QQI1m8LwsLbmgoVwv6QwetJw+6GamV8xKrgQMWnAwQx1nIaRjWYJAeZDBY/vZEnYwtpsju8c3VUqaw3J59hYMg0IE3dMDOEtbBn31/RNIwoM87XLzHrQrRNyADjxy4OI2gIOzOrjYzBtP+v2JLvEGyVc/xupxBh0gewhx4otHHA5Bk/u8AJcpMjQ==,
type = rsa,
ensure = present,
}
/pre
This doesn't work because of the duplicate aliases.
So I've got a problem where I don't really care what the resource is named in
Puppet, but I want to influence the hostname(s) added to
/etc/ssh/ssh_known_hosts. I'm unable to do this because of the tight coupling
between the name of the Puppet resource, and what goes into the known_hosts
file, as well as aliases defining something inside of Puppet as well as what
goes into the 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.
