facter 2.1.0 → 2.2.0

data/COMMITTERS.md

@@ -5,7 +5,7 @@ We would like to make it easier for community members to contribute to facter
 using pull requests, even if it makes the task of reviewing and committing
 these changes a little harder.  Pull requests are only ever based on a single
 branch, however, we maintain more than one active branch.  As a result
-contributors should target their changes at the facter-2 branch. This makes the
+contributors should target their changes at the master branch. This makes the
 process of contributing a little easier for the contributor since they don't
 need to concern themselves with the question, "What branch do I base my changes
 on?"  This is already called out in the [CONTRIBUTING.md](http://goo.gl/XRH2J).
@@ -37,7 +37,8 @@ making the decision what base branch to merge the change set into.
 
 **base branch** - A branch in Git that contains an active history of changes
 and will eventually be released using semantic version guidelines.  The branch
-named master will always exist as a base branch.
+named master will always exist as a base branch.  All other base branches will
+be associated with a specific released version of facter, e.g. 1.6.x and 1.7.x.
 
 Committer Guide
 ====
@@ -96,7 +97,7 @@ branch:
    documentation being kept up to date?
  * Does the change set include clean code?  (software code that is formatted
    correctly and in an organized manner so that another coder can easily read
-   or modify it.)  HINT: `git diff --check`
+   or modify it.)  HINT: `git diff master --check`
  * Does the change set conform to the contributing guide?
 
 
@@ -112,9 +113,9 @@ paying attention to our automated build tools.
  * Watch the build until your changes have gone through green
  * Update the ticket status and target version.  The target version field in
    our issue tracker should be updated to be the next release of facter.  For
-   example, if the most recent release of facter is 2.0.1 and you merge a
-   backwards compatible change set into facter-2, then the target version should
-   be 2.1.0 in the issue tracker.)
+   example, if the most recent release of facter is 1.6.17 and you merge a
+   backwards compatible change set into master, then the target version should
+   be 1.7.0 in the issue tracker.)
  * Ensure the pull request is closed (Hint: amend your merge commit to contain
    the string `closes #123` where 123 is the pull request number.
 
@@ -125,11 +126,11 @@ This section helps a committer rebase a contribution onto an earlier base
 branch, then merge into the base branch and up through all active base
 branches.
 
-Suppose a contributor submits a pull request based on facter-2.  The change set
-fixes a bug reported against facter 2.0.1 which is the most recently released
+Suppose a contributor submits a pull request based on master.  The change set
+fixes a bug reported against facter 1.7.1 which is the most recently released
 version of facter.
 
-In this example the committer should rebase the change set onto the stable
+In this example the committer should rebase the change set onto the 1.7.x
 branch since this is a bug rather than new functionality.
 
 First, the committer pulls down the branch using the `hub` gem.  This tool
@@ -140,55 +141,45 @@ branch to track the remote branch.
     Branch jeffmccune-fix_foo_error set up to track remote branch fix_foo_error from jeffmccune.
     Switched to a new branch 'jeffmccune-fix_foo_error'
 
-At this point the topic branch is a descendant of facter-2, but we want it to
-descend from stable.  The committer creates a new branch then re-bases the
+At this point the topic branch is a descendant of master, but we want it to
+descend from 1.7.x.  The committer creates a new branch then re-bases the
 change set:
 
-    $ git branch bug/stable/fix_foo_error
-    $ git rebase --onto stable master bug/stable/fix_foo_error
+    $ git branch bug/1.7.x/fix_foo_error
+    $ git rebase --onto 1.7.x master bug/1.7.x/fix_foo_error
     First, rewinding head to replay your work on top of it...
-    Applying: (#23456) Fix FooError that always bites users in 2.0.1
+    Applying: (#23456) Fix FooError that always bites users in 1.7.1
 
 The `git rebase` command may be interpreted as, "First, check out the branch
-named `bug/stable/fix_foo_error`, then take the changes that were previously
-based on `facter-2` and re-base them onto `stable`.
+named `bug/1.7.x/fix_foo_error`, then take the changes that were previously
+based on `master` and re-base them onto `1.7.x`.
 
 Now that we have a topic branch containing the change set based on the correct
 release branch, the committer merges in:
 
-    $ git checkout stable
-    Switched to branch 'stable'
-    $ git merge --no-ff --log bug/stable/fix_foo_error
+    $ git checkout 1.7.x
+    Switched to branch '1.7.x'
+    $ git merge --no-ff --log bug/1.7.x/fix_foo_error
     Merge made by the 'recursive' strategy.
      foo | 0
      1 file changed, 0 insertions(+), 0 deletions(-)
      create mode 100644 foo
 
-Once merged into the first base branch, the committer merges up to facter-2:
-
-    $ git checkout facter-2
-    Switched to branch 'facter-2'
-    $ git merge --no-ff --log stable
-    Merge made by the 'recursive' strategy.
-     foo | 0
-     1 file changed, 0 insertions(+), 0 deletions(-)
-     create mode 100644 foo
-
-And then merges up to master:
+Once merged into the first base branch, the committer merges up:
 
     $ git checkout master
     Switched to branch 'master'
-    $ git merge --no-ff --log stable
+    $ git merge --no-ff --log 1.7.x
     Merge made by the 'recursive' strategy.
      foo | 0
      1 file changed, 0 insertions(+), 0 deletions(-)
      create mode 100644 foo
 
 Once the change set has been merged "in and up." the committer pushes.  (Note,
-the checklist should be complete at this point.)  Note that the stable,
-facter-2 and master branches are being pushed at the same time.
+the checklist should be complete at this point.)  Note that both the 1.7.x and
+master branches are being pushed at the same time.
 
-    $ git push puppetlabs master:master facter-2:facter-2 stable:stable
+    $ git push puppetlabs master:master 1.7.x:1.7.x
 
 That's it!  The committer then updates the pull request, updates the issue in
 our issue tracker, and keeps an eye on the build status.

data/CONTRIBUTING.md

@@ -19,13 +19,13 @@ top of things.
 ## Making Changes
 
 * Create a topic branch from where you want to base your work.
-  * This is usually the facter-2 branch.
+  * This is usually the master branch.
   * Only target release branches if you are certain your fix must be on that
     branch.
-  * To quickly create a topic branch based on facter-2; `git branch
-    fix/facter-2/my_contribution facter-2` then checkout the new branch with `git
-    checkout fix/facter-2/my_contribution`.  Please avoid working directly on the
-    `facter-2` branch.
+  * To quickly create a topic branch based on master; `git branch
+    fix/master/my_contribution master` then checkout the new branch with `git
+    checkout fix/master/my_contribution`.  Please avoid working directly on the
+    `master` branch.
 * Make commits of logical units.
 * Check for unnecessary whitespace with `git diff --check` before committing.
 * Make sure your commit messages are in the proper format.
@@ -47,6 +47,28 @@ top of things.
 * Make sure you have added the necessary tests for your changes.
 * Run _all_ the tests to assure nothing else was accidentally broken.
 
+## Making Trivial Changes
+
+### Documentation
+
+For changes of a trivial nature to comments and documentation, it is not
+always necessary to create a new ticket in Jira. In this case, it is
+appropriate to start the first line of a commit with '(doc)' instead of
+a ticket number.
+
+````
+    (doc) Add documentation commit example to CONTRIBUTING
+
+    There is no example for contributing a documentation commit
+    to the Facter repository. This is a problem because the contributor
+    is left to assume how a commit of this nature may appear.
+
+    The first line is a real life imperative statement with '(doc)' in
+    place of what would have been the ticket number in a
+    non-documentation related commit. The body describes the nature of
+    the new documentation or comments added.
+````
+
 ## Submitting Changes
 
 * Sign the [Contributor License Agreement](http://links.puppetlabs.com/cla).

data/README.md

@@ -7,6 +7,13 @@ like the output of `uname`, public ssh keys, the number of processors, etc.
 
 See `bin/facter` for an example of the interface.
 
+Installation
+------------
+
+Generally, you need the following things installed:
+
+* A supported Ruby version. Ruby 1.8.7, 1.9.3, and 2.0.0 (at least p195) are fully supported.
+
 Running Facter
 --------------
 
@@ -31,3 +38,28 @@ Further Information
 -------------------
 
 See http://www.puppetlabs.com/puppet/related-projects/facter for more details.
+
+Support
+-------
+Please log tickets and issues at our [JIRA tracker](http://tickets.puppetlabs.com).  A [mailing
+list](https://groups.google.com/forum/?fromgroups#!forum/puppet-users) is
+available for asking questions and getting help from others. In addition there
+is an active #puppet channel on Freenode.
+
+We use semantic version numbers for our releases, and recommend that users stay
+as up-to-date as possible by upgrading to patch releases and minor releases as
+they become available.
+
+Bugfixes and ongoing development will occur in minor releases for the current
+major version. Security fixes will be backported to a previous major version on
+a best-effort basis, until the previous major version is no longer maintained.
+
+
+For example: If a security vulnerability is discovered in Facter 2.1.0, we
+would fix it in the 2 series, most likely as 2.1.1. Maintainers would then make
+a best effort to backport that fix onto the latest Facter 1.7 release.
+
+Long-term support, including security patches and bug fixes, is available for
+commercial customers. Please see the following page for more details:
+
+[Puppet Enterprise Support Lifecycle](http://puppetlabs.com/misc/puppet-enterprise-lifecycle)

data/ext/build_defaults.yaml

@@ -2,7 +2,7 @@
 packaging_url: 'git://github.com/puppetlabs/packaging.git --branch=master'
 packaging_repo: 'packaging'
 default_cow: 'base-squeeze-i386.cow'
-cows: 'base-lucid-i386.cow base-lucid-amd64.cow base-precise-i386.cow base-precise-amd64.cow base-quantal-i386.cow base-quantal-amd64.cow base-saucy-i386.cow base-saucy-amd64.cow base-sid-i386.cow base-sid-amd64.cow base-squeeze-i386.cow base-squeeze-amd64.cow base-stable-i386.cow base-stable-amd64.cow base-testing-i386.cow base-testing-amd64.cow base-trusty-i386.cow base-trusty-amd64.cow base-unstable-i386.cow base-unstable-amd64.cow base-wheezy-i386.cow base-wheezy-amd64.cow'
+cows: 'base-lucid-i386.cow base-lucid-amd64.cow base-precise-i386.cow base-precise-amd64.cow base-squeeze-i386.cow base-squeeze-amd64.cow base-stable-i386.cow base-stable-amd64.cow base-testing-i386.cow base-testing-amd64.cow base-trusty-i386.cow base-trusty-amd64.cow base-wheezy-i386.cow base-wheezy-amd64.cow'
 pbuild_conf: '/etc/pbuilderrc'
 packager: 'puppetlabs'
 gpg_name: 'info@puppetlabs.com'

data/ext/debian/control

@@ -7,8 +7,9 @@ Standards-Version: 3.9.1
 Homepage: http://www.puppetlabs.com
 
 Package: facter
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ruby | ruby-interpreter, dmidecode [i386 amd64 ia64], virt-what, pciutils
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, ruby | ruby-interpreter, virt-what, pciutils
+Recommends: lsb-release, dmidecode
 Description: Ruby module for collecting simple facts about a host operating system
  Some of the facts are preconfigured, such as the hostname and the operating
  system. Additional facts can be added through simple Ruby scripts.

data/ext/osx/file_mapping.yaml

@@ -19,6 +19,11 @@ directories:
     owner: 'root'
     group: 'wheel'
     perms: '0644'
+  man/man8:
+    path: 'usr/share/man/man8'
+    owner: 'root'
+    group: 'wheel'
+    perms: '0755'
 files:
   '[A-Z]*':
     path: 'usr/share/doc/facter'

data/ext/redhat/facter.spec.erb

@@ -32,7 +32,10 @@ Requires:       dmidecode
 Requires:       pciutils
 %endif
 Requires:       virt-what
-Requires:       ruby >= 1.8.7
+# In Fedora 19+ or RHEL 7+ net-tools is required for interface facts
+%if 0%{?fedora} >= 19 || 0%{?rhel} >= 7
+Requires:       net-tools
+%endif
 BuildRequires:  ruby >= 1.8.7
 
 # In Fedora 17+ or RHEL 7+ ruby-rdoc is called rubygem-rdoc

data/lib/facter/Cfkey.rb

@@ -1,9 +1,9 @@
-# Fact: Cfkey
+# Fact: cfkey
 #
 # Purpose: Return the public key(s) for CFengine.
 #
 # Resolution:
-#   Tries each file of standard localhost.pub & cfkey.pub locations,
+#   Tries each file of standard `localhost.pub` and `cfkey.pub` locations,
 #   checks if they appear to be a public key, and then join them all together.
 #
 # Caveats:

data/lib/facter/architecture.rb

@@ -4,8 +4,8 @@
 #   Return the CPU hardware architecture.
 #
 # Resolution:
-#   On non-AIX IBM, OpenBSD, Linux and Debian's kfreebsd, use the hardwaremodel fact.
-#   On AIX get the arch value from lsattr -El proc0 -a type
+#   On non-AIX IBM, OpenBSD, Linux, and Debian's kfreebsd, use the hardwaremodel fact.
+#   On AIX get the arch value from `lsattr -El proc0 -a type`.
 #   Gentoo and Debian call "x86_86" "amd64".
 #   Gentoo also calls "i386" "x86".
 #

data/lib/facter/augeasversion.rb

@@ -1,9 +1,9 @@
 # Fact: augeasversion
 #
-# Purpose: Report the version of the Augeas library
+# Purpose: Report the version of the Augeas library.
 #
 # Resolution:
-#   Loads ruby-augeas and reports the value of /augeas/version, the version of
+#   Loads ruby-augeas and reports the value of `/augeas/version`, the version of
 #   the underlying Augeas library.
 #
 # Caveats:

data/lib/facter/blockdevices.rb

@@ -1,50 +1,50 @@
 # Fact: blockdevice_<devicename>_size
 #
 # Purpose:
-#   Return the size of a block device in bytes
+#   Return the size of a block device in bytes.
 #
 # Resolution:
-#   Parse the contents of /sys/block/<device>/size to receive the size (multiplying by 512 to correct for blocks-to-bytes)
+#   Parse the contents of `/sys/block/<device>/size` to receive the size (multiplying by 512 to correct for blocks-to-bytes).
 #
 # Caveats:
-#   Only supports Linux 2.6+ at this time, due to the reliance on sysfs
+#   Only supports Linux 2.6+ at this time, due to the reliance on sysfs.
 #
 
 # Fact: blockdevice_<devicename>_vendor
 #
 # Purpose:
-#   Return the vendor name of block devices attached to the system
+#   Return the vendor name of block devices attached to the system.
 #
 # Resolution:
-#   Parse the contents of /sys/block/<device>/device/vendor to retrieve the vendor for a device
+#   Parse the contents of `/sys/block/<device>/device/vendor` to retrieve the vendor for a device.
 #
 # Caveats:
-#   Only supports Linux 2.6+ at this time, due to the reliance on sysfs
+#   Only supports Linux 2.6+ at this time, due to the reliance on sysfs.
 #
 
 # Fact: blockdevice_<devicename>_model
 #
 # Purpose:
-#   Return the model name of block devices attached to the system
+#   Return the model name of block devices attached to the system.
 #
 # Resolution:
-#   Parse the contents of /sys/block/<device>/device/model to retrieve the model name/number for a device
+#   Parse the contents of `/sys/block/<device>/device/model` to retrieve the model name/number for a device.
 #
 # Caveats:
-#   Only supports Linux 2.6+ at this time, due to the reliance on sysfs
+#   Only supports Linux 2.6+ at this time, due to the reliance on sysfs.
 #
 
 
 # Fact: blockdevices
 #
 # Purpose:
-#   Return a comma seperated list of block devices
+#   Return a comma separated list of block devices.
 #
 # Resolution:
-#   Retrieve the block devices that were identified and iterated over in the creation of the blockdevice_ facts
+#   Retrieve the block devices that were identified and iterated over in the creation of the blockdevice_ facts.
 #
 # Caveats:
-#   Block devices must have been identified using sysfs information
+#   Block devices must have been identified using sysfs information.
 #
 
 # Author: Jason Gill <jasongill@gmail.com>

data/lib/facter/dhcp_servers.rb

@@ -2,14 +2,14 @@
 #
 # Purpose:
 #   Return the DHCP server addresses for all interfaces as a hash.
-#   If the interface that is the default gateway is dhcp assigned, there
-#   will also be a 'system' entry in the hash.
+#   If the interface that is the default gateway is DHCP assigned, there
+#   will also be a `"system"` entry in the hash.
 #
 # Resolution:
-#   Parses the output of nmcli to find the DHCP server for the interface if available
+#   Parses the output of `nmcli` to find the DHCP server for the interface if available.
 #
 # Caveats:
-#   Requires nmcli to be available and the interface must use network-manager.
+#   Requires `nmcli` to be available and the interface must use network-manager.
 #
 
 require 'facter'

data/lib/facter/domain.rb

@@ -5,12 +5,12 @@
 #
 # Resolution:
 #   On UNIX (excluding Darwin), first try and use the hostname fact,
-#   which uses the hostname system command, and then parse the output
+#   which uses the `hostname` system command, and then parse the output
 #   of that.
-#   Failing that it tries the dnsdomainname system command.
-#   Failing that it uses /etc/resolv.conf and takes the domain from that, or as
+#   Failing that, it tries the `dnsdomainname` system command.
+#   Failing that, it uses `/etc/resolv.conf` and takes the domain from that, or as
 #   a final resort, the search from that.
-#   Otherwise returns nil.
+#   Otherwise returns `nil`.
 #
 #   On Windows uses the win32ole gem and winmgmts to get the DNSDomain value
 #   from the Win32 networking stack.

data/lib/facter/ec2.rb

@@ -1,3 +1,20 @@
+# Fact: ec2_<EC2 INSTANCE DATA>
+#
+# Purpose:
+#   Returns info retrieved in bulk from the EC2 API. The names of these facts
+#   should be self explanatory, and they are otherwise undocumented. The full
+#   list of these facts is: ec2_ami_id, ec2_ami_launch_index,
+#   ec2_ami_manifest_path, ec2_block_device_mapping_ami,
+#   ec2_block_device_mapping_ephemeral0, ec2_block_device_mapping_root,
+#   ec2_hostname, ec2_instance_id, ec2_instance_type, ec2_kernel_id,
+#   ec2_local_hostname, ec2_local_ipv4, ec2_placement_availability_zone,
+#   ec2_profile, ec2_public_hostname, ec2_public_ipv4,
+#   ec2_public_keys_0_openssh_key, ec2_reservation_id, and ec2_security_groups.
+#
+# Resolution:
+#   Directly queries the EC2 metadata endpoint.
+#
+
 require 'facter/ec2/rest'
 
 Facter.define_fact(:ec2_metadata) do

data/lib/facter/ec2/rest.rb

@@ -21,7 +21,7 @@ module Facter
 
         begin
           Timeout.timeout(timeout) do
-            open(@baseurl).read
+            open(@baseurl, :proxy => nil).read
           end
           able_to_connect = true
         rescue OpenURI::HTTPError => e
@@ -78,7 +78,7 @@ module Facter
       # @return [Array, NilClass]
       def fetch_endpoint(path)
         uri = @baseurl + path
-        body = open(uri).read
+        body = open(uri, :proxy => nil).read
         parse_results(body)
       rescue OpenURI::HTTPError => e
         if e.message.match /404 Not Found/i

data/lib/facter/facterversion.rb

@@ -1,8 +1,8 @@
 # Fact: facterversion
 #
-# Purpose: returns the version of the facter module.
+# Purpose: Returns the version of the facter module.
 #
-# Resolution: Uses the Facter.version method.
+# Resolution: Uses the `Facter.version` method.
 #
 # Caveats:
 #