Cloudron Forum

• Title: IsoFlow on Cloudron - Isometric network and infrastructure diagrams

---

• Main Page: https://github.com/pronetivity/cloudron-isoflow
• Git: https://github.com/pronetivity/cloudron-isoflow
• Licence: MIT
• Dockerfile: Yes
• Demo: N/A

---

• Summary: Browser-based isometric editor for network and infrastructure diagrams, packaged as a Cloudron community app.

---

• Notes: Maintained fork of the original IsoFlow Community Edition with Cloudron packaging, optional Cloudron SSO, JSON import/export, PNG export, and bundled icon packs for AWS, Azure, GCP, Kubernetes, and infrastructure diagrams.

---

• Alternative to / Libhunt link: N/A

• Screenshots:

Smokeping stands out for its ability to provide detailed, long-term network latency and performance monitoring through highly visual, customizable charts, making it an indispensable tool for maintaining network reliability. With Docker images readily available, integrating Smokeping into Cloudron’s app store should be fairly straightforward.

SmokePing is ...

• extensible through plug-in modules
• easy to customize through a webtemplate and an extensive configuration file.
• written in perl and should readily port to any unix system
• an RRDtool frontend
• able to deal with DYNAMIC IP addresses as used with Cable and ADSL internet.

https://oss.oetiker.ch/smokeping/
https://oss.oetiker.ch/smokeping/pub/
https://github.com/oetiker/SmokePing
https://hub.docker.com/r/linuxserver/smokeping
https://hub.docker.com/r/divyavanmahajan/smokeping
https://github.com/jwigley/docker-smokeping-speedtest

Demo:
https://smokeping.oetiker.ch/?target=Customers.OP

I've fixed this. Will send a patch via existing support email thread.

Successfully ported to a cloudron app. Will share link once I'm done testing.

Is there still interest in having Wazuh ported?

Can be closed, posted in Community Apps.

https://forum.cloudron.io/topic/15508/isoflow-on-cloudron-isometric-network-and-infrastructure-diagrams

I am also going to leave this here:

I finally got around to putting together a fix:

https://github.com/pronetivity/cloudron-freescout/commit/27697c310fb373f1a972c7990f5c00dc3052ee54

A detailed analysis is available here:

https://github.com/pronetivity/cloudron-freescout/blob/master/LARAVEL-CACHE-FIX.md

Disclaimer: the commit also includes a few quality-of-life changes. The actual fix is limited to the caching adjustments.

Cheers,
JD

This would be a great addition. Tried it once, finding it a bit rough around the edges but the core functionality is definitely there.

Hey @girish, thanks for picking up the patch!

So, that one cleaned up the queue worker side of things (which was genuinely broken), but the root-owned cache files started appearing again. I've spent some more time on this and I FINALLY found the culprit ...

Turns out it's not anything inside the app container. It's the scheduler sidecar.

On the host:

$ docker ps --format '{{.Names}} {{.Command}}' | grep <app-id>
<app-id>-crontab.0  "/bin/sh -c 'php /ap…"
<app-id>             "/app/pkg/start.sh"

$ docker inspect --format '{{.Config.Cmd}}' <app-id>-crontab.0
[/bin/sh -c php /app/code/artisan schedule:run >> /dev/null 2>&1]

$ docker inspect --format '{{.Config.User}}' <app-id>-crontab.0
(empty - runs as root)

The sidecar runs php artisan schedule:run directly as root every minute, creating scheduler mutex files and other cache entries under storage/framework/cache/data/ owned by root:root. When the app (running as www-data) tries to write to those same directories - permission denied.

Two things I noticed:

1. The sidecar doesn't use the manifest's "command": "/app/pkg/cron.sh" - which uses gosu to drop privileges - it hardcodes php artisan schedule:run instead
2. It runs without a user set, so it defaults to root

The fix from MR61 is still good to keep, but need to address the sidecar situation. For the freescout app specifically, I've now removed the scheduler addon and switched to running the schedule:run job in the same container via a supervisor-managed process. That eliminates the sidecar container entirely.

I've patched and tested the repo accordingly:

https://github.com/pronetivity/cloudron-freescout/commit/6771b826ee45cca6fc75d145f85d9d3da198daae

https://github.com/pronetivity/cloudron-freescout/blob/master/LARAVEL-CACHE-FIX.md

As for the scheduler sidecar - shouldn't it respect the manifest command (or run as the app user)? That would be a nicer fix at the platform level going forward.

Cheers,
JD

Done. Fully integrated.

https://github.com/pronetivity/cloudron-smokeping

@girish apologies, I jumped the gun on that last post. You were right.

I had a look at the box source code (src/scheduler.js, src/docker.js) and the manifest command IS respected by the scheduler. The php artisan schedule:run on my instance came from a custom crontab entry carried over when we migrated from a standalone install to Cloudron over 2 years ago. That entry must have slipped through unnoticed, but it explains everything.

After removing it, the scheduler container (now suffixed -housekeeping instead of -crontab.0) correctly runs cron.sh:

$ docker inspect --format '{{.Config.Cmd}}' 1af144bb-fbf4-434d-8edd-bb4b95c00ef5-housekeeping
Cmd: [/bin/sh -c /app/pkg/cron.sh]

Things are working correctly with cron.sh + gosu now

I should have caught this sooner. In my defense (barely), the Cron tab of the app doesn't mention that commands run as root. I eventually found it in the documentation at the bottom of the Cron page. A small note in the Cron tab itself would probably help others avoid the same mistake.

Cheers,
JD

Has anyone worked on this in silence? If not, will port it

@girish This is as simple as smokeping in terms of implementation. Generally, are you guys interested to move it to the appstore, once tested and stable? Otherwise we'll package it as a community app and set up a build pipe.

It appears that the directories owned by root are created either on the hour or at 45 minutes past the hour. And it seems to be related to those stalled App\Jobs\UpdateFolderCounters job.

@michaelpope Uptime Kuma caters to a completely different use case, although, there is some overlap e.g. webhook reporting and notification. I am running several instances of both, Uptime Kuma and healthchecks in production

Yes, this would be great. However, multi-tenancy might present some challenges due to the service ports required by the Unifi Controller, especially for device discovery. That said, as long as L3 adoption is implemented (e.g. via DNS or DHCP option), using a dedicated custom set of ports for each instance should work fine.

See also; https://help.ui.com/hc/en-us/articles/218506997-Required-Ports-Reference

This is basically a static web frontend with a simple cron based backend. Hasn't seen any breaking updates in a decade and there are existing docker images for it. No one else interested?

I've looked through the app development guide and trying to find some time to build some images for cloudron.

Has anyone worked on this in silence? If not, will port it

@girish This is a bit more complex as it needs to tie into mongodb and has a bunch of ports that have to be mapped. Generally, are you guys interested to move it to the appstore, once tested and stable? This isn't an open source app, so I am assuming, not? If that's the case, will just port it and set it up as a community app with a separate build pipe.

Hi everyone,

A customer using Safari on Apple iOS 18 is unable to access any apps that rely on the managed WordPress app.

Before I investigate further, could someone try replicating this issue?

Initial test with SSL Test Labs comes back clean:

Apparently it's working on a freshly deployed managed wordpress app. So it's probably something with the htaccess configuration or some plugin related problems.