The Molinillo library is a good library for systems that need a
constraint solver that will solve dependency problems requiring a single
version of each named dependency.
In our case, the eventual goal is to allow libraries to have conflicting
transitive dependencies at runtime. Isolation will be provided by
restricting all calls within a given profile to scope which can only see
that profile's dependencies.
To facilitate working on the isolation feature, I've replaced the
Molinillo-based resolver with a minimal resolver which will allow us to
load multiple versions of the same library.
Since we will likely want a good amount of logging around this feature
in the future, I've added a Inspec::Log singleton-style class, replacing
the previous Inpsec::Log which appeared unused in the code base.
Signed-off-by: Steven Danna <steve@chef.io>
This adds a basic prototype of inspec.lock. When the lockfile exists on
disk, the dependencies tree is constructed using the information in the
lock file rather than using the resolver.
Signed-off-by: Steven Danna <steve@chef.io>
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 commit is the foundation of the dependency resolution as described in https://github.com/chef/inspec/issues/888 .
It currently only works with local dependencies, as seen in the example inheritance profile.
Tests and full resolution are coming next on the path to an MVP implementation.
Redhat conf_dir detection was regressed in 57d7275 which inadvertently
removed the setting of @conf_dir. Any attempt to use the postgres
resource on RHEL would rain an exception:
inspec> postgres.data_dir
TypeError: no implicit conversion of nil into String
Further, the redhat detection code appears to assume that RHEL always
uses versioned data directories. This however, does not appear to be the
case:
$ cat /etc/redhat-release
CentOS release 6.7 (Final)
$ sudo ls /var/lib/pgsql/
backups data pgstartup.log
The code now can handle both versioned and un-versioned directory
formats on RHEL. Further, it provides diagnostic warnings about
uncertainty in the discovered data directories and configuration
directories.
Signed-off-by: Steven Danna <steve@chef.io>
Previously, if you typed more than 20 characters at the prompt and
attempted pressed Ctrl+a (readline's "Move to start of line" command),
your prompt would appear at the ~11th character from the start of the
line, unable to go further back.
This was a result readline counting the terminal escape sequences we use
for color output as part of the line.
Wrapping these sequences in \001 and \002 instructs readline to ignore
them when doing calculations regarding line-length, resolving the
problem.
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.
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>
The output of `systemctl show SERVICENAME` can be misleading in the
case of non-native services (i.e. services configured via an init script
and integrated with systemd via a shim) or for more sophisticated unit
types.
For example, the UnitFileState of ntp is "bad":
> systemctl show ntp | grep UnitFileState
UnitFileState=bad
despite systemd reporting it as enabled:
> systemctl is-enabled ntp
ntp.service is not a native service, redirecting to
systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install is-enabled ntp
enabled
Further, the old parsing code would have missed unit files in the
following states that are technically enabled:
enabled-runtime, indirect, generated, and transient
Using the `is-enabled` commands ensures that we report the same enabled
status that systemd reports, without having to update our own parsing in
the event that new unit states are added. Additionally, as shown above,
it handles the sysv compatibility helper.
Similarly, the is-active helper command ensures that we always report
the same active/not-active status as systemd would natively. For
instance, a quick reading of `src/systemctl/systemctl.c` in the systemd
source shows that systemctl reports units as active if they are in the
state `UNIT_ACTIVE` or `UNIT_RELOADING`.
Fixes#749
Signed-off-by: Steven Danna <steve@chef.io>
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.
reporters didnt stick to the formatters that were configured but looked for an old json one. this MR ensures that the formatter that is configured is pulled out to generate the report
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`.
