Cloudron Forum

@nebulon Yes, they still have ongoing problems... Even if they mark as “solved”, problem is not fixed.

This can affect Cloudron installations.

Just tried to install Cloudron again but...

Err:75 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-firmware amd64 20240318.git3b128b60-0ubuntu2.26
  429  Too Many Requests [IP: 2620:2d:4000:1::103 80]
Fetched 220 MB in 5min 41s (643 kB/s)
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_20240318.git3b128b60-0ubuntu2.26_amd64.deb  429  Too Many Requests [IP: 2620:2d:4000:1::103 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

@james Trying a second install, on previous broken Cloudron installation, will give this:

=> Updating apt and installing script dependencies
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...

while

tail -f /var/log/cloudron-setup.log

give this:

Running cloudron-setup with args : --

@james Yes, I know very well that Repos is not managed by Cloudron, but whole process can interfere with Cloudron installations and be critical specially when configuring a new Cloudron in a case of disaster recovery or switching Cloudron instances with backup/recovery, or simply when installing a new Cloudron instance.

In fact, if repository cannot be reached, Cloudron cannot be installed.

Hetzner give a good guide on how to switch, and also their repository is always reachable, fast and stable.

How @robi suggested, it could be interesting to add to Cloudron install script some strings to avoid this kind of issue.

Could be a speedy mirror or ability to pass parameter in ./cloudron-setup eg. ./cloudron-setup -h or something where user can chose wich mirror to use. -h = Hetzner, and so on.

At this point, script will manage all the whole process and continue installation of packages and Cloudron instance.

Ubuntu Repository is often slow and unstable.

In last months I had several time same problem: unreachable, overloaded...

In Cloudron installation script it could be interesting to select (or auto shift based on ping) a different mirror as an alternative.

This is a real time video record of the speed today:

Err:75 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-firmware amd64 20240318.git3b128b60-0ubuntu2.26
  429  Too Many Requests [IP: 185.125.190.82 80]
Fetched 291 MB in 14min 1s (346 kB/s)
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_20240318.git3b128b60-0ubuntu2.26_amd64.deb  429  Too Many Requests [IP: 185.125.190.82 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

And then result is:

=> Installing base dependencies (this takes some time) ...Init script failed. See /var/log/cloudron-setup.log for details

@james Yes, this is a great find. Thanks a lot for your cooperation.

In email service’s logs no any log...

Whenever you want, I can reproduce issue and I can send you raw log.

Keep me posted.

Thanks again @james for your cooperation.

I can confirm that after removing custom Spamassassin rules from Email > Settings > Spam Filtering > Custom Spamassassin rules problem has been solved.

However, further testing would be needed to determine which rules interacted negatively with emails, potentially causing false positives.

@imc67 So were we using the same rules from @d19dotca ?

For now I removed from all istances, but in future I want to keep only rules who works in local, not requiring any outbound connection.

@imc67 Hi, what kind of rules you added?

I’m asking this because I had issues receiving emails (here my post) and I was applying these rules in Spam assassin, that probably blocked emails.

I’m still doing some tests but is interesting to know what kind of rules you was using.

Thanks

Hi @james there is also another option to completely disable image preview generation, or limit to only some providers:

For high security deployments we recommend disabling the preview generation by setting the enable_previews switch to false in config.php. As an administrator you are also able to manage which preview providers are enabled by modifying the enabledPreviewProviders option switch.

Sources:

• Disable preview image generation
• Configuration Parameters
• Previews

Ok @james. I’ll do more accurate research

@james Thanks a lot for your question.

IOPS it seems to be good...

Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 510.82 MB/s (127.7k) | 870.43 MB/s  (13.6k)
Write      | 512.17 MB/s (128.0k) | 875.01 MB/s  (13.6k)
Total      | 1.02 GB/s   (255.7k) | 1.74 GB/s    (27.2k)
           |                      |                     
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 595.93 MB/s   (1.1k) | 1.49 GB/s     (1.4k)
Write      | 627.60 MB/s   (1.2k) | 1.59 GB/s     (1.5k)
Total      | 1.22 GB/s     (2.3k) | 3.09 GB/s     (3.0k)

Hi @james I’m still managing this problem. There is a way to manage Haraka timeout to avoid this Connection timed out issue, eg. making longer timeout?

@girish Thanks a lot, this is a great great news!

@crazybrad Yes, plugin isolation is one of the most powerful things ... actually plugins access to all core functions of WP...

I didn’t see yet the Playground, but I would like to see if platform is lighter than WP.

@robi It seems that some parts are required, eg. Cloudflare Workers.

@crazybrad with pleasure. Let see if this can be self-hosted and implemented in Cloudron... but I don’t think so...

@james Yes, interesting concept of isolation but I think this is somethings that have to depend from Cloudflare services... cannot be, eg, self-hosted... or not?

EmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress

A full-stack TypeScript CMS built on Astro and Cloudflare. EmDash takes the ideas that made WordPress dominant -- extensibility, admin UX, a plugin ecosystem -- and rebuilds them on serverless, type-safe foundations. Plugins run in sandboxed Worker isolates, solving the fundamental security problem with WordPress's plugin architecture.

• https://blog.cloudflare.com/emdash-wordpress/
• https://github.com/emdash-cms/emdash

@robi Amazing!!!

Something like a “bridge” that every day take from the source and update Cloudron block list...

@robi Thanks a lot.

I found and applied specific rules in Wordpress .htaccess:

• 8G Firewall
• Ultimate Block List to Stop AI Bots

I think is a good start.

Both filters it seems working fine. Of course, it would better to manage and deploy centrally.

Thanks again for your advices Robi.

@riankellyit thanks a lot for your advices, I’ll go to try to better understand, but actually problem seems to be resolved, so as @nebulon, problem seems to be S3 side. Thanks again for your patience and efforts.