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

@fbartels said in 2FA for all LDAP apps:

and rotate them regularly

(Forcing password rotation when there has been no indication of compromise has actually been proven experimentally to lower security, rather than enhance it : if encourages users to chose simpler passwords, because they're gonna have to remember more passwords)

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

Personally, from a security standpoint, I would totally not recommend Cloudflare. Their model is literally performing a (authorized) man-in-the-middle attack on your traffic. They have access to all your data.

I'm not saying they're nefarious. I'm just saying that for the minute benefit they offer, I don't think it's worth it to add yet another entity to the chain of trust.

@matthewdykstra I do not know, or I would have said ^^

It is most probably a problem with the packaging : they must have added some kind of cache directory for the plugins in a recent update, and as the cloudron package uses a read-only base, and has not taken this particular directory into account, it fails. This will need a small tweak to the package to fix. The "hard" part (and when I say "hard", it may actually be trivial and take 2 minutes, but it may be harder to pinpoint) is going to be to find which directory.

@matthewdykstra I can reproduce the issue. There indeed appears to be a 500 error when trying to load the plugin catalog.

The default config is supposed to seed at least until a ratio of 2 before deleting the torrents, IIRC.

I know it is not necessary usual for transmission, but transmission has no auto-cleanup feature. I implemented this as default because a lot of people I know had trouble remembering to delete the torrents manually.

I am completely open to removing it as default if the Cloudron core team wants to. In any case, it's quite easy to disable by tweaking your config file and disabling the script-torrent-done thing.

@shodanime is this a clean install of Ubuntu? Or do you already have stuff installed on this server? Because Cloudron should be installed on a fresh Ubuntu install.

@jlx89 Oh OK. So it's probably something to do with your desktop PC's OS / network config / VPN Client software. What are you using ?

@jlx89 This seems related to your ISP then, not Cloudron. I don't think there's much to do to help on the cloudron side of things. Sorry.

Does this happen on every internet connection you try, or only a specific one? If so, what kind of connection is it? In which country? Because this looks like it may be the network blocking OpenVPN connections with DPI.

@robi I do not mean that it is impossible to do. I said that it would not work in this case with the current software : Even if one manages to find a nginx config which would work, Cloudron does not support custom edits of the nginx config, as they would get overwritten all the time. And this would be very custom ^^

@7dowwilkes Honestly, I don't think there is any way to do it with cloudron, as 443 is already taken by HTTPS and there is no way to do both on the same server (well, there are, but they would not work in this case).

However, I think you should look for other ports that your network will allow through, there most probably are some others, like IMAP / SMTP ports, maybe ftp, stuff like that. You most probably would be able to put OpenVPN on these and get it to work.

@girish actually, it's supposed to be very hard to distinguish between OpenVPN TCP and HTTPS traffic on a network level, because they both are in an SSL tunnel, so a firewall cannot see into it and know what kind of protocol is going on inside the tunnel.