@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

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

It certainly could. Alongside the docker registry app. Another bonus for using gitea for container storage is that you can use access tokens instead of the actual user password.

@LoudLemur possibly because it looks incredibly dated?

Very nice, it’s been a long time coming! That NLnet’s grants list is a bunch of awesomeness btw https://nlnet.nl/project/current.html

@ocelotsloth thanks, merged! will publish shortly.

@girish Thanks for your extremely quick and helpful answer! It worked! Side note: I have been using cloudron for about 2 years now, and I am a happy paying customer. The fact that it is the first question I had to ask so far is a testament to the quality of your work and documentation. Congratulations to the team!

Hi @krschuerman, for me this still works, but as already said in my last post here in this thread the setting needs to be placed in the security block. [security] [..] DISABLE_GIT_HOOKS = false

@girish Yeah, I ran: /home/git/gitea/gitea convert -c /run/gitea/app.ini as user git, and now things seem converted: ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC On the downside, the convert tool seems to unconditionally convert, and is quite slow, so I guess it can't easily be run as part of the startup process or something

@murgero Removed the blank template file from the custom folder and it worked without a hitch. I see this is marked as solved already but you can close the internal ticket if you haven't already.