mirror

mirror@lists.centos.org

4577 discussions

mirror.spreitzer.ch - maintenance announcement
by Sascha Spreitzer 04 May '16

04 May '16

Hi mirror.spreitzer.ch will be offline several hours in the next 2-3 days. This is due to a migration from software raid5 mdadm to btrfs raid5 of the virtualization host. Kind regards Sascha

2 2

Mirror Officially Request
by ali hejazi 03 May '16

03 May '16

Dear sir or madam We have created a mirror server for CentOS and the mirror is completely being synced in a few minutes. Please check the status of our server and define it officially. HTTP: http://mirror.aminidc.com/centos/ FTP: ftp://mirror.aminidc.com/centos/ RSYNC: rsync://mirror.aminidc.com/centos/ Sync schedule: Every 6 hrs Bandwidth: 1 Gbps Location: Iran, Islamic Republic of Sponsor: Amin IDC Sponsor URL: http://www.aminidc.com IP to authorize: 185.142.156.14 Email contact: mr.hejazi(a)gmail.com Mirroring AltArch : no With best regards, Ali

2 1

Mirror Update
by Patrick Beane 03 May '16

03 May '16

Hello, Mirror information has changed, please update accordingly. ----- HTTP: http://mirror.fusioncloud.co/pub/centos/ FTP: RSYNC: rsync://rsync.fusioncloud.co/mirror/centos Sync schedule: Every 6 hrs Bandwidth: 10 Gbps Location: US Sponsor: Fusion Cloud IP to authorize: 74.91.18.146 IPv6: 2604:4300:a:4d::a Email contact: patrick(a)fusioncloud.co Mirroring AltArch : no ----- Added IPv6 support, RSYNC access. Bandwidth also updated to 10 Gbps. Thank you, Patrick Beane

2 1

New source IP address used for rsync
by Fernando Carolo 03 May '16

03 May '16

Hi, Could you please allow rysnc access from 131.0.24.130 for mirror.globo.com? We are getting a new set of machines for our mirror setup, connected to a different network segment on our side. Best, -- Fernando Carolo :: Globo.com +55 21 2483.6705 @fcarolo

2 1

Mirror Capacity
by ali hejazi 03 May '16

03 May '16

Hi guys Please help me for what the capacity needed for CentOS mirror. 15Tb or 15TB ?? Regards, Ali

3 2

New Mirror
by Benjamin Rose 25 Apr '16

25 Apr '16

Hi all, Princeton University Department of Mathematics has a new mirror host and would like to be made official for mirroring CentOS content. HTTP: http://mirror.math.princeton.edu/pub/centos RSYNC: rsync://mirror.math.princeton.edu/pub/centos Sync schedule: Every 4 hrs Bandwidth: 10-gigabit to University core. Available on I2. Location: Princeton, NJ, USA Sponsor: Princeton University Department of Mathematics Sponsor URL: http://www.math.princeton.edu/ IP to authorize: 128.112.18.21 Email contact: compudoc(a)math.princeton.edu Mirroring AltArch : yes There's two targets: mirror.math.princeton.edu/pub/centos mirror.math.princeton.edu/pub/centos-vault The former is currently synced from wpi.edu. The latter is from mirrors.kernel.org and I believe contains the AltArch stuff. Thanks, Ben

2 1

Change of mirror URL's
by Danny Horne 25 Apr '16

25 Apr '16

Hi Could you please change our mirror to point to the following URL's HTTP: http://centos.trisect.eu FTP: ftp://centos.trisect.eu/CentOS/ RSYNC: rsync://centos.trisect.eu/CentOS/ Sync schedule: Every 6 hrs Bandwidth: 250Mb/s Location: Roubaix, France Sponsor: Trisect Networks Sponsor URL: N/A IP to authorize: 164.132.220.20 / 2001:41d0:1:f41f:20::1 Email contact: hostmaster(a)trisect.uk Mirroring AltArch : No Thanks

2 1

Re: [CentOS-mirror] Update Mirrror [DE]
by Fabian Arrotin 25 Apr '16

25 Apr '16

On 22/04/16 07:13, mirror(a)cuegee.net wrote: > Hello folks, > please update my mirror information: > > ----- > HTTP: http://mirror.cuegee.de/centos/ > FTP: > RSYNC: rsync://mirror.cuegee.de/centos/ > > Sync schedule: Every 4 hrs > Bandwidth: 1 Gbps > Location: DE > Sponsor: cuegee it gmbh > Sponsor URL: https://cuegee.de > IP to authorize: 185.144.238.4 > Email contact: mirror at cuegee.net > Mirroring AltArch : no > ----- > > (Added rsync support and changed IP). > > Best regards > Alexander Schaber > Updated, cheers, -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 0

Update Mirrror [DE]
by mirror＠cuegee.net 22 Apr '16

22 Apr '16

Hello folks, please update my mirror information: ----- HTTP: http://mirror.cuegee.de/centos/ FTP: RSYNC: rsync://mirror.cuegee.de/centos/ Sync schedule: Every 4 hrs Bandwidth: 1 Gbps Location: DE Sponsor: cuegee it gmbh Sponsor URL: https://cuegee.de IP to authorize: 185.144.238.4 Email contact: mirror at cuegee.net Mirroring AltArch : no ----- (Added rsync support and changed IP). Best regards Alexander Schaber cuegee it gmbh | Elisabethstraße 11 | 40217 Düsseldorf Sitz: Düsseldorf | Registergericht: Düsseldorf | Registernummer: HRB 76270 Geschäftsführer: Alexander H. Schaber

1 0

Re: [CentOS-mirror] centos mirror @ seas.harvard.edu
by Chuck Anderson 22 Apr '16

22 Apr '16

On Fri, Apr 22, 2016 at 12:31:31AM -0400, Chuck Anderson wrote: > On Fri, Apr 22, 2016 at 04:04:17AM +0300, Anssi Johansson wrote: > > 22.4.2016, 0.48, Chuck Anderson kirjoitti: > > >>You could also try without --delay-updates, which also triggers this > > >>requirement to know the full file list in advance. > > > > > >But not using --delay-updates means that the yum repo could be in an > > >inconsistent/nonfuctional state until the sync finishes. That isn't > > >good for a public mirror. > > > > If also using --delete-delay, the files to be deleted will be > > deleted only at the end of sync, reducing the chances of anything > > breaking. Although I see your point, I believe the base repositories > > (os, updates, extras, fasttrack etc) would end up getting synced in > > such a sequence that yum won't get confused. The repodata directory > > tends to get synced last, and it is not harmful if there are .rpm > > files on the mirror that are not yet referenced in the repodata. > > "tends to get synced last" isn't something to rely on. > > Instead, you could sync everything except the repodata, then do a 2nd > sync of just the repodata. I should correct my statement above. The first sync should sync everything except the repodata/ directories, and not do any --delete. The second sync should then do --delay-updates on the full tree. There was a long discussion about this on the Red Hat mirror list in 2009. It is probably just easier to always use --delay-updates --delete-delay so you dont have to get things "just right" with the manual methods. You might also need to increase --timeout if you are having problems with timeouts...y Some excerpts from the 2009 discussion: > rsync pulls files in sort order, so repodata comes before many > packages. If you pull fast the time interval between repodata and all > the following is short and the probability of mismatch is small. But > if it takes longer, or there's a lot yet to pull after repodata, it > may become a problem. Given the number of client updates, even a small > fraction of misses becomes a big number over time, and users will > complain. > > A way around --delay-updates is to have a multi-pass rsync which first > > transfers rpms only w/o --delete*, then transfers everything w/o > > --delete* (repodata including rpms to avoid any racing between data > > and metadata) and finally does a full rsync w/ --delete* options > > (again full for avoiding racing problems). That's the way I used it > > before rsync (on my mirror) had the delay options. > A 2-pass is enough, just use delay-updates in the second one. It's > much smaller so won't be a big hit and will be short enough to > minimize incoherences.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

mirror