Salt: Salt SSH: Specifying a configuration directory in a local Saltfile fails.

[razed11]

Description of Issue/Question

Specifying a configuration directory in a local Saltfile does not appear to be honored.

Setup

I have a directory with the following files.

./Saltfile
./etc
./etc/salt
./etc/salt/master
./etc/salt/roster

Saltfile:

salt-ssh:
  config_dir: ./etc/salt # If I rename this to something that doesn't exist I get an error.

./etc/salt/master (Deltas from default file):

pki_dir: ./etc/salt/pki/master
cachedir: ./etc/salt/cache/salt/master
ssh_log_file: ./var/log/salt/ssh

Steps to Reproduce Issue

$ salt-ssh b0d5cc0d894a test.ping
No permissions to access "/var/log/salt/ssh", are you running as the correct user?

$ salt-ssh b0d5cc0d894a test.ping --log-file ./junk.log
.
.
.
IOError: [Errno 13] Permission denied: '/etc/salt/cache/salt/master/roots/mtime_map'

Versions Report

Salt Version:
           Salt: 2016.11.4

Dependency Versions:
           cffi: 1.9.1
       cherrypy: Not Installed
       dateutil: 2.6.0
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.9.6
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: 2.17
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 |Continuum Analytics, Inc.| (default, Dec 20 2016, 23:05:08)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.1
            ZMQ: 4.1.6

System Versions:
           dist:   
        machine: x86_64
        release: 16.5.0
         system: Darwin
        version: 10.12.4 x86_64

[razed11]

Changing this appears to solve the problem:

root_dir: ./

Perhaps improve the docs:

https://docs.saltstack.com/en/latest/topics/ssh/#running-salt-ssh-as-non-root-user

I have to say that I've been working with Salt for about three weeks now and it has been a grind. I can see the value in the technology and probably accept that it is the best tool for the job but I am not walking around singing its praises because of how difficult it has been to make things work. I think it is mainly the documentation. It's just not presented well and it makes the early learning very difficult and leads to very long and frustrating debug cycles. Seriously: Honest feedback. Not meant to offend. Definitely appreciate that a bunch of people in Utah are building a tool for the world to use.

I understand that I could contribute here but I simply don't have the bandwidth or breadth of knowledge.

[gtmanfred]

Thanks for the feed back!

Yup, if you do find the time, we would appreciate it.

But I am going to make this as a documentation issue, and we will get it added as a good to know for salt-ssh!

Thanks,
Daniel

[cachedout]

Hi @razed11

Thanks for the feedback. If you find specific cases where things are confusing, please feel free to file them as GitHub issues so we can improve in those areas. It's a little hard to know what to do with just a general comment about the documentation but with specifics, we can all work together to improve. :] Thanks.

[razed11]

OK. I will at least submit issues on things that can be clarified or things that I found confusing in the documentation.

In this case I think clarifying the 'root_dir' configuration variable. Maybe some details on how Salt uses the file system for caching and where keys are stored etc (it could be a separate theory of operations that Salt-SSH as non-root can point to).

The other thing that could use a paragraph would be a description of how Salt interprets the relative paths. I think it is relative to where salt-ssh is issued. But you can see that it might get confusing--is it relative to the configuration file or Saltfile etc.

In the end I was able to define a SLS that upgraded my minion and reassigned it's master. So I salt-ssh to upgrade the minion then jump to my ZeroMQ master and the key is happily waiting to be accepted. This was some work but very satisfying and allowed me to eliminate a separate Python-based SSH tool.

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