I have essentially a barebones saltstack "cluster" running. In fact, it's actually a master and a minion on the same host machine.
This is really a 2 part question.
1) The salt-master takes a really long time to boot. Like 2+ minutes. The debug logs look like it's got several threads going in a loop loading/reloading configs:
[DEBUG ] Reading configuration from /etc/salt/minion.d/master.conf
[DEBUG ] Reading configuration from /etc/salt/minion.d/master.conf
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: host.my.domain
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: host.my.domain
[DEBUG ] Reading configuration from /etc/salt/master
[DEBUG ] Reading configuration from /etc/salt/master
[DEBUG ] Including configuration from '/etc/salt/minion.d/master.conf'
[DEBUG ] Reading configuration from /etc/salt/minion.d/master.conf
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: host.my.domain
[DEBUG ] Reading configuration from /etc/salt/master
[DEBUG ] Including configuration from '/etc/salt/minion.d/master.conf'
[DEBUG ] Reading configuration from /etc/salt/minion.d/master.conf
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: host.my.domain
[DEBUG ] Including configuration from '/etc/salt/minion.d/master.conf'
[DEBUG ] Reading configuration from /etc/salt/minion.d/master.conf
[DEBUG ] Reading configuration from /etc/salt/master
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: host.my.domain
[DEBUG ] Reading configuration from /etc/salt/master
[DEBUG ] LazyLoaded local_cache.clean_old_jobs
[DEBUG ] This salt-master instance has accepted 1 minion keys.
[DEBUG ] The `dmidecode` binary is not available on the system. GPU grains will not be available.
[DEBUG ] The `dmidecode` binary is not available on the system. GPU grains will not be available.
[DEBUG ] The `dmidecode` binary is not available on the system. GPU grains will not be available.
[DEBUG ] The `dmidecode` binary is not available on the system. GPU grains will not be available.
[DEBUG ] The `dmidecode` binary is not available on the system. GPU grains will not be available.
[DEBUG ] MasterEvent PUB socket URI: ipc:///var/run/salt/master/master_event_pub.ipc
[DEBUG ] MasterEvent PULL socket URI: ipc:///var/run/salt/master/master_event_pull.ipc
[DEBUG ] MasterEvent PUB socket URI: ipc:///var/run/salt/master/master_event_pub.ipc
[DEBUG ] MasterEvent PULL socket URI: ipc:///var/run/salt/master/master_event_pull.ipc
[DEBUG ] MasterEvent PUB socket URI: ipc:///var/run/salt/master/master_event_pub.ipc
[DEBUG ] MasterEvent PULL socket URI: ipc:///var/run/salt/master/master_event_pull.ipc
And 2) Once it finally finishes and I can auth the minion to it, just a simple test.ping is taking 30+ seconds:
time salt '*' test.ping
real 0m34.556s
user 0m12.230s
sys 0m0.500s
From the minion debug logs:
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
This is essentially an out of the box setup with not states or anything setup. Can anyone help me address these performance issues?
Running Arch Linux on a raspberry pi, installed via the official arch repo(https://www.archlinux.org/packages/community/any/salt-zmq/), version 7.2014. These are the logs from running it manually in debug mode. There is no specific pause, it just runs in what appears to be several loops for a few minutes spewing out the above(among other things, but all generally related to loading configuration files) until it finally settles down
If you are running the master and minion on Raspberry Pi's - that would be your problem.
I'm on real hardware for my salt master and salt minions - I get results from the test.ping module in seconds.
The master starts up in seconds as well.
Related
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
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 have installed Saltsatck(salt-master) on my virtual machine and also installed Proxmox(Cloud) on another virtual machine.
They both are on same network.
Salt-master and proxmox are running successfully.
Whenever I run the below command :-
# salt-cloud -p my-proxmox-config mytest
I get the following output :-
[INFO ] salt-cloud starting
[INFO ] Starting new HTTPS connection (1): 192.168.2.245
[INFO ] Creating Cloud VM mytest
[ERROR ] Error creating mytest on PROXMOX
The following exception was thrown when trying to run the initial deployment:
Error: There was a profile error: Failed to deploy VM
Please look at the below config files :-
1. /etc/salt/cloud.providers.d/proxmox.conf
proxmox-config:
user: root#pam or root#pve
password: oodles
url: 192.168.2.245
driver: proxmox
verify_ssl: False
minion:
master: 192.168.2.228
2. /etc/salt/cloud.profiles.d/proxmox.conf
my-proxmox-config :
provider: proxmox-config
image: /root/ISO/ubuntu-14.04-server-amd64.iso
technology: kvm / Openvz
host: cloud
ip_address: 192.168.2.245
ssh_username: root
password: oodles
cpus: 1
memory: 512
swap: 512
disk: 2
nameserver: 8.8.8.8 8.8.4.4
Please suggest/advice me what to correct from my configurations file .
Thanks
The error you're getting is saying that something is wrong with your profile config. We just need to troubleshoot what's going on with it.
I haven't used the proxmox provider, but according to https://docs.saltstack.com/en/latest/topics/cloud/proxmox.html it looks like for the image option you might have to use local:/root/ISO/ubuntu-14.04-server-amd64.iso.
Also, have you tried just technology: openvz?
I am able to solve the above issue i.e. now I am able to launch a VM/instance in proxmox from salt-master by doing the below configurations :-
1. /etc/salt/cloud.providers.d/proxmox.conf
proxmox-config:
minion:
master_type: standard
master: '192.x.x.x'
user: 'root#pam'
password: "your password"
url: '192.168.x.x'
port: '8006'
driver: proxmox
verify_ssl: False
2. /etc/salt/cloud.profiles.d/proxmox.conf
my-proxmox-config :
provider: proxmox-config
image: local:vztmpl/ubuntu-12.04-standard_12.04-1_i386.tar.gz
technology: openvz
host: cloud
ip_address: 192.168.x.x
ssh_username: root
password: "your password"
cpus: 1
memory: 512
swap: 512
disk: 2
nameserver: 8.8.8.8 8.8.4.4
In the above file, the image option will only work if you have downloaded the desired operating ISO in templates option available in PROXMOX GUI.
Now , you can easily launch a Instance by using below command :-
# salt-cloud -p my-proxmox-config mytest
Thanks
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.