On Wed, Aug 05, 2020 at 05:59:05PM +0200, Qubes wrote: > 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, [email protected] 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?
Yes, it is. A simple mechanism is to install apt-cacher-ng, and configure it to listen on port 8082, while removing or masking tinyproxy. This acts as a simple drop in replacement with benefit of caching. To use https in the repositories you need to rewrite them as "http://HTTPS///", and the caching proxy will then connect using https. To use for Fedora you need to keep an eye on the multiplicity of Fedora repos, and update the repo definitions. Debian and debian based archives work out of the box. > > 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. > The security isnt to be found at the proxy level, but at the package management level. It's there that verification is (and should be) done. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200806010324.GA456%40thirdeyesecurity.org.
