inspec 2.1.0 → 2.1.10

data/docs/resources/xml.md.erb

@@ -1,85 +1,85 @@
----
-title: About the xml Resource
-platform: os
----
-
-# xml
-
-Use the `xml` InSpec audit resource to test data in an XML file.
-
-<br>
-
-## Syntax
-
-An `xml` resource block declares the data to be tested. Assume the following XML file:
-
-    <root>
-      <name>hello</name>
-      <meta>
-        <creator>John Doe</creator>
-      </meta>
-      <array>
-        <element>one</element>
-        <element>two</element>
-      </array>
-      <array>
-        <element value="one"></element>
-        <element value="two"></element>
-      </array>
-    </root>
-
-This file can be queried for elements using:
-
-    describe xml('/path/to/name.xml') do
-      its('root/name') { should eq ['hello'] }
-      its('root/meta/creator') { should eq ['John Doe'] }
-      its('root/array[2]/element') { should eq ['two'] }
-    end
-
-This file can be queried for attributes using:
-
-    describe xml('/path/to/name.xml') do
-      its('root/array[2]/element/@value') { should eq ['one', 'two'] }
-      its('root/array[2]/element/attribute::value') { should eq ['one', 'two'] }
-      its('root/array[2]/element[2]/attribute::value') { should eq ['two'] }
-    end
-
-where
-
-* `root/name` and `root/array[2]/element/@value` is an XPath expression
-* `should eq ['foo']` tests a value of `root/name` as read from an XML file versus the value declared in the test
-
-In the above example, you see the use of `@` and `attribute::` which are both methods of fetching attributes.
-
-In the event the path contains an element which contains periods, the alternate syntax can be used:
-
-    its(['root/name.with.a.period']) { should cmp 'so_many_dots' }
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test an AppPool's presence in an applicationHost.config file or the default site under applicationHost.sites
-
-    describe xml('applicationHost.config') do
-      # using the alternate syntax as described above because of the . in the key name
-      its(['configuration/system.applicationHost/applicationPools/add@name']) { should contain('my_pool') }
-    end
-
-    describe xml('applicationHost.sites') do
-      its('site[@name="Default Web Site"]/application/virtualDirectory/@path') { should eq ['/'] }
-    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 xml Resource
+platform: os
+---
+
+# xml
+
+Use the `xml` InSpec audit resource to test data in an XML file.
+
+<br>
+
+## Syntax
+
+An `xml` resource block declares the data to be tested. Assume the following XML file:
+
+    <root>
+      <name>hello</name>
+      <meta>
+        <creator>John Doe</creator>
+      </meta>
+      <array>
+        <element>one</element>
+        <element>two</element>
+      </array>
+      <array>
+        <element value="one"></element>
+        <element value="two"></element>
+      </array>
+    </root>
+
+This file can be queried for elements using:
+
+    describe xml('/path/to/name.xml') do
+      its('root/name') { should eq ['hello'] }
+      its('root/meta/creator') { should eq ['John Doe'] }
+      its('root/array[2]/element') { should eq ['two'] }
+    end
+
+This file can be queried for attributes using:
+
+    describe xml('/path/to/name.xml') do
+      its('root/array[2]/element/@value') { should eq ['one', 'two'] }
+      its('root/array[2]/element/attribute::value') { should eq ['one', 'two'] }
+      its('root/array[2]/element[2]/attribute::value') { should eq ['two'] }
+    end
+
+where
+
+* `root/name` and `root/array[2]/element/@value` is an XPath expression
+* `should eq ['foo']` tests a value of `root/name` as read from an XML file versus the value declared in the test
+
+In the above example, you see the use of `@` and `attribute::` which are both methods of fetching attributes.
+
+In the event the path contains an element which contains periods, the alternate syntax can be used:
+
+    its(['root/name.with.a.period']) { should cmp 'so_many_dots' }
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test an AppPool's presence in an applicationHost.config file or the default site under applicationHost.sites
+
+    describe xml('applicationHost.config') do
+      # using the alternate syntax as described above because of the . in the key name
+      its(['configuration/system.applicationHost/applicationPools/add@name']) { should contain('my_pool') }
+    end
+
+    describe xml('applicationHost.sites') do
+      its('site[@name="Default Web Site"]/application/virtualDirectory/@path') { should eq ['/'] }
+    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/yaml.md.erb

@@ -1,69 +1,69 @@
----
-title: About the yaml Resource
-platform: os
----
-
-# yaml
-
-Use the `yaml` InSpec audit resource to test configuration data in a Yaml file.
-
-<br>
-
-## Syntax
-
-A `yaml` resource block declares the configuration data to be tested. Assume the following Yaml file:
-
-    name: foo
-    array:
-      - zero
-      - one
-
-This file can be queried using:
-
-    describe yaml('filename.yml') do
-      its('name') { should eq 'foo' }
-      its(['array', 1]) { should eq 'one' }
-    end
-
-where
-
-* `name` is a configuration setting in a Yaml file
-* `should eq 'foo'` tests a value of `name` as read from a Yaml file versus the value declared in the test
-
-Like the `json` resource, the `yaml` resource can read a file, run a command, or accept content inline:
-
-    describe yaml('config.yaml') do
-      its(['driver', 'name']) { should eq 'vagrant' }
-    end
-
-    describe yaml({ command: 'retrieve_data.py --yaml' }) do
-      its('state') { should eq 'open' }
-    end
-
-    describe yaml({ content: \"key1: value1\nkey2: value2\" }) do
-      its('key2') { should cmp 'value2' }
-    end
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test a kitchen.yml file driver
-
-    describe yaml('.kitchen.yaml') do
-      its('driver.name') { should eq('vagrant') }
-    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 Yaml file versus the value declared in the test:
-
-    its('name') { should eq 'foo' }
+---
+title: About the yaml Resource
+platform: os
+---
+
+# yaml
+
+Use the `yaml` InSpec audit resource to test configuration data in a Yaml file.
+
+<br>
+
+## Syntax
+
+A `yaml` resource block declares the configuration data to be tested. Assume the following Yaml file:
+
+    name: foo
+    array:
+      - zero
+      - one
+
+This file can be queried using:
+
+    describe yaml('filename.yml') do
+      its('name') { should eq 'foo' }
+      its(['array', 1]) { should eq 'one' }
+    end
+
+where
+
+* `name` is a configuration setting in a Yaml file
+* `should eq 'foo'` tests a value of `name` as read from a Yaml file versus the value declared in the test
+
+Like the `json` resource, the `yaml` resource can read a file, run a command, or accept content inline:
+
+    describe yaml('config.yaml') do
+      its(['driver', 'name']) { should eq 'vagrant' }
+    end
+
+    describe yaml({ command: 'retrieve_data.py --yaml' }) do
+      its('state') { should eq 'open' }
+    end
+
+    describe yaml({ content: \"key1: value1\nkey2: value2\" }) do
+      its('key2') { should cmp 'value2' }
+    end
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test a kitchen.yml file driver
+
+    describe yaml('.kitchen.yaml') do
+      its('driver.name') { should eq('vagrant') }
+    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 Yaml file versus the value declared in the test:
+
+    its('name') { should eq 'foo' }

data/docs/resources/yum.md.erb

@@ -1,98 +1,98 @@
----
-title: About the yum Resource
-platform: linux
----
-
-# yum
-
-Use the `yum` InSpec audit resource to test packages in the Yum repository.
-
-<br>
-
-## Syntax
-
-A `yum` resource block declares a package repo, tests if the package repository is present, and if it that package repository is a valid package source (i.e. "is enabled"):
-
-    describe yum.repo('name') do
-      it { should exist }
-      it { should be_enabled }
-    end
-
-where
-
-* `repo('name')` is the (optional) name of a package repo, using either a full identifier (`'updates/7/x86_64'`) or a short identifier (`'updates'`)
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test if the yum repo exists
-
-    describe yum do
-      its('repos') { should exist }
-    end
-
-### Test if the 'base/7/x86_64' repo exists and is enabled
-
-    describe yum do
-      its('repos') { should include 'base/7/x86_64' }
-      its('epel') { should exist }
-      its('epel') { should be_enabled }
-    end
-
-### Test if a specific yum repo exists
-
-    describe yum.repo('epel') do
-      it { should exist }
-      it { should be_enabled }
-    end
-
-### Test a particular repository configuration, such as its Base URL
-
-    describe yum.repo('mycompany-artifacts') do
-      it { should exist }
-      it { should be_enabled }
-      its('baseurl') { should include 'mycompany.biz' }
-    end
-
-<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 package repository is a valid package source:
-
-    it { should be_enabled }
-
-### exist
-
-The `exist` matcher tests if the package repository exists:
-
-    it { should exist }
-
-### repo('name')
-
-The `repo('name')` matcher names a specific package repository:
-
-    describe yum.repo('epel') do
-      ...
-    end
-
-### repos
-
-The `repos` matcher tests if a named repo, using either a full identifier (`'updates/7/x86_64'`) or a short identifier (`'updates'`), is included in the Yum repo:
-
-    its('repos') { should include 'some_repo' }
-
-### shortname
-
-The `shortname` matcher names a specific package repository's group identifier. For example, if a repository's group name is "Directory Server", the corresponding group idenfier is typically "directory-server":
-
-    describe yum.repo('Directory Server') do
-      its('shortname') { should eq 'directory-server' }
-    end
+---
+title: About the yum Resource
+platform: linux
+---
+
+# yum
+
+Use the `yum` InSpec audit resource to test packages in the Yum repository.
+
+<br>
+
+## Syntax
+
+A `yum` resource block declares a package repo, tests if the package repository is present, and if it that package repository is a valid package source (i.e. "is enabled"):
+
+    describe yum.repo('name') do
+      it { should exist }
+      it { should be_enabled }
+    end
+
+where
+
+* `repo('name')` is the (optional) name of a package repo, using either a full identifier (`'updates/7/x86_64'`) or a short identifier (`'updates'`)
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test if the yum repo exists
+
+    describe yum do
+      its('repos') { should exist }
+    end
+
+### Test if the 'base/7/x86_64' repo exists and is enabled
+
+    describe yum do
+      its('repos') { should include 'base/7/x86_64' }
+      its('epel') { should exist }
+      its('epel') { should be_enabled }
+    end
+
+### Test if a specific yum repo exists
+
+    describe yum.repo('epel') do
+      it { should exist }
+      it { should be_enabled }
+    end
+
+### Test a particular repository configuration, such as its Base URL
+
+    describe yum.repo('mycompany-artifacts') do
+      it { should exist }
+      it { should be_enabled }
+      its('baseurl') { should include 'mycompany.biz' }
+    end
+
+<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 package repository is a valid package source:
+
+    it { should be_enabled }
+
+### exist
+
+The `exist` matcher tests if the package repository exists:
+
+    it { should exist }
+
+### repo('name')
+
+The `repo('name')` matcher names a specific package repository:
+
+    describe yum.repo('epel') do
+      ...
+    end
+
+### repos
+
+The `repos` matcher tests if a named repo, using either a full identifier (`'updates/7/x86_64'`) or a short identifier (`'updates'`), is included in the Yum repo:
+
+    its('repos') { should include 'some_repo' }
+
+### shortname
+
+The `shortname` matcher names a specific package repository's group identifier. For example, if a repository's group name is "Directory Server", the corresponding group identifier is typically "directory-server":
+
+    describe yum.repo('Directory Server') do
+      its('shortname') { should eq 'directory-server' }
+    end