On Fri, Jul 1, 2022 at 9:19 AM Nicolas Kovacs wrote:

Le 01/07/2022 à 14:44, Darin Perusich a écrit :

...

Why not just setup a local mirror of the repos?

https://en.opensuse.org/openSUSE:Mirror_howto https://en.opensuse.org/openSUSE:Mirror_howto

Because we have very limited bandwidth.

I just want to keep already downloaded packages, not fetch the whole download.opensuse.org site.

I understand you have limited bandwidth, this is the reason for having a local mirror. If the bandwidth is that poor then mirror the repos that you need from another site with a faster internet circuit, then sync that data to your onsite mirror. Then you only need to sync the updates repositories which should be a small subset of packages on a nightly basis.I would think this to be a simpler solution then trying to figure out some caching thing across N+1 computers. Good luck

Nicolas Kovacs wrote:

The OpenSUSE galaxy is badly lacking such a tool.

I wrote this just about 10 years ago: https://wiki.jessen.ch/index/How_to_cache_openSUSE_repositories_with_Squid It'll take you more than 30 seconds to set up though :-) -- Per Jessen, Zürich (21.9°C)

Andrei Borzenkov wrote:

On 01.07.2022 18:56, Per Jessen wrote:

...

Nicolas Kovacs wrote:

...

The OpenSUSE galaxy is badly lacking such a tool.

I wrote this just about 10 years ago:

https://wiki.jessen.ch/index/How_to_cache_openSUSE_repositories_with_Squid

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Yeah, sorry, it's a very old webserver :-( Maybe I'll move that site - wikimedia also needs updating, to php7. In the meantime, for those truly interested, firefox permits downgrading tls for specific hosts: about:config security.tls.insecure_fallback_hosts -- Per Jessen, Zürich (21.4°C)

On 2022-07-01 16:11, Nicolas Kovacs wrote:

Le 01/07/2022 à 15:54, Darin Perusich a écrit :

...

I understand you have limited bandwidth, this is the reason for having a local mirror. If the bandwidth is that poor then mirror the repos that you need from another site with a faster internet circuit, then sync that data to your onsite mirror. Then you only need to sync the updates repositories which should be a small subset of packages on a nightly basis.I would think this to be a simpler solution then trying to figure out some caching thing across N+1 computers.

Here's how you do it on Debian-based systems:

1. Install apt-cacher on a local machine and run it. Works out of the box.

2. Point all clients to that local machine using dpkg-reconfigure and typing the cache machine's host name.

Takes 30 seconds to setup.

No jumping through burning loops.

No downloading/mirroring tons of RPMs.

The OpenSUSE galaxy is badly lacking such a tool.

Yes. I have said so for ages.

https://en.wikipedia.org/wiki/KISS_principle

-- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)

On Fri, 2022-07-01 at 15:33 +0200, Nicolas Kovacs wrote:

Le 01/07/2022 à 15:29, Dave Howorth a écrit :

...

Set all the files so zypper doesn't have enough privilage to erase them?

All these files are created by Zypper in the first place.

Let me state this otherwise:

How can I potty-train Zypper NEVER TO WIPE THE CACHE ?

:o)

-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

How about setting the immutable flag for any RPMs found in /var/cache/zypp (ahead of any host being upgraded w/ that cache in place)? # find /var/cache/zypp -type f -iname '*.rpm' -exec chattr +i {} \; # find /var/cache/zypp -type f -iname '*.rpm' -exec lsattr {} \; # find /var/cache/zypp -type f -iname '*.rpm' -exec chattr +i {} \; # find /var/cache/zypp -type f -iname '*.rpm' -exec lsattr {} \; ----i----------C------ /var/cache/zypp/packages/home_gmbr3_Chromium/x86_64/chromium- 96.0.4664.110-1626.1.x86_64.rpm # find /var/cache/zypp -type f -iname '*.rpm' -exec rm -v {} \; rm: cannot remove '/var/cache/zypp/packages/home_gmbr3_Chromium/x86_64/chromium- 96.0.4664.110-1626.1.x86_64.rpm': Operation not permitted -- ~ Scott Bradnick |- Windows Subsystem for Linux (WSL) Developer |-- Tumbleweed: |--- Dell Precision 5540 [NVIDIA Quadro T1000] (x86_64) |--- O-DROID H2+ [UHD Graphics 600] (x86_64) |--- 2x Raspberry Pi 4 Model B Rev 1.2 (aarch64) |--- 1x Raspberry Pi 3 Model B Rev 1.2 (aarch64) |--- WinBook TW100 (x86_64) https://keys.openpgp.org/ :: DBC5AA9A2D2BAEBC

Andrei Borzenkov composed on 2022-07-01 18:25 (UTC+0300):

b) do not use "zypper addrepo", just drop repository definition into /etc/zypp/repos.d

I've been doing this since April, mainly to speed up each PC's update process. Installing from the LAN is much faster than from the internet on machines unconstrained by 100MB NICs. Some few rpms somehow acquire RO status, a puzzle I have yet to try to diagnose. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Le 01/07/2022 à 17:25, Andrei Borzenkov a écrit :

...

And here's the thing: this operation WIPES THE CACHE. Which, as far as I can tell, is Zypper being particularly stupid.

That is not the language to use for technical questions.

If a Linux tool does exactly the opposite (e. g. wipes the cache) of what I'm asking it to do in the first place (--keep-packages), then "stupid" is more likely the most *polite* word I can come up with in the context. Please note that I refrained from a selection of more colorful expletives overheard from my late Hungarian grandmother. :o) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

Le 02/07/2022 à 13:32, Patrick Shanahan a écrit :

perhaps you are expecting something from a tool which was not intended. maybe better that you offer to provide the functionality you desire.

Here's the corresponding quote from 'man zypper': -k, --keep-packages Enable RPM files caching for the repository. I think we can all agree that man pages are a good source to show the *intended* functionality of a tool. In that case, *not* empty the package cache but keep stuff that's downloaded. In daily practicy, using zypper addrepo along with this option effectively wipes the cache. *insert obscene expletive here*. Corresponding bug reports have been sent (see earlier in this thread) and answered with a WONTFIX. And no, I won't fork zypper now. The workaround posted by Andrei works, so I guess it will do. Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

Nicolas Kovacs wrote:

Le 02/07/2022 à 13:32, Patrick Shanahan a écrit :

...

perhaps you are expecting something from a tool which was not intended. maybe better that you offer to provide the functionality you desire.

Here's the corresponding quote from 'man zypper':

-k, --keep-packages Enable RPM files caching for the repository.

I think we can all agree that man pages are a good source to show the *intended* functionality of a tool. In that case, *not* empty the package cache but keep stuff that's downloaded.

TBH, it sort of makes sense. You are adding a *new* repo. It is therefore safe to assume that anything already in the cache direcory is bogus stuff and should be removed. The '-k' switch only refers to the *future* behavior of that repo. To do what you want IMO it would need a new keyword --keep-existing-cache. I'd say the best route for you is the suggestion to just drop in the new repo files in /etc/zypp/repos.d and do a 'zypper ref; zypper dup'. Just make sure it's the proper one (from initial upgraded host) that has the keep-packages active.

In daily practicy, using zypper addrepo along with this option effectively wipes the cache. *insert obscene expletive here*.

As explained above, IMO this is a sensible choice. Keeping a pre-existing cache because of the use of -k option is not.

On 03.07.2022 11:48, Nicolas Kovacs wrote:

Le 03/07/2022 à 10:12, Peter Suetterlin a écrit :

...

TBH, it sort of makes sense. You are adding a *new* repo. It is therefore safe to assume that anything already in the cache direcory is bogus stuff and should be removed. The '-k' switch only refers to the *future* behavior of that repo. To do what you want IMO it would need a new keyword --keep-existing-cache.

Yes, that would make sense. Sort of. Except the fact that adding *one* new repo effectively wipes *all* the existing stuff from *all* the repos.

I cannot reproduce it.

Le 03/07/2022 à 16:52, Carlos E. R. a écrit :

...

I cannot reproduce it. I recall this behavior in the past. I have not tested recently. It should be in my bug report, years ago.

Before we're going further down this foxhole, let me just state that Andrei's suggestion works perfectly. I just setup four networked VMs on my workstation to test the setup. * One NFS server running Rocky Linux 8 * Three OpenSUSE Leap 15.3 NFS clients with shared cache. I upgraded the first client using my upgrade.sh script, which downloaded and installed about 1.200 packages. Then I launched the script on the next client, and packages were fetched as expected over the shared cache. Installation was much (!) faster. Same thing on the third desktop client. Just works. So tomorrow I'll configure this shared NFS package cache in our local school to manage dist-upgrading all our two dozen desktop clients to OpenSUSE Leap 15.4. And I'm glad to have found a working solution to make up for our painfully slow bandwidth. Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

Am 03.07.2022 um 10:49 schrieb Nicolas Kovacs :

Hey, can I have a beer with my steak ?

- Of course, but let me first clean your table.

- But I'm eating my steak.

- No problem. You can order one again anytime.

I like analogisms to real world 😃 Which directly leads to the natural solution: one would always order the beer first. 😀 Have a nice day, Berny