source function library *before* client sysconfig overrides

My client's environment mandates strict umask settings:
  - 027 for init scripts
  - 077 for normal users
This causes problems when using exec resources or any add-on functions
that exec external scripts/programs.

The fix is relatively simple - run umask in /etc/sysconfig/puppet
and set a more lenient umask for puppet.
However, the /etc/sysconfig/puppet is sourced before the init
function library so any umask changes made in the former are
overridden by any in the latter.

Looking in other init scripts (including the puppetmaster init
script), it is usual for the function library to be sourced at the
start of the init script, ie. before the sysconfig override.

This change simply moves the lines that source the init function
library to the start of the init script.
(maint) Simplify the CA use of the autosign setting

Commit bca628dc adds proper conversion of autosign input values to
booleans, but Puppet::SSL::CertificateAuthority was still trying to
handle string values. This commit simplifies the checking logic and lets
the autosign setting handle data normalization.
(#PUP-1046) Add spec test for skeleton for generated modules

This patch adds a simple spec test to ensure that by including the
class with default values for all the parameters, that the class is
contained within the catalog.
(#FORGE-38) Add Rakefile to skeleton for generated modules

This patch adds a simple Rakefile that provides rake tasks `lint` for
puppet-lint, `validate` for validation of manifests, templates, and ruby
files, and the tasks provided by the puppetlabs_spec_helper.
(PUP-1174) enable the purging of authorized ssh keys

Purging authorized ssh keys is difficult because there is no way know
where key files may be located. Users commented that for most it should
be sufficient to clean the keys from users that puppet manages.
John Bollinger suggested a design that's based on a new parameter to the
user type. There are two ways to use it:

user { "name": purge_ssh_keys => true }

to make puppet purge from the default ~/.ssh/authorized_keys file, or

user { "name": purge_ssh_keys => [ "/etc/keyfiles/name" ] }

to specify one or more files in non-standard locations.

The implementation is similar to the file type's purging code. The user
type now has an eval_trace method that searches the specified files for keys
and adds any unmanaged keys to the catalog with ensure => absent.
(PUP-1174) amend resources type documentation

Add a reference to the new purging feature to the documentation of the
resources type description.
(PUP-1174) add tests for the purge_ssh_keys parameter of the user type
Clarified `pattern` parameter for Service type (DOCUMENT-1)
Clarified the use of slashes around RegEx for `pattern` attribute
(PUP-1586) allow managing existing cronjobs without caring for command

When the catalog contains a cron resource that does not specify a value
for the command property, the transaction would fail with the cryptic
error message 'no command, somehow' under certain conditions.

This error is spurious. Generally, it's quite allowable to manage a subset
of cron properties that does not include the command. Fixed by removing
the devfail invocation. The command property is now handled just like
the 'special' property.
(PUP-1586) remove obsolete unit test

The cron type unit test titled "it should require a command when adding
a new entry" did not quite do what it said. What it actually tested was
that the type would raise an exception when an empty command should-value
was accessed.

This can be safely removed, as PUP-1587 will implement a more sensible
protection against the creation of cronjobs that lack a command, including
a working integration test.
(PUP-1587) crontab: make sure that invalid crontabs aren't written out

It is permissible to manage cron entries and not manage the command
property. However, if the entry doesn't exist on the target system yet,
puppet should not try to create it.

In other words, a cron resource without a should value for the command
property can only be synced to a valid state if the corresponding resource
on the target system has a valid command value already.

cron { "foo": minute => 1 }

is alright with an existing crontab of

 # Puppet Name: foo
 * * * * * /some/command

but not with a crontab not yet containing the entry named 'foo'.

This change prevents the sync operation in the error scenario.
(PUP-1749) Fix module_tool extract for non-gnu tar

This commit refactors how tar is called when the module tool extracts a
downloaded archive so that it is compatible with generic Unix tar, and
does not require GNU extensions. The commit allows the module tool to
work out of the box on Solaris 10, without requiring access to the gtar
command, and presumably this aspect of the module tool will now work
with tar on other old-style unix platforms as well.
Add tests for module_tool changes

I'm not entirely sure if I'm using #yields() correctly but this allows
me to expect that Dir.chdir is called, and still expect all the calls to
Puppet::Util::Execution.execute to be made.
(pup-1766) Remove duplicate test
(pup-1766) Add support for multiple defaultfor's

Prior to this change, it was possible to specify a defaultfor to
cover, say, multiple osfamily's e.g. with:
    defaultfor :osfamily => [:os1, :os2]
Or it was possible to specify a more complex hash, e.g. with
    defaultfor :osfamily => :os1, :operatingsystemmajorrelease => "42"

But if more specificity for just one of the operatingsystem values was
needed, defaultfor couldn't support that. This change allows for this, e.g.:
    defaultfor :osfamily => :os1  # all variants of os1
    defaultfor :osfamily => :os2, :operatingsystemmajrelease => "42"  # only release #42 of this os

To support this change Provider defaults is now an array of hashes (formerly,
it was a merge of the hashes provided by all defaultfor invocations), which requires
commensurate updates to the specificity method and the dochook.

There are also some new spec tests for representative defaultfor combinations, and
two spec tests needed to be updated with the expectation that Facter will be invoked
to assess defaultprovider specificity.
(pup-1766) Set systemd as a default provider for the service type on rhel7
(pup-1766) Add support for :feature to defaultfor

Previous to this change defaultfor had no support for a key
of :feature, however the exec/posix.rb provider assumed
there was such support.

The only reason this worked was that the specificity method
evaluated hash length independent of whether the hash matched
reality in anyway. E.g. exec/posix.rb could just as easily have
specified:
  defaultfor :foo => :nonsense
And it would have a specificity of 1 (yay).

This stops working with the changes in this pull request to
make specificity actually evaluate whether the specified hash
is match in anyway.

So, this commit adds the :feature support to defaultfor which
exec/posix.rb already assumed it had. That file was the only
use of 'defaultfor :feature' I found, but adding this support
seems like potentially useful as an enhancement.
(PUP-1041) nagios: parse empty parameter values in definitions

This is a valid nagios defintion:

define host {
	parents
	use       linux-server
}

That's because an empty parents list has distinct semantics. There may be
other variables that can take an empty value, possibly in conjunction with
object inheritance.

The naginator provider will not accept this definition, because the
nagios config parser expects a value for each and every parameter.

Fix this by adding an according rule to the grammar.

Also, the lexer must be altered, because parameters and values are lexed
differently and returned as distinct tokens. When encountering newline
while scanning for a parameter value, the lexer must give up and reset
its internal state. (Otherwise, it would not accept another parameter
name or the end of the current definition block.)
(pup-1766) Break out at first failed match

The previous version of default_match walked through all of the
hash elements even after finding a failure. This patch uses all?
to break out at the first failed match; as an additional benefit,
the code is cleaner.