I am strongly against replacing the server in the current OpenVPN app.
However, it totally makes sense as a new, separate, app.
@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).
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.
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)
Oh, I just had to go to my profile settings and enable it ! I am officially not jealous anymore
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 think the cloudron team still accepts Merge Requests, even if it's not Open Source, as long as you sign a contributor's agreement (https://cla.cloudron.io/)
If I can add File Permissions management to the Wishlist for the nice new File Manager please.
Seeing the screenshot in girish's post here (more precisely the icons of the actions on the right), I think it's already done for the next version
@mehdi I guess one hack is to package frontend and backend as separate apps (like matrix synapse/riot). Not ideal but something.
I'm not sure even that would work, as they are supposed to be run as a single server process ... I have no idea if it's only to make things easier, or if the "front-end" part actually uses stuff stored in the DB, etc. In any case, it would at least require extensive manual modifications of the config files to make the 2 apps work with each other
I have no idea what happens if we follow the
Disable recursion or limit recursion to trusted clients in the DNS server's configuration.
But maybe it's a/the solution
It is not a solution. It means the DNS server of the app would be forbidden to ask an upstream DNS server when it does not know a domain, which would basically make it useless
@luckow 100% agree. There should be a port-level firewall config, that defaults to restricting access to local IPs only (RFC1918).
@robi Annoyingly, it seems Cryptpad is impossible to package for cloudron for the moment
Their app requires 2 different origins, or domains: one to serve the UI, and one the API.
Reading their doc, there does not seem to be a way to work-around this requirement.
Once upon a time, Cloudron had a "SSL" addon (or TLS ? I'm not 100% sure of the name), which allowed an app to directly have access to the certs. In that case, it would have been possible to serve the API directly on a different port that way. However, it would have been a very complicated setup, jumping through a lot of hoops, and using another nginx inside the package to serve https on this other port..
Honestly, I don't see a clean way, even taking into account possible changes to cloudron, to do this cleanly. I know supporting multiple domains is planned, but requiring another domain for this app, and only 2 domains, not more, seems very specific to this setup
@lolliop Yes, as @msbt just said, you should not be on Ubuntu 20.04. I'm surprised, how did you end up with cloudron on ubuntu 20 ?
Did you install it directly on 20.04, and the installer worked ? (It should not)
Or did you update the underlying Ubuntu while Cloudron was already installed ? (In that case, I am very surprised that this disk usage thing is the only thing that broke ^^)
There is indeed a problem, looks like the new version of the jellyfin package does not know by default the path of ffmpeg installed by the jellyfin-ffmpeg package.
@pratik to work-around for now, you can go to the admin dashboard, the Playback tab, and in the "FFmpeg path" input, paste
@girish I'm looking for a way to automate this. I think there's a CLI switch. I'll let you know
@girish I think nothing ffmpeg-related has been changed in a while. Looking at the dockerfile, it seems it does install the jellyfin-specific build of ffmpeg, so at first glance I don't see a reason for it to not work. I'll give it a try later today