Help - No minions matched the target.

2,712 views
Skip to first unread message

Pablo DC

unread,
Apr 28, 2013, 7:32:36 PM4/28/13
to salt-...@googlegroups.com
Hi all, I'm new in Salt stack.

I have a master server called cm-server and I have a minion server called zipcap-dev.

In cm-server I have this sls file deploy-zipcap.sls file placed into /srv/salt/

  git.latest:
    - rev: develop
    - target: /home/cloud/zipcap
    - force: true
    - order: 1

deploy-project:
  cmd.run:
    - name: cp -Rf /home/cloud/zipcap/* /var/www/html/zipcap/
    - stateful: true
    - order: 2

restore-config-file:
  cmd.run:
    - name: cp -r /home/cloud/for-salt/config.php /var/www/html/zipcap/
    - stateful: true
    - order: 3

upgrade-sql-script:
  cmd.run:
    - name: /home/cloud/for-salt/upgrade-sql.sh
    - stateful: true
    - order: 4


My top.sls file in /srv/salt

base:
  'zipcap-dev':
    - deploy-zipcap


When I run :
sudo salt 'zipcap-dev' test.ping
I get:
No minions matched the target. No command was sent, no jid was assigned.

Please, could any body help me in find out what I'm doing wrong?
Thanks a lot!



Szu-Han Chen

unread,
Apr 28, 2013, 7:40:30 PM4/28/13
to salt-...@googlegroups.com



On Sunday, April 28, 2013 at 7:32 PM, Pablo DC wrote:

> Hi all, I'm new in Salt stack.
>
> I have a master server called cm-server and I have a minion server called zipcap-dev.
>
> In cm-server I have this sls file deploy-zipcap.sls file placed into /srv/salt/
>
> https://user:pa...@bitbucket.org/path-to-my-project:
> git.latest:
> - rev: develop
> - target: /home/cloud/zipcap
> - force: true
> - order: 1
>
> deploy-project:
> cmd.run:
> - name: cp -Rf /home/cloud/zipcap/* /var/www/html/zipcap/
> - stateful: true
> - order: 2
>
> restore-config-file:
> cmd.run:
> - name: cp -r /home/cloud/for-salt/config.php /var/www/html/zipcap/
> - stateful: true
> - order: 3
>
> upgrade-sql-script:
> cmd.run:
> - name: /home/cloud/for-salt/upgrade-sql.sh (http://upgrade-sql.sh)
> - stateful: true
> - order: 4
>
>
>
> My top.sls file in /srv/salt
>
> base:
> 'zipcap-dev':
> - deploy-zipcap
>
>
>
> When I run :
> sudo salt 'zipcap-dev' test.ping
> I get:
> No minions matched the target. No command was sent, no jid was assigned.
>
> Please, could any body help me in find out what I'm doing wrong?
> Thanks a lot!
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com (mailto:salt-users+...@googlegroups.com).
> For more options, visit https://groups.google.com/groups/opt_out.
>
>


whats the output of `salt-key -L`? is zipcap-dev in that list?

--
Szu-Han Chen



Pablo DC

unread,
Apr 28, 2013, 9:41:20 PM4/28/13
to salt-...@googlegroups.com
First of all, thanks for reply!
I forgot change something related that, I just fixed it and now in cm-server:/etc/salt/pki/minion/ I have zipcap-dev.pem and zipcap-dev.pub.
Now I get:

root@cm-server:/etc/salt/pki/minion# salt-key -L
Accepted Keys:
cm-server.novalocal
zipcap-dev
Unaccepted Keys:
Rejected Keys:

But when I run
sudo salt 'zipcap-dev' test.ping
or
sudo salt 'zipcap-dev' state.sls deploy-zipcap

Nothing happens.
Any clue? It there any log I can check?

Thanks in advance!


On Sunday, April 28, 2013 8:32:36 PM UTC-3, Pablo DC wrote:
Hi all, I'm new in Salt stack.

I have a master server called cm-server and I have a minion server called zipcap-dev.

In cm-server I have this sls file deploy-zipcap.sls file placed into /srv/salt/

Message has been deleted

Pablo DC

unread,
Apr 28, 2013, 10:14:24 PM4/28/13
to salt-...@googlegroups.com
I just ran this:

root@cm-server:/etc/salt/pki/minion# sudo salt-call state.highstate -l debug
[INFO    ] Loaded configuration file: /etc/salt/minion
[DEBUG   ] loading grain in ['/var/cache/salt/minion/extmods/grains', '/usr/lib/pymodules/python2.7/salt/grains']
[DEBUG   ] Skipping /var/cache/salt/minion/extmods/grains, it is not a directory
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
Minion failed to authenticate with the master, has the minion key been accepted?

Does anybody know what does it mean?
Thanks!

Les Mikesell

unread,
Apr 29, 2013, 8:49:06 AM4/29/13
to salt-users
I think I've seen situations where re-installing salt-minion on a
minion would change the key so it doesn't work with the one of the
same name that you accepted on the master. Try deleting it with
salt-key -d and accepting the current one.

--
Les Mikesell
lesmi...@gmail.com

Pablo DC

unread,
Apr 29, 2013, 11:53:35 AM4/29/13
to salt-...@googlegroups.com
Les, thanks for reply.
I'll try with that.

About accepting the new key,
do I have to put the new one into cm-server:/etc/salt/pki/master/minions/ only? 
or also should I have to append the new key into cm-server:/etc/salt/pki/minion/minion.pem ?
Is there any other step that I have to do related to salt keys stuff ?

Thanks in advance!

Pablo.


David Boucha

unread,
Apr 29, 2013, 12:12:14 PM4/29/13
to salt users list
Pablo,

If you go through the walkthrough it will tell you how to accept the minion's keys.

sudo salt-key -a 'minion-name'

http://www.docs.saltstack.com/topics/tutorials/walkthrough.html#using-salt-key


--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Dave Boucha  |  Sr. Engineer


5272 South College Drive, Suite 301 | Murray, UT 84123

office 801-305-3563
da...@saltstack.com | www.saltstack.com

Les Mikesell

unread,
Apr 29, 2013, 12:38:46 PM4/29/13
to salt-users
You shouldn't need any of that, just:
salt-key -d zipcap-dev
then
salt-key -a zipcap-dev
or to accept all outstanding keys, 'salt-key -A'
In some circumstances you might have to restart the minion but I think
recent versions are pretty persistent about staying connected and
updating any new key. I'm not sure if there is any way to tell from
the server side that this has happened, though, other than the
connection not working any more.

--
Les Mikesell
lesmi...@gmail.com

Pablo DC

unread,
Apr 29, 2013, 7:49:01 PM4/29/13
to salt-...@googlegroups.com
Hi buds,
I performed these steps:

1) Shut down salt-minion service in zipcap-dev
2) In cm-server I deleted /etc/salt/pki/master/minions/zipcap-dev with salt-key -d and re-created it again with salt-key --gen-keys, then I ran salt-key -a zipcap-dev.
3) Starup salt-minion service in zipcap-dev
4) I got the same issue:
root@cm-server:/etc/salt/pki/minion# sudo salt-call state.highstate -l debug
[INFO    ] Loaded configuration file: /etc/salt/minion
[DEBUG   ] loading grain in ['/var/cache/salt/minion/extmods/grains', '/usr/lib/pymodules/python2.7/salt/grains']
[DEBUG   ] Skipping /var/cache/salt/minion/extmods/grains, it is not a directory
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
Minion failed to authenticate with the master, has the minion key been accepted?

I read

What does mean step 4)  Preseed the Minion with the keys ?
What I have to do with these files?:
/etc/salt/pki/minion/minion.pem
/etc/salt/pki/minion/minion.pub

Should I have to do something else with generated files zipcap-dev.pem and zipcap-dev.pub?

Thanks!

Mike Chesnut

unread,
Apr 29, 2013, 7:53:30 PM4/29/13
to salt-...@googlegroups.com
Yes, if you are pre-generating the keys on the master, you need to do something to make the minion use them.  Step 4 in that document is telling you to accomplish this by copying the key files to the minion.

I don't think key pre-seeding is necessary for your scenario, though.  I would try this:

1. stop salt-minion service on zipcap-dev
2. on cm-server do: salt-key -d zipcap-dev
3. start salt-minion service on zipcap-dev
4. accept key on cm-server: salt-key -a zipcap-dev




David Boucha

unread,
Apr 29, 2013, 9:30:03 PM4/29/13
to salt users list

Yes, Mike is correct. You probably don't need to manually generate the keys in this situation. When you start the minion it will auto generate its own keys. Once it contacts the master just run salt-key -L to see if it has connected and salt-key -a minionname on the master to accept the key

Pablo DC

unread,
Apr 30, 2013, 9:37:53 AM4/30/13
to salt-...@googlegroups.com
Hi all, thanks for your help.

How I can know that that zipcap-dev (minion) can contact cm-server (master) ?

On the other hand, when I run in cm-server
root@cm-server:/etc/salt/pki/minion# sudo salt-call state.highstate -l debug
[INFO    ] Loaded configuration file: /etc/salt/minion
[DEBUG   ] loading grain in ['/var/cache/salt/minion/extmods/grains', '/usr/lib/pymodules/python2.7/salt/grains']
[DEBUG   ] Skipping /var/cache/salt/minion/extmods/grains, it is not a directory
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
Minion failed to authenticate with the master, has the minion key been accepted?
why is loading /etc/salt/pki/minion/minion.pem from cm-server?
does not have to check the key that I generated for zipcap-dev which I left on /etc/salt/pki/master/minions/ ?

Thanks!

Les Mikesell

unread,
Apr 30, 2013, 11:01:32 AM4/30/13
to salt-users
On Tue, Apr 30, 2013 at 8:37 AM, Pablo DC <pabl...@gmail.com> wrote:
>
> How I can know that that zipcap-dev (minion) can contact cm-server (master)
> ?

Normally the minion generates its own key and sends to the master, so
the fact that you have a key to accept shows that the contact is
working. And once you accept it, test.ping (etc.) should work.

> On the other hand, when I run in cm-server
> root@cm-server:/etc/salt/pki/minion# sudo salt-call state.highstate -l debug
> [INFO ] Loaded configuration file: /etc/salt/minion
> [DEBUG ] loading grain in ['/var/cache/salt/minion/extmods/grains',
> '/usr/lib/pymodules/python2.7/salt/grains']
> [DEBUG ] Skipping /var/cache/salt/minion/extmods/grains, it is not a
> directory
> [DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
> Minion failed to authenticate with the master, has the minion key been
> accepted?
> why is loading /etc/salt/pki/minion/minion.pem from cm-server?
> does not have to check the key that I generated for zipcap-dev which I left
> on /etc/salt/pki/master/minions/ ?
>

I think your minion and server are using different keys. Is there
some reason you need to pre-generate the keys on the master?

--
Les Mikesell
lesmi...@gmail.com

Pablo DC

unread,
Apr 30, 2013, 11:34:20 AM4/30/13
to salt-...@googlegroups.com
Hi Les,
no,  there is not any reason, I only followed the advises that people told me in this group.
Current from cm-server (master) I run
salt 'zipcap-dev' test.ping
and I don't get any output result

>Normally the minion generates its own key and sends to the master, so 
>the fact that you have a key to accept shows that the contact is 
>working.  And once you accept it, test.ping (etc.) should work. 

So, if I remove in cm-server 
/etc/salt/pki/minion/minion.pem
/etc/salt/pki/minion/minion.pub

-Then I restart minion service in zipcap-dev, that should re-generate minion.pem and minion.pub in cm-sever?
-In what folder into cm-server (master), zipcap-dev (minion) generates its onw keys?
-Before to create and accept the key in master using
salt-key --gen-keys=zipcap-dev
I have to get the minion keys into master, right?


-when I run in cm-server
root@cm-server:/etc/salt/pki/minion# sudo salt-call state.highstate -l debug
[INFO    ] Loaded configuration file: /etc/salt/minion
[DEBUG   ] loading grain in ['/var/cache/salt/minion/extmods/grains', '/usr/lib/pymodules/python2.7/salt/grains']
[DEBUG   ] Skipping /var/cache/salt/minion/extmods/grains, it is not a directory
[DEBUG   ] Loaded minion key: /etc/salt/pki/minion/minion.pem
Minion failed to authenticate with the master, has the minion key been accepted?
do you know why is loading /etc/salt/pki/minion/minion.pem from cm-server?
is it correct that salt master try to load minion key from that path?




Les Mikesell

unread,
Apr 30, 2013, 11:45:07 AM4/30/13
to salt-users
On Tue, Apr 30, 2013 at 10:34 AM, Pablo DC <pabl...@gmail.com> wrote:
>
> -Before to create and accept the key in master using
> salt-key --gen-keys=zipcap-dev
> I have to get the minion keys into master, right?

Why are you using -gen-keys in the first place? The minion will
generate its own key and send it, and all you have to do is salt-key
-a (or -A) to accept it. If you manually generate a key then it is
up to you to get a copy in the right place on the minion before
starting it or they won't match.

--
Les Mikesell
lesmi...@gmail.com

Pablo DC

unread,
Apr 30, 2013, 2:06:43 PM4/30/13
to salt-...@googlegroups.com
In what path minion generates its own keys?
And in what path into master server, minion should copy those keys to master server?

Thanks.

Les Mikesell

unread,
Apr 30, 2013, 5:48:02 PM4/30/13
to salt-users
On Tue, Apr 30, 2013 at 1:06 PM, Pablo DC <pabl...@gmail.com> wrote:
> In what path minion generates its own keys?

You can probably change it in the config, but mine are in /etc/salt/pki/minion/.

> And in what path into master server, minion should copy those keys to master
> server?

They should automatically land in /etc/salt/pki/master/minions_pre/
(filename is the minion name) until you accept them with salt-key -a
or -A. Then they move under /etc/salt/pki/master/minions. But
normally you shouldn't need to know anything about them.

--
Les Mikesell
lesmi...@gmail.com
Reply all
Reply to author
Forward
0 new messages