embedded ssh won't clone on 1.19.3 #24981
Labels
issue/needs-feedback
For bugs, we need more details. For features, the feature must be described in more detail
Comments
|
Could you help to run ssh for your Gitea server and share the full logs? Like this: ssh -vvv GitUser@GiteaServer -p GiteaSshPort git-receive-pack TheOwner/TheRepo.git
# for github (demo):
ssh -vvv git@github.com -p 22 git-receive-pack wxiaoguang/playground.gitNormally you could see some verbose logs with git response: |
|
that gives a lot of interesting output! ... I'm not sure what it means ... here's the file though |
|
and here it is as "not an attachement" sorry |
|
Your Gitea & SSH server just works. For the problem itself, I can see 2 suspicious points here:
If you build your own Docker image, you need to follow the Gitea's docker mechisam strictly:
|
wxiaoguang
added
issue/needs-feedback
|
Hi g-pechorin, has the problem been solved? |
|
Nope. I haven't had a chance to try building it from source like the
instructions say
…On Fri, 2 Jun 2023, 06:10 wxiaoguang, ***@***.***> wrote:
Hi g-pechorin, has the problem been solved?
—
Reply to this email directly, view it on GitHub
<#24981 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHJNK235SM3CHLAP7KF5Q3XJFYURANCNFSM6AAAAAAYSOYSGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Reproduced the bug. It might be caused by #19815 You can try to set Any log message printed during the git protocol would cause the protocol broken. I think there are still more similar cases, while they need to be cleaned one by one. |
wxiaoguang
added a commit
to wxiaoguang/gitea
that referenced
this issue
Jun 21, 2023
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
----
Close go-gitea#24818
Close go-gitea#24222
Close go-gitea#21606
Close go-gitea#21498
Close go-gitea#25107
Close go-gitea#24981
Maybe close go-gitea#24503
Replace go-gitea#23301
Replace go-gitea#22754
And maybe more
# Conflicts:
# cmd/web.go
|
I need to try this (had an unrelated hardware failure) |
silverwind
pushed a commit
that referenced
this issue
Jun 28, 2023
More fix for #24981 * #24981 Close #22361 * #22361 There were many patches for Gitea's sub-commands to satisfy the facts: * Some sub-commands shouldn't output any log, otherwise the git protocol would be broken * Sometimes the users want to see "verbose" or "quiet" outputs That's a longstanding problem, and very fragile. This PR is only a quick patch for the problem. In the future, the sub-command system should be refactored to a clear solution. ---- Other changes: * Use `ReplaceAllWriters` to replace `RemoveAllWriters().AddWriters(writer)`, then it's an atomic operation. * Remove unnecessary `syncLevelInternal` calls, because `AddWriters/addWritersInternal` already calls it. Co-authored-by: Giteabot <teabot@gitea.io>
wxiaoguang
added a commit
to wxiaoguang/gitea
that referenced
this issue
Jun 28, 2023
More fix for go-gitea#24981 * go-gitea#24981 Close go-gitea#22361 * go-gitea#22361 There were many patches for Gitea's sub-commands to satisfy the facts: * Some sub-commands shouldn't output any log, otherwise the git protocol would be broken * Sometimes the users want to see "verbose" or "quiet" outputs That's a longstanding problem, and very fragile. This PR is only a quick patch for the problem. In the future, the sub-command system should be refactored to a clear solution. ---- Other changes: * Use `ReplaceAllWriters` to replace `RemoveAllWriters().AddWriters(writer)`, then it's an atomic operation. * Remove unnecessary `syncLevelInternal` calls, because `AddWriters/addWritersInternal` already calls it. Co-authored-by: Giteabot <teabot@gitea.io>
lunny
pushed a commit
that referenced
this issue
Jun 28, 2023
Backport #25537 More fix for #24981 * #24981 Close #22361, #25552 * #22361 * #25552 There were many patches for Gitea's sub-commands to satisfy the facts: * Some sub-commands shouldn't output any log, otherwise the git protocol would be broken * Sometimes the users want to see "verbose" or "quiet" outputs That's a longstanding problem, and very fragile. This PR is only a quick patch for the problem. In the future, the sub-command system should be refactored to a clear solution. ---- Other changes: * Use `ReplaceAllWriters` to replace `RemoveAllWriters().AddWriters(writer)`, then it's an atomic operation. * Remove unnecessary `syncLevelInternal` calls, because `AddWriters/addWritersInternal` already calls it.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
When using docker+alpine+arm6, and the embedded SSHD server, everything works up until trying to cone repository.
Running
git clonefrom the embedded ssh server just stalls "forever"Gitea Version
1.19.3-0
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
docker+alpine atop rasbian
How are you running Gitea?
docker+alpine atop rasbian
Database
SQLite
The text was updated successfully, but these errors were encountered: