inspec 2.0.32 → 2.0.45

data/docs/resources/bond.md.erb

@@ -1,90 +1,90 @@
----
-title: About the bond Resource
-platform: linux
----
-
-# bond
-
-Use the `bond` InSpec audit resource to test a logical, bonded network interface (i.e. "two or more network interfaces aggregated into a single, logical network interface"). On Linux platforms, any value in the `/proc/net/bonding` directory may be tested.
-
-<br>
-
-## Syntax
-
-A `bond` resource block declares a bonded network interface, and then specifies the properties of that bonded network interface to be tested:
-
-    describe bond('name') do
-      it { should exist }
-    end
-
-where
-
-* `'name'` is the name of the bonded network interface
-* `{ should exist }` is a valid matcher for this resource
-
-<br>
-
-## Property Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### content
-
-The `content` matcher tests if contents in the file that defines the bonded network interface match the value specified in the test. The values of the `content` matcher are arbitrary.
-
-    its('content') { should match('value') }
-
-### interfaces
-
-The `interfaces` matcher tests if the named secondary interfaces are available.
-
-    its('interfaces') { should eq ['eth0', 'eth1', ...] }
-
-### mode
-
-The `mode` matcher tests the Bonding Mode.
-
-    its('mode') { should eq 'IEEE 802.3ad Dynamic link aggregation' }
-
-### params
-
-The `params` matcher tests arbitrary parameters for the bonded network interface.
-
-    its('params') { should eq 'value' }
-
-### Test if eth0 is a secondary interface for bond0
-
-    describe bond('bond0') do
-      it { should exist }
-      it { should have_interface 'eth0' }
-    end
-
-### Test parameters for bond0
-
-    describe bond('bond0') do
-      its('mode') { should eq 'IEEE 802.3ad Dynamic link aggregation' }
-      its('Transmit Hash Policy') { should eq 'layer3+4 (1)' }
-      its('MII Status') { should eq 'up' }
-      its('MII Polling Interval (ms)') { should eq '100' }
-      its('Up Delay (ms)') { should eq '0' }
-      its('Down Delay (ms)') { should eq '0' }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### exist
-
-The `exist` matcher tests if the bonded network interface is available:
-
-    it { should exist }
-
-### have_interface
-
-The `have_interface` matcher tests if the bonded network interface has one (or more) secondary interfaces:
-
-    it { should have_interface }
-
+---
+title: About the bond Resource
+platform: linux
+---
+
+# bond
+
+Use the `bond` InSpec audit resource to test a logical, bonded network interface (i.e. "two or more network interfaces aggregated into a single, logical network interface"). On Linux platforms, any value in the `/proc/net/bonding` directory may be tested.
+
+<br>
+
+## Syntax
+
+A `bond` resource block declares a bonded network interface, and then specifies the properties of that bonded network interface to be tested:
+
+    describe bond('name') do
+      it { should exist }
+    end
+
+where
+
+* `'name'` is the name of the bonded network interface
+* `{ should exist }` is a valid matcher for this resource
+
+<br>
+
+## Property Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### content
+
+The `content` matcher tests if contents in the file that defines the bonded network interface match the value specified in the test. The values of the `content` matcher are arbitrary.
+
+    its('content') { should match('value') }
+
+### interfaces
+
+The `interfaces` matcher tests if the named secondary interfaces are available.
+
+    its('interfaces') { should eq ['eth0', 'eth1', ...] }
+
+### mode
+
+The `mode` matcher tests the Bonding Mode.
+
+    its('mode') { should eq 'IEEE 802.3ad Dynamic link aggregation' }
+
+### params
+
+The `params` matcher tests arbitrary parameters for the bonded network interface.
+
+    its('params') { should eq 'value' }
+
+### Test if eth0 is a secondary interface for bond0
+
+    describe bond('bond0') do
+      it { should exist }
+      it { should have_interface 'eth0' }
+    end
+
+### Test parameters for bond0
+
+    describe bond('bond0') do
+      its('mode') { should eq 'IEEE 802.3ad Dynamic link aggregation' }
+      its('Transmit Hash Policy') { should eq 'layer3+4 (1)' }
+      its('MII Status') { should eq 'up' }
+      its('MII Polling Interval (ms)') { should eq '100' }
+      its('Up Delay (ms)') { should eq '0' }
+      its('Down Delay (ms)') { should eq '0' }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### exist
+
+The `exist` matcher tests if the bonded network interface is available:
+
+    it { should exist }
+
+### have_interface
+
+The `have_interface` matcher tests if the bonded network interface has one (or more) secondary interfaces:
+
+    it { should have_interface }
+

data/docs/resources/bridge.md.erb

@@ -1,57 +1,57 @@
----
-title: About the bridge Resource
-platform: linux
----
-
-# bridge
-
-Use the `bridge` InSpec audit resource to test basic network bridge properties, such as name, if an interface is defined, and the associations for any defined interface.
-
-<br>
-
-## Syntax
-
-A `bridge` resource block declares the bridge to be tested and what interface it should be associated with:
-
-    describe bridge('br0') do
-      it { should exist }
-      it { should have_interface 'eth0' }
-    end
-
-<br>
-
-## Properties
-
-* On Linux platforms, any value in the `/sys/class/net/{interface}/bridge` directory may be tested
-* On the Windows platform, the `Get-NetAdapter` cmdlet is associated with the `Get-NetAdapterBinding` cmdlet and returns the `ComponentID ms_bridge` value as a JSON object
-
-<br>
-
-## Property Examples
-
-### interfaces
-
-The `interfaces` property tests if the named interface is present:
-
-    its('interfaces') { should eq 'foo' }
-    its('interfaces') { should eq 'bar' }
-    its('interfaces') { should include('foo') }
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### exist
-
-The `exist` matcher tests if the network bridge is available:
-
-    it { should exist }
-
-### have_interface
-
-The `have_interface` matcher tests if the named interface is defined for the network bridge:
-
-    it { should have_interface 'eth0' }
-
+---
+title: About the bridge Resource
+platform: linux
+---
+
+# bridge
+
+Use the `bridge` InSpec audit resource to test basic network bridge properties, such as name, if an interface is defined, and the associations for any defined interface.
+
+<br>
+
+## Syntax
+
+A `bridge` resource block declares the bridge to be tested and what interface it should be associated with:
+
+    describe bridge('br0') do
+      it { should exist }
+      it { should have_interface 'eth0' }
+    end
+
+<br>
+
+## Properties
+
+* On Linux platforms, any value in the `/sys/class/net/{interface}/bridge` directory may be tested
+* On the Windows platform, the `Get-NetAdapter` cmdlet is associated with the `Get-NetAdapterBinding` cmdlet and returns the `ComponentID ms_bridge` value as a JSON object
+
+<br>
+
+## Property Examples
+
+### interfaces
+
+The `interfaces` property tests if the named interface is present:
+
+    its('interfaces') { should eq 'foo' }
+    its('interfaces') { should eq 'bar' }
+    its('interfaces') { should include('foo') }
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### exist
+
+The `exist` matcher tests if the network bridge is available:
+
+    it { should exist }
+
+### have_interface
+
+The `have_interface` matcher tests if the named interface is defined for the network bridge:
+
+    it { should have_interface 'eth0' }
+

data/docs/resources/bsd_service.md.erb

@@ -1,67 +1,67 @@
----
-title: About the bsd_service Resource
-platform: linux
----
-
-# bsd_service
-
-Use the `bsd_service` InSpec audit resource to test a service using a Berkeley OS-style `init` on the FreeBSD platform.
-
-<br>
-
-## Syntax
-
-A `bsd_service` resource block declares the name of a service and then one (or more) matchers to test the state of the service:
-
-    describe bsd_service('service_name') do
-      it { should be_installed }
-      it { should be_enabled }
-      it { should be_running }
-    end
-
-where
-
-* `('service_name')` must specify a service name
-* `be_installed`, `be_enabled`, and `be_running` are valid matchers for this resource.
-
-### Using `bsd_service` resource parameters
-
-#### Path
-
-The path to the service manager's control may be specified for situations where the path isn't available in the current `PATH`. For example:
-
-    describe bsd_service('service_name', '/path/to/control') do
-      it { should be_enabled }
-      it { should be_installed }
-      it { should be_running }
-    end
-
-<br>
-
-## Properties
-
-All properties available to the `service` resource may be used.
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### be_enabled
-
-The `be_enabled` matcher tests if the named service is enabled:
-
-    it { should be_enabled }
-
-### be_installed
-
-The `be_installed` matcher tests if the named service is installed:
-
-    it { should be_installed }
-
-### be_running
-
-The `be_running` matcher tests if the named service is running:
-
-    it { should be_running }
+---
+title: About the bsd_service Resource
+platform: linux
+---
+
+# bsd_service
+
+Use the `bsd_service` InSpec audit resource to test a service using a Berkeley OS-style `init` on the FreeBSD platform.
+
+<br>
+
+## Syntax
+
+A `bsd_service` resource block declares the name of a service and then one (or more) matchers to test the state of the service:
+
+    describe bsd_service('service_name') do
+      it { should be_installed }
+      it { should be_enabled }
+      it { should be_running }
+    end
+
+where
+
+* `('service_name')` must specify a service name
+* `be_installed`, `be_enabled`, and `be_running` are valid matchers for this resource.
+
+### Using `bsd_service` resource parameters
+
+#### Path
+
+The path to the service manager's control may be specified for situations where the path isn't available in the current `PATH`. For example:
+
+    describe bsd_service('service_name', '/path/to/control') do
+      it { should be_enabled }
+      it { should be_installed }
+      it { should be_running }
+    end
+
+<br>
+
+## Properties
+
+All properties available to the `service` resource may be used.
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### be_enabled
+
+The `be_enabled` matcher tests if the named service is enabled:
+
+    it { should be_enabled }
+
+### be_installed
+
+The `be_installed` matcher tests if the named service is installed:
+
+    it { should be_installed }
+
+### be_running
+
+The `be_running` matcher tests if the named service is running:
+
+    it { should be_running }

data/docs/resources/command.md.erb

@@ -1,138 +1,138 @@
----
-title: About the command Resource
-platform: os
----
-
-# command
-
-Use the `command` InSpec audit resource to test an arbitrary command that is run on the system.
-
-<br>
-
-## Syntax
-
-A `command` resource block declares a command to be run, one (or more) expected values, and the location to which that output is sent:
-
-    describe command('command') do
-      it { should exist }
-      its('property') { should eq 'value' }
-    end
-
-where
-
-* `'command'` must specify a command to be run
-* `'property'` is one of `exit_status`, `stderr`, or `stdout`
-* `'output'` tests the output of the command run on the system versus the output value stated in the test
-
-<br>
-
-## Property Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### exit_status
-
-The `exit_status` property tests the exit status for the command:
-
-    its('exit_status') { should eq 123 }
-
-### stderr
-
-The `stderr` property tests results of the command as returned in standard error (stderr):
-
-    its('stderr') { should eq 'error' }
-
-### stdout
-
-The `stdout` property tests results of the command as returned in standard output (stdout). The following example shows matching output using a regular expression:
-
-    describe command('echo 1') do
-       its('stdout') { should match (/[0-9]/) }
-    end
-
-### Test standard output (stdout)
-
-    describe command('echo hello') do
-      its('stdout') { should eq "hello\n" }
-      its('stderr') { should eq '' }
-      its('exit_status') { should eq 0 }
-    end
-
-### Test standard error (stderr)
-
-    describe command('>&2 echo error') do
-      its('stdout') { should eq '' }
-      its('stderr') { should eq "error\n" }
-      its('exit_status') { should eq 0 }
-    end
-
-### Test an exit status code
-
-    describe command('exit 123') do
-      its('stdout') { should eq '' }
-      its('stderr') { should eq '' }
-      its('exit_status') { should eq 123 }
-    end
-
-### Test if the command shell exists
-
-    describe command('/bin/sh').exist? do
-      it { should eq true }
-    end
-
-### Test for a command that should not exist
-
-    describe command('this is not existing').exist? do
-      it { should eq false }
-    end
-
-### Test for PostgreSQL database running a RC, development, or beta release
-
-    describe command('psql -V') do
-      its('stdout') { should eq '/RC/' }
-      its('stdout') { should_not eq '/DEVEL/' }
-      its('stdout') { should_not eq '/BETA/' }
-    end
-
-### Verify NTP
-
-The following example shows how to use the `file` audit resource to verify if the `ntp.conf` and `leap-seconds` files are present, and then the `command` resource to verify if NTP is installed and running:
-
-    describe file('/etc/ntp.conf') do
-       it { should be_file }
-    end
-
-    describe file('/etc/ntp.leapseconds') do
-      it { should be_file }
-    end
-
-    describe command('pgrep ntp') do
-       its('exit_status') { should eq 0 }
-    end
-
-### Verify WiX
-
-Wix includes serveral tools -- such as `candle` (preprocesses and compiles source files into object files), `light` (links and binds object files to an installer database), and `heat` (harvests files from various input formats). The following example uses a whitespace array and the `file` audit resource to verify if these three tools are present:
-
-    %w(
-      candle.exe
-      heat.exe
-      light.exe
-    ).each do |utility|
-      describe file("C:/wix/##{utility}") do
-        it { should be_file }
-      end
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### exist
-
-The `exist` matcher tests if a command may be run on the system:
-
-    it { should exist }
-
+---
+title: About the command Resource
+platform: os
+---
+
+# command
+
+Use the `command` InSpec audit resource to test an arbitrary command that is run on the system.
+
+<br>
+
+## Syntax
+
+A `command` resource block declares a command to be run, one (or more) expected values, and the location to which that output is sent:
+
+    describe command('command') do
+      it { should exist }
+      its('property') { should eq 'value' }
+    end
+
+where
+
+* `'command'` must specify a command to be run
+* `'property'` is one of `exit_status`, `stderr`, or `stdout`
+* `'output'` tests the output of the command run on the system versus the output value stated in the test
+
+<br>
+
+## Property Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### exit_status
+
+The `exit_status` property tests the exit status for the command:
+
+    its('exit_status') { should eq 123 }
+
+### stderr
+
+The `stderr` property tests results of the command as returned in standard error (stderr):
+
+    its('stderr') { should eq 'error' }
+
+### stdout
+
+The `stdout` property tests results of the command as returned in standard output (stdout). The following example shows matching output using a regular expression:
+
+    describe command('echo 1') do
+       its('stdout') { should match (/[0-9]/) }
+    end
+
+### Test standard output (stdout)
+
+    describe command('echo hello') do
+      its('stdout') { should eq "hello\n" }
+      its('stderr') { should eq '' }
+      its('exit_status') { should eq 0 }
+    end
+
+### Test standard error (stderr)
+
+    describe command('>&2 echo error') do
+      its('stdout') { should eq '' }
+      its('stderr') { should eq "error\n" }
+      its('exit_status') { should eq 0 }
+    end
+
+### Test an exit status code
+
+    describe command('exit 123') do
+      its('stdout') { should eq '' }
+      its('stderr') { should eq '' }
+      its('exit_status') { should eq 123 }
+    end
+
+### Test if the command shell exists
+
+    describe command('/bin/sh').exist? do
+      it { should eq true }
+    end
+
+### Test for a command that should not exist
+
+    describe command('this is not existing').exist? do
+      it { should eq false }
+    end
+
+### Test for PostgreSQL database running a RC, development, or beta release
+
+    describe command('psql -V') do
+      its('stdout') { should eq '/RC/' }
+      its('stdout') { should_not eq '/DEVEL/' }
+      its('stdout') { should_not eq '/BETA/' }
+    end
+
+### Verify NTP
+
+The following example shows how to use the `file` audit resource to verify if the `ntp.conf` and `leap-seconds` files are present, and then the `command` resource to verify if NTP is installed and running:
+
+    describe file('/etc/ntp.conf') do
+       it { should be_file }
+    end
+
+    describe file('/etc/ntp.leapseconds') do
+      it { should be_file }
+    end
+
+    describe command('pgrep ntp') do
+       its('exit_status') { should eq 0 }
+    end
+
+### Verify WiX
+
+Wix includes serveral tools -- such as `candle` (preprocesses and compiles source files into object files), `light` (links and binds object files to an installer database), and `heat` (harvests files from various input formats). The following example uses a whitespace array and the `file` audit resource to verify if these three tools are present:
+
+    %w(
+      candle.exe
+      heat.exe
+      light.exe
+    ).each do |utility|
+      describe file("C:/wix/##{utility}") do
+        it { should be_file }
+      end
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### exist
+
+The `exist` matcher tests if a command may be run on the system:
+
+    it { should exist }
+