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

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.

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.

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.).

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.

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.

Project page: https://github.com/tonarino/innernet

Announcement post: https://blog.tonari.no/introducing-innernet

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?

@moocloud_matt The number of servers that use a 1GB NIC and could saturate it because using a gateway doubles the bandwidth used to serve minio requests would probably fit on one hand if there are any at all. This concern is like a third or fourth level extrapolation, I don't think it's worth anyone's time to consider this eventuality right now.

@moocloud_matt I'm confused how "multiple Network Interface Card (NIC)" support is relevant here. Are you familiar with the minio gateways? They are orthogonal to networking configuration.

https://docs.min.io/docs/minio-gateway-for-s3.html

@girish Ok I asked and @tulir on #matrix:matrix.org said that we can just omit the "m.identity_server" server field entirely. Apparently it's used to map third party ids (email/phone) to matrix ids. But since we're using cloudron logins we can just omit it.

Also note that that field is not marked as required on the API docs page.

Hm, I'm not sure that the identity server is supposed to be pinned to vector.im... I'll see if someone on the matrix channel can chime in.

@nebulon said in Opt-in for Beta Updates:

manually checking for updates on your Cloudron will skip that rollout order and your Cloudron will see any pending update

Perhaps it would be a good idea to indicate on the update page that the user is currently on the latest stable release and that a particular manually checked update is a beta release and will opt them into the beta channel.

I would say what works brilliantly in Cloudron is the tight, seamless integration between the different components which enables admins to not have to think about huge problems like taking backups.

Good question, I'm not sure. I guess */server is for federation (server<->server), and */client is for clients (client->server).

Nice thanks for the Nextcloud example. I added it to the list in the OP.

Gateway mode would be wonderful but it also adds some complications, in particular if done incorrectly it could throw a spanner into the currently very clean backup/restore system which is actually my favorite Cloudron feature. With that in mind I would be happy to get a version-1 implementation that only supports the local filesystem configuration.

@nebulon Yes, the matrix server location is already filled in. I've been using Synapse+Riot client on my server for several months and it's been working great. Specifically, the */server endpoint is currently working correctly and serves data as expected from https://my-cloudron-domain/.well-known/matrix/server :

{"m.server":"matrix.my-cloudron-domain.com:443"}

Note the difference between the existing endpoint and the new one:

https://my-cloudron-domain/.well-known/matrix/server < existing, works great
https://my-cloudron-domain/.well-known/matrix/client < what this thread is about

I tried to log in via a new matrix client, Cinny, but login failed. Opening up the browser inspector I found that a GET request to https://my-cloudron-domain/.well-known/matrix/client was returning 404. /.well-known/matrix/client is a well known (pun intended) standard API endpoint used for server discovery. The matrix.org server serves at this endpoint:

{
    "m.homeserver": {
        "base_url": "https://matrix-client.matrix.org"
    },
    "m.identity_server": {
        "base_url": "https://vector.im"
    }
}

Cloudron already supports the /.well-known/matrix/server endpoint; I propose that support for the client endpoint is added as well.