Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSH push error on relative unix socket address #17833

Closed
mamins1376 opened this issue Nov 27, 2021 · 2 comments · Fixed by #17836
Closed

SSH push error on relative unix socket address #17833

mamins1376 opened this issue Nov 27, 2021 · 2 comments · Fixed by #17836

Comments

@mamins1376
Copy link

Gitea Version

Gitea version 1.15.6 built with GNU Make 4.1, go1.16.9 : bindata, sqlite, sqlite_unlock_notify

Git Version

git version 2.20.1

Operating System

Debian Buster

How are you running Gitea?

I downloaded the binray from releases page and activated the systemd service.

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

Using a relative address for HTTP_ADDR when PROTOCOL is unix would result in push failure:

remote: Resolving deltas: 100% (100/100), done.
remote:
remote: Gitea: Internal Server Error
remote: Unable to contact gitea: Post "http://unix/api/internal/hook/pre-receive/user/repo": dial unix socket: connect: no such file or directory
remote: Gitea: Internal Server Error

Screenshots

No response

@zeripath
Copy link
Contributor

zeripath commented Nov 27, 2021

What is your LOCAL_ROOT_URL and PROTOCOL.


Now I understand what you're saying.

We never intended to support relative addresses for unix sockets, so there's no normalisation of the "address" and I expect that the socket that is being looked for is relative to where your running Gitea from.

This location will be different when running Gitea serv from when running Gitea web.

If you are keen for relative paths to be supported please define where you think they should be relative from and why.

In the meantime use absolute paths.

@mamins1376
Copy link
Author

The point is they should be resolved the same way in any context, web or hooks.

It looks like currently they are resolved relative to current working directory which is different than server worker when gitea is invoked to receive a push.

Personally I'd prefer resolution to be relative to executable binary, but the alternatives are config file and server working directory.

zeripath added a commit to zeripath/gitea that referenced this issue Nov 27, 2021
Make relative unix sockets absolute by making them absolute against the AppWorkPath

Fix go-gitea#17833

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit that referenced this issue Nov 27, 2021
Make relative unix sockets absolute by making them absolute against the AppWorkPath

Fix #17833

## ⚠️ BREAKING ⚠️ 

Prior to this PR relative unix sockets would have been asserted to be relative to the current working directory that gitea, gitea serv, hook and manager etc were running in. Hooks and Serv would have failed to work properly under this situation so we expect that although this is a technically breaking change the previous situation was already broken.

Signed-off-by: Andrew Thornton <art27@cantab.net>
Chianina pushed a commit to Chianina/gitea that referenced this issue Mar 28, 2022
Make relative unix sockets absolute by making them absolute against the AppWorkPath

Fix go-gitea#17833

## ⚠️ BREAKING ⚠️ 

Prior to this PR relative unix sockets would have been asserted to be relative to the current working directory that gitea, gitea serv, hook and manager etc were running in. Hooks and Serv would have failed to work properly under this situation so we expect that although this is a technically breaking change the previous situation was already broken.

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants