[Planned maintenance] GitLab - 28th of October 2022, 7 - 10 AM (UTC)

Hi,

the GNOME Infrastructure will be undergoing a planned maintenance on gitlab.gnome.org. The service will be migrated to our Openshift platform for all of the GitLab components but the SSH endpoint. The service will be unavailable between 7 - 10 AM UTC.

Changes on our side

The SSHFP records will be updated accordingly to match the new SSH endpoints.

Changes on your side

As a result of splitting up internal GitLab components the SSH URL hostname will change from:

TO

ssh.gitlab.gnome.org

Please make sure your .ssh/config file is adapted as follows:

  Host gitlab.gnome.org
      Hostname ssh.gitlab.gnome.org

This particular migration will bring relief to the undergoing general platform slowness and consolidate services into containers and proper redundancy/load balancing.

Thanks,
Andrea

2 Likes

This maintenance is about to start.

1 Like

We’re finalizing some post-maintenance tasks, but GitLab itself is available now and can be used as usually. If you experience any problems, please reach out to us.

I have a project using Weblate for translations. Does anyone have suggestions on how to configure it to use ssh.gitlab.gnome.org?

Sorry if this should rather go into its own topic.

Edit: I reached out to the Weblate team to ask whether such a change is possible on their side.

For the last day or two every other request has been either 500 or 502’ing. Browsing repositories and searching issues are both impractically difficult. Could this be a consequence of the migration?

EDIT: Just to clarify, today (as opposed to yesterday) I can load most web pages fine. It seems to be just that the GraphQL endpoint is returning lots of 500 responses which is making it hard to browse repos etc at present.

It looks like the fingerprint for ssh.gitlab.gnome.org differs from that of the old gitlab.gnome.org. Can you confirm what the new fingerprint should be please, @averi, so people know what to trust?

There are some hiccups we’re still working on. So far it seems fine after I tuned something database-related yesterday, but we will keep an eye on it.

Please use SSHFP records to verify new fingerprints, there’s built in support on the openssh client as well to make sure they’re correct without having to verify those manually, please run:

ssh -o VerifyHostKeyDNS=yes git@ssh.gitlab.gnome.org

FYI, the issue has been resolved by the Weblate team.

What exactly is the expected output for this command if everything is correct?

SSH connection would succeed in that case, if there was a key mismatch the SSH attempt would not go through and report back a key mismatch error.

So the following is an expected correct result, I assume:

$ ssh -o VerifyHostKeyDNS=yes ssh.gitlab.gnome.org
Connection closed by 8.43.85.27 port 22

There’s the chance that some people might interpret the “Connection closed” as an unsuccessful verification.

Make sure you ssh as the git user:

ssh -o VerifyHostKeyDNS=yes git@ssh.gitlab.gnome.org

Updated the comment I made above accordingly.