Announce: Puppet 3.2.1 Available

[Matthaus Owens]

Puppet 3.2.1 is a bugfix release for the 3.x series of Puppet.

This release addresses two major issues that were uncovered in 3.2.0
and caused us to pull that release (#20726 and #20742). It also
includes a fix for Solaris support (#19760).

Downloads are available at:
* Source https://downloads.puppetlabs.com/puppet/puppet-3.2.1.tar.gz

Available in native package format at:
http://yum.puppetlabs.com and http://apt.puppetlabs.com

Gems are available via rubygems at
https://rubygems.org/downloads/puppet-3.2.1.gem
or by using `gem install puppet`

Mac packages are available at
https://downloads.puppetlabs.com/mac/puppet-3.2.1.dmg

Windows packages are available at
https://downloads.puppetlabs.com/windows/puppet-3.2.1.msi

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 3.2.1:
https://projects.puppetlabs.com/projects/puppet/

=======================
## Puppet 3.2.1 Contributors ##
=======================

Andrew Parker, Hailee Kenney, Josh Cooper, Josh Partlow, Matthaus Owens

=========================
## Puppet 3.2.1 Release Notes ##
=========================

### Issues fixed:

* [Bug #19760]: install sun packages failed with: `Error:
/Stage[main]/Inf_sol10defaultpkg/Package[SMCcurl]: Could not evaluate:
Unable to get information about package SMCcurl because of: No
message`
* [Bug #20726]: usermod command arguments out of order
* [Bug #20742]: unauthenticated clients unable to communicate with
puppet master (running in passenger)

### Known Regressions

On Windows, Puppet 3.2.1 is unable to manage the home directory for a
user account. ([Bug #20768]) This is a regression from Puppet 3.1.1;
it was introduced by switching to Ruby 1.9 in the Windows .msi
package. This bug will be fixed soon in a point release, but wasn't
severe enough to delay shipping.

### All 3.2.1 Changes

To see a list of the issues addressed by this release, check out the
3.2.1 version in our issue tracker at:
https://projects.puppetlabs.com/versions/405

======================
## Puppet 3.2.1 Changelog ##
======================

Andrew Parker (3):
76664ae (Maint) Give each test a meaningful name
ab670d1 (#20742) Handle DNs that cannot be parsed
de34775 (#20742) Only use certifcate info if there is a CN

Josh Cooper (1):
4274d66 (#20726) Manage home has issues on Solaris

Josh Partlow (4):
0588e57 (#20726) Add user managehome acceptance tests
6f92379 Revert "Merge branch 'pull-1512'"
46df39d (#20726) Include password for useradd managehome tests on windows
866ecbc (maint) Change load order for
puppet/provider/package/windows/package

Matthaus Owens (2):
2576f8f (packaging) Update PUPPETVERSION to 3.2.1-rc1
025f00d (packaging) Update PUPPETVERSION to 3.2.1

Nick Fagerlund (1):
b301ada Maint: Improve documentation of filebucket attributes

Stefan Schulte (3):
5e091bb (#19760) Use combine when running pkginfo
887c2037 (#19760) Use pkginfo method instead of execute
f04d271 (#19760) Remove unnecessary stubbing in sun_spec

[Matthaus Owens]

Matt,
What platform are you on? Are you using a cache of some sort in front
of apt? We haven't been able to reproduce this problem.

On Wed, May 22, 2013 at 2:50 PM, Matthew Kennedy <mattke...@gmail.com> wrote:
> It seems that the puppetlabs apt repository is broken with the release of
> these packages.
>
> When trying to install puppetmaster-passenger I now get.... this was working
> 2 hours ago.
>
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> puppetmaster-passenger : Depends: puppetmaster-common (=
> 3.2.1-1puppetlabs1) but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.
>
> Matt

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To post to this group, send email to puppet...@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Matthaus Owens
Release Manager, Puppet Labs

Join us at PuppetConf 2013, August 22-23 in San Francisco -
http://bit.ly/pupconf13
Register now and take advantage of the Early Bird discount - save 25%!

[Matthaus Owens]

I neglected to mention in the announcement email, to support the
"Future" parser, we have added dependencies on ruby-rgen to our puppet
packages that support dependency resolution (gem, deb, rpm). It is
available as a gem
on rubygems.org and packaged as a library in our apt and yum
dependencies repos.

[Andreas Ntaflos]

On 2013-05-22 21:54, Matthaus Owens wrote:
> Puppet 3.2.1 is a bugfix release for the 3.x series of Puppet.

Did something change in the way Puppet outputs messages? Until this
morning we used the following to run Puppet from Cron on all our nodes:

cron { 'puppet_agent':
ensure => 'present',
command => '/usr/bin/puppet agent -o --no-daemonize --logdest syslog',
user => 'root',
minute => [ $min1, $min2, $min3, $min4 ],
}

But as of 3.2.1 this produces output on every Puppet agent run and that
output is mailed out, resulting in hundreds of messages which contain
nothing of importance (see below). This had worked fine for almost two
years now, with output only generated on errors and problems (such as
DNS not available).

We had to change the cron resource to this:

cron { 'puppet_agent':
ensure => 'present',
command => '/usr/bin/puppet agent -o --no-daemonize --logdest syslog
> /dev/null 2>&1',
user => 'root',
minute => [ $min1, $min2, $min3, $min4 ],
}

Is this behaviour change a bug or expected?

Andreas

Typical Puppet agent run output mailed by Cron as of Puppet 3.2.1:

[0;32mInfo: Retrieving plugin [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/lvm_disk_usage.rb [0m
[0;32mInfo: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/puppet_vardir.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/corosync_mcastport.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/libvirt_guests.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/concat_basedir.rb [0m
[0;32mInfo: Loading facts in /var/lib/puppet/lib/facter/has_libvirtd.rb [0m
[0;32mInfo: Loading facts in /var/lib/puppet/lib/facter/root_home.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/postgres_default_version.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/corosync_mcastaddr.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/has_group_libvirtd.rb [0m
[0;32mInfo: Loading facts in
/var/lib/puppet/lib/facter/libvirt_used_memory.rb [0m
[0;32mInfo: Caching catalog for devfw01.fw.rz01.riseops.at [0m
[0;32mInfo: Applying configuration version '1369264386' [0m
[mNotice: Finished catalog run in 17.63 seconds [0m

[Martijn]

Ah, that bit me too. Thanks for clarifying. That's why aptitude was unable to find a correct path to upgrade from Puppet 3.1.

I'll add the dependencies repo on all nodes.

Regards, Martijn

Op donderdag 23 mei 2013 02:08:42 UTC+2 schreef Matthaus Litteken het volgende:

[Thomas Eichberger]

I like the new features in 3.2.1 very much.

My suggestion for the lambda syntax is:

# Alternative 1: Parameters are inside the lambda block. [1,2,3].each { |$value| notice $value }

Then it's more like Ruby.

[Paul Tötterman]

Did something change in the way Puppet outputs messages? Until this 

morning we used the following to run Puppet from Cron on all our nodes:

 

But as of 3.2.1 this produces output on every Puppet agent run and that

output is mailed out, resulting in hundreds of messages which contain
nothing of importance (see below). This had worked fine for almost two
years now, with output only generated on errors and problems (such as
DNS not available).

I'm having the same issue. I couldn't find a bug report about this. There is --verbose and --debug, but not --silent or --quiet. Should we maybe use --logdest? Anyway the behaviour has changed from 3.1.1

Cheers,

Paul

[Andreas Ntaflos]

We have always been using "--logdest syslog", it is only with 3.2.1 that
log messages now seem to go not only to syslog but also to stdout, which
is why Cron generates annoying mail messages.

Even more interesting: before 3.2.1 /var/log/syslog would only show the
"finished catalog run" message when running Puppet from Cron with
"puppet agent -o --no-daemonize --logdest syslog":

May 21 09:30:01 node01 CRON[14018]: (root) CMD (/usr/bin/puppet agent
--onetime --no-daemonize --logdest syslog)
May 21 09:30:38 node01 crontab[15379]: (root) LIST (root)
May 21 09:30:38 node01 puppet-agent[14019]: Finished catalog run in
17.33 seconds

Now it shows everything in /var/log/syslog:

May 24 07:15:01 node01 CRON[23182]: (root) CMD (/usr/bin/puppet agent
--onetime --no-daemonize --logdest syslog > /dev/null 2>&1)
May 24 07:15:02 node01 puppet-agent[23183]: Retrieving plugin
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/postgres_default_version.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/corosync_mcastaddr.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/pe_version.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/concat_basedir.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/root_home.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/lvm_disk_usage.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/corosync_mcastport.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/libvirt_guests.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/libvirt_used_memory.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/puppet_vardir.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/has_libvirtd.rb
May 24 07:15:03 node01 puppet-agent[23183]: Loading facts in
/var/lib/puppet/lib/facter/has_group_libvirtd.rb
May 24 07:15:22 node01 puppet-agent[23183]: Caching catalog for
dbb01.db01.prod.rz01.riseops.at
May 24 07:15:24 node01 puppet-agent[23183]: Applying configuration
version '1369362429'
May 24 07:15:43 node01 crontab[24545]: (root) LIST (root)
May 24 07:15:43 node01 puppet-agent[23183]: Finished catalog run in
20.11 seconds

So, I am asking the Puppet devs: is this behaviour intended or a bug?
Should I open a bug report?

Andreas