Cloudron Forum

@DualOSWinWiz Absolutely no idea but please keep us updated!

@potemkin_ai Where is your code? Not an expert but I'm willing to take a look

@luckow said in What does it take to use Surfer as a “real” multidomain surfer?:

In the end, it's more of a UI issue

Second this. One surfer instance for these things is just much easier to monitor too.

@girish Not by design. However this could be easily added since it's just a static website with no complexity

@girish well it’s not really different from the synapse app?

@luckow +1. Use surfer for lots of static, low traffic sites. It's great!

@girish Not a web app and no UI. The bridge is managed via a matrix client after configuring bridge and synapse to sync.

https://git.due.ren/andreas/mautrix-whatsapp-cloudron

Ready for further testing. @girish @nebulon

@robi Not optimal but still useful for my purposes.

@joseph Oh nice!

@robi Not clickable but filterable. Darkmode exists. You can rudimentarily change the layout but this is not designed to be hyper customized it seems.

@d19dotca it’ll break down the memory usage per docker instance for example

@imc67 Well I did the unspeakable and unrecommended thing and installed it on a cloudron as a binary. Very much not recommended so I'm leaving the instructions here so you all can avoid it:

curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && chmod +x /tmp/install-agent.sh && /tmp/install-agent.sh -p 45876 -k "KEY HERE"

And opened up that port on cloudron with iptables:

sudo iptables -I INPUT 1 -p tcp --dport 45876 -j ACCEPT -m comment --comment "Cloudron: Allow TCP 45876 (Manual Addition for Beszel - DO NOT APPLY)"

This is likely not going to be persistent and did I mention not recommended?

Did anyone try setting it up to monitor the same or different cloudrons?

@BrutalBirdie Gemini says:

Conclusion based purely on this AGPL-3.0 license text:

If the Rallly code that implements the user limit and the nag banner is itself licensed under this AGPL-3.0, then:

• Yes, a user or organization (like Cloudron, if they chose) can legally fork Rallly.
• Yes, they can modify the AGPL-3.0 licensed source code to remove the multi-user licensing check and the associated nag banner. This would be considered removing a "further restriction" as permitted by Section 7.
• They must still comply with all other AGPL-3.0 terms when they distribute or provide network access to their modified version:
  • Clearly state that their version is modified (Section 5a).
  • State that their modified version is released under the AGPL-3.0 (Section 5b).
  • Display "Appropriate Legal Notices" (the AGPL ones, not Rallly's proprietary ones) in the UI (Section 5d).
  • Provide the Corresponding Source of their modified version to users interacting with it over a network (Section 13).
  • Keep original copyright notices and AGPL license information intact.

The Neo4j precedent mentioned in the forum discussion is less relevant here if Rallly is genuinely distributing the entirety of this V4 code (including the restriction mechanism) under this standard, unmodified AGPL-3.0. The Neo4j case involved a license that was AGPLv3 plus a "Commons Clause," which was a significant alteration/addition to the AGPL terms. If Rallly is just using plain AGPL-3.0, then plain AGPL-3.0 rules apply.

In summary: The AGPL-3.0 is designed to prevent exactly this kind of "bait-and-switch" where software is offered as "free" under a strong copyleft license, but then functional restrictions are baked in that users cannot remove. The license explicitly gives users the right to remove such "further restrictions."

Oh I think this is why I can't seem to get uploads to R2 working, because this is hardcoded now?

@makemrproper I'm sorry could you summarize or even give step-by-step instructions on what you ended up doing?

Following this topic for the same reasons

I'm not sure, there might be a good argument made fore the existing blocklist. However it made me troubleshoot a federation issue much longer than I wish it would, hence my request here to have the whitelist included if the blacklist is because others might run into similar issues.

Hi @girish

1. The 172.16.0.0/12 Range:

   • This CIDR block represents IP addresses from 172.16.0.0 to 172.31.255.255.
   • The /12 means the first 12 bits are fixed for the network portion, leaving 20 bits for host addresses.

2. Cloudron's Docker Network 172.18.0.0/16:

   • This CIDR block represents IP addresses from 172.18.0.0 to 172.18.255.255.

The range 172.18.0.0 to 172.18.255.255 (Cloudron's Docker network) is a sub-range within 172.16.0.0 to 172.31.255.255.
Since 16 <= 18 <= 31, any IP in 172.18.x.y falls into the 172.16.0.0/12 block.

You are likely looking at 172.18.x.x and 172.16.x.x and thinking they are distinct because the second octet is different. However, the /12 subnet mask on 172.16.0.0 makes it a much larger range that also encompasses 172.18.0.0/16.