When attempting to access array values via the `json` resource:
```
describe json('/tmp/test.json') do
its(['array',0]) { should eq "zero" }
end
```
... the resulting data would be an array of the size of the original array
with all the values replaced with nils:
```
expected: "zero"
got: [nil, nil, nil]
```
This was due to a bug in the ObjectTraverser mixin that mapped array values
back through `extract_value` rather than properly handling the passed-in
key(s). This worked fine for the specific data format created by the `csv`
resource but did not work `json` or any other resource that subclassed the
`JsonConfig` resource.
This change fixes the logic when dealing with an array when it's encountered,
and fixes up the `csv` resource with its own `value` method.
This change also adds tests for ObjectTraverser.
Signed-off-by: Adam Leff <adam@leff.co>
As raised in #1526, adding an additional example showing how
a user can use the `where` accessor to find commands matching
a pattern and write a test using the results.
Signed-off-by: Adam Leff <adam@leff.co>
Currently, if the inspec.yml for a profile is invalid (such as including
an improperly-defined multi-line string), InSpec will throw an exception
from the YAML parser that does not given a clear indication that the
issue was encountered while parsing the inspec.yml file.
This change introduces a better exception message to clue the user into
where the problem actually lies.
Signed-off-by: Adam Leff <adam@leff.co>
On Linux, netstat may show a tcp6/udp6 protocol line but include a
v4 address. This happens with AF_INET6 sockets that can accept
both v4 and v6 traffic. The port check was not properly handling
this situation and trying to pass a v4 address to URI bracketed as
if it was a v6 address.
Signed-off-by: Adam Leff <adam@leff.co>
* Add open_timeout to NET::HTTP.start call
Signed-off-by: Makoto Nozaki <makoto.nozaki@twosigma.com>
* Code cleanup based on the discussion at #1538
Signed-off-by: Makoto Nozaki <makoto.nozaki@twosigma.com>
When running a InSpec profile built with Habitat, we now
write the formatter/reporter data to a JSON file in the
pkg.svc_var_path rather than STDOUT. This will allow for
programmatic collection of this data and future enhancements
to allow this data to be passed around a Habitat ring.
This also corrects an issue creating a Habitat profile if the
profile had never been in the local InSpec cache. By setting a
mock Backend when creating the profile object, similarly to what
the archivers do, this issue is avoided.
Signed-off-by: Adam Leff <adam@leff.co>
Fixes issue #1508
* Windows terminals don't support extended ANSI colours. Use basic + intensity
* Windows terminals don't support UTF-8 well so don't use special characters
Other OS'es get what they had before.
Signed-off-by: Richard Nixon <richard.nixon@btinternet.com>
Two new commands have been created:
* inspec habitat profile create /path/to/profile
* inspec habitat profile upload /path/to/profile
The `create` command creates a Habitat artifact that contains the contents
of the Habitat profile found at the provided path. This will be used later
in some Habitat + InSpec integrations.
The `upload` command does the same create process but then uploads the
resulting artifact to the Habitat Depot.
Signed-off-by: Adam Leff <adam@leff.co>
The following new resources have been added; however, they
presently only support FreeBSD and similar.
* `zfs_dataset`: tests if a named ZFS dataset is present
and/or has certain properties.
* `zfs_pool`: tests if a named ZFS pool is present and/or
has certain properties.
Additionally, the `mount` resource has been reworked to
include support for FreeBSD; while the existing class
was renamed to LinuxMountParser.
Unit-tests were added for all of the above.
Signed-off-by: Joseph Benden <joe@benden.us>
When in inspec shell, you need to type the `help` command to find out info
about your target system. This info would be super helpful right out of the
gate so users have confidence that they're targeting the correct system.
The target info is still available via the `help` command as it always has
been, as well.
Signed-off-by: Adam Leff <adam@leff.co>
The inline docs for SourceReaders::InspecReader#new state that it takes
a SourceReader object for the target... but we're trying to create the
SourceReader object! It actually takes a FileProvider object that is
capabile of listing files for the given profile and reading them.
Signed-off-by: Adam Leff <adam@leff.co>
When running InSpec with multiple profiles, and two or more of the profiles
are read in using the "Flat" SourceReader (i.e. they are not actual profiles
with a metadata file like inspec.yml, but rather just a folder containing
.rb files with controls and tests in them), InSpec would throw a NilClass
error when building the necessary objects for the formatter.
The cause was in `#profile_contains_example` in the formatter code which
checks to see if the profile name is the same as the profile_id in the given
example. However, if both of those were nil, it would potentially match the
wrong Flat-read profile.
This change fixes this in two ways: refusing to match if the profile name
or example profile ID is nil, and adding a default name to a profile if
it doesn't have a title or name. This will solve the matching issue and also
clean up the formatter output so users can more easily tell what tests
are from which profile/path.
Signed-off-by: Adam Leff <adam@leff.co>
The crontab resource parses a particular user's crontab file into
individual entries and allows the user to assert information about
each entry as needed.
Signed-off-by: Adam Leff <adam@leff.co>
The other Chef tooling (chef-client, chef, kitchen, berks, etc.)
support a `-v` flag to display the version. Currently, inspec
errors out with the following error:
```
Could not find command "_v".
```
This adds a Thor map so that `-v` executes the `version` command.
Signed-off-by: Adam Leff <adam@leff.co>
This pull request adds a packages resource so that we can check for pattern matches against all the packages on a system. This initially implements only dpkg support for debian-based platforms so we can cover this use case:
```ruby
describe packages(/^xserver-xorg.*/) do
its("list") { should be_empty }
end
```
This uses FilterTable so we can supply additional queries, too.
```ruby
describe packages(/vi.+/).where { status != 'installed' } do
its('statuses') { should be_empty }
end
```
Users can specify the name as a string or a regular expression. If it is a string, we will escape it and convert it to a regular expression to use in matching against the full returned list of packages. If it is a regular expression, we take that as is and use it to filter the results.
While some package management systems such as `dpkg` can take a shell glob argument to filter their results, we eschew this and require a regular expression to match multiple package names because we will need this to work across other platforms in the future. This means that the following:
```ruby
packages("vim")
```
Will return *all* the "vim" packages on the system. The `packages` resource will take `"vim"`, turn it into `/vim/`, and greedily match anything with "vim" in the name. To match only a single package named `vim`, it needs to be an anchored regular expression.
```ruby
packages(/^vim$/)
```
Signed-off-by: Joshua Timberman <joshua@chef.io>
Use entries instead of list
Added a few more tests and non installed package in output
Signed-off-by: Alex Pop <apop@chef.io>
fix lint
Signed-off-by: Alex Pop <apop@chef.io>
Signed-off-by: Joshua Timberman <joshua@chef.io>
