Mirror: ftp.acc.umu.se domain move

[ZNikke]

Hi!

The contact information, and preferably the host/mirror name, for the
mirror provided by Academic Computer Club (ACC) needs to be changed as
ACC is moving to a new domain.

Background: Umeå University has decided that non-official services are
no longer allowed to exist as a sub domain to umu.se. As a consequence
of this we are moving all services from the acc.umu.se domain.

Contact email:

Changes from ftp-adm@acc.umu.se to ftp-adm@accum.se. The old email
address will stop working sometime in the future.

File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name. Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).

Remove mention of Umeå University:

Where appropriate, refer to us as:

Academic Computer Club in Umeå, Sweden

ie removing any mention of Umeå University.

Available bandwidth:

While not related to the domain move, we'd like to inform you that the
file archive now enjoys 200 Gbps connectivity to SUNET. Our servers
can't handle this quite yet, but we're looking at scaling up by
refreshing server hardware etc.

[lazka]

Thanks!

[Biswa96]

Is there any official statement or notice about this domain change?

[lazka]

All done:

• msys2/MSYS2-packages@fd9d412
• msys2/msys2-main-server@3e6965b
• 118af59

Is there any official statement or notice about this domain change?

The old domain has the announcement on top

[lazka]

@ZNikke hey, just wondering, are you using --delay-updates (see https://www.msys2.org/dev/mirrors/#adding-a-new-mirror) with rsync when syncing the mirror? There was just an error due to a repo signature being out of sync in CI and while rsync is not atomic there, it should be very unlikely with --delay-updates.

[ZNikke]

@lazka We're syncing with --delay-updates, but we're also leveraging the lastupdate and lastsync files to do a quick-update when there's been no change.

If the lastupdate isn't getting updated appropriately things will get out of sync, if you give me some kind of timeframe I can give you the short sync log that gives the view from our side on this.

Alternatively, if your CI stuff isn't handling errors/timeouts gracefully you might have talked to the frontend that's been acting up periodically due to Reasons Unknown. This is my guess since we've had one of these hickups during christmas. We're trying to figure out why, but since it only hits in production load after a week or three it's a slow process... Most http clients does the right thing (ie trying the next IP) when there is no life sign at all, but when the server is alive enough to start answering but takes a looong time doing it we've seen all sorts of things happen.

[lazka]

Ah, thank you, all good then. lastupdate/sync shouldn't change anything.

The error case here was that our CI downloaded the DB file and the matching signature file, and the signature check failed, suggesting that one of the files was old and one was new. Could also be that there was an error response and the signature check didn't handle that properly, hard to say.

It just smelled like delay-updates being missing, but since that's not the case, and it only happened once, it's not worth investigating it further imo.

thanks again