Port 22: No route to host when pushing to Self-Hosted Gitlab via Merge Request

[Armaldio]

Describe the issue

Hello

I'm having a hard time pushing changes from Weblate to Self-Hosted GitLab merge request

I have successfully pulled from an ssh URL: ssh://xxx:port/group/project.git
But each time I hit the push button, I get this error:

ssh: connect to host xxx port 22: No route to host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Of course, port 22 is not accessible. I have specified the port in the URL: it's not 22

Is there any way I have misconfigured something ?

Thanks in advance

I already tried

• I've read and searched the documentation.
• I've searched for similar issues in this repository.

Steps to reproduce the behavior

1. Setup self-hosted GitLab instance
2. Install Weblate using docker
3. set: WEBLATE_GITLAB_USERNAME, WEBLATE_GITLAB_HOST, WEBLATE_GITLAB_TOKEN
4. Create a project
5. Create a component and import strings from a GitLab repo
6. Modify a translation using Weblate
7. Commit through Weblate
8. Push through Weblate
9. Get the error.

Expected behavior

Since I have specified the port to use in the URL, it should not use default port 22

Screenshots

Exception traceback

k-weblate-1   | gunicorn stderr | [2023-03-27 08:38:14,568: INFO/363] xxx: updating repository
k-weblate-1   | gunicorn stderr | [2023-03-27 08:38:15,574: INFO/363] xxx: update took 1.00 seconds
k-weblate-1   | gunicorn stderr | [2023-03-27 08:38:15,577: INFO/363] xxx: repository up to date at b148bb52df7fd1a5f329eaea6f6cd9ad3584b35d
k-weblate-1   | gunicorn stderr | [2023-03-27 08:38:15,612: INFO/363] xxx: pushing to remote repo
k-weblate-1   | 2023-03-27 08:38:15,665 INFO reaped unknown pid 1963 (exit status 255)
k-weblate-1   | gunicorn stderr | [2023-03-27 08:38:15,665: WARNING/363] Could not push the repo: RepositoryException: ssh: connect to host xxx port 22: No route to host
k-weblate-1   | gunicorn stderr | fatal: Could not read from remote repository.
k-weblate-1   | gunicorn stderr | 
k-weblate-1   | gunicorn stderr | Please make sure you have the correct access rights
k-weblate-1   | gunicorn stderr | and the repository exists.
k-weblate-1   | gunicorn stderr |  (128)

How do you run Weblate?

Docker container

Weblate versions

• Weblate: 4.16.4
• Django: 4.1.7
• siphashc: 2.1
• translate-toolkit: 3.8.6
• lxml: 4.9.2
• Pillow: 9.4.0
• nh3: 0.2.8
• python-dateutil: 2.8.2
• social-auth-core: 4.4.0
• social-auth-app-django: 5.1.0
• django-crispy-forms: 2.0
• oauthlib: 3.2.2
• django-compressor: 4.3.1
• djangorestframework: 3.14.0
• django-filter: 22.1
• django-appconf: 1.0.5
• user-agents: 2.2.0
• filelock: 3.10.0
• rapidfuzz: 2.13.7
• openpyxl: 3.1.2
• celery: 5.2.7
• django-celery-beat: 2.5.0
• kombu: 5.2.4
• translation-finder: 2.15
• weblate-language-data: 2023.3
• html2text: 2020.1.16
• pycairo: 1.23.0
• pygobject: 3.42.2
• diff-match-patch: 20200713
• requests: 2.28.2
• django-redis: 5.2.0
• hiredis: 2.2.2
• sentry_sdk: 1.16.0
• Cython: 0.29.33
• misaka: 2.1.1
• GitPython: 3.1.31
• borgbackup: 1.2.3
• pyparsing: 3.0.9
• pyahocorasick: 2.0.0
• python-redis-lock: 4.0.0
• charset-normalizer: 3.1.0
• Python: 3.11.2
• Git: 2.30.2
• psycopg2: 2.9.5
• psycopg2-binary: 2.9.5
• phply: 1.2.6
• ruamel.yaml: 0.17.21
• tesserocr: 2.6.0
• boto3: 1.26.92
• zeep: 4.2.1
• aeidon: 1.12
• iniparse: 0.5
• mysqlclient: 2.1.1
• Mercurial: 6.3.3
• git-svn: 2.30.2
• git-review: 2.3.1
• Redis server: 7.0.10
• PostgreSQL server: 15.2
• Database backends: django.db.backends.postgresql
• Cache backends: default:RedisCache, avatar:FileBasedCache
• Email setup: django.core.mail.backends.smtp.EmailBackend: 127.0.0.1
• OS encoding: filesystem=utf-8, default=utf-8
• Celery: redis://cache:6379/1, redis://cache:6379/1, regular
• Platform: Linux 5.10.0-19-cloud-amd64 (x86_64)

Weblate deploy checks

SystemCheckError: System check identified some issues:

CRITICALS:
?: (weblate.E003) Cannot send e-mail ([Errno 111] Connection refused), please check EMAIL_* settings.
	HINT: https://docs.weblate.org/en/weblate-4.16.4/admin/install.html#out-mail
?: (weblate.E012) The server e-mail address should be changed from its default value
	HINT: https://docs.weblate.org/en/weblate-4.16.4/admin/install.html#production-email
?: (weblate.E013) The "From" e-mail address should be changed from its default value
	HINT: https://docs.weblate.org/en/weblate-4.16.4/admin/install.html#production-email

WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
?: (security.W018) You should not have DEBUG set to True in deployment.

INFOS:
?: (weblate.I021) Error collection is not set up, it is highly recommended for production use
	HINT: https://docs.weblate.org/en/weblate-4.16.4/admin/install.html#collecting-errors
?: (weblate.I028) Backups are not configured, it is highly recommended for production use
	HINT: https://docs.weblate.org/en/weblate-4.16.4/admin/backup.html

System check identified 9 issues (1 silenced).

Additional context

No response

[github-actions]

This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger.

In case your question is already answered, making a donation is the right way to say thank you!

[nijel]

Check networking setup:

• does DNS work properly?
• is it using IPv4 or IPv6 and is that routed properly?
• what kind of networking do you use in Docker?

[Armaldio]

Hello,

• DNS is working properly
• Yes, I think it's IPv6
• docker-compose.yml similar to the one provided, without external network

It still seems weird to me that the behavior to push is different that the one to pull ?!

[nijel]

I don't think it's related to the push, but something has changed in the networking meanwhile.

Docker network using the same IPv4 range as some others is a typical example – it works sometimes depending on what lands in ARP cache.

[Armaldio]

Are you sure it's a Docker issue ?
Seems to me that everything is right, except that Weblate is not using the right port.

[nijel]

Is your component push url also including the port?

[Armaldio]

Sure
I've tried first without specifying it and then specifying pull the same as push (ssh://git@xxx:220xx/xxx/xxx.git)

[nijel]

Weblate does no processing here – it just configures these URLs in git and calls git push. So it looks weird that one way it would work and the other way not.

[Armaldio]

Is there any way I can try to debug this or show logs ?

[nijel]

The repository is stored in /data/vcs/PROJECT/COMPONENT/, you can check the content of .git/config whether url and pushurl match what is configured in Weblate.

[Armaldio]

Indeed, the URLs are not right:

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = ssh://git@xxx:220xxx/xxx/xxx.git
	fetch = +refs/heads/*:refs/remotes/origin/*
	tagOpt = --no-tags
	pushurl = ssh://git@xxx:220xxx/xxx/xxx.git
[branch "dev"]
	remote = origin
	merge = "refs/heads/dev"
[user]
	name = Weblate
	email = noreply@weblate.org
[push]
	default = current
[remote "weblate"]
	pushurl = git@xxx:weblate/xxx.git

The last push URL, the Weblate remote (what is it ?) is missing the port

[nijel]

Ah, I didn't notice that in the initial post.

In the case of merge requests, Weblate uses the GitLab API to create a fork and then uses whatever GitLab returns as an SSH URL for the repository. Would it be possible to configure GitLab so that it reports a valid SSH URL?

As a workaround, you can configure push branch in Weblate, it will then push to the existing repository using the configured push URL. See https://docs.weblate.org/en/latest/admin/continuous.html#pushing-changes-from-weblate for more info.

[Armaldio]

Once, my GitLab config was fixed, it started passing this step!
Still, more errors ahead

Thanks a lot

For reference, if you are using custom ports for GitLab, also set this config to the port you're using:

gitlab_rails['gitlab_shell_ssh_port'] = PORT

[github-actions]

The issue you have reported is now resolved. If you don’t feel it’s right, please follow its labels to get a clue for further steps.

• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.