Salt: Allow run salt-ssh without root

[slav0nic]

Why this is not allowed?
salt-ssh will be nice replacement for fabric

[basepi]

Are you wanting to run it as non-root on the "master" server or on the target servers?

[slav0nic]

on the master

[basepi]

Yes, we should definitely support this. Thanks for the request!

[vaijab]

I just hit the same issue. Anyone wants to implement this?

[jansauer]

:+1:
Seems to overlap #17063

[basepi]

I'm 90% sure this actually works. You just have to give salt-ssh a directory for keys and configuration that it can write to. Using salt-ssh with -c or giving access to /etc/salt to the user in question should allow this to work. Can anyone verify one way or another? If not I'll do some testing later.

[basepi]

Though I guess it would be inconvenient to have to configure a cachedir and whatnot as well that's accessible. I'll have to think on this.

I mean, let's assume we want to make configuring those directories easier. If we don't force you to configure each of those directories to be something where the user has write permissions, where can we safely assume you have write permissions? ~/.salt or something?

[anlutro]

To achieve this without any extra command-line arguments, you currently need two files. A Saltfile, located in the current working directory as you execute salt-ssh:

salt-ssh:
  config_dir: /path/to/salt/config

.. and a master config file inside config_dir:

root_dir: /path/to/salt
pki_dir: config/pki
cachedir: cache

pki_dir and cache_dir are optional, but if you leave them out, your PKI files get put in /path/to/salt/etc/salt/pki/master/ssh/, and your cache files are put in /path/to/salt/var/cache/salt/master/, both of which are way deeper in the directory tree than necessary.

I think if there was a standard location to look for the Saltfile, maybe ~/.Saltfile, and if pki_dir and cachedir are set as relative to root_dir if root_dir is set, that would make things more convenient.

Another annoyance is that you can't use ~ in a Saltfile or a master config. If you do, Salt will create a directory named ~ in the current working directory, as opposed to expanding to $HOME. You can use relative paths, though (root_dir: ./ will set root_dir to the current working directory, for example).

[babilen5]

It would probably make sense to use standard XDG directories (cf. [0]) such as $XDG_CONFIG_HOME, $XDG_CACHE_HOME, … (i.e. ~/.config/salt/, ~/.cache/salt/) and so on.

This would allow salt to behave in a predictable way that is obvious to users.

[0] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

[Linuturk]

I've done a search and there seem to be a large number of issues related to salt-ssh usability with non-root users. I'd like to understand more about the perceived use case from Salt's perspective and give some feedback.

Perceived use case

salt-ssh seems to be an answer to Ansible and Fabric where the ssh transport from a single laptop is useful for a system administrator to maintain a smaller set of infrastructure. My use case would be running from a virtualenv after pip installing salt-ssh. I would typically create a folder for a set of infrastructure and states. If I was executing the command from this directory I expect salt-ssh to look in this working directory for things like rosters and configuration files. The next place would be a folder ~/.salt-ssh folder in my home directory. I would expect cache directories to be automatically created in that location. The final location would be the system wide settings in /etc/salt.

Ideal workflow

The salt-ssh command should just work given the following actions on my part:

1. Create a virtualenv and pip install salt-ssh
2. Activate the virtualenv
3. Make and change into a working directory.
4. Create a roster file with the hosts I want to manage.
5. A command like salt-ssh "*" test.ping should work without any further configurations assuming ssh keys are in place. (which brings me to my next point.)

SSH Configuration

Another expectation on my part was that salt-ssh would make use of my existing ~/.ssh/config configuration to connect to the various hosts in my roster. That includes pre-existing ssh keys, SSH proxy through a configured bastion, usernames, ports, and other settings allowed in this configuration file.

The auto creation of an ssh key is admirable for someone that hasn't used keys before but re-keying all my servers would be annoying. salt-ssh should try to detect existing keys in their default locations and only offer to generate one if it can't find a key.

Saltfile

This line from the documentation concerns me as well:

The option keys specified must match the destination attributes for the options specified in the parser salt.utils.parsers.SaltSSHOptionParser.

At the very least the documentation should link or document the config file parameters so we don't have to dig through the code to find them.

The options specified should either:

1. Be fully documented in the code,
2. Match the command line parameters, or
3. Document the alternative names in the help text of salt-ssh -h.

Ultimately...

the goal is to make it as easy as possible for me to go from 0 to salt-ssh with the smallest amount of pain possible. A confusing use case, complicated installation and configuration, ignoring existing SSH configurations, and undocumented options in Saltfile make this unnecessarily complicated.

Another Use Case

If the goal of salt-ssh is to simply be an alternative transport for the existing use case of the salt command then my points are invalid. If we want to give users an easier introduction into SaltStack and lower the barrier to entry I think these changes are valid and necessary.

Thanks for taking the time to read about my experiences trying to use salt-ssh for the first time!

[basepi]

salt-ssh was created to be an alternate transport option for saltstack, for those who were concerned with running an "agent" (a bad word in some circles) on all their target machines.

That said, we've actually been discussing ideas for how to make salt-ssh better, and decoupling it from some of the core salt cruft that it doesn't need is one of those ideas. I do think we could make salt-ssh much faster and easier to use, and I very much appreciate your suggestions and point of view. I think you're dead on from a usability standpoint.

[babilen5]

@Linuturk Spot on, but why would you prefer ~/.salt-ssh over a XDG compliant scheme as detailed earlier?

[Linuturk]

It has always made more sense to me to have each app's configurations under the same folder. I don't see the value of splitting into .config, .cache, etc. I'm not too hung up on that part though.

[razed11]

Any progress on this? I have a few hundred embedded linux systems that are running the minion and am unsatisfied with the techniques to upgrade the salt-minion service and change the master IP address. I am also unsatisfied with Fabric. salt-ssh looks promising even if it still works as described in this thread. Just curious if management of the writeable directories has improved.

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

[youk]

I see no reason for closing the issue as it is still relevant.

[stale[bot]]

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