If we are talking about handling updates for multiple desktop/laptop/workstations. I simply update them as I use them. If they are used by other people, it is their responsibility to keep them updated. If they can’t or won’t updates themselves, I don’t run an Arch-based distro on their machines.
Automating updates on an Arch-based distro is fraught with peril. It simply isn’t worth the hassle of having to fix things every time they break. For me, the automation costs more than it saves.
If you don’t care and want to do it anyway, there is no sophistication required in automating updates. You can simply create a systemd timer that passes --noconfirm
You may want to think about how you get notified when updates start failing.
I feel no mater how I type it, people are not understanding what I am meaning by ‘automation’ in this case. I even gave very specific examples and I feel they were not read. (Also, simply adding –noconfirm does not skip the requirement of needing a password. Putting that on any sort of timer is not going to help anything))
I DO NOT want an automation that kicks off BY ITSELF set on some sort of timer or otherwise. Not once have I ever suggested that.
I am talking about a script that I can run when I feel like it where I monitor the process of updating several machines. Taking what I already do manually (Update all the machines at once) and removing the tediousness of having to open 7+ ssh sessions and start the update process. That’s it.
I am sorry if I came across as strong. I did not mean to say anything that would counter what you have said. I did not mean to imply that you were against automation. I was merely elaborating on the utility of automation and pitfalls of it.
I agree with you 100% on the need to automate common repeated tasks, including updating. If the same task has to be done multiple times, have the computer do it.
That script to only monitor the progress of updates across different computers will have to be built. And it will be specific to use case. Using SSH would require logging into the systems remotely. It would be better to have a systemd-service or a daemon which runs in the background on the system being patched. This service captures the data from pacman.log file and should able to stream it across the LAN. This service would be an agent always running on the host. If required SFTP could be used too, while pacman.log file is shared across the LAN but it would be an overkill and not the most optimal.
IMHO Currently Linux package managers and their tools do not readily make available the capability to remotely monitor the updates.
There are 3rd party solutions which do what you are looking for, i.e. from a centralized host/computer they control, observe and deploy patches. They typically work on an agent-server mechanism. An Agent, which is nothing more than a daemon software, is deployed on the target machine where patches have to be deployed. While server is the software from where all of this is controlled.
Some of the products are ManageEngine Patch Manager Plus, SolarWinds Patch Manager, Patch My PC, Action 1 and others. Some of them are free up-to certain number of hosts. Some of them support Linux and other OS while some do not support Linux. Cannot comment on which of these products would be best.
That’s probably the easiest solution. Zellij is also great for this kind of situation, haven’t used it in months and sadly i don’t have my script anymore but i used something similar to connect several pc at the same time with a command/keybind.
If the service for the timer is running as root, you won’t need a password. If you were going to do it that way, you could put the timers on each workstation.
But…it seems that is not what you actually want.
It still seems fairly straightforward to write a script. Use ssh keys to login to each box and run the remote command over ssh.