LFS uses ROOT_URL to upload LFS objects during git push

[VultureX]

• 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

[zeripath]

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

[VultureX]

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 git-lfs/git-lfs#3457)

[zeripath]

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.

[VultureX]

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 : )

[ryshi]

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

[zeripath]

@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.

[ryshi]

@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.

[VultureX]

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")
}