[Puppet - Bug #15735] Deprecate 'puppet kick' run mode
Issue #15735 has been updated by Markus Joosten. I can only agree to what Nikita said. Mcollective has such a huge overhead, since it is relies on ActiveMQ which is a Java application after all. Most of our systems do not have Java installed (for several purposes, security being only one of those reasons!) and with the current puppet kick functionality we can at least trigger our puppet agents to run. Just out of curiosity, why do you guys want to deprecate the kick functionality? Is it to hard to maintain code-wise? Does it lack some critical features? Security issues? Bug #15735: Deprecate 'puppet kick' run mode https://projects.puppetlabs.com/issues/15735#change-101119 * Author: eric sorenson * Status: Re-opened * Priority: High * Assignee: eric sorenson * Category: agent * Target version: 3.x * Affected Puppet version: * Keywords: telly_deprecation * Branch: https://github.com/puppetlabs/puppet/pull/1129 People interested in `puppet kick` functionality should set up mcollective. Supporting it causes problems like #10418. Let's consider removing it for Telly. -- 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] (Merged - Pending Release) Puppet fails when facter loads a script based external fact that doesn't return any output
Issue #22622 has been updated by Josh Cooper. Status changed from Accepted to Merged - Pending Release Branch changed from https://github.com/puppetlabs/facter/pull/564 to https://github.com/puppetlabs/facter/pull/567 Merged in commit [3bdc0bf](https://github.com/puppetlabs/facter/commit/3bdc0bf) to be released in 1.7.4 Bug #22622: Puppet fails when facter loads a script based external fact that doesn't return any output https://projects.puppetlabs.com/issues/22622#change-101120 * Author: Martijn Grendelman * Status: Merged - Pending Release * Priority: Normal * Assignee: Martijn Grendelman * Category: * Target version: 1.7.4 * Keywords: windows * Branch: https://github.com/puppetlabs/facter/pull/567 * 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
[Puppet - Bug #23369] (Accepted) An empty csr_attributes.yaml file fails with undefined method
Issue #23369 has been reported by Josh Cooper. Bug #23369: An empty csr_attributes.yaml file fails with undefined method https://projects.puppetlabs.com/issues/23369 * Author: Josh Cooper * Status: Accepted * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 3.4.0-rc1 * Keywords: * Branch: See https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e -- 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 #23318] Invalid YAML (hiera) file and automatic param binding fails in vague errors
Issue #23318 has been updated by Henrique Rodrigues.
I have the exact same problem, but using CentOS 64-bit, Puppet 3.3.2, Hiera
1.2.1 and the normal Puppet parser (not future).
Bug #23318: Invalid YAML (hiera) file and automatic param binding fails in
vague errors
https://projects.puppetlabs.com/issues/23318#change-101121
* Author: Dolf Schimmel
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 3.3.2
* Keywords: hiera, automatic parameter binding
* Branch:
Hi,
In my chain of hiera files I have an empty file. My manifests look as follows:
pre
blockquote
node 'example.com' {
include role::vps::hypervisor
}
class role::vps::hypervisor inherits role::vps {
}
class role::vps inherits role {
}
class role {
include profile::base
}
class profile::base (
$firewall = params_lookup('firewall', 'global' ),
$manage_networking = true
) {
# Some code here
}
/pre
/blockquote
This results in the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
undefined method `empty?' for false:FalseClass at role.pp:2 on node example.com
Once I remove the parameters in the profile::base class, the error changes in
to the little bit more helpful message:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Data
retrieved from /etc/puppet/hieradata/vps.yaml is String not Hash at
/etc/puppet/modules/profile/manifests/base.pp:13 on node example.com.
Two issues:ulli
I think an empty or invalid Hiera file should not result in an error at
all./lili
If, for whatever reason, automatic parameter binding fails, a reasonable error
should be displayed. In the past I've seen (and reported) several issues where
the binding failed, and resulted in some vague issues which are hard to debug.
/li/ul
Parser: future (not sure if relevant)br /
br /
Hiera version: 1.3.0br /
Puppet version: 3.3.2br /
OS: Debian 7, 64 bitbr /
Env: Passengerbr /
I wouldn't classify the priority of this issue as low, because it's easy to
trigger, and really hard to find the cause off the given error message.
--
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 #23318] Invalid YAML (hiera) file and automatic param binding fails in vague errors
Issue #23318 has been updated by Henrique Rodrigues.
Looks like a duplicate of #23273.
Bug #23318: Invalid YAML (hiera) file and automatic param binding fails in
vague errors
https://projects.puppetlabs.com/issues/23318#change-101124
* Author: Dolf Schimmel
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 3.3.2
* Keywords: hiera, automatic parameter binding
* Branch:
Hi,
In my chain of hiera files I have an empty file. My manifests look as follows:
pre
blockquote
node 'example.com' {
include role::vps::hypervisor
}
class role::vps::hypervisor inherits role::vps {
}
class role::vps inherits role {
}
class role {
include profile::base
}
class profile::base (
$firewall = params_lookup('firewall', 'global' ),
$manage_networking = true
) {
# Some code here
}
/pre
/blockquote
This results in the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
undefined method `empty?' for false:FalseClass at role.pp:2 on node example.com
Once I remove the parameters in the profile::base class, the error changes in
to the little bit more helpful message:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Data
retrieved from /etc/puppet/hieradata/vps.yaml is String not Hash at
/etc/puppet/modules/profile/manifests/base.pp:13 on node example.com.
Two issues:ulli
I think an empty or invalid Hiera file should not result in an error at
all./lili
If, for whatever reason, automatic parameter binding fails, a reasonable error
should be displayed. In the past I've seen (and reported) several issues where
the binding failed, and resulted in some vague issues which are hard to debug.
/li/ul
Parser: future (not sure if relevant)br /
br /
Hiera version: 1.3.0br /
Puppet version: 3.3.2br /
OS: Debian 7, 64 bitbr /
Env: Passengerbr /
I wouldn't classify the priority of this issue as low, because it's easy to
trigger, and really hard to find the cause off the given error message.
--
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 #23372] (Unreviewed) FreeBSD: Puppet triggers loading of ZFS module
Issue #23372 has been reported by Remko Catersels. Bug #23372: FreeBSD: Puppet triggers loading of ZFS module https://projects.puppetlabs.com/issues/23372 * Author: Remko Catersels * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: When puppet starts the puppet ZFS provider issues the zfs command. On FreeBSD this automatically loads the ZFS kernel module. Even when ZFS is not used on that host. The provider should first check if ZFS is enabled or not. If it's not enabled it shouldn't execute any zpool or zfs commands as those will trigger the automatic load of the kernel module. -- 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 #23372] FreeBSD: Puppet triggers loading of ZFS module
Issue #23372 has been updated by Remko Catersels. Affected Puppet version set to 3.3.1 Forgot to add the affected puppet version. Bug #23372: FreeBSD: Puppet triggers loading of ZFS module https://projects.puppetlabs.com/issues/23372#change-101128 * Author: Remko Catersels * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: 3.3.1 * Keywords: * Branch: When puppet starts the puppet ZFS provider issues the zfs command. On FreeBSD this automatically loads the ZFS kernel module. Even when ZFS is not used on that host. The provider should first check if ZFS is enabled or not. If it's not enabled it shouldn't execute any zpool or zfs commands as those will trigger the automatic load of the kernel module. -- 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 #23373] (Accepted) Command line manipulation of puppet.conf
Issue #23373 has been reported by Andrew Parker. Feature #23373: Command line manipulation of puppet.conf https://projects.puppetlabs.com/issues/23373 * Author: Andrew Parker * Status: Accepted * Priority: Normal * Assignee: Andrew Parker * Category: * Target version: 3.5.0 * Affected Puppet version: * Keywords: * Branch: In order to more easily support setting up new agents, it would be useful to have a simple command which could be used to configure the agent. Something like `puppet config set server=puppet.example.com` would work great. The big open question with it is how to support sections in the presence of run modes. The simplest seems to be to just ignore run modes (since they don't have a bidirectional mapping with sections) and provide an explicit `--section` flag (probably with a default of `main`). The end goal is to be able to easily build an agent install script which looks something like this: pre yum install -y puppet puppet config set certname=$(hostname -f) puppet config set server=puppet.example.com puppet config set environment=test puppet resource service puppet ensure=running enable=true /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To 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 #23374] (Unreviewed) Ports provider is buggy and lacks several crucial features
Issue #23374 has been reported by Paweł Tomulik. Bug #23374: Ports provider is buggy and lacks several crucial features https://projects.puppetlabs.com/issues/23374 * Author: Paweł Tomulik * Status: Unreviewed * Priority: High * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: freebsd ports package * Branch: Hi, I was trying to use puppet on FreeBSD with more or less success. One of the biggest problem was the `ports` package provider, which appears to be buggy and lacks some important features. I'm not able to describe in depth all the issues I had, so I'll just leave a short list and provide link to description here. Some of the issues with current ports provider: * no way to define *build options* for a package - normally FreeBSD packages are first configured by user with `make config`, then compiled + installed. Current `ports` provider has no way to configure packages. Without this feature it is a little bit useless, * to identify packages it uses internally *portnames* instead of *port origins*, *portnames* are ambiguous and cause lot of problems (two packages with same *portname* may be installed at same time, and puppet is not able to handle them correctly), * it claims it has `upgradeable` feature, but this doesn't work (what worse - it may approach to downgrade in some situations, fortunatelly without luck), * to list installed packages it uses `pkg_info`, which is a part of the old *pkg* toolstack. FreeBSD is now transitioning to new *pkgng* tools, * once installed a package, the provider is unable to uninstall it in most cases (dependency problems, when other packages depend on it) - this could be easilly mitigated with `uninstall_options` * output of `puppet resource package` is ususally wrong, * no `install_options` feature, * no `uninstall_options` feature, * finally, there seems to be no tests (neither system, nor unit) for this provider I've reimplemented the provider. Currently it's available as a standalone puppet module for installation, but I would like to propose it to be included in puppet core (PR on the way). Most of the issues I've found are resolved the new implementation. They're described here: https://github.com/ptomulik/puppet-packagex#resolved-issues For trying and testing, the standalone module is available at http://forge.puppetlabs.com/ptomulik/packagex Repo available at github: https://github.com/ptomulik/puppet-packagex The PR I'm preparing is simply the `ptomulik-packagex` module converted by a shell script to fit to puppet source tree. -- 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 #23368] Script based external facts fail on Windows 2003
Issue #23368 has been updated by Ethan Brown.
* Merged to stable in
[8eba83858b7ffb3e778c374a1d5b1bdb6e14c819](https://github.com/puppetlabs/facter/commit/8eba83858b7ffb3e778c374a1d5b1bdb6e14c819)
* Merged to master in
[7130e3acc5f320d8ef7accb6b5d6fae92e833d66](https://github.com/puppetlabs/facter/commit/7130e3acc5f320d8ef7accb6b5d6fae92e833d66)
Bug #23368: Script based external facts fail on Windows 2003
https://projects.puppetlabs.com/issues/23368#change-101129
* Author: Josh Cooper
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee:
* Category:
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/569
* Affected Facter version: 1.7.0
Facter's ScriptParser will execute external facts with extensions (bat, cmd,
com, exe) using ruby's `%x{ }`. On 2003, the path to these files will contain a
space, e.g. `C:\Documents and Settings\All Users\Application
Data\PuppetLabs\facter\facts.d`. Since the command is not quoted, it will fail
(it's interpreted as the command `C:\Documents` with arguments `and`,
`Settings\All`, etc.
It is not an issue on 2008 and later, because the path to the script does not
typically contain a space, `C:\ProgramData\PuppetLabs\facter\facts.d`.
It is not an issue with Powershell scripts, because there is a powershell
specific parser that executes `powershell -File 'path/to/file.ps1'`
It is not an issue for text based external facts, because `File.read` does not
require the path to be quoted.
The fix is simple, make sure the path is quoted if it contains spaces.
--
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 #23368] (Merged - Pending Release) Script based external facts fail on Windows 2003
Issue #23368 has been updated by Ethan Brown.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Bug #23368: Script based external facts fail on Windows 2003
https://projects.puppetlabs.com/issues/23368#change-101130
* Author: Josh Cooper
* Status: Merged - Pending Release
* Priority: Normal
* Assignee:
* Category:
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/569
* Affected Facter version: 1.7.0
Facter's ScriptParser will execute external facts with extensions (bat, cmd,
com, exe) using ruby's `%x{ }`. On 2003, the path to these files will contain a
space, e.g. `C:\Documents and Settings\All Users\Application
Data\PuppetLabs\facter\facts.d`. Since the command is not quoted, it will fail
(it's interpreted as the command `C:\Documents` with arguments `and`,
`Settings\All`, etc.
It is not an issue on 2008 and later, because the path to the script does not
typically contain a space, `C:\ProgramData\PuppetLabs\facter\facts.d`.
It is not an issue with Powershell scripts, because there is a powershell
specific parser that executes `powershell -File 'path/to/file.ps1'`
It is not an issue for text based external facts, because `File.read` does not
require the path to be quoted.
The fix is simple, make sure the path is quoted if it contains spaces.
--
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 #23369] (In Topic Branch Pending Review) An empty csr_attributes.yaml file fails with undefined method
Issue #23369 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/2131 Bug #23369: An empty csr_attributes.yaml file fails with undefined method https://projects.puppetlabs.com/issues/23369#change-101131 * Author: Josh Cooper * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 3.4.0-rc1 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2131 See https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e -- 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 #23369] (Merged - Pending Release) An empty csr_attributes.yaml file fails with undefined method
Issue #23369 has been updated by Adrien Thebo. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged into stable in 710e167; this should be released in 3.4.0. Bug #23369: An empty csr_attributes.yaml file fails with undefined method https://projects.puppetlabs.com/issues/23369#change-101132 * Author: Josh Cooper * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 3.4.0-rc1 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2131 See https://github.com/jpartlow/puppet/commit/406ca2233dd83700ea688ebc9c7d2980db02a65e -- 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 #22363] (Merged - Pending Release) Implement new evaluator for future parser
Issue #22363 has been updated by Josh Partlow. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged into master in 8a93b72 Feature #22363: Implement new evaluator for future parser https://projects.puppetlabs.com/issues/22363#change-101135 * Author: Henrik Lindberg * Status: Merged - Pending Release * Priority: Normal * Assignee: Henrik Lindberg * Category: language * Target version: 3.5.0 * Affected Puppet version: * Keywords: language parser evaluation * Branch: https://github.com/puppetlabs/puppet/pull/2123 The future parser currently performs evaluation by transforming the future (nick named pops) AST model into the old (3.x) AST and evaluates the transformed result. The purpose of this evaluator is to untangle the currently nested evaluation behavior (in AST and various other classes) to improve separation of concerns (leading to robustness and code that is easier to work with, debug and extend). Since evaluation of the pops model currently involves transformation to the current AST it is also slow and removal of this step should boost the performance. -- 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 #22365] (Merged - Pending Release) All errors created by future parser ast_transformer lack line numbers
Issue #22365 has been updated by Josh Partlow.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Merged into master in 8a93b72
Bug #22365: All errors created by future parser ast_transformer lack line
numbers
https://projects.puppetlabs.com/issues/22365#change-101136
* Author: Erik Dalén
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: parser
* Target version: 3.5.0
* Affected Puppet version: 3.2.4
* Keywords: future_parser
* Branch: https://github.com/puppetlabs/puppet/pull/2123
Errors created by the ast transformer in the future parser have the wrong type,
so they lack line numbers. An example is:
puppet apply --parser=future -e 'File|| ? {default=foo}'
--
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 #22366] (Merged - Pending Release) The future parser validator doesn't catch using bad resource types in collection queries
Issue #22366 has been updated by Josh Partlow. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged into master in 8a93b72 Bug #22366: The future parser validator doesn't catch using bad resource types in collection queries https://projects.puppetlabs.com/issues/22366#change-101137 * Author: Erik Dalén * Status: Merged - Pending Release * Priority: Normal * Assignee: Henrik Lindberg * Category: parser * Target version: 3.5.0 * Affected Puppet version: 3.2.4 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2123 For example: puppet apply --parser=future -e '1||' Error: Resource type #puppet::pops::model::literalnumber:0x007f822724c1c8 doesn't exist on node dalen -- 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 #22454] (Merged - Pending Release) match variables are only partially shadowed
Issue #22454 has been updated by Josh Partlow.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Merged into master in 8a93b72
Bug #22454: match variables are only partially shadowed
https://projects.puppetlabs.com/issues/22454#change-101138
* Author: Henrik Lindberg
* Status: Merged - Pending Release
* Priority: Normal
* Assignee:
* Category: language
* Target version: 3.5.0
* Affected Puppet version:
* Keywords: language
* Branch: https://github.com/puppetlabs/puppet/pull/2123
Match expressions have the side effect of setting `$0`-`$n` numerical variables
to the matched, and each matched capture.
As many variables as there are captures are set.
The implementation in scope creates a new ephemeral scope-level for each match
expression. As an example:
if 'foobar' =~ /(f)(o)(o)(b)(a)(r)/ and 'foo' =~ /(f)(o)(o)/ {
notice $4
}
Outputs b since the second match did not have a $4.
This is surprising. The most nested ephemeral scope should be responsible for
returning all numeric variables (i.e. from the last successful match).
This behavior have been in place for quite some time.
--
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 #15735] Deprecate 'puppet kick' run mode
Issue #15735 has been updated by Jo Rhett. You only need java and activemq on a single system, not every system. Unless you have tens of thousands of systems (wherein you wouldn't be arguing for puppet kick anyway) activemq's resource consumption will be neglible. For less than a thousand systems IMHO you can safely stick this on any other host in your puppet architecture: puppetmaster, dashboard, puppetdb, etc. It has near-zero I/O requirements except on the network interface. Seriously: pre $ ps -U activemq -u activemq -o cp,pcpu,pmem,rss,stat,f,etime,cputime,cmd CP %CPU %MEM RSS STAT F ELAPSED TIME CMD 0 0.0 0.0 1268 Sl 1 16-13:31:12 00:04:19 /usr/sbin/tanukiwrapper /usr/share/activemq/conf/activemq-wrapper.conf wrapper.syslog.ident=activemq wrapper.pidfile=/var/run/activemq/activemq.pid wrapper.daemonize=TRUE 1 0.1 1.2 204968 Sl 0 16-13:31:12 00:25:55 java -Dactivemq.home=/usr/share/activemq -Dactivemq.base=/usr/share/activemq -Dcom.sun.management.jmxremote -Dorg.apache.activemq.UseDedicatedTaskRunner=true -Xmx512m -Dja /pre Bug #15735: Deprecate 'puppet kick' run mode https://projects.puppetlabs.com/issues/15735#change-101139 * Author: eric sorenson * Status: Re-opened * Priority: High * Assignee: eric sorenson * Category: agent * Target version: 3.x * Affected Puppet version: * Keywords: telly_deprecation * Branch: https://github.com/puppetlabs/puppet/pull/1129 People interested in `puppet kick` functionality should set up mcollective. Supporting it causes problems like #10418. Let's consider removing it for Telly. -- 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 #23366] (Merged - Pending Release) Puppet on Windows can fail to run depending on load order
Issue #23366 has been updated by Josh Cooper. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged into stable in [541eb25b3](https://github.com/puppetlabs/puppet/commit/541eb25b321fafcae822b9c76e56ea841ca01a68) to be released in 3.4.0 Bug #23366: Puppet on Windows can fail to run depending on load order https://projects.puppetlabs.com/issues/23366#change-101140 * Author: Josh Cooper * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 3.4.0-rc1 * Keywords: windows * Branch: https://github.com/puppetlabs/puppet/pull/2128 The Puppet::Util::Windows::Security module doesn't require 'ffi' before using it. The gem is required in other places, though so this seems to be dependent on the load order. pre $ ssh administra...@josh-ny1po54a0o.solar.lan cmd.exe /c puppet agent --test C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:635:in `lt;module:API': uninitialized constant Puppet::Util::Windows::Security::API::FFI (NameError) from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:634:in `lt;module:Security' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows/security.rb:77:in `lt;top (required)' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows.rb:6:in `lt;module:Windows' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/windows.rb:1:in `lt;top (required)' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/monkey_patches.rb:190:in `lt;top (required)' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:16:in `lt;module:Util' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:15:in `lt;module:Puppet' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util.rb:14:in `lt;top (required)' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet.rb:8:in `lt;top (required)' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/puppet/util/command_line.rb:12:in `lt;top (required)' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from C:/ruby193/bin/puppet:3:in `lt;main' /pre The fix is simple, add `require 'ffi'` -- 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 #22944] (Merged - Pending Release) External facts are evaluated many times
Issue #22944 has been updated by Ethan Brown. Status changed from In Topic Branch Pending Review to Merged - Pending Release Merged to stable in [e0bdf2873c8ade9d7a06878d66e6bca902417515](https://github.com/puppetlabs/facter/commit/e0bdf2873c8ade9d7a06878d66e6bca902417515) Merged to master in [20b0ee56b1c35c9ca75b98c58d66c93ec61834fc](https://github.com/puppetlabs/facter/commit/20b0ee56b1c35c9ca75b98c58d66c93ec61834fc) Bug #22944: External facts are evaluated many times https://projects.puppetlabs.com/issues/22944#change-101145 * Author: Matthias Baur * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: * Target version: 1.7.4 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/570 * Affected Facter version: 1.7.3 ** Reproduction ** * Drop script /etc/facter/facts.d/test.sh: pre #!/bin/bash echo SCRIPT CALLED 2 echo test=value /pre * Make script executeable pre chmod +x /etc/facter/facts.d/test.sh /pre * Call 'facter', the following output is shown: pre root@puppet:~# facter SCRIPT CALLED SCRIPT CALLED SCRIPT CALLED SCRIPT CALLED SCRIPT CALLED SCRIPT CALLED ... Regular facter output ... /pre I don't see a reason why the script is called 6 times. System information * Ubuntu 12.04.3 * Facter 1.7.3 -- 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 #23375] (Unreviewed) more verbosity in thing-not-found debug logs
Issue #23375 has been reported by Christopher Wood. Bug #23375: more verbosity in thing-not-found debug logs https://projects.puppetlabs.com/issues/23375 * Author: Christopher Wood * Status: Unreviewed * Priority: Low * Assignee: * Category: error reporting * Target version: * Affected Puppet version: 3.3.2 * Keywords: * Branch: Doing something like this to reproduce a file system permissions issue I had: chmod 000 /etc/puppet/environments/production/modules/puppet And then doing: puppet master --environment production --config /etc/puppet/puppetmaster.conf --debug --verbose --no-daemonize Leads to a message like this in the debug output when trying to do an agent run : Error: Could not find class puppet::agent for a1.cw on node a1.cw Error: Could not find class puppet::agent for a1.cw on node a1.cw Error: Could not find class puppet::agent for a1.cw on node a1.cw But from the strace output, we see that actually it was looking for a specific thing, and couldn't access that thing: lstat(/etc/puppet/environments/production/modules/puppet/manifests/agent.pp, 0x7fff1616b580) = -1 EACCES (Permission denied) Could we please have the reason (File not found, Permission denied, etc.) and the path that the master was looking for also in the debug output following the Could not find class line? For example: Error: Class puppet::agent should be in /etc/puppet/environments/production/modules/puppet/manifests/agent.pp but stat said Permission denied. Assuming the same situation might be the case for templates and similar items, could we please have similar detailed error logging for those too? (I searched for my error and couldn't find similar bugs, my apologies if I missed one.) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://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 #23376] (Unreviewed) Add support for ssh-ed25519 keys to ssh_authorized_key type
Issue #23376 has been reported by Jasper Lievisse Adriaanse. Feature #23376: Add support for ssh-ed25519 keys to ssh_authorized_key type https://projects.puppetlabs.com/issues/23376 * Author: Jasper Lievisse Adriaanse * Status: Unreviewed * Priority: Normal * Assignee: * Category: ssh * Target version: * Affected Puppet version: * Keywords: * Branch: Support for ssh-ed25519 keys was recently committed to OpenSSH [1], this patch adds support for this key to the ssh_authorized_key type. 1: http://marc.info/?l=openbsd-cvsm=138633721618361w=2 -- 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 #23376] (In Topic Branch Pending Review) Add support for ssh-ed25519 keys to ssh_authorized_key type
Issue #23376 has been updated by Jasper Lievisse Adriaanse. Status changed from Unreviewed to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/2132 Feature #23376: Add support for ssh-ed25519 keys to ssh_authorized_key type https://projects.puppetlabs.com/issues/23376#change-101147 * Author: Jasper Lievisse Adriaanse * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: * Category: ssh * Target version: * Affected Puppet version: * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2132 Support for ssh-ed25519 keys was recently committed to OpenSSH [1], this patch adds support for this key to the ssh_authorized_key type. 1: http://marc.info/?l=openbsd-cvsm=138633721618361w=2 -- 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 #21869] (Merged - Pending Release) another Error: Could not request certificate: stack level too deep
Issue #21869 has been updated by Ethan Brown. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version changed from 3.x to 3.4.0 Merged in [b230568095128194fd752db65771bf37fd254fb3](https://github.com/puppetlabs/puppet/commit/b230568095128194fd752db65771bf37fd254fb3) Bug #21869: another Error: Could not request certificate: stack level too deep https://projects.puppetlabs.com/issues/21869#change-101148 * Author: Ilkka Tengvall * Status: Merged - Pending Release * Priority: High * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 3.0.0 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2090 There seems to others like this bug, but they are closed already and this still happens for me. In short: prepuppet agent -v -t -d|tee /home/ec2-user/perror.log bunch of debug log attached separately Error: Could not request certificate: stack level too deep Exiting; failed to retrieve certificate and waitforcert is disabled /pre puppet is from puppetlabs repos yesterday: pre[root@puppet-client puppet]# rpm -q puppet puppet-3.2.3-1.el6.noarch [root@puppetmaster puppet-etc]# rpm -q puppet-server puppet-server-3.2.3-1.el6.noarch /pre I am trying to create a generic machine cert for virtual machines built by Jenkins job. I want the machines with the given cert to be able to register to puppet-master automatically, and assing a profile for themselves. I was following this guide: https://gist.github.com/ahpook/1182243. The OS underneath the both puppet agent and master is RHEL 6.4. I attach the long debug log coming from the command above. I have both the master and the client in the cloud. ! 1. I setup the master with certname with public ip name separate to it's cloud private hostname. pre[master] node_name = facter certname = ospp-float2.hard.ware.fi /pre ! 2. and create the keys for the client pre puppet cert --generate hattara.taivaalla.pilvi /pre ! 3. copy them into place pre # private master:$ssldir/private_keys/hattara.taivaalla.pilvi.pem - client:$ssldir/private_keys/hattara.taivaalla.pilvi.pem # public master:$ssldir/ca/signed/hattara.taivaalla.pilvi.pem - client:$ssldir/certs/hattara.taivaalla.pilvi.pem /pre ! 4. set the generic cert name for the client pre [agent] # let's get assign the node name from facter # and let the fact be fqdn atm, later PaaS profile # from /etc/cybercom-release.yaml certname = hattara.taivaalla.pilvi node_name = facter node_name_fact = fqdn server = ospp-float2.hard.ware.fi /pre ! 5. start puppet master preservice puppetmaster restart/pre ! 6. try the first command. The debug output is attached. prepuppet agent -v -t -d|tee /home/ec2-user/perror.log bunch of debug log attached separately Error: Could not request certificate: stack level too deep Exiting; failed to retrieve certificate and waitforcert is disabled /pre And I see from master http log that the client tries to retrieve the cert. If I retry the command, it behaves differently, some locking problem pre Error: Could not request certificate: Thread(#Thread:0x7f91023bc370 run) not locked. Exiting; failed to retrieve certificate and waitforcert is disabled /pre I can retrieve the cert manually by using curl just fine. pre curl --insecure -H 'Accept: s' https://ospp-float2.hard.ware.fi:8140/production/certificate/ca /pre That's about it. Tried all different things for hours today. I suppose it's a bug. -- 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 #23377] (Accepted) zfs_version broken on Solaris 11
Issue #23377 has been reported by Kylo Ginsberg. Bug #23377: zfs_version broken on Solaris 11 https://projects.puppetlabs.com/issues/23377 * Author: Kylo Ginsberg * Status: Accepted * Priority: Normal * Assignee: Kylo Ginsberg * Category: * Target version: * Keywords: * Branch: * Affected Facter version: facter zfs_version returns nothing on Solaris 11. -- 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 #23374] Ports provider is buggy and lacks several crucial features
Issue #23374 has been updated by Paweł Tomulik. https://github.com/puppetlabs/puppet/pull/2130 Bug #23374: Ports provider is buggy and lacks several crucial features https://projects.puppetlabs.com/issues/23374#change-101153 * Author: Paweł Tomulik * Status: Unreviewed * Priority: High * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: freebsd ports package * Branch: Hi, I was trying to use puppet on FreeBSD with more or less success. One of the biggest problem was the `ports` package provider, which appears to be buggy and lacks some important features. I'm not able to describe in depth all the issues I had, so I'll just leave a short list and provide link to description here. Some of the issues with current ports provider: * no way to define *build options* for a package - normally FreeBSD packages are first configured by user with `make config`, then compiled + installed. Current `ports` provider has no way to configure packages. Without this feature it is a little bit useless, * to identify packages it uses internally *portnames* instead of *port origins*, *portnames* are ambiguous and cause lot of problems (two packages with same *portname* may be installed at same time, and puppet is not able to handle them correctly), * it claims it has `upgradeable` feature, but this doesn't work (what worse - it may approach to downgrade in some situations, fortunatelly without luck), * to list installed packages it uses `pkg_info`, which is a part of the old *pkg* toolstack. FreeBSD is now transitioning to new *pkgng* tools, * once installed a package, the provider is unable to uninstall it in most cases (dependency problems, when other packages depend on it) - this could be easilly mitigated with `uninstall_options` * output of `puppet resource package` is ususally wrong, * no `install_options` feature, * no `uninstall_options` feature, * finally, there seems to be no tests (neither system, nor unit) for this provider I've reimplemented the provider. Currently it's available as a standalone puppet module for installation, but I would like to propose it to be included in puppet core (PR on the way). Most of the issues I've found are resolved the new implementation. They're described here: https://github.com/ptomulik/puppet-packagex#resolved-issues For trying and testing, the standalone module is available at http://forge.puppetlabs.com/ptomulik/packagex Repo available at github: https://github.com/ptomulik/puppet-packagex The PR I'm preparing is simply the `ptomulik-packagex` module converted by a shell script to fit to puppet source tree. -- 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 #18399] Chained resources with empty collections
Issue #18399 has been updated by Adrien Thebo.
Project changed from Puppet Documentation to Puppet
Bug #18399: Chained resources with empty collections
https://projects.puppetlabs.com/issues/18399#change-101154
* Author: Martin Collins
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Hi,
When using chained resources, with a collection within the string, if the
collection is empty, the chain is broken and the resources either side do not
depend on each other.
Example:
test/manifests/init.pp
class test {
$cr = [1, 2]
exec{pre:
command = /bin/true
}
exec{post:
command = /bin/true
}
test::test{$cr: }
Exec[pre]
- Exec| tag == 'inter' |
- Exec[post]
}
test/manifests/test.pp
define test::test{
exec{echo $name:
command = /bin/echo $name,
tag = inter
}
}
Run as is:
!non_empty_collection.jpg!
If we comment out:
test::test{$cr: }
So it is empty, we get empty_collection.jpg, this:
!empty_collection.jpg!
To get the desired result and what I would have expected as the default, I have
to manually add another relationship between pre and post to cater for the
empty collection.
Exec[pre]
- Exec| tag == 'inter' |
- Exec[post]
Exec[pre]
- Exec[post]
Resulting in:
!workaround.jpg!
Is this the intended behaviour? I would expect the workaround relationship to
be implicit (Pre - a collection that happens to be empty - post), as I do not
know how many tags of inter will be created (in my real use, this is pulled
from hiera)
Thanks,
Martin
--
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 #18399] Chained resources with empty collections
Issue #18399 has been updated by Nick Fagerlund.
Yo, that is completely wacky and is almost definitely not intended behavior.
Thanks for spotting it. We've moved it to a puppet issue, and I've made a note
in the docs on chaining arrows about it.
Bug #18399: Chained resources with empty collections
https://projects.puppetlabs.com/issues/18399#change-101155
* Author: Martin Collins
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Hi,
When using chained resources, with a collection within the string, if the
collection is empty, the chain is broken and the resources either side do not
depend on each other.
Example:
test/manifests/init.pp
class test {
$cr = [1, 2]
exec{pre:
command = /bin/true
}
exec{post:
command = /bin/true
}
test::test{$cr: }
Exec[pre]
- Exec| tag == 'inter' |
- Exec[post]
}
test/manifests/test.pp
define test::test{
exec{echo $name:
command = /bin/echo $name,
tag = inter
}
}
Run as is:
!non_empty_collection.jpg!
If we comment out:
test::test{$cr: }
So it is empty, we get empty_collection.jpg, this:
!empty_collection.jpg!
To get the desired result and what I would have expected as the default, I have
to manually add another relationship between pre and post to cater for the
empty collection.
Exec[pre]
- Exec| tag == 'inter' |
- Exec[post]
Exec[pre]
- Exec[post]
Resulting in:
!workaround.jpg!
Is this the intended behaviour? I would expect the workaround relationship to
be implicit (Pre - a collection that happens to be empty - post), as I do not
know how many tags of inter will be created (in my real use, this is pulled
from hiera)
Thanks,
Martin
--
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 #18399] Empty resource collectors can break long relationship chains
Issue #18399 has been updated by Nick Fagerlund.
Subject changed from Chained resources with empty collections to Empty resource
collectors can break long relationship chains
Bug #18399: Empty resource collectors can break long relationship chains
https://projects.puppetlabs.com/issues/18399#change-101156
* Author: Martin Collins
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Hi,
When using chained resources, with a collection within the string, if the
collection is empty, the chain is broken and the resources either side do not
depend on each other.
Example:
test/manifests/init.pp
class test {
$cr = [1, 2]
exec{pre:
command = /bin/true
}
exec{post:
command = /bin/true
}
test::test{$cr: }
Exec[pre]
- Exec| tag == 'inter' |
- Exec[post]
}
test/manifests/test.pp
define test::test{
exec{echo $name:
command = /bin/echo $name,
tag = inter
}
}
Run as is:
!non_empty_collection.jpg!
If we comment out:
test::test{$cr: }
So it is empty, we get empty_collection.jpg, this:
!empty_collection.jpg!
To get the desired result and what I would have expected as the default, I have
to manually add another relationship between pre and post to cater for the
empty collection.
Exec[pre]
- Exec| tag == 'inter' |
- Exec[post]
Exec[pre]
- Exec[post]
Resulting in:
!workaround.jpg!
Is this the intended behaviour? I would expect the workaround relationship to
be implicit (Pre - a collection that happens to be empty - post), as I do not
know how many tags of inter will be created (in my real use, this is pulled
from hiera)
Thanks,
Martin
--
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 #23377] (Merged - Pending Release) zfs_version broken on Solaris 11
Issue #23377 has been updated by Josh Cooper. Status changed from Accepted to Merged - Pending Release Target version set to 2.0.0 Merged in [c5e2e32](https://github.com/puppetlabs/facter/commit/c5e2e32) to be released in facter 2.0 Bug #23377: zfs_version broken on Solaris 11 https://projects.puppetlabs.com/issues/23377#change-101162 * Author: Kylo Ginsberg * Status: Merged - Pending Release * Priority: Normal * Assignee: Kylo Ginsberg * Category: * Target version: 2.0.0 * Keywords: * Branch: * Affected Facter version: facter zfs_version returns nothing on Solaris 11. -- 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 #23135] (Merged - Pending Release) Update Facter Master Windows/Solaris jobs to use vcloud.
Issue #23135 has been updated by Josh Cooper. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 1.7.4 Backported to stable in commit 681de633 Bug #23135: Update Facter Master Windows/Solaris jobs to use vcloud. https://projects.puppetlabs.com/issues/23135#change-101177 * Author: Branan Purvine-Riley * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: * Target version: 1.7.4 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/556 * Affected Facter version: -- 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 - Refactor #22651] (Merged - Pending Release) add fixture access methods for example /proc/cpuinfo files
Issue #22651 has been updated by Josh Cooper. Status changed from Unreviewed to Merged - Pending Release Target version set to 1.7.4 Merged into stable in commit [77b2eab54a](https://github.com/puppetlabs/facter/commit/77b2eab54a90e78365bbb19049a31e3b4e2c5f66) Refactor #22651: add fixture access methods for example /proc/cpuinfo files https://projects.puppetlabs.com/issues/22651#change-101178 * Author: Joshua Hoblitt * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: testing * Target version: 1.7.4 * Keywords: fixtures rspec * Branch: * Affected Facter version: Based on the discussion of #22649 on #puppet with Adrien, it was recommended that we add a `FacterSpec::Cpuinfo` or similar module to house the `/proc/cpuinfo` example fixture access methods I am propossing. -- 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 - Refactor #22649] fixture sources for example `/proc/cpuinfo` files should be consolidated
Issue #22649 has been updated by Josh Cooper. Target version set to 2.0.0 Refactor #22649: fixture sources for example `/proc/cpuinfo` files should be consolidated https://projects.puppetlabs.com/issues/22649#change-101179 * Author: Joshua Hoblitt * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: testing * Target version: 2.0.0 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/538 * Affected Facter version: At present, example versions of `/proc/cpuinfo` are stored under `spec/fixtures/cpuinfo` and `spec/fixtures/unit/physialprocessorcount`. The two sources should be unifed and made accessible via a set of common fixtures access methods. -- 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 #18215] processorcount counting CPU cores on Solaris
Issue #18215 has been updated by Josh Cooper. This was backported to stable in commit [a6d12a5](https://github.com/puppetlabs/facter/commit/a6d12a5) to be released in 1.7.4 Bug #18215: processorcount counting CPU cores on Solaris https://projects.puppetlabs.com/issues/18215#change-101180 * Author: Alex Harvey * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: solaris * Target version: * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/438 * Affected Facter version: The processorcount fact on Solaris is counting CPU cores - pre myhost# facter |grep proc physicalprocessorcount = 1 processor0 = SPARC64-VII processor1 = SPARC64-VII processor2 = SPARC64-VII processor3 = SPARC64-VII processor4 = SPARC64-VII processor5 = SPARC64-VII processor6 = SPARC64-VII processor7 = SPARC64-VII processorcount = 4 /pre - but on linux is counting CPU threads - pre myotherhost# facter |grep proc physicalprocessorcount = 1 processor0 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor1 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor2 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor3 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor4 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor5 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor6 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor7 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processorcount = 8 /pre This is a single 4-core CPU with 8 threads similar to the Solaris example above. A patch here should also provide a processorcorecount fact that preserves the existing behaviour of processorcount on Solaris. See discussions in puppet users https://groups.google.com/forum/?fromgroups=pli=1#!topic/puppet-users/rOj9OszhlQM And puppet developers https://groups.google.com/forum/?fromgroups=pli=1#!topic/puppet-dev/payc4ToNcGQ -- 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 #20739] processorX facts fail on HP superdome servers
Issue #20739 has been updated by Josh Cooper. Target version changed from 2.0.0 to 1.7.4 And it was backported in commit [a6d12a5](https://github.com/puppetlabs/facter/commit/a6d12a5) to be released in 1.7.4. Note the commit message reference ticket #17894 which was deleted, and this ticket replicates. Bug #20739: processorX facts fail on HP superdome servers https://projects.puppetlabs.com/issues/20739#change-101181 * Author: Anonymous * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: hpux * Target version: 1.7.4 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/368 * Affected Facter version: 1.7.1 This was originally ticket #17894, creating a new ticket for it since the old one was deleted but we still need to resolve this issue. We had a pull request for this at one point, but it seems to be gone from GitHub, so I'll mark this as Code Insufficient. -- 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 #18215] processorcount counting CPU cores on Solaris
Issue #18215 has been updated by Josh Cooper. Target version set to 1.7.4 Bug #18215: processorcount counting CPU cores on Solaris https://projects.puppetlabs.com/issues/18215#change-101182 * Author: Alex Harvey * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: solaris * Target version: 1.7.4 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/438 * Affected Facter version: The processorcount fact on Solaris is counting CPU cores - pre myhost# facter |grep proc physicalprocessorcount = 1 processor0 = SPARC64-VII processor1 = SPARC64-VII processor2 = SPARC64-VII processor3 = SPARC64-VII processor4 = SPARC64-VII processor5 = SPARC64-VII processor6 = SPARC64-VII processor7 = SPARC64-VII processorcount = 4 /pre - but on linux is counting CPU threads - pre myotherhost# facter |grep proc physicalprocessorcount = 1 processor0 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor1 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor2 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor3 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor4 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor5 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor6 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processor7 = Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz processorcount = 8 /pre This is a single 4-core CPU with 8 threads similar to the Solaris example above. A patch here should also provide a processorcorecount fact that preserves the existing behaviour of processorcount on Solaris. See discussions in puppet users https://groups.google.com/forum/?fromgroups=pli=1#!topic/puppet-users/rOj9OszhlQM And puppet developers https://groups.google.com/forum/?fromgroups=pli=1#!topic/puppet-dev/payc4ToNcGQ -- 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 #20994] memoryfree and memorysize facts are set to 0 on AIX
Issue #20994 has been updated by Josh Cooper. Target version changed from 2.0.0 to 1.7.4 Backported in commit [cbbb6de](https://github.com/puppetlabs/facter/commit/cbbb6de) to be released in 1.7.4 Bug #20994: memoryfree and memorysize facts are set to 0 on AIX https://projects.puppetlabs.com/issues/20994#change-101183 * Author: Aran Cox * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: library * Target version: 1.7.4 * Keywords: AIX * Branch: https://github.com/puppetlabs/facter/pull/448 * Affected Facter version: development Previous versions of facter 1.6.8 simply didn't have memoryfree and memorysize facts for AIX. Starting with 1.7.1 (or possibly some other intermediate vesion) the memoryfree and memorysize variables are being set to 0, which is worse than not having them. This also affects the head of the master branch. It does not matter if facter is run as root or not, the result is the same: # uname;oslevel;facter --puppet memoryfree memoryfree_mb memorysize memorysize_mb memorytotal AIX 6.1.0.0 memoryfree = 0.00 MB memoryfree_mb = 0.00 memorysize = 0.00 MB memorysize_mb = 0.00 memorytotal = 0.00 MB -- 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 #9546] Plugin sync support for external facts
Issue #9546 has been updated by Josh Cooper. A fix for excluding .bat, .cmd, etc files on non-windows platforms was made in facter in commit [20a2de6e](https://github.com/puppetlabs/facter/commit/20a2de6e5a158f185e26b6ed6797de781ee874d6) Feature #9546: Plugin sync support for external facts https://projects.puppetlabs.com/issues/9546#change-101184 * Author: Ken Barber * Status: Closed * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: * Keywords: external facts * Branch: So now we have external facts (#2157) we would want to be able to synchronise these somehow using pluginsync. -- 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.
