(#15791) isolate deterministic random function

We should not fiddle with the global seed, as other people
might still depend on Kernel.rand() not being that deterministic
as it is the idea with the fqdn_rand function.

However, as ruby < 1.9.2 does not provide such a nice solution, as
a dedicated Random class we simply call Kernel.srand() again on ruby
< 1.9.2 -> Reinitialize with a less deterministic seed.
Remove some duplicate code, simplify

The this_csr_is_for_the_current_host method appeared twice (apparently a
merge error), and produced more confusion than was removed by factoring
it out of the generate_certificate_request method, since "this" in this
case is a host, not a CSR.
(Maint) Re-structure require statements to avoid loop

The way in which the require statements for the puppet/interface module
worked caused a dependency loop that could only be resolved by using the
modules and classes in a very specific order. The tests showed this
problem if they were run in a different order:

  /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface/action_builder.rb:128: uninitialized constant Puppet::Interface::Action (NameError)
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface/action_manager.rb:2
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface.rb:13
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface/action.rb:1
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
    from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/spec/unit/interface/action_spec.rb:3
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load'
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load_spec_files'
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `map'
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load_spec_files'
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:22:in `run'
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:69:in `run'
    from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:10:in `autorun'
    from /opt/csw/bin/rspec:19

This re-orders the requires so that only the top level module
(Puppet::Interface) requires all of the components that are part of it.

Paired-with: patrick@puppetlabs.com
Merge pull request #1562 from zaphod42/maint/load-order-error

(Maint) Re-structure require statements to avoid loop
Use the `message` method to get exception info

Withot this, the error is "Could not request certificate: system lib",
which is not very helpful.
Merge pull request #1563 from djmitche/log-exception-message

Use the `message` method to get exception info
Merge pull request #1558 from djmitche/dupcode

Remove some duplicate code, simplify
Merge pull request #1539 from duritong/fix/master/15791_do_not_fiddle_with_global_seed

(#15791) isolate deterministic random function
(Maint) Ensure that kick tests don't trigger an agent run

This commit fixes the infamous error that appeared periodically as:

````
  1) Puppet::Application::FaceBase#parse_options should stop if the first thing found is not an action
     Failure/Error: @logs.map(&:message).should == ["'basetest' has no 'banana' action.  See `puppet help basetest`."]
       expected: ["'basetest' has no 'banana' action.  See `puppet help basetest`."]
            got: ["Could not run Puppet configuration client: Not a directory - /dev/null/state/agent_catalog_run.lock", "'basetest' has no 'banana' action.  See `puppet help basetest`."] (using ==)
````

The error came from the spec for Puppet::Application::Kick, which tried
to test the error responses from the application calling Puppet::Run.
Unfortunately only one of the 4 tests actually stubbed out the call
which ends up invoking a puppet run via Puppet::Run.

The reason this was so hard to track down is that it only occured if the
thread that was created for the puppet run executed during the later
test and added a message into the log messages tracked in memory. To
find this the kick test and the face_base test were run repeatedly until
the error occurred.

In 2.7.x, this done using ruby 1.9 with the command:

$ rspec --tag "~@fails_on_ruby_1.9.2" spec/unit/application/kick_spec.rb
  spec/unit/application/face_base_spec.rb
Merge remote-tracking branch 'upstream/2.7.x' into 3.1.x

* upstream/2.7.x:
  (Maint) Ensure that kick tests don't trigger an agent run
Merge remote-tracking branch 'upstream/3.1.x'

* upstream/3.1.x:
  (Maint) Ensure that kick tests don't trigger an agent run
(#656) keep crontab from re-applying certain commands

The cron type allows arbitrary text in its command property.
The crontab provider will silently discard leading and trailing spaces
in record fields. Therefor, when parsing the generated records from disk,
the spaces appear to be missing.

To avoid this, it is safe to munge the command and discard the spaces
on the type level. The provider never gets to see them and will not
assume the need to refresh.
Merge pull request #1564 from ffrank/ticket/master/656-cron-dont-keep-refreshing

(#656) keep crontab from re-applying certain commands
(#19876) Fix crontab regression in resource matching

The logic for matching new resources with exiting unmanaged cronjobs
has been reworked during the fix for #16809. Somehow, this lead to
a new issue which caused spurious matches, e.g.:

10 * * * * /bin/true

and

cron { "blank": command => "/bin/true", ensure => present }

would now match. At least puppet will not try to change the name of the
record (i.e., the 'Puppet Name:' line). But the new entry will not get
added either. It still works if there is a non-matching time field, e.g.

cron { "blank": command => "/bin/true", hour => 1 }

but without such fields, the behaviour is wrong.

The match method (in the crontab provider) will expressly ignore named
records on disk. This is safe to do; if the resource does have the
same name as the on-disk record, the match method will not even get invoked.

There is no scenario in which we'd want differently named records to be
matched with a resource. If an on-disk record has a name, it either is
managed through another resource, or it used to be managed. Either way,
the resource in question needs adding or matching to a different record.
(#15561) Extract CN from certificate subjects more carefully

When using certificate chaning or otherwise generating SSL certificates
outside of Puppet, the subject often has multiple components, e.g.,
  CN=hostname.foo.com,O=Foo\, Inc.,OU=Marketing
The hostname, which is later verified against a strict set of allowed
characters, is only extracted from the "CN" field, with all of the other
fields ignored.

This uses OpenSSL::X509::Name to parse the DN's, allowing both
rfc2253-formatted and openssl-formatted DNS, as seen from Apache and
nginx, respectively.
(#15561) Make implementation match spec examples

Without this patch applied, the following spec failure occurs.

    3) Puppet::Util::SSL when getting a CN from a subject should return nil for a bare string
       Failure/Error: described_class.cn_from_subject("/CN=foo").should == nil
       NoMethodError:
         undefined method `to_a' for "/CN=foo":String
       # ./lib/puppet/util/ssl.rb:23:in `cn_from_subject'
       # ./spec/unit/util/ssl_spec.rb:47:in `block (3 levels) in <top (required)>'

This failure is caused by the implementation of the `cn_from_subject` method
calling `to_a` on the string, which raises an exception.

This patch makes the implementation match the specified behavior by checking
for the `to_a` method.  If false, `nil` is returned as expected.
(#15561) Doc only YARD cleanup change
(#15561) Fix spec failure in certificate_request_spec

Without this patch applied, the x.509 CN extraction improvements cause
the following spec failure in the certificate_request_spec.rb file

      1) Puppet::SSL::CertificateRequest when converting from a string should create a CSR ...
         Failure/Error: described_class.from_s("my csr")
         NoMethodError:
           undefined method `to_a' for "/CN=Foo.madstop.com":String
         # ./lib/puppet/util/ssl.rb:23:in `cn_from_subject'
         # ./lib/puppet/ssl/base.rb:54:in `name_from_subject'
         # ./lib/puppet/ssl/base.rb:62:in `from_instance'
         # ./lib/puppet/ssl/base.rb:71:in `from_s'
         # ./spec/unit/ssl/certificate_request_spec.rb:42:in `block (3 levels) in <top (required)>'

Poor stubbing is the root cause of this problem.  The mock certificate
object returns a String from `#subject`, however the system expects a
kind of `OpenSSL::X509::Name`.

This patch addresses the problem by changing the mock object to return
an instance of `OpenSSL::X509::Name` when the mocked `#subject` instance
is called.
(#15561) Merge branch 'djmitche-bug15561-subject-fix'

* djmitche-bug15561-subject-fix:
  (#15561) Fix spec failure in certificate_request_spec
  (#15561) Doc only YARD cleanup change
  (#15561) Make implementation match spec examples
  (#15561) Extract CN from certificate subjects more carefully

closes #1556
Handle exceptions in verify_callback

These exceptions are otherwise ignored, with a message telling you the
exception was ignored but not actually telling you what the exception
was.