| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously, our verify callback stated that it received an SSLContext
parameter, but that is not correct. While there are SSLContext classes
in ruby, the actual object passed is of type StoreContext.
(rdb:1) store_context.class
OpenSSL::X509::StoreContext
|
|
There are a few settings for which interpolation of $environment does
not make sense when using directory environments.
* default_manifest -> defines either the relative path to manifests
within a directory environment, or an absolute path to manifests to be
used by all directory environments. It is currently a configuration
error to set $environment within default_manifest.
* basemodulepath -> conceptually, this is intended for supplemental
modules required for all environments, and should not vary by
environment.
* environmentpath -> this is the base path defining what directory
environments can be found. Interpolating $environment within it makes no
sense.
Additionally, both environmentpath and basemodulepath are required by
the environment loaders during initialization. They will interpolate
relative to a specified environment if you interogate config, but in a
running master instance, will have interpolated to the default
environment regardless of the current environment being processed for a
catalog, for instance.
A last case, irregardless of type of environment, is the pathological
case of attempting to interpolate $environment within environment.
This, unsurprisingly, causes a stack overflow.
This patch adjusts the Puppet::Settings interpolation code so that
$environment is not interpolated within any of these four settings when
using directory environments (so, when the environmentpath has been
set).* So assuming a confdir=/etc/puppet,
basemodulepath=$confdir/modules/$environment will be interpolated as
'/etc/puppet/modules/$environment' and a warning will be logged.
*Currently setting $environment in default_manifest will error out
when puppet loads as a setting validation error, and this behavior will
never be reached.
|
|
* upstream/pr/3057:
correct test description for http_compression disabled
(PUP-1680) Set accept-encoding to identity when http_compression is false
Closes GH-3057
|
|
|
|
Override the Ruby 2.x default of setting accept-encoding to gzip when puppet http_compression is set to false.
|
|
hlindberg/PUP-3177_Stable-Remove-square-bracket-magic-in-titles
(PUP-3177) Remove magic handling of square brackets in resource title
|
|
|
|
The loaders previously assumed that any installation of puppet would be
under a directory called lib. This holds true when running puppet from
source (during development), or in some package cases, but is not
generally true. This simplifying assumption was made so that the loading
path for both puppet system extensions (built in functions) and module
extensions could be loaded in the same manner: find the root of the
extender and loading code from `lib/puppet/...`.
This changes to loading to instead only assume that there is a `puppet`
directory and not the name of the parent. This, however, forces the
loader for modules to become specialized to only be able to find ruby
extentions, because they are in the 'lib' directory, which is how the
loader must now be configured.
|
|
|
|
|
|
- Text from "what is puppet" at
https://docs.puppetlabs.com/guides/faq.html
|
|
|
|
|
|
- git-copyright-scan did the heavy lifting
|
|
|
|
Upstream version 3.7.0
|
|
|
|
The Resource handles square brackets in a resource title as
if it is a complete resource reference. This behavior is there
to support the component resource type, and whits. The implementation
however did not check if a regular type was also given.
This means that any resource with square brackets in its title either
leads to an error, or to the creation of an instance of different
type/title than what was intended.
This commit fixes this by only doing the munging of the title if the
type is nil, component or a whit.
|
|
This makes the settings catalog skip managment of manifestdir if
environmentpath is set.
|
|
* upstream/master:
(packaging) Update PUPPETVERSION to 3.7.0
|
|
|
|
* upstream/master: (767 commits)
(maint) Namespace constant declaration in specs to prevent warnings
(maint) Expect test to fail on windows ruby 2.0 x86
(PUP-3069) Fix path expansion for environment.conf test on Win
(PUP-2349) Add windows specific expectation for deprecation_warning
(PUP-2349) Add windows specific expectation for deprecation_warning
(PUP-3069) Clear configuration_file for tests
(PUP-3069) Test both future and current parser with default_manifest
(PUP-3069) Update default_manifest setting descriptions
(PUP-3069) Change restrict_environment_manifest name
(PUP-3163) Create and manage the mode of $reportsdir
(maint) Clear record of configured deprecated settings
(PUP-3069) Add an integration spec for default_manifest
(PUP-3069) Halt compile if environment has manifest conflict
(PUP-3069) Add spec test for new default options
(PUP-3069) Add default manifest settings
PUP-3155 Improve spec tests around the PE puppet version
(PUP-3153) Guard against nil when closing Uniquefiles
(PUP-2984) Remove old installation directory when going from x64 to x86
(PUP-1884) Migrate MSI deps into puppet repo
(PUP-3154) Create and manage the mode of $statedir on redhat
...
|
|
(docs) Revise and unify explanations of module/file references in functi...
|
|
(docs) Clarify note about ssh_authorized_keys in resources resource type
|
|
Add module namespacing to two specs declaring an FS constant (for
convenience) so that we don't receive warnings about the duplicate
declaration.
|
|
Ruby 2.0 x86 on windows does not observe the 'TZ' environment variable, so the
test would generate a Time object whose `#zone` was 'Eur', but had timezone
offset based on the current timezone.
C:\work\puppet>ruby --version
ruby 2.0.0p481 (2014-05-08) [i386-mingw32]
C:\work\puppet>irb
irb(main):001:0> ENV['TZ'] = 'Europe/London'
=> "Europe/London"
irb(main):002:0> tm = Time.local(2012, "dec", 11, 15, 59, 2)
=> 2012-12-11 15:59:02 -0800
irb(main):003:0> tm.zone
=> "Eur"
irb(main):004:0> tm.gmt_offset
=> -28800
Ironically, ruby 1.9 and 2.0 x64 do the correct thing:
C:\Windows\system32>ruby --version
ruby 2.0.0p481 (2014-05-08) [x64-mingw32]
C:\Windows\system32>irb
irb(main):001:0> ENV['TZ'] = 'Europe/London'
=> "Europe/London"
irb(main):002:0> tm = Time.local(2012, "dec", 11, 15, 59, 2)
=> 2012-12-11 15:59:02 +0000
irb(main):003:0> tm.gmt_offset
=> 0
irb(main):004:0> tm.zone
=> "Eur"
This commit modifies the test so that we expect failure on windows 1.8 and
2.0 x86, otherwise, we expect the test to pass on other ruby platforms.
Reviewed-by: Josh Partlow <joshua.partlow@puppetlabs.com>
|
|
* 'master' of github.com:puppetlabs/puppet:
(PUP-3069) Fix path expansion for environment.conf test on Win
(PUP-2349) Add windows specific expectation for deprecation_warning
|
|
* feature/master/pup-3069-win-spec-fix:
(PUP-3069) Fix path expansion for environment.conf test on Win
|
|
The intention in these specs is for the default_manifest setting
to be absolute for the platform under test. Without an expand_path,
the POSIX style setting we're using will still seem relative on
windows, causing these two tests to fail. Really these settings
should only be used on a master instance, which would be POSIX,
but for completeness sake, this commit expands the initial
default_manifest paths.
|
|
Previously, the spec test assumed that no deprecation warnings would be issued.
However, the test relies on puppet using the `source_permissions` of the
source, and that behavior is deprecated on Windows. As a result, the test
was failing on Windows.
This commit updates the test to expect only the "Copying owner/mode/group/.."
deprecation warning on Windows, and no deprecation warnings on other platforms.
Reviewed-by: Josh Partlow <joshua.partlow@puppetlabs.com>
|
|
Previously, the spec test assumed that no deprecation warnings would be issued.
However, the test relies on puppet using the `source_permissions` of the
source, and that behavior is deprecated on Windows. As a result, the test
was failing on Windows.
This commit updates the test to expect only the "Copying owner/mode/group/.."
deprecation warning on Windows, and no deprecation warnings on other platforms.
|
|
jpartlow/feature/master/pup-3069-add-defaultmanifest
Feature/master/pup 3069 add defaultmanifest
|
|
The new default_manifest integration spec is parsing actual
configuration files and uncovered that our Settings do not clear the
@configuration_file data when #unsafe_clear is called. This allows
parsed settings to leak across specs.
Specifically dropping the @configuration_file in the test helper
Settings#clear_everything_for_tests, resolves this, without changing the
behavior of the Settings#clear, and through it, the Puppet.clear
methods.
|
|
Previously the environments/default_manifest_spec.rb was only running
with the current parser. This runs the set of tests for both the future
and current parser cases.
|
|
Better descriptions of default_manifest and
disable_per_environment_manifest courtesy of Nick Fagerlund.
|
|
hlindberg/PUP-3117_resource-expression-splat-rocket-alt
(PUP-3117) Complete the Resource Expression implementation
|
|
After discussion with Nick Fagerlund and Henrik Lindberg, changing
restrict_environment_manifest setting to
disable_per_environment_manifest to more clearly reflect what the
setting does.
|
|
(PUP-3163) Create and manage the mode of $reportsdir
|
|
For redhat and debian, we create and manage a $statedir with ownership
set to puppet:puppet. Unfortuntely, we also create a $reportsdir that is
owned by root. This means that other applications, even those in the
puppet group, could not write to this directory. This commits adds the
$reportsdir to both debian and redhat packaging to ensure it is created
with the correct permissions (just at the $statedir is), to ensure a
more consistent experience for users of our packages.
|
|
We cache a list of deprecated settings that have been configured in the
initial parse_config, so that later initialization steps allow us to
read the :disable_warnings value, and then decide whether or not to
actually issue a particular warning.
But we weren't clearing this cache in the unsafe_clear call, which was
allowing this state to leak across specs. Once we added that cache
clear to unsafe_clear, we then had to reorder parse_config steps for
unsafe_clear, followed by record_deprecations_from_puppet_conf(data).
|
|
This adds integration testing of the new default_manifest and
restrict_environment_manifest settings. It tests all the way from
Puppet initialization from actual puppet.conf files and
environment/manifest files through catalog compilation, simulating
Puppet master activity. Since these settings are purely server-side
constructs, in that they do not impact the agent beyond the contents of
the final catalog the agent receives, I believe this is sufficient to
validate them.
|
|
Henrik brought up that with the new restrict_environment_manifest
setting set true, authors of modules in a particular environment
may be surprised by a manifest they have specified in their
environment.conf not being pulled in, leading to bad behavior when a
catalog is executed. Although this is logged on the master, compilation
delivery and catalog execution is not prevented.
This commit will raise an exception on the master prior to catalog
compilation if it detect's a conflict between manifest settings in the
requested environment.
|
|
Added tests for checking that default_manifest behaves properly when
given $environment. Also when restrict_environment_manifest is true with
a non-relative default_manifest.
This commit also fixed the hook on the :default_manifest setting to
validate that $environment was not present when setting the value.
|
|
Some Puppet installations do not use environment specific manifests
(particularly when an ENC is in use), however may still have global
setup required for all environments. For these installations it is
convenient to have a :default_manifest setting specified rather than
copying them manifest into every environment.
There are also installations which have a separation of roles between
users mainting the puppet master, puppet.conf and enc, and users making
per environment module changes. In these cases some Puppet installations
prefer to restrict the use of per environment manifests.
These two use cases were handled by setting the global manifest to a
non-interpolated path while setting the global modulepath to a path
interpolated with $environment.
With these settings being deprecated, directory environment
installations did not provide a means of preserving this functionality.
This patch addresses this by providing two new settings:
* default_manifest - is now the fallback manifest path if non is
specified in a given environment's environment.conf. It defaults to the
environment root relative path './manifests' which is the same default
that was previously hardset in early version of directory environments.
* restrict_environment_manifest - if set to true, enforces that
environments cannot define their own manifest setting, and validates
that default_manifest is set to an absolute path.
It is an initialization error if default_manifest is set to a string
that has an '$environment' to be interpolated within it.
We also log an error if restrict_environment_manifest is true and the
loaded environment's environment.conf has a manifest setting that
differs from the default_manifest setting.
|
|
andersonmills/fix/master/PUP-3155-improve_pe_version_spec_tests
PUP-3155 Improve spec tests around the PE puppet version
|
|
cprice404/bug/master/PUP-3153-guard-against-nil-when-closing-uniquefiles
(PUP-3153) Guard against nil when closing Uniquefiles
|
|
Before this commit, when checking the puppet version on a PE build,
several characters; '(', ')' and '.'; caused problems with the regex.
This commit Regexp.escape-s them.
|
|
In a recent commit we introduced `Uniquefile` to use in place
of `Tempfile` for certain code paths. Because `Uniquefile` does
not automatically delete files for you, it is necessary to call
`close!` explicitly if you wish to make sure that they get
removed.
In the original commit I did this in a few places in an `ensure`
block. However, I did not guard against the possibility that
an error might occur when attempting to instantiate the `Uniquefile`
object (e.g., file permissions error), and thus the calls to `close!`
in the `ensure` blocks may result in a NilClass exception (and also
mask the real error).
This commit adds guards to ensure that we only try to call `close!`
if the `Uniquefile` object was actually instantiated.
|
|
Update dependency on puppet_for_the_win:
https://github.com/puppetlabs/puppet_for_the_win/commit/c61dda253b09bd855488f7b6dd7332fdf84d3039
|
|
(PUP-1884) Migrate MSI deps into puppet repo
|
