Salt: 2018.3.2, failed: could not determine a constructor for the tag

[nicholashoule]

Description of Issue/Question

I've configured my salt server to look to GitHub for the pillar, states, and reactor data, but I can't seem to get past two errors when restarting my targeted minion. Additionally, for the life of me, I cannot set the root users or any other users password to either '*' or '!' using my reactor file (start.sls).

Error 1

2018-10-06 16:16:07,795 [salt.state           :3454][CRITICAL][4921] Rendering SLS 'base:users' failed: could not determine a constructor for the tag '!$6$./xyz'
  in "<unicode string>", line 7, column 17:
        - password: !$6$./xyz ... 

Error 2
Fails silently and the minion doesn't update the users.
Running state.apply users works.

Setup

Getting pillar and states from GitHub.

master:

/etc/salt/master

gitfs_remotes:
   # HTTPS authentication
   - https://github.com/[user]/salt-states.git:
     - user: user
     - password: password


ext_pillar:
   - git:
     # HTTPS authentication
     - master https://github.com/[user]/salt-pillar.git:
       - user: user
       - password: password

reactor:
   - 'salt/minion/*/start':
    - salt://reactor/start.sls

pillar:

/pillar/top.sls

base:
  '*':
    - users
    - pkg

/pillar/users/init.sls

 users:
  {% if grains['os_family'] == 'RedHat' %}
  # Not supported

  {% elif grains['os_family'] == 'Debian' %}

  {% if grains['os'] == 'Ubuntu' %}
  # Users for Ubuntu
  root:
    fullname: root
    password: '"!"'
    shell: /bin/bash

  user1:
    fullname: User 1
    password: '"*"'
    shell: /bin/bash

  user2:
    fullname: User 2
    password: '"!$6$./xyz ..."'
    shell: /bin/bash
    ssh-keys:
      - ssh-ed25519 AAAAXYZ [email protected]
  {% endif %}

  {% elif grains['os'] == 'Arch' %}
  # Not supported
  {% endif %}

states:

/srv/salt/users/init.sls

# Add users
{% for user, args in pillar['users'].iteritems() %}
{{ user }}:
  group.present:
    - system: True
  user.present:
    - fullname: {{ args['fullname'] }}
    - password: {{ args['password'] }}
    - shell: {{ args['shell'] }}
    {% if not user == 'root' %}
    - groups:
      - {{ user }}
      - adm
      - sudo
    {% endif %}

{% if 'ssh-keys' in args %}
# User has ssh-keys
{{ user }}-sshkey:
  ssh_auth.present:
    - user: {{ user }}
    - config: '%h/.ssh/authorized_keys'
    - names:
      {% for key in args['ssh-keys'] %}
      - {{ key }}
      {% endfor %}

{% endif %}
{% endfor %}

reactor:

/srv/reactor/start.sls

highstate_run_packages:
  local.state.apply:
    - tgt: 'os:Ubuntu'
    - tgt_type: grain
    - arg:
      - packages

highstate_run_users:
  local.state.apply:
    - tgt: 'os:Ubuntu'
    - tgt_type: grain
    - arg:
      - users

Steps to Reproduce Issue

Follow the pillar doc specifically to add users and packages.
https://docs.saltstack.com/en/latest/topics/tutorials/pillar.html

Use a git-backed salt server for:

• pillar
• states
• reactor

Modify the pillar users file to resemble mine.
Modify the state users file to resemble mine.
Add the reactor start.sls file targeting at least one minion.
Change the passwords for the targeted users.
Restart the minion targeted in the reactor start.sls file.

Versions Report

Salt Version:
           Salt: 2018.3.2

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.8
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: 0.26.0
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.26.2
         Python: 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 17.1.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: Ubuntu 18.04 bionic
         locale: UTF-8
        machine: x86_64
        release: 4.15.0-36-generic
         system: Linux
        version: Ubuntu 18.04 bionic

[garethgreenaway]

@nicholashoule Thanks for the report. I wasn't able to duplicate the error on minion start up but when I was attempting to runt the above users state manually I got a YAML rendering error because the passwords aren't wrapped in quotes, so the asterisk in this case was being interrupted by YAML. I suspect the same is true for the exclamation mark.

[nicholashoule]

@garethgreenaway, I fixed my code comment to include '"[value]"' for the working module when running state.apply. I have to admit the system appears to be working at times, but if you verify the minion's shadow file it isn't being updated; well not on my end. I'm able to update the minion by issuing a state.apply users command from the master which proves the module works and the minion's shadows file reflects the changes. Maybe I'm not using reactors correctly; Is the shadow file on the minion changing for you using the reactor start.sls file, if you restart the minion?

Note:

Additional details:

The salt-minion is running in a Docker container (ubuntu:18.04), but that detail shouldn't matter.

Docker Node: 362a5dfed5d0

VERSION="18.04.1 LTS (Bionic Beaver)"
salt-minion 2018.3.2 (Oxygen)

I've tried:

'"!"' and "!", neither have worked for me.
'"*"' and "*", neither have worked for me.
'"!$6$./xyz ..."' and "!$6$./xyz ...", neither have worked for me.

{%- if grains['os'] == 'Ubuntu' -%} (Removed spacing, generates 1st error above.)

Update:

I found my Sending event tag, but the minion's /etc/shadow file isn't reflecting the values from the pillar.

[INFO    ] Got return from 362a5dfed5d0 for job 20181008221406057654
[DEBUG   ] Sending event: tag = salt/job/20181008221406057654/ret/362a5dfed5d0; data = {'fun_args': ['users'], 'jid': '20181008221406057654', 'return': ['The function "state.apply" is running as PID 1401 and was started at 2018, Oct 08 22:14:06.040579 with jid 20181008221406040579'], 'retcode': 1, 'success': True, 'cmd': '_return', u'_stamp': '2018-10-08T22:14:06.248825', 'fun': 'state.apply', 'id': '362a5dfed5d0', 'out': 'highstate'}

[DEBUG   ] Sending event: tag = salt/job/20181008223100626732/ret/362a5dfed5d0; data = {'fun_args': [], 'jid': '20181008223100626732', 'return': {'users': {'root': {'password': '!', 'fullname': 'root', 'shell': '/bin/bash'}, 
'user2': {'password': '!$6$./XYZ ...', 'fullname': 'User 2', 'shell': '/bin/bash', 
'ssh-keys': ['ssh-ed25519 AAAAC ... [email protected]']}}, 'pkgs': {'build-essential': 'build-essential', 'dnsutils': 'dnsutils', 'git': 'git-core', 'nano': 'nano', 
'haveged': 'haveged', 'screen': 'screen', 'tree': 'tree', 'tmux': 'tmux', 'vim': 'vim', 'htop': 'htop', 'net-tools': 'net-tools', 'wget': 'wget', 'curl': 'curl', 'dos2unix': 'dos2unix', 'ssh': 'ssh'}, 
'securepolicy_role': 'base'}, 'retcode': 0, 'success': True, 'cmd': '_return', u'_stamp': '2018-10-08T22:31:01.466736', 'fun': 'pillar.items', 'id': '362a5dfed5d0'}

[nicholashoule]

I've created two example repos reflecting my configurations:
https://github.com/nicholashoule/salt-pillar
https://github.com/nicholashoule/salt-states

I'm trying to set/ensure the systems' root password to ! and the user's password to !$6$ ... using a reactor file, notice the leading exclamation mark in both passwords. The events appear to trigger and everything seems to work until I verify the contents of the shadow file on the minion that was targeted. Can you reproduce this using a similar configuration to the repos referenced above? Did the minion's shadow file change when you view it's contents?

[garethgreenaway]

@nicholashoule Thanks. I'll try to reproduce using the repos above.

[garethgreenaway]

@nicholashoule I see the reactor firing and running the packages state but doesn't run the user state. The problem is likely that there are multiple reactions in the reactor SLS file. Try breaking them out:

start_ubuntu_packages.sls:

highstate_ubuntu_run_packages:
  local.state.apply:
    - tgt: 'os:Ubuntu'
    - tgt_type: grain
    - arg:
      - packages

start_ubuntu_users.sls:

highstate_ubuntu_run_users:
  local.state.apply:
    - tgt: 'os:Ubuntu'
    - tgt_type: grain
    - arg:
      - users

Then update your reactor configuration:

reactor:
  - 'minion_start':
    - salt://reactor/start_ubuntu_packages.sls
    - salt://reactor/start_ubuntu_users.sls

[nicholashoule]

@garethgreenaway , I separated out my reactor files as you demonstrated and, finally, I was was able to see the changes reflected in the minion's /etc/shadow file. There was one caveat, order mattered, I had to list the start_ubuntu_users.sls file before the start_ubuntu_packages.sls file. Did you notice that behavior or not?

######        Reactor Settings        #####
###########################################
# Define a salt reactor. See https://docs.saltstack.com/en/latest/topics/reactor/
reactor:
  - 'minion_start':
    - salt://reactor/start_ubuntu_users.sls      # Things to do when a ubuntu minion starts
    - salt://reactor/start_ubuntu_packages.sls   # Things to do when a ubuntu minion starts
    - salt://reactor/start_raspbian_packages.sls # Things to do when a Raspbian minion starts
    - salt://reactor/start_raspbian_users.sls    # Things to do when a Raspbian minion starts
    - salt://reactor/sync_grains.sls             # Sync custom grains

[garethgreenaway]

@nicholashoule I will have to go back and take another look, I don't remember if I noticed if the order mattered or not.

[nicholashoule]

@garethgreenaway , I do have to admit my start_ubuntu_users.sls reactor fails often. I restarted the minion after manually changing the user's password and the reactor hasn't changed the password back so it must be silently failing again. My confidence in reactors is nearing zero and I might have to figure a new way of ensuring user accounts are locked.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.