F
For those that would be interested. I have just created a live stream on Youtube for Sunday 21.06. 14:00 (CET). During that stream I want to show a bit how to make a Cloudron app and will use Matterbridge as the example for it.
I would timebox the whole stream to a max of two hours, lets see how far I'll get in that time, maybe I won't even need that much time.
There will be an unedited recording of the stream later on.
You can follow the stream at
WireGuard
automation from homelab to enterprise
Create Manage Automate
️ WireGuard Networks
(Uses the native Wireguard apps for the clients, so already very mature tried & tested open-source for that part of the overall)
Hi everyone,
I saw a post yesterday on Reddit showing how to use the Google Cloud free tier to run Uptime Kuma. One of the alternatives for free hosting mentioned in the post was fly.io and since their tooling intrigued me I have since then started hosting Uptime Kuma on their platform (combined with notifications through Telegram to be as independent from my own infrastructure as possible).
Their free tier includes a vm to run own code or a docker container along with 1cpu and 256mb of ram. this can be coupled with a persistent storage volume of 3gb, so plenty of resources for Uptime Kuma. In addition to this they allow usage of own domain names so you can have your status page at https://status.mydomain.com instead of on one of their subdomains.
All you need is the following toml file to deploy the Uptime Kuma container on fly.io:
# fly.toml file generated for mykuma
app = "mykuma"
kill_signal = "SIGINT"
kill_timeout = 5
processes = []
[build]
image = "louislam/uptime-kuma:1"
[mounts]
source="kuma"
destination="/app/data"
[env]
PORT = "8080"
[experimental]
allowed_public_ports = []
auto_rollback = true
[[services]]
http_checks = []
internal_port = 8080
processes = ["app"]
protocol = "tcp"
script_checks = []
[services.concurrency]
hard_limit = 25
soft_limit = 20
type = "connections"
[[services.ports]]
force_https = true
handlers = ["http"]
port = 80
[[services.ports]]
handlers = ["tls", "http"]
port = 443
[[services.tcp_checks]]
grace_period = "1s"
interval = "15s"
restart_limit = 0
timeout = "2s"
The configuration refers to a volume called "kuma", which needs to be created before the app can be deployed by running flyctl volumes create kuma.
I have written a bit more in detail about on on my blog: https://blog.9wd.eu/posts/flyio/ (first draft status, may need refinement)
Hi,
I'm thinking about creating a Cloudron app that uses fetchmail to fetch external mailboxes and deliver their mails to local accounts. Depending if I find a good example for a config ui this would then be configurable either from a small web ui or by simply editing the fetchmailrc file from the console.
Anyone else interested?
Hi,
I am not using it myself, but could imagine this being useful to others. Looking at their deployment structures this only needs node and a postgres database.
Look like an interesting notion like systems with a powerful plugin system. There is a plugin for realtime collaboration even. Markdown parses nicely in their editor as well.
The only downside, it feels like a single user architecture. But for an experiment it could be put behind cloudrons auth wall. Might give it a shot next week.
@girish said in Incorporate a WAF built into cloudron:
it should totally possible to move to apache instead of nginx for the reverse proxy, with some effort
I'm not sure if moving from Nginx to Apache is a very "modern" decision. There has been a buzz on this forum about Crowdsec a few weeks ago, maybe this would another approach that is possible (although the downside seems to be that you lock people into a third party SaaS).
In regards to reverse proxies. I recently spent quite some time working with apisix, which is basically nginx/openresty with an additional manage api in lua. It can get its route configuration either from etcd or a yaml file (other backends could afaik be implemented as plugins). And since its based on Nginx its quite fast.
I recently talked to the CEO of Humhub and also made him aware of Cloudron and this topic. He said that they are currently busy with investigating ways to automate deployments in container scenarios and once that is solved they would be open to collaborate on an app for Cloudron.
Since I am always missing notifications in Cloudron (don't log into the dashboard often enough) I decided to add a monitor for it to Uptime Kuma.
"notifications":[]360 (could be higher however, I don't need instant alerts for new notifications)Since the api only works with auth, we also need to send a header for this. For this paste the following in the "Headers" field:
{
"authorization": "Bearer xxx"
}
The xxx needs to be replaced with a valid api token, which can be created in the user profile.
Everything you can see on the Cloudron dashboard comes from the Cloudron api. So if further checks are needed I always recommend to pop out the network console and check which endpoints get requested for the data you need.
To simplify logging into my Cloudron hosted Gitea I wanted to configure the new OpenID Provider, which was introduced in Cloudron 7.4. I wrote down a blog with the detailed steps in case someone wants to replicate this configuration.
@msbt said in Proposal: Free-Tier Alterations 
:
Not sure if paying for updates defeats the purpose of having a secure system with rolling auto-updates
Exactly. I think it's bad practice to hide things like updates and 2FA behind an extra paywall.
Plus it was like this in the past already and was changed for the very same reason: you don't want to have people with vulnerable old versions out in the wild.
@necrevistonnezr said in Jitsi:
Mailbox.org is switching away
One bit of context that is not in the post is that OpenTalk is developed by the same people/company that are operating mailbox.org
A post of @luckow has made me interested in baserow (which is already available as an app on Cloudron). With it you can define databases and fill these through a form. It already has the ability to trigger a webhook if an entry was created.
At the moment the webhook payload cannot be freely defined, but if it would add this feature one could make a simple sign up page for Cloudron. User would be created, but sadly one needs to make multiple requests to also send out an invitation mail and to add the user to groups. But this way the admin can decide on their own if the signup should be confirmed.
I have meanwhile made the app public so anybody can now install it from my git repo. It can be found at https://github.com/fbartels/cloudron-drone-app
@necrevistonnezr I am not using bitwarden on Cloudron, but in general you can enable an admin interface, which would then be available at https://your-bitwarden.cloudron/admin.
From that interface you can delete users.
This sounds like a nice imitative.
I think I would piece this together a bit differently. Having a small bash script as the glue that holds it together is fine. But instead of installing the cloudron cli via npm I would just execute is as a docker container. This way you also have more control over versions and don't need to tell people to manually update the cloudron cli.
Instead of asking people to manually download the manifest and favicon, let them supply the url to the git repo of the app. Then you could do a local clone and get these files from the clone. This also opens up the possibility of building the app locally instead of using somebody elses (potentially untrusted) container image. For apps that should still be pulled instead of built you could include a text file with the address of the container instead of having to have your user copy it manually into a file.
The other benefit of putting some of your logic inside of a container is that your could there rely on better tooling instead of parsing yaml files with bash.
I have only had a quick glance at your script and the way it looked to me you need to have one configuration file per app (and also one copy of your script per app?), which will lead to a lot of duplication.
Edit: and for the approach with the surfer app you should make sure to tell people to create these files in a place that is not served to the internet. Else you may expose your API key to the public.
@compotter yes selecting a mailbox for catchall that is located on a different domain would be nice.
Instead of checking all these mailboxes I worked around the issue by added a rule in Roundcube to forward all mails to this "catch all inbox" to my actual inbox.
@d19dotca said in Cachet - status page system:
I think the more common ones to Cachet is StatPing, ..
I played around with statping today. What intrigues me about it (apart from it being written in golang) is the ability to use custom webhooks and even own scripts for notifications.
App is located at https://git.cloudron.io/fbartels/statping-app/, but surely can use some more polish. But it is generally in an "it works" state.
Instead of directly installing imapsync on the Cloudron host you could also use the official docker image of imapsync. This way you could just run docker run --rm gilleslamiral/imapsync imapsync <usual imapsync arguments> which will leave no traces once the execution has finished.
More info:
https://hub.docker.com/r/gilleslamiral/imapsync/
edit: full sync command. Since running the container on the cloudron host i also decided to run it in the host network to be able to just localhost for the cloudron mailbox.
My current command is:
docker run --rm --network host gilleslamiral/imapsync imapsync \
--host1 old.server.com --user1 old.user --password1 REDACTED --ssl1 \
--host2 127.0.0.1 --user2 cloudron.user@domain --password2 REDACTED --ssl2 \
--nosslcheck --useheader Message-Id --automap --dry