Configure with env variables

[tboerger]

To make the configuration easier especially in the world of systemd and docker we should make it possible to entirely configure gitea with environment variables. To work around the required variables used within the ssh shell we can generate an environment file for it automatically on application start. That way we can get rid of the requirement of the custom app.ini.

[tboerger]

The official image or my image?

As already commented on the roadmap issue, it would make much more sense to reduce the config file to a minimum and make the rest part of the database which can be changed via cli and optionally via Web ui.

[TheAssassin]

That's a good alternative, as long as deployment-critical data can be set via env vars (ports, public (as in: load balancer) URLs, etc.).

[tboerger]

Infrastructure/deployment parts got to be part of the config, the rest should be part of the db.

[zeripath]

These are infrastructure questions: e.g. what is the internal URL that serv/hook talks to.

There needs to be some way of configuring these non s6/entrypoint processes, and allowing environment overrides at that point is a security risk.

I think we're going round in circles. If docker requires that you replace an ini file with an exploded set of environment variables so be it. Overlaying this config on top of a provided config á la gitea docker-environment-config is the simplest solution I can think of. Yes, we should consider moving config to the db but unless you're willing to remove any dependency on modules/setting in serv and hook and replace it with arguments - and do so carefully for multiple docker environments and account for non docker users too - you're going to have to have some way of configuring this.

[tboerger]

@zeripath you are missing the point, but whatever. I will just unsubscribe.

[TheAssassin]

@zeripath I have doubts you ever used some container-based systems for deployment. Have you ever tried a random, more well known Docker container? For instance, PostgreSQL is a good example: https://hub.docker.com/_/postgres. Check their "How to use this image". You're thinking way too complicated...

[christhomas]

@zeripath perhaps you can explain what these security risks are when it comes to configuring ssh using environment variables? I've already stated that installing keys and files into the .ssh directory should be done through mounting files into the file system and not environment variables. But you continue to restate that it's a security risk and I'm not sure what risk you are talking about.

[tboerger]

A config file is fine, just reduce it to a minimum which includes database config, cache config (like redis) and bindings like port, internal domain. That's it. All the other stuff could be stored on the database.

[TheAssassin]

I still don't see why a config file would have to contain all the things by default even.

When I develop web apps, there's a default config that contains standard values, and any user config file or env vars can override those keys. That should exist already anyway. If required settings are missing, the app refuses to start up.

You don't have to expose every setting as env var either. Just the stuff we really need to be able to set via env var, which are important for deployment.

[techknowlogick]

Temporarily locking this issue due to amount of comments on it. More than 400 people get an email each comment. Let’s discuss this over on discord for now, and I’ll reopen in the near future.

Maintainers: you should still be able to comment. If not ping me in discord and I’ll post on your behalf.

[tboerger]

Just some closing words, just env variables without a config at all is pretty difficult because the executable gets called from different contexts.

The web application itself should work by env variables, but you can't hand over this environment to the script called by ssh commands like cloning or pushing, which is calling gitea serv for every connection.

So you can see that there is some reasoning for a config file.