I'm gonna try to package it up for Cloudron this evening and report back here with my results.

Best posts made by infogulch
-
RE: Notea
-
RE: Notea
I started a cloudron app package for Notea, you can find the source here: https://source.infogulch.com/infogulch/notea-app If anyone wants to try it, the docker image for this source is
infogulch/notea-app:0.0.1-6
.I did run into some trouble after getting it to start successfully:
- I'm using a minio instance on the same cloudron as the data store for Notea since it doesn't support local file storage directly. This means that it's a bit awkward to configure; after installing the app, open the terminal and edit
/app/data/env.sh
to add the s3/minio backend storage config, then restart the app. - I used proxyAuth because I think it's the bees knees but that mostly just caused me extra problems because the notea app implements authentication itself and redirects to
/login
which obviously doesn't work very well with proxyauth. I did open an issue to request an option to disable the login page.- In the meantime, it would probably be more expedient to relent and disable proxyAuth, and use notea's built-in authentication which is just a password configured by setting the
PASSWORD
env var inenv.sh
- In the meantime, it would probably be more expedient to relent and disable proxyAuth, and use notea's built-in authentication which is just a password configured by setting the
- I'm using a minio instance on the same cloudron as the data store for Notea since it doesn't support local file storage directly. This means that it's a bit awkward to configure; after installing the app, open the terminal and edit
-
Notea
Notea / https://github.com/QingWei-Li/notea
Self hosted note taking app stored on S3. Notea is a privacy-first, open-source note-taking application. It supports Markdown syntax, sharing, responsive and more.
Brought to my attention by @yusf on Notion-like FOSS app thread.
-
RE: Nice ideas for reducing container size
Just to put my money where my mouth is, here is a formatted view of
docker system df -v
from one of my cloudrons which shows for each image what its "size", "shared size", and "unique size" is (I hope fits nicely):REPOSITORY SIZE SHARED SIZE UNIQUE SIZE cloudron/org.navidrome.cloudronapp 2.212GB 2.176GB 36MB cloudron/im.riot.cloudronapp 2.223GB 2.176GB 47MB cloudron/com.github.bitwardenrs 3.286GB 2.176GB 1110MB cloudron/org.matrix.synapse 2.555GB 2.176GB 379MB cloudron/org.jupyter.cloudronapp 3.358GB 2.176GB 1183MB cloudron/io.gitea.cloudronapp 2.326GB 2.176GB 150MB cloudron/github.pages.cloudronapp 2.286GB 2.176GB 109MB cloudron/net.minecraft.cloudronapp 2.723GB 2.176GB 547MB cloudron/org.fireflyiii.cloudronapp 3.269GB 2.176GB 1093MB cloudron/com.docker.registry 2.284GB 2.176GB 108MB cloudron/mail 2.844GB 2.176GB 668MB cloudron/sftp 2.194GB 2.176GB 18MB cloudron/io.minio.cloudronapp 2.236GB 2.176GB 59MB cloudron/org.freshrss.cloudronapp 2.184GB 2.176GB 8MB cloudron/postgresql 2.343GB 2.176GB 167MB cloudron/net.roundcube.cloudronapp 2.239GB 2.176GB 63MB infogulch/promnesia-app 2.224GB 2.176GB 48MB cloudron/graphite 2.246GB 2.176GB 70MB cloudron/turn 2.182GB 2.176GB 5MB cloudron/com.electerious.lychee.cloudronapp 2.248GB 2.176GB 72MB cloudron/mysql 2.495GB 2.176GB 318MB cloudron/redis 2.182GB 2.176GB 6MB cloudron/mongodb 2.299GB 2.176GB 122MB infogulch/terminusdb-app 3.331GB 2.176GB 1155MB cloudron/org.radicale.cloudronapp2 2.187GB 2.176GB 11MB cloudron/base 2.176GB 2.176GB 0B
You might notice that the "size" of every image is at least 2.1GB, but that 2.1 GB is shared between all the apps (namely, cloudron/base) because they all use the same base image. And I don't see any world where I wouldn't pay 2.1 GB to have every one of my images be useably-debuggable in case I needed it.
All this said, there may still be opportunities to reduce image sizes by using multi-stage builds to only copy release files (and not source code) to the final image -- but there's no reason for that final image to not be based on cloudron/base.
-
RE: Send from subaddresses
Oh cool thanks for pointing that out, I hadn't noticed before.
I guess the downsides don't really apply to me right now, but I'm not sure I'd want to enable arbitrary masquerading if there were a bunch of other people on this cloudron.
I still think it's reasonable for users to be able to send with a subaddress of any of their aliases, without opening the floodgates and allowing them to send from any address at all.
-
Home Assistant
Home Assistant / home-assistant.io
Awaken your home
Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.
Pretty awesome application and community. Today I was able to set it up on my Pi3, connected a zigbee usb controller, set up a few light bulbs, and already created scripted automations all within an hour or so. Strikingly straightforward to set up.
I think it would be great if we were able to manage an instance in Cloudron, maybe even on a Pi. I think this would be a great use case for the multi-cloudron feature coming in 7.0.
Home assistant has a Docker-based deployment option; though it also has a bunch of device / hw integrations (zigbee usb controller, for example) which could delay a fully-featured implementation.
-
RE: Outline - a Notion-like open source app
@klawitterb Nice thanks for sharing!
it also requires a S3 compatible storage like minio
Maybe this is a good time to bring up the Addon request: blob storage (s3) thread, which proposes a new "s3" addon in the same vein as the database addons that would create and manage s3-compatible buckets for apps automatically upon request in the app definition's manifest.
-
Addon request: blob storage (s3)
Some apps, especially recently, store and access data via an s3-compatible api. I think Cloudron should add s3 storage as a new addon that can be requested in CloudronManifest.json to better support packaging such apps.
Some potential apps that would use this addon:
Here are some numbered opinions so you can refer to (refute) them:
- I think it should be implemented as a Minio server which is set up like the postgresql or mysql addons in that the one instance is configured automatically and can serve a number of different apps. Say, each app that has the s3 addon gets a new random bucket and creds for that bucket.
- Ideally it can be configured in either local or gateway mode. Users can use local if there is enough storage on their server, or configure a gateway to point to any S3-compatible, Azure, or NAS service. Note that many service providers offer an S3-compatible storage API, so the list of supported providers is already much bigger than just those three, and includes hosts like Backblaze, Linode, DigitalOcean among many others.
- Figuring out how backups should work will probably be the biggest issue. Here are a few potential solutions:
a. Just clone / replicate the whole bucket on every backup. Might cost a lot of storage, but that's how backups work today so... See: Bucket Replication Guide
b. Something-something object versions? Though it might be difficult to, say, take a snapshot of a whole bucket. Bucket Versioning Guide
c. Minio contributors don't seem very receptive to the general idea of bucket-level shapshots. Taking Backups of MinIO #4398, Snapshots #9376
d. Just don't support backups at all? (not a fan of this option, but it's technically an option)
Thoughts?
-
RE: Scaling / High Availability Cloudron Setup
I'm not sure I'd want fancy, distributed filesystems on by default for most apps. I feel like most apps would need custom changes to explicitly support distributed storage, and I'm skeptical that a blanket drop-in distributed-fs solution could meet the performance and reliability needs of the diversity of cloudron users.
I'd rather have multi-node app management than distributed app runtime. Manage all your cloudron nodes and assign apps between them, migrate them etc, but most apps can still only be deployed to one cloudron instance at a time. At least I think this would be a better scaling/ha goal for a v1 implementation.
-
Record backup size estimate in backup metadata
I suspected some of my apps were consuming a lot of space recently, and I had to do a fair amount of digging before the details became evident. To me this was particularly concerning for backups because they don't do any deduplication and I could end up with many multiples of this increased disk consumption.
It would be nice to have the size of each backup recorded in the metadata for backups. Even if it's a little off compared to my backup host it would still be nice to have an order-of-magnitude estimate.
Latest posts made by infogulch
-
Meetsy - an online booking system
Alternative to Calendy
Finding meeting times are painful. Meetsy simplifies finding a time that works for you and your friend!
-
RE: My Kutt was hacked! How? Check yours!!
@timconsidine that's quite concerning! Default-on registration is mentioned in the Kutt docs, maybe it deserves to be highlighted more prominently in the install notes, or the default adjusted.
Registration
Registration is enabled by default. This can be disabled by settings DISALLOW_REGISTRATION=true in /app/data/env -
RE: Outline - a Notion-like open source app
Now that Cloudron adds authentication headers with the proxyAuth addon, maybe the easiest solution to integrate authentication is to use those headers in outline. I guess that might be as simple as adding a new file to the /server/routes/auth/providers dir. This would simplify the cloudron package because it wouldn't have to set up and run keycloak.
https://github.com/outline/outline/tree/main/server/routes/auth/providers
Then the only barrier to packaging for cloudron would be the hypothetical s3/minio addon mentioned above.
-
RE: What's coming in 7.2
This also includes the proxyAuth change that allows Firefly iii to authenticate again, correct?
-
RE: Actual - Self Hosted, Privacy Friendly Financial Planning System
Neat app. I wonder how it compares to firefly iii
-
RE: Forward emails to remote SMTP server
@mehdi iirc, one signal used to detect spam is whether the inbound and outbound IPs are the same. Maybe this is not the case, but Google and Microsoft are pretty finicky about email delivery so my instinct is to keep the externally visible configuration 'clean'. That's why I am looking at a design like this.
-
RE: Upstream dropped LDAP support with v5.7.0
@girish Wow that's great! Thanks for implementing this, I hope that it can be used for other apps in the future.
Did you happen to check whether the
x-forwarded-*
headers are stripped from the original request? Theres a potential impersonation vuln if we're not careful with these headers in particular. -
RE: proxyAuth addon
@mehdi I think we can add Firefly III to the list of apps that use this authentication strategy.
-
RE: Upstream dropped LDAP support with v5.7.0
Just to connect things, this is what I was aiming at in the proxyAuth addon thread.
Cloudron uses the ngx_http_auth_request_module to forward auth requests to the /http-auth route, then to 127.0.0.1:3001/auth . See: https://git.cloudron.io/cloudron/box/-/blob/master/src/nginxconfig.ejs#L292
I found this article that describes how to configure nginx and the auth server to provide the user back to the app by using the X-Forwarded-User header: https://redbyte.eu/en/blog/using-the-nginx-auth-request-module/
This is the same strategy used by Firefly III in #5847.
I think we could reenable authentication in firefly iii (and other apps that use this authentication stragegy) with the addition of a few headers returned by the service at :3001 and in the nginx config. I think defaulting to hard-coded X-Forwarded-User would be a good starting place.