For anyone facing this issue, best workaround/mitigation for me were to run Anubis on a separate VPS following a setup similar to https://forum.cloudron.io/topic/13957/deploying-anubis-ai-crawler-filtering-on-a-cloudron-server/8 so all requests to my Gitea instance go through Anubis but for some API/Healthchecks calls (from Uptime Kuma etc). I could even decrease the allocated memory.

What I was aiming for with this was to simplify the Gitea app install process for new instances. This would: Remove the step where new app owners must change the root password and save it, eliminating the initial period where new installs are vulnerable to spam and abuse, and eliminating the need for a root user at all. Allow for disabling username/password entry form, streamlining cloudron logins. Derive Gitea Site Administrator privileges directly from app owner/operator role, simplifying app administrator delegation. These goals are related to the default initial configuration of the gitea app, and are thus not possible to achieve with cloudron groups. To do this, cloudron would need to: Add a role claim (maybe roles plural) to the claims returned by getClaims, corresponding to the user's role assignment for that app. Accept a PR to the gitea app that configures it to use these claims to set the site administrator role, after waiting for gitea to implement the ability to configure these settings from app.ini. I understand if you are not interested at this time.

Maybe because the next line is SHOW_REGISTRATION_BUTTON = false. Not sure what this combination of features does, maybe it hides the register button but allows direct POST requests to the endpoint anyway?

@joseph Thanks for pointing that out. Good to know. We can close this request.

Well, I am confused. For me, it works out of the box. See this comment from @nebulon - https://forum.cloudron.io/post/55637 GNUPGHOME is already to /app/data/gnupg Just put your keys in above directory curl https://gitea.domain.com/api/v1/signing-key.gpg works Create empty repo. [image: 1737979881957-644690e5-f121-48e4-86b6-13b49e481dc3-image.png]

@Meuschke Ah ok. The ability to set a separate backup schedule per app is coming shortly. Until then, maybe you can disable backups for Gitea and simply click the 'Create Backup' button manually every week (or equivalent). Yeah, sorry, not ideal

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: 1696425244095-8c33484f-e5ba-4655-80bf-94086bdcde45-image-resized.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.