inspec 2.0.32 → 2.0.45

data/docs/resources/launchd_service.md.erb

@@ -1,57 +1,57 @@
----
-title: About the launchd_service Resource
-platform: linux
----
-
-# launchd_service
-
-Use the ``launchd_service`` InSpec audit resource to test a service using Launchd.
-
-<br>
-
-## Syntax
-
-A ``launchd_service`` resource block declares the name of a service and then one (or more) matchers to test the state of the service:
-
-    describe launchd_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; all matchers available to the `service` resource may be used
-
-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 launchd_service('service_name', '/path/to/control') do
-      it { should be_enabled }
-      it { should be_installed }
-      it { should be_running }
-    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 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 launchd_service Resource
+platform: linux
+---
+
+# launchd_service
+
+Use the ``launchd_service`` InSpec audit resource to test a service using Launchd.
+
+<br>
+
+## Syntax
+
+A ``launchd_service`` resource block declares the name of a service and then one (or more) matchers to test the state of the service:
+
+    describe launchd_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; all matchers available to the `service` resource may be used
+
+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 launchd_service('service_name', '/path/to/control') do
+      it { should be_enabled }
+      it { should be_installed }
+      it { should be_running }
+    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 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/limits_conf.md.erb

@@ -1,75 +1,75 @@
----
-title: About the limits_conf Resource
-platform: linux
----
-
-# limits_conf
-
-Use the `limits_conf` InSpec audit resource to test configuration settings in the `/etc/security/limits.conf` file. The `limits.conf` defines limits for processes (by user and/or group names) and helps ensure that the system running those processes remains stable. Each process may be assigned a hard or soft limit.
-
-* Soft limits are maintained by the shell and defines the number of file handles (or open files) available to the user or group after login
-* Hard limits are maintained by the kernel and defines the maximum number of allowed file handles
-
-Entries in the `limits.conf` file are similar to:
-
-    grantmc     soft   nofile   4096
-    grantmc     hard   nofile   63536
-
-    ^^^^^^^^^   ^^^^   ^^^^^^   ^^^^^
-    domain      type    item    value
-
-<br>
-
-## Syntax
-
-A `limits_conf` resource block declares a domain to be tested, along with associated type, item, and value:
-
-    describe limits_conf('path') do
-      its('domain') { should include ['type', 'item', 'value'] }
-      its('domain') { should eq ['type', 'item', 'value'] }
-    end
-
-where
-
-* `('path')` is the non-default path to the `inetd.conf` file
-* `'domain'` is a user or group name, such as `grantmc`
-* `'type'` is either `hard` or `soft`
-* `'item'` is the item for which limits are defined, such as `core`, `nofile`, `stack`, `nproc`, `priority`, or `maxlogins`
-* `'value'` is the value associated with the `item`
-
-<br>
-
-## Properties
-
-* `domain`
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### domain
-
-The `domain` property tests the domain in the `limits.conf` file, along with associated type, item, and value:
-
-    its('domain') { should include ['type', 'item', 'value'] }
-`
-For example:
-
-    its('grantmc') { should include ['hard', 'nofile', '63536'] }
-
-### Test limits
-
-    describe limits_conf('path') do
-      its('*') { should include ['soft', 'core', '0'], ['hard', 'rss', '10000'] }
-      its('ftp') { should eq ['hard', 'nproc', '0'] }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-
+---
+title: About the limits_conf Resource
+platform: linux
+---
+
+# limits_conf
+
+Use the `limits_conf` InSpec audit resource to test configuration settings in the `/etc/security/limits.conf` file. The `limits.conf` defines limits for processes (by user and/or group names) and helps ensure that the system running those processes remains stable. Each process may be assigned a hard or soft limit.
+
+* Soft limits are maintained by the shell and defines the number of file handles (or open files) available to the user or group after login
+* Hard limits are maintained by the kernel and defines the maximum number of allowed file handles
+
+Entries in the `limits.conf` file are similar to:
+
+    grantmc     soft   nofile   4096
+    grantmc     hard   nofile   63536
+
+    ^^^^^^^^^   ^^^^   ^^^^^^   ^^^^^
+    domain      type    item    value
+
+<br>
+
+## Syntax
+
+A `limits_conf` resource block declares a domain to be tested, along with associated type, item, and value:
+
+    describe limits_conf('path') do
+      its('domain') { should include ['type', 'item', 'value'] }
+      its('domain') { should eq ['type', 'item', 'value'] }
+    end
+
+where
+
+* `('path')` is the non-default path to the `inetd.conf` file
+* `'domain'` is a user or group name, such as `grantmc`
+* `'type'` is either `hard` or `soft`
+* `'item'` is the item for which limits are defined, such as `core`, `nofile`, `stack`, `nproc`, `priority`, or `maxlogins`
+* `'value'` is the value associated with the `item`
+
+<br>
+
+## Properties
+
+* `domain`
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### domain
+
+The `domain` property tests the domain in the `limits.conf` file, along with associated type, item, and value:
+
+    its('domain') { should include ['type', 'item', 'value'] }
+`
+For example:
+
+    its('grantmc') { should include ['hard', 'nofile', '63536'] }
+
+### Test limits
+
+    describe limits_conf('path') do
+      its('*') { should include ['soft', 'core', '0'], ['hard', 'rss', '10000'] }
+      its('ftp') { should eq ['hard', 'nproc', '0'] }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+

data/docs/resources/login_def.md.erb

@@ -1,71 +1,71 @@
----
-title: About the login_defs Resource
-platform: linux
----
-
-# login_defs
-
-Use the `login_defs` InSpec audit resource to test configuration settings in the `/etc/login.defs` file. The `logins.defs` file defines site-specific configuration for the shadow password suite on Linux and Unix platforms, such as password expiration ranges, minimum/maximum values for automatic selection of user and group identifiers, or the method with which passwords are encrypted.
-
-<br>
-
-## Syntax
-
-A `login_defs` resource block declares the `login.defs` configuration data to be tested:
-
-    describe login_defs do
-      its('name') { should include('foo') }
-    end
-
-where
-
-* `name` is a configuration setting in `login.defs`
-* `{ should include('foo') }` tests the value of `name` as read from `login.defs` versus the value declared in the test
-
-<br>
-
-## Properties
-
-This resource supports the properties found in the `login.defs` configuration settings.
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### name
-
-The `name` matcher tests the value of `name` as read from `login.defs` versus the value declared in the test:
-
-    its('name') { should eq 'foo' }
-
-### Test password expiration settings
-
-    describe login_defs do
-      its('PASS_MAX_DAYS') { should eq '180' }
-      its('PASS_MIN_DAYS') { should eq '1' }
-      its('PASS_MIN_LEN') { should eq '15' }
-      its('PASS_WARN_AGE') { should eq '30' }
-    end
-
-### Test the encryption method
-
-    describe login_defs do
-      its('ENCRYPT_METHOD') { should eq 'SHA512' }
-    end
-
-### Test umask setting
-
-    describe login_def do
-      its('UMASK') { should eq '077' }
-      its('PASS_MAX_DAYS') { should eq '90' }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-
+---
+title: About the login_defs Resource
+platform: linux
+---
+
+# login_defs
+
+Use the `login_defs` InSpec audit resource to test configuration settings in the `/etc/login.defs` file. The `logins.defs` file defines site-specific configuration for the shadow password suite on Linux and Unix platforms, such as password expiration ranges, minimum/maximum values for automatic selection of user and group identifiers, or the method with which passwords are encrypted.
+
+<br>
+
+## Syntax
+
+A `login_defs` resource block declares the `login.defs` configuration data to be tested:
+
+    describe login_defs do
+      its('name') { should include('foo') }
+    end
+
+where
+
+* `name` is a configuration setting in `login.defs`
+* `{ should include('foo') }` tests the value of `name` as read from `login.defs` versus the value declared in the test
+
+<br>
+
+## Properties
+
+This resource supports the properties found in the `login.defs` configuration settings.
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### name
+
+The `name` matcher tests the value of `name` as read from `login.defs` versus the value declared in the test:
+
+    its('name') { should eq 'foo' }
+
+### Test password expiration settings
+
+    describe login_defs do
+      its('PASS_MAX_DAYS') { should eq '180' }
+      its('PASS_MIN_DAYS') { should eq '1' }
+      its('PASS_MIN_LEN') { should eq '15' }
+      its('PASS_WARN_AGE') { should eq '30' }
+    end
+
+### Test the encryption method
+
+    describe login_defs do
+      its('ENCRYPT_METHOD') { should eq 'SHA512' }
+    end
+
+### Test umask setting
+
+    describe login_def do
+      its('UMASK') { should eq '077' }
+      its('PASS_MAX_DAYS') { should eq '90' }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+

data/docs/resources/mount.md.erb

@@ -1,69 +1,69 @@
----
-title: About the mount Resource
-platform: linux
----
-
-# mount
-
-Use the `mount` InSpec audit resource to test the mount points on FreeBSD and Linux systems.
-
-<br>
-
-## Syntax
-
-An `mount` resource block declares the synchronization settings that should be tested:
-
-    describe mount('path') do
-      it { should MATCHER 'value' }
-    end
-
-where
-
-* `('path')` is the path to the mounted directory
-* `MATCHER` is a valid matcher for this resource
-* `'value'` is the value to be tested
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test a the mount point on '/'
-
-    describe mount('/') do
-      it { should be_mounted }
-      its('device') { should eq  '/dev/mapper/VolGroup-lv_root' }
-      its('type') { should eq  'ext4' }
-      its('options') { should eq ['rw', 'mode=620'] }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
-### be_mounted
-
-The `be_mounted` matcher tests if the file is accessible from the file system:
-
-    it { should be_mounted }
-
-### device
-
-The `device` matcher tests the device from the `fstab` table:
-
-    its('device') { should eq  '/dev/mapper/VolGroup-lv_root' }
-
-### options
-
-The `options` matcher tests the mount options for the file system from the `fstab` table:
-
-    its('options') { should eq ['rw', 'mode=620'] }
-
-### type
-
-The `type` matcher tests the file system type:
-
-    its('type') { should eq  'ext4' }
+---
+title: About the mount Resource
+platform: linux
+---
+
+# mount
+
+Use the `mount` InSpec audit resource to test the mount points on FreeBSD and Linux systems.
+
+<br>
+
+## Syntax
+
+An `mount` resource block declares the synchronization settings that should be tested:
+
+    describe mount('path') do
+      it { should MATCHER 'value' }
+    end
+
+where
+
+* `('path')` is the path to the mounted directory
+* `MATCHER` is a valid matcher for this resource
+* `'value'` is the value to be tested
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test a the mount point on '/'
+
+    describe mount('/') do
+      it { should be_mounted }
+      its('device') { should eq  '/dev/mapper/VolGroup-lv_root' }
+      its('type') { should eq  'ext4' }
+      its('options') { should eq ['rw', 'mode=620'] }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+
+### be_mounted
+
+The `be_mounted` matcher tests if the file is accessible from the file system:
+
+    it { should be_mounted }
+
+### device
+
+The `device` matcher tests the device from the `fstab` table:
+
+    its('device') { should eq  '/dev/mapper/VolGroup-lv_root' }
+
+### options
+
+The `options` matcher tests the mount options for the file system from the `fstab` table:
+
+    its('options') { should eq ['rw', 'mode=620'] }
+
+### type
+
+The `type` matcher tests the file system type:
+
+    its('type') { should eq  'ext4' }