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/

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

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

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.

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

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

@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

@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).

Slowly rolling-out automatic updates, but allowing manual updates immediately, seems a great idea to me.

@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.)

Oh, I just had to go to my profile settings and enable it ! I am officially not jealous anymore

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

make the functionality of the Program (…) available to third parties

This means directly. When you host an app that uses MongoDB in the back-end, you are making the app itself available, not mongodb, so no, it does not apply.

CF this citation from Mongo's own FAQ about SSPL:

Does section 13 of the SSPL apply if I’m offering MongoDB as a service for internal-only use?

No. We do not consider providing MongoDB as a service internally or to subsidiary companies to be making it available to a third party.

Or also :

What will happen if someone in the community is currently building something on MongoDB Community Server?

There will be no impact to anyone in the community building an application using MongoDB Community Server unless it is a publicly available MongoDB as a service. The copyleft condition of Section 13 of the SSPL does not apply to companies building other applications or a MongoDB as a service offering for internal-only use.

Source https://www.mongodb.com/licensing/server-side-public-license/faq

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

So I think it does not affect the Cloudron source code but potentially the source code on all apps using MongoDB.

That is not the case. The SSPL provision in question only applies when you sell Mongo itself as a service. Key phrase in you citation :

offering a service the value of which entirely or primarily derives from the value of the Program or modified version

The point is to prevent Cloud service providers like AWS & such to sell managed versions of Mongo, with their own modifications & optimizations, without contributing back to the upstream Mongo.

@drpaneas I believe it's just a cache problem. It seems cloudron answers with a 301 MOVED PERMANENTLY after you have uninstalled the app, and browsers usually cache the 301 responses for quite a long time by default. You should try with another browser to make sure

@infogulch That's totally true, but it assumes that apps are built with Cloudron specifically (or something similar) in mind. It's not the case for most Cloudron apps at the moment

@d19dotca This tests the TLS of the HTTPS server. @Mastadamus is talking about the TLS of the IMAPS server.

@marcusquinn Honestly, not sure. I'm more interested in ejabberd for the XMPP.

But from a quick look at Jami, it doesn't seem that it needs a SIP server, only that it may use one. I think the point of connecting it to a SIP server is more for connecting to the actual phone system, so there wouldn't really be any point to connect Jami to ejabberd's SIP.

Just a few links that may be helpful if someone wants to try packaging it :

• https://docs.ejabberd.im/admin/configuration/database-ldap/#relational-databases
• https://docs.ejabberd.im/admin/configuration/database-ldap/#ldap
• https://github.com/processone/docker-ejabberd/blob/master/ecs/Dockerfile
• https://wiki.jabberfr.org/Intégration_de_LDAP_dans_ejabberd

On first glance, it seems quite packageable. The only thing that I think may be a bit of trouble would be some kind of web interface, to at least provide the Cloudron healthcheck.

I may end up trying to package it up if I have the time some day. But if anyone else wants to give it a go, be my guest!

@jodumont The key is always generated on your own device. There is zero reason to allow users to import an external key. If you don't trust the local app to correctly generate a keypair, you have no reason to trust it to correctly perform the encryption. So importing a key brings nothing.

@infogulch said in proxyAuth addon:

It's by far the easiest auth system to implement first if you write something custom.

I don't think it is.

Cloudron used to have something very similar (in usage, if not technologically), using OAuth. They decided to drop it, because almost no apps supported it.

What you are describing would be indeed quite interesting, but more or less custom to cloudron : i think this would be even more difficult to convince upstream devs to implement, because it's so custom.

Do you know of any apps that currently support a similar thing ?

@doodlemania2 I think you should just use traefik (or another reverse-proxy that handles Let'sEncrypt stuff by itself), and just disable certs on Cloudron's side. You don't really care about the encryption between the Reverse-Proxy and cloudron, if there are self-signed certs, it shouldn't be an issue (as long as the reverse-proxy is configured to accept it)