Glad it worked out in the end, even if we don't know why.

As a first step, since user-mapping will likely not work with Cloudron SSO by just importing a database dump, install Gitea without Cloudron user-management, then try to import the database dump following the guide at https://docs.cloudron.io/guides/import-mysql/

Solved
This turned out to be easier than I expected, oops. I modified signin_inner.tmpl to only have the small OAuth2 portion of the signin page, i.e. I deleted lines 13-54 and 56-58 from that file (as it exists now), and put my version in gitea's folder custom/templates/user/auth/. As desired, it still displays "Login with cloudron", but not the main login option.

After this I simply retried update and it worked. And now all apps are updating as well. Thank you.

It was a problem with one of the queues running rogue. Fixed by cleaning that queue.

With pleasure ! And and in the end I've deleted the new admin account because I'm paranoid 🙂

root@a45580f2-9906-49b6-a090-476ecd0ec3ac:/home/git# sudo -u git /home/git/gitea/gitea -c /run/gitea/app.ini admin user list ID Username Email IsActive IsAdmin 2FA 1 sansguidon morgan@zoemp.be true true false 3 superadmin bonjour@zoemp.be true true false root@a45580f2-9906-49b6-a090-476ecd0ec3ac:/home/git# sudo -u git /home/git/gitea/gitea -c /run/gitea/app.ini admin user delete Command error: You must provide the id, username or email of a user to delete root@a45580f2-9906-49b6-a090-476ecd0ec3ac:/home/git# sudo -u git /home/git/gitea/gitea -c /run/gitea/app.ini admin user delete --id 3 2024/02/15 14:46:55 ...s/storage/storage.go:176:initAttachments() [I] Initialising Attachment storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/attachments 2024/02/15 14:46:55 ...s/storage/storage.go:166:initAvatars() [I] Initialising Avatar storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/avatars 2024/02/15 14:46:55 ...s/storage/storage.go:192:initRepoAvatars() [I] Initialising Repository Avatar storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/repo-avatars 2024/02/15 14:46:55 ...s/storage/storage.go:198:initRepoArchives() [I] Initialising Repository Archive storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/repo-archive 2024/02/15 14:46:55 ...s/storage/storage.go:208:initPackages() [I] Initialising Packages storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/packages 2024/02/15 14:46:55 ...s/storage/storage.go:219:initActions() [I] Initialising Actions storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/actions_log 2024/02/15 14:46:55 ...s/storage/storage.go:223:initActions() [I] Initialising ActionsArtifacts storage with type: local 2024/02/15 14:46:55 ...les/storage/local.go:33:NewLocalStorage() [I] Creating new Local Storage at /app/data/appdata/actions_artifacts root@a45580f2-9906-49b6-a090-476ecd0ec3ac:/home/git# sudo -u git /home/git/gitea/gitea -c /run/gitea/app.ini admin user list ID Username Email IsActive IsAdmin 2FA 1 sansguidon morgan@zoemp.be true true false

Sorry, no, I didn't - I thought clourdon is similar to mastodon or any other collaboration tool...now I see, I am wrong...

Release 1.20.0 included these PRs related to mirroring, maybe one of them caused the issue:

Refactor Pull Mirror and fix out-of-sync bugs #24732 Use the type RefName for all the needed places and fix pull mirror sync bugs #24634 Allow skipping forks and mirrors from being indexed #23187

@benjifrank The location of css assets have changed. It is now in CUSTOM/public/assets/css (starting from 1.21.0 it seems). The templates are also not into custom directly , but into templates/base it seems. Not 100% sure but it seems like that unlikes color themes, there can only be 1 template (?) because the template names don't have a theme prefix....

Anyway, so, my directory structure is like this:

root@fd219d58-a046-4087-910f-ffca7d16dfee:/app/data/custom# find . . ./templates ./templates/base ./public ./public/assets ./public/assets/img ./public/assets/css ./public/assets/css/theme-arc-red.css

I put this in my app.ini:

[ui] THEMES = gitea-auto,gitea-light,gitea-dark,arc-red DEFAULT_THEME = arc-red

Restarted the app.

And then I do red color scrollbars etc.

@nebulon That is probably a great idea, I have not used this before.

I have gone to Gitea, go to Settings, and on the left hand menu select SSH/GPG Keys it gives me the ability to add an existing SSH public key.

It also says that "SSH is currently disabled so these keys are only used for commit signature verification"

image.png

It does look like there is an option to enable the SSH port under the Location settings of the app so to make this work the way your describing I believe someone would need to:

Install Gitea Enable Location > SSH port Generate ssh key pair using ssh-keygen Open Gitea > Settings > SSH/GPG keys Click Add Key and add the public key portion of your generated ssh key and click Add Key button at the bottom

Given that SSH isn't enabled by default, that there are additional steps and tools needed, and that there is no way to do OID login via the git cli tool (that I know of) it seems like the Generate Token option would be the expected default choice for new users of gitea on cloudron with more advanced or experienced users going through the additional steps to use SSH if that is more consistent with their workflow.

In the browser, it says : "2FA token is invalid".
In the app logs, I can see no error

So I had to change a lot of variable to "public" or "true" to make it happen.

I am certain I didn't myself change this manually, so let's blame a solar bit flip. 😉

Thanks for the pointer!

@girish I think in the case of Gitea it probably makes sense to not move from ldap to oidc, but to rather configure both. Their ux seemed quite clear to me even when logging in with oidc for a user which had it not configured beforehand. Instead of creating a completely new user it asked again for the username and password of my existing ldap user to link these two accounts together.

When last experimenting with Vikunja it preferred creating new users instead of combining them like Gitea does, so for some apps it makes sense to move to oidc only, while others are good in a combination of ldap and oidc.

@mario install them in the LAMP app.

@ChristopherMag thanks!

@Wirv I did it by setting this to false

SERVE_DIRECT = true

@girish Setting

[indexer] ISSUE_INDEXER_TYPE=db

in app.ini solved the issue immediately. Thanks alot!

Now I'm curious to know what db means in this context (but the urgency is gone 😅). Should the Cloudron package have db as ISSUE_INDEXER_TYPE out of the box, for example?

Some Cloudron app config data got alot of legacy files from earlier versions, so sometimes it's hard to know what the true good defaults are.

@jaschaezra there recently was a topic of someone building a custom forgejo app https://forum.cloudron.io/topic/8312/moving-from-packaged-app-to-custom?_=1673347978007

@yusf thanks, fixed in latest package.