low tech Salt deployment

So I have been tearing down and rebuilding a lot of crap in the lab lately (kubernetes clusters, ELK stack, etc) and I have been constantly having to re-add salt to the VMs because salt-cloud doesnt yet play nice with Xen.  After about the 3rd time of doing this I got tired of manually installing epel-release, salt-minion and then changing the config so I wrote perhaps the worst script ever to remotely do all that work for me and possibly be used later when I finally get salt-cloud working with Xen.


echo "deploying salt -> $HOST"
ssh root@$HOST "yum -y install epel-release && yum -y install salt-minion"
ssh root@$HOST "sed -i 's/#master: salt/master:' /etc/salt/minion"
ssh root@$HOST "systemctl start salt-minion && systemctl enable salt-minion"
echo "salt successfully deployed on host: $HOST"

Granted this relies upon me still manually doing ssh-copy-id so I don’t have to keep typing in passwords thats a lot fewer commands, maybe if I get the time I will add in some logic to then auto-accept the key in salt so that I don’t have to manually do that either.

Salt States for the Homelab

Over the past year or so I have been playing around with saltstack to automate as much as I possibly can in my lab, from updates to base vm configuration and making lab wide configuration changes (such as setting up SNMP for monitoring).  Here are my collection of states I currently use to carry out that baseline setup, they are all called from within my top.sls so at highstate they all are applied and make things suck just a little less when running updates and helps prevent typos from making things take longer than necessary.


    - password: $1$hud1CQZ8$eBQ/vZhwxfgIbLP/UbQzA.
    - text:
      - "# added via salt"
      - "dword ALL=(ALL)       ALL"


  pkg.installed: []
    - enable: True
    - running


    - humanname: CentOS-$releasever - Updates
    - baseurl:
    - gpgcheck: 1
    - gpgkey: file:///etc/pki/rpm-gpg/RPM_GPG-KEY-CentOS-7


  pkg.installed: []
  pck.installed: []


And finally my favorite of all, a working curl from within a state to hit an API target to kick off discovery, in this case its a discovery within EM7 but it can be easily modified as necessary

# this will perform a curl on the target minion
    - name: >-
        curl -k -v -H 'X-em7-beautify-response:1' -u 'dword:somepass' "" -H 'content-type:application/em7-resource-uri' --data-binary "/api/discovery_session/1"


Curl within a salt-state

So I have been looking all over for how to make this happen and finally figured it out, preserving it for anybody else who wants to kick off a curl in a salt state to say add something into monitoring or begin another process via an API call

# this will perform a curl on the target minion
    - name: >-
        curl -X POST -d '{"hostname":"","version":"v2c","community":"public"}' -H 'X-Auth-Token: 286755fad04869ca523320acce0dc6a4' ""

Right now this is just using testing data from my lab, but as long as you enclose all the salient data in ‘ or ” it should be fine

Strange behavior from Postman

I was working through changing my Saltstack configuration to work with LibreNMS and was working through adding devices via the API as opposed to using auto discovery and realized that basically the same query in curl works fine, but when I tried it with Postman it doesn’t work and acts like I never passed some of the values, observe!

as opposed to when done in curl

dword@DESKTOP:~$ curl -X POST -d '{"hostname":"","version":"v2c","community":"public"}' -H 'X-Auth-Token: 286755fad04869ca523320acce0dc6a4'
    "status": "ok",
    "message": "Device (18) has been added successfully"
dword@DESKTOP:~$ man curl

The only possible thing I can figure that is going since this is such an absurdly simple API query is that Postman does some kind of magic thats not plainly visible that changes how the data is received by the API.  This is moderately troubling because it gets me wondering what else they are doing with data and if there is some kind underhanded snooping going on, not that I’m working on anything too terribly sensitive other than helping myself become more lazy in the lab.  If I was tossing in a pile of headers I could see where the room for mistakes exists but with only three key/value pairs passed in data and the X-Auth-Token passed in headers I can’t really see any possible place I have messed up but sure enough we get the error about not specifying the version of SNMP for the add device call, so something definitely is hosed up somewhere.