@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

@scottalanmiller said in Fedora 26 Failing Salt Update:

@tim_g said in Fedora 26 Failing Salt Update:

Will that uninstall yum-utils? Isn't that still needed for a lot of things?

dnf-utils replaces it.

https://bugzilla.redhat.com/show_bug.cgi?id=1478593

@emad-r One of the main points of using configuration management tools is that when using them properly you create idempotent operations (getting the same result no matter the number of times the operation is executed).

Instead of using cmd.run to execute the install, you could as others have mentioned the chocolatey module, or if you don't want to install chocolatey on your computers you could use the win_pkg which requries a repo created on the salt-master. Both of those modules are idempotent, so once you reach the desired state no matter how many times you run them they will not make any more changes.

https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.win_pkg.html
https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.chocolatey.html

The software available in the official windows git repo.
https://github.com/saltstack/salt-winrepo-ng

Creating a windows software repository:
On your salt master run

salt-run winrepo.update_git_repos

Sync the repo on your Windows minions

salt -G 'os:windows' pkg.refresh_db

Now you can use the pkg module in your states, or adhoc commands.

//Example adhoc command (remote execution) salt -G 'os:Windows' pkg.install salt-minion

That last command will always install the latest version of the salt-minion you could add the version parameter to specify the one you require.

My Favorite Ultra-VNC setup:

Not all issues can fixed from command line alas, thus this recipe:

uvnc: file.recurse: - source: salt://uvnc - name: 'c:\salt\uvnc' - makedirs: True cmd.run: - name: 'c:\salt\uvnc\state.cmd' module.run: - name: firewall.disable

remeber to re-enable the firewall of the client when finished. (salt "client" firewall.enable)
you will need to create uvnc folder (get it from UltraVNC portable builds) folder in your Salt master, in /srv/salt

in it :

winvnc.exe

UltraVNC.ini

state.cmd

SecureVNCPlugin32.dsm (Optional Encryption plugin)

Server_ClientAuth.pubkey (Optional Encryption server SSL handshake check)

And in the state.cmd put the following:

taskkill /f /im winvnc.exe sc stop uvnc_service sc delete uvnc_service "c:\salt\uvnc\winvnc.exe" -install "c:\salt\uvnc\winvnc.exe" -startservice sc config uvnc_service start= demand ipconfig | findstr /i "ipv4"

And whenever you want to connect to client, run this in salt master:
salt '172' state.apply uvnc

And you will see the IP of the client, you will need to match the IP and if you made any custom setting like port number/encryption plugin with vnc viewer and connect to client.