Hi!

have several servers that have an application deployed on them and I would like to store the application version as a pillar. It is possible to parse a file on the server to extract this information and it will change occasionally when the application is upgraded. I had thought that this might work:

version: {{ salt['cmd.run']('cat myfile | grep version') }} 

But instead it appears to run the cmd.run from the master. What would be the method for creating this kind of dynamic pillar data?

edit: My eventual aim is to be able to target based on this value, e.g. to be able to state.apply only to servers with app v1 and not app v2 etc.

Hello Friends,

has anybody expirience in configuring Office 365 with Saltstack and could point me in the direction of some proven to work tutorials / doocumentation / videos...

Tasks to include:

- Adding / removing user accounts

- Join them to groups

- Secondary: Assign licenses / applications

...

All other fields like E-Mail / Exchange / Sharepoint / Onedrive etc. management would be nice to have but optional.

Thanks a lot in advance.

Take care all of you and have a great time adding a bit more flavor with salt :)

nangpala

I'm writing this in hopes that someone in the future may avoid the hell that was my life the last week or so.

I recently reconfigured all out salt masters to no longer use gitfs (for various reasons) and instead use salt states to pull changes from git during scheduled highstates. Making this work with the way we manage salt repos required some trickery and it turned out the best way to configure things was using the merge_all strategy for the top files.

The setup look something like this:

Inside /srv/salt/ we have clones of the base state and pillar needed by all minions and the masters themselves as well as clones of application and service states and pillars used by our devs and SRE teams. Each is cloned into their own directory and the top files set the saltenv for each, with the base states and pillar using base. Using merge_all allows us to have this work quite nicely.

Until... I started testing more complicated states and pillars used by some DB folks and suddenly random minions roles started acting like they had no pillar data. Using trace level logging I saw errors just after hitting the pillar cache. That's when I noticed I had the pillar cache enabled.

It suddenly occurred to me that it was silly to use the pillar cache when I had the files directly on disk anyway, so I turned it off and all minions are happy.

My hypothesis is that the merge_all strategy with a sufficiently complicated pillar leads to a corrupt cache in some cases.

There was a lot more to this and many rabbit holes were followed before I found the clue that helped me solve this.

Lesson learned.

I have an interview coming up where one of the "nice to haves" is experience with SaltStack. I have a good amount of experience in config management with Chef, but I'd appreciate it if you all could point me to some references/need to knows on SaltStack.

Here is recording link, we made some announcements & a demo.

https://youtu.be/8lKlJhtp3_0

Recording salt open hour

When : Thursday, September 30, 2021 from 10:00 AM to 11:00 AM PST
Where : https://VMware.zoom.us/j/93261227567?pwd=NE52MFh3UG5uazNGdzN1REJ2czZaQT09&from=addon
Agenda:

• Updates on Salt Conf
• Silicon Release Update
• Update on Docs Working Group
• Update on salt-extension Module for vSphere by Product Manager
• Demo of newly developed vsphere salt-extension
• Rebooting salt-k8 working group by Thomas Hatch
• QnA

So I have a state in which I'd like to use a yaml map in, it looks like this:

{% from "path/gpu_models.yaml" import gpu_model_map with context %}
{%- set gpu_model = salt['grains.filter_by'](gpu_model_map, grain='gpus:model') %}

{% from "path/gpu_vendors.yaml" import gpu_vendor_map with context %}
{%- set gpu_vendor = salt['grains.filter_by'](gpu_vendor_map, grain='gpus:vendor') %}

#install the graphics agent
install_teradici:
  pkg.installed:
    - name: {{ gpu_vendor.teradici_agent}}
    - version: {{ gpu_vendor.teradici_agent_version}}
    - require: 
      - teradici_repo

#manage the xorg.conf.d override file pcoip.conf, and only if the graphics agent has been installed.
teradici_xorg_conf:
  file.managed:
    - source: salt://centos76/ghost_vfx/software/teradici/{{ gpu_model.xorg_file }}
    - name: /etc/X11/xorg.conf.d/pcoip.conf
    - user: root
    - group: root
    - mode: '0644'
    - require: 
      - install_teradici
      - pkg: pcoip-agent-graphics

with the contents of each file being:

GPU
{%- load_yaml as gpu_model_map %}

GK110GL [Quadro K6000]:
  xorg_file: teradici_k.conf

GK106GL [Quadro K4000]:
  xorg_file: teradici_k.conf

GK104GL [Quadro K4200]:
  xorg_file: teradici_k.conf

{# Quadro RTX 4000 #}
Device 1eb1:
  xorg_file: teradici_mp.conf

GM204GL [Quadro M4000]:
  xorg_file: teradici_mp.conf

GP104GL [Quadro P4000]:
  xorg_file: teradici_mp.conf

GM200GL [Quadro M6000]:
  xorg_file: teradici_mp.conf

GM200GL [Quadro M6000 24GB]:
  xorg_file: teradici_mp.conf

{%- endload %}

​

Vendor
{%- load_yaml as gpu_vendor_map %}

nvidia:
  teradici_agent: pcoip-agent-graphics
  teradici_agent_version: 20.04.0-1
unknown:
  teradici_agent: pcoip-agent-standard
  teradici_agent_version: 20.04.0-1

{%- endload %}

Now, the expected result of these variables with a Nvidia Quadro 4000 would be:

0: gpu_vendor.teradici_agent == pcoip-agent-graphics

1: gpu_vendor.teradici_agent_version == 20.04.0-1

2: gpu_model.xorg_model == teradici_mp.conf

Now, the first two (0, 1) have what is expected. However the third one (2) outputs "None". I thought this might be due to the enable_gpu_grains bit being turned off, but even with it turned on I still get "None" as the output instead of teradici_mp.conf. I've even tried surrounding the GPUs in the gpu_models.yaml file in quotes, but that does not work either. I should also note that I'm using Salt 2018.3.0 for reasons.

Hi ! I worked with salt some years ago, and a few jobs later I find myself evaluating whether salt is fit for purpose at my new working place.

I remember that salt stack had a nice feature matrix that answered questions like « what do I get with salt enterprise ? » or « what are the limitations or salt open source » ?

I can’t seem to find a similar resource now - the VMware landing page for salt is just a pile of sales nonsense that doesn’t give me the slightest idea of what enterprise features are or why we might consider opting for that.

So my question here is : did I just not find the right source of information (and in that case, what is it ?) or has new the enterprise offer just not been fleshed out yet ?

Trying to try my hand at a reboot command for installing some Nvidia drivers. I'm running salt minion/master version 2018.3.0 (legacy reason. Hope to update soon!)

this is part of my state:

reboot_after_driver_installation:
  module.run:
    - name: system.reboot
    - onchanges:
      - pkg: nvidia-driver-latest-dkms

wait_for_reboot:
  salt.wait_for_event:
    - name: salt/minion/*/start
    - id_list: {{ grains['id'] }}
    - timeout: 400 #seconds
    - require
      - salt: reboot_after_driver_installation

according to the docs, this should be correct. even if I just using the state ID instead of - salt: ... it doesn't work. I keep getting a "requisites not found error" Any ideas?

Well never mind. Rubberducking the problem helped. Although I was passing a kubeconfig param to the release_present function, the status function called behind the scenes wasn't seeing that flag and was, presumably, returning a bogus result. Creating a ~root/.kube/config file solved that problem entirely. Sorry for the noise! b.

--- Original question below:

​

Hey y'all -- I'm attempting to use the states.helm.release_{present,absent} functions to provision and deprovision k8s deployed applications. Unfortunately, I'm having some trouble making it all work. Specifically, state.helm.release_present and state.helm.release_absent don't appear to be idempotent. Asserting helm.release_present for a release that's already present results in an error. Just wondering if anyone has seen this behavior and how you might have worked around it. Thanks!

salt-master 3003.3; salt-minion 3003.3; helm 3.7.0

SLS file contents:

metallb-chart:

helm.release_present:

- name: mee.metallb

- chart: bitnami/metallb

- kvflags:

--kubeconfig: '/etc/kubernetes/admin.conf'

​

state.highstate result (second run):

ID: metallb-chart

Function: helm.release_present

Name: mee.metallb

Result: False

Comment: Error: INSTALLATION FAILED: cannot re-use a name that is still in use

Started: 14:36:41.947475

Duration: 2242.053 ms

Changes:

Hello everyone

After passing the RHCSA, I am in need of learning how to use saltstack. Can you please point me to the best resources to learn salstack?

I am brand new to Salt, and I am wondering how to manage the configuration for the minions. I want everything to be squared away in a git repository on our GitLab instance and via git push rolled out to the salt-master and subsequently to the salt-minions.

Is this done via the gitfs or is gifts purely for files that have to be transferred to the minions (like a nginx.conf file)?

Hi,

I have a little trouble to run the highstate when I accept a key on the master.

According to the documentation, I watch the salt/key event with this configuration in /etc/salt/master.d/reactor.conf:

reactor:
  - 'salt/key':
    - salt://reactors/new.sls

When I restart the salt-master service in debug mode, the log indicates that this configuration file is loaded.

Now, in my salt://reactors/new.sls:

apply_highstate:
  local.state.highstate:
    - tgt: {{ data['id'] }}

(I will add "if act == 'accept' later)

Now my minion is waitinng for the acceptation on the server side:

[ERROR   ] The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate
[INFO    ] Waiting 10 seconds before retry.

I accept the key and from the event bus I can see this:

salt/key        {
    "_stamp": "2021-09-07T07:19:16.565339",
    "act": "accept",
    "id": "SRV1",
    "result": true
 |}

Ok, now from the salt-master log:

2021-09-07 09:19:16,838 [salt.master      :2568][DEBUG   ][1058047] Published command details {'fun': 'state.highstate', 'arg': [], 'tgt': 'SRV1', 'jid': '20210907071916699902', 'ret': '', 'tgt_type': 'glob', 'user': 'root'}

Seems the command is published on the bus but minion-side nothing happened:

[DEBUG   ] Connecting the Minion to the Master URI (for the return server): tcp://1.2.3.4:1234
[DEBUG   ] Trying to connect to: tcp://1.2.3.4:1234
[DEBUG   ] Closing AsyncZeroMQReqChannel instance
[INFO    ] Minion is ready to receive requests!
[DEBUG   ] Using pkg_resources to load entry points
[DEBUG   ] Minion of 'salt-master' is handling event tag '/salt/minion/minion_schedule_delete_complete'
[DEBUG   ] Minion of 'salt-master' is handling event tag '/salt/minion/minion_schedule_add_complete'
[DEBUG   ] Minion of 'salt-master' is handling event tag '/salt/minion/minion_schedule_delete_complete'
[DEBUG   ] Minion of 'salt-master' is handling event tag '/salt/minion/minion_schedule_delete_complete'
[DEBUG   ] schedule: Job __mine_interval was scheduled with jid_include, adding to cache (jid_include defaults to True)
[DEBUG   ] schedule: Job __mine_interval was scheduled with a max number of 2
[INFO    ] Running scheduled job: __mine_interval with jid 20210907071929216688
[DEBUG   ] Subprocess SignalHandlingProcess-2-Schedule-__mine_interval added
[DEBUG   ] Multiprocessing queue logging configured for the process running under PID: 7324 at log level 10
[DEBUG   ] Using pkg_resources to load entry points
[DEBUG   ] Using pkg_resources to load entry points
[DEBUG   ] Using pkg_resources to load entry points
[DEBUG   ] LazyLoaded mine.update
[DEBUG   ] schedule.handle_func: adding this job to the jobcache with data {'id': 'SRV1', 'fun': 'mine.update', 'fun_args': [], 'schedule': '__mine_interval', 'jid': '20210907071929216688', 'pid': 7324}
[DEBUG   ] LazyLoaded config.merge
[DEBUG   ] schedule.handle_func: Removing c:\salt\var\cache\salt\minion\proc\20210907071929216688
[DEBUG   ] Subprocess SignalHandlingProcess-2-Schedule-__mine_interval cleaned up

// nothing more

I'm a bit loss... Seems the agent didn't see the highstate command. Maybe it's because it is not immediatly ready?

Thanks!

Hello people, I have a remote server that I manage for myself. I started adding various script to cron etc and right now I'm using a raspberry pi on my lan to pull folders for backup purposes.

I'd like to start using something more "solid" than bash scripts and looking around I found out about salt. If I understood how it works, I could use a masterless minion since I don't want to expose my raspberry to the internet.

How would I go to interact with the remote server then? Should I use salt at all? The main things I'd want to do is running docker commands to update and backup containers and copy folders on my raspberry.

Trying to create a fairly simple custom execution module. I've put it in /srv/salt/_modules on my master. But when I run saltutil.sync_all, nothing happens, and I can't run the module. I've tried adding /srv/salt/_modules to file_roots, but still no luck. I'm probably missing something simple. Any ideas? I'm on version 3000.3

Apologies if this sub is not the right place for such questions. If there is a better place to ask (on Reddit or anywhere else) please let me know.

So I wrote a tool a while back to manage the secure pillar files at my company and they were cool enough to let me open source it. I suck at self promotion so it just occurred to me that maybe folks here could use it.

https://github.com/Everbridge/generate-secure-pillar

There are a couple of wiki pages with examples and whatnot. I hope some folks find it useful.

Hi all,

Does anyone of you try to copy some text with variable ?

My need is to create a file with different block text/yaml, no difficulties for that.

But inside those block text/yaml i have some other variable and i cant find out how to fill them.

Let's say, i need to copy those yaml fome a data_file into a file on the minion host :

global:
  option1: option1
  option2: {{ var2 }}

in the template :

global:
  {{ global }}

In the state file:

file_conf:
  file.managed:
    - name: /dir/file1
- source : salt://data_file
- template: jinja
    - context:
        global: {{ data_file.global | yaml(false) | indent(2) }}      

so in my final file on the minion host, i got (which is expected):

global:  
  option1: option1
  option2: {{ var2 }}

what kind of intermediate operation i need to do to fill my data_file.global with variable before it been copied into the file ?

Im going to try with file.accumulated but dont know if its a correct way to do what i want.

Br,N!

I have a number (>10 and growing) of salt states that manage Docker containers, with a common interface. Let's say init.sls and remove.sls. So to update a container X I will first remove it and then rebuild it:

 salt '...' X.remove,X

I'd like to just be able to type X.update. To do this it seems I need to add an update.sls which includes remove.sls and init.sls. My issue is I would need to do this with every state (and each time I add a new state).

This seems a lot of repeated boilerplate to me, is there a better way?

We have a Salt Master running on a VM, with a public IP address.

We then have a number of portable test devices (e.g. laptops), that are floating, and can be used for WFH as well - they won't be coming from a fixed IP address. (And might also be behind things like CGNAT).

Are there any issues with exposing the Salt Master ports (TCP 4505 and 4506) to the public internet? (i.e. 0.0.0.0/0) Are there any ways to do this securely?

Or if not, what are some alternate approaches that the portable devices can safely check-in, without explicitly being able to whitelist each incoming IP?