Salt: Call Execution Module passing parameter value from Pillar data - salt-stack

I would like to execute a Salt Execution Module, let's say 'svn.update'.
I would prefer not to pass the SVN username and password in the command line. That data is already stored in Pillar data available to the target minions.
How can I tell the execution module to get the values for those parameters from the minion's Pillar data?
Something kind of like this (which of course doesn't work):
$ sudo salt minionid svn.update cwd=/path/to/sandbox username='pillar.get svn:username' password='pillar.get svn:password'

You can do following from a state file to call execution module with pillars,
{% set svn_update = salt['svn'].update(cwd='/path/to/sandbox', username=pillar['svn']['username'], password=pillar['svn']['password'] %}

Related

How can I use salt-mine when using salt-ssh

I have a saltstack state which requires accessing the salt mine for it to execute correctly. This has been working fine, but we have recently switched to using salt-ssh and it is producing the following error
TypeError encountered executing example_token: 'FunctionWrapper' object is not callable
This mine function is set up in my pillar as follows
mine_functions:
example_token:
- mine_function: cp.get_file_str
- file:///tmp/example.txt
This is called in the state using
salt['mine.get'](minion_host_name, 'example_token')[minion_host_name]
Like I mentioned this has always worked when calling salt '*' state.apply
But after switching to salt-ssh -i '*' state.apply
Also switching to salt-ssh was out of my hands and going back is not an option. I have also tried declaring the functions in the roster rather than the pillar but produces the same result

Cannot setup a MySQL Backend for Airflow LocalExecutor

I need to run dags in parallel but do not need significant scaling, so LocalExecutor can do the job just fine. I looked through the Airflow docs and first created a MySQL database:
CREATE DATABASE airflow_db CHARACTER SET utf8;
CREATE USER <user> IDENTIFIED BY <pass>;
GRANT ALL PRIVILEGES ON airflow_db.* TO <user>;
I then modify the following parameters in the airflow.cfg file:
executor = LocalExecutor
sql_alchemy_conn = mysql+mysqlconnector://<user>:<pass>#localhost:3306/airflow_db
When I run airflow db init, I run into the following error message:
AttributeError: 'MySQLConverter' object has no attribute '_dagruntype_to_mysql'
During handling of the above exception, another exception occurred:
TypeError: Python 'dagruntype' cannot be converted to a MySQL type
Please note that nothing else in the airflow.cfg file was altered and that using the default SequentialExecutor with sqlite lets everything run just fine. Also note that I am using Airflow version 2.2.0
I found the solution to my own question. Instead of using the mysqlconnector, I used the pymysql driver:
pip install PyMySQL
The airflow.cfg parameters can then be adjusted as follows:
sql_alchemy_conn = mysql+pymysql://<user>:<pass>#localhost:3306/airflow_db
All else can stay the same.

Provisioning prometheus with saltstack

Using this formula:
https://github.com/bechtoldt/saltstack-prometheus-formula.git
for provisioning prometheus, I can't achieve convergence.
Fails pretty early on:
# salt prometheus-master state.apply test=True
prometheus-master:
Data failed to compile:
----------
No matching sls found for 'prometheus' in env 'base'
ERROR: Minions returned with non-zero exit code
Have 'prometheus' defined in bot states & pillars top.sls.
bechtoldt's formula requires additional code taken from his GitHub repository to work, formhelper, https://github.com/bechtoldt/salt-modules/blob/master/_modules/formhelper.py in https://github.com/bechtoldt/salt-modules which is his special way to manage pillars that gives him more flexibility to manage versions.
It is certainly not as straightforward as pillars are on their own, and you will need to understand that to operate the prometheus formula, so unfortunately it is not going to work out of the box.

saltstack 'Pillar failed to render with the following messages'

I'm getting the following error message when I do a state.apply:
[ERROR ] Data passed to highstate outputter is not a
valid highstate return: {'sonia9': ['Pillar failed to
render with the following messages:', "Rendering SLS 'users'
failed. Please see master log for details."]}
Is it possible to see the actually rendering and where it failed?
I've already tried:
log_level: garbage in /etc/salt/master, restarted daemon
salt-call -l debug state.apply on the minion
I get the same unhelpful error message, and no more detail about the actual rendering.
Sometimes it can happen that minion has stale cache. I have experience with the frustration when salt is reporting that something failed to render but that "something" is no longer listed in the top.sls files and saltmaster log doesn't say anything at all.
What can help in this case is to refresh grains on the affected minion (also refreshes pillars by default):
salt <target_host_pattern> saltutil.refresh_grains
I have found that if your pillar has duplicates In my case the same package was listed in the yaml twice. (long List) it would fail to complile but give no reason.. so to shorten the answer you may have to just clean your pillar and 1980's debug the file
Looks like users.sls under your pillar location (mostly /srv/pillar) is not correctly formed.
Run > salt sonia9 pillar.items OR salt minion state.sls filenameto check it

How to correctly setup keys with Hadley's secure package

I would like to use Hadley Wickam's secure package from GitHub.
The example usage isn't explicit about how to create keys and where to store them and I'm messing something up (possibly more than one thing).
I installed the package
# install.packages("devtools")
devtools::install_github("s-u/PKI") # needed for bug fixes not currently on CRAN
devtools::install_github("hadley/secure")
set up a vault folder:
dir.create("vault")
Then the next step is to add a user / key:
secure::add_user("hackr", local_key())
and of course if I literally run that last line as-is it says
Error: No key matches id_rsa
Because I don't have a key. So, I used PuttyGen to create a public/private RSA key pair.
I saved them to my desktop and tried putting the full path in the command above:
secure::add_user("hackr", local_key("C:/Users/hackr/Desktop/r_public_key"))
But that didn't work:
Error: No key matches
Then I tried saving the public key in the vault and doing:
secure::add_user("hackr", local_key("r_public_key"))
but I got the same error. Next I tried putting the public key in the working directory (one directory higher than the vault) but got the same error.
Finally, I tried copying the keys to C:\Users\hackr\.ssh but that also led to the same error.
I suspect I need to save the key somewhere special (in Windows I'm not sure where that would be?) and/or I am using the wrong type of key since PuttyGen is for SSH (?).
It looks like local_key is assuming your key is stored in ~/.ssh (which is a reasonable assumption). By default it assumes that the file is named id_rsa.pub so if you've renamed it then you'll need to pass the name into local_key.
I haven't used this package but always remember those wise words "Hack-R view the source"
The issue is that Hadley's local_key() function is assuming your key is stored in ~/.ssh which is where the commands below will place it by default, and name it id_rsa.pub. If you have a different setup, you can change the defaults, or you could simply follow the steps below.
Step 1
Go to https://help.github.com/articles/generating-an-ssh-key/
Read up. It's useful stuff to know.
It will tell you to do this in the console:
ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
Set a passphrase. Remember it.
Then enter this:
ssh-add ~/.ssh/id_rsa
Enter your passphrase.
Step 2
Your secure::add_user("hackr", local_key()) should work now.

Resources