[Puppet - Bug #21683] modulepath can't follow symlinks
Issue #21683 has been updated by Erik Dalén. I don't know what went wrong here, but this is exactly how we've been running in production without any issues like that at all. ATM on 3.3.1, but have been running it on most other master versions as well. Bug #21683: modulepath can't follow symlinks https://projects.puppetlabs.com/issues/21683#change-98772 * Author: Carl Caum * Status: Needs More Information * Priority: Normal * Assignee: Carl Caum * Category: * Target version: * Affected Puppet version: 3.2.2 * Keywords: * Branch: If a directory in the modulepath is a symlink, puppet is unable to follow it. For example, if /etc/puppetlabs/puppet/environments is a symlink and the modulepath is /etc/puppetlabs/puppet/environments/staging, puppet will not find any modules in the path. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #22622] Puppet 3.3.0 and Facter completely broken on Windows Server 2003
Issue #22622 has been updated by Rob Reynolds. If I had to guess, I would say that spaces are the issue Bug #22622: Puppet 3.3.0 and Facter completely broken on Windows Server 2003 https://projects.puppetlabs.com/issues/22622#change-98774 * Author: Martijn Grendelman * Status: Accepted * Priority: Normal * Assignee: Martijn Grendelman * Category: * Target version: 1.7.4 * Keywords: windows * Branch: * Affected Facter version: 1.7.3 After upgrading Puppet agent on a Windows Server 2003 instance to 3.3.0 (from Puppetlabs-supplied puppet-3.3.0.msi), both Facter and Puppet did no longer work: Facter: Running Facter on demand ... Failed to load feature test for root: undefined method `each_line' for nil:NilClass Error: undefined method `each_line' for nil:NilClass Puppet: Running Puppet agent on demand ... Failed to load feature test for root: undefined method `each_line' for nil:NilClass C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/parser.rb:73:in `parse': undefined method `each_line' for nil:NilClass (NoMethodError) from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/parser.rb:120:in `results' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/directory_loader.rb:61:in `block in load' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/directory_loader.rb:55:in `each' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/directory_loader.rb:55:in `load' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `block in load' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `each' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/composite_loader.rb:10:in `load' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/collection.rb:109:in `load' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/collection.rb:84:in `fact' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter/util/collection.rb:139:in `value' from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter.rb:112:in `block (2 levels) in singletonclass' from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/defaults.rb:4:in `default_diffargs' from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/defaults.rb:183:in `module:Puppet' from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/defaults.rb:1:in `top (required)' from C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet.rb:109:in `module:Puppet' from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet.rb:29:in `top (required)' from C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb:12:in `top (required)' from C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/Program Files/Puppet Labs/Puppet/puppet/bin/puppet:3:in `main' Downgrading to 3.2.4 fixed the problem and restored functionality. The problem does not occur on Windows Server 2008 with Puppet 3.3.0. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #15062] puppet fails if template contains invalid utf-8
Issue #15062 has been updated by Mathieu Arnold.
Any news on that front ?
Bug #15062: puppet fails if template contains invalid utf-8
https://projects.puppetlabs.com/issues/15062#change-98779
* Author: Chris Price
* Status: Needs Decision
* Priority: Normal
* Assignee: eric sorenson
* Category: templates
* Target version:
* Affected Puppet version: 2.7.16
* Keywords: character encoding binary utf8
* Branch:
If you attempt to use a file resource with a 'content' parameter pointing at a
template, and the template contains binary content, you may get an error like
this:
Error: Failed to apply catalog: Parameter content failed: Munging failed
for value ...
invalid byte sequence in UTF-8
I've reproduced the failure in 2.7.16 and 3.x, though the error messages differ
slightly between the two (and also depending on whether you repro via 'apply'
or via master/agent run).
I'm attaching the binary file that I'm using to repro. Save it into a
directory structure like this:
modules/mymod/templates/mytemplate.erb
Add the modules directory to your module path and then you can repro with the
following manifest:
file { /tmp/myfile:
mode = 755,
content = template(mymod/mytemplate.erb),
}
Note that if you use the 'source' parameter rather than the 'content' parameter
(and avoid calling the template function), the manifest can be applied
successfully; so the issue is when bringing in binary data as a string.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #15062] puppet fails if template contains invalid utf-8
Issue #15062 has been updated by Mathieu Arnold.
Priority changed from Normal to High
Bug #15062: puppet fails if template contains invalid utf-8
https://projects.puppetlabs.com/issues/15062#change-98780
* Author: Chris Price
* Status: Needs Decision
* Priority: High
* Assignee: eric sorenson
* Category: templates
* Target version:
* Affected Puppet version: 2.7.16
* Keywords: character encoding binary utf8
* Branch:
If you attempt to use a file resource with a 'content' parameter pointing at a
template, and the template contains binary content, you may get an error like
this:
Error: Failed to apply catalog: Parameter content failed: Munging failed
for value ...
invalid byte sequence in UTF-8
I've reproduced the failure in 2.7.16 and 3.x, though the error messages differ
slightly between the two (and also depending on whether you repro via 'apply'
or via master/agent run).
I'm attaching the binary file that I'm using to repro. Save it into a
directory structure like this:
modules/mymod/templates/mytemplate.erb
Add the modules directory to your module path and then you can repro with the
following manifest:
file { /tmp/myfile:
mode = 755,
content = template(mymod/mytemplate.erb),
}
Note that if you use the 'source' parameter rather than the 'content' parameter
(and avoid calling the template function), the manifest can be applied
successfully; so the issue is when bringing in binary data as a string.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22839] (Investigating) The Service Startup Type for the Puppet Enterprise for Windows Agent
Issue #22839 has been updated by Rob Reynolds. Status changed from Re-opened to Investigating This is a bit different than the other as this refers to delayed startup. Although I'd say we'll investigate this. Feature #22839: The Service Startup Type for the Puppet Enterprise for Windows Agent https://projects.puppetlabs.com/issues/22839#change-98782 * Author: Glenn Sarti * Status: Investigating * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: windows service agent * Branch: The service startup type of the Windows Puppet agent is set to Automatic, with no service dependencies. While it is an uncommon occurrence, it is possible for the Puppet Agent to start before the network components are available e.g. It would be possible for the Puppet Agent to start before the DHCP Client has finished configuring the network adapters. As I have only started using Puppet recently I have not seen this specific issue with Puppet in the wild but I have seen similar timing issues with other windows programs in the past, particularly with 802.1x authenticated networks. I see two ways that this issue could be avoided: 1. Change the Startup Type As of Server 2008 (I think?) and Vista an additional Startup type was added; Automatic (Delayed) From http://en.wikipedia.org/wiki/Windows_service Automatic: The service starts at system logon. Automatic (Delayed): The service starts a short while after the system has finished starting up. This option was introduced in Windows Vista in an attempt to reduce the boot-to-desktop time. However, not all services support delayed start It seems that ...a short while after... is roughly 120 seconds after the last Automatic Service is started. This would ensure that the network and other services required by Puppet. 2. Specify the Service Dependencies for the Puppet Agent The Puppet Agent Service could specify which services it depends on e.g. Puppet would depend on the Network Store Interface Service for network interface information to be available. The service dependencies method seems a little harder to manage because PuppetLabs does not know what technologies module authors will use. As an example, say I created a puppet class that runs a PowerShell Script that uses information from the Tivoli Backup Service. In that case the Puppet Agent now depends on the Tivoli Backup Service to be running for a successful catalog run. There is no way that PuppetLabs would know about this dependency and put it in their installation script. Out of both options, Option 1 seems to make the most sense and is pretty easy to implement. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22852] (Needs More Information) puppet help only show error message
Issue #22852 has been updated by Josh Cooper. Status changed from Unreviewed to Needs More Information Assignee set to Reinhard Vicinus I think you have multiple versions of puppet installed, perhaps as a package and as a gem? Bug #22852: puppet help only show error message https://projects.puppetlabs.com/issues/22852#change-98784 * Author: Reinhard Vicinus * Status: Needs More Information * Priority: Normal * Assignee: Reinhard Vicinus * Category: * Target version: * Affected Puppet version: 3.3.1 * Keywords: * Branch: All puppet agents i have updated from 3.3.0 to 3.3.1 show on puppet help only the following error message: Error: --name=: already defined in puppet Error: Try 'puppet help help help' for usage The same error is shown with all puppet man xyz commands, but puppet help xyz seems to work with all commands. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22852] puppet help only show error message
Issue #22852 has been updated by Reinhard Vicinus. I have some new information. The problem also occurs on 3.3.0. It only occors if 'puppet help' is called as root user. Normal user get the correct help message if they call 'puppet help'. As I was only logged in as root on the servers I updated puppet, it looked like only puppet 3.3.1 was affected. As far as I know I have only the puppet debian packages installed. On one computer with debian unstable that has this problem, 'gem list' shows no entries and 'dpkg -l | grep puppet' shows: ii facter1.7.3-1puppetlabs1 amd64 Ruby module for collecting simple facts about a host operating system ii hiera 1.2.1-1puppetlabs1 all A simple pluggable Hierarchical Database. ii puppet3.3.1-1puppetlabs1 all Centralized configuration management - agent startup and compatibility scripts ii puppet-common 3.3.1-1puppetlabs1 all Centralized configuration management ii ruby-rgen 0.6.5-1puppetlabs1 all A framework supporting Model Driven Software Development (MDSD) and the only thing done on this computer with puppet was add the puppetlabs repo and 'apt-get install puppet' followed by 'puppet help' as root. Bug #22852: puppet help only show error message https://projects.puppetlabs.com/issues/22852#change-98789 * Author: Reinhard Vicinus * Status: Needs More Information * Priority: Normal * Assignee: Reinhard Vicinus * Category: * Target version: * Affected Puppet version: 3.3.1 * Keywords: * Branch: All puppet agents i have updated from 3.3.0 to 3.3.1 show on puppet help only the following error message: Error: --name=: already defined in puppet Error: Try 'puppet help help help' for usage The same error is shown with all puppet man xyz commands, but puppet help xyz seems to work with all commands. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22778] (Duplicate) Puppet user resource should read only from local databases
Issue #22778 has been updated by Stefan Schulte. Status changed from Unreviewed to Duplicate You should be able to do that with the `forcelocal` parameter of the user resource (http://docs.puppetlabs.com/references/latest/type.html#user-attribute-forcelocal) which exists since 3.2.0 so I am marking this as a duplicate of #7911. If you think #7911 does not match your feature request, please feel free to reopen. Feature #22778: Puppet user resource should read only from local databases https://projects.puppetlabs.com/issues/22778#change-98790 * Author: Zachary Stern * Status: Duplicate * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: Currently, the puppet user type uses `getent` to get information about user resources. The problem with this is that `getent` will also report information from LDAP and other remote user management services that are configured in nsswitch.conf, which are not actually managed by Puppet. This can cause Puppet to think a user is in a local group, or not in a local group, when the opposite is true. This is especially problematic since we user the useradd suite of commands to actually manage the settings, which of course affect local users/groups only. Puppet's user type should have some way of examining only local users and groups, to check if something is currently true/present/etc. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22769] (Needs More Information) mount{} type on Solaris 10 requires 'atboot' option to be set to true.
Issue #22769 has been updated by Stefan Schulte.
Status changed from Unreviewed to Needs More Information
The `atboot` property is a mandatory field in Solaris `/etc/vfstab` file and
should only be set to `yes` or `no` so your first example will actually create
an invalid `/etc/vfstab` entry according to
http://docs.oracle.com/cd/E19455-01/805-7228/6j6q7uev3/index.html (if you run
puppet 3.3, you'll be able to use `true`/`false` as an alias for `yes`/`no`
though - see #22383)
Linux does not use `/etc/vfstab` but `/etc/fstab` which has a different format
that does not feature an `atboot` field so the `atboot` property is completly
ignored on Linux (you'll have to use the `auto`/`noauto` boot options to get
the same effect).
Having said that puppet should always complain on solaris if you do not specify
`atboot` *unless* the resource is already present and puppet only has to modify
an already existent entry that already has an `atboot` value. Can you please
verify that you have tested both puppet versions under the same circumstances
(mount point already present in `/etc/vfstab` or mount point absent prior to
running puppet)?
About your last example: It should work when you put quotation marks around
`false` but as I said at the beginning, `false` is not really valid in
`/etc/vfstab`, so you should use `no` here.
Bug #22769: mount{} type on Solaris 10 requires 'atboot' option to be set to
true.
https://projects.puppetlabs.com/issues/22769#change-98791
* Author: Paul Lussier
* Status: Needs More Information
* Priority: Normal
* Assignee:
* Category: Solaris
* Target version:
* Affected Puppet version: 2.7.21
* Keywords: mount solaris
* Branch:
$mountops = 'proto=tcp,vers=3,rsize=32768,wsize=32768,noexec,nosuid,rw,bg,hard\
,intr'
$fs = '/foo'
# This works fine
mount {
$fs :
device = ${nfs_server}:${fs},
atboot = true,
ensure = mounted,
fstype = 'nfs',
blockdevice = '-',
options = $mountops,
dump= 1;
}
#
# The following fail
#
mount {
$fs :
device = ${nfs_server}:${fs},
ensure = mounted,
fstype = 'nfs',
blockdevice = '-',
options = $mountops,
dump= 1;
}
mount {
$fs :
device = ${nfs_server}:${fs},
atboot = false,
ensure = mounted,
fstype = 'nfs',
blockdevice = '-',
options = $mountops,
dump= 1;
}
The error message provided for the last two calls to mount is:
err: /Stage[main]/Mount[/foo]/ensure: change from absent to mounted failed:
Got a nil value for should at /etc/puppet/manifests/nodes.pp:68
This does not occur on Linux, or with puppet 2.7.9 and earlier.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22580] (Needs More Information) Recognize 'undef' value of ensure property of service
Issue #22580 has been updated by Stefan Schulte.
Status changed from Unreviewed to Needs More Information
Assignee set to Vadim Nevorotin
Priority changed from High to Normal
You can already pass `undef` to any property of any type and it is the same as
you hadn't even specified the property. So you can write
service { 'foo':
ensure = undef,
}
or even
class foo ($ensure = undef) {
service { 'foo':
ensure = $ensure,
}
}
doesn't this solve your usecase?
Feature #22580: Recognize 'undef' value of ensure property of service
https://projects.puppetlabs.com/issues/22580#change-98792
* Author: Vadim Nevorotin
* Status: Needs More Information
* Priority: Normal
* Assignee: Vadim Nevorotin
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Now it's impossible to leave service in it's current state if you add ensure
property. There is no valid value for it.
But if you write a wrapper class for some service (e.g. classical
package-config-service) you need to send value for ensure from main class to
service.
So, e.g., class is
class someservice (
$ensure,
...
And in it
service {'someservice':
ensure = $ensure
...
In this case you must specify 'running' or 'stopped' when declare main class.
But sometimes you don't need to change service status. (when service controlled
from scripts).
So please add 'undef' valid value for ensure property of a service. If
ensure=undef, then curren't status of a service should not be changed.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22587] (Needs More Information) Default value for all type's atrributes
Issue #22587 has been updated by Stefan Schulte.
Status changed from Unreviewed to Needs More Information
Assignee set to Vadim Nevorotin
Priority changed from Urgent to Normal
To be honest I don't really understand what you are asking for. If you have a
property with a default value than not specifying a value means that the
default takes place, e.g. if you specify
pre
user { 'foo':
ensure = present,
}
/pre
and you have not specified the `system` parameter it will be set to false, so
the above statement is the same as specifying
pre
user { 'foo':
ensure = present,
system = false,
}
/pre
Defining default values for all properties is cleary not desired because you
would not be able to partly manage a resource - you will always manage every
attribute of a resource because you've either set it explicitly or it was
implicitly set to a default value. I also don't quite get the problem were
having default values for every type would be handy, so please help me
understand the actual problem.
Feature #22587: Default value for all type's atrributes
https://projects.puppetlabs.com/issues/22587#change-98793
* Author: Vadim Nevorotin
* Status: Needs More Information
* Priority: Normal
* Assignee: Vadim Nevorotin
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Each attribute for all built-in types must have default values. (from here:
http://docs.puppetlabs.com/references/3.stable/type.html)
It's very important when you wrap some type with parametrized class/defined
type. I that case you should pass parameters from container to wrapped type. So
you must know default values for all type's attribute to add then as default
values for class/defined type.
E.g. you has standard package-config-service parametrized class. You want to
add enable and ensure attributes of service to main class:
class someclass (
$ensure = ,
$enabled = ,
...
) {
service {'someservice':
ensure = $ensure,
enabled = $enabled,
...
Now you can't simply use default values of attributes from service to class,
because there is no default values. So behavior of whole class differs from
behavior of a service. And so there is a lot of problems in large installations.
See http://projects.puppetlabs.com/issues/22580 - here is one of examples.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22792] (Merged - Pending Release) Rename select to filter (future parser iterative function)
Issue #22792 has been updated by Josh Cooper. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged in commit [ca454e1](https://github.com/puppetlabs/puppet/commit/ca454e1) to be released in 3.4.0 Bug #22792: Rename select to filter (future parser iterative function) https://projects.puppetlabs.com/issues/22792#change-98795 * Author: Erik Dalén * Status: Merged - Pending Release * Priority: Normal * Assignee: Henrik Lindberg * Category: compiler * Target version: 3.4.0 * Affected Puppet version: 3.3.0 * Keywords: future_parser * Branch: https://github.com/puppetlabs/puppet/pull/1988 I think the functions collect and select should be renamed to map filter which seem to be much more common names for these functions in various programming languages. http://en.wikipedia.org/wiki/Map_(higher-order_function) http://en.wikipedia.org/wiki/Filter_(higher-order_function) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22729] (Merged - Pending Release) New future-parser-only functions are loaded although one is not using the future parser
Issue #22729 has been updated by Josh Cooper. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged in commit [1720f00](https://github.com/puppetlabs/puppet/commit/1720f00) to be released in 3.4.0. Bug #22729: New future-parser-only functions are loaded although one is not using the future parser https://projects.puppetlabs.com/issues/22729#change-98796 * Author: Peter Meier * Status: Merged - Pending Release * Priority: Normal * Assignee: Henrik Lindberg * Category: functions * Target version: 3.4.0 * Affected Puppet version: 3.3.0 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/1985 Since 3.2 there is now a function reject, that is part of the new future parser. In the description of the function it is noted, that this function requires the future parser. However, there is also a popular function called reject in the stdlib module, which works with the old parser. If somebody tries to use the stdlib-function with a puppet version 3.2 without having the stdlib module in their modulepath, they encounter a weird error, that is not really helpful: https://github.com/duritong/puppet-munin/issues/21 pre # puppet --version 3.3.0 # puppet apply -e notice reject(['a','b'],'b') Error: reject(): wrong argument type (String; must be a parameterized block. at line 1 on node foo Wrapped exception: reject(): wrong argument type (String; must be a parameterized block. Error: reject(): wrong argument type (String; must be a parameterized block. at line 1 on node foo /pre So there are two problems here: 1. People should use the stlib module if the requirements say so. 2. Although the new reject function is future-parser-only it is still available if puppet does not use the future parser. If the last point would not be the case, the error would have been something like: Unknown function reject and it would have been pretty obvious that the user is missing the stdlib module. So if puppet starts shipping future-parser-only functions it should ensure that they are also only available if the future parser is used. Otherwise this is not very user friendly and actually we can be happy, that module-contributed functions are loaded *before* built-in functions, otherwise the stdlib module would not be usable at all any more. Also note, that the wrapped exception is identical to the first displayed one, which is not very helpful either and which also would have made it easier to spot the problem in the first place, but this is something for another ticket. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22778] (Re-opened) Puppet user resource should read only from local databases
Issue #22778 has been updated by Zachary Stern. Status changed from Duplicate to Re-opened I do not believe this is a duplicate. As per my discussions with Jill Burrows, the user and group resources still uses `getent` to check if a user or group already exists, and this will always include the remote users/groups. Does the `forcelocal` parameter actually work around that in some way? If that is the case, then you can mark this as duplicate once again. Feature #22778: Puppet user resource should read only from local databases https://projects.puppetlabs.com/issues/22778#change-98797 * Author: Zachary Stern * Status: Re-opened * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: Currently, the puppet user type uses `getent` to get information about user resources. The problem with this is that `getent` will also report information from LDAP and other remote user management services that are configured in nsswitch.conf, which are not actually managed by Puppet. This can cause Puppet to think a user is in a local group, or not in a local group, when the opposite is true. This is especially problematic since we user the useradd suite of commands to actually manage the settings, which of course affect local users/groups only. Puppet's user type should have some way of examining only local users and groups, to check if something is currently true/present/etc. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22785] (In Topic Branch Pending Review) Rename the collect function to map
Issue #22785 has been updated by Josh Cooper. Status changed from Accepted to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/1973 Bug #22785: Rename the collect function to map https://projects.puppetlabs.com/issues/22785#change-98798 * Author: Henrik Lindberg * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Henrik Lindberg * Category: language * Target version: 3.4.0 * Affected Puppet version: 3.2.1 * Keywords: function future_parser * Branch: https://github.com/puppetlabs/puppet/pull/1973 The iterative collect function should be renamed to map since we chose to use reduce (instead of inject which goes with collect). Now we have a mix of two schools. The fix is to rename the collect function, but to keep a stub that throws an error that says that the users should change to using map. Since this is in an experimental version we do not have to have a deprecation cycle. This has impact on user documentation, examples etc. that shows the collect function. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #2247] enablerepo and disablerepo for yum type
Issue #2247 has been updated by Brian Pitts.
Any updates here? Jeff? Charlie?
Feature #2247: enablerepo and disablerepo for yum type
https://projects.puppetlabs.com/issues/2247#change-98800
* Author: Ben -
* Status: Investigating
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version: 3.x
* Affected Puppet version: 0.24.8
* Keywords: yum enablerepo customer
* Branch: https://github.com/puppetlabs/puppet/pull/1974
it would be nice to be able to enable a disabled repo for the installation on
one package.
for example installing facter from EPEL.
something like;
pre
package { facter: ensure = installed, enablerepo = [ epel, epel-testing
]; }
/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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22778] Puppet user resource should read only from local databases
Issue #22778 has been updated by Stefan Schulte. what do you mean with **still** uses getent to check if a user or group already exists? After using `forcelocal`? I have not used it myself and I don't have an LDAP environment to test this but `forcelocal` should check the existance of an user by parsing the content of the `/etc/passwd` file and should not use `getent`. And a new user will be created with `luseradd` instead of `useradd`. Feature #22778: Puppet user resource should read only from local databases https://projects.puppetlabs.com/issues/22778#change-98801 * Author: Zachary Stern * Status: Re-opened * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: Currently, the puppet user type uses `getent` to get information about user resources. The problem with this is that `getent` will also report information from LDAP and other remote user management services that are configured in nsswitch.conf, which are not actually managed by Puppet. This can cause Puppet to think a user is in a local group, or not in a local group, when the opposite is true. This is especially problematic since we user the useradd suite of commands to actually manage the settings, which of course affect local users/groups only. Puppet's user type should have some way of examining only local users and groups, to check if something is currently true/present/etc. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22778] Puppet user resource should read only from local databases
Issue #22778 has been updated by Zachary Stern. The issue isn't how the system creates the user - it's how it checks whether the user already exists. According to Jill, this is always done via the `getent` command, `getent` will always return the remote users. How the user is actually created in the end isn't the relevant question here. Feature #22778: Puppet user resource should read only from local databases https://projects.puppetlabs.com/issues/22778#change-98802 * Author: Zachary Stern * Status: Re-opened * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: Currently, the puppet user type uses `getent` to get information about user resources. The problem with this is that `getent` will also report information from LDAP and other remote user management services that are configured in nsswitch.conf, which are not actually managed by Puppet. This can cause Puppet to think a user is in a local group, or not in a local group, when the opposite is true. This is especially problematic since we user the useradd suite of commands to actually manage the settings, which of course affect local users/groups only. Puppet's user type should have some way of examining only local users and groups, to check if something is currently true/present/etc. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22864] (Unreviewed) automated response
Issue #22864 has been reported by Andreas Schiermeier. Bug #22864: automated response https://projects.puppetlabs.com/issues/22864 * Author: Andreas Schiermeier * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: Dear sender, I'm out of office including Sunday, 20th October 2013. I don't have access to my e-mails. Your e-mail will not be forwarded. In urgent cases please contact pcsupp...@trustinternational.com Regards, Andreas Schiermeier -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22785] (Merged - Pending Release) Rename the collect function to map
Issue #22785 has been updated by Josh Cooper. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged in [bcc8412](https://github.com/puppetlabs/puppet/commit/bcc8412) to be released in 3.4.0. Bug #22785: Rename the collect function to map https://projects.puppetlabs.com/issues/22785#change-98803 * Author: Henrik Lindberg * Status: Merged - Pending Release * Priority: Normal * Assignee: Henrik Lindberg * Category: language * Target version: 3.4.0 * Affected Puppet version: 3.2.1 * Keywords: function future_parser * Branch: https://github.com/puppetlabs/puppet/pull/1973 The iterative collect function should be renamed to map since we chose to use reduce (instead of inject which goes with collect). Now we have a mix of two schools. The fix is to rename the collect function, but to keep a stub that throws an error that says that the users should change to using map. Since this is in an experimental version we do not have to have a deprecation cycle. This has impact on user documentation, examples etc. that shows the collect function. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22864] (Rejected) automated response
Issue #22864 has been updated by Josh Cooper. Status changed from Unreviewed to Rejected Bug #22864: automated response https://projects.puppetlabs.com/issues/22864#change-98805 * Author: Andreas Schiermeier * Status: Rejected * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: Dear sender, I'm out of office including Sunday, 20th October 2013. I don't have access to my e-mails. Your e-mail will not be forwarded. In urgent cases please contact pcsupp...@trustinternational.com Regards, Andreas Schiermeier -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22866] (Unreviewed) incorrect permissions in rpms
Issue #22866 has been reported by R.I. Pienaar. Bug #22866: incorrect permissions in rpms https://projects.puppetlabs.com/issues/22866 * Author: R.I. Pienaar * Status: Unreviewed * Priority: Normal * Assignee: Matthaus Owens * Category: * Target version: * Affected Puppet version: 3.3.0 * Keywords: * Branch: The /usr/share/doc/puppet-3.3.1 and below directories have incorrect perms: pre % rpm -qlpv http://yum.puppetlabs.com/el/6/products/x86_64/puppet-3.3.1-1.el6.noarch.rpm|egrep ^d.+share.doc drwxr-x---2 puppet puppet 0 Oct 7 19:03 /usr/share/doc/puppet-3.3.1 drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/etc drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/etc/hieradb drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/data drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/data/manifests drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/ntp drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/ntp/manifests drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/ntp/templates drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/users drwxr-x---2 puppet puppet 0 Oct 7 19:00 /usr/share/doc/puppet-3.3.1/examples/hiera/modules/users/manifests /pre they're all 0750 -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #2198] Install multiple package within a single call to the package manager
Issue #2198 has been updated by Kylo Ginsberg. There was a great discussion on puppet-dev: https://groups.google.com/forum/#!topic/puppet-dev/X7RgakTGnbk The initial outcome was: The provider interface: * Provider::batchable?(resource1, resource2) * Provider::batch_start * Provider::batch_end We defined an initial set of vertical slices to work on, with the yum provider as the initial guinea pig: 1. Define report schema changes 2. Every resource is its own batch. The provider executes the batch and these batches appear in the report. 3. The provider is able to control what resources can go into a batch to allow batches of size 1. Manifest ordering algorithm. 4. The yum provider executes all of the items in a batch using a single command. It assumes that everything will succeed and no error reporting is done. 5. The yum provider handles errors while executing a batch and reports a failure for any item as a failure for all items. 6. The yum provider is able to report which item of the batch caused the actual error and preserve this information in the report. 7. Extend/test for Title Hash order and Random Order. Prior to this, the conservative (manifest ordering) algorithm is used per batch. I suspect we'll learn some about batch processing (and perhaps yum!) as we go, so these slices aren't set in stone, but just an initial development plan. I'm hoping we'll see some of these slices getting developed soon! Feature #2198: Install multiple package within a single call to the package manager https://projects.puppetlabs.com/issues/2198#change-98806 * Author: Stéphan Gorget * Status: Investigating * Priority: Normal * Assignee: * Category: transactions * Target version: * Affected Puppet version: 0.25.0 * Keywords: communitypatch * Branch: http://github.com/phantez/puppet/commit/51ff88c950c172e6060ae63c1c71968e7898b462 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22778] Puppet user resource should read only from local databases
Issue #22778 has been updated by Stefan Schulte. As I said, if you use `forcelocal` puppet will only parse `/etc/passwd` to check existance, so this should be what you need. The `forcelocal` parameter was added as a result of #7911. I was not able to find any statements of a Jill Burrows in this ticket or in #7911 so I don't know wether or not Jill refered to this new parameter when making the statements about `getent`. Please note that this is a public ticketing system and I am not a puppetlabs employee, so if you are referring to an internal discussion between you as a customer and puppetlabs staff, than this is will not be visible for me. Feature #22778: Puppet user resource should read only from local databases https://projects.puppetlabs.com/issues/22778#change-98807 * Author: Zachary Stern * Status: Re-opened * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: Currently, the puppet user type uses `getent` to get information about user resources. The problem with this is that `getent` will also report information from LDAP and other remote user management services that are configured in nsswitch.conf, which are not actually managed by Puppet. This can cause Puppet to think a user is in a local group, or not in a local group, when the opposite is true. This is especially problematic since we user the useradd suite of commands to actually manage the settings, which of course affect local users/groups only. Puppet's user type should have some way of examining only local users and groups, to check if something is currently true/present/etc. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22778] Puppet user resource should read only from local databases
Issue #22778 has been updated by Zachary Stern. I am referring to an internal discussion with a Puppet Labs engineer, yes. I will follow up on this and get back to you. Feature #22778: Puppet user resource should read only from local databases https://projects.puppetlabs.com/issues/22778#change-98808 * Author: Zachary Stern * Status: Re-opened * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: Currently, the puppet user type uses `getent` to get information about user resources. The problem with this is that `getent` will also report information from LDAP and other remote user management services that are configured in nsswitch.conf, which are not actually managed by Puppet. This can cause Puppet to think a user is in a local group, or not in a local group, when the opposite is true. This is especially problematic since we user the useradd suite of commands to actually manage the settings, which of course affect local users/groups only. Puppet's user type should have some way of examining only local users and groups, to check if something is currently true/present/etc. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22867] (Unreviewed) Add S3 or HTTP puppet enterprise payload argument value
Issue #22867 has been reported by Luis Mayorga. Feature #22867: Add S3 or HTTP puppet enterprise payload argument value https://projects.puppetlabs.com/issues/22867 * Author: Luis Mayorga * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: Hi, I am using Puppet Enterprise 3.0.1 Cloud Provisioner Command Line and would like to know if its possible to add s3 or http values to the --installer-payload argument. I believe most of the puppet enterprise releases are stored with the s3 service and would be nice if we can access them directly from our AWS instances instead of uploading from a local machine. The same for http would apply i guess. puppet node_aws bootstrap --image ami-a73264ce --keyname lmo0 --type m1.small --security-group lmo0-secure --login ubuntu --keyfile=~/.ssh/lmo0.pem --installer-answers=~/amazon.puppetenterprise.answers --installer-payload=~/puppet-enterprise-3.0.1-ubuntu-12.04-amd64.tar.gz --install-script=puppet-enterprise -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #17707] Fail to download complete file resources on Puppet for Windows 3.0.0
Issue #17707 has been updated by Luis Mayorga. This is not happening with the latest 3.0.1 release anymore. I guess it can be closed Bug #17707: Fail to download complete file resources on Puppet for Windows 3.0.0 https://projects.puppetlabs.com/issues/17707#change-98809 * Author: Luis Mayorga * Status: Needs More Information * Priority: Normal * Assignee: Luis Mayorga * Category: * Target version: * Affected Puppet version: * Keywords: windows * Branch: Hi, We have a windows share drive mounted on our RHL Puppet Master v.3.0.0 on the fileserver.conf file. We have experienced different issues with puppet trying to download file resources(.msi packages) and all our Package resources start failing since they are not full downloaded files. Could this be related to the mounted partition or should be just start using the shared drive path on all our file recipes. 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22867] Add S3 or HTTP puppet enterprise payload argument value on cloud provisioner command line tool (puppet node_aws)
Issue #22867 has been updated by Luis Mayorga. Subject changed from Add S3 or HTTP puppet enterprise payload argument value to Add S3 or HTTP puppet enterprise payload argument value on cloud provisioner command line tool (puppet node_aws) Feature #22867: Add S3 or HTTP puppet enterprise payload argument value on cloud provisioner command line tool (puppet node_aws) https://projects.puppetlabs.com/issues/22867#change-98810 * Author: Luis Mayorga * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: Hi, I am using Puppet Enterprise 3.0.1 Cloud Provisioner Command Line and would like to know if its possible to add s3 or http values to the --installer-payload argument. I believe most of the puppet enterprise releases are stored with the s3 service and would be nice if we can access them directly from our AWS instances instead of uploading from a local machine. The same for http would apply i guess. puppet node_aws bootstrap --image ami-a73264ce --keyname lmo0 --type m1.small --security-group lmo0-secure --login ubuntu --keyfile=~/.ssh/lmo0.pem --installer-answers=~/amazon.puppetenterprise.answers --installer-payload=~/puppet-enterprise-3.0.1-ubuntu-12.04-amd64.tar.gz --install-script=puppet-enterprise -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22868] (Unreviewed) Puppet 3.X does not properly inherit 'commands' in providers.
Issue #22868 has been reported by Trevor Vaughan. Bug #22868: Puppet 3.X does not properly inherit 'commands' in providers. https://projects.puppetlabs.com/issues/22868 * Author: Trevor Vaughan * Status: Unreviewed * Priority: Normal * Assignee: * Category: provider * Target version: * Affected Puppet version: 3.3.1 * Keywords: provider, inheritance * Branch: In Puppet 2.7, you could have one provider inherit another and the 'commands' options would be properly overridden if provided with the same name. In 3.X, the parent provider command is used. Interestingly, calling command(:command_name) returns the *correct answer* in 3.X, but the actual command called when running 'command_name', is the parent command. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
