- openSUSE Mirrors

Upgraded opensusemirror.lihaso.com
by René Linder 17 Dec '20

17 Dec '20

Hi All Sorry for the instability from my mirror server the last 2 months. Mostly i had problems with full Disk... and the this night the power supply was blowing up. I did moved the mirror server now in a new case with place for now around 4300G usable SSD space. and added 4GB Memory :-) Local server farm could get around 900Mbit/s traffic from this machine. Current Uplink Peak is at 107MBit/s. Currently sync stage.opensuse.org::opensuse-full-with-factory And excluded currently: opensuse/ports opensuse/history When the current sync is done ports will also be removed from excluded list. For what is history and makes it sense to mirror it? Greetings René -- René Linder Geschäftsführer(CEO) Linder Hard- und Software Wiesenstrasse 4 Mobile +41 78 625 42 97 CH-5303 Würenlingen https://www.lihaso.ch/

2 1

Upgraded opensusemirror.lihaso.com
by René Linder 17 Dec '20

17 Dec '20

Hi All Sorry for the instability from my mirror server the last 2 months. Mostly i had problems with full Disk... and the this night the power supply was blowing up. I did moved the mirror server now in a new case with place for now around 4300G usable SSD space. and added 4GB Memory :-) Local server farm could get around 900Mbit/s traffic from this machine. Current Uplink Peak is at 107MBit/s. Currently sync stage.opensuse.org::opensuse-full-with-factory And excluded currently: opensuse/ports opensuse/history When the current sync is done ports will also be removed from excluded list. For what is history and makes it sense to mirror it? Greetings René -- René Linder Geschäftsführer(CEO) Linder Hard- und Software Wiesenstrasse 4 Mobile +41 78 625 42 97 CH-5303 Würenlingen https://www.lihaso.ch/

1 0

Subscription and Registering openSUSE Mirror
by Kelompok Linux Arek Suroboyo 10 Dec '20

10 Dec '20

Dear, openSUSE Community Hi, let me introduce myself, my name is Imanuel Ronaldo from Indonesia, i would like to subscribe for registering our official community service, GNU/Linux Distribution Mirror (http://buaya.klas.or.id/). openSUSE already include inside our service. Thank you -- *Your Faithfully,* [image: photograph] *Admin Cangkrukan KLAS* Event Organizer email: cangkrukan.klas(a)gmail.com mobile: +62895-6314-21101 (Andhika, Ketua) +62 851-5645-2629 (Imanuel, Humas) Kelompok Linux Arek Suroboyo, Jl. Panglima Sudirman No.101, Embong Kaliasin, Genteng, Kota Surabaya, Jawa Timur 60271 [image: facebook icon] <https://www.facebook.com/kelompoklinuxareksuroboyo/> [image: twitter icon] <https://twitter.com/KLAS_Activity> [image: instagram icon] <https://www.instagram.com/klas_activity/> klas.or.id

1 0

[mirror] no TW update repo, and a lot more missing
by Felix Miata 07 Nov '20

07 Nov '20

download.opensuse.org is much too frequently inaccessible or timing out from my SE USA location, as it is now, as reported by zypper ref unable to locate valid repodata and timouts on repomd.xml. This recurring situation is especially true late on Fridays and through the weekends. widehat.opensuse.org/update/ and ftp5.gwdg.de/pub/opensuse/update/ are both missing update/tumbleweed/. https://progress.opensuse.org/issues/new is missing a place to report this. https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE.org is missing an infrastructure component -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: mirror+unsubscribe(a)opensuse.org To contact the owner, email: mirror+owner(a)opensuse.org

1 0

[mirror] Reminder: openSUSE Leap 15.2 GA is today
by Lubos Kocman 02 Jul '20

02 Jul '20

Hello mirror admins! this is a friendly heads up that openSUSE Leap 15.2 is expected to be Globally Available today at 12 noon UTC. (Correction from 10:00 AM). All the data including GM isos were already made available specifically for mirrors (160GB, 320GB, 640GB). Progress of individual GA tasks can be seen here: https://progress.opensuse.org/projects/leap_152/issues/gantt Thank you and Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: mirror+unsubscribe(a)opensuse.org To contact the owner, email: mirror+owner(a)opensuse.org

1 1

[mirror] Reminder: openSUSE Leap 15.2 GA is on 2nd July 2020
by Lubos Kocman 30 Jun '20

30 Jun '20

Hello mirror admins! this is a friendly heads up that openSUSE Leap 15.2 is expected to be Globally Available on July 2nd 10:00 UTC. This task is tracked here: https://progress.opensuse.org/issues/61389 Progress of individual GA tasks can be seen here: https://progress.opensuse.org/projects/leap_152/issues/gantt Thank you Lubos Kocman Release Manager openSUSE Leap N��r��y隊Y��+��칻�&ޢ��'��-��w�zf��h�� ޮ�^�ˬz��

1 0

[mirror] FYI: New IPv6 addresses for scanner|download|stage|ftp.opensuse.org 2020-06-15
by Lars Vogdt 04 Jun '20

04 Jun '20

Hi We need to move to a new IPv6 subnet (2001:67c:2178::/48) with all opensuse.org machines at: 2020-06-15 All machines switch from 2620 to 2001 at this date. At the moment, they are running in both networks and should be reachable via their old and new address. If you are using DNS, no change is needed on your side. The most important machines that might have some ACL settings on some of your firewalls are: # scanner.opensuse.org 2620:113:80c0:8::20 => 2001:67c:2178:8::20 # stage.opensuse.org 2620:113:80c0:8::10 => 2001:67c:2178:8::10 # ftp.opensuse.org 2620:113:80c0:8::13 => 2001:67c:2178:8::13 # downloadcontent.opensuse.org 2620:113:80c0:8::27 => 2001:67c:2178:8::27 Note: this does not affect ACL settings for stage.opensuse.org on our side. If your mirror has an entry which allows him to sync from stage.opensuse.org, everything is fine. You might just notice scans from the different IPv6 addresses above. With kind regards, Lars -- Lars Vogdt <Lars.Vogdt(a)suse.com> - BuildOPS Engineering Team Lead - SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: mirror+unsubscribe(a)opensuse.org To contact the owner, email: mirror+owner(a)opensuse.org

1 0

[mirror] FYI: provo-mirror.opensuse.org: downtime and new IPv4 address 2020-06-05 - 2020-06-07
by Lars Vogdt 29 May '20

29 May '20

Hi Admins TL;DR: * provo-mirror.opensuse.org downtime 2020-06-05 until 2020-06-07 * 130.57.72.10 => 91.193.113.70 * 2620:113:8044:72:130:57:72:10 => deleted -- -- -- The public openSUSE servers in Provo, Utah will move into a new network and get new IPv4 addresses assigned as well during the first weekend in June: 2020-06-05 - 2020-06-07. There are currently no IPv6 (which is currently buggy anyway) addresses available in the new network. provo-mirror.opensuse.org is currently using: * 130.57.72.10 * 2620:113:8044:72:130:57:72:10 After the weekend, provo-mirror.opensuse.org will use: * 91.193.113.70 Please adjust your scripts or rsync module ACLs, if needed. Thanks in advance, Lars -- To unsubscribe, e-mail: mirror+unsubscribe(a)opensuse.org To contact the owner, email: mirror+owner(a)opensuse.org

1 0

Re: Fwd: [mirror] Suboptimal (for mirrors) download pattern by opensuse clients
by Benjamin Zeller 03 Mar '20

03 Mar '20

Hi, Sorry for top posting but I just subscribed to this ML for this conversation. I'm currently working on the libzypp/zypper http/https media backend and have suspected something like that myself. Currently we do not download multiple files at once but download one file in multiple chunks. I have a new downloader implemented that would support multiple downloads in parallel but I suffer from the problem that mirrorbrains forwards me from HTTPS to HTTP if I disable the metalink downloads in favour of downloading full files only, curl errors out in that case. I know we could disable that error but I'm not really sure that this is what we want. With metalink files we get the metalink description over https , which includes all checksums for the several chunks and then can use http connections as well because we can check if we really got what we asked for. Would be interesting to know here if we can configure mirrorbrains to just redirect to HTTPS if that's what the incoming connection is using. Not sure if we could drop Metalinks completely, however it makes the code much more complex supporting it and if it actually does more harm then good we should think about something else. As to the suggestion to use dynamic or bigger chunks: The metalink description file we download at the beginning has the list of chunks included and they are fixed. We probably could try and download multiple chunks in the same request though. Cheers, Benjamin On 3/2/20 3:04 PM, Michael Andres wrote: > > -------- Forwarded Message -------- > Subject: [mirror] Suboptimal (for mirrors) download pattern by opensuse > clients > Date: Fri, 21 Feb 2020 14:36:26 +0100 (CET) > From: Niklas Edmundsson <nikke(a)acc.umu.se> > To: mirror(a)opensuse.org > > > Hi, > > am I the only mirror admin that finds the current behavior of opensuse > clients suboptimal? > > Requests by "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" etc > seem to be done with 256 kb chunk size, always, as an example: > > GET bytes=0-262143 > /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm > GET bytes=262144-524287 > /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm > > That's a silly small size, since TCP won't be able to ramp window sizes > and get good speed before those 256k are done. Also, we get > int($filesize/256k) entries in our logs for each download. > > To make matters worse, the thing seems to do some kind of round robin > between sites, with this pattern being the most ineffective looking from > a mirror admin standpoint: > > GET bytes=2097152-2359295 > /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm > GET bytes=2621440-2883583 > /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm > > Since the OS normally does read-ahead on file system reads, it will > read-ahead after byte 2359295 in preparation for the next read(). In > this case though, that's in vain as the request never comes but the next > data read is instead byte 2621440 and forward... OS read-ahead is most > commonly in the 64kB-1MB range, so it's not unlikely that the entire > 256k gap inbetween is read from disk without being used... > > Downloading files this way is just plain stupid, IMHO. > > I don't know what problem this behavior is supposed so solve, but it's > definitely not beneficial for us as a mirror, and I think it's hurting > your end users as well. > > If you want more bandwidth from us, request larger chunks (or whole > files). The TCP window will grow and you'll get the performance (within > the limits of 10 gigabit networking for one download). > > If you want to spread the load between mirrors, use larger chunks, and > specifically avoid small chunks and striped access. > > In any case, merge requests! If you're going to request a number of > consecutive chunks, do it in one request, preferrably as one range, to > make the most of the tcp connection you've set up. > > My minimum suggestion would be to bump the chunk-size to multiple > megabytes at the minimum, possibly varying depending on download > performance, aiming for each GET taking at least a couple of seconds to > allow for TCP to ramp speed (and reduce the noise in our logs). In > extreme cases we're seeing multiple tens of GET:s each second for some > downloads, I'm guessing the rate throttles due to the RTT latency (ping > time) and not some real bandwidth limit... > > > /Nikke - admin of ftp.acc.umu.se -- Benjamin Zeller <bzeller(a)suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: mirror+unsubscribe(a)opensuse.org To contact the owner, email: mirror+owner(a)opensuse.org

5 14

[mirror] Suboptimal (for mirrors) download pattern by opensuse clients
by Niklas Edmundsson 21 Feb '20

21 Feb '20

Hi, am I the only mirror admin that finds the current behavior of opensuse clients suboptimal? Requests by "ZYpp 17.11.4 (curl 7.60.0) openSUSE-Leap-15.1-x86_64" etc seem to be done with 256 kb chunk size, always, as an example: GET bytes=0-262143 /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm GET bytes=262144-524287 /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm That's a silly small size, since TCP won't be able to ramp window sizes and get good speed before those 256k are done. Also, we get int($filesize/256k) entries in our logs for each download. To make matters worse, the thing seems to do some kind of round robin between sites, with this pattern being the most ineffective looking from a mirror admin standpoint: GET bytes=2097152-2359295 /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm GET bytes=2621440-2883583 /mirror/opensuse.org/tumbleweed/repo/oss/x86_64/libqt5-qtwebengine-5.14.1-1.5.x86_64.rpm Since the OS normally does read-ahead on file system reads, it will read-ahead after byte 2359295 in preparation for the next read(). In this case though, that's in vain as the request never comes but the next data read is instead byte 2621440 and forward... OS read-ahead is most commonly in the 64kB-1MB range, so it's not unlikely that the entire 256k gap inbetween is read from disk without being used... Downloading files this way is just plain stupid, IMHO. I don't know what problem this behavior is supposed so solve, but it's definitely not beneficial for us as a mirror, and I think it's hurting your end users as well. If you want more bandwidth from us, request larger chunks (or whole files). The TCP window will grow and you'll get the performance (within the limits of 10 gigabit networking for one download). If you want to spread the load between mirrors, use larger chunks, and specifically avoid small chunks and striped access. In any case, merge requests! If you're going to request a number of consecutive chunks, do it in one request, preferrably as one range, to make the most of the tcp connection you've set up. My minimum suggestion would be to bump the chunk-size to multiple megabytes at the minimum, possibly varying depending on download performance, aiming for each GET taking at least a couple of seconds to allow for TCP to ramp speed (and reduce the noise in our logs). In extreme cases we're seeing multiple tens of GET:s each second for some downloads, I'm guessing the rate throttles due to the RTT latency (ping time) and not some real bandwidth limit... /Nikke - admin of ftp.acc.umu.se -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke(a)acc.umu.se --------------------------------------------------------------------------- NOW (n), adv: A moment in time that has already passed. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- To unsubscribe, e-mail: mirror+unsubscribe(a)opensuse.org To contact the owner, email: mirror+owner(a)opensuse.org

1 0