Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

systemd is-enabled check does not handle backcompat with sysv-init scripts (e.g. ntp on Ubuntu 16.04) #749

Closed
lamont-granquist opened this issue May 13, 2016 · 8 comments
Closed

systemd is-enabled check does not handle backcompat with sysv-init scripts (e.g. ntp on Ubuntu 16.04) #749

lamont-granquist opened this issue May 13, 2016 · 8 comments
Labels
Type: Bug Feature not working as expected
Milestone
0.29.0

Comments

@lamont-granquist
Copy link
Contributor

lamont-granquist commented May 13, 2016 •
edited by chris-rock
Loading

Description

False failure for ntp and nscd services being enabled.

InSpec and Platform Version

Ubuntu 16.04
inspec (0.20.1)
kitchen-inspec (0.12.5)

Replication Case

  • use the default nscd and/or ntp chef cookbooks to configure nscd/ntp.
  • service[ntp] will run with :enable and :start actions
  • service[nscd] will run with :enable and :start actions
  • inspec tests will fail with these tests:
describe service('ntp') do
  it { should be_enabled }
end

describe service('nscd') do
  it { should be_enabled }
end

Possible Solutions

  • note that the service is called 'ntp' in the first case but the process that is launched is called 'ntpd', that might be causing issues if you're doing scans of ps output.
  • ubuntu 16.04 is all systemd-ified so that might be causing issues.

Stacktrace

Failures:

  1) Service nscd should be enabled
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
       expected that `Service nscd` is enabled
     # ./test/integration/webapp/default_spec.rb:15:in `block (2 levels) in load'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/inspec-0.20.1/lib/inspec/runner_rspec.rb:67:in `run'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/kitchen-inspec-0.12.5/lib/kitchen/verifier/inspec.rb:47:in `call'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:423:in `block in verify_action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:513:in `call'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:513:in `synchronize_or_call'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:478:in `block in action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:477:in `action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:415:in `verify_action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:348:in `block in transition_to'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:347:in `each'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:347:in `transition_to'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:160:in `verify'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/command.rb:176:in `public_send'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/command.rb:176:in `block (2 levels) in run_action'

  2) Service ntp should be enabled
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
       expected that `Service ntp` is enabled
     # ./test/integration/webapp/default_spec.rb:45:in `block (2 levels) in load'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/inspec-0.20.1/lib/inspec/runner_rspec.rb:67:in `run'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/kitchen-inspec-0.12.5/lib/kitchen/verifier/inspec.rb:47:in `call'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:423:in `block in verify_action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:513:in `call'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:513:in `synchronize_or_call'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:478:in `block in action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:477:in `action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:415:in `verify_action'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:348:in `block in transition_to'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:347:in `each'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:347:in `transition_to'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/instance.rb:160:in `verify'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/command.rb:176:in `public_send'
     # /Users/lamont/.rvm/gems/ruby-2.2.5/gems/test-kitchen-1.8.0/lib/kitchen/command.rb:176:in `block (2 levels) in run_action'

Finished in 0.16498 seconds (files took 0.70271 seconds to load)
16 examples, 2 failures

Failed examples:

rspec  # Service nscd should be enabled
rspec  # Service ntp should be enabled
@lamont-granquist
Copy link
Contributor Author

but 'fail2ban' and 'ssh' seem to work, so..... ???

@chris-rock
Copy link
Contributor

So Ubuntu 16.04 should use systemd by default https://github.com/chef/inspec/blob/master/lib/resources/service.rb#L117-L121:

if version < 15.04
  Upstart.new(inspec, service_ctl)
else
  Systemd.new(inspec, service_ctl)
end

@chris-rock
Copy link
Contributor

We also have a systemd_service, is it working with that resource?

@chris-rock
Copy link
Contributor

Do you use the systemd name for ntp?

@lamont-granquist
Copy link
Contributor Author

so there's no systemd_service documented at https://github.com/chef/inspec/blob/master/docs/resources.rst

@lamont-granquist
Copy link
Contributor Author

lamont-granquist commented May 16, 2016 •
edited
Loading

and i just tried ntp.service but that failed as well.

this might help:

# 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

@lamont-granquist lamont-granquist changed the title False failure with ntp and nscd service resources when testing 'should be_enabled' on Ubuntu 16.04 (systemd issue?) systemd is-enabled check does not handle backcompat with sysv-init scripts (e.g. ntp on Ubuntu 16.04) May 16, 2016
@lamont-granquist
Copy link
Contributor Author

probably a more accurate title based on the behavior i'm seeing... could be as simple as checking that the last line from stdout is "enabled" rather than checking if the output == "enabled"?

@chris-rock chris-rock added the Type: Bug Feature not working as expected label May 19, 2016
@chris-rock chris-rock added this to the 1.0.0 milestone Jul 26, 2016
@viq
Copy link

viq commented Jul 29, 2016

Just a note that I'm seeing problems with is_enabled on debian 8 (systemd) as well .

@chris-rock chris-rock mentioned this issue Aug 2, 2016
Closed
@chris-rock chris-rock modified the milestones: 0.29.0, 1.0.0 Aug 2, 2016
stevendanna added a commit that referenced this issue Aug 3, 2016
@stevendanna
Use systemctl's helper command to determine enabled & active status
546b5e6 
Fixes #749

Signed-off-by: Steven Danna <steve@chef.io>
@stevendanna stevendanna mentioned this issue Aug 3, 2016
Merged
stevendanna added a commit that referenced this issue Aug 3, 2016
@stevendanna
Use systemctl's helper command to determine enabled & active status
9403011 
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
times.

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. Further, 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>
stevendanna added a commit that referenced this issue Aug 3, 2016
@stevendanna
Use systemctl's helper command to determine enabled & active status
28946f5 
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>
@chris-rock chris-rock mentioned this issue Aug 18, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Bug Feature not working as expected
Projects
None yet
Milestone
0.29.0
Development

No branches or pull requests
4 participants
@lamont-granquist @viq @stevendanna @chris-rock