[Facter - Feature #3937] (Code Insufficient) mounts list
Issue #3937 has been updated by James Turnbull.
Category set to library
Status changed from Unreviewed to Code Insufficient
Target version set to unplanned
This is a bit too Linux centric to be accepted as a generic fact.
Feature #3937: mounts list
http://projects.puppetlabs.com/issues/3937
Author: Mario Verbelen
Status: Code Insufficient
Priority: Normal
Assigned to:
Category: library
Target version: unplanned
Keywords:
Branch:
I use myself a mount list for monitoring purposes
So here the code I use
mounts.rb
preFacter.add(mounts) do
mounts = []
mntpoints=`mount -t ext2,ext3,ext4,reiserfs`
mntpoints.split(/\n/).each do |m|
mount = m.split(/ /)[2]
mounts mount
end
setcode do
mounts.join(',')
end
end/pre
output:
pre10:48:15|r...@leo:~ 0 # facter mounts
/,/boot,/home,/usr,/var,/tmp,/data/pre
In the template for snmpd.conf.erb I use
pre%- if has_variable?(mounts) then
mounts.split(',').each do |val| -%
disk %= val %
% end end -%/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.
[Facter - Bug #3713] (Needs design decision) ipaddress fact doesn't function properly with dummy interfaces (linux)
Issue #3713 has been updated by James Turnbull. Status changed from Unreviewed to Needs design decision Assigned to set to Paul Nasrat You're probably closer to this than me Paul. Bug #3713: ipaddress fact doesn't function properly with dummy interfaces (linux) http://projects.puppetlabs.com/issues/3713 Author: Benjamin Kite Status: Needs design decision Priority: Normal Assigned to: Paul Nasrat Category: library Target version: Keywords: Branch: Since dummy devices appear alphabetically before eth devices under linux, the dummy device IP is taking precedence over eth0, making the default IP the dummy one (probably not the best idea, especially if you re-use your dummy address). A simple fix might be to apply similar logic as later in the file, which presumes the default route is on the lead interface. A patch to this effect is attached. -- 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 #3929] (Ready for Testing) Unvalidated swap -l output in facter on AIX 6.1
Issue #3929 has been updated by James Turnbull. Category set to library Status changed from Unreviewed to Ready for Testing Branch set to http://github.com/jamtur01/facter/tree/tickets/master/3929 Bug #3929: Unvalidated swap -l output in facter on AIX 6.1 http://projects.puppetlabs.com/issues/3929 Author: Hector Rivas Status: Ready for Testing Priority: Low Assigned to: Category: library Target version: 1.5.8 Keywords: Branch: http://github.com/jamtur01/facter/tree/tickets/master/3929 if swap -l fails (in my case, a normal user can not execute swap -l), facter will fail: $ facter /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/memory.rb:26: undefined method `each' for nil:NilClass (NoMethodError) from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:73:in `load' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:73:in `load_file' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:38:in `load_all' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:33:in `each' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:33:in `load_all' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:30:in `each' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/loader.rb:30:in `load_all' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter/util/collection.rb:90:in `load_all' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/lib/facter.rb:91:in `to_hash' from /usr/local/stow/ruby-1.8.7-p174-aix61/lib/ruby/gems/1.8/gems/facter-1.5.7/bin/facter:138 from /usr/local/bin/facter:19:in `load' from /usr/local/bin/facter:19 -- 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 #3909] (Needs design decision) Facter does not behave properly with non-existent top-level domains.
Issue #3909 has been updated by James Turnbull.
Category set to library
Status changed from Unreviewed to Needs design decision
Bug #3909: Facter does not behave properly with non-existent top-level domains.
http://projects.puppetlabs.com/issues/3909
Author: Joe McDonagh
Status: Needs design decision
Priority: Normal
Assigned to:
Category: library
Target version:
Keywords:
Branch:
On behalf of a puppet-users posted who did not want to create an additional
login to file a bug:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
I was stumbling over the fact that I use a (not existing) toplevel
domain in my environment. So I set up the dnsdomainname to print out the
correct domain (without fullstop ('.')). Additional I limited the search
path in resolv.conf to end with a '.'.
That seems to tangle facter. As I read the code it needs a '.' anywhere
in domainname to work and the fallback to parse /etc/resolv.conf cannot
handle trailing '.'. The last is easy to handle by $1.sub(/\.$/, '') but
the first I do not know how to handle correctly for every case (At least
on debian there seems to be '(none)' if it is not defined correctly.)
Could that go into upstream code respective how to fix the first case
proper?
Regards
Klaus Ethgen
- --
Klaus Ethgenhttp://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEVAwUBS/xBU5+OKpjRpO3lAQpDUgf7B8gw4EqNTZO4HemjLzFRkR6tQqUm/fFm
eHvzgjmfktshgxak8vrq0hvU6njC8BG/aloNvDBwdwJYFqn/L9iJRTVouqzp4G0Z
pAiRGgFvn/itVuK5tpenuJF7nBtZkDjhDhNxwSCwxfc4l+aFPTSgj50Isor2cieQ
iK0RXQH6O00vtvuFL8eWnHwTKD4hd4pCv2XSB4O3tprxZK8y7/NxdD5b/ikcv7VW
s3K4iD6iqZozsN9uEEJIh1ZAbLLkmYBEYJOdtElj/pPw2gcdeLnZGF7P/H9vdu00
qU1KA7kyo8u4PuctCTvuBdMrtPHxg5MGt9HGfN1/1rgw7aBaO5IEzA==
=Q4PY
-END PGP SIGNATURE-
--
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 #3926] (Needs design decision) uniqueid not unique enough
Issue #3926 has been updated by James Turnbull. Category set to library Status changed from Unreviewed to Needs design decision Hmmm this probably won't help with all OSes. Think this needs more thought. Bug #3926: uniqueid not unique enough http://projects.puppetlabs.com/issues/3926 Author: Greg Maples Status: Needs design decision Priority: Normal Assigned to: Category: library Target version: Affected version: 0.25.4 Keywords: Branch: basing it on hostid is not nearly unique enough especially in a xen environment with duplicated machines and multiple instances of IPs and MACs. I'd suggest something like serial number from BIOS (works for dell, hp, ibm, etc - significant portion of all x86 machines) modified by the system time when facter was initially installed. -- 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 #3922] Ssh_authorized_key Could not apply complete catalog: Could not back up
Issue #3922 has been updated by Jason Koppe.
I'm having a similar issue after an upgrade from puppet 0.25.0 (src/compiled)
to puppet-0.25.5-1.el5 (rpm). It's only happening to a user that has two keys.
I changed the target of the second key to target a different file
(authorized_keys2) and everything runs fine.
Bug #3922: Ssh_authorized_key Could not apply complete catalog: Could not back
up
http://projects.puppetlabs.com/issues/3922
Author: mélanie Gault
Status: Investigating
Priority: Normal
Assigned to: Matt Robinson
Category: ssh
Target version:
Affected version: 0.25.5
Keywords: backup clientbucket catalog Ssh_authorized_key
Branch:
I manage user, directories, ssh_authorized_key, ... on redhat 4 and 5 boxes
with a master and a client with 0.25.5 version.
My puppet client runs as root and my maser with the user puppet.
Everything works fine for some of my users, but I got an error with
clientbucket directory :
preinfo: Caching catalog for puppet-client
info: Applying configuration version '1275367180'
notice: //users/My::User[my.user]/Ssh_authorized_key[my.user]/ensure: created
err: Could not apply complete catalog: Could not back up
/home/my.user/.ssh/authorized_keys: Permission denied -
/var/lib/puppet/clientbucket/f
notice: Finished catalog run in 3.52 seconds/pre
If I create manualy this directory I got the same error for
/var/lib/puppet/clientbucket/f/6 next for /var/lib/puppet/clientbucket/f/6/9...
And at the end I have :
pre[r...@monserveur: i386 ]$ puppetd --server my-puppet -t -o
info: Caching catalog for puppet-client
info: Applying configuration version '1275367180'
notice: //users/My::User[my.user]/Ssh_authorized_key[my.user]/ensure: created
err: Could not apply complete catalog: Could not back up
/home/my.user/.ssh/authorized_keys: Permission denied -
/var/lib/puppet/clientbucket/f/6/9/4/9/5/1/7/f6949517cbf4fddfa665d41361f8bce4
notice: Finished catalog run in 3.69 seconds/pre
manifest citation :
pre ssh_authorized_key { $name:
ensure = $ensure,
type = dsa,
key= $key,
user = $name,
require = File[/home/$name/.ssh],
}
/pre
With 0.25.3 I didn't have this issue.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://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 #1545] The module name should be available as a variable
Issue #1545 has been updated by Alan Barrett.
Like Volcane, my use case is a definition that searches for files, using
something like this:
pre
file { $name:
source = [
puppet:///$module/$basename.$fqdn,
puppet:///$module/$basename.$environment,
puppet:///$module/$basename.COMMON,
],
}
/pre
I currently pass the equivalent of puppet://$module/$basename as a parameter
to the definition, but if $module could be provided automatically, then I could
rewrite the definition to figure out a default $basename from $name, and I
could save some effort every time the definition is called.
Feature #1545: The module name should be available as a variable
http://projects.puppetlabs.com/issues/1545
Author: Felix Schäfer
Status: Ready for Testing
Priority: Normal
Assigned to: Luke Kanies
Category: newfeature
Target version: 2.6
Affected version: 0.25.1
Keywords:
Branch: luke/tickets/master/1545-module_name_as_variable
It's been discussed before in #1104, but I can't find a ticket for that, so I
suppose there isn't one as of now.
Anyway, it would be nice to know which module some definition is being called
from, this would save me some Common_definition { module = module1, } at the
beginning of module1.
--
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 #3926] uniqueid not unique enough
Issue #3926 has been updated by Greg Maples. A variation of bios based serial number is available in all sun/solaris machines, all linux based dell, hp, aix/ibm, etc. It's available on the mac, etc. I would think that covering 90% of your target user base with something virtually guaranteed to be unique, and using some other sequence for the 10% would be a fast and very useful approach. Bug #3926: uniqueid not unique enough http://projects.puppetlabs.com/issues/3926 Author: Greg Maples Status: Needs design decision Priority: Normal Assigned to: Category: library Target version: Affected version: 0.25.4 Keywords: Branch: basing it on hostid is not nearly unique enough especially in a xen environment with duplicated machines and multiple instances of IPs and MACs. I'd suggest something like serial number from BIOS (works for dell, hp, ibm, etc - significant portion of all x86 machines) modified by the system time when facter was initially installed. -- 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 - Refactor #3393] Facter for MS Windows
Issue #3393 has been updated by David Schmitt. Thanks to Paul's analysis, I could easily create another patch to fix the failures on *NIX systems. It's now also on the ticket/master/3393 branch. The two patches can be squashed before publishing. Refactor #3393: Facter for MS Windows http://projects.puppetlabs.com/issues/3393 Author: Daniel Berger Status: Code Insufficient Priority: Normal Assigned to: Category: library Target version: 1.5.8 Branch: The file resolution.rb contains several unixisms that will not work on MS Windows. This needs to be refactored in order to work across platforms. -- 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 - Refactor #3393] Facter for MS Windows
Issue #3393 has been updated by David Schmitt. Correction: I rebased and squashed myself. The new commit is 1adc473 Refactor #3393: Facter for MS Windows http://projects.puppetlabs.com/issues/3393 Author: Daniel Berger Status: Code Insufficient Priority: Normal Assigned to: Category: library Target version: 1.5.8 Branch: The file resolution.rb contains several unixisms that will not work on MS Windows. This needs to be refactored in order to work across platforms. -- 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 #3987] (Unreviewed) Allow ${var} with curlies everywhere
Issue #3987 has been reported by Alan Barrett.
Feature #3987: Allow ${var} with curlies everywhere
http://projects.puppetlabs.com/issues/3987
Author: Alan Barrett
Status: Unreviewed
Priority: Normal
Assigned to:
Category:
Target version:
Affected version: 0.25.5
Keywords:
Branch:
Inside quoted strings, variables may be written as $var or ${var}, but
outside quoted strings, the $var form is required, and attempts to use ${var}
result in confusing error messages:
pre
var = value
notify { A: message = $var, } # works
notify { B: message = ${var}, } # works
notify { C: message = $var, } # works
notify { D: message = ${var}, } # fails, with Error 400 on SERVER: Could not
match '${var},' at filename:line
/pre
It would be nice if ${var} could be used in this context.
--
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 #3988] (Ready for Checkin) Watchr should be supported alongside autotest
Issue #3988 has been reported by Luke Kanies. Feature #3988: Watchr should be supported alongside autotest http://projects.puppetlabs.com/issues/3988 Author: Luke Kanies Status: Ready for Checkin Priority: Normal Assigned to: Luke Kanies Category: Target version: 2.6 Affected version: 0.25.5 Keywords: Branch: Watchr (http://github.com/mynyml/watchr) is a bit more minimal than autotest and requires more setup, but it also plays nice with filesystem events, which makes a big difference on a system this size. I've got a basic watcher config set up and it should be part of core. -- 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 #3986] (Needs more information) apt-get update after failed apt-get install
Issue #3986 has been updated by James Turnbull. Category changed from provider to package Status changed from Unreviewed to Needs more information Hmmm I am not convinced of this ... There are lots of reasons an install might fail - working around this one use case by forcing every user to go through fail, update, fail seems counter-intuitive to me. Bug #3986: apt-get update after failed apt-get install http://projects.puppetlabs.com/issues/3986 Author: Robert Scheer Status: Needs more information Priority: Normal Assigned to: Category: package Target version: Affected version: 0.25.5 Keywords: debian apt apt-get update Branch: Apt, the default package provider for Debian, maintains a local cache of a remote package repository. Updating this cache (by executing apt-get update) can and should be an external non-Puppet task, as it is a relatively expensive process. It is time-consuming on the Debian client and resource-consuming on the package repository server, so this should not happen too often. However, failing to install a package just because the local package cache is out-of-date, I consider to be a bug in Puppet. This is why I propose the following fix: if apt-get install package fails, then first execute apt-get update and then repeat apt-get install package. This is the same one would do when trying to install the package manually. A patch for the current stable version is attached. -- 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 #3980] (Accepted) Puppet docs should have more examples
Issue #3980 has been updated by James Turnbull. Status changed from Unreviewed to Accepted Feature #3980: Puppet docs should have more examples http://projects.puppetlabs.com/issues/3980 Author: Jeff McCune Status: Accepted Priority: Normal Assigned to: Jeff McCune Category: documentation Target version: Affected version: 0.25.5 Keywords: example, documentation, type, function, provider Branch: Visiting a customer, they mentioned it would help tremendously if the puppet documentation for the type reference, function reference, etc... should contain example use cases. I think this will particularly help ESL users of puppet. -- 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 #3951] (Needs design decision) Quadruple slashes in puppet:// URIs refer to the current module.
Issue #3951 has been updated by James Turnbull.
Category set to fileserving
Status changed from Unreviewed to Needs design decision
Assigned to set to Luke Kanies
Feature #3951: Quadruple slashes in puppet:// URIs refer to the current module.
http://projects.puppetlabs.com/issues/3951
Author: Nigel Kersten
Status: Needs design decision
Priority: Normal
Assigned to: Luke Kanies
Category: fileserving
Target version:
Affected version: 0.25.4
Keywords:
Branch:
pre
class foo {
file { /etc/foo/foo.conf:
source = puppet:foo.conf,
}
}
/pre
and this would expand to:
pre
puppet://$servername/$modulename/foo.conf
/pre
This would make modules even more portable and save me a lot of typing. :)
I'd understand if this got rejected though. It's a bit ugly.
--
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 #1545] The module name should be available as a variable
Issue #1545 has been updated by R.I. Pienaar aka Volcane.
Ticket #3951 relates to this, the 3 slash thing will have the same
simplification effect.
Feature #1545: The module name should be available as a variable
http://projects.puppetlabs.com/issues/1545
Author: Felix Schäfer
Status: Ready for Testing
Priority: Normal
Assigned to: Luke Kanies
Category: newfeature
Target version: 2.6
Affected version: 0.25.1
Keywords:
Branch: luke/tickets/master/1545-module_name_as_variable
It's been discussed before in #1104, but I can't find a ticket for that, so I
suppose there isn't one as of now.
Anyway, it would be nice to know which module some definition is being called
from, this would save me some Common_definition { module = module1, } at the
beginning of module1.
--
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.
[Forge - Feature #3991] (Unreviewed) Tool should ignore VCS artifacts when buiding new module
Issue #3991 has been reported by Jens Hilligsøe. Feature #3991: Tool should ignore VCS artifacts when buiding new module http://projects.puppetlabs.com/issues/3991 Author: Jens Hilligsøe Status: Unreviewed Priority: Normal Assigned to: Igal Koshevoy Category: module tool Target version: Keywords: Branch: Affected URL: `puppet-module build` includes .svn and CVS directories in the resulting .tar.gz 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.
[Facter - Feature #3989] (Accepted) Add HPUX interface facts
Issue #3989 has been reported by James Turnbull. Feature #3989: Add HPUX interface facts http://projects.puppetlabs.com/issues/3989 Author: James Turnbull Status: Accepted Priority: Normal Assigned to: James Turnbull Category: library Target version: 1.5.8 Keywords: Branch: -- 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 #3990] (Unreviewed) Friday
Issue #3990 has been reported by Luke Kanies. Bug #3990: Friday http://projects.puppetlabs.com/issues/3990 Author: Luke Kanies Status: Unreviewed Priority: Normal Assigned to: Category: Target version: Affected version: 0.25.5 Keywords: Branch: It looked like I was going to be in tomorrow, at least until the afternoon, but I'm apparently spending the night in Phoenix instead. Ping me if you need me, I'll be in BWI until 8pm local. -- Sent from mobile device | +1-615-594-8199 -- 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 #3986] apt-get update after failed apt-get install
Issue #3986 has been updated by Nigel Kersten.
pre
class apt::updates {
exec { blah blah apt-get update }
}
Package { require = Class[apt::updates], }
}
/pre
We've taken this a bit further and have an apt_package defined type to do other
things.
There are lots of reasons apt-get update might fail, there are lots of reasons
apt-get install foo might fail.
Requiring such an expensive process each time a package fails isn't how I
expect puppet to work.
Bug #3986: apt-get update after failed apt-get install
http://projects.puppetlabs.com/issues/3986
Author: Robert Scheer
Status: Needs more information
Priority: Normal
Assigned to:
Category: package
Target version:
Affected version: 0.25.5
Keywords: debian apt apt-get update
Branch:
Apt, the default package provider for Debian, maintains a local cache of a
remote package repository. Updating this cache (by executing apt-get update)
can and should be an external non-Puppet task, as it is a relatively expensive
process. It is time-consuming on the Debian client and resource-consuming on
the package repository server, so this should not happen too often.
However, failing to install a package just because the local package cache is
out-of-date, I consider to be a bug in Puppet. This is why I propose the
following fix: if apt-get install package fails, then first execute
apt-get update and then repeat apt-get install package. This is the same
one would do when trying to install the package manually.
A patch for the current stable version is attached.
--
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 #3962] 0.25.5 fails to start if /var/lib does not exist
Issue #3962 has been updated by Matt Robinson. Assigned to set to Matt Robinson Bug #3962: 0.25.5 fails to start if /var/lib does not exist http://projects.puppetlabs.com/issues/3962 Author: eric sorenson Status: Accepted Priority: Normal Assigned to: Matt Robinson Category: Target version: Affected version: 0.25.5 Keywords: Branch: Due to #86 and the 0.25.4-0.25.5 move of $vardir from /var (which always exists on Unix) to /var/lib (which might or might not exist), puppetd now fails to start on OSes without a /var/lib. This broke out of the box for me on both OS X and Solaris machines. The attached patch fixes the issue by adding a 'varparentdir' resource which is conditional upon root/not root EUID as confdir and vardir are. I'm not sure this is the best way to go about it and will happily take improvements that address the issue. before patch: pre err: /File[/var/lib/puppet]/ensure: change from absent to directory failed: Cannot create /var/lib/puppet; parent directory /var/lib does not exist [ ... dependencies fail, startup aborts ... ] /pre patched, as root: pre debug: /File[/var/lib]: Changing ensure debug: /File[/var/lib]: 1 change(s) debug: /File[/var/lib]/ensure: created [ .. startup succeeds ... ] /pre not as root: pre debug: /File[/Users/eric/.puppet]: Autorequiring File[/Users/eric] [ no-op as this exists ] [ ... startup succeeds ... ] /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 - Feature #1545] The module name should be available as a variable
Issue #1545 has been updated by Luke Kanies.
Ok, I've added a 'caller_module_name' variable in my latest branch which should
do what people seem to want - I'd much appreciate people testing to see if this
works like you were hoping.
Feature #1545: The module name should be available as a variable
http://projects.puppetlabs.com/issues/1545
Author: Felix Schäfer
Status: Ready for Testing
Priority: Normal
Assigned to: Luke Kanies
Category: newfeature
Target version: 2.6
Affected version: 0.25.1
Keywords:
Branch: luke/tickets/master/1545-module_name_as_variable
It's been discussed before in #1104, but I can't find a ticket for that, so I
suppose there isn't one as of now.
Anyway, it would be nice to know which module some definition is being called
from, this would save me some Common_definition { module = module1, } at the
beginning of module1.
--
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.
