Cloudron Forum

Right.. thanks for reporting @fbartels . cc @vladimir.d

https://git.cloudron.io/packages/umami-app/-/merge_requests/16

@fanvyr it's intentional to ship the source code. We want users to have a copy of not just the build but also the source code and the build tools. If one knows how, they can trivially change the source files and build dist. Personally, I would love to see this in all the stuff I use I like this kind of freedom, to be able to inspect, change and learn.

(And also, many of our service providers, simply maintain patches which they apply on top of the release and rebuild. So, it's much easier for them).

@fanvyr good investigation! clearly a bug on our side. Fixed in https://git.cloudron.io/platform/box/-/commit/22cb7f7d8fc8312254db4d1ea670d563bf0ff1af

Have to see. There is a risk of using container images maintained by others. What if it suddenly becomes non-free etc. After all, docker has a history of changing pricing (including docker hub).

I would atleast like to move our base image but afaict they offer no hardened ubuntu image.

Thanks for reporting. Fixed in https://git.cloudron.io/platform/box/-/commit/5107cd28c4a0b8b362e9ee5da7151a9271db9fa3 . It won't collapse anymore and you can select it.

The link to http://www.barracudanetworks.com/reputation/?pr=1&ip= ... itself is broken, gets forwarded to https://www.barracuda.com/ which results in a 404. Working link is https://www.barracudacentral.org/lookups but I didn't manage to add the IP as parameter

This is actually the raw TXT record that is in their DNS. It would not be safe to render it as a link, since it is random external data. But also their DNS simply has raw links like above which are i guess broken. For example:

# host -t TXT 70.188.231.171.b.barracudacentral.org 127.0.0.150
Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases: 

70.188.231.171.b.barracudacentral.org descriptive text "http://www.barracudanetworks.com/reputation/?pr=1&ip=171.231.188.70"

Oh, that is rough to send an email when DNS records change. In Cloudron 9, we periodically test the validity of the domain/DNS keys by adding a test record. I guess we can change it to just "read" records and not "write" a test record for say namecheap. Would that work?

w00h00 . @themeerkat works I was sending the /verify incorrectly to surfer instead of hecapte.

@themeerkat yes, I got it going more . I used your example and changed the URLs - https://paste.cloudron.io/saruhogawi.xml . I had to upload the static things (solver, worker, wasm) into surfer . Then, some CORS into nginx (would be great if the hecapte server can have this configurable) and my test site loads. Something is up with /verify , checking what...

This is great, already have it running.

1. git clone https://codeberg.org/TheMeerkat/HeCAPTe-Cloudron.git
2. cloudron install --image codeberg.org/themeerkat/hecapte-cloudron:1.0.0
3. Visited /admin and set a password
4. Created a site id and secret key.
5. <stuck here> . is there an example where I can copy/paste the wasm stuff needed?

I am not a professional programmer. I'm not even good at it.

Wow, that is quite some tremendous work, if that's what you consider yourself

Thanks for the feedback!

On my personal wish list: To be able to set the VPN app as the 'network' for an existing installed app. This way that app can only be reached via the VPN.

The CLI was just meant for app packaging .

It's not a priority for us but happy to take in PRs if people want to build on existing CLI. cloudron domains list etc. Repo is at git.cloudron.io/platform/cloudron-cli

@d19dotca thanks https://git.cloudron.io/packages/wordpress-developer-app/-/merge_requests/20

1. There is no doc yet, hopefully the docs will get updated by the end of the year.

2. Right, app backups don't block app operations anymore. App backups are now totally in background

3. Concurrent backups are fine. Just have to make sure the locations don't conflict i.e storageprovider+target+prefix must not eventually be the exact same location. If you have different prefixes, that is fine too. It is also fine if schedules conflict.

4. I think if SSHFS works, I would go with that. It is much faster since we have optimized code paths for it.

@robi they replied to me saying they won't fix it . They did tell me why, but you might want to reach out to them for more info, don't want to breach confidentiality.

@robi I could reproduce it. There is a bug in the tebi service. It is listing directories as part of listObjectsV2 API call. S3 has no concept of directories, just key/value pairs.

I have reported this to them.

@robi said in Old backup not found when updating app:

Maybe it's an rsync vs tgz issue now, in combination with the former path "/" issue?

Oh, this could be. Testing

@robi ah, it could be that old (invalid) backups are not found. I think if you delete the Site and add it again, it will work . Can you try that?

@dylightful If we can have access to your setup, can you write to me at support@cloudron.io ? Would love to debug and figure out why it's failing . Is this reproducible easily - meaning if you take a backup and restore, it fails?