salt-ssh JSON Render failed - Permission denied, no authentication information

[skandyla]

Hi, this issue is based on the following discussion https://groups.google.com/forum/?pli=1#!topic/salt-users/elKOx-T0yFM

In some cases, when we install pkg and create the config for it, salt reporting with

[ERROR   ] JSON Render failed for: 
Permission denied, no authentication information
[ERROR   ] No JSON object could be decoded

But actually state executes normal.

Actual Behavior

Just to show, that screen package is absent at my system:

# salt-ssh -i example.com -r 'rpm -qa|grep screen; ls -l /etc/screenrc'
example.com:
    ----------
    retcode:
        2
    stderr:
        ls: cannot access /etc/screenrc: No such file or directory
    stdout:

The first run:

mysrv salt # salt-ssh  example.com state.sls tools.screen
[ERROR   ] JSON Render failed for: 
Permission denied, no authentication information
[ERROR   ] No JSON object could be decoded
example.com:

Second:

mysrv salt # salt-ssh  example.com state.sls tools.screen
example.com:

Summary for example.com
------------
Succeeded: 2
Failed:    0
------------
Total states run:     2

Steps to Reproduce Issue

salt-ssh example.com -r 'yum -y remove screen; rm /etc/screenrc' salt-ssh example.com state.sls tools.screen

Versions Report

\ Provided by running salt --versions-report**

Salt Version:
           Salt: 2015.8.7

Dependency Versions:
         Jinja2: 2.7.3
       M2Crypto: 0.21.1
           Mako: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.7.0
         Python: 2.7.5 (default, Nov 20 2015, 02:00:19)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.4.2
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
        libgit2: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: Not Installed
        timelib: Not Installed

System Versions:
           dist: centos 7.2.1511 Core
        machine: x86_64
        release: 3.10.0-327.3.1.el7.x86_64
         system: CentOS Linux 7.2.1511 Core

Relevant Logs, Configs, or States

cat tools/screen/init.sls

screen:
  pkg.installed

screenrc:
  file.managed:
    - name: /etc/screenrc
    - source: salt://tools/screen/.screenrc
    - user: root
    - group: root                                                                    
    - mode: 644

The contents of the screenrc doesn't matter. I also tried to provide config with contents_pillar: - contents_pillar: screen:screenrc without any success.

roster is trivial:

example.com:
  host: example.com

The issue reproduces on every of my centos7 srvs, and doesn't reproduces on ubuntu\debian srvs. Also, this is not screen-related issue. I've got the same issue at my chrony module.

[jfindlay]

@skandyla, thanks for the report.

[duk3luk3]

This error also happens when the salt-ssh output is too large. For example replacing a 254K file using file.managed (resulting in a huge diff being printed) triggered it.

                  Salt: 2015.5.3
                Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
                Jinja2: 2.7.2
              M2Crypto: 0.21.1
        msgpack-python: 0.3.0
          msgpack-pure: Not Installed
              pycrypto: 2.6.1
               libnacl: Not Installed
                PyYAML: 3.10
                 ioflo: Not Installed
                 PyZMQ: Not Installed
                  RAET: Not Installed
                   ZMQ: Not Installed
                  Mako: Not Installed
               Tornado: Not Installed
 Debian source package: 2015.5.3+ds-1trusty1

[skandyla]

Hi, this error also very hard to debug. Since salt-ssh doesn't report which module caused it.

For example, what I start getting recently:

# time salt-ssh  remotesrv.com state.highstate
[ERROR   ] JSON Render failed for:
Permission denied, no authentication information
[ERROR   ] No JSON object could be decoded
remotesrv.com:

real    7m31.709s
user    0m15.327s
sys     0m3.276s

# time salt-ssh  remotesrv.com state.highstate
remotesrv.com:

Summary for remotesrv.com
--------------
Succeeded: 164
Failed:      0
--------------
Total states run:     164

real    0m58.189s
user    0m12.150s
sys     0m1.597s

Debug logging doesn't help.

[duk3luk3]

164 states looks a lot like it could be the same problem as mine (output too large).

[jfindlay]

Especially since the second highstate run is very likely to contain less output than the first.

[skandyla]

Actually the size of the output doesn't matter. It fails with less count of states too:

mysrv # time salt-ssh -i --wipe remotesrv.com state.highstate
[ERROR   ] JSON Render failed for: 
Permission denied, no authentication information
[ERROR   ] No JSON object could be decoded
remotesrv.com:

real    2m29.970s
user    0m10.925s
sys     0m1.720s

mysrv # time salt-ssh -i --wipe remotesrv.com state.highstate
remotesrv.com:

Summary for remotesrv.com
-------------
Succeeded: 81
Failed:     0
-------------
Total states run:     81

real    0m36.515s
user    0m8.605s
sys     0m1.336s

[skandyla]

It seems, that two my latests comments it's another issue, caused by deploying to ec2 nodes with sudo.

remotesrv.com:
  host:  111
  user: centos
  sudo: true

I've tried to deploy to DigitalOcean with the same settings, but without sudo - and it's working good.

[axmetishe]

I don't know is it actual, but I got same issue. In my case I tried to rewrite configuration file with 650 lines(mostly comments) by 6 lines of pure configuration, it looks like it can't return diff. Of course this is not a normal behavior but I'm resolved this issue via file cleaning

[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.