On 8/5/20 1:07 AM, Ulrich Windl wrote:
On 8/2/20 4:42 PM, Chris Laprise wrote:
On 8/2/20 8:32 AM, fiftyfourthparal...@gmail.com wrote:
I have a ton of templates and standalones (>10), so updating them one
by one serially is a pain. I found a convenient dom0 script so I
thought I'd share.
Basically, take this and paste it into dom0 then make it executable.
There'a also a handy test function. All credit goes to Andrea
Micheloni. Anyone have similarly handy modifications/scripts?
https://m7i.org/tips/qubes-update-all-templates/
IIRC there is an option somewhere in 'qubesctl' for parallel template
updates.
Actually instead of parallel updates (assuming limited bandwidth) I'd
vote for a more verbose progress indicator (in the graphical update app):
Currently the VMs start, update starts, and then ...long time
nothing..., then the list of packages updated.
Regards,
Ulrich
You can check out my github for some interesting stuff. The
'Qubes-scripts' project has a (serial) template updater that lets you
select by certain criteria. It could be parallelized pretty easily.
Since you have a lot of templates+standalones, the 'findpref' tool
might also be of interest. It can bulk search/replace VM prefs, such
as changing all the VMs that are using 'sys-vpn1' to use 'sys-vpn3'
instead, or change VMs to use a different template.
I also wrote 'wyng-backup', a fast LVM incremental backup tool that
only scans where LVM reports new activity.
Finally, there is a VPN tool and one to enhance VM internal security.
I vote for the local proxy to cache updates. Is that not possible?
Would it not make sense if a Fedora-32 or Fedora-32-xx template
downloads for example the latest Firefox that it should be cached
locally. When the next Fedora-32 template checks for updates the system
can check what the latest version is on the repository, if it is the
same as the cached version use the cached copy. This will dramatically
reduce update bandwidth requirements and make updating quick and
painless no matter the number of templateVMs.
There must be a fancy way of making this secure. When an update is
downloaded for the first time it is verified so we must ensure the
cache's integrity. Maybe the downloaded files can be signed by the users
own key kept in the vault AppVM.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/efc80a20-21a1-f26f-3f2d-2547d91814ce%40ak47.co.za.
