Project

General

Profile

Actions

tickets #95941

closed

mirror.sfo12.us.leaseweb.net is 4 months back version

Added by jimc@jfcarter.net over 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Mirrors
Target version:
-
Start date:
2021-07-23
Due date:
% Done:

100%

Estimated time:

Description

(Redirected from SuSE bug 1188496)

Due to version skew when different mirrors were used for different
files (reported separately), I edited
/etc/zypp/repos.d/download.opensuse.org-oss.repo and also non-oss
to use a specific mirror. Specifically,
baseurl=http://http://mirror.sfo12.us.leaseweb.net/opensuse/opensuse/tumbleweed/repo/oss/?proxy=http://distro.cft.ca.us:3128
and similarly for non-oss.

Bad move. I did "zypper dist-upgrade --dry-run ..." as I usually do,
and it wanted to downgrade 3945 packages, plus a few updates, removals,
and new packages. I tracked it down the next day (on 2021-07-19):
their repomd.xml is dated 2021-03-07! And I assume without checking
that the rest of the mirrored files are similarly back version.

Maybe you should have a chat with them to find out what's going on.
Also, you could save everyone a lot of grief if you enforced timeliness
standards with an automated check of all the mirrors. I notice that
different mirrors advance to new versions at different times.

I read in one of SuSE's blogs that for a new non-rolling release, you
push out everything to the mirrors in a not-exactly-public directory.
Then when the mirrors are presumed to have everything, you send out one
symbolic link, which atomically makes the new release available. This
would not be practical for Tumbleweed, but an atomic transition of the
repodata directory likely would be practical. Also, in the past I've
often (like once a month) had a RPM file vanish. I think the timeline
goes like this:

  • I do "zypper refresh"
  • Then immediately "zypper --non-interactive dist-upgrade".
  • Some RPM file gets removed and replaced by a newer version.
  • I don't know when the metadata is replaced, but it wasn't updated when I downloaded it in step 1.
  • Zypper tries to download the file listed in the metadata, doesn't get it, and aborts.

Perhaps you could retain old RPMs for a reasonable amount of time. In
fact, I maintain an archive area containing every installed or
to-be-installed RPM on my various machines and I keep them for a month
after they get replaced, so I can revert a bad new version. In other
words, for me the reasonable amount of time is one month.

--
James F. Carter Email: jimc@jfcarter.net
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)


Files

signature.asc (488 Bytes) signature.asc jimc@jfcarter.net, 2021-07-23 18:28
Actions #1

Updated by cboltz over 2 years ago

  • Category set to Mirrors
  • Assignee set to pjessen
Actions #2

Updated by pjessen over 2 years ago

  • Private changed from Yes to No

jimc@jfcarter.net wrote:

to use a specific mirror. Specifically,
baseurl=http://http://mirror.sfo12.us.leaseweb.net/opensuse/opensuse/tumbleweed/repo/oss/?proxy=http://distro.cft.ca.us:3128
and similarly for non-oss.

I assume that URL has a couple of typos? This is the correct one:
http://mirror.sfo12.us.leaseweb.net/opensuse/tumbleweed/repo/oss

and new packages. I tracked it down the next day (on 2021-07-19):
their repomd.xml is dated 2021-03-07! And I assume without checking
that the rest of the mirrored files are similarly back version.

Yes, it does look like that mirror stopped synchronizing some time in early March.

Also, you could save everyone a lot of grief if you enforced timeliness
standards with an automated check of all the mirrors.

We do, all mirrors are continually scanned to make sure we know which ones are up to date.
Somehow that has clearly stopped working for this mirror.

I notice that different mirrors advance to new versions at different times.

Yes, that depends entirely on the synch schedule of the individual mirror.

I read in one of SuSE's blogs that for a new non-rolling release, you
push out everything to the mirrors in a not-exactly-public directory.

Something like that. Prior to a release of openSUSE Leap, we enable all mirrors to be current before we "flip the switch".

For the time being, I'll disable mirror.sfo12.us.leaseweb.net. I'll take a closer look when I'm back from summer hols.

Actions #3

Updated by pjessen over 2 years ago

  • Status changed from New to In Progress

Yesterday I ran a scan:

# mb scan mirror.sfo12.us.leaseweb.net
Wed Dec  1 11:10:49 2021 mirror.sfo12.us.leaseweb.net: starting
Wed Dec  1 12:33:40 2021 mirror.sfo12.us.leaseweb.net: total files before scan: 2001559
__DIE__: (/usr/bin/scanner 1124 main::rsync_get_filelist => /usr/bin/scanner 1293 main::muxread => /usr/bin/scanner 1178 main::sread)
Wed Dec  1 13:37:35 2021 mirror.sfo12.us.leaseweb.net: scanned 954705 files (248/s) in 3835s
Wed Dec  1 14:23:01 2021 mirror.sfo12.us.leaseweb.net: files to be purged: 1046854
Wed Dec  1 15:55:55 2021 mirror.sfo12.us.leaseweb.net: total files after scan: 954705 (delta: -1046854)
Wed Dec  1 15:55:55 2021 mirror.sfo12.us.leaseweb.net: purged old files in 8300s.
Wed Dec  1 15:56:03 2021 mirror.sfo12.us.leaseweb.net: done.
Completed in 4.8 hours

I have re-enabled the mirror, we'll see.

Actions #4

Updated by pjessen over 2 years ago

Well, http://mirror.sfo12.us.leaseweb.net/opensuse/tumbleweed/repo/oss/repodata/ still contains data from March, so something is wrong.
I'll talk to the mirror admin.

Actions #5

Updated by pjessen over 2 years ago

  • Status changed from In Progress to Feedback

We have the following leaseweb entries in the database:

mirror.leaseweb.com
mirror.dal10.us.leaseweb.net
mirror.nl.leaseweb.net
mirror.us.leaseweb.net
mirror.sfo12.us.leaseweb.net
mirror.de.leaseweb.net

Apart from sfo12 and dal10, they seem to be current - I wonder if we really ought to have separate database entries for sfo12 and dal10.
I am disabling both until I hear from the mirror admin.

Actions #6

Updated by pjessen almost 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Closing as resolved. Please re-open if necessary.

Actions

Also available in: Atom PDF