github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-09 12:46:42 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

LFS uses ROOT_URL to upload LFS objects during git push #2710

New Issue
Closed
opened 2025-11-02 04:45:14 -06:00 by GiteaMirror · 8 comments
GiteaMirror commented 2025-11-02 04:45:14 -06:00
Owner
Copy Link

Originally created by @VultureX on GitHub (Jan 5, 2019).

  • Gitea version: gitea-1.6.2-windows-4.0-amd64
  • Git version: Git-2.20.1-64-bit
  • Operating system: Windows 10 1803
  • Database:
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Not relevant

Whenever I try to push new files that are tracked by LFS with a computer inside the local network the push operation fails, because it's trying to connect to the ROOT_URL defined in app.ini.
I can change the ROOT_URL to point to the local address, but then computers from outside obviously can't connect. I do not have a domain name registered, so I'm using explicit IPs. Is there a way to solve this?

"D:\Programs\Git\bin\git.exe" push --recurse-submodules=check --progress "origin" refs/heads/master:refs/heads/master Uploading LFS objects: 0% (0/1), 0 B | 0 B/s, done LFS: Put https://xxx.xxx.xxx.xxx:3000/XX/Test.git/info/lfs/objects/aed286ac1fa67fe7050ff63cac3056decd38d37743525fd06de777c80265a189: dial tcp xxx.xxx.xxx.xxx:3000: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. error: failed to push some refs to 'https://192.168.192.49:3000/XX/Test.git' Done

app.ini

[server]
ROOT_URL = https://xxx.xxx.xxx.xxx:3000/

I've tried changing the lfs url with the following command on the pc in the local network:

git config --add lfs.url https://192.168.192.49:3000/XX/Test.git/info/lfs
git config --add lfs.pushurl https://192.168.192.49:3000/XX/Test.git/info/lfs

But this had no effect

Originally created by @VultureX on GitHub (Jan 5, 2019). - Gitea version: gitea-1.6.2-windows-4.0-amd64 - Git version: Git-2.20.1-64-bit - Operating system: Windows 10 1803 - Database: - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Not relevant Whenever I try to push new files that are tracked by LFS with a computer inside the local network the push operation fails, because it's trying to connect to the ROOT_URL defined in app.ini. I can change the ROOT_URL to point to the local address, but then computers from outside obviously can't connect. I do not have a domain name registered, so I'm using explicit IPs. Is there a way to solve this? `"D:\Programs\Git\bin\git.exe" push --recurse-submodules=check --progress "origin" refs/heads/master:refs/heads/master Uploading LFS objects: 0% (0/1), 0 B | 0 B/s, done LFS: Put https://xxx.xxx.xxx.xxx:3000/XX/Test.git/info/lfs/objects/aed286ac1fa67fe7050ff63cac3056decd38d37743525fd06de777c80265a189: dial tcp xxx.xxx.xxx.xxx:3000: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. error: failed to push some refs to 'https://192.168.192.49:3000/XX/Test.git' Done` app.ini ``` [server] ROOT_URL = https://xxx.xxx.xxx.xxx:3000/ ``` I've tried changing the lfs url with the following command on the pc in the local network: ``` git config --add lfs.url https://192.168.192.49:3000/XX/Test.git/info/lfs git config --add lfs.pushurl https://192.168.192.49:3000/XX/Test.git/info/lfs ``` But this had no effect
GiteaMirror added the type/question label 2025-11-02 04:45:14 -06:00
GiteaMirror commented 2025-11-02 04:45:15 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 11, 2019):

hmm... If you have a second SSH server running on different port and use the KeyAuthorizedCommand functionality to run the gitea serv with a different app.ini for that different port, that should work. Please note however your LFS won't work if you take your machine out of that network though.

The gitea binary would need to be owned by root, not writable by anyone else, or have a bash shim to it that satisifies the above criteria. Then if you add to the sshd.conf for that second SSH server:

AuthorizedKeysCommandUser git
AuthorizedKeysCommand /path/to/gitea-or-bash-shim -c /path/to/alternative-app.ini -e git -u %u -t %t -k %k

Then when you ssh clone from that other port you should get the different results. There's probably a way of using a single ssh server with different configuration sections per requesting IP but I'm not a specialist in the configuration of ssh.

The bash shim above would be something like:

#!/bin/sh
/path/to/gitea "$@"

Owned by root with mode 644

@zeripath commented on GitHub (Jan 11, 2019): hmm... If you have a second SSH server running on different port and use the KeyAuthorizedCommand functionality to run the gitea serv with a different app.ini for that different port, that should work. Please note however your LFS won't work if you take your machine out of that network though. The gitea binary would need to be owned by root, not writable by anyone else, or have a bash shim to it that satisifies the above criteria. Then if you add to the sshd.conf for that second SSH server: ``` AuthorizedKeysCommandUser git AuthorizedKeysCommand /path/to/gitea-or-bash-shim -c /path/to/alternative-app.ini -e git -u %u -t %t -k %k ``` Then when you ssh clone from that other port you should get the different results. There's probably a way of using a single ssh server with different configuration sections per requesting IP but I'm not a specialist in the configuration of ssh. --- The bash shim above would be something like: ``` #!/bin/sh /path/to/gitea "$@" ``` Owned by root with mode 644
GiteaMirror commented 2025-11-02 04:45:15 -06:00
Author
Owner
Copy Link

@VultureX commented on GitHub (Jan 11, 2019):

Thanks for your reply zeripath.

I actually don't know much about webservers. I'm using https and I'm just running the gitea binary (on Windows). 'Simply run the binary' is what I was going for, no additional SSH servers. :) Your suggestions would only make sense if I was using SSH with an additional server besides the Gitea binary, right?

It would be great if the LFS connection url could be configured per requesting IP on the server side (via any Gitea config file), I didn't find any information about how to do this either, but I figure this should be possible.
(See also the comment from the git-lfs page https://github.com/git-lfs/git-lfs/issues/3457)

@VultureX commented on GitHub (Jan 11, 2019): Thanks for your reply zeripath. I actually don't know much about webservers. I'm using https and I'm just running the gitea binary (on Windows). 'Simply run the binary' is what I was going for, no additional SSH servers. :) Your suggestions would only make sense if I was using SSH with an additional server besides the Gitea binary, right? It would be great if the LFS connection url could be configured per requesting IP on the server side (via any Gitea config file), I didn't find any information about how to do this either, but I figure this should be possible. (See also the comment from the git-lfs page https://github.com/git-lfs/git-lfs/issues/3457)
GiteaMirror commented 2025-11-02 04:45:15 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 13, 2019):

OK I've just looked at removing the host, scheme (and user - although that's irrelevant) parts from the URLs returned from LFS. Unfortunately they're totally required. So I can't see how this can work.

The only other option I can think of is to have another version of Gitea running - but you won't be able to use sqlite for its database, you should be able to share the database if you use postgres/mysql or the link, but I think you might end up our first ever cluster user.

@zeripath commented on GitHub (Jan 13, 2019): OK I've just looked at removing the host, scheme (and user - although that's irrelevant) parts from the URLs returned from LFS. Unfortunately they're totally required. So I can't see how this can work. The only other option I can think of is to have another version of Gitea running - but you won't be able to use sqlite for its database, you should be able to share the database if you use postgres/mysql or the link, but I think you might end up our first ever cluster user.
GiteaMirror commented 2025-11-02 04:45:15 -06:00
Author
Owner
Copy Link

@VultureX commented on GitHub (Jan 16, 2019):

Hmm, bk2204 mentioned the following in the Git LFS discussion I linked:

it sounds like you want to have a ROOT_URL setting that's customized depending on the incoming interface.

This is exactly what I need. If that requires running two Gitea instances that work together somehow then I'll try this, but I don't want to create additional problems.

I'm not aware of how Gitea's git server handles git lfs push requests internally, but it seems that execution of this command uses the ROOT_URL property (even though during execution it should use the incoming remote repository url, which in the case of my client is defined as a local address)
If Gitea could use the incoming remote repository url to deduce the root or if I could add a ROOT_URL_LOCAL property that is used when the incoming connection is a local ip address then all is fixed.

Perhaps I could make a code change somewhere to facilitate this. Any pointers where to begin looking would be greatly appreciated. I'm totally not a web developer and new to Go and this project. I'll see if I can build it in the first place when I have some free time : )

@VultureX commented on GitHub (Jan 16, 2019): Hmm, bk2204 mentioned the following in the Git LFS discussion I linked: > it sounds like you want to have a ROOT_URL setting that's customized depending on the incoming interface. This is exactly what I need. If that requires running two Gitea instances that work together somehow then I'll try this, but I don't want to create additional problems. I'm not aware of how Gitea's git server handles git lfs push requests internally, but it seems that execution of this command uses the ROOT_URL property (even though during execution it should use the incoming remote repository url, which in the case of my client is defined as a local address) If Gitea could use the incoming remote repository url to deduce the root or if I could add a ROOT_URL_LOCAL property that is used when the incoming connection is a local ip address then all is fixed. Perhaps I could make a code change somewhere to facilitate this. Any pointers where to begin looking would be greatly appreciated. I'm totally not a web developer and new to Go and this project. I'll see if I can build it in the first place when I have some free time : )
GiteaMirror commented 2025-11-02 04:45:16 -06:00
Author
Owner
Copy Link

@ryshi commented on GitHub (Jan 18, 2019):

I have almost the same problem.
I installed gitea with url https://192.168.1.10/gitea/

app.ini

[server]
ROOT_URL = https://192.168.1.10/gitea/

My repo's url are

  • SSH : ssh://git@192.168.1.10:3000/john/lfs.git
  • HTTPS : https://192.168.1.10/gitea/john/lfs.git

when I clone with ssh url, lfs party of .git/config is

[lfs "https://192.168.1.10/john/lfs.git/info/lfs"]
	locksverify = false

It seems ssh or lfs service needs to handle ROOT_URL too

@ryshi commented on GitHub (Jan 18, 2019): I have almost the same problem. I installed gitea with url `https://192.168.1.10/gitea/` app.ini ``` [server] ROOT_URL = https://192.168.1.10/gitea/ ``` My repo's url are - SSH : `ssh://git@192.168.1.10:3000/john/lfs.git` - HTTPS : `https://192.168.1.10/gitea/john/lfs.git` when I clone with ssh url, lfs party of .git/config is ``` [lfs "https://192.168.1.10/john/lfs.git/info/lfs"] locksverify = false ``` It seems ssh or lfs service needs to handle ROOT_URL too
GiteaMirror commented 2025-11-02 04:45:16 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 18, 2019):

@ryshi There is no SSH transport for LFS. That's the protocol I'm afraid.

@VultureX I'm not sure where you would get this information. Over HTTP transports you may find something on the request object but I'm not sure that it will be totally trustworthy and probably won't work in proxied environments - you would basically have to look through the Gitea source looking for references to LFS and adjust the app_url every time, I guess make getting the appurl a function taking the http request so you can then add in the correct value.

Over SSH I'm really not sure at all. You may find that SSH sets an environment variable but I haven't a clue if it does set this.

@zeripath commented on GitHub (Jan 18, 2019): @ryshi There is no SSH transport for LFS. That's the protocol I'm afraid. @VultureX I'm not sure where you would get this information. Over HTTP transports you may find something on the request object but I'm not sure that it will be totally trustworthy and probably won't work in proxied environments - you would basically have to look through the Gitea source looking for references to LFS and adjust the app_url every time, I guess make getting the appurl a function taking the http request so you can then add in the correct value. Over SSH I'm really not sure at all. You may find that SSH sets an environment variable but I haven't a clue if it does set this.
GiteaMirror commented 2025-11-02 04:45:16 -06:00
Author
Owner
Copy Link

@ryshi commented on GitHub (Jan 18, 2019):

@zeripath I noticed the lfs url was created in .git/config

ssh://git@192.168.1.10:3000/john/lfs.git  -> https://192.168.1.10/john/lfs.git/info/lfs

as you said, it should include the ROOT_URL, just like https://192.168.1.10/gitea/john/lfs.git/info/lfs

I'm not sure if it's done by server or client.

@ryshi commented on GitHub (Jan 18, 2019): @zeripath I noticed the lfs url was created in `.git/config` ``` ssh://git@192.168.1.10:3000/john/lfs.git -> https://192.168.1.10/john/lfs.git/info/lfs ``` as you said, it should include the ROOT_URL, just like `https://192.168.1.10/gitea/john/lfs.git/info/lfs` I'm not sure if it's done by server or client.
GiteaMirror commented 2025-11-02 04:45:16 -06:00
Author
Owner
Copy Link

@VultureX commented on GitHub (Jan 27, 2019):

OK, it took me a while to get going on Windows since the documentation to run from source is lacking.

A high level view of the code changes in server.go that solved my problem:

// AppURL returns the root url from settings based on the requesting IP
func (v *RequestVars) AppURL() string {
	if IsPrivateIP(v.RequestingIP) {
		return setting.LocalURL
	}
	return setting.AppURL
}

// ObjectLink builds a URL linking to the object.
func (v *RequestVars) ObjectLink() string {
	return v.AppURL() + path.Join(v.User, v.Repo+".git", "info/lfs/objects", v.Oid)
}

// VerifyLink builds a URL for verifying the object.
func (v *RequestVars) VerifyLink() string {
	return v.AppURL() + path.Join(v.User, v.Repo+".git", "info/lfs/verify")
}
@VultureX commented on GitHub (Jan 27, 2019): OK, it took me a while to get going on Windows since the documentation to run from source is lacking. A high level view of the code changes in server.go that solved my problem: ``` // AppURL returns the root url from settings based on the requesting IP func (v *RequestVars) AppURL() string { if IsPrivateIP(v.RequestingIP) { return setting.LocalURL } return setting.AppURL } // ObjectLink builds a URL linking to the object. func (v *RequestVars) ObjectLink() string { return v.AppURL() + path.Join(v.User, v.Repo+".git", "info/lfs/objects", v.Oid) } // VerifyLink builds a URL for verifying the object. func (v *RequestVars) VerifyLink() string { return v.AppURL() + path.Join(v.User, v.Repo+".git", "info/lfs/verify") } ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2710
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?