Error using sudoers.included

[brandentimm]

I am experiencing errors with the sudoers.included state related to the 'sudoers' variable in the /etc/sudoers template. Here is my configuration:

In top.sls, sudoers is applied globally, and sudoers.included is applied to the host experiencing the error:
top.sls

base:
  '*':
    - sudoers
  'myhost':
    - sudoers.included

The pillar data for myhost is as follows:

sudoers:
  groups:
    itops: 'ALL=(ALL) ALL'
    sudo: 'ALL=(ALL) ALL'
  includedir: /etc/sudoers.d
  included_files:
    /etc/sudoers.d/git-salt:
      - users:
        - git: 'ALL= /usr/bin/salt-call'

However when salt is called, I receive the following error:

          ID: /etc/sudoers.d/git-salt
    Function: file.managed
      Result: False
     Comment: Unable to manage file: Jinja variable 'list object' has no attribute 'get'; line 18

              ---
              [...]
                  {%- set users = sudoers.get('users', {}) %}
                  {%- set groups = sudoers.get('groups', {}) %}
                {%- endif %}
                {%- set includedir = sudoers.get('includedir', '/etc/sudoers.d') -%}
              {%- else %}
                {%- set defaults = sudoers.get('defaults', []) %}    <======================
                {%- set users = sudoers.get('users', {}) %}
                {%- set groups = sudoers.get('groups', {}) %}
                {%- set includedir = sudoers.get('includedir', None) %}
              {%- endif %}
              {%- set aliases = sudoers.get('aliases', {}) %}
              [...]
              ---

From looking at the code, it seems that indeed sudoers is not initialized if the file is included, which it is from sudoers.included. sudoers.included does initialize sudoers from pillar, but I'm not sure how or if the context gets passed between the included file.

[vachaspativ]

+1
Very true, i have the same issue when using the sudoers.included

[gravyboat]

Hmm, I'm surprised this is still an issue (I actually don't even remember this one being opened last year sadly). @nmadhok Do you know who is familiar enough with this formula to do a quick fix? The contributors list is pretty sparse.

[nmadhok]

@carlosperello or @aboe76 May be able to provide a fix for this.

[vachaspativ]

Carlos or Niels, can you please let us know if there are any updates.
thanks.

[aboe76]

@vachaspativ

Strange I run the same sudoers formula on my own machines, archlinux / opensuse / debian

and I have this configuration:

sudoers:
  users:
    root:
      - 'ALL=(ALL) ALL'
  defaults:
    generic:
      - env_reset
      - always_set_home
      - mail_no_perms
      - set_home
      - tty_tickets
      - mail_badpass
      - secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      - editor=/usr/bin/vim
    user_list:
      aboe: '!requiretty'
    runas_list:
      root: '!set_logname'
  includedir: /etc/sudoers.d
  included_files:
    /etc/sudoers.d/10_XXXXXXXX:
      users:
        XXXXXXXX:
          - 'ALL=(ALL) NOPASSWD: ALL'
          - 'ALL = NOPASSWD: /usr/bin/build'
          - 'ALL = NOPASSWD: /usr/bin/osc'

And I don't see this problem,

this is my top.sls

base:
  '*':
    - users_minion
    - salt-minion
    - openssh
    - sudoers
    - mine
    - ntp

Will test with sudoers.included

[aboe76]

@vachaspativ update,
even with this top.sls I don't see the issue you report:

base:
  '*':
    - users
    - sudoers
    - sudoers.included
    - logrotate
    - openssh
    - openssh.client
    - openssh.config
    - vim.salt
    - vim.jinja
    - vim.repeat
    - salt.minion
    - haveged
  'example.home.lan':
    - sudoers.included

running state.highstate on example.home.lan is without issues.

[vachaspativ]

Hi Niels,
I just created a Debian Wheezy VM and tested it.
You are actually correct. Even I am able to successfully create the file when i execute sudoers.included

But when i try it out for Oracle Ent Linux 6.5 its failing.

The error is below.

      ID: /etc/sudoers.d/XXXXXXX
Function: file.managed
  Result: False
 Comment: Unable to manage file: Jinja error: local variable 'l_sudoers' referenced before assignment
          Traceback (most recent call last):
            File "/usr/lib/python2.6/site-packages/salt/utils/templates.py", line 286, in render_jinja_tmpl
              output = template.render(**unicode_context)
            File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 669, in render
              return self.environment.handle_exception(exc_info, True)
            File "<template>", line 28, in top-level template code
          UnboundLocalError: local variable 'l_sudoers' referenced before assignment

          ; line 28

          ---
          [...]
              {%- set users = sudoers.get('users', {}) %}
              {%- set groups = sudoers.get('groups', {}) %}
            {%- endif %}
            {%- set includedir = sudoers.get('includedir', '/etc/sudoers.d') -%}
          {%- else %}
            {%- set defaults = sudoers.get('defaults', {}) %}    <======================
            {%- set generic_defaults = defaults.get('generic', []) %}
            {%- set user_list_defaults = defaults.get('user_list', {}) %}
            {%- set host_list_defaults = defaults.get('host_list', {}) %}
            {%- set command_list_defaults = defaults.get('command_list', {}) %}
            {%- set runas_list_defaults = defaults.get('runas_list', {}) %}
          [...]
          ---
 Started: 14:11:37.296000
Duration: 54.016 ms
 Changes:

I observed that the python is 2.7.3 on the Debian machine but it is just 2.6.6 on the OEL.
Could that be the problem? I am looking into it myself now.
Will get back if I find anything.
Thanks.

[southquist]

I am experiencing this problem on some CentOS 6.5 systems, the only difference that i see is the version of jinja.

minion001:
    python-jinja2-2.7-1.el6.noarch
minion002:
    python-jinja2-2.7.2-2.el7.noarch
minion003:
    python-jinja2-2.2.1-2.el6_5.x86_64
minion004:
    python-jinja2-2.2.1-2.el6_5.x86_64

For me sudoers.included does not work on minion003 and minion004 that uses python-jinja2-2.2.1-2.el6_5.x86_64.

[gravyboat]

Hmm, I know there is some functionality that doesn't work on older Jinja2 releases, but I'm not familiar enough with them to confirm if that functionality exists in this formula.

[jcross-linkup]

I can confirm that it is a jinja2 version issue in CentOS 6. I started with jinja2 2.2.1 which did not work. I then switched to version 2.8 and it worked. Here's the hack I use to work around it:

yum install -y yum-versionlock python-pip
# version lock the python-jinja2 package so an update of it doesn't clobber the pip version
yum versionlock python-jinja2
# note: without C compilers this will be pure python without speed-ups
pip install --upgrade jinja2

[bradthurber]

@jcross-linkup commented on Jan 28, 2016, 10:07 PM EST:

I can confirm that it is a jinja2 version issue in CentOS 6. I started with jinja2 2.2.1 which did not work. I then switched to version 2.8 and it worked. Here's the hack I use to work around it:

I am on RHEL 6.7 with the same Jinja2 2.2.1. I can confirm that @jcross-linkup 's workaround also works in my case. In, fact the issue goes away in Jinja2 2.3 - which is the very next version after 2.2.1. From the Jinja2 2.3 change log I'm guessing that this may be the jinja2 issue that fixes this:

fixed a problem with having call blocks in outer scopes that have an argument
that is also used as local variable in an inner frame (#360).

I'm not sure what that tells those of us that are stuck on 2.2.1. Should the formula be modified to account for this? Should salt/utils/templates.py be modified to work better with Jinja2 2.2.1? Should we consider slipstreaming a newer version of Jinja2 on RHEL 6/CentOS 6?