Installed salt-minions using saltstack cookbook and different versions of this cookbook been used while installing as minions got connected at different times. Now, would like to know what minion is using what version of the cookbook so is there a way to find from salt-master ?
If you mean you want to know the versions of the minions you are running:
salt-run manage.versions
In Jinja there is an execution module:
{{ salt["test.version"]() }}
Or on the command line:
salt-call --version
You can retrieve the salt version using grains.fetch like this:
salt '*' grains.fetch saltversion
Source: https://docs.saltstack.com/en/latest/topics/grains/
Related
I am wondering for for both GitFS file systems and GIT Pillar, where are those files checked out? I don't seem to be able to locate them on my system.
My issue might be related to this: Salt External Pillar Issues
/var/cache/salt/master/gitfs and /var/cache/salt/master/git_pillar
When I use saltstack to manage my servers. I found an interesting thing:
When I run salt '*' pkg.installed httpd, I get the following message: pkg.installed is not available. But I can use pkg.installed function in my .sls files and it worked very well. So, I am confused about that. And I think this is happening because of saltstack.
Who can help me?
There are two related but different concepts here.
Salt Execution Modules
Salt State Modules.
Execution modules are where most of the work actually happens and is what you are running on the command line, generally. For example:
salt '*' pkg.install vim
That will call out directly to your OS's package manager, such as yum or apt, and install vim.
State modules are statefull commands that kind of sit "above" the execution modules. A state module will check if the desired result already exists and make any necessary changes to get the desired state. They are conjugated differently than the execution modules. For example in this salt state file (sls file):
cat /srv/salt/vim.sls
install_vim_please:
pkg.installed:
- name: vim
Then you could run the state.sls execution module to apply this sls file with the pkg.installed state.
salt '*' state.sls vim
Because we're using the pkg.installed state Salt will check with your OS's package manager and see if vim is already installed. Salt will only attempt to install vim if the package manager says that vim is not installed already.
Keeping your Salt States in sls files makes it easy to keep them in git or whatever vcs you use to track them.
You could skip the sls file and run the command statefully from the command line like this:
salt '*' state.single pkg.installed name=vim
As far as the documentation goes, if one would like to query for available execution modules, the following command should be used:
salt '<minion_name>' sys.list_modules
My question is,
- whether it possible to run the above without a minion?
(e.g salt sys.list_modules , isn't it cleaner?)
If you just want to know all the modules available to you, or the latest modules available for the current saltstack version.
salt-call --local sys.list_modules
Saltstack documentation is very difficult and unclear for beginner. If you could give simple example how to install something on vagrant machine using saltstack I'd be very grateful
I believe some tutorials are out on the web. I could offer some of mine:
Setup Zabbix using Salt in a masterless setup, this installs among others a PHP stack needed for Zabbix.
Setup Consul in the cloud at DigitalOcean, with Saltstack. Includes a full script, but also works with Vagrant (see cheatsheet.adoc)
I think the biggest help for me when starting was the SaltStack tutorials.
https://docs.saltstack.com/en/getstarted/fundamentals/index.html
The states tutorial gives an example of installing rsync, lftp and curl:
https://docs.saltstack.com/en/getstarted/fundamentals/states.html
This tutorial shows how to setup what you need with vagrant with a master and a couple of minions, shows basics of targeting minions and setting up state files (the files that tell Salt what to do on a minion).
There is a lot more to Salt than that, but it is a good start.
In Saltstack there are two types of machines :
Master : As the name suggests this is the controlling. You can use this to run tasks on multiple minions.
Minion : Minions are like slaves. You can run commands on minions, or install any packages, run scripts on minions through master. Basically any command or any task that you can run by logging into a minion machine you should be able to accomplish through the master machine.
You can write all the tasks you want to perform on minion in an sls file and run it.
Saltstack has functions which you should call along with the desired arguments. Every function performs a specific task. Saltstack has Execution modules and States modules
Execution modules:
They are designed to perform tasks on a minion. For example: mysql.query will query a specified database. The execution module does not check if the database needs to be queried or not. It just executes its task.
Have a look at the complete list of modules and you will see that they will just execute a task for you. https://docs.saltstack.com/en/latest/ref/modules/all/index.html
States module:
It's called THE states module.
The states module is a module too. But it's a special one. With the states module you can create states (the sls files under /srv/salt ) for your Minions.
You could for example create a state that ensures the Minion has a web server configured for www.example.com.
After you have created your state you can apply it with the states module: salt state.apply example_webserver
The example_webserver state specifies what the Minion needs to have. If the Minion is already in the correct state, it does nothing. If the Minion is not in the correct state it will try to get there.
The states module can be found here: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.module.html
Sample sls file :
//This state is to make sure git is installed. If yes : no action will be taken if not it will be installed.
git_install:
pkg.installed:
- name: git
//This step makes sure the folder with the specified name is not present. If it is present it will be deleted. Here "delete_appname_old" is the step name and should not be duplicated in the same sls file
delete_appname_old:
file.absent:
- name: /home/user/folder_name
//This step is for cloning a git project
clone_project:
module.run:
- name: git.clone
- url: ssh://gitreposshclonelink
- cwd: /home/user/folder_name
- user: $username
- identity: $pathofsshkey
While bootstapping on AWS EMR - I am getting the following. Any clues how to resolve it?
/mnt/var/lib/bootstrap-actions/1/STAR: /lib/libc.so.6: version 'GLIBC_2.14' not found (required by /mnt/var/lib/bootstrap-actions/1/STAR)
It's probably caused by not having high enough version of libc6.
You can SSH into the EC2 instance the EMR job created by following this: Open an SSH Tunnel to the Master Node
Then update the packages, for example, if your instance uses ubuntu, you should do sudo apt-get update. The command depends on which distribution of linux you are creating on your ec2 instance. The default emr job uses Debian, and Amazon linux is built based on redhat.
See if this would work.
If this is actually the problem, you can add this update package command (with ignoring Y/N prompt) at the start of your bootstrap script.