Pillar locations

[Mr-Dilkington]

First of all, thanks to the entire SO team for creating/maintaining such a great product!

I apologize for what's almost certainly a stupid question(s) but I'm a little confused about a few things I've run into with Salt/Steno. What started my confusion is my attempt to permanently stop Steno from running - both at the local level and centrally via the Manager. The latest documentation clearly states that this can be done using the "minion.sls" or "global.sls" files (again, locally vs centrally for a pan-grid change). However, starting with the Sensor-specific local option, I see three separate minion.sls files located in different locations:

/root/SecurityOnion/salt/salt/minion.sls
/var/cache/salt/minion/files/base/salt/minion.sls
/home/admin/SecurityOnion/salt/salt/minion.sls

These don't line up with the documented location - /opt/so/saltstack/local/pillar/minions/.sls

In my case (I have looked on both a test Sensor as well as a Search Node), there is no "local" directory at all under saltstack.

I've also noticed that in some of the documentation, the pillar file is referred to as the above with the cited as being a variable as part of the filename yet in other places, it's being referred to simply as "minion.sls". I have however found what appears to be an unused version of the .sls file at:

/root/installtmp/pillar/minions/

....but it only ever appears there and doesn't seem to exist anywhere else

Regardless, I have tried editing all three of the above-mentioned minion.sls (not the ones with ID) files with:

steno:
enabled: false

....but this doesn't result in Steno being turned off.

I have also edited the global.sls file on the manager followed by "so-checkin" on both the manager and the sensor but this also doesn't result in Steno being shut down either.

For now, I have resorted to doing a manual stop of Steno with so-pcap-stop but I'd really prefer to do this the right way - especially if I end up deploying SO in a production environment.

Sorry for the longwinded query on all this and much appreciate any insight/help.

[TotieBash]

disclaimer, I have a "standalone" install and not the "distributed" architecture that you have. But I think you should edit the "/opt/so/saltstack/local/pillar/minions/.sls" file from the manager node and salt will do all the heavy lifting and that should trickle down the entire distributed node.

[Mr-Dilkington]

Thanks.

I believe you are referring to the global.sls file from the manager node. As I mentioned in my post, I have also done that and this method doesn't work either. Also, even if this worked, this would force steno to be turned off on all minions (sensors) and this is not actually what I want.

[dougburks]

However, starting with the Sensor-specific local option, I see three separate minion.sls files located in different locations:

/root/SecurityOnion/salt/salt/minion.sls /var/cache/salt/minion/files/base/salt/minion.sls /home/admin/SecurityOnion/salt/salt/minion.sls

These don't line up with the documented location - /opt/so/saltstack/local/pillar/minions/.sls

From the manager, what is the ouptut of the following command?

sudo ls -alh /opt/so/saltstack/local/pillar/minions/

[Mr-Dilkington]

Hi Doug. Output for that command is:

total 16K
drwxr-xr-x. 2 socore socore 121 Nov 12 21:45 .
drwxr-xr-x. 14 socore socore 255 Dec 2 02:28 ..
-rw-r--r--. 1 socore socore 984 Nov 12 18:25 somgmt1_manager.sls
-rw-r--r--. 1 socore socore 550 Nov 12 21:58 sosearch1_searchnode.sls
-rw-r--r--. 1 socore socore 431 Nov 12 21:29 sosearch1_sensor.sls
-rw-r--r--. 1 socore socore 431 Nov 12 21:45 sosensor1_sensor.sls

This confuses me as I can't actually seem to get into that directory directly. It's as if it exists and doesn't exist at the same time. Perhaps my linux skills are failing me somehow. Second, the names of the sls files indicates issues with the installs (which did fail on both the sensor and search nodes) at least in terms of changed names. Finally, I'd thought this path was supposed to exist only on actual Minions as opposed to the manager where I'd thought only the global sls would reside. Afraid I'm not well versed with Salt.

I think what all of this seems to indicate is that I should wipe this entire set up and redo it. The part about not being able to change directory into that path is really confusing me.

Thanks for your help on this. Will report back after I've rebuilt all of it.

[Mr-Dilkington]

Confirmed editing sosensor1_sensor.sls followed by so-checkin on sensor disabled steno. I'm still going to blow this entire set up and start over but either way, thanks for the help!

[dougburks]

This confuses me as I can't actually seem to get into that directory directly. It's as if it exists and doesn't exist at the same time.

Normal user accounts don't have permission to access the directory. You can elevate permissions using sudo.

Finally, I'd thought this path was supposed to exist only on actual Minions as opposed to the manager where I'd thought only the global sls would reside.

We've designed Security Onion so that you can manage your entire grid from the manager.

[Mr-Dilkington]

Yes, this is what was confusing me as I was trying to sudo into that path directly and it wouldn't allow me to. In the end, I just did a sudo -i and was able to get to it properly.

I understand about being able to manage everything centrally - it's just that I didn't understand how the Salt Pillars/Minions work. I'd thought that part you mentioned would be one that only resides on every Minion whereas the global.sls was something I thought would be used to change the configuration of all Minions. I'll have to read up on Salt as I'm still confused about the specific mechanics involved.

Thanks again for helping with this.