salt-ssh can't use MySQL returner

Created on 14 Apr 2016  Â·  12Comments  Â·  Source: saltstack/salt

Description

root@test-saltstack-10-63 salt]# salt 'test-yum-10-59' test.ping -v
Executing job with jid 20160414141800867893
-------------------------------------------

test-yum-10-59:
    True
[root@test-saltstack-10-63 salt]# salt-ssh '172.26.10.59' test.ping -v
[ERROR   ] Could not save load with returner mysql: MySQL returner could not connect to d
Executing job with jid 20160414141817681994
-------------------------------------------


[CRITICAL] MySQL returner could not connect to database: (1045, "Access denied for user '
[CRITICAL] Could not store return with MySQL returner. MySQL server unavailable.
172.26.10.59:
    True

######################################################################


MariaDB [salt]> select * from jids where jid='20160414141817681994';
Empty set (0.00 sec)

MariaDB [salt]> select * from jids where jid='20160414141800867893';
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| jid                  | load                                                                                                                                                                                                                            |
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 20160414141800867893 | {"tgt_type": "glob", "jid": "20160414141800867893", "cmd": "publish", "tgt": "test-yum-10-59", "kwargs": {"delimiter": ":", "show_timeout": true, "show_jid": false}, "ret": "", "user": "root", "arg": [], "fun": "test.ping"} |
+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Setup

master config:
...
mysql.host: '172.26.10.63'
mysql.user: 'salt'
mysql.pass: 'q1w2e3r4'
mysql.db: 'salt'
mysql.port: 3306
master_job_cache: mysql
...

Versions Report

Salt Version:
           Salt: 2015.8.8.2

Dependency Versions:
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
           Mako: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.7.0
         Python: 2.7.5 (default, Oct 11 2015, 17:47:16)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5
           cffi: Not Installed
       cherrypy: 3.2.2
       dateutil: 1.5
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
        libgit2: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: Not Installed
        timelib: Not Installed

System Versions:
           dist: redhat 7.2 Maipo
        machine: x86_64
        release: 3.10.0-327.13.1.el7.x86_64
         system: Red Hat Enterprise Linux Server 7.2 Maipo
Bug Confirmed Core Returners Salt-SSH phase-plan severity-medium status-to-do team-ssh

All 12 comments

@ivanwa, thanks for reporting.

Hrm, yes. So, this is actually a pretty big problem since I suspect that we're evaluating the returner opts on the remote side and the master opts on the local side. This means that we're going to see that a returner is in use in this case, but we'll use the wrong set of opts to figure out how it's set up.

cc: @thatch45

Thanks for the heads up on this one @cachedout, I know where to look

@thatch45 Nice!

@thatch45 Did you ever get back to this one?

Sorry, I never did get back to this

@cachedout @thatch45 Seems like this is a naming conflict where a keyword of salt-ssh overrides user of the MySQL returner. (I didn't have much time to dig into this.)

This – let's call it a workaround – "fixes" the issue. The main disadvantage is, that it breaks current configuration.

--- ./returners/mysql.py.orig   2017-02-23 00:32:57.628630209 +0100
+++ ./returners/mysql.py        2017-02-23 00:33:03.173848441 +0100
@@ -178,7 +178,7 @@
     Returns options used for the MySQL connection.
     '''
     defaults = {'host': 'salt',
-                'user': 'salt',
+                'dbuser': 'salt',
                 'pass': 'salt',
                 'db': 'salt',
                 'port': 3306,
@@ -187,7 +187,7 @@
                 'ssl_key': None}

     attrs = {'host': 'host',
-             'user': 'user',
+             'user': 'dbuser',
              'pass': 'pass',
              'db': 'db',
              'port': 'port',
# master.d/mysql.conf
master_job_cache: mysql
event_return: mysql

mysql.host: '192.168.255.1'
#mysql.user: 'salt-master'
mysql.dbuser: 'salt-master'
mysql.pass: 'mypassword'
mysql.db: 'salt'
mysql.port: 3306

I'm trying to use the openssh-formula with salt-ssh. "Fixing" this issue on the master I managed to run into #27808. :-)


Salt Version:
           Salt: 2016.11.2

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.5.3
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: 1.5.0
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: 1.4.4
       M2Crypto: 0.25.1
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.13 (default, Jan  3 2017, 01:35:50)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 16.0.2
           RAET: 0.6.5
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.4.2
            ZMQ: 4.1.5

System Versions:
           dist:
        machine: amd64
        release: 10.3-RELEASE-p11
         system: FreeBSD
        version: Not Installed

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.

This issue is still present sadly.
Can this be re-opened, please? @thatch45 @cachedout

The workaround proposed by @alxwr worked for me and while this is a breaking change (requiring a change in the master configuration) it's not too bad. Should I open a PR?

Thank you for updating this issue. It is no longer marked as stale.

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.

Thank you for updating this issue. It is no longer marked as stale.

Was this page helpful?
0 / 5 - 0 ratings