After creating a new key and configuring it in app.ini and restarting gitea I still get an error: root@0f44f577-d0e0-42e6-a371-d3914aba0014:/home/git# sudo -u git bash git@0f44f577-d0e0-42e6-a371-d3914aba0014:~$ export GNUPGHOME=/app/data/appdata/home/.gnupg git@0f44f577-d0e0-42e6-a371-d3914aba0014:~$ gpg --list-keys /app/data/appdata/home/.gnupg/pubring.kbx ----------------------------------------- pub rsa4096 2025-01-21 [SC] [expires: 2027-01-21] EF80C8DE297670B7E8C0360108DA2115185FFD9C uid [ultimate] jascha.wtf Gitea <git@git.jascha.wtf> section of app.ini: [repository.signing] SIGNING_KEY = EF80C8DE297670B7E8C0360108DA2115185FFD9C SIGNING_NAME = jascha.wtf Gitea SIGNING_EMAIL = git@git.jascha.wtf INITIAL_COMMIT = always CRUD_ACTIONS = pubkey, twofa, parentsigned WIKI = never MERGES = pubkey, twofa, basesigned, commitssigned GITEA__REPOSITORY__ENABLE_PUSH_CREATE_USER=true From the log: Jan 21 10:45:28 Error: exit status 128 - error: gpg failed to sign the data Jan 21 10:45:28 fatal: failed to write commit object Jan 21 10:45:28 - error: gpg failed to sign the data Jan 21 10:45:28 fatal: failed to write commit object Jan 21 10:45:28 2025/01/21 09:45:28 ...ers/web/repo/repo.go:217:handleCreateError() [E] CreatePost: initRepository: initRepoCommit: git commit: exit status 128 - error: gpg failed to sign the data Jan 21 10:45:28 fatal: failed to write commit object Jan 21 10:45:28 - error: gpg failed to sign the data Jan 21 10:45:28 fatal: failed to write commit object Jan 21 10:45:28 2025/01/21 09:45:28 ...eb/routing/logger.go:102:func1() [I] router: completed POST /repo/create for 82.140.42.234:0, 500 Internal Server Error in 55.3ms @ repo/repo.go:222(repo.CreatePost) Update: Gitea does not get the signing key. The response of https://git.jascha.wtf/api/v1/signing-key.gpg is empty My best guess is that there are some path poblems - https://docs.gitea.com/administration/signing

I've also lost quite some time kicking accounts and repositories, in the end I've combined some of the options below (don't forget the [service] section marker and also restart after the changes !) [service] DISABLE_REGISTRATION = True REGISTER_MANUAL_CONFIRM = True EMAIL_DOMAIN_ALLOWLIST = XX_your_domain_here_XX,cloudron.local DEFAULT_USER_IS_RESTRICTED = True It's overkill if all are used at the same time, but depending on the needs and paranoia, it can be useful

@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.

@mario install them in the LAMP app.

@ChristopherMag thanks!

@Wirv I did it by setting this to false SERVE_DIRECT = true