I have a host with standalone minion configured. It has all the required configurations in /srv/salt. Executing it using salt-call, and it works as expected. Now I wanted have a master to have control over this minion.
So I have created a salt master in one another host, and updated the /etc/salt/minion configuration file in the minion host to connect to master.Then restarted the minion and accepted key in server.
Now I could do some basic checks like salt 'minion-host' test.ping . But salt 'minion-host' state.highstate is failing with minion not responding. I could I execute the minion with its configuration from the master.
What is the proper way to execute the salt-call over minion, using the available minion configurations inside minion host.
If salt minion test.ping works that's a good start, you could also use:
salt-run manage.up
That should give a list of minions currently up.
Keep in mind that the minion needs to run the salt agent (https://docs.saltstack.com/en/getstarted/system/communication.html)
Test with this:
salt minion state.highstate test=True
Or get a more verbose output using:
salt minion state.highstate -l debug
Related
I have a puppet-master puppet agent setup in AWS VPC. The system has been running for the last 2 years without too many issues, but today the master will not accept a certificate request from any of the agents once they are launched saying "Could not resolve x.x.x.x: no name for x.x.x.x"
The puppet master is specified in the puppet.conf for the agent. I can see in the logs for the master that the agent does in face reach, but the master "rejects" and does not sign a certificate from an instance in a subnet which it usually accepts. Ive also tried to remove the certs from the master running "puppet cert clean ip-x-x-x-x.ap-in..." and re trying manually from the agent. The agent tries to connect and then says "Exiting;no certificate found and waitforcert is disabled"
Being on ec2, I presume is Linux.
Stop puppet service:
systemctl stop puppet pxp-agent (on systemd OS-es) or
service puppet stop (on init.d OS-es)
Remove /etc/puppetlabs/puppet/ssl
Run puppet agent -t --debug manual. In this case the ssl directory should be created. You shouldn't be getting any errors (due to connectivity)
Start puppet service:
systemctl start puppet pxp-agent (on systemd OS-es) or
service puppet start (on init.d OS-es)
Run puppet agent -t also on the master(s), as you may want to check that your certs are Ok on the Primary Master (CA) (and/or Compile Masters)
I know that there is Blackout mode for salt-minions (https://docs.saltstack.com/en/latest/topics/blackout/index.html) but it is configured on a master side. My need is to configure minion to do not run any commands (I mean any commands like salt '*' test.ping or salt '*' file.mkdir "/tmp/foobar") from a salt-master and only allow to run salt '*' state.apply with local state files.
Is it possible?
While I discover the codebase of Salt I found that there is solution for my issue there in upstream. I found that they added minion_blackout config to grains not only to pillar, so now I can configure that on my minion and allow only state.apply in minion_blackout_whitelist config.
I'm trying to test salt-cloud with vmWare/vCenter and all is really good so far. However it appears the minion is not being installed on the VM. I have been digging around and the only settings I find are
http://salt-cloud.readthedocs.io/en/latest/topics/windows.html
my-softlayer:
provider: softlayer
user: MYUSER1138
apikey: 'e3b68aa711e6deadc62d5b76355674beef7cc3116062ddbacafe5f7e465bfdc9'
minion:
master: saltmaster.example.com
**win_installer: /root/Salt-Minion-0.17.0-AMD64-Setup.exe
win_username: Administrator
win_password: letmein**
Does this mean, I need to have the windows installer in /root for salt-cloud to run? I thought setting deploy: True would do the install. Below is my config. my vlan is using dhcp, so I am getting a good IP and all.
cloud.profile.d/test.conf
windows-test:
provider: vcenter
clonefrom: 'Win2K12'
num_cpus: 1
memory: 2GB
devices:
network:
Network adapter 1:
name: vlan
adapter_type: vmxnet3
switch_type: distributed
cluster: cluster
datastore: datastore
folder: 'OS Testing'
power_on: True
deploy: True
customization: False
win_username: Administrator
win_password: password
minion:
master: salt
EDIT
I do have to specify the installer location. That seems to work. The problem now is trying to get pywinrm/Windows Remote Management to work. For some reason salt-cloud is trying to connect on 5986, but looking at the VM I see WRM is listening on 5985. So I'm wondering if it's a pywinrm setting now???
I have a minion with id app1. It has the following grains as reported locally via salt-call -g and which are corroborated by its minion file:
id: app1
datacenter: dc1
master: saltmaster1
prototypes: application
...
where datacenter and prototypes are custom grains.
From saltmaster1, I run salt 'app1' cmd.run "echo 'yo' | wall" to make sure that I am talking to the correct minion and I see the wall message on app1. I then test that I can ping app1 and that it will respond salt 'app1' test.ping and it responds True. Now I run salt 'app1' grains.items from saltmaster1 and it displays the following values:
id: app1
master: saltmaster1
prototypes: application
...
The datacenter grain is missing! Why?
I restarted the salt-minion service and waited a few minutes.
I am trying to access salt master from salt-minion. But, I am unable to get the keys on salt-master.
On my VM, I installed salt-master and on my Windows, I installed salt-minion. I have given master IP address on my minion vi salt\conf\minion
master: master ip address
I tried to run the command below:
c:\salt\salt-minion.exe -l debug -c c:\salt\conf
I am getting a message like below:
[DEBUG ] Reading configuration from c:\salt\conf\minion
[INFO ] Using cached minion ID from c:\salt\conf\minion_id: HoroppaLabs
[DEBUG ] Configuration file path: c:\salt\conf\minion
[INFO ] Setting up the Salt Minion "HoroppaLabs"
[DEBUG ] Created pidfile: c:\salt\var\run\salt-minion.pid
[DEBUG ] Reading configuration from c:\salt\conf\minion
[DEBUG ] Attempting to authenticate with the Salt Master at 172.31.16.131
[DEBUG ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem
[DEBUG ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem
[WARNING ] SaltReqTimeoutError: Waited 60 seconds
[INFO ] Waiting for minion key to be accepted by the master.
[DEBUG ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem
[WARNING ] SaltReqTimeoutError: Waited 60 seconds
[INFO ] Waiting for minion key to be accepted by the master.
[DEBUG ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem
I didn't get anything else, just the above.
On master, I tried to run the below command
sudo salt-key -L
Accepted Keys:
Unaccepted Keys:
Rejected Keys:
I didn't get any keys on master to accept
Can any one help, how can I communicate with salt-master?
This could be due to default incoming port on master (4505 and 4506) for salt communication are blocked
Since minions connect to masters, the only firewall configuration that must be done is on the master. By default master must be able to accept incoming connection on port 4505 and 4506
If your master is on centos or RHEL try below command to add ports to your firewall settings
1. firewall-cmd --get-active-zones
It will say either public, dmz, or something else.
You should only apply to the zones required.
firewall-cmd --permanent --zone= --add-port=4505-4506/tcp
firewall-cmd --reload (to open port 4505 and 4506)
You need to add your salt minion to your master. To do that run following command on you master:
salt-key -A <your_minions_hostname_or_ip>
For example in my case I did
salt-key -A virtual#192.168.56.101
For reference have a look here.