mirror of
https://github.com/inspec/inspec
synced 2024-11-22 04:33:09 +00:00
Fix typo in some docs (#2841)
Also includes fixes such as PostgreSQL, TCPMUX, and etc. Signed-off-by: ERAMOTO Masaya <eramoto.masaya@jp.fujitsu.com>
This commit is contained in:
parent
58d2b01d3f
commit
a687479e6c
28 changed files with 38 additions and 38 deletions
|
@ -193,7 +193,7 @@ end
|
|||
```
|
||||
|
||||
* Test your `kitchen.yml` file to verify that only Vagrant is configured as the driver. The %w() formatting will
|
||||
pass rubocop lintng and allow you to access nested mappings.
|
||||
pass rubocop linting and allow you to access nested mappings.
|
||||
|
||||
```ruby
|
||||
describe yaml('.kitchen.yml') do
|
||||
|
|
|
@ -100,7 +100,7 @@ control 'windows-account-102' do
|
|||
end
|
||||
```
|
||||
|
||||
## Are PosgtreSQL passwords empty?
|
||||
## Are PostgreSQL passwords empty?
|
||||
|
||||
The following test shows how to audit machines running PostgreSQL to ensure that passwords are not empty.
|
||||
|
||||
|
|
|
@ -256,7 +256,7 @@ end
|
|||
|
||||
## Are you supporting the `expect` syntax?
|
||||
|
||||
Of course. We still prefer the `should` syntax for UX reasons. We did surveys with various types of customers like devops engineers, auditors, managers. All participants who prefered the `expect` syntax have been Ruby experts. All non-Ruby developers found it easier to understand the `should` syntax.
|
||||
Of course. We still prefer the `should` syntax for UX reasons. We did surveys with various types of customers like devops engineers, auditors, managers. All participants who preferred the `expect` syntax have been Ruby experts. All non-Ruby developers found it easier to understand the `should` syntax.
|
||||
|
||||
### `should` syntax with InSpec
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ InSpec allows you to output your test results to one or more reporters. You can
|
|||
|
||||
## Syntax
|
||||
|
||||
You can specify one or more reporters using the `--reporter` cli flag. You can also specify a output by appending a path seperated by a colon.
|
||||
You can specify one or more reporters using the `--reporter` cli flag. You can also specify a output by appending a path separated by a colon.
|
||||
|
||||
Output json to screen.
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ platform: linux
|
|||
|
||||
# auditd
|
||||
|
||||
Use the `auditd` InSpec audit resource to test the rules for logging that exist on the system. The audit.rules file is typically located under /etc/audit/ and contains the list of rules that define what is captured in log files. These rules are output using the auditcl -l command. This resource supports versions of `audit` >= 2.3.
|
||||
Use the `auditd` InSpec audit resource to test the rules for logging that exist on the system. The audit.rules file is typically located under /etc/audit/ and contains the list of rules that define what is captured in log files. These rules are output using the auditctl -l command. This resource supports versions of `audit` >= 2.3.
|
||||
|
||||
<br>
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Use the `aws_sns_topic` InSpec audit resource to test properties of a single AWS
|
|||
|
||||
### ARN
|
||||
|
||||
This resource expects a single parameter that uniquely identifes the SNS Topic, an ARN. Amazon Resource Names for SNS topics have the format `arn:aws:sns:region:account-id:topicname`. AWS requires a fully-specified ARN for looking up an SNS topic. The account ID and region are required. Wildcards are not permitted.
|
||||
This resource expects a single parameter that uniquely identifies the SNS Topic, an ARN. Amazon Resource Names for SNS topics have the format `arn:aws:sns:region:account-id:topicname`. AWS requires a fully-specified ARN for looking up an SNS topic. The account ID and region are required. Wildcards are not permitted.
|
||||
|
||||
See also the [AWS documentation on ARNs](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ A string identifying the subnet that the VPC contains.
|
|||
|
||||
## Properties
|
||||
|
||||
* `availavailability_zone`, `available_ip_address_count`, `cidr_block`, `subnet_id`, `vpc_id`
|
||||
* `availability_zone`, `available_ip_address_count`, `cidr_block`, `subnet_id`, `vpc_id`
|
||||
|
||||
<br>
|
||||
|
||||
|
@ -131,4 +131,4 @@ Provides the VPC ID for the subnet.
|
|||
|
||||
describe aws_subnet(subnet_id: 'subnet-12345678') do
|
||||
it { should be_mapping_public_ip_on_launch }
|
||||
end
|
||||
end
|
||||
|
|
|
@ -43,7 +43,7 @@ As this is the initial release of `aws_subnets`, its limited functionality precl
|
|||
|
||||
A string identifying the VPC which may or may not contain subnets.
|
||||
|
||||
# Look for all subnts within a vpc.
|
||||
# Look for all subnets within a vpc.
|
||||
describe aws_subnets.where( vpc_id: 'vpc-12345678') do
|
||||
its('subnet_ids') { should include 'subnet-12345678' }
|
||||
its('subnet_ids') { should include 'subnet-98765432' }
|
||||
|
|
|
@ -16,7 +16,7 @@ where
|
|||
|
||||
* `MyResourceGroup` is the name of the resource group that contains the Azure Resource to be validated
|
||||
* `MyResource` is the name of the resource that needs to be checked
|
||||
* `property` This generic resource dynamically creates the properties on the fly based on the type of resource that has been targetted.
|
||||
* `property` This generic resource dynamically creates the properties on the fly based on the type of resource that has been targeted.
|
||||
* `value` is the expected output from the chosen property
|
||||
|
||||
<br>
|
||||
|
@ -168,4 +168,4 @@ This InSpec audit resource has the following special matchers. For a full list o
|
|||
|
||||
Please see the integration tests for in depth examples of how this resource can be used.
|
||||
|
||||
[Inspec Integration Tests for Azure Generic Resources](https://github.com/chef/inspec/tree/master/test/azure/verify/controls)
|
||||
[Inspec Integration Tests for Azure Generic Resources](https://github.com/chef/inspec/tree/master/test/azure/verify/controls)
|
||||
|
|
|
@ -119,7 +119,7 @@ This takes the format: `/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURC
|
|||
|
||||
### provisioning_state
|
||||
|
||||
Tests thehe provisioning state of the resource group.
|
||||
Tests the provisioning state of the resource group.
|
||||
|
||||
its('provisioning_state') { should cmp 'Succeeded' }
|
||||
|
||||
|
@ -188,7 +188,7 @@ For a full list of available matchers, please visit our [matchers page](https://
|
|||
|
||||
Use this matcher to test if network interfaces exist.
|
||||
|
||||
it { should have_ncis }
|
||||
it { should have_nics }
|
||||
|
||||
### have_vms
|
||||
|
||||
|
|
|
@ -200,7 +200,7 @@ This returns an array of the NIC ids that are connected to the machine. This mea
|
|||
|
||||
its('connected_nics') { should include /Inspec-NIC-1/ }
|
||||
|
||||
Note the use of the regular expression here. This is because the NIC id is a long string that contains the subscription id, resource group, machine id as well as other things. By using the regular expression the NIC can be checked withouth breaking this string up. It also means that other tests can be performed.
|
||||
Note the use of the regular expression here. This is because the NIC id is a long string that contains the subscription id, resource group, machine id as well as other things. By using the regular expression the NIC can be checked without breaking this string up. It also means that other tests can be performed.
|
||||
|
||||
An example of the id string is `/subscriptions/1e0b427a-d58b-494e-ae4f-ee558463ebbf/resourceGroups/Inspec-Azure/providers/Microsoft.Network/networkInterfaces/Inspec-NIC-1`
|
||||
|
||||
|
@ -250,7 +250,7 @@ If boot diagnostics are enabled for the machine they will be saved in a storage
|
|||
|
||||
## Matchers
|
||||
|
||||
There are a number of built in comparison operrtors that are available to test the result with an expected value.
|
||||
There are a number of built in comparison operators that are available to test the result with an expected value.
|
||||
|
||||
For information on all that are available please refer to the [Inspec Matchers Reference](https://www.inspec.io/docs/reference/matchers/) page.
|
||||
|
||||
|
@ -328,7 +328,7 @@ It is possible to check if a specific tag has been set on the resource.
|
|||
|
||||
### xxx\_tag
|
||||
|
||||
To get the value of the tag, a number of tests have been craeted from the tags that are set.
|
||||
To get the value of the tag, a number of tests have been created from the tags that are set.
|
||||
|
||||
For example, if the following tag is set on a resource:
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ The name of the resource group and machine are required to use this resource.
|
|||
where
|
||||
|
||||
* `MyVm` is the name of the virtual machine as seen in Azure. (It is **not** the hostname of the machine)
|
||||
* `InSpec-Azure` is the name of the resouce group that the machine is in.
|
||||
* `InSpec-Azure` is the name of the resource group that the machine is in.
|
||||
* `property` is a resource property
|
||||
* `value` is the expected output from the matcher
|
||||
|
||||
|
@ -201,7 +201,7 @@ This is derived from the `id`.
|
|||
|
||||
This InSpec audit resource has the following special matchers. For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
|
||||
|
||||
The following properties are applied to the virtual machine itself and not specfic disks.
|
||||
The following properties are applied to the virtual machine itself and not specific disks.
|
||||
|
||||
### have\_data\_disks
|
||||
|
||||
|
|
|
@ -112,7 +112,7 @@ The following example shows how to use the `file` audit resource to verify if th
|
|||
|
||||
### 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:
|
||||
Wix includes several 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
|
||||
|
|
|
@ -42,15 +42,15 @@ The following examples show how to use this InSpec audit resource.
|
|||
its('entries.length') { should cmp '0' }
|
||||
end
|
||||
|
||||
### Test that the logged-in user's crontab contains a single command that matches a mattern
|
||||
### Test that the logged-in user's crontab contains a single command that matches a pattern
|
||||
|
||||
describe crontab.where { command =~ /a partial command string/ } do
|
||||
its('entries.length') { should cmp 1 }
|
||||
end
|
||||
|
||||
### Test a special time string (i.e., @yearly /root/anual_report.sh)
|
||||
### Test a special time string (i.e., @yearly /root/annual_report.sh)
|
||||
|
||||
describe crontab.commands('/root/anual_report.sh') do
|
||||
describe crontab.commands('/root/annual_report.sh') do
|
||||
its('hours') { should cmp '0' }
|
||||
its('minutes') { should cmp '0' }
|
||||
its('days') { should cmp '1' }
|
||||
|
|
|
@ -125,7 +125,7 @@ Returns a list of enabled modules for each node in the cluster. For more additio
|
|||
|
||||
### modules
|
||||
|
||||
Returns detailed information about each enabled module for each node in the cluster. For a succint list of the names of each of the modules enabled, use the `module_list` property. This example uses additional Ruby to find a specific module and assert a value.
|
||||
Returns detailed information about each enabled module for each node in the cluster. For a succinct list of the names of each of the modules enabled, use the `module_list` property. This example uses additional Ruby to find a specific module and assert a value.
|
||||
|
||||
modules = elasticsearch.modules.first
|
||||
lang_groovy_module = modules.find { |mod| mod.name == 'lang-groovy' }
|
||||
|
@ -169,7 +169,7 @@ Returns a list of enabled plugins for each node in the cluster. For more additio
|
|||
|
||||
### plugins
|
||||
|
||||
Returns detailed information about each enabled plugin for each node in the cluster. For a succint list of the names of each of the plugins enabled, use the `plugin_list` property. This example uses additional Ruby to find a specific plugin and assert a value.
|
||||
Returns detailed information about each enabled plugin for each node in the cluster. For a succinct list of the names of each of the plugins enabled, use the `plugin_list` property. This example uses additional Ruby to find a specific plugin and assert a value.
|
||||
|
||||
plugins = elasticsearch.plugins.first
|
||||
my_plugin = plugins.find { |plugin| plugin.name == 'my_plugin' }
|
||||
|
|
|
@ -59,7 +59,7 @@ Use the optional constructor parameter to give an alternative path to fstab file
|
|||
|
||||
### mount_point
|
||||
|
||||
`mount_point` returns a string array of directorys at which filesystems are configured to be mounted.
|
||||
`mount_point` returns a string array of directories at which filesystems are configured to be mounted.
|
||||
|
||||
describe etc_fstab.where { device_name == '/dev/sr0' } do
|
||||
its('mount_point') { should cmp '/mnt/sr0' }
|
||||
|
|
|
@ -35,7 +35,7 @@ where
|
|||
|
||||
* `ip_address` is the ip address of the hostname in either ipv4 or ipv6 format.
|
||||
* `primary_name` is the name associated with the ip address.
|
||||
* `all_host_names` is a list including the primary_name as the first entry followed by any aliase names the host has.
|
||||
* `all_host_names` is a list including the primary_name as the first entry followed by any alias names the host has.
|
||||
|
||||
<br>
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ Use the `filesystem` InSpec resource to audit filesystem disk space usage.
|
|||
|
||||
## Syntax
|
||||
|
||||
A `filesystem` resource block declares tests for disk space in a partion:
|
||||
A `filesystem` resource block declares tests for disk space in a partition:
|
||||
|
||||
describe filesystem('/') do
|
||||
its('size') { should be >= 32000 }
|
||||
|
|
|
@ -73,7 +73,7 @@ The following test verifies the kernel, ensures that kernel is the default kerne
|
|||
its('timeout') { should eq '10' }
|
||||
end
|
||||
|
||||
The following test verifies the `ramdisk_size` for the non-deault kernel:
|
||||
The following test verifies the `ramdisk_size` for the non-default kernel:
|
||||
|
||||
describe grub_conf('/etc/grub.conf', 'Red Hat Enterprise Linux ES (2.6.32-358.14.1.el6.x86_64)') do
|
||||
its('kernel') { should include 'ramdisk_size=400000' }
|
||||
|
|
|
@ -113,7 +113,7 @@ The `version` matcher tests if the named package version is on the system:
|
|||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
||||
You can also use the `cmp OPERATOR` matcher to perform comparisions using the version attribute:
|
||||
You can also use the `cmp OPERATOR` matcher to perform comparisons using the version attribute:
|
||||
|
||||
its('version') { should cmp >= '7.35.0-1ubuntu3.10' }
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ The following examples show how to use this InSpec audit resource.
|
|||
its('list.length') { should eq 1 }
|
||||
end
|
||||
|
||||
### Test if the process is owned by a specifc user
|
||||
### Test if the process is owned by a specific user
|
||||
|
||||
describe processes('init') do
|
||||
its('users') { should eq ['root'] }
|
||||
|
|
|
@ -42,7 +42,7 @@ A Windows registry key can be used as a string in Ruby code, such as when a regi
|
|||
|
||||
HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Themes
|
||||
|
||||
may be encloused in a single-quoted string with a single backslash:
|
||||
may be enclosed in a single-quoted string with a single backslash:
|
||||
|
||||
'HKCU\SOFTWARE\path\to\key\Themes'
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ platform: windows
|
|||
# windows_task
|
||||
|
||||
Use the `windows_task` InSpec audit resource to test a scheduled tasks configuration on a Windows platform.
|
||||
Microsoft and application vendors use scheduled tasks to perform a variety of system maintaince tasks but system administrators can schedule their own.
|
||||
Microsoft and application vendors use scheduled tasks to perform a variety of system maintenance tasks but system administrators can schedule their own.
|
||||
|
||||
<br>
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ The network socket type: `dgram` (a datagram-based service), `raw` (a service th
|
|||
|
||||
### Test a service type
|
||||
|
||||
The type of service: `INTERNAL` (a service provided by xinetd), `RPC` (an RPC-based service), `TCPMUX` (a service that is started on a well-known TPCMUX port), or `UNLISTED` (a service that is not listed in a standard system file location).
|
||||
The type of service: `INTERNAL` (a service provided by xinetd), `RPC` (an RPC-based service), `TCPMUX` (a service that is started on a well-known TCPMUX port), or `UNLISTED` (a service that is not listed in a standard system file location).
|
||||
|
||||
describe xinetd_conf.services('service_name') do
|
||||
its('type') { should include 'RPC' }
|
||||
|
@ -93,7 +93,7 @@ All three settings can be tested in the same block as well:
|
|||
|
||||
For a full list of available matchers, please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
|
||||
|
||||
### be_enabed
|
||||
### be_enabled
|
||||
|
||||
The `be_enabled` matcher tests if a service listed under `/etc/xinet.d` is enabled:
|
||||
|
||||
|
|
|
@ -91,7 +91,7 @@ The `repos` matcher tests if a named repo, using either a full identifier (`'upd
|
|||
|
||||
### 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":
|
||||
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' }
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Example InSpec Profile with Sensitive failures
|
||||
|
||||
This profile demostrates resources flagged as sensitive
|
||||
This profile demonstrates resources flagged as sensitive
|
||||
|
||||
## Usage
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ To use the CLI, this InSpec add-on adds the following commands:
|
|||
* `$ inspec compliance upload path/to/local/profile` - uploads a local profile to Chef Automate/Chef Compliance
|
||||
* `$ inspec compliance logout` - logout of Chef Automate/Chef Compliance
|
||||
|
||||
Compliance profiles can be executed in two mays:
|
||||
Compliance profiles can be executed in two ways:
|
||||
|
||||
- via compliance exec: `inspec compliance exec profile`
|
||||
- via compliance scheme: `inspec exec compliance://profile`
|
||||
|
|
|
@ -6,7 +6,7 @@ To use the CLI, this InSpec add-on adds the following commands:
|
|||
* `$ inspec supermarket search` - searches for a compliance profile on supermarket
|
||||
* `$ inspec supermarket exec nathenharvey/tmp-compliance-profile` - extends execute to load the profile
|
||||
|
||||
Compliance profiles from Supermarket can be executed in two mays:
|
||||
Compliance profiles from Supermarket can be executed in two ways:
|
||||
|
||||
- via supermarket exec: `inspec supermarket exec nathenharvey/tmp-compliance-profile`
|
||||
- via supermarket scheme: `inspec exec supermarket://nathenharvey/tmp-compliance-profile`
|
||||
|
|
Loading…
Reference in a new issue