@flaxking said in Monitoring with SaltStack VS Zabbix: @scottalanmiller said in Monitoring with SaltStack VS Zabbix: @flaxking said in Monitoring with SaltStack VS Zabbix: Collecting metrics and triggering alerts based on predefined characteristics would be a whole area of monitoring you would miss out on. Collecting metrics is a core part of Salt. The events framework is part of Sodium. Those two pieces are there natively when you use SodiumSuite, it's just not extensive (yet). It's good at exporting values, but you would need to integrate another tool to store the data, analyze it and send alerts based on the data over time. Which I guess is where Sodium could come in. Exactly. SodiumSuite has been doing that part from the beginning. You still don't want to use Salt as the basis for anything intensive, though. It's meant to be run like 1-4 times an hour, not several times a minute.

@Obsolesce said in Converting a cron job to a systemd timer: First some info as it may have impact on whether or not to do this in the first place: I have a SaltStack deployment of 600-ish minions. Currently, I have a highstate set to run every 45 minutes via cron: */45 * * * * root /usr/bin/salt -b 25\% '*' state.apply I know one of the benefits of systemd over cron is the logging, and I think this would be great to have better logging of when this runs. More can potentially be done with it automatically, like look for issues and send emails just as one easy example. But I don't know how to test this... maybe it doesn't produce the kind of log I want, and salt may already do this in it's own log even better. Or maybe this will produce a log that's too big and cause issues later. I can watch it in the beginning either way, so it's fine. Can that cron job be converted into a reliable systemd timer? If so, how? 600ish minions. Wow. Curious about your setup. (Types of systems, types of states, how to manage and review output of all of that, etc.” Maybe an upcoming post?

@jaredbusch said in Installing a salt minion on FreePBX: @fuznutz04 I have not. But as you are seeing, FreePBX 14 and newer are not CentOS anymore. They are Sangoma OS. I am sure some manual setup would work as most things seemt to be ported, but no idea. The only extra thing I have added to FreePBX is ZeroTier. Good point. I will post some notes as to how well this works out. I was at least able to install it successfully.

Fedora 28 is fixed. Remove salt, and install again. Should be all set.

Don't know about CentOS, but the fixed Salt packages hit the Fedora repos in the last few hours.

@obsolesce said in Salt-Master Errors Fedora 28: @scottalanmiller said in Salt-Master Errors Fedora 28: Or closer to working, at least. Something still wrong with it? F28-only? Yeah, it runs better now, but still throws errors later.

Supposedly Foreman also works with Salt, I've only used it with Puppet though.

@scottalanmiller Which I agree to, which is what we have done.

Those $2.50 instances makes its impossible to install Fedora without using the one Vultr provides.

@dafyre said in Installing SaltStack Salt-Minion to Solus Linux: @quixoticjustin said in Installing SaltStack Salt-Minion to Solus Linux: Solus Linux lacks a native package for SaltStack and so to use it as a Salt Minion you have to grab the packages from GitHub and create it yourself. Special thanks to @scottalanmiller who looked into this and Exoner4ted in the Solus community who did the research and figured out how to make this work. Remember to change "saltmastip" to the actual IP of your salt master or handle that however makes sense for you. cd /tmp; wget https://github.com/saltstack/salt/archive/2018.3.zip unzip 2018.3.zip; cd /tmp/salt-2018.3/ python /root/salt-2018.3setup.py install echo "saltmasterip salt" >> /etc/hosts cp /root/salt-2018.3/pkg/salt-minion.service /usr/lib/systemd/system/ systemctl daemon-reload && systemctl enable salt-minion eopkg install python-pyzmq pycrypto python-msgpack python-tornado python-jinja pyyaml systemctl restart salt-minion Unfortunately this package is not self updating. Once you get the initial client installed, you should be able to to push out new salt-minion packages via Salt itself, right? Yes, but not using a repo. So you'd need to build your own installer / updater inside of a Salt state. Totally possible, but not as simple as telling it to update.

Even though I know that it is there, I get this... salt 'minion' ps.cpu_times minion: 'ps' __virtual__ returned False: The ps module cannot be loaded: python module psutil not installed. ERROR: Minions returned with non-zero exit code

@scottalanmiller said in Errors Installing SaltStack on NetBSD 7.1.1: Got it, it was a packaging versioning issue. I had accidentally set the verison to 8.0 when it was 7.1.1. I got a clean install and set the package version correctly and now it works fine. If you want to know how to set the version accurately automatically, try this that I just made... export PKG_PATH="http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/`uname -m`/`uname -r`/All/" That's exactly what I was thinking but didn't say anything. I wanted to see what you'd do.

I would check if there are any DNS errors trying to get the Repos or sites then look at this: https://github.com/saltstack/salt-bootstrap/issues/996 More recently on this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104

@tim_g said in SaltStack: Here's a SaltStack repo for Windows software: https://github.com/saltstack/salt-winrepo-ng These are ready to go and install via your own State files, or CLI. I was looking at a lot of those files, and it would appear to be very easy to setup my own in house repo. I will eventually be trying that.

Strictly SYSCTL speaking, here's what I got so far: kernel.randomize_va_space: sysctl.present: - value: 2 fs.protected_hardlinks: sysctl.present: - value: 1 fs.protected_symlinks: sysctl.present: - value: 1 net.ipv4.icmp_echo_ignore_broadcasts: sysctl.present: - value: 1 net.ipv4.icmp_ignore_bogus_error_responses: sysctl.present: - value: 1 net.ipv4.tcp_syncookies: sysctl.present: - value: 1 net.ipv4.conf.all.log_martians: sysctl.present: - value: 1 net.ipv4.conf.default.log_martians: sysctl.present: - value: 1 net.ipv4.conf.all.accept_source_route: sysctl.present: - value: 0 net.ipv4.conf.default.accept_source_route: sysctl.present: - value: 0 net.ipv4.conf.all.rp_filter: sysctl.present: - value: 1 net.ipv4.conf.default.rp_filter: sysctl.present: - value: 1 net.ipv4.conf.all.accept_redirects: sysctl.present: - value: 0 net.ipv4.conf.default.accept_redirects: sysctl.present: - value: 0 net.ipv4.conf.all.secure_redirects: sysctl.present: - value: 0 net.ipv4.conf.default.secure_redirects: sysctl.present: - value: 0 net.ipv4.ip_forward: sysctl.present: - value: 0 net.ipv4.conf.all.send_redirects: sysctl.present: - value: 0 net.ipv4.conf.default.send_redirects: sysctl.present: - value: 0 net.ipv4.conf.all.forwarding: sysctl.present: - value: 0 net.ipv6.conf.all.forwarding: sysctl.present: - value: 0 net.ipv4.conf.all.mc_forwarding: sysctl.present: - value: 0 net.ipv6.conf.all.mc_forwarding: sysctl.present: - value: 0 net.ipv6.conf.all.accept_source_route: sysctl.present: - value: 0 net.ipv6.conf.default.accept_source_route: sysctl.present: - value: 0 net.ipv6.conf.all.accept_redirects: sysctl.present: - value: 0 net.ipv6.conf.default.accept_redirects: sysctl.present: - value: 0 I know some of it may be redundant, as in they already may be set as such by default. My thinking is that should they become changed somehow, this will set it straight again. Is this a bad way of thinking or simply not needed? Are there any others a good idea or generally a best practice to include?

@jaredbusch said in SaltStack State: DNF-Automatic: @tim_g said in SaltStack State: DNF-Automatic: @jaredbusch said in SaltStack State: DNF-Automatic: This would be the default one that comes down with the package. So that means there is nothing to grab. Correct. I installed it on something first to get the config files, so I know what I'm working with. That is more work and does nothing to help you when the file is updated upstream. I did find how to easily modify files with SaltStack: https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.file.html#salt.modules.file.replace But I think I would still rather host my own config file(s) at least for now. If they change in future updates, I'll just modify the config files on GitLab. Anyways, link above for future reference when I come back to this later.

@tim_g said in VPS Open Ports - Thoughts?: @stacksofplates said in VPS Open Ports - Thoughts?: @tim_g said in VPS Open Ports - Thoughts?: I think if SodiumSuite plays their cards right, it has the potential to completely replace Microsoft's system management (like Group Policy and SCCM and others in the suite) as well as the major alternatives, such as Dell's KACE, etc. Quest bought KACE and it's gone downhill a bit. Yeah I know, old habit. I even see the new Quest branding every day when I log in to it. I don't know how I feel about the new interface. The K logo is weird.

I just noticed I had a typo in the salt-highstate part above. Fixed now. I left out the '*', which specifies all minions. Also, a \ is needed before the % symbol to escape it.

@tim_g said in Is it possible to use groupinstall in a Salt State?: It looks like it is supported, but I haven't tested it yet: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.group_installed That's cool.

Learn something new every day. I'm so used to CentOS, so I'm not used to the differences with Fedora. Thanks!

So forget my comments. It turned out maybe your instructions are fine. (Maybe, maybe not. I don't know, but will reinstall using your instructions again just to verify.) My problem was that I was opening up the firewall ports in the wrong zone. The default Install I used made only 1 zone on the master called "FedoraServer." Opening ports on this zone solved the issue. See this post from this morning: https://mangolassi.it/topic/15620/salt-stack-communication-issues/2

@flaxking said in Salt grain to retrieve users present on minion (Windows): @scottalanmiller said in Salt grain to retrieve users present on minion (Windows): @flaxking said in Salt grain to retrieve users present on minion (Windows): @scottalanmiller said in Salt grain to retrieve users present on minion (Windows): Salt seems like the obvious tool for desktop administration to me! And the thing is that automating desktop configuration has been the norm for longer than automating server configuration (at least in the Windows word), just with crappier tools. Yeah, very weird that people don't see this. @QuixoticJeremy actually presented on using tools like Salt to manage desktops at MangoCon 2017 a few months ago. No MangoCon 2017 videos up yet? No, waiting on @Minion-Queen