22

I am a total beginner with SaltStack but I have managed to setup some states on a machine and run them on a minion.

What I have right now is a Debian machine setup with salt-master as well as another Debian setup as salt-minion.

Since I am using the salt-master also as a development machine, I would like to know if I can somehow apply the states on the master itself as well. And if so, how?

Is there a command I can run to apply the states on the master? (so far I was unable to find it)

Should I install salt-minion on the same machine as well to be able to do this and simply register the same machine as a minion on itself?

Thanks!

Adam Michalik
  • 9,678
  • 13
  • 71
  • 102
austrum
  • 223
  • 1
  • 2
  • 6

3 Answers3

22

Since I am using the salt-master also as a development machine, I would like to know if I can somehow apply the states on the master itself as well. And if so, how?

You can do that by following the following steps:

  1. Install salt-minion on your development machine
  2. Edit /etc/salt/minion to point to your master (vi /etc/salt/minion and change the following : master: salt -> master: 127.0.0.1)
    • (optional) Edit /etc/salt/minion_id to something that is meaningful to you
  3. Start up your salt-minion
  4. Use salt-key to accept your minion's key
  5. Use your salt-master to control your minion as if it were any other salt-minion

Is there a command I can run to apply the states on the master?

The salt-master doesn't really run the the state files, the salt-minions do. If you followed the above steps then you can target your salt-master to run highstate with the following command:

salt 'the_value_of_/etc/salt/minion_id' state.highstate

Should I install salt-minion on the same machine as well to be able to do this and simply register the same machine as a minion on itself?

Yup. I think you have an idea as to what you need to do and just need a push in the right direction.

Richard Hansen
  • 51,690
  • 20
  • 90
  • 97
Jason Zhu
  • 2,194
  • 3
  • 23
  • 27
  • The numbering of you list is messed up. In the markup you have a "3.5" step, but that's incorrect markup. Also, I think 4, 5 , and 6 were meant to be one item, weren't they? Or maybe 5 and 6 are one item, but part of 5 got appended to 4. Can you fix it so that it reads like you intend it to read? – Bryan Oakley May 21 '14 at 23:00
  • Fixed. Thanks for the heads up @BryanOakley – Jason Zhu May 21 '14 at 23:52
  • Even this setup is in poor control. E.g. if you want to execute code between the highstate. salt.state.event + reactor + your execution code is the current way to do it. You can put a state.event inside highstate, give it a tag, while the reactor will check the tag and execute the reaction given. – mootmoot Apr 05 '16 at 12:52
  • If you have already installed the Master on your development machine, then installing the minion is not needed. But you have to restart the minion service/daemon after (~3.) – Mayra Delgado Mar 12 '21 at 09:01
  • Thanks for this answer. I am new to salt, too, and the question of whether to run minion on the master is quite straightforward but I had to do a surprising amount of searching to confirm. – bitofagoob May 23 '21 at 19:45
8

Install both Minion and Master on single node

I call such node Master Minion. No steps provided - you already know it based on the question.

Some conceptual info instead:

  • In short, Master never applies states. Instead, it triggers Minions (the local Master Minion in this case).
  • Salt Minion and Master are two separate services with independent runtime & configuration.
  • While instances use common software, runtime talk over the network (location-independent).
  • If you can apply states on remote Minion, the same mechanism will be used for local Minion one as well.

Additional info

There are two ways to apply states:

  • Master-side salt command to "push" states to multiple remote minions.

    rpm -qf $(which salt)
salt-master-2015.5.3-4.fc22.noarch

  • Minion-side salt-call command to "pull" states on single local minion.

    rpm -qf $(which salt-call)
salt-minion-2015.5.3-4.fc22.noarch

Until more than one minion is involved, it's better to use salt-call for the same effect:

salt-call state.highstate

Minion-side salt-call provides advantages especially for testing, isolation, troubleshooting:

  • It makes network issues (if any) more obvious.
  • It safely applies states only on single local minion (no way to specify more than one).

  • It shows debug output directly in the local terminal:

    salt-call -l debug test.ping

The last point, salt-call--local can also be used in masterless setup using no network.

uvsmtid
  • 4,187
  • 4
  • 38
  • 64
3

Now it's near end of 2015. Let's review some more possibilities to salt master self-control:

  1. Install a minion aside with salt master on the same box

This one has been widely discussed as above two answers.

  1. Use salt-ssh + salt-run state.orchestrate

Setup steps:

Step 1: install salt-ssh

Step 2: modify roster file (e.g. /etc/salt/roster in CentOS 6). The default installation already provide you some example. Since you probably ssh into salt master, of course username / password / private key setup should not be a problem for you. For example to control salt master vagrant box, this sample should do:

localhost:
  host: 127.0.0.1
  user: vagrant
  passwd: vagrant
  sudo: True

Now, steal from official tutorial with a little bit twist:

# /srv/salt/orch/cleanfoo.sls
cmd.run:
  salt.function:
    - tgt: 'localhost'
    - ssh: 'true'
    - arg:
      - touch /tmp/test.txt

And run it with:

salt-run state.orchestrate orch.cleanfoo

Check your salt master vagrant box /tmp directory if test.txt file is there.

This approach should also work for state. Either way you need to install something. I prefer the second way since in general, calling salt master self control (to provision some work) is just a step before I actually call minion to process other state(s).

Ming Hsieh
  • 713
  • 2
  • 8
  • 29