Cloudron Forum

Currently, tika ia only part of the mail server but we can make it a service/addon - https://docs.openwebui.com/tutorials/integrations/apachetika/

I am active there . r/selfhosted is self hosting enthusiasts and tinkerers. There was a survey a while ago about the users and a veyr big chunk was mostly people trying to learn devops/k8s and it doesn't matter if thigns break and you have to start over. Given the personal and education use space, it has a bias for "free" as in beer stuff. Nothing wrong with all this, just giving some context around that sub . It's a great sub for discovering new projects and getting some tips here and there (off late, the technical users have dried up a lot though) . Depending on the mood of the day, you might even get downvoted if suggesting using a VPS btw It's because they are much in the homelab and hosting with laptops on a private lan .

An anomaly in all this is that they are vehemently against selfhosting email (you can search for various threads)

@avatar1024 said in Email search not working properly:

What's tika?

tika is this - https://tika.apache.org/ . it converts the pdf/docs attachments in emails to text to make them searchable

@baris thanks !

chat is re-enabled now. For those who don't want it , there is a setting in the profile:

@charlesnw I think the best approach is to do a restore yourself to understand how it all works . See https://docs.cloudron.io/backups/#restore-cloudron .

For backup frequency, see https://docs.cloudron.io/backups/#schedule

To overall explain backups:

Cloudron Backup = Box backup + Email backup + App backups

The box backup has many things including users, domains, profiles, settings, apps installed, backup i.e everything you do in the dashboard . Email backup is the emails (just that) . App backups is each app backed up separately. Together, all these backups form a single Cloudron backup.

We are yet to hit a situation to restore user database separately. Not sure why this is needed but you can restore the full cloudron from Cloudron backup if your server hard disk crashes . You can also restore individual apps. This is needed often when an app update went wrong.

There is no UI to restore an individual email account. Not sure why this is needed (can someone even delete all their emails by "accident" ?) But you can just copy that single mailbox from the email backup into the live cloudron instance to restore. There is no magic here, you can just open the backups and see what's inside them.

There is an initial package at https://git.cloudron.io/cloudron/owntracks-app . It will get published eventually .

@canadaduane thanks for the heads up . https://docs.openwebui.com/license/#open-webui-license-explained has an ELI5 of sorts

@jdaviescoates said in Nextcloud OIDC integration:

I wonder if @staff could rename the provider to something more generic like "Open ID Connect" or "OIDC"?

Those terms are just generic technology terms. One should always have "Login with <provider>" . Like Login with gmail, Login with Github etc. Login with OIDC doesn't actually mean anything (unless it's providing some dropdown of providers after clicking the button). I think we should open a bug report upstream, seems easy to fix

@simon might be worth reporting upstream . Closest I found similar to your issue is https://github.com/louislam/uptime-kuma/issues/3276

I guess you are on an internal network? If so, port 40000 has to be port forwarded as well. On a public network, you have to make sure 40000 is open in any Cloud firewall.

The Cloudflare warning exists because Cloudflare only forwards http (port 80, 443).

LDAP uses a custom port and won't be compatible with Cloudflare. Cloudflare only proxies HTTP. OIDC should be compatible with Cloudflare though .

@q__nt_n we are looking into implementing this for the next release as part of 8.1 .https://forum.cloudron.io/topic/9975/what-s-coming-in-8-1 . As for the API, indeed, it seems to be missed in the API docs. But you can just call /api/v1/apps/<appid>/backup POST . This will return a taskId to track as well (similar to other API calls).

Wow, this ran with basically no effort on my machine. Just 3 commands - https://github.com/HeyPuter/puter?tab=readme-ov-file#-local-development

There's no uninstall procedure as such since the installation script doesn't keep a copy of all the things it changes. It's best to just reimage ubuntu.

Cloudron is developed like a platform/OS and it touches everything - docker, nginx, dns configuration, systemd services, iptables, nodejs etc.

@hpz24 said in Best practice for migrating apps from one Cloudron to another?:

Now I'm curious: does an app actually survive the move to another cloudron instance with a different domain?

In most apps, yes. The federated apps like mastodon and matrix are a special case. They don't support changing the domain . Even though the app itself will work after changing the domain, expect bad things to happen (tm) after domain change. For example, not seeing proper history of old message etc. I haven't tried this much, so this is just a warning really.

@umnz it opens a new tab for me . Which browser are you using?

@SansGuidon I think your approach is the best as of right now. We will have to add automatic restart built into Cloudron at some point.

@AartJansen said in Email sending broken after updating to 8.2.x (due to IPv6 issues):

So with a self hosted install I would need to ask the ISP to set up the ipv6 PTR like they ip4 record ?

yes

@avatar1024 usually, if that happens it's because something else is enabling ipv6 on the interface. Do you use netplan? If so, I could chek /etc/netplan/50-cloud-init.yaml . Does it have some statically assigned ipv6 block?

The tika error seems to be because tika was down . I think a UI button to rebuild index will help a lot.