The Heimdall app launcher / dashboard would be a great addition to the build in app luncher for cloudron.
Maybe even a preset provisioning with the cloudron apps could be accomplished.
Packaging the docker image should be fairly easy (I think).
The Heimdall app launcher / dashboard would be a great addition to the build in app luncher for cloudron.
Maybe even a preset provisioning with the cloudron apps could be accomplished.
Packaging the docker image should be fairly easy (I think).
An LDAP server would be great. I would vote for an identity provider (with LDAP, Oauth, etc.)!
I think @jimcavoli is already working one something along these lines: https://forum.cloudron.io/topic/2320/scaling-high-availability-cloudron-setup/5
@MooCloud_Matt I love the Unifi ecosystem and have used it in many (even quite large) installations. I would always recommend to keep the controller on an appliance on its own seperate from all servers (e.g. on the Cloud Key Gen2 or Dream Machine Pro) though with a spare controller hardware in stock. Just my 2 cents though. Might be useful for others to run this on cloudron. I believe there is an unofficial docker image available somewhere as I have seen it run on Synology NAS systems in Docker. This might me helpful for packaging.
I would also be interested in this. Maybe @girish and @nebulon could offer a (paid!) recorded webinar with some simple sample apps? Maybe even some more advanced "tutorials" later on? I would also be willing to pay for this, and most likely others as well. Recording these webinars and offering them in a web shop should not be too hard and this might be another source of income for cloudron and get more apps in the app store in the future.
@girish Awesome! You guys really know how to set priorities and I love the direction cloudron development is going in! Great job guys!
Thanks for this write-up. You can easily adjust this to use a wireguard tunnel (apt install wireguard-tools) and port forwarding instead of Tailscale and a reverse proxy. Just use destination NAT and source NAT to route all outbound traffic through a VPS (I use a cheap 1€/month VPS) with a public ip and forward inbound ports to your private server behind a NAT (eg. at home, etc). This works, even for email.
The concept is the same as with Tailscale above, but without a reverse proxy and port forwarding instead (making email etc. work). Just use the following Wireguard configs (adjust to your specific needs):
Wireguard config (/etc/wireguard/wg0.conf) on your public VPS (IP: 1.2.3.4)
[Interface]
PrivateKey = AAAAAAAAABBBBBBBBBCCCCCC= # (<- server privte key)
Address = 10.10.10.2/32
ListenPort = 51822
PreUp = sysctl -w net.ipv4.ip_forward=1
# (replace ens6 with your server network interface)
PreUp = iptables -t nat -A POSTROUTING -o ens6 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o ens6 -j MASQUERADE
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.1:80
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 80 -j DNAT --to-destination 10.10.10.1:80
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.1:443
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 443 -j DNAT --to-destination 10.10.10.1:443
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 25 -j DNAT --to-destination 10.10.10.1:25
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 25 -j DNAT --to-destination 10.10.10.1:25
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 465 -j DNAT --to-destination 10.10.10.1:465
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 465 -j DNAT --to-destination 10.10.10.1:465
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 587 -j DNAT --to-destination 10.10.10.1:587
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 587 -j DNAT --to-destination 10.10.10.1:587
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 993 -j DNAT --to-destination 10.10.10.1:993
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 993 -j DNAT --to-destination 10.10.10.1:993
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 3478 -j DNAT --to-destination 10.10.10.1:3478
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 3478 -j DNAT --to-destination 10.10.10.1:3478
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 4190 -j DNAT --to-destination 10.10.10.1:4190
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 4190 -j DNAT --to-destination 10.10.10.1:4190
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 5349 -j DNAT --to-destination 10.10.10.1:5349
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 5349 -j DNAT --to-destination 10.10.10.1:5349
PreUp = iptables -t nat -A PREROUTING -i ens6 -p tcp --dport 222 -j DNAT --to-destination 10.10.10.1:222
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp --dport 222 -j DNAT --to-destination 10.10.10.1:222
[Peer]
PublicKey = AAAAAABBBBBBCCCCC= (<- private servers public key)
AllowedIPs = 10.10.10.1
PersistentKeepalive = 25
(If you use the TURN server, you might want to forward additional port ranges)
Wireguard config (/etc/wireguard/wg0.conf) on your private server:
[Interface]
PrivateKey = AAAAAABBBBBBCCCCC= (<- private servers private key)
Address = 10.10.10.1
ListenPort = 51821
[Peer]
PublicKey = AAAAAABBBBBBCCCCC= (<- public VPSpublic key)
Endpoint = 1.2.3.4:51822
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
During install (or after setting up the Wireguard tunnel), make sure you set your Cloudrons public IP manually to "Static IP" and enter your public VPS ip address.
Don't forget to set Wireguard to start as a service and enjoy your Cloudron instance on a home server.
systemctl enable wg-quick@wg0.service
systemctl daemon-reload
systemctl start wg-quick@wg0
This is nothing I would recommend for an enterprise grade deployment, but might be suitable for a testing/development instance.
Getting elasticsearch into Cloudron would be great! Fulltext search for Nextcloud is a must and running a separate instance side by side to cloudron is very inefficient...
@girish said in Is cloudron subscription per 'instance' or per 'customer':
@dfldadm The pricing is per instance. For email atleast, I recommend, running it on a separate VM along with a webmail. This won't cost you anything since it's covered under the free plan (email is also not counted as an app).
That's an interesting idea. Is there any way to sync the users between the two separate instances? If we run email and webmail on a separate instance we would have two seperate user bases, right?
Maybe exposing LDAP (encrypted) to another instance (or even better: active-active LDAP sync) would be something for the future? This would add the possibility to run multiple servers with the same user basis.
Licensing would be something to look into and a single dashboard which connects to the apps would be needed as well. So just some ideas here. You guys are doing an incredible job in what you are doing (plus contributing upstream) and I can't say enough that I really appreciate the hard work and support that all cloudron contributors are putting into this amazing product!
@marcusquinn You‘re welcome. We are using openwebui with RAG (our own documents aka knowledge) for the IT support team. We are using it on cloudron together with the private IONOS AI Hub. Great service if you are serving EU customers.
@timmeh scaleway is/was facing an issue with their object based storage in Amsterdam:
https://status.scaleway.com/incident/775
I was facing the same issue and just created a new bucket and used that one for backups. Should be fixed on the scaleway side soon though.
Thanks for the update @girish! The 5.1.5 update of cloudron fixes the error and Kopano Meet is working now.
Sometimes, mail providers such als Gmail/Yahoo/AOL can be picky when accepting incoming mails from self-hosted mail servers, even if they come from a reputable IP address of a cloud hosting provider. Mails are being temporarily rejected with a 4xx error code and it can take a long time for them to be accepted, if at all.
Would it be possible to have a configuration in Cloudron to use an external SMTP relay service for mails only in case a mail stays in the queue for a (configurable) time, e.g. 30 minutes?
Cloudron could continuously monitor the outgoing mail queue and if a mail is in the main queue for a certain amount of time without being delivered, it could move it to a secondary queue, configured with an external SMTP relay (mailgun, rapidmail, etc.) to ensure delivery of the mail.
Any thoughts on this? Would this be possible?
@girish said in matrix.org (communication):
@subven Yes, I am not 100% sure if the configuration I have actually works (for federation) but in theory it should. For the
well-known
, we are looking into adding this to Cloudron itself (probably in the domains view). We can then do mail auto-discovery, mastodon etc.
Heads up for adding the well-known to the root domain! As you said, this would add autoconfig for mail as well which would be great. Not quite sure if this could be added as a configurable feature for Caldav for example, as users could use different Caldav server (Sogo, Nextcloud, etc.)
@echokos From what I know the DNS settings will be propagated correctly and set to the new IP if you enabled DNS management in cloudron right after restoring the backup on the new server. There is also the "dynamic IP" option which you can set in case the automatic switchover does not work and DNS records are not set correctly. This should not be necessary though.
Wow, what a big step to release this as open source. Especially with Jisti being hard to be packaged, this would be awesome to get running on cloudron. I am not aware of any solution offering a videobridge/MCU/etc. so far that is available on cloudron, so this would be a great addition.
Thank you! A local installation of imapsync on the server did a great and fast job in transfering the emails from one account to the other.
Having this available in the cloudron universe would be simply awesome and a big selling point. I have so far not seen any providers offering a hosted solution with the Talk High Performance Backend. @doodlemania2: please keep us updated on the packaging. If you need help with tests, etc. let us know. I really appreciate that you are willing to give it a try!
Together with a future elasticsearch service (hopefully) for full text search, cloudron will become a great nextlcoud hosting platform.
@Vladimir You might want to check (via command line) if you have any stale sieve filters left for the mailbox. This might happen if you switched the webmail installation.
I am pretty happy with this in openwebui:
@girish said in What's coming in 4.5:
Mail fts search - This will be optional since the dovecot+solr integration takes a lot of memory.
Mail fulltext search for dovecot with solr would be awesome. I would love to see solr being integrated in a way that other apps can use it, eg. for implementing a Nextcloud fulltext search.