Install first user from config #1199

New Issue

GiteaMirror · 2025-11-02T03:52:08-06:00

GiteaMirror commented

2025-11-02 03:52:08 -06:00

Originally created by @willis7 on GitHub (Nov 1, 2017).

Description

As a non-UI user I would like to programmatically start Gitea with the first user installed. I would be happy to supply an Environment Variable, but would prefer to include it in my app.ini.

Originally created by @willis7 on GitHub (Nov 1, 2017). ## Description As a non-UI user I would like to programmatically start Gitea with the first user installed. I would be happy to supply an Environment Variable, but would prefer to include it in my `app.ini`.

GiteaMirror added the type/proposal label 2025-11-02 03:52:08 -06:00

GiteaMirror closed this issue

2025-11-02 03:52:08 -06:00

GiteaMirror commented

2025-11-02 03:52:09 -06:00

@0rzech commented on GitHub (Nov 26, 2017):

Perhaps environment variables could be used instead of app.ini, eg. GITEA_ADMIN_USER, GITEA_ADMIN_PASSWORD and GITEA_ADMIN_EMAIL, like suggested in #1525. This way app.ini would be free from storing yet another password.

@0rzech commented on GitHub (Nov 26, 2017): Perhaps environment variables could be used instead of app.ini, eg. `GITEA_ADMIN_USER`, `GITEA_ADMIN_PASSWORD` and `GITEA_ADMIN_EMAIL`, like suggested in #1525. This way app.ini would be free from storing yet another password.

GiteaMirror commented

2025-11-02 03:52:09 -06:00

@jmls commented on GitHub (Sep 12, 2018):

has there been any movement on this ? I am looking to do the same thing

@jmls commented on GitHub (Sep 12, 2018): has there been any movement on this ? I am looking to do the same thing

GiteaMirror commented

2025-11-02 03:52:09 -06:00

@marklee77 commented on GitHub (Feb 1, 2019):

install/setup wizards are the wrong way to do things. It should be possible (and easy) to stand up an instance without any user interaction whatsoever.

@marklee77 commented on GitHub (Feb 1, 2019): install/setup wizards are the wrong way to do things. It should be possible (and easy) to stand up an instance without any user interaction whatsoever.

GiteaMirror commented

2025-11-02 03:52:09 -06:00

@marklee77 commented on GitHub (Feb 1, 2019):

okay, maybe that was a little strong, but I really don't like interactive setup wizards as a standard way to do things.

@marklee77 commented on GitHub (Feb 1, 2019): okay, maybe that was a little strong, but I really don't like interactive setup wizards as a standard way to do things.

GiteaMirror commented

2025-11-02 03:52:10 -06:00

@zeripath commented on GitHub (Feb 1, 2019):

Can't this be solved with: gitea admin create-user

@zeripath commented on GitHub (Feb 1, 2019): Can't this be solved with: `gitea admin create-user`

GiteaMirror commented

2025-11-02 03:52:10 -06:00

@marklee77 commented on GitHub (Feb 1, 2019):

that would be helpful for the comment by 0rzech, but doesn't address the actual request, which is to have a way to set up/configure gitea without using the gui.

@marklee77 commented on GitHub (Feb 1, 2019): that would be helpful for the comment by 0rzech, but doesn't address the actual request, which is to have a way to set up/configure gitea without using the gui.

GiteaMirror commented

2025-11-02 03:52:10 -06:00

@zeripath commented on GitHub (Feb 2, 2019):

You don't need the UI to run gitea admin create-user - but you do need Gitea to be running. I'm not immediately sure how to prevent the first user registration getting admin - as I'm on my phone - so I guess there could be a race here if you allow auto registration? But I think that's solvable -if we find where that happens we can write an option to disable that, if it's not already configurable.

I don't think putting more user config into the app.ini is the right thing at all. We already have trouble with people complaining about the SECRETs in there already. So that's a no - and PRs that do that will get a nack from me.

So, what's the underlying circumstance where this kind of environment variable is required? You're talking about docker aren't you?

Ok, gitea admin can't be run until the server is up. So you can't do it until https://github.com/go-gitea/gitea/blob/master/docker/etc/s6/gitea/run has run.

So perhaps after
https://github.com/go-gitea/gitea/blob/master/docker/usr/bin/entrypoint#L36

We could add the code to do the check if the admin user bunf is set. But what do you do if the admin user is there?

@zeripath commented on GitHub (Feb 2, 2019): You don't need the UI to run `gitea admin create-user` - but you do need Gitea to be running. I'm not immediately sure how to prevent the first user registration getting admin - as I'm on my phone - so I guess there could be a race here if you allow auto registration? But I think that's solvable -if we find where that happens we can write an option to disable that, if it's not already configurable. I don't think putting more user config into the app.ini is the right thing at all. We already have trouble with people complaining about the SECRETs in there already. So that's a no - and PRs that do that will get a nack from me. So, what's the underlying circumstance where this kind of environment variable is required? You're talking about docker aren't you? Ok, `gitea admin` can't be run until the server is up. So you can't do it until https://github.com/go-gitea/gitea/blob/master/docker/etc/s6/gitea/run has run. So perhaps after https://github.com/go-gitea/gitea/blob/master/docker/usr/bin/entrypoint#L36 We could add the code to do the check if the admin user bunf is set. But what do you do if the admin user is there?

GiteaMirror commented

2025-11-02 03:52:10 -06:00

@marklee77 commented on GitHub (Feb 2, 2019):

The use case is to completely automate the stand up of and tear down of gitea so you can CI your devops workflow and have something you can evaluate in a staging environment before deploying to production. I worked around the issue by taking a database dump and then setting up my mysql container to pre-create the login_source and user table entries, but that's not totally ideal. I agree you shouldn't be putting secrets in the app.ini, but it should be possible to read those in from files at startup so you can use something like vault to mount the secrets in the container on startup on ram-backed storage.

@marklee77 commented on GitHub (Feb 2, 2019): The use case is to completely automate the stand up of and tear down of gitea so you can CI your devops workflow and have something you can evaluate in a staging environment before deploying to production. I worked around the issue by taking a database dump and then setting up my mysql container to pre-create the login_source and user table entries, but that's not totally ideal. I agree you shouldn't be putting secrets in the app.ini, but it should be possible to read those in from files at startup so you can use something like vault to mount the secrets in the container on startup on ram-backed storage.

GiteaMirror commented

2025-11-02 03:52:10 -06:00

@zeripath commented on GitHub (Feb 2, 2019):

But why can't gitea admin create-user form part of that CI setup? See: https://github.com/bozaro/git-as-svn/blob/master/src/test/java/svnserver/ext/gitea/GiteaIntegrationTest.java

@zeripath commented on GitHub (Feb 2, 2019): But why can't `gitea admin create-user` form part of that CI setup? See: https://github.com/bozaro/git-as-svn/blob/master/src/test/java/svnserver/ext/gitea/GiteaIntegrationTest.java

GiteaMirror commented

2025-11-02 03:52:11 -06:00

@marklee77 commented on GitHub (Feb 2, 2019):

Actually, for the initial setup of the admin user that's not a bad idea. It would be slightly nicer if the entrypoint supported user-supplied init scripts, but it's not difficult to work around that. The actual thing that I wish were easier to do without logging in as the admin user is setting up auth to an internal ldap server with a private certificate authority. In any case, as I've said, I have gotten this working for now, I just have to add creating the table and inserting some entries into the mysql initialization scripts.

@marklee77 commented on GitHub (Feb 2, 2019): Actually, for the initial setup of the admin user that's not a bad idea. It would be slightly nicer if the entrypoint supported user-supplied init scripts, but it's not difficult to work around that. The actual thing that I wish were easier to do without logging in as the admin user is setting up auth to an internal ldap server with a private certificate authority. In any case, as I've said, I have gotten this working for now, I just have to add creating the table and inserting some entries into the mysql initialization scripts.

GiteaMirror commented

2025-11-02 03:52:11 -06:00

@marklee77 commented on GitHub (Feb 2, 2019):

I suppose this has gotten slightly off the issue topic, I should probably just add a request for more ability to configure the auth backends from the command line.

@marklee77 commented on GitHub (Feb 2, 2019): I suppose this has gotten slightly off the issue topic, I should probably just add a request for more ability to configure the auth backends from the command line.

GiteaMirror commented

2025-11-02 03:52:12 -06:00

@techknowlogick commented on GitHub (Feb 2, 2019):

Closing this as users can be created from CLI, so if some users need this they can instead add an additional step to provision.

In terms of adding new auth systems, adding OAUTH works from CLI, and a new ticket can be opened for working with other types of auth.

@techknowlogick commented on GitHub (Feb 2, 2019): Closing this as users can be created from CLI, so if some users need this they can instead add an additional step to provision. In terms of adding new auth systems, adding OAUTH works from CLI, and a new ticket can be opened for working with other types of auth.

GiteaMirror referenced this issue

2025-11-02 12:21:06 -06:00

[PR #3308] [MERGED] Templates for extra links in top navbar and repo tool tabs. #16874

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1199