| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Upstream version 3.7.1
|
|
|
|
Now that we are testing puppet packages with service scripts, the puppet
master defaults to running, and we cannot adjust the puppet user uid
while that user is associated with a runing process. This acceptance
test was stopping the puppet master to remove the system puppet
user/group, but was failing to stop the puppet master when restoring the
system user group, resulting in the puppet system user retaining it's
new uid, and some files (particularly in ssldir) being owned by the old
uid. This would potentially cause failures depending on test order.
This commit fixes the puppet_manages_own_configuration_in_robust_manner
test to stop the puppet master and restore the original user uid.
|
|
|
|
jpartlow/issue/stable/pup-3231-tags-dont-skip-suitability-check
(PUP-3231) Don't check suitability if resource is missing tags.
|
|
A transaction applying resources has to lazily determine suitability of
resources, since changes being made during the application of the
catalog can alter whether the system is now in a state to apply a
resource. Specifically in the case of providers, a provider may become
suitable because of package installation performed during the
application. However if tags are being used, and a resource has not been
tagged, then it should not matter whether or not the specified provider
has been found for the resource.
Prior to this patch, unsuitable, untagged resources would halt the
transaction. With this patch, we check whether the deferred resource is
missing_tags? before issuing an error. With that change, a tagged run
will no longer halt if an untagged resource's provider is not available.
|
|
jpartlow/issue/stable/pup-3136-fix-acceptance-on-lucid
(PUP-3136) Fix upstart acceptance test on lucid
|
|
Due to the fact that this acceptance test depends on the output
of `service rabbitmq-server status`, it was failing on lucid.
This was due to the fact that lucid has an older version of rabbitmq
and therefor a different output than trusty and precise.
Update the regexes and exit codes so that they support lucid. It's
worth noting that since these tests are based on the text output
of `service rabbitmq-server status`, they are fragile and may break
if rabbitmq changes the output of its init.d script. Additionally, if
rabbitmq switches from init.d to upstart we will need to find another
package.
Paired with Will Hopper <whopper@puppetlabs.com>
|
|
cprice404/maint/stable/PUP-3236-gemfile-puppet-loaded
(PUP-3236) Support PUPPET_LOADED env var in Gemfile
|
|
This commit adds support for an environment variable, PUPPET_LOADED,
to be set during bundle installation. If set, the variable will
prevent the puppet gem from being loaded; the use case is for test
environments where you already have puppet available on the load path.
|
|
Windows 2003 doesn't support symlinks, so the test would fail trying to
create one as a precondition for the test. Conditionally execute the
test on platforms that support symlinks.
|
|
zaphod42/issues/stable/pup-3190-cannot-load-4x-funcs-from-system
(PUP-3190) Don't assume puppet is in a lib dir
|
|
|
|
jpartlow/issue/stable/pup-3186-symlinked-production-envdir
(PUP-3186) Skip creation of symlinked default directory env
|
|
To provide a better out of the box user experience, Puppet will ensure
the existence of the default production directory environment. However
if this path has already been created as a symlink, the File resource
will ensure it is replaced with an empty directory.
Since an existing symlink is an indication that the user has already
made configuration changes, and the purpose of ensuring the existence of
the production directory environment is purely for assisting in new,
unmodified installations, this commit skips ensuring anything about the
production directory environment when a symlink is detected.
With Josh Partlow <jpartlow@puppetlabs.com>
|
|
Previously the test failed on windows, because we were expecting the
environment config_version to return on POSIX path. But on Windows it is
expanded based on the current drive.
Paired-with: Josh Partlow <joshua.partlow@puppetlabs.com>
|
|
This changes the fun4x_loadable_from_modules acceptance test
from using the deprecated modulepath to using a directory environment.
|
|
(PUP-3191) Use FileSystem.readlink in unpacker
|
|
|
|
Prior to this commit we were using File.readlink, which does not work properly
on Windows platforms, to tell the user about symlinks found when unpacking.
This commit changes that behavior to instead use the Puppet::Filesystem.readlink
function, which should work on all platforms that support symlinks.
|
|
(PUP-894) Be more lenient about CRL not yet valid errors
|
|
Prior to this commit, upgrading from puppet=2.7.23-1~deb7u3 and
puppetmaster=2.7.23-1~deb7u3 to puppet=3.7.0.29-1puppetlabs1 and
puppetmaster=3.7.0.29-1puppetlabs1 fails. I believe this problem is due
to how Debian chose to package puppet-common, which owns
`/usr/share/man/man8/puppet-master.8.gz`.
This commit adds in a `Conflicts:` to the puppetmaster and
puppetmaster-common packages to make sure that we can successfully
upgrade from these older package versions. However, if a user has
puppetmaster and puppet older than 3.3.0 installed on a machine, and
only upgrades puppetmaster, this will uninstall the puppet package from
the system.
|
|
Issue/stable/pup 3136 upstart acceptance
|
|
This commit modifies the existing test to include detailed exit codes on
the `apply_manifest_on` step so that when the test fails errors will be
helpful.
|
|
It was discovered that when puppet attempted to start apache the
provider would say that it was stopped even though it was starting. On
agents where a puppet master was installed with passenger the apache
service would take longer than usual to start lengthening the starting
process. By the time puppet tested if the service was running or not
apache would still be attempting to start causing the test to fail.
This commit replaces the apache2 package with rabbitmq since it is not
used by puppet and therefore tests down the road will not fail with us
managing it with puppet. It also uses a manifest instead of the
`puppet_resource` function to ensure that there is not any more timing
problems giving us the errors.
|
|
* upstream/pr/3070:
(PUP-3175) Isolate yamldir for node/check_woy_cache_works.rb
|
|
* pr/3069:
(maint) Disable activerecord testcase against puppet-server
(PUP-3173) Fix old references to jvm-puppet in tests.
Closes GH-3069
|
|
Signed-off-by: Wayne <wayne@puppetlabs.com>
|
|
jpartlow/issue/stable/pup-3162-whitelist-environment-interpolation
(PUP-3162) Issue/stable/pup 3162 whitelist environment interpolation
|
|
Signed-off-by: Wayne <wayne@puppetlabs.com>
|
|
Signed-off-by: Wayne <wayne@puppetlabs.com>
|
|
|
|
Previously, the windows security_spec could fail if the same test was
executed in parallel, since the test assumed the account didn't exist.
This commit makes the names unique. The maximum length for local
user and groups accounts in 2003 is 20 and 256 characters[1],
respectively, and we remain below that limit in both cases.
[1] http://technet.microsoft.com/en-us/library/cc783323.aspx
|
|
Commit c752a9ceea was supposed to rescue StandardErrors not
SystemCallErrors so that we do not break in the same way again
if the win32-service gem decides to raise a different exception.
This commit restores rescuing of StandardErrors.
|
|
(PUP-3222) Rescue StandardError instead of non-existent exception
|
|
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.
|
|
(PUP-3157) Allow variable DNS name order in helpful error cert name test
|
|
Add acceptance test for External CA on Jetty
|
|
This commit removes the newline character from the end of the host_entry
method in the acceptance test ExternalCertFixtures. The presence of this
character was causing the jetty_external_root_ca.rb test, when run on
Debian, to not properly set the needed hostname entry into the
/etc/hosts file.
|
|
This commit adds an acceptance test which exercises External CA
functionality against a Jetty configuration.
|
|
This commit updates the
`helpful_error_message_when_hostname_not_match_server_certificate.rb`
test to allow for the order in which the DNS names are enumerated back
from the master server's certificate to be variable. This allows the
test to not errantly fail depending upon the order in which the names
were actually signed into the certificate.
|
|
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.
|
|
(PUP-3191) Fix symlink checking
|
|
Prior to this commit we were trying to use Pathname.realpath to find where a
symlink points to. This throws a file not found when the symlink doesn't point
at anything valid in the filesystem.
This commit fixes that problem by only using File.readlink and not attempting
to find the symlinked file relative to the module unpacking directory.
|
|
|
|
* 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.
|
|
Previously, we assumed that verify_callback was only called once for each
cert in the chain, with preverify_ok set to true or false depending on
whether the cert is verified.
However, openssl call invoke the verify_callback for a number of other
reasons, e.g. CRL not yet valid. In that case, the error is not with
the current_cert, but with the current_crl.
This commit moves the logic for appending the current_cert to the
@peer_certs array only in the case that preverify_ok is true. Does not
cause problems, because we only looked at @peer_certs array if every
cert in the chain was successfully verified.
This commit makes it easier to handle other types of verify errors.
|
