Cloudron Forum

@imc67 @girish Yep, couldn't agree more and am repeating myself. Pihole plus Wireguard would be a killer combination and I bet, so many more users, who don't even know what they are missing would start using it.

@girish Maybe this is of help, too....

https://workaround.org/ispmail/buster/mail-client-auto-configuration/

@girish Love it....:-) Thank you for your consideration!

@girish Still hoping for this one to make it into Cloudron eventually...:=-)

https://hub.docker.com/_/solr

@girish I found this here. Dovecot Enterprise have developed their own FTS solution that comes with the commercial version of Dovecot.
All the other referenced solutions are working with the FOSS version of Dovecot, so it says.

https://doc.dovecot.org/configuration_manual/fts/

I keep pushing and hoping....:-)

@girish Again, appreciate the call to move forward faster with small incremental changes.

@girish Getting kind of excited when I read this. Does this mean that Full Text Search for the Cloudron e-mail server could then be in the cards, too?

https://github.com/filiphanes/fts-elastic

@girish Maybe now in the cards...?

https://forum.cloudron.io/topic/2914/activesync-push-notifications-for-cloudron-mailserver

I understand from other posts that this had been looked at before,

https://git.cloudron.io/cloudron/sogo-app/-/issues/4

but it did not work/install at the time. But now there are Ubuntu 18.04 LTS packages available.

https://repo.z-hub.io/z-push:/final/Ubuntu_18.04/

It would surely be nice if we could add push notifications to the Cloudron Mail Server instance.

@nebulon That did the trick, thanks a lot again.

@nebulon Ha...it was not enabled. Let me check the time for the next backup. Thanks a lot meanwhile.

I have just established to mount my home server via sshfs as a backup source. While there are obvious drawbacks It works nicely so far and I want to continue to give it a try.
In view of the more limited bandwidth I have come to realize that the cloudron backup service creates a box.tar.gz on the mounted (limited bandwidth) network share and then copies this file from the mounted share to another directory on the very same mounted share.

I am wondering if this transaction can be optimized in order to be mindful of low bandwith situations?!? E.g. create the box. tar.gz file in a tmp directory on the cloudron server and then copy it to the network share (that should save the read and write transactions from the network share, shouldn't it?)

@Miggi I am a big fan, too and are upvoting.

Please also see this thread:

https://forum.cloudron.io/topic/1355/pi-hole-network-wide-ad-blocking/17?_=1594947401156

Together it makes even more sense.

@girish Like it. Thanks! Faster incremental improvements for the user base rather than waiting longer for bigger changes. Good call!

@ultraviolet Glad I could help...

@d19dotca Thanks for your suggestions! I will try and work on it and report back in case of progress or success....

@savity couldn’t agree more. For me it would be a killer feature. And would make for a nice campaign on Twitter, Reddit et. all. Just look how many people google this and try to establish it manually....this is a mainstream feature, that would be appreciated by the entire user base, much more than specific applications that appeal only to certain users.... my opinion

@girish @imc67 Same here, I think the combination is awesome and makes a lot of sense. PLEASE, PLEASE...Yes...:-)

@girish @d19dotca Thank you for your feedback, good exchange.

I think I need to crawl, before I walk meaning I can work with manual input to get this done.
@d19dotca I think the idea with rsync (or maybe even better lsyncd,
https://github.com/axkibe/lsyncd) is a good one, and I believe I could handle this part. That would pretty much replicate a live backup to another cloudron instance on another domain.

How would one handle the user database? All (e-mail) users would have to exist on the other instance, too, right?

And then - once the primary cloudron instance would go down, one would have to do the DNS re-mapping to the new instance, right?

Conceptually, is this what one would have to do? @d19dotca just following your footsteps and thoughts...

@ultraviolet I had similiar issues and here is what helped me. As a summary:

• Ensure that the local mount point is owned by yellowtent:yellowtent

• Before creating the fstab entry, please try to mount on the command line.

sudo sshfs -o port=23 -o allow_other,default_permissions,uid=1001,gid=1001,IdentityFile=/home/yellowtent/.ssh/id_rsa user@host /backup_sshfs/

I have used sudo because I am assuming that you are not logged in as user yellowtent.