Cloudron Forum

packaging update : basic functionality working further testing needed Will share package and deployment instructions when proven stable.

I think that means that no backup destinations have been set up or no successful backups have completed. Cloudron won’t update if there’s no backup to roll back to.

@djxx Do you have a repo link? Would love to see if there is a way to start moving away from the hacky stuff and get this on the store!

OK - managed to enter the terminal with recovery modus and changed ownership of the files. App is now running again. But still - whats the issue with the backup restore?

Yes (FWIW, I am a Debian developer and freelancer and did the upgrade for a customer). I knew that you were using docker-ce without a sources.list entry. Thus, after having upgraded the system, I was curious if these packages had been upgraded as well by any of the post-upgrade scripts mentioned in the 20.04->22.04 guide. But they hadn't. The system seems to run fine, though.

@girish it's a deep psychological phenomenon where familiarity is disturbed with dislike and confusion when things are changed and the time invested in learning and optimization is disgarded for a complete new layout where so many things change from left to right or right to left that it does indeed become a productivity problem. Unfortunately it's also often expressed in less than kind words which is a shocker to those already familiar with the new design. Different stage of acceptance.

Sounds like an unset variable

@nebulon At times I see that the Cloudron is not responsive (browser timeouts, which could be something other than a busy Cloudron server). I am also having an issue when using external monitors to check the health of my Cloudron (Uptime Robot, BetterStack). Attempts to use the API health check to return Cloudron version sometimes fails (causing Uptime or BetterStack to issue an alert). The same problem happens using the appid API call to check my Kuma instance. Again, I am not sure why this is happening or if it relates to the swapfile and performance. The GET failures are intermittent, but frequent enough to cause me to disable these alerts. Given the CPU/RAM/Disk of this server, I would not expect any of this to be an issue. I am not seeing anything in the box log that might suggest a problem. An article I was reading prompted me to look at the swapfile and utilization. Inside Cloudron, the monitoring chart seems to show a 50/50 split between RAM and swapfile. Ideally, Cloudron would use close to 100% RAM, but if subsystems dictate a 50/50 split, then perhaps I should increase from an 8GB swapfile to something much larger (I have enough disk to accommodate this easily). Theoretically, suppose I allocate 1GB to /apps.swap? How would that impact Cloudron performance? Would applications crash? Wait for available swapfile RAM? Just trying to figure out how to best allocate extra resources to get better performance.

@bartmathijssen said in Forgejo: @ruihildt I found some time, and was able to create a working package based on the Gitea package. The source code can be found on my Codeberg profile. https://codeberg.org/bart/forgejo-app I tried to take a look but got 404'ed. The page you are trying to reach either does not exist, has been removed or you are not authorized to view it. Is there a different place ? Or private ?

@jdaviescoates Thanks - Not the I have not though about this, but, at last, this could only be a temporary solution following our infrastructure setup. It also does not solve the underlying OIDC issue, which I very much find intriguing.

@scooke I use Google Analytics

Thanks @girish . I can confirm that the bug has been addressed.