Puppet 2.7.7rc2 is available.
This RC addresses a few significant issues found in 2.7.7rc1.
File serving performance issue with large numbers of files:
https://projects.puppetlabs.com/issues/9671
Agent may crash when attempting to manage permissions on non-NTFS
filesystems (on Windows)
https://projects.puppetlabs.com/issues/10614
Serve files in binary mode
https://projects.puppetlabs.com/issues/9983
Additionally, we were able to fix a few other items:
(#10727) Don''t rely on Kernel#Pathname -- this fixes a pre ruby-1.8.5
compatibility issue
(#2744) Display file diffs through the Puppet log system. -- *This
may have impact on your log file sizes*.
Release Notes for 2.7.7 series --
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
This release is available for download at:
http://downloads.puppetlabs.com/puppet/
See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.7rc2
http://projects.puppetlabs.com/projects/puppet
Documentation is available at: http://docs.puppetlabs.com/index.html
Release notes for 2.7.7rc2
(#9617) Speed up recursive file management in 2.7
Through a series of commits the managing file ownership and permissions
recurrsively is much (10x or more) faster. As a side effect this
speed improvement can
be seen in some other scenarios.
(#10614) Detect when trying to managing ACLs on a non-ACL volume
Previously, when managing owner, group, and/or mode on a file whose
volume does not support ACLs, Puppet would raise an error when trying
to get/set the ACL.
This commit allows a file provider to optionally perform validation of
the resource. On Windows, the provider ensures that if owner, group,
and/or mode are being managed, but the underlying volume does not
support ACLs, then we fail early with an appropriate error message.
This is a noop for the POSIX file provider as no validation is
required.
File.expand_path uses the current working directory to generate
absolute paths. This was causing failures when running the specs from
a mapped network drive, e.g. HGFS, since the volume does not support
ACLs. This commit changes these tests to use make_absolute method
instead, and changes that method to always use the local
''C:\'' volume.
(#10614) Provide default metadata values for Windows ACLs
Previously, when sourcing file content from a volume that doesn''t
support Windows ACLs, e.g. VMware shared drive, puppet would raise an
error.
This commit defaults the owner (Administrators), group (Nobody), and
mode (0644), so that content can be sourced without requiring the
owner, group, and mode to be specified in the manifest.
(#10614) Add method for detecting Windows volumes that support ACLs
Added a method to detect whether the root of a given path is on a
volume that supports persistent Windows ACLs. Note it is not enough to
check that the volume type is ''NTFS'' as some filesystems
claim to be
NTFS, but do not support ACLs, e.g. NetApp. Other filesystems like FAT
and CIFS do not support ACLs either.
This commit does not add any new windows gem dependencies, as the
Windows::Volume module is part of the windows-pr gem.
(#10614) Fix setting and clearing read-only attribute on Windows
Previously, we were incorrectly checking the return value of
SetFileAttributes. In cases where we didn''t own the file, the call
to
set/clear the readonly attribute would fail, but we were not raising
an error.
In fixing this, I uncovered ordering issues whereby we needed to set
the file attributes before setting the owner, both in the tests and
the Puppet::Util::Windows::Security module. I also modified the code
to only call SetFileAttributes if it would actually result in a
change, such as when changing the mode, but not the owner or group.
(#10614) Fix error checking for Windows BOOL return values
Previously, the agent could segfault when attempting to manage a DACL
on a non-NTFS filesystem. The problem was that we were incorrectly
checking the return value from several of the Windows APIs due to the
windows gems automatically converting BOOL values into ruby true/false
values.
For example, this call returns a ruby true/false value:
API.new(''IsValidAcl'', ''P'',
''B'', ''advapi32'')
But this one will return an integer value:
API.new(''GetSecurityInfo'', ''LLLPPPPP'',
''L'', ''advapi32'')
The crash is now fixed because we correctly raise an exception when
IsValidAcl returns false.
(#10727) Don''t rely on Kernel#Pathname
A recent change to Puppet::Type::File made use of Kernel#Pathname
which is only available in ruby 1.8.5 and later. Since the change
introduced more incompatibility with pre-1.8.5 for no good reason, and
is trivial to fix, I''m fixing it to use Pathname.new instead.
(#2744) Display file diffs through the Puppet log system.
When Puppet generated a diff between the file on disk, it previously just
printed it directly. This means that the user can view it, but it
is lost in
the rest of the system - monitoring, logs, and reports have no visibility of
this.
Better, then, to send it through our regular logging system, so that the
content is visible in all the places that it might be viewed by the user or
monitored by machines.
(#9508) Default ACL of `auth any` makes sense where we had `auth no`
In `auth.conf`, a setting of `auth no` means that only unauthenticated
requests are allowed. If you actually have a certificate you can''t
use the
service. (Yes, anonymous users have *more* access than authenticated ones.)
This alters the default to `auth any` instead, which allows you to access
these endpoints even where you already have a certificate.
This better supports the distributed model of certificate management anyhow,
now that we have things like the cloud provisioner trying to manage
certificates for other nodes over the network.
(#9983) Serve file content in binary mode
Previously, Puppet::FileServing::Content opened files in text
mode. Changed to binary mode.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.