Refactor path system #24818
Comments
wxiaoguang
added
type/proposal
|
Generally agree. If there is no |
It doesn't work. The "writing back" is necessary. eg: some people do this:
|
|
thing is, an application shouldn't write to /etc so if gitea needs to store such persistent changes it really should go into $HOME/.config/gitea.ini (or /var/lib/gitea/*) but this just adds more confusion as to where a setting is actually being set, as well as a full backup and restore |
This variable is mislabeled. A working directory in the classic sense is the directory where the application runs in. Not necessarily the directory where the data resides. A better name would be |
If the |
There was already a In history, the code only got patched and patched (as an open-source project, I can understand), no design, refactoring or improvement, so the situation becomes today's problems. |
I appreciate that but for a correctly configured system /etc shouldn't be writable by non-root and if it was writeable by non-root implies a system that has some serious issue if it is compromised. So if it can be assumed that /etc isn't writable by root and gitea would not run as root, where would such settings be storable by gitea?
|
Sorry I don't get the point. The whole picture in my mind is: For a fresh installation:
For an existing installation (upgrading):
(there could be some slightly different cases, IMO all of them could be covered) Does this answer your question? Or could you help to show some bad cases? |
|
my bad, I interpreted aspects of this as advocating writing to /etc/gitea/app.ini |
|
Maybe we should introduce another file to store the write-back information including tokens. |
|
It's not completely unheard of that applications write back into config, Redis does it too. But I agree, a second file would be good where we could write stuff to, e.g. |
# 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 #24818
Close #24222
Close #21606
Close #21498
Close #25107
Close #24981
Maybe close #24503
Replace #23301
Replace #22754
And maybe more
# 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
Feature Description
Gitea's path system was not well designed, it just got patched and patched and accumulated a lot of problems:
git push#25107The root problem is, Gitea tries to guess these paths, and the environment/command argument/config option affect each other.
This a a refactoring plan for improving this system and resolving the problem with minimal breaking.
There could be more details, I think this plan is feasible and stable.
Screenshots
No response
The text was updated successfully, but these errors were encountered: