For once, this post is not really to request an app, but to announce that my package for it is ready ^^

https://git.cloudron.io/mehdi/couchpotato-app

http://couchpota.to/

@girish said in What's coming in 6.4:

Specifically, we moved from callback based programming to more modern async/await.

Great ! Honestly, that was long overdue ^^ I think it is a great time investment, as it will definitely speed up future developments significantly.

I quite agree with @timconsidine . We could have these apps on Cloudron, but with a big fat red warning that says the app is unsupported :

• zero user support
• larger backups
• no auto-update

If unhappy: bother the original author.

I am strongly against replacing the server in the current OpenVPN app.

However, it totally makes sense as a new, separate, app.

@ruihildt said in Why not make Cloudron fully open source again?:

I'm sad not to be able to recommend Cloudron as the best open source paas since the license change.
It has in effect changed my relation to the project, from an invested advocate to a simple client.

I totally agree with this part. More than that, I would never have picked up Cloudron at all at the beginning if it weren't open source.

And as to contributions, I am the author of one of these rare contributions ^^ (to make the platform compatible with the OpenVPN app), and I would definitely not have contributed if it were not open source.

TLDR: I am 100% in favor of switching back to an open source licence.

(As for the precise licence, I do not really care, be it MIT, Apache, GPL, AGPL ... whatever.)

I am a regular user of cryptpad, and I can confirm it works well ! It's basically an Etherpad, but with end2end encryption. Would love to see it on cloudron.

@infogulch said in Scaling / High Availability Cloudron Setup:

I'd rather have multi-node app management than distributed app runtime. Manage all your cloudron nodes and assign apps between them, migrate them etc, but most apps can still only be deployed to one cloudron instance at a time. At least I think this would be a better scaling/ha goal for a v1 implementation.

I totally agree, and I think it's the way the cloudron team is headed for the V1

@LoudLemur

Gitea is a fork of Gogs, so they are quite similar : both are lightweight and efficient, but quite minimalist.

GitLab is much heavier, but has much more features.

I suggest going with Gitea if you only need Git hosting + basic issue tracker. I suggest GitLab if you are interested in having integrated CI, more complete issue tracking, package manager, ... basically every bells and whistles you could think of and then some ^^

@lonk It combines Jellyfin (for which there's already an app now), Transmission, SickChill, Couchpotato (the 3 I just mentioned), a custom file manager (built before Cloudron had one), and a custom TV Shows and Movies streaming interface (built before I integrated Jellyfin). Plus a few custom things, like a script to auto-remove finished torrents on transmission, and a script to auto-convert videos to MP4 for easy streaming in the browser (for my custom streaming interface. I disabled it now that I mainly use jellyfin, which handles this automatically).

@girish @nebulon My Transmission app is done, tests and all https://git.cloudron.io/mehdi/transmission-app

In my opinion, it's ready to push to store. It may need a bit more doc, but other than that it's good to go

BTW, the proxyAuth addon rocks !

@nebulon I understand, this makes sense.

Any other step I can take to help you debug the underlying problem with the new version ?

Also, I can confirm that a rollback to v1.1.0 fixes the problem for me. I am disabling auto updates for now

(btw, it's a bit annoying that there is no way to rollback the version without restoring an old backup Would be nice if it were possible on the interface)

EDIT: btw, I also tried on a clean install of Transmission : same behaviour. Seems to work fine when there are no torrents, then crashes as soon as I add any torrent.

@girish OK, after a bit more investigation, it appears that the app stops crashing when I remove the transmission-config dir and restart it, then starts crashing again as soon as I add any torrent to download. There appears to be something in the new base image that transmission does not like at all...

@girish Thanks

After a quick investigation, there appears to be a SegFault in the logs:

 Healtheck error: Error: connect ETIMEDOUT 172.18.18.169:90912023-01-10T18:39:17.000Z /app/code/start.sh: line 21: 17 Segmentation fault (core dumped) /usr/local/bin/gosu cloudron:cloudron /usr/local/bin/transmission-daemon --config-dir /app/data/transmission-config/ --foreground
Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:90912023-01-10T18:40:18.000Z Starting Transmission...
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Transmission 3.00 (bb6b5a062e) started (session.c:769)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: transmission.zde.land (rpc-server.c:956)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:956)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: ::1 (rpc-server.c:956)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Serving RPC and Web requests on 0.0.0.0:9091/transmission/ (rpc-server.c:1243)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:97)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:99)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:105)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:107)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] DHT Generating new id (tr-dht.c:389)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Using settings from "/app/data/transmission-config/" (daemon.c:646)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Saved "/app/data/transmission-config/settings.json" (variant.c:1221)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Loaded 16 torrents (session.c:2170)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Changed open file limit from 1048576 to 1024 (fdlimit.c:408)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:73)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:73)
Jan 10 19:40:27 /app/code/start.sh: line 21: 16 Segmentation fault (core dumped) /usr/local/bin/gosu cloudron:cloudron /usr/local/bin/transmission-daemon --config-dir /app/data/transmission-config/ --foreground
Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:90912023-01-10T18:41:28.000Z Starting Transmission...

Hello !
Long time no see
I just noticed that since the newest update of Transmission, 5 days ago, I get a lot of 502s on the web interface, and it is generally extremely slow. No idea why this is happening. I tried restarting the app, it does not help. Anybody else seeing this ?

Which browser / OS are you using ? Did you try different ones ? I seem to remember a similar issue maybe a year ago, but IIRC it only affected firefox or something. Not sure what the root cause ended up being

@girish said in out of space error leading to missing certs:

@roofboard yes, agreed. I don't like it the way it currently right now that filling up disk space brings everything down. Currently, we have a simple cron checker which will give alerts if it's nearing some amount of disk space but this fails in many cases because it runs only every 6 hours or so (it's not run too often to prevent disk churn).

I think a good long term solution is to figure out how to limit disk usage of apps. I think another thread there is a idea that maybe all appdata can be stored in a XFS partition. We can then enforce quotas on apps.

A good shorter term solution would be to allow to configure the level below which the alert is sent. Depending on if you use your server for storing text files, or if you download video, your "low disk" tolerance will be wildly different.

Hardened node developer here : long story short, nothing to worry about.

NPM security warnings are completely broken, they have a near 100% false positive rate (technically, the "vulnerable" dependency is here, but the flaw is, in literally all instances I have seen, not exploitable). An interesting read about this if you want : https://overreacted.io/npm-audit-broken-by-design/

BTW the cloudrons docs page seems to be wrong:

Ackee is a Self-hosted, Node.js based analytics tool for those who care about privacy

I think there was a copy/paste that got out of hand ^^

@wisameldin Temporary failure resolving 'archive.ubuntu.com' => looks like your server has connectivity issues. Or maybe DNS issues. Which provider are you using?