SaltStack State: DNF-Automatic
-
If you're already using Salt, why use dnf-automatic? Just schedule Salt to do the updates. Here's what I do nightly for my DNS servers. It runs serially so one is up while the other is updating. You also have all of your update logs in one place this way.
--- - name: Update playbook hosts: dns_servers user: centos become: true gather_facts: true serial: 1 tasks: - block: - name: update packages package: name: '*' state: latest - name: reboot servers shell: sleep 2 && /sbin/shutdown -r now "Ansible system upgraded" async: 1 poll: 0 ignore_errors: true - name: wait for server to come back wait_for: host: "{{ openstack.networks.private[1] }}" port: 22 delay: 10 delegate_to: localhost - name: Send Slack notification slack: token: "{{ slack_token }}" channel: #ansible msg: "Updates completed on {{ openstack.name }} successfully" delegate_to: localhost rescue: - name: fail slack: token: "{{ slack_token }}" channel: #ansible msg: "Updates on {{ openstack.name }} failed" delegate_to: localhost
-
@jaredbusch said in SaltStack State: DNF-Automatic:
@tim_g said in SaltStack State: DNF-Automatic:
I won't post the config and timer files, those are easy enough to get.
That defeats the purpose of a simple guide. Your want to provide 100% of the pieces someone needs to do something when you make a guide like this.
This kinds of stuff is why I almost always have to make my own guides for things (and post them here). Because half the shit on the net is missing pieces like this.
When I am looking for something like this, I will choose the Google result that has everything I need in one good guide instead of using 5 different ones jsut to get all the pieces of information.
Maybe I'm alone in that I like to grab config files myself even if they're posted to make sure I'm using the correct and latest one.
But you do make a good a point. I'll add them to my OP in a bit.
-
@tim_g said in SaltStack State: DNF-Automatic:
Maybe I'm alone in that I like to grab config files myself even if they're posted to make sure I'm using the correct and latest one.
This would be the default one that comes down with the package. So that means there is nothing to grab.
In this case your state should just be editing an existing and not "grabbing" anything.
-
@jaredbusch said in SaltStack State: DNF-Automatic:
@tim_g said in SaltStack State: DNF-Automatic:
Maybe I'm alone in that I like to grab config files myself even if they're posted to make sure I'm using the correct and latest one.
In this case your state should just be editing an existing and not "grabbing" anything.
That's why I like Salt config files (as an easy example). You can leave the default config files in place untouched, and include your own custom config files, and it will use that to overwrite the defaults.
However with dnf-automatic, I'm not aware of it having that capability. I also didn't bother to check. I do prefer to host config files on my GitLab server and use those.
If there's a way to look for and pick out certain bits of a config file, and change those to something specified in a file on GitLab (via Salt), I'd prefer doing it that way. But I haven't gotten that far yet, if there is.
My plan is to be able to fully set up my VPS host 100% in all aspects via Salt and GitLab, and my Fedora Linux Desktop clients along the way.
Once I accomplish that, I will be able to dive deeper into things. And perhaps that will be one of those I touch before others.
-
@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.
-
@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.
-
@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...
Not with salt. I get the config file, then I can use it on 10,000 machines instantly.
-
@jaredbusch said in SaltStack State: DNF-Automatic:
...and does nothing to help you when the file is updated upstream.
I realized that going into this thing. I know that for the time being, the present config file "should" be fine for now until I'm finished and can learn more as I mentioned earlier. If the config file would change in a future update, I doubt it would be significant enough to matter, at least in my specific case for the near future.
It's great and works well as-is to get things going and into gear.
-
The point of this topic was that if you are using Salt, and want to quickly get dnf-automatic installed, configured, and working... it will get that done.
Feel free to make any other adjustments you see fit in your own environment.
-
Added files to original post.
-
@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.