Cloudron Forum

@JOduMonT yeah, I think you are on the old package. Please start another instance. In the latest package, we have fixed the NLTK download directory.

It seems one can deploy this on Surfer - https://github.com/linka-app/linka?tab=readme-ov-file#deployment-guide . Unsure, how this works. Maybe it needs CORS support in linkding.

@Jack-613 this is a Cloudron related forum, so if you are not using OpenWebUI on Cloudron, then you should probably ask in the upstream project instead.

@JOduMonT an email server (without email relays) requires a public IP. There is no way around this. Even if you add a second IP, the second IP will be exposed and one can always access your Cloudron dashboard via that IP address. Just have to put an entry in /etc/hosts on my laptop and point that floating IP to my.domain.com and that's it.

I guess you are looking for a way to "sandbox" mail server to a specific IP somehow. We don't have a way to do this in Cloudron. I can move this to Feature Requests.

But also, it might be easier to just create another VM and run mail on the other VM? Security wise , this is the easiest and cleanest instead of writing a lot of code to make sure mail server and dashboard despite being on the same server don't step on each other (networking wise).

@JOduMonT when I last checked, it seems like the certificate is not valid . Valid certs are required for OIDC to work. The site was also behind Cloudflare, so I would recommend disabling that for a start and see if it works without that.

Hi @JOduMonT,

I ran Cloudron with a combination of Tailscale & Cloudflared for two weeks without a public IP at my home setup. So far, everything was working well and I didn't encounter any significant issues. Below is the process that I followed:

1# I had two servers - one for Cloudron and the second with docker and docker-compose. Tailscale was installed and configured with Tailscale IP on both servers. The automatic domain configured was disabled in Cloudron and was set manually.

2# I ran the docker-compose.yml file on the second server using the following:

version: '3.8' services: tunnel: image: 'ghcr.io/shmick/docker-cloudflared' container_name: tunnel hostname: tunnel restart: unless-stopped user: 1000:1000 env_file: - $PWD/tunnel.env volumes: - /etc/timezone:/etc/timezone:ro command: tunnel run network_mode: host TUNNEL_TOKEN={TUNNEL-TOKEN}

3# I set up and configured the domain in the Cloudflared UI, and used HTTPS for the Cloudron Tailscale IP with No TLS Verify enabled.

Yes it will put the raw value into the XML config and then also restart the collabora server in the background. For the actual value, I don't know either, you may have to ask the collabora community for that.

@JOduMonT good idea. I think it would be nice if we had a "migrate domain" which "moves" everything - dashboard, MAIL FROM, mailboxes etc. All these are available individually but not as a single operation.

Can you make a feature request?

@JOduMonT Since 3 weeks there is no new Cloudron Vaultwarden App update.

App Title and Version: Vaultwarden 1.27.0
Package Version: com.github.bitwardenrs@1.11.0
Last updated 26 Dec 2022
https://www.cloudron.io/store/com.github.bitwardenrs.html

Please follow the mysql tasks again. I hope that this process will not be necessary when we get a new Vaultwarden app update.

@girish said in no password when update to 1.11.0:

@jayonrails this is only on older instances

...and only on some of them. I never hit this issue myself.

How should I read the doc made by the Cloudron team. 😉

@girish hey forgot to mention.
My IP is not listed but the AS network is declared as spammy.

While I contacted OVH for this and I respect their answers, they said they are not willing and paying for deblacklisting their network because it like an hostage situation.

So I asked them to change the IP of my instance, let's see.

Thank you for both of your replied.
@nebulon yes, I read the doc and configured the well-known for the domain via the Cloudron interface.
It's just, maybe I miss reads, but the Step 3 confused me.

@JOduMonT thanks, that's really helpful 🙂

To add the key to the config.js, I added this code below the admin keys part (it can go anywhere though):

supportMailboxPublicKey: [ "~~~YourPublicKeyHere~~~", ],

The snippet in context looks like:

adminKeys: [ //"[cryptpad-user1@my.awesome.website/YZgXQxKR0Rcb6r6CmxHPdAGLVludrAF2lEnkbx1vVOo=]", ], supportMailboxPublicKey: [ "~~~YourPublicKeyHere~~~", ], /* ===================== * STORAGE * ===================== */

And then just restart the app 🙂

@JOduMonT

This looks really cool, any progress on building a docker container or getting this running?

@JOduMonT you're right. "official" was the wrong wording. What I meant was use is to use the notes functionality of Nextcloud and then use an app on ios that is designed to sync with it.

Which honestly is a bit of a pity since most note sync applications are markdown or plaintext, while systems like Apple Notes and Microsoft Onenote allow for more functionality (multimedia, cross application integration and stylus support).

@JOduMonT Both issues are fixed in the latest package.

@JOduMonT it is only a daemon, but sometimes containers are recreated, images are managed and so forth which may use up a lot of server resources temporarily, especially if disk I/O is slow.

To give some reference here, we are talking about the code section from https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js#L318 to https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js#L340 so something is slow on your system in that area. Not sure how much tinkering you want to do for debugging, but you could stray in some console.log()s there to narrow down the issue. I can also help here, if you enable remote SSH support and send us a mail with your dashboard domain to support@cloudron.io

@nebulon said in my.cloudron.tld is not accessible:

nosudo

thank you for eyes and help 😉
this is so weird and like you I don't know that option.

also; etckeeper as not being initiated on that server, so I'm unable to retrace when that change has been made

@JOduMonT thanks for the info and research. The encrypted password handling in dolibarr as described does not make too much sense for us, since the password might change during package update, depending on the database addon thus it always have to be fetched freshly. Further it will always be present in the app's environment as injected into the container.

For phpinfo() I am not sure how this is an attack angle, since if one is able to inject php code to run phpinfo() the attacker might as well just simply dump the env variables manually.