Gitea should offer a configcheck command #1177

New Issue

GiteaMirror · 2025-11-02T03:51:28-06:00

GiteaMirror commented

2025-11-02 03:51:28 -06:00

Originally created by @stblassitude on GitHub (Oct 22, 2017).

Gitea version (or commit ref): 1.2.0

Using the FreeBSD port for Gitea on FreeBSD 11.1.

Description

After upgrading to Gitea 1.2, Gitea won't start if the config file cannot be written by the user Gitea is running under:

[...s/setting/setting.go:859 NewContext()] [E] Error saving generated JWT Secret to custom config: open /usr/local/etc/gitea/conf/app.ini: permission denied

This is due to the security/INTERNAL_TOKEN option not being set, and Gitea being unable to add it to the config itself.

Start scripts should be able to verify the configuration and print appropriate error messages, before trying to start Gitea as a daemon.

Originally created by @stblassitude on GitHub (Oct 22, 2017). - Gitea version (or commit ref): 1.2.0 Using the FreeBSD port for Gitea on FreeBSD 11.1. ## Description After upgrading to Gitea 1.2, Gitea won't start if the config file cannot be written by the user Gitea is running under: ``` [...s/setting/setting.go:859 NewContext()] [E] Error saving generated JWT Secret to custom config: open /usr/local/etc/gitea/conf/app.ini: permission denied ``` This is due to the security/INTERNAL_TOKEN option not being set, and Gitea being unable to add it to the config itself. Start scripts should be able to verify the configuration and print appropriate error messages, before trying to start Gitea as a daemon.

GiteaMirror added the type/proposal label 2025-11-02 03:51:28 -06:00

GiteaMirror commented

2025-11-02 03:51:28 -06:00

@bkcsoft commented on GitHub (Nov 1, 2017):

In this case, there's nothing wrong with the config file itself, so a verification wouldn't help. The issue is that Gitea can't write to the config-file, hence it fails. With that said, having a gitea admin config command for verification (and maybe other things) would be nice.

@bkcsoft commented on GitHub (Nov 1, 2017): In this case, there's nothing wrong with the config file itself, so a verification wouldn't help. The issue is that Gitea can't write to the config-file, hence it fails. With that said, having a `gitea admin config` command for verification (and maybe other things) would be nice.

GiteaMirror commented

2025-11-02 03:51:29 -06:00

@stblassitude commented on GitHub (Nov 1, 2017):

A mandatory config key missing is an error in the config file. The fact that Gitea might be able to fix that automatically doesn't mean its not an error. Otherwise, Gitea would continue to run without the key being set.

@stblassitude commented on GitHub (Nov 1, 2017): A mandatory config key missing is an error in the config file. The fact that Gitea might be able to fix that automatically doesn't mean its not an error. Otherwise, Gitea would continue to run without the key being set.

GiteaMirror commented

2025-11-02 03:51:29 -06:00

@bkcsoft commented on GitHub (Nov 1, 2017):

Gitea needs to generate and write this token on each start-up, having the config file in read-only is the error.

@bkcsoft commented on GitHub (Nov 1, 2017): Gitea needs to generate and write this token on each start-up, having the config file in read-only is the error.

GiteaMirror commented

2025-11-02 03:51:29 -06:00

@stblassitude commented on GitHub (Nov 1, 2017):

That makes even less sense. Why would it need to be written to the config file, if it is recomputed at every start?

And why do you insist that Gitea must be able to write the config file?

@stblassitude commented on GitHub (Nov 1, 2017): That makes even less sense. Why would it need to be written to the config file, if it is recomputed at every start? And why do you insist that Gitea must be able to write the config file?

GiteaMirror commented

2025-11-02 03:51:29 -06:00

@bkcsoft commented on GitHub (Nov 1, 2017):

It needs to be written to a file (the config was available so it ended up there) because gitea serv needs to know about it. I don't remember why it had to be recomputed on every restart, but my guess is #becausesecurity 🙄

As for Gitea needing to write the config, that's because the initial setup in only available in the WebUI (therefore needs to be managed by Gitea itself), and that one needs to write the config to disk afterwards

Edit: It's not perfect, but it's what we have. PRs welcome :trollface:

@bkcsoft commented on GitHub (Nov 1, 2017): It needs to be written to _a_ file (the config was available so it ended up there) because `gitea serv` needs to know about it. I don't remember why it had to be recomputed on every restart, but my guess is #becausesecurity 🙄 As for Gitea needing to write the config, that's because the initial setup in only available in the WebUI (therefore needs to be managed by Gitea itself), and that one needs to write the config to disk afterwards Edit: It's not perfect, but it's what we have. PRs welcome :trollface:

GiteaMirror commented

2025-11-02 03:51:29 -06:00

@lunny commented on GitHub (Nov 2, 2017):

Another reason except installation is because Gitea in fact provides serval sub command, gitea web, gitea serve, gitea hook. They are comminuted each other via the same database at past
and should be via internal HTTP in future(partially implementation). This token is the key to keep the communication more secure. Any better idea about it then we can avoid to write data to the config file. Or maybe we could write the token to another standalone file.

@lunny commented on GitHub (Nov 2, 2017): Another reason except installation is because Gitea in fact provides serval sub command, `gitea web`, `gitea serve`, `gitea hook`. They are comminuted each other via the same database at past and should be via internal HTTP in future(partially implementation). This token is the key to keep the communication more secure. Any better idea about it then we can avoid to write data to the config file. Or maybe we could write the token to another standalone file.

GiteaMirror commented

2025-11-02 03:51:29 -06:00

@lafriks commented on GitHub (Nov 2, 2017):

@lunny or let's move such data to database setting table

@lafriks commented on GitHub (Nov 2, 2017): @lunny or let's move such data to database `setting` table

GiteaMirror commented

2025-11-02 03:51:30 -06:00

@lunny commented on GitHub (Nov 2, 2017):

@lafriks don't want gitea serv / update / hook to visit database directly in future.

@lunny commented on GitHub (Nov 2, 2017): @lafriks don't want `gitea serv / update / hook` to visit database directly in future.

GiteaMirror commented

2025-11-02 03:51:30 -06:00

@stblassitude commented on GitHub (Nov 2, 2017):

Storing this secret in the config file is acceptable, but there should be documentation on what it is used for, and how to create one yourself, if you prefer to keep the config file readonly and managed outside of Gitea.

From reading the source, it appears that the only requirement for a value is a non-empty string; however, a sensibly complex random string is preferreable. In the FreeBSD port, a random number is generated with openssl, producing a similar value to the code in modules/setting/setting.go.

To get back to the original feature request: while it's nice that Gitea can be set up through a web browser, there a re scenarios in which it is preferrable for the config file to be read-only to the Gitea user, and the config file contents being managed by some configuration management tool. It would be great if Gitea would support this scenario with appropriate error messages.

The standard gitea web output is extremely verbose and will likely be logged at debug level or not at all. This is why a seperate command to check the configuration and present appropriate hints on configuration problems is desirable.

Alternatively, the output form gitea web should be reduced to major events only, so that it can be logged as syslog daemon.notice or higher. If this can be configured already, I apologize, but I did not find a log setting that seems to apply to the console output.

@stblassitude commented on GitHub (Nov 2, 2017): Storing this secret in the config file is acceptable, but there should be documentation on what it is used for, and how to create one yourself, if you prefer to keep the config file readonly and managed outside of Gitea. From reading the source, it appears that the only requirement for a value is a non-empty string; however, a sensibly complex random string is preferreable. In the FreeBSD port, a random number is generated with openssl, producing a similar value to the code in modules/setting/setting.go. To get back to the original feature request: while it's nice that Gitea can be set up through a web browser, there a re scenarios in which it is preferrable for the config file to be read-only to the Gitea user, and the config file contents being managed by some configuration management tool. It would be great if Gitea would support this scenario with appropriate error messages. The standard `gitea web` output is extremely verbose and will likely be logged at debug level or not at all. This is why a seperate command to check the configuration and present appropriate hints on configuration problems is desirable. Alternatively, the output form `gitea web` should be reduced to major events only, so that it can be logged as syslog daemon.notice or higher. If this can be configured already, I apologize, but I did not find a log setting that seems to apply to the console output.

GiteaMirror commented

2025-11-02 03:51:30 -06:00

@stblassitude commented on GitHub (Nov 2, 2017):

@lunny For gitea serv etc. to communicate with the daemon, you could consider HTTP over unix socket. This way, access is controlled by file system permissions.

A quick google suggest for example: https://gist.github.com/teknoraver/5ffacb8757330715bcbcc90e6d46ac74

@stblassitude commented on GitHub (Nov 2, 2017): @lunny For `gitea serv` etc. to communicate with the daemon, you could consider HTTP over unix socket. This way, access is controlled by file system permissions. A quick google suggest for example: https://gist.github.com/teknoraver/5ffacb8757330715bcbcc90e6d46ac74

GiteaMirror commented

2025-11-02 03:51:30 -06:00

@lunny commented on GitHub (Nov 3, 2017):

@stblassitude thanks, I will check that.

@lunny commented on GitHub (Nov 3, 2017): @stblassitude thanks, I will check that.

GiteaMirror commented

2025-11-02 03:51:31 -06:00

@lafriks commented on GitHub (Nov 3, 2017):

@lunny @stblassitude gitea does that already if gitea is set to listen on socket using fcgi

@lafriks commented on GitHub (Nov 3, 2017): @lunny @stblassitude gitea does that already if gitea is set to listen on socket using fcgi

GiteaMirror commented

2025-11-02 03:51:31 -06:00

@ghost commented on GitHub (Jan 5, 2018):

Writing the configuration file automatically, which is meant to be customized by the user, is very bad practise which I'd consider being a bug. In fact, like @stblassitude said, it's very complex to automate configuration deployment in an idempotent manner. If there was a hard requirement to write such information into a file, it might get written into another file, but not in the configuration file, which is meant for the user to customize the runtime of gitea. Furthermore +1 on this feature request. It would be very nice to verify the configuration before restarting a service automatically on a configuration file update.

@ghost commented on GitHub (Jan 5, 2018): Writing the configuration file automatically, which is meant to be customized by the user, is very bad practise which I'd consider being a bug. In fact, like @stblassitude said, it's very complex to automate configuration deployment in an idempotent manner. If there was a hard requirement to write such information into a file, it might get written into another file, but not in the configuration file, which is meant for the user to customize the runtime of gitea. Furthermore +1 on this feature request. It would be very nice to verify the configuration before restarting a service automatically on a configuration file update.

GiteaMirror referenced this issue

2025-11-02 11:54:53 -06:00

[PR #1177] [MERGED] Fix ini format incomiptable with crowdin #15800

GiteaMirror referenced this issue

2025-11-02 11:54:55 -06:00

[PR #1192] [MERGED] fix ini format incomiptable with crowdin (#1177) #15802

Sign in to join this conversation.