Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
infogulchI

infogulch

@infogulch
About
Posts
186
Topics
36
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Default config changes
    infogulchI infogulch

    Yes I suspected that's how it would work.

    What if we configure Gitea admin group claims from OIDC tokens? Can cloudron add a claim to the token when the authenticated user is an operator?

    • --group-claim-name: Claim name providing group names for this source. (Optional)
    • --admin-group: Group Claim value for administrator users. (Optional)

    -Gitea Command Line Reference

    image.png

    https://github.com/search?q=repo%3Ago-gitea%2Fgitea oauth2_group_claim_name&type=code
    https://github.com/search?q=repo%3Ago-gitea%2Fgitea+oauth2groupclaimname&type=code
    https://github.com/search?q=repo%3Ago-gitea%2Fgitea GroupClaimName&type=code

    Ok it looks like these configs are not settable by app.ini. I'll ask in the discord and post back here.

    https://github.com/go-gitea/gitea/blob/b861d86f80ea7a848efb539b798bbde3c7877d02/modules/setting/oauth2.go#L63-L79

    Gitea

  • Default config changes
    infogulchI infogulch

    What if the OIDC user can be made admin through the CLI in start.sh?

    Gitea

  • Default config changes
    infogulchI infogulch

    Yes that's what I'm saying: I've never logged in with the root user since changing the password, I've always managed my gitea instance by giving my cloudron identity administrator privileges in the app. So maybe the admin is not even necessary. And if we just completely disable the admin login this would simplify first-time setup of the gitea app.

    Gitea

  • Default config changes
    infogulchI infogulch

    Cool. What do you think about item 2?

    Gitea

  • Default config changes
    infogulchI infogulch

    I was looking through the gitea config cheat sheet and there are some changes that could be made to make it more operator friendly.

    I'd like to hear your thoughts.

    1. Disable registration by default

    See Prevent external users from joining gitea instance.

    [service]
    DISABLE_REGISTRATION = True
    REGISTER_MANUAL_CONFIRM = True
    EMAIL_DOMAIN_ALLOWLIST = XX_your_domain_here_XX,cloudron.local
    DEFAULT_USER_IS_RESTRICTED = True
    

    I would guess that most cloudron users would want to manage gitea user accounts through cloudron instead of in the app itself. This would prevent spam and abuse of gitea instances by default. This may require some tuning, I'm not sure how carefully these configs were tested.

    2. Completely disable gitea password-based signin form

    I noticed gitea has these options to disable the username/password signin form entirely. This would make cloudron logins smoother because I keep forgetting and fill in my cloudron credentials to the gitea login form, which doesn't work, instead of clicking "Sign in with Cloudron".

    More importantly, if this setting is changed it might eliminate the need to change and manage the admin password during first time app install, simplifying the initial setup. To ensure that users can get to the admin panel, maybe we could use the CLI to make the cloudron app owner account an administrator in start.sh.

    [service]
    ENABLE_PASSWORD_SIGNIN_FORM = false
    ENABLE_BASIC_AUTHENTICATION = false
    

    ENABLE_PASSWORD_SIGNIN_FORM: true: Show the password login form (for password-based login), otherwise, only show OAuth2 or passkey login methods if they are enabled. If you set it to false, maybe it also needs to set ENABLE_BASIC_AUTHENTICATION to false to completely disable password-based authentication.

    Gitea

  • Prevent external users joining gitea instance
    infogulchI infogulch

    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?

    Gitea

  • Prevent external users joining gitea instance
    infogulchI infogulch

    +1 to "change the app so that the default is a disabled registration". I just had a big mess to clean up because of this. https://forum.cloudron.io/topic/14053/clean-up-external-users-that-have-accessed-gitea-instance

    At the very least these configs should be mentioned in the admin checklist.

    Gitea

  • Clean up external users that have accessed gitea instance
    infogulchI infogulch
    • With help from Grok: https://grok.com/share/bGVnYWN5_baedbb67-0507-41f0-b26d-29da9f1b7f94
    • Exported users to delete with mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE} -e "SELECT id FROM user WHERE FROM_UNIXTIME(created_unix) > '2025-03-01'" > /app/data/users-to-delete.txt
    • Deleted the header name with vim
    • Switch to git user sudo -u git bash
    • Run a command to use the cli to purge each user in the list: while read -r id; do /home/git/gitea/gitea -c /run/gitea/app.ini admin user delete --id "$id" --purge; done < /app/data/users-to-delete.txt
    • All bad users cleared but one (not sure why), deleted manually.
    • Done!
    Support

  • Clean up external users that have accessed gitea instance
    infogulchI infogulch

    In 2022 gitea added the ability to purge an individual account including all memberships and repos: Add option to purge users (go-gitea#18064)

    Unfortunately for me there is no option to purge multiple accounts at once. So I posted on an existing open issue with a request for this feature: Multi-select users for mass modification/deletion/purge #33376

    I may consider reverse-engineering the purge code and running it manually, but that would be a lot of work...

    Maybe a curl script to hit the purge endpoint is a better idea.

    Support

  • Clean up external users that have accessed gitea instance
    infogulchI infogulch

    It seems the schema has changed since that blog post, but the basic idea still worked.

    • SELECT COUNT(*) FROM user; showed 19922 accounts.
    • I noticed most accounts were added starting March 2025
    • SELECT * FROM user WHERE FROM_UNIXTIME(created_unix) < '2025-03-01' shows only the 4 very old accounts that I recognized.
    • SELECT COUNT(*) FROM user WHERE FROM_UNIXTIME(created_unix) > '2025-03-01' showed 19918 accounts that I would want to delete.
    • UPDATE user SET is_active = 0 WHERE FROM_UNIXTIME(created_unix) > '2025-03-01'; marked these accounts as inactive
    • Under Maintenance > Dashboard, I clicked Run on the Delete all unactivated accounts maintenance operation.
    • It took ~5 minutes and deleted a bunch of accounts, but now it's stuck at 2169 accounts and running the maintenance operation again isn't working.
    • Restarting app...
    • The issue with the stuck accounts is shown in the logs: Inactive user "<snip>" has repositories, organizations or packages, skipping deletion: user still has ownership of repositories
    • Looking into deleting inactive users along with everything they own.
    Support

  • Clean up external users that have accessed gitea instance
    infogulchI infogulch

    My gitea instance is filled up with spam and malware distribution. Looks like over 1000 users since March 2025. I thought I disabled that feature but maybe not...

    I have added the same list of configs that the user in this thread did: Prevent external users joining gitea instance

    [service]
    DISABLE_REGISTRATION = True
    REGISTER_MANUAL_CONFIRM = True
    EMAIL_DOMAIN_ALLOWLIST = XX_your_domain_here_XX,cloudron.local
    DEFAULT_USER_IS_RESTRICTED = True
    

    But now I have a mess to clean up. I'll document what I did here.

    I found this blog article from 2022 with a 2-step solution:

    1. Use sql query to change status of unwanted users to inactive: UPDATE public.user SET is_active = 'f' WHERE name != 'bertieb'; (modify as needed)
    2. Use the gitea dashboard feature to delete inactive users.

    I'll try this and report back.

    Support

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Ok if I switch it to "Direct disk" it fails to boot but "GRUB (Legacy)" kernel option seems to boot fine. 🤷

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Thank you that is helpful.

    So maybe the correct option is to use the "Direct Disk" option that boots the kernel installed on the disk to allow the OS updates to manage the kernel version. This should head off any future issues and I won't have to coordinate when I upgrade to 22.04 and 24.04.

    See: https://techdocs.akamai.com/cloud-computing/docs/manage-the-kernel-on-a-compute-instance#view-and-modify-the-kernel-in-cloud-manager

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Everything seems to be back up and running now. Thank you!

    Any advice which latest kernel version I should be using? There are many options...

    Edit: Oh maybe I should upgrade 20.04 as a first step...

    https://docs.cloudron.io/guides/upgrade-ubuntu-22/
    https://docs.cloudron.io/guides/upgrade-ubuntu-24/

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Maybe it would be worth putting the kernel version in the info section?

    image.png

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Wow that's crazy. Yeah, it looks like the kernel was set to "latest" so maybe it was autoupdating? I'm switching back down to 5.4.10 which is the oldest allowed...

    image.png

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Enabled and dashboard url sent. I can wait if that will help find a root cause, if it's no longer helpful let me know and we can do a restore.

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    Linode since before they were purchased by Akamai

    Support cgroups docker

  • Services and all apps down due to cgroups error
    infogulchI infogulch

    The following pattern occurs often: the server becomes completely unresponsive, I check the cloud dashboard and the server is using 100% CPU for something (I've never figured out what), so I reboot it and it goes back to normal. This cycle has repeated for over a year; I recall that I reported it before, but it's still an issue. Here's what it looked like in May:

    image.png

    I did this again on July 4th, but this time it looks like it didn't come back ok:

    d28e5fbe-ef3d-45d5-8db1-b1d476860832-image.png

    I have plenty of disk left, > 50GB

    Support cgroups docker
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search