I wasn't seeing expected failures when I started making SLES 10
available, so I switched to using expect { block }.to raise_error(/foo/)
in order to verify that the tests were noticing that errors were no
longer being thrown.

We were determining the master's agent_version based on
file('/opt/puppetlabs/puppet/VERSION'). Since we need to refer to this
in more than one class now, and since it is only used in PE, it makes
sense to move it to the params class and to base it off of the
pe_compiling_server_aio_build() function which inspects the same file.
This way we're not duplicating the function across modules, and we're
not mocking the builtin file() function specifically in our specs.

Introduces support for upgrading SLES 10 agents in PE. SLES 10 does not
have tools for securely handling remote package management.

* puppet-agent package is downloaded from a pe_packages fileserver mount
prepared separately on the master (in puppet_enterprise module)
* the package is downloaded with a File resource, but only if agent node
is not already at the current aio version
* because of limitations in the rpm package provider, it is not feasible
to get the install of the new puppet-agent package to run with '-U
--replacepkgs' flags that would allow rpm to correctly uninstall
conflicting superseded pe-* packages, so we remove those prior to
install. (Passing '-U --replacepkgs' in install_options parameter ends
up failing:

Error: Execution of '/bin/rpm -i "-U --replacepkgs"
/opt/puppetlabs/packages/puppet-agent-1.2.5-1.sles10.x86_64.rpm'
returned 1: -U --replacepkgs: not an rpm package (or package manifest)

* I'm threading package_file_name parameter through because it varies by
platform and ends up being needed both in the prepare and the install
phase for these special case platforms.

...to indicate support for 10 and 11.  I'm not entirely certain how
rspec-puppet-facts works, but this then produced failures for SLES 11.
SLES 10 and 12 aren't tested because rspec-puppet-facts doesn't seem to
generate facts for them.  The fix for SLES 11 was to set is_pe and
operatingsystemmajrelease specifically, and to mock the pe only
functions that the SLES classes need.

(PE-10915) Add SLES 10 upgrade for PE

Based on the work done for PE-10915, add an osfamily class for Solaris
10 and update the install and install/remove_packages classes.

* as with SLES10, we're relying on a pe_packages file mount to have been
set up on the master in order to be able to download the puppet-agent
package we are upgrading too.
* the downloaded package is unzipped
* previous pe-* packages are manually uninstalled prior to installing
pe-puppet

And a fix to the solaris/nexenta spec in puppet_agent_spec.rb to add
architecture.  This began failing the validate_re check in init.pp once
manifest/params.pp had 'Solaris' added to the osfamily case for
supported platforms, and so was no longer failing immediately.

Removing the PUPpuppet and PUPmcollective packages does not stop the
running services.  I've added service resources for both of the old PE
services to ensure they are stopped.  However, it is also critical that
they are stopped as the very last act of the catalog, because stopping
the pe-puppet service, at least on Solaris, terminates the run in mid
progress.  Originally I had the services stopped in the prepare stage,
but had to reposition them.

…s-10

(PE-12001) Add solaris 10

…avoid recreating install_puppet.bat at every agent run.

(maint) allow using the internal mirror when resolving gems

…y release

Prior to this change the puppet agent module has a note that it's to be
used with PE < 2015.3. This Commit updates the metadata.json to note
PE Ankeny versions.

Prior to this commit the puppet_agent module did not accept
the sparc (sun4u/v) arch on Solaris 10.
This commit adds that arch to the accepted architectures, as well
as add special handling on Solaris 10 to use the "sparc" packages
on those arches.

…0_sparc

(PE-12001) Add Solaris 10 sparc to supported arch

…nt_Module_Update_metadata.json_to_include_Ankeny_release

(PE-13179) Puppet Agent Module: Update metadata.json to include Anken…

Prior to this commit upgrades for osx running pe 3.8
were not possible.

This commit adds special logic to remove pe 3.8 from osx.
It also adds support for osx 10.10 and 10.11 as well as
associated specs.

…09-upgrade

Issue/master/pe 10914 add osx 109 upgrade

Before this commit when rspec-puppet would attempt to use the
'that_comes_before' matcher on a POSIX system with the file resource
when the file resource contained a windows path the test would fail.
This is because when puppet converts the catalog to the RAL catalog type
it pokes around in the actual types themselves. Since this is done on a
POSIX based system puppet attempts to validate the absolute path in the
file resource as a POSIX file path and fails since it is not a valid
absolute path.

This commit replaces the call to create the relationship graph to
determine where the windows file resource is at with a more basic test
to assert that the 'before' parameter is filled out on the resource
instead.

…ix-wat

(PE-13608) Do not convert windows file resource to RAL catalog

looks sane and specs are now passing

This change adds puppet agent support for AIX.

Support is gated by the 'aix' operatingsystem fact
and an archetecture fact matching 'PowerPC_POWER[5,6,7]'.

This change uses the same strategy as sles for removing
unused packages as aix doesn't have fully fledged package
management for rpms.

…pport

(PE-12002) Add AIX support

Pass in Puppet agent PID as command line parameter to avoid recreatin…

Prior to this commit you needed access to the internet in
order to upgrade the agent on Windows.
This commit adds support for a PE-hosted MSI to perform the
upgrade. In order to have that MSI available, the user must
classify their master with pe_repo::platform::windows_<architecture>

Prior to this commit we had a platform specific variable for
the local package location hidden away in package::prepare.
This commit moves that platform specific logic to params.pp,
and changes the references to the original veriable to the new
one in params.pp.

Prior to this commit I forgot to add fixes for behavior
on non-PE installs, as well as forgot to move the $_arch
logic around.
This commit fixes non-PE installs, and moves the $_arch up
to `init.pp`.

Prior to this commit the specs were not up to date with the
latest functionality from the module, specifically, the
new PE windows upgrade, which required some path changes.

Prior to this commit I decided to check for a null
`::puppet_agent::service_names`, but I've since
realized that should never really be null at this
point in the module.
This commit reverts the change I made to add a
null check to `::puppet_agent::service_names`.

These syntax errors were causing `rake test` to fail, so they
have been fixed in this commit.

Prior to this commit we were hardcoding the location of
the puppet install to `C:\Program Files\Puppet Labs\Puppet Enterprise`,
but we can't count on the location being set there.
This commit changes the location to use `common_appdata` which
even non-root users should have write access to.

Prior to this commit we were attempting to manage the
puppet/mcollective services on Windows systems, which
resulted in errors in the puppet run due to the MSI being
in the middle of configuring those services.
This commit removes management of the puppet/mco services
on windows systems, because the MSI is handling that already
and attempting to manage it in puppet just creates a race
condition.

Prior to this commit our call to msiexec would not block until
the msi finished. This resulted in any commands dependent on
puppet that were run after a puppet_agent upgrade puppet run would
fail due to puppet still being in the middle of upgrading.
This commit adds a `start /wait` to the msiexec so that, hopefully,
we will block until the MSI finishes running and puppet is actually
upgraded.

Prior to this commit when re-installing the MSI on windows systems,
it would automatically revert the Puppet server setting to whatever
was defined when puppet was initially installed. If that value was
configured to be 'puppet' because no argument was given (as is the
case in beaker) then it would default back to 'puppet', even though
we had set the server to the appropriate master with beaker post-MSI
install.
This commit gets around that surprising behavior by always providing
the currently configured Puppet server value to the MSI.

Prior to this commit we were setting the agent's `server` setting
to whatever `settings::server` was set to, which in a compile master
scenario, would be the MoM. This certainly isn't what a user would
want to have happen in production.
This commit creates a `puppet_master_server` fact populated with the
value of `Puppet.settings['server']` on the agent and uses that as the
argument to the windows MSI upgrade so we don't override the existing
config value with the default of `puppet` or whatever was written to
the registry on install.

(PE-10956) windows upgrade

Prior to this commit we removed management of `/opt/puppetlabs`.
This resulted in platforms that need to create
`/opt/puppetlabs/packages` before installation failing to work
because the parent directory was not present (because packaging
didn't create it yet)

This commit adds `/opt/puppetlabs` to the managed directories.

Added a few specs to the aix, suse, solaris, darwin tests which depend
on /opt/puppetlabs being created before packages are downloaded.

(PE-10956) Manage /opt/puppetlabs

Prior to this commit we didn't verify that the local MSI package
resource existed before trying to install with it.
This commit updates the windows install manifest to check that
the MSI package resource does exist before trying to install it.

Previously, the exec to import the Puppetlabs GPG key made a call out to the
gpg binary to gather the hex value of the Puppetlabs GPG key. This call works
from the console with an ENV, but it doesn't work when automated because it
cannot find the relative homedir (~/.gnupg). To work around this, explicitly
set the value for root's .gnupg homedir in the unless command and expose it as
a variable should we need to deal with it later.

Prior to this commit the specs were failing due to changes in
63e6eb0 to the SLES GPG key
handling.
This commit updates the specs to match those changes.

(MODULES-3015) Fix SLES11 GPG key import issue

Puppet introduced the ability to use strings as the right operand of the regex
match operator, however, when testing this on 3.8.4 SLES11 boxes, I discovered
that they arose errors if the right operand wasn't a regular expression. This
commit corrects that to account for the errors.

Prior to this commit SLES would most likely fail on these
additional `=~` string checks.
This commit updates all the remaining `=~` expressions I could
find to have a regex on the right hand side.

Use slashes for regex

…defined

(PE-10956) Ensure local package resource defined on Windows