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>
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>
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>
* Fixes an issue when specifying no profile
* Fixes an issue when displaying a profile that has included/required profiels
* Fixes an issue when specifying profiles with only metadata
* Fixes formatting for spacing to ensure it adheres to previous alignment
* Fixes issue with the Control object and the rolling up of failed
and skipped examples.
Signed-off-by: Franklin Webber <franklin@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>
This commit threads through some state related to whether or not a
profile is "local", that is whether it is a directory on disk. If it
is, we then write out the lockfile to disk.
Signed-off-by: Steven Danna <steve@chef.io>
If a URL based source does not match the shasum recorded in the
lockfile, it likely means a new version has been pushed to the remote
source. In this case, we fail to help ensure that when using a lockfile
we always run the same code as when the lockfile was created.
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>
This is a regression introduced by the changes from string to symbol
keys in v0.34.0. It seems that our test cookbook that had a nested
dependency example wasn't actually wired up to run.
This adds a basic functional test and corrects the typo.
Signed-off-by: Steven Danna <steve@chef.io>
The recent changes to provide isolated views of the available resources
was not extended to Rspec::ExampleGroups. This ensures that
ExampleGroups have access to the same resources as the enclosing
Inspec::Rule.
Signed-off-by: Steven Danna <steve@chef.io>
This adds a new git fetcher. In doing so, it also refactors how the
fetchers work a bit to better support fetchers that need to resolve
user-provided sources to fully specified sources appropriate for a
lockfile.
Signed-off-by: Steven Danna <steve@chef.io>
Before this change, simplecov was reporting
1864 / 5198 LOC (35.86%) covered
After this change it is reporting
4131 / 5275 LOC (78.31%) covered.
Keeping the require at the top of the file ensure that simplecov is
loaded before any of our application code.
Previously, libraries were loaded by instance_eval'ing them against
the same execution context used for control files. All resources were
registered against a single global registry when the `name` dsl method
was invoked. To obtain seperation of resources, we would mutate the
instance variable holding the globale registry and then change it back
at the end.
Now, we instance_eval library files inside an anonymous class. This
class has its own version of `Inspec.resource` that returns another
class with the resource DSL method and the profile-specific resource
registry.
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>
The goal of this change is to provide an isolated view of the available
profiles when the user calls the include_controls or require_controls
APIs. Namely,
- A profile should only be able to reference profiles that are part of
its transitive dependency tree. That is, if the dependency tree for a
profile looks like the following:
A
|- B --> C
|
|- D --> E
Then profile B should only be able to see profile C and fail if it
tries to reference A, D, or E.
- The same profile should be include-able at different versions from
different parts of the tree without conflict. That is, if the
dependency tree for a profile looks like the following:
A
|- B --> C@1.0
|
|- D --> C@2.0
Then profile B should see the 1.0 version of C and profile D should
see the 2.0 profile C with respect to the included controls.
To achieve these goals we:
- Ensure that we construct ProfileContext objects with respect to the
correct dependencies in Inspec::DSL.
- Provide a method of accessing all transitively defined rules on a
ProfileContext without pushing all of the rules onto the same global
namespace.
This does not yet handle attributes or libraries.
This extends the dependency feature to include support for url-based
dependencies. It takes some deviations from the current support for
URLs that we'll likely want to make more consistent.
By default, we store downloaded archives in the cache rather than the
unpacked archive. However, to facilitate debugging, we will prefer the
unpacked archive if we find it in the cache.
Signed-off-by: Steven Danna <steve@chef.io>
This adds a new subcommand:
inspec env [SHELL]
which outputs a shell-appropriate completion script that the user can
source into their shell:
eval "$(inspec env SHELL)"
Currently, we provide completions for ZSH and Bash. The completion
scripts are generated from the data Thor collects.
If the user doesn't provide SHELL we attempt to detect what the user's
shell may be using a number of methods.
Signed-off-by: Steven Danna <steve@chef.io>
(1) The field is not yet optimal, the calculations are great!
(2) Changing this field should go together with all other breaking json changes, especially if https://github.com/chef/inspec/pull/811 results in a change.
Ruby's autoload feature is not threadsafe. We are hoping requiring the
docker plugin early will fix odd failures we have been seeing.
Signed-off-by: Steven Danna <steve@chef.io>
This allows the user to write:
describe port(22) do
it { should be_listening }
end
as well as
describe port('22') do
it { should be_listening }
end
without hitting an error.
Fixes#867
Signed-off-by: Steven Danna <steve@chef.io>
In many linux distributions a link to /proc/kcore is placed at
`/dev/core`. In TravisCI we see it at `/dev/kcore`. To avoid tests
failing for some developers locally, we support either location.
Mixing types in an array without specifying what these fields point to is not just confusing, but also causes issues with endpoints that may consume this data and dont process mixed types. We strive to have a stable api for 1.0 and this is a sin that was left after the major overhaul. Time to fix it.
this happens when the profile is run (exec) and also interpreted (via profile.params). It will load 2 profile context calls (both via Runner) which in turn gets 2 rounds of interpreter+runner executions. This is an issue with auto-generated IDs, due to their random component, which changes in this case
Full rewrite of all formatters. Create a minimal JSON, a full JSON, and a fallback RSpec formatter. The latter is only needed for corner cases and should not really be used. The former 2 are for (1) running `inspec json` followed by `inspec exec` (`--format json`) and (2) running just `inspec exec --format fulljson`.
