| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously, the windows service provider rescued exceptions of type
Win32::Service::Error. However, FFI-based versions of win32-service (v0.8.x)
no longer raise that type of error. Instead they raise SystemCallError.
So previously, if puppet failed to manage a service, e.g. service didn't
exist, puppet would try to rescue the exception specifying a class that
was not defined:
puppet resource service foo ensure=stopped
Error: /Service[foo]: Could not evaluate: uninitialized constant Win32::Service::Error
This regression was introduced as part of PUP-1283 when we migrated from
win32-service version 0.7.x to 0.8.x.
This commit modifies the various provider methods to more broadly rescue
StandardErrors and updates the spec tests to handle the negative cases.
Paired-with: Ethan J Brown <ethan@puppetlabs.com>
|
|
Previously, the agent would reject an SSL connection if the CRL it
downloaded from the CA had a `last_update` time that was slightly in the
future. The agent reports this as "CRL is not yet valid." This issue can
happen when the CA's time is slightly ahead of the agent's time, the CRL
is recently updated, and the agent doesn't already have a cached version
of the CRL (due to PUP-2103).
The CRL not yet valid error sometimes happens during acceptance testing
when we delete the agent's ssl directory, revoke a cert on the master
(which updates the CRL's last_update field), and run the agent (which
downloads the latest CRL).
This commit modifies the verify callback to ignore CRL not yet valid
errors provided all of the following are true:
* current_crl is not nil
* current_crl.last_update is not nil
* current_crl.last_update is strictly less than 5 minutes from now
It also adds specs around unspecified behavior, e.g. ensure the verify
callback returns false when errors are detected.
|
|
This commit adds specs for current behavior, especially that the verify
callback rejects the connection if preverify_ok is false, and we reject
CRLs whose last_update time is more than 5 minutes in the future.
|
|
Previous commit blacklisted a small set of settings from having
$environment interpolated. After some discussion, we decided to broaden
this to a whitelist, and the only setting we can currently think of
needing $environment interpolation when using directory environments is
config_version.
We also decided to not halt startup for default_manifest with
$environment in it, as these errors are difficult to read with the
current error reporting from a rack master. So the validation for
default_manifest is removed.
|
|
* pr/3054:
(maint) Cleanup test to be more readable
(PUP-3174) Make settings catalog skip manifestdir if environmentpath
Closes GH-3054
|
|
The formatting was a little off, which made it hard to see what code was
in the test. This fixes the formatting and uses the resource matcher so
that it can provide a better error message.
|
|
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.
|
|
|
|
Override the Ruby 2.x default of setting accept-encoding to gzip when puppet http_compression is set to false.
|
|
|
|
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.
|
|
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.
|
|
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>
|
|
* 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>
|
|
jpartlow/feature/master/pup-3069-add-defaultmanifest
Feature/master/pup 3069 add defaultmanifest
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
There was a typo in the message that referenced a non existing variable.
This was undetected because there was no test to cover this.
When testing the expected behavior, it was found that the validation
was not correct as it allowed parameters to have hexadecimal names, but
not octal names. Now all numeric parameter names are disallowed (they
cannot be used or addressed anyway).
|
|
This completes the implenentation of the Resource Expression.
* The LHS must now be a QualifiedName (i.e. file, notify), or
a QualifiedReference (i.e. File, Notify), or an access expression
with a left QualifiedReference (i.e. Resource[file]), or literal
'class'
* The result of the LHS must be a CatalogEntry type, and it may not
be detailed to title level.
* The * => syntax can be used to to unfold a hash. It may be used
once per titled resource body. Attribute names must be unique across
the attributes set with name => expr, and those set with * => hash.
|
|
This change was required to be able to see anything relevant regarding
where a problem originated. The fix is to patch the stacktrace
for failed expectencies. While not ideal there is very little that can
be done with Rspec 2 to fix this except reimplementing the support for
produces and fails to be matchers. (Rspec 3 has composable matchers that
may make this simpler).
A ticket has been logged about further improvements to the two support
functions (produces, and fails).
|
|
snippets
In the puppet 4.0 parser, the file resource's mode property will be
required to be a string containing an octal (or symbolic) representation
of mode.
For consistency then, this commit changes all cases where mode was
specified as a Numeric to be a string containing an octal representation
of mode (always prefaced with a 0, again for clarity and consistency).
|
|
The initial commit for this ticket missed the case where
the mode value isn't explicitly specified but rather comes from
source permissions of a file resource, e.g. as happens during
pluginsync.
This change ensures that mode from a source permission is
converted to an octal string if it's a Numeric.
|
|
Before this commit, the spec tests checked for symlink-ignore behavior on all
OSes. After this commit, the spec tests only check symlink-ignore
behavior on OSes that have symlinks.
|
|
|
|
This fixes a problem in the grammar that made it impossible to have
more than one *=> per body.
This commit also adds a check for duplicate entries in the resulting
hash with the final set of parameter to value mapping.
|
|
Before this commit, pmtignore functionality worked, but only after
checking for symlinks, so it was impossible to ignore symlinks. This
commit allows symlinks to be ignored, too.
|
|
Adding spec tests to cover build when .pmtignore/.gitignore files are present/absent
|
|
(PUP-2745) Skip dependencies with malformed dependencies.
|
|
(PUP-2817) Fix zone properties so that nil is not passed through
|
|
Seeing sporadic failures on 1.8.7 with these two tests, probably related
to order of parameter keys not being guaranteed. This patch loosens the
regex on these two tests slightly so that it the keys can be in any
order.
With Britt Gresham <britt@puppetlabs.com>
|
|
Before this patch, when `insync?` was called on the zone properties ip,
dataset and inherit with value nil (happens the first time when the properties
are not present), `true` was returned, which resulted in them not being set
until the values were actually queried, which happened after the installation
of zone. Unfortunately, the inherit property can only be set before
installation.
This patch removes the spurious check for `nil`, which always returned `true`,
and instead handles it similar to when `:absent` is used.
|
|
Prior to this commit if we encountered a dependent candidate module with a
malformed dependency, we would just ignore the malformed dependency.
This commit changes that behavior to ignore the entire dependent candidate as
an invalid module, this preventing the installation of a module with unknown
dependencies.
|
|
Two of the new tests re: Uniquefile are not compatible with
windows. (In the ruby source tree, they are skipped on windows.)
This commit confines them to only run on unix.
|
|
cprice404/feature/master/PUP-3032-setting-to-cache-feature-load-failures
(PUP-3032) Add setting to always cache `feature` load attempts
|
|
cprice404/bug/master/PUP-3030-server-side-tempfiles
(PUP-3030) More explicit handling of tempfiles on the server
|
|
(PUP-1044) Make FileBucket::File use a file when possible
|
|
zaphod42/issue/master/pup-2631-non-existant-env-produces-long-message
(PUP-2631) Elide long URIs for 404 message
|
|
- win32-eventlog gem upgraded from 0.5.3 to 0.6.1 as part of
https://github.com/puppetlabs/puppet/commit/ac8d4e257f69beaf87489b2e2a57f8aaab512edc
- win32-eventlog gem 0.6.1 doesn't yet include the patch necessary to
properly load it on 2003 from:
https://github.com/djberg96/win32-eventlog/commit/4692e2a67ae8dc794981928d6e6488b775a6689a
- Therefore, mark these eventlog tests as pending on 2003 until the
0.6.2 gem ships and the Gemfile can be updated
- These guards will be removed as part of PUP-3061
|
|
This commit adds additional tests for the Uniquefile class. The
new tests are ported from the Ruby 1.9.3 source code for the
built-in `Tempfile` class, since that is what our `Uniquefile`
implementation is based on.
See: https://github.com/ruby/ruby/blob/v1_9_3_547/test/test_tempfile.rb
|
|
Since the new implementation of Puppet::FileSystem::Tempfile is
not trying to manage the deletion of files created through it,
the name was misleading. This commit simply changes the name
to Uniquefile to try to make it a bit more obvious that it is
not responsible for deleting the files.
|
