Linux – How to get salt-ssh to run a local script on a remote node

linuxsaltstack

.::UPDATE-SOLVED::.

With must assistance form @wirap, it is now working. I've symlinked the script directory into /etc/salt/states/scripts and using this test.sls configuration it is now working.

/root/bin/updater/scripts/pam-setup-access:
    file.managed:
      - name: /tmp/pam-setup-access
      - source: salt://scripts/pam-setup-access
      - mode: 0700
run_script:
   cmd.run:
      - name: /tmp/pam-setup-access
   file.absent:
      - name: /tmp/pam-setup-access

I am new to salt-ssh and looking at some info here regarding how to run a script which resides on my admin box (/root/bin/updater/scripts/pam-setup-access) on a remote node that I have root access too.

I've created a state file (below) but not sure where to place it. The salt-ssh docs only mention /etc/salt/master so I looked that up but those docs seem to be specific for vagrant and package installation.

add script:
    file.managed:
    - name: pam-setup-access
    - source: /root/bin/updater/scripts/pam-setup-access

run script:
    cmd.run:
    - name: pam-setup-access

Lastly, I tried simply running the state file from the current directory as shown in the first link but I've only annoyed it. What am I missing?

# salt-ssh '*' state.apply test.sls 
nod0:
    [CRITICAL] Unable to import msgpack or msgpack_pure python modules
    Function state.apply is not available

nod1:
    [CRITICAL] Unable to import msgpack or msgpack_pure python modules
    Function state.apply is not available

.:: UPDATE ::.

I need to use salt-ssh as several "minions" reside on a network separate from the master (DMZ). As I understand, the traditional salt setup requires minions to connect to the salt master.

Since posting, I've installed salt-ssh from the saltstack repo which seems to have gotten rid of the msgpack error above. I've also modified some of the examples from the vagrant specific link above, adding a master file and states directory under /etc/salt. I've placed the state file (above) under /etc/salt/states/test.sls. Results are below.

I've added underscores between add script and run script, as suggested by @wirap. This has gotten me further as shown below. It seems there is some error involving the script path on the client, or server. Not sure yet. It seems I need to call state.apply with the name of the .sls file only (without the .sls extension).

/etc/salt/master:

file_roots:
   base:
      - /etc/salt/states

When I launch salt-ssh now, I get:

# salt-ssh '*' state.apply test
nod0:
----------
          ID: add_script
    Function: file.managed
        Name: pam-setup-access
      Result: False
     Comment: Specified file pam-setup-access is not an absolute path
     Started: 11:53:50.237379
    Duration: 0.602 ms
     Changes:   
----------
          ID: run_script
    Function: cmd.run
        Name: pam-setup-access
      Result: False
     Comment: Command "pam-setup-access" run
     Started: 11:53:50.238629
    Duration: 8.297 ms
     Changes:   
              ----------
              pid:
                  1037
              retcode:
                  127
              stderr:
                  /bin/bash: pam-setup-access: command not found
              stdout:

Summary for nod0
------------
Succeeded: 0 (changed=1)
Failed:    2
------------
Total states run:     2
Total run time:   8.899 ms
nod1:
----------
          ID: add_script
    Function: file.managed
        Name: pam-setup-access
      Result: False
     Comment: Specified file pam-setup-access is not an absolute path
     Started: 11:53:50.476743
    Duration: 0.555 ms
     Changes:   
----------
          ID: run_script
    Function: cmd.run
        Name: pam-setup-access
      Result: False
     Comment: Command "pam-setup-access" run
     Started: 11:53:50.477906
    Duration: 7.5 ms
     Changes:   
              ----------
              pid:
                  30772
              retcode:
                  127
              stderr:
                  /bin/bash: pam-setup-access: command not found
              stdout:

Summary for nod1
------------
Succeeded: 0 (changed=1)
Failed:    2
------------
Total states run:     2
Total run time:   8.055 ms

Best Answer

Are you sure you want to use salt-ssh ("Execute salt commands and states over ssh without installing a salt-minion."). You only need to do it this way if you cannot install salt-minion on your minions
Where did you put your states? Typically in the /etc/salt/master configuration you write the path where your state files should be
Do not use the state supplied in the example verbatim. I'm pretty sure you can't have a space in the id declaration (add script:).
Your error message is unknown to me. This thread here makes the following suggestion: "The msgpack error is very misleading, as it is entirely unrelated. It seems one of your server.conf files has invalid utf-8 on one minion and the file doesn't exist on the other? " I strongly suspect, the space (' ') in your state id. In my experience, SaltStack can spit out quite misleading error messages if you have invalid characters in your state files or pillar.

Extra hints:

Look here for information about how to setup your state tree.
Maybe use a preinstalled installation of SaltStack (docker, Vagrant ?) that already works for learning how it works. Since UtahDave is pretty active in SaltStack, I would go with his demo (Disclaimer: Did not test this myself!)

Update: When you use file.managed:

the parameter source of file.managed is the path on your master (relative to your state path), not the target.
you need to specify the path on the target, that's why you're getting the error: "Specified file pam-setup-access is not an absolute path"

Example:

/root/bin/updater/scripts/pam-setup-access
   file.managed:
     - source: salt://files/pam-setup-access

is the same as:

some-arbitrary-id
    file.managed:
    - name: /root/bin/updater/scripts/pam-setup-access
    - source: salt://files/pam-setup-access

https://docs.saltstack.com/en/develop/ref/states/all/salt.states.file.html#module-salt.states.file

The same goes for cmd.run.

Read the general SaltStack tutorial. When you design states it does not matter if you use salt-ssh or salt. Don't let this confuse you.

Related Solutions

Debian – Running Stable and Installing Packages from Testing

Many people seem to be afraid of mixing stable with testing, but frankly, testing is fairly stable in its own right, and with proper preferences and solution checking, you can avoid the "stability drift" that puts your core packages on the unstable path.

"Testing is fairly stable??", you ask. Yes. In order for a package to migrate from unstable to testing, it has to have zero open bugs for 10 consecutive days. Chances are that, especially for the more popular packages, somebody is going to submit a bug report for an unstable version if something is wrong.

Even if you don't want to mix the environments, it's still nice to have the option there in case you run into something that requires a newer version than what is in stable.

Here's what I recommend for setting this up:

First, create the following files in /etc/apt/preferences.d:

stable.pref:

# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent

Package: *
Pin: release a=stable
Pin-Priority: 900

testing.pref:

# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent

Package: *
Pin: release a=testing
Pin-Priority: 400

unstable.pref:

# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=unstable
Pin-Priority: 50

experimental.pref:

# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=experimental
Pin-Priority: 1

(Don't be afraid of the unstable/experimental stuff here. The priorities are low enough that it's never going to automatically install any of that stuff. Even the testing branch will behave, as it's only going to install the packages you want to be in testing.)

Now, creating a matching set for /etc/apt/sources.list.d:

stable.list: Copy from your original /etc/apt/sources.list. Rename the old file to something like sources.list.orig.

testing.list: Same as stable.list, except with testing.

unstable.list: Same as stable.list, except with unstable, and remove the security lists.

experimental.list: Same as unstable.list, except with experimental.

You can also add a oldstable in sources.lists.d and preferences.d (use a priority of 1), though this moniker will tend to expire and disappear before the next stable cycle. In cases like that, you can use http://archive.debian.org/debian/ and "hardcode" the Debian version (etch, lenny, etc.).

To install the testing version of a package, simply use aptitude install lib-foobar-package/testing, or just jump into aptitude's GUI and select the version inside of the package details (hit enter on the package you're looking at).

If you get complaints of package conflicts, look at the solutions first. In most cases, the first one is going to be "don't install this version". Learn to use the per-package accept/reject resolver choices. For example, if you're installing foobar-package/testing, and the first solution is "don't install foobar-package/testing", then mark that choice as rejected, and the other solutions will never veer to that path again. In cases like these, you'll probably have to install a few other testing packages.

If it's getting too hairy (like it's trying to upgrade libc or the kernel or some other huge core system), then you can either reject those upgrade paths or just back out of the initial upgrade altogether. Remember that it's only going to upgrade stuff to testing/unstable if you allow it to.

EDIT: Fixed some priority pins, and updated the list.

Linux – How to execute with /bin/false shell

Use the DenyUsers or DenyGroups settings in sshd_config.

Best Answer

Related Solutions

Debian – Running Stable and Installing Packages from Testing

Linux – How to execute with /bin/false shell

Related Topic