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

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 in env.sh

I recently encountered some issues after I switched from wildcard DNS configuration to provider-based automatic DNS configuration.

When you create an app with provider-DNS configured, cloudron will use your provider's API to automatically create the DNS subdomain record to point to your server so cloudron can serve the app. But if you create the app while you have wildcard DNS configured, no specific subdomain will be created. This is expected.

However, if you create the app under wildcard-DNS, then switch to provider-DNS, then the subdomains that would normally have been created when running under provider-DNS are not created automatically when switching between DNS configurations. This can cause a problem when the user deletes their wildcard DNS record because they assume that Cloudron will use provider-DNS to provision DNS entries for all apps.

I propose that Cloudron add a feature to check the DNS entries and reprovision DNS records as required when the user switches DNS configurations. I could imagine this could be implemented by triggering automatically as soon as the user switches DNS configurations, or as a button on the dashboard to recheck that dns entries for all apps are correctly assigned (including my.).

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.

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.

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.

Minio auth configuration seems to be rather awkward. It appears to have pretty decent support for LDAP authentication: https://github.com/minio/minio/blob/master/docs/sts/ldap.md

Do you think it would be a good idea to enable this?

@girish Wow that console UI looks great. Based on the publish date of that article and the current release tag on the console (0.7.0) it seems that it's a pretty new project. As far as being separate I can imagine wanting to have a very lightweight UI for the storage device itself and running the full-featured UI separately, especially if they're targeting k8s-like deployments.

https://github.com/valeriansaliou/sonic

🦔 Fast, lightweight & schema-less search backend. An alternative to Elasticsearch that runs on a few MBs of RAM.

Lightweight as in their single-thread benchmark which indexed 1M records and sustained 1k rps search traffic never went above 28MB ram (!). There are some limitations: it's schemaless and only supports integer keys, so it may need to be paired with some other data store to replace solr (depending on which features are used^), but if possible it would allow virtually all users to enable email FTS regardless of their server memory capacity. The sonic-channel nodejs library describes the api.

As a data point, sonic is used by ArchiveBox to provide FTS features to archived pages. ArchiveBox is on the App Wishlist.

^ I was gonna look into this myself, but I wasn't able to find the mail app on cloudron git, am I blind or is it not published?

@plusone-nick said in Proposal: Free-Tier Alterations :

It was more of a "its the free tier so its their problem to deal with" proceed at your own risk but fully rethinking it again that might be a good recipe for disaster, leaving people out to dry.

I'm glad you came around, this is definitely the better way to think about it. Sure, the license terms may say that you're on your own, no support etc; but users don't interact with license terms, they interact with your product. If someone has a bad time because of choices you enabled them to make with your product, somebody has to pay something ($, time, ...) to fix it, be it staff, the community, or even the product's reputation. I hope the team avoids going into future-support-debt in exchange for a short-term growth spurt.

@girish I think that would be a good change.

I also think I should have gone through the Troubleshooting document sooner :

https://docs.cloudron.io/troubleshooting/

Thanks!

And after starting the mail container, I was able to disable solr.

Everything seems to be back online again. Thanks for your help.

My guess is that some general slowness (perhaps due to memory overcommit and swap?) was preventing the mail app from responding to queries about its status, which I percieved as "the button didn't show up".

@girish df -h shows 23G Avail, so I suppose it's not a full disk.

systemctl status mysql showed

● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Sun 2021-05-09 20:01:10 UTC; 22h ago

systemctl start mysql brought the admin page back up.

mail container is stopped, after systemctl restart box the logs transitioned from

2021-05-10T18:04:40.001Z box:apphealthmonitor run: could not check app health. connect ECONNREFUSED 127.0.0.1:3306
Box GET /api/v1/cloudron/status 500 Internal Server Error connect ECONNREFUSED 127.0.0.1:3306 1.351 ms - 217
Box GET /api/v1/cloudron/status 500 Internal Server Error connect ECONNREFUSED 127.0.0.1:3306 1.692 ms - 217
Box GET /api/v1/cloudron/status 500 Internal Server Error connect ECONNREFUSED 127.0.0.1:3306 2.145 ms - 217
Box GET /api/v1/cloudron/status 500 Internal Server Error connect ECONNREFUSED 127.0.0.1:3306 2.381 ms - 217
2021-05-10T18:04:50.002Z box:apphealthmonitor run: could not check app health. connect ECONNREFUSED 127.0.0.1:3306
Box GET /api/v1/cloudron/status 500 Internal Server Error connect ECONNREFUSED 127.0.0.1:3306 1.853 ms - 217

... into this:

2021-05-10T18:04:51.732Z box:box Received SIGTERM. Shutting down.
2021-05-10T18:04:51.733Z box:tasks stopTask: stopping all tasks
2021-05-10T18:04:51.734Z box:shell stopTask spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2021-05-10T18:04:56.425Z box:server ==========================================
2021-05-10T18:04:57.946Z box:server ==========================================
2021-05-10T18:04:59.324Z box:server ==========================================
2021-05-10T18:05:00.540Z box:server ==========================================
2021-05-10T18:05:02.024Z box:server ==========================================

Which if I tail the log it is still printing every second or so.

However the my. admin page is still returning a 503.

@girish I'm saying the button was missing entirely. There was no button.

the button to open the config dialog was just missing.

Edit: to be clear, the screenshot above came directly from the cloudron.io docs pages, sorry if that was confusing.

And I can't get to the admin page right now because it's been down since this occurred.

@nebulon There was no checkbox. The email config page said that solr was enabled, but the button to open the config dialog was just missing.

This button was just absent:

@BrutalBirdie I'm referring to the Full Text Search feature in Email settings which is powered by Solr.

I enabled Solr to try it out, but using 3GB is a bit much on my 4GB server and a bunch of my apps started crashing with OOM errors, so I need to disable it. I didn't see the option to disable it in mail settings, so I lowered the mail memory down to 512MB, which (perhaps predictably) caused even more problems and now the box app is not responding at all.

I'm able to ssh into the server, but neither the cloudron web app nor cli works and instead gives "Login failed: Status code: 500 message: connect ECONNREFUSED 127.0.0.1:3306".

Any ideas to un-f*** myself?

@girish I'm not sure. It is intended to support image and other media uploads, so perhaps they're looking at long term consumption with such media. There is an open issue about it, and user diamkil seems to be pursuing the bundled-minio image strategy. The reddit thread mentions local storage throughout.

The current storage provider implementation seems to serve files by providing the client an s3-style signed url. Perhaps a new provider could be written that provides a file url that just points to the server itself, I guess requests would be authenticated by the usual domain cookies.

That's a neat thing about catching a project in the early stages: easy feature requests are likely to be accepted. I updated to the latest version and adjusted how the image is built. The updated docker image is now at infogulch/notea-app:0.0.1-9.

This works with proxyauth, but I'm not sure if my minio config is working correctly. I wonder if it would be a good idea to just package up minio with this app in the same image...

@girish Wow that console UI looks great. Based on the publish date of that article and the current release tag on the console (0.7.0) it seems that it's a pretty new project. As far as being separate I can imagine wanting to have a very lightweight UI for the storage device itself and running the full-featured UI separately, especially if they're targeting k8s-like deployments.