inspec 2.0.16 → 2.0.17

data/docs/resources/iptables.md.erb

@@ -1,64 +1,64 @@
----
-title: About the iptables Resource
-platform: linux
----
-
-# iptables
-
-Use the `iptables` InSpec audit resource to test rules that are defined in `iptables`, which maintains tables of IP packet filtering rules. There may be more than one table. Each table contains one (or more) chains (both built-in and custom). A chain is a list of rules that match packets. When the rule matches, the rule defines what target to assign to the packet.
-
-<br>
-
-## Syntax
-
-A `iptables` resource block declares tests for rules in IP tables:
-
-    describe iptables(rule:'name', table:'name', chain: 'name') do
-      it { should have_rule('RULE') }
-    end
-
-where
-
-* `iptables()` may specify any combination of `rule`, `table`, or `chain`
-* `rule:'name'` is the name of a rule that matches a set of packets
-* `table:'name'` is the packet matching table against which the test is run
-* `chain: 'name'` is the name of a user-defined chain or one of `ACCEPT`, `DROP`, `QUEUE`, or `RETURN`
-* `have_rule('RULE')` tests that rule in the iptables list. This must match the entire line taken from `iptables -S CHAIN`.
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test if the INPUT chain is in default ACCEPT mode
-
-    describe iptables do
-      it { should have_rule('-P INPUT ACCEPT') }
-    end
-
-### Test if the INPUT chain from the mangle table is in ACCEPT mode
-
-    describe iptables(table:'mangle', chain: 'INPUT') do
-      it { should have_rule('-P INPUT ACCEPT') }
-    end
-
-### Test if there is a rule allowing Postgres (5432/TCP) traffic
-
-    describe iptables do
-      it { should have_rule('-A INPUT -p tcp -m tcp -m multiport --dports 5432 -m comment --comment "postgres" -j ACCEPT') }
-    end
-
-Note that the rule specification must exactly match what's in the output of `iptables -S INPUT`, which will depend on how you've built your rules.
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### have_rule
-
-The `have_rule` matcher tests the named rule against the information in the `iptables` file:
-
-    it { should have_rule('RULE') }
+---
+title: About the iptables Resource
+platform: linux
+---
+
+# iptables
+
+Use the `iptables` InSpec audit resource to test rules that are defined in `iptables`, which maintains tables of IP packet filtering rules. There may be more than one table. Each table contains one (or more) chains (both built-in and custom). A chain is a list of rules that match packets. When the rule matches, the rule defines what target to assign to the packet.
+
+<br>
+
+## Syntax
+
+A `iptables` resource block declares tests for rules in IP tables:
+
+    describe iptables(rule:'name', table:'name', chain: 'name') do
+      it { should have_rule('RULE') }
+    end
+
+where
+
+* `iptables()` may specify any combination of `rule`, `table`, or `chain`
+* `rule:'name'` is the name of a rule that matches a set of packets
+* `table:'name'` is the packet matching table against which the test is run
+* `chain: 'name'` is the name of a user-defined chain or one of `ACCEPT`, `DROP`, `QUEUE`, or `RETURN`
+* `have_rule('RULE')` tests that rule in the iptables list. This must match the entire line taken from `iptables -S CHAIN`.
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test if the INPUT chain is in default ACCEPT mode
+
+    describe iptables do
+      it { should have_rule('-P INPUT ACCEPT') }
+    end
+
+### Test if the INPUT chain from the mangle table is in ACCEPT mode
+
+    describe iptables(table:'mangle', chain: 'INPUT') do
+      it { should have_rule('-P INPUT ACCEPT') }
+    end
+
+### Test if there is a rule allowing Postgres (5432/TCP) traffic
+
+    describe iptables do
+      it { should have_rule('-A INPUT -p tcp -m tcp -m multiport --dports 5432 -m comment --comment "postgres" -j ACCEPT') }
+    end
+
+Note that the rule specification must exactly match what's in the output of `iptables -S INPUT`, which will depend on how you've built your rules.
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### have_rule
+
+The `have_rule` matcher tests the named rule against the information in the `iptables` file:
+
+    it { should have_rule('RULE') }

data/docs/resources/json.md.erb

@@ -1,62 +1,62 @@
----
-title: About the json Resource
-platform: os
----
-
-# json
-
-Use the `json` InSpec audit resource to test data in a JSON file.
-
-<br>
-
-## Syntax
-
-A `json` resource block declares the data to be tested. Assume the following JSON file:
-
-    {
-      "name" : "hello",
-      "meta" : {
-        "creator" : "John Doe"
-      },
-      "array": [
-        "zero",
-        "one"
-      ]
-    }
-
-This file can be queried using:
-
-    describe json('/path/to/name.json') do
-      its('name') { should eq 'hello' }
-      its(['meta','creator']) { should eq 'John Doe' }
-      its(['array', 1]) { should eq 'one' }
-    end
-
-where
-
-* `name` is a configuration setting in a JSON file
-* `should eq 'foo'` tests a value of `name` as read from a JSON file versus the value declared in the test
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test a cookbook version in a policyfile.lock.json file
-
-    describe json('policyfile.lock.json') do
-      its(['cookbook_locks', 'omnibus', 'version']) { should eq('2.2.0') }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### name
-
-The `name` matcher tests the value of `name` as read from a JSON file versus the value declared in the test:
-
-    its('name') { should eq 'foo' }
+---
+title: About the json Resource
+platform: os
+---
+
+# json
+
+Use the `json` InSpec audit resource to test data in a JSON file.
+
+<br>
+
+## Syntax
+
+A `json` resource block declares the data to be tested. Assume the following JSON file:
+
+    {
+      "name" : "hello",
+      "meta" : {
+        "creator" : "John Doe"
+      },
+      "array": [
+        "zero",
+        "one"
+      ]
+    }
+
+This file can be queried using:
+
+    describe json('/path/to/name.json') do
+      its('name') { should eq 'hello' }
+      its(['meta','creator']) { should eq 'John Doe' }
+      its(['array', 1]) { should eq 'one' }
+    end
+
+where
+
+* `name` is a configuration setting in a JSON file
+* `should eq 'foo'` tests a value of `name` as read from a JSON file versus the value declared in the test
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test a cookbook version in a policyfile.lock.json file
+
+    describe json('policyfile.lock.json') do
+      its(['cookbook_locks', 'omnibus', 'version']) { should eq('2.2.0') }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### name
+
+The `name` matcher tests the value of `name` as read from a JSON file versus the value declared in the test:
+
+    its('name') { should eq 'foo' }

data/docs/resources/kernel_module.md.erb

@@ -1,107 +1,107 @@
----
-title: About the kernel_module Resource
-platform: linux
----
-
-# kernel_module
-
-Use the `kernel_module` InSpec audit resource to test kernel modules on Linux
-platforms. These parameters are located under `/lib/modules`. Any submodule may
-be tested using this resource.
-
-The `kernel_module` resource can also verify if a kernel module is `blacklisted`
-or if a module is disabled via a fake install using the `bin_true` or `bin_false`
-method.
-
-<br>
-
-## Syntax
-
-A `kernel_module` resource block declares a module name, and then tests if that
-module is a loadable kernel module, if it is enabled, disabled or if it is
-blacklisted:
-
-    describe kernel_module('module_name') do
-      it { should be_loaded }
-      it { should_not be_disabled }
-      it { should_not be_blacklisted }
-    end
-
-where
-
-* `'module_name'` must specify a kernel module, such as `'bridge'`
-* `{ should be_loaded }` tests if the module is a loadable kernel module
-* `{ should be_blacklisted }` tests if the module is blacklisted or if the module is disabled via a fake install using /bin/false or /bin/true
-* `{ should be_disabled }` tests if the module is disabled via a fake install using /bin/false or /bin/true
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test a modules 'version'
-
-      describe kernel_module('bridge') do
-        it { should be_loaded }
-        its(:version) { should cmp >= '2.2.2' }
-      end
-
-### Test if a module is loaded, not disabled and not blacklisted
-
-      describe kernel_module('video') do
-        it { should be_loaded }
-        it { should_not be_disabled }
-        it { should_not be_blacklisted }
-      end
-
-### Check if a module is blacklisted
-
-      describe kernel_module('floppy') do
-        it { should be_blacklisted }
-      end
-
-### Ensure a module is *not* blacklisted and it is loaded
-
-      describe kernel_module('video') do
-        it { should_not be_blacklisted }
-        it { should be_loaded }
-      end
-
-### Ensure a module is disabled via 'bin_false'
-
-      describe kernel_module('sstfb') do
-        it { should_not be_loaded }
-        it { should be_disabled }
-      end
-
-### Ensure a module is 'blacklisted'/'disabled' via 'bin_true'
-
-      describe kernel_module('nvidiafb') do
-        it { should_not be_loaded }
-        it { should be_blacklisted }
-      end
-
-### Ensure a module is not loaded
-
-      describe kernel_module('dhcp') do
-        it { should_not be_loaded }
-      end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### be_loaded
-
-The `be_loaded` matcher tests if the module is a loadable kernel module:
-
-    it { should be_loaded }
-
-### version
-
-The `version` matcher tests if the named module version is on the system:
-
-    its(:version) { should eq '3.2.2' }
+---
+title: About the kernel_module Resource
+platform: linux
+---
+
+# kernel_module
+
+Use the `kernel_module` InSpec audit resource to test kernel modules on Linux
+platforms. These parameters are located under `/lib/modules`. Any submodule may
+be tested using this resource.
+
+The `kernel_module` resource can also verify if a kernel module is `blacklisted`
+or if a module is disabled via a fake install using the `bin_true` or `bin_false`
+method.
+
+<br>
+
+## Syntax
+
+A `kernel_module` resource block declares a module name, and then tests if that
+module is a loadable kernel module, if it is enabled, disabled or if it is
+blacklisted:
+
+    describe kernel_module('module_name') do
+      it { should be_loaded }
+      it { should_not be_disabled }
+      it { should_not be_blacklisted }
+    end
+
+where
+
+* `'module_name'` must specify a kernel module, such as `'bridge'`
+* `{ should be_loaded }` tests if the module is a loadable kernel module
+* `{ should be_blacklisted }` tests if the module is blacklisted or if the module is disabled via a fake install using /bin/false or /bin/true
+* `{ should be_disabled }` tests if the module is disabled via a fake install using /bin/false or /bin/true
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test a modules 'version'
+
+      describe kernel_module('bridge') do
+        it { should be_loaded }
+        its(:version) { should cmp >= '2.2.2' }
+      end
+
+### Test if a module is loaded, not disabled and not blacklisted
+
+      describe kernel_module('video') do
+        it { should be_loaded }
+        it { should_not be_disabled }
+        it { should_not be_blacklisted }
+      end
+
+### Check if a module is blacklisted
+
+      describe kernel_module('floppy') do
+        it { should be_blacklisted }
+      end
+
+### Ensure a module is *not* blacklisted and it is loaded
+
+      describe kernel_module('video') do
+        it { should_not be_blacklisted }
+        it { should be_loaded }
+      end
+
+### Ensure a module is disabled via 'bin_false'
+
+      describe kernel_module('sstfb') do
+        it { should_not be_loaded }
+        it { should be_disabled }
+      end
+
+### Ensure a module is 'blacklisted'/'disabled' via 'bin_true'
+
+      describe kernel_module('nvidiafb') do
+        it { should_not be_loaded }
+        it { should be_blacklisted }
+      end
+
+### Ensure a module is not loaded
+
+      describe kernel_module('dhcp') do
+        it { should_not be_loaded }
+      end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### be_loaded
+
+The `be_loaded` matcher tests if the module is a loadable kernel module:
+
+    it { should be_loaded }
+
+### version
+
+The `version` matcher tests if the named module version is on the system:
+
+    its(:version) { should eq '3.2.2' }