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.
