Pre-installation support

[lunny]

This feature is very useful for rapidly creating an OEM Gitea instance. All the pre-installation will only need give a specific ini file. This file is not the same as the config.ini.

• set a default database
• set run user
• set a default admin user and password
• add users or organizations
• add auth source
• migrate some git repos. For example, migrate all the repos of mine in github.

[stevenroose]

Why would it not be the same as config.ini? All the things you mention seem to be configuration variables..

[lunny]

The first three could, but the last three cannot

[stevenroose]

Hmm. "add auth source" could, see #183. The other two indeed should not. But that are post-installation steps, imo.

[bkcsoft]

IMO just create a gitea admin load <FILE>-command.

config.yml (Yes, I like yaml. And very much hand-written, non-linted, pseudo-yaml)

install:
  database:
    type: sqlite
    path: data/gitea.db
    secret: FOOBAR42
  run_user: git
  admin_user:
  - name: admin
    password: foobaz
users:
- name: bkc
  password: foobar42
  admin: false
- name: lunny
  password: badf00d1337
  admin: true
organizations:
- name: octokit
migrate:
- source: https://github.com/octokit/hello-world.git
  namespace: octokit
  name: hello-world
  mirror: false

[lunny]

lack of auth sources.

[stevenroose]

Run user, admin user, database and auth sources are not install vars but global config vars that should be kept in a config file that is loaded on every run, not black-box inserted on install.

There is no need for pre-installation stuff, I setup a whole lot self-hosted applications and none have them. What they have is a config file that contains all you need.

Post-installation actions might make sense, though. F.e. adding users and organisations. However shouldn't the API allow for this when you provide an admin user in app.ini?

[lunny]

@stevenroose, I don't think so. Installation and Configuration are not the same things. Installation should have something you can not easily change. i.e. database, run user, data root dir. If you changed these, you have to restart your system. Adding users/organizations, adding auth source, config sendmail and etc. are configurations and could be changed when system is running.

[tboerger]

I would prefer a single file as well. And if authentication sources are defined via config I would even disable editing via ui

[stevenroose]

@lunny Almost all of them you could in theory change at runtime except maybe run user. But almost all of them you probably don't want to do that at runtime. Things like database, datadirs, auth source, sendmail are core configurations and will almost never change once your system is deployed. They shouldn't too.

[bkcsoft]

@stevenroose Gitea currently makes no effort at separating global/install var so currently it's sort-of a moot argument. Being able to bootstrap an instance is really helpful :)

[stevenroose]

@bkcsoft Yeah but there currently is a global config file and no install config file, so instead of making the latter, I think it makes more sense to just put it into the already existing config file :)

Makes installation much more intuitive for new users too, just fill in the app.ini file and run and you're done.

[bkcsoft]

with #354 that will be easier since the default app.ini is now included in the binary :)

[couling]

To add my two cents worth. I think we ought to continue to be careful to keep the use of app.ini coherent. There is a danger that it will become confusing. I think the auth provider is sitting on the wrong side of the fence. I know it threw me when I was first setting up gogs. We ought to look at moving it, even if it needs its own config file. INI files are flexible enough that we could have an "auth.ini" where each section refers to a different auth provider.

However the items "add users", "add or organizations" "migrate git repos" are once off admin activities and should not happen every time the server starts. Therefore they belong nowhere near a settings file. I believe the best idea would be a command line API.

Rather than a gitea admin load <FILE> to load a monolithic file. A set of functions:

• gitea admin add user
• gitea admin list users
• gitea admin delete user

This lets user create shell scripts or batch scripts which are as complex or simple as their needs. It also provides some simple solutions to lost admin passwords etc.

[lunny]

reset someuser's password.

gitea admin passwd <user>

[bkcsoft]

@lunny with an optional password for those of us that don't have an email server setup 😉

gitea admin passwd <user> [password]

[lunny]

@bkcsoft This only for who forget admin password. If you have admin password, you can change user's password in Admin Panel.

[bkcsoft]

@lunny unless you want a cron-job that changes their password every 3 months ;)

[ptman]

Instead of storing "dynamic configuration variables" in the database, one could keep them in the same config file and support reload instead of restart of gitea. (think apache/nginx reload vs restart)

[rajdavies]

We would like to to use gitea for out of the box git support in the fabric8.io project - which uses KeyCloak as an identity provider (Oauth). Being able to configure the OAuth provider in a configuration file seems to be the only way forward for us.

[hankerepo]

What about a config directory that would always start with a default app.ini.whatever. app.ini.whatever would be the starting point with the other files being merged and overriding any settings app.ini.whatever? Similar to /etc/whatever.d style directories

[randyesq]

Was any support for this ever added? I have the same use case as @rajdavies . I already have Keycloak up and running and in my environment, there is no real way to open a web UI and make changes. Being able to put everything in a config file for Ansible or some other CM tool to bootstrap the installation and configuration is key.

[lunny]

I think now every thing listed could be done via app.ini or gitea command lines.

[randyesq]

Where can I find the related docs?

[jolheiser]

https://docs.gitea.io/en-us/command-line/