lunny/helm-chart
1
0
Fork 1
Code Issues36 Pull Requests14 Actions Packages Projects Releases93 Wiki Activity

Chart creates faulty admin user with v2.1.0 #79

New Issue
Closed
opened 2020-12-08 08:31:15 +00:00 by luhahn · 7 comments
luhahn commented 2020-12-08 08:31:15 +00:00 (Migrated from gitea.com)

After upgrading to v2.1.0 the admin user won't be able to login anymore.

Original issue on github: https://github.com/go-gitea/gitea/issues/13832#issuecomment-739872134

After upgrading to v2.1.0 the admin user won't be able to login anymore. Original issue on github: https://github.com/go-gitea/gitea/issues/13832#issuecomment-739872134
luhahn commented 2020-12-08 08:33:30 +00:00 (Migrated from gitea.com)

Currenlty investigating this issue. It seems that for newly created admin users it is now required to set

--must-change-password=false

Otherwise the admin user will be required to change its password, which is clearly not wanted for automation.

I'll have a look why already existing admins are not able to login anymore.

I will create a PR once I've figured out why this does not work.

Currenlty investigating this issue. It seems that for newly created admin users it is now required to set ``` --must-change-password=false ``` Otherwise the admin user will be required to change its password, which is clearly not wanted for automation. I'll have a look why already existing admins are not able to login anymore. I will create a PR once I've figured out why this does not work.
luhahn commented 2020-12-08 09:39:05 +00:00 (Migrated from gitea.com)

Copied Text from my Pull Request:

Even though this fixes the admin user creation for 1.13.0. It will not fix the admin users created before gitea 1.13.0 (Chart 2.1.0).

To fix those Admins you can:

  • Login to your gitea Container
  • Create another admin account
  • Login with new admin
  • Remove old admin from all organisations
  • Delete old admin
  • Rerun helm install or create your old admin again

After this the helm chart is upgradeable again and the admin user will persist.

Command to create a new admin user:

gitea admin create-user --username  myAdmin --password 'myPassword123 --email my@admin.com --admin --must-change-password=false

Please keep in mind, that I currently don't know why the existing admins are unable to login after the upgrade, so this is a workaround to get your admin back and prevention for those problems for new installations of gitea.

Copied Text from my Pull Request: Even though this fixes the admin user creation for 1.13.0. It will not fix the admin users created before gitea 1.13.0 (Chart 2.1.0). To fix those Admins you can: - Login to your gitea Container - Create another admin account - Login with new admin - Remove old admin from all organisations - Delete old admin - Rerun helm install or create your old admin again After this the helm chart is upgradeable again and the admin user will persist. Command to create a new admin user: ```bash gitea admin create-user --username myAdmin --password 'myPassword123 --email my@admin.com --admin --must-change-password=false ``` Please keep in mind, that I currently don't know why the existing admins are unable to login after the upgrade, so this is a workaround to get your admin back and prevention for those problems for new installations of gitea.
onedr0p commented 2020-12-10 12:55:00 +00:00 (Migrated from gitea.com)

I followed @luhahn guide above which created the new admin account. I was able to sign in with the new admin account and update the password for the older account. After that I was able to log back in with the older account.

I followed @luhahn guide above which created the new admin account. I was able to sign in with the new admin account and update the password for the older account. After that I was able to log back in with the older account.
👍 2
Rafal commented 2021-06-04 18:36:56 +00:00 (Migrated from gitea.com)

It seems that this is still the case currently

CHART: gitea-3.0.0
APP VERSION: 1.14.1

Any known workarounds? I wanted to use gitea to demo some GitOps setups in self-contained kind clusters

image

It seems that this is still the case currently ``` CHART: gitea-3.0.0 APP VERSION: 1.14.1 ``` Any known workarounds? I wanted to use gitea to demo some GitOps setups in self-contained kind clusters ![image](/attachments/d8497164-0c0c-42eb-929e-4cad6adc3322)
Rafal commented 2021-06-04 18:39:32 +00:00 (Migrated from gitea.com)

Though maybe I am doing something wrong but by just setting in helm values

gitea:
  admin:
    email: "admin@seldon.io"
    password: "some uber cool password here"
    username: "seldon"

it didn't let me to log in

Though maybe I am doing something wrong but by just setting in helm values ``` gitea: admin: email: "admin@seldon.io" password: "some uber cool password here" username: "seldon" ``` it didn't let me to log in
luhahn commented 2021-06-08 15:50:56 +00:00 (Migrated from gitea.com)

can you have a look at the init container logs? There should be an output if the admin user command fails

can you have a look at the init container logs? There should be an output if the admin user command fails
Rafal commented 2021-06-08 22:24:21 +00:00 (Migrated from gitea.com)

Actually, now it seems to work fine, I do not know what was going wrong with it.
I think we can close it, at least from my side - I can re-open with problem comes back.

Actually, now it seems to work fine, I do not know what was going wrong with it. I think we can close it, at least from my side - I can re-open with problem comes back.
Sign in to join this conversation.
No Label
kind/bug
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#79
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?