Bug 1024236 - Can't activate a host due to /etc/sudoer configuration
Can't activate a host due to /etc/sudoer configuration
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
Unspecified Unspecified
low Severity low
: ---
: 3.4.0
Assigned To: Yaniv Bronhaim
Petr Beňas
Depends On:
  Show dependency treegraph
Reported: 2013-10-29 03:58 EDT by Alexander Chuzhoy
Modified: 2016-02-10 14:11 EST (History)
11 users (show)

See Also:
Fixed In Version: ovirt-3.4.0-alpha1
Doc Type: Bug Fix
Doc Text:
An error message has been added to remind users that sudo rights must be checked in order to ensure that hosts are properly activated by the vdsm user. This error message appears when the #includedir /etc/sudoers.d directive has been skipped for any reason (for instance, because a custom tool was used to generate the sudoers.d file). This error message reads "Verify sudoer rules configuration".
Story Points: ---
Clone Of:
VDSM: vdsm-4.10.2-27.0.el6ev.x86_64 OS: RHEL6.4 Kernel: vdsm-4.10.2-27.0.el6ev.x86_64
Last Closed: 2014-06-09 09:26:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is a vdsm log of the affected host. (2.45 MB, text/plain)
2013-10-29 03:58 EDT, Alexander Chuzhoy
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 22888 None None None Never

  None (edit)
Description Alexander Chuzhoy 2013-10-29 03:58:09 EDT
Created attachment 816998 [details]
This is a vdsm log of the affected host.

Description of problem:
Can't activate a new host in the existing cluster.

Version-Release number of selected component (if applicable):
VDSM: vdsm-4.10.2-27.0.el6ev.x86_64

How reproducible:

Steps to Reproduce:
1. Adding a new host to the existing cluster on manager running 3.2.4.

Actual results:
The host becomes "Non Operational"

Expected results:
The state should be "UP".

Additional info:
Comment 1 Itamar Heim 2013-10-29 11:50:01 EDT
please add engine log for the non-operational reason (regardless, need to make sure the supervdsm errors in the vdsm log are ok)
Comment 2 Yaniv Bronhaim 2013-10-30 07:36:54 EDT
No need for additional information. The reason vdsm didn't start properly is the sudoer.d configuration. Somehow vdsm config was settled under the appropriate location with the right configuration for vdsm user, but still the sudo operations was prevented (as starting supervdsm process with sudo, running multipath commands, both were terminated).

Please inform me if reinstallation of the host helped, if not we need to figure why the sudoer file was not enough
Comment 3 Alexander Chuzhoy 2013-10-30 09:46:18 EDT
The sudoers file was autogenerated by some tool we use so it missed the #includedir /etc/sudoers.d directive.
Once added - the issue got fixed.

I'd suggest verifying it exists in the installation.
Comment 4 Yaniv Bronhaim 2013-10-31 05:13:17 EDT
After some thinking, you're right. we should verify it during pre-start of vdsmd

vdsm adds 50_vdsm file under /etc/sudoers.d , without #includedir /etc/sudoers.d on /etc/sudoers , this won't be read and all sudo operations by vdsm user will be rejected. the implications -> multipath commands fail, supervdsmServer cannot start and more and inc. vdsm cannot operate without this line, so it should verify it. please ack the bug.
Comment 5 Dan Kenigsberg 2013-10-31 06:56:31 EDT
There could be soooo many configuration files that can be ruined by a local admin or "by some tool we use". We can never expect to check every configuration file in the host meets our expectations.

We require a sudoers version that has #includedir by default. If the local admin removes it, he should have a really good reason to do it, and also inlined /etc/sudoers.d/50_vdsm. It's not vdsm's business to force an #includedir upon him.

My vote: CLOSE|NOTABUG after verifying that our log are clear, complaining about missing sudo rights.
Comment 6 Alexander Chuzhoy 2013-10-31 08:49:53 EDT
That's just it. We weren't able to understand what's wrong from the logs.
Making it clear that the sudo rights need to be checked is good enough (IMHO).
Comment 9 Petr Beňas 2014-02-18 07:20:16 EST
Verified in 3.4.0-0.7.beta2.el6

[root@slot-7 ~]# grep '\.d' /etc/sudoers
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
##includedir /etc/sudoers.d
[root@slot-7 ~]# grep sudoer /var/log/messages | tail -n 3
Feb 18 13:15:08 slot-7 python: vdsm user could not manage to run sudo operation: (stderr: ['sudo: sorry, you must have a tty to run sudo']). Verify sudoer rules configuration
Feb 18 13:15:08 slot-7 python: vdsm user could not manage to run sudo operation: (stderr: ['sudo: sorry, you must have a tty to run sudo']). Verify sudoer rules configuration
Feb 18 13:15:09 slot-7 python: vdsm user could not manage to run sudo operation: (stderr: ['sudo: sorry, you must have a tty to run sudo']). Verify sudoer rules configuration
Comment 10 errata-xmlrpc 2014-06-09 09:26:16 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.