Netstat will sometimes output an IPv6 address that is not
formatted correctly; the address is either truncated or uses
or implies the `::` shorthand notation twice. This yields an
invalid IPv6 address and causes IPAddr.new to choke.
This change guards against invalid IP addresses and ensures they
do not end up in the port resource's entries list.
Signed-off-by: Adam Leff <adam@leff.co>
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>
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>
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>
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>
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>
Previous, require_controls was including all controls from the named
profile, despite the documented behavior being that it only includes
controls explicitly pulled in by the user. The cause was two-fold:
1) A previous refactor meant that we weren't removing the rule from the
correct context, and
2) We weren't descending down the dependency tree when filtering rules.
This commit fixes the require_controls DSL method and adds a test to
help prevent future regressions.
Signed-off-by: Steven Danna <steve@chef.io>
All resources from deps are added into the control_eval_context used by
the current profile. However, if there is a name conflict, the last
loaded resource wins. The new `require_resource` dsl method allows the
user to do the following:
require_resource(profile: 'profile_name',
resource: 'other',
as: 'renamed')
describe renamed do
...
end
Signed-off-by: Steven Danna <steve@chef.io>
The goal of these changes is to ensure that the libraries from
dependencies are loaded even if their controls are never included. To
facilitate this, we break up the loading into seperate steps, and move
the loading code into the Profile which has acceess to the dependency
information.
Signed-off-by: Steven Danna <steve@chef.io>
Previously, all resources were loaded into a single resource registry.
Now, each profile context has a resource registry, when a profile's
library is loaded into the profile context, we update the
profile-context-specific resource registry. This local registry is
then used to populate the execution context that the rules are
evaluated in.
Signed-off-by: Steven Danna <steve@chef.io>
A few minor issues were causing 3 functional test failures on OS X.
These were not program errors but where rather the result of the
profiles under test assuming a linux environment.
Since many of the developers who will work on this project in the future
will be running OS X, let's ensure they can run the functional tests
easily.
Signed-off-by: Steven Danna <steve@chef.io>
