Best posts made by jimcavoli

Z-Push EAS interface for IMAP/CardDav/CalDAV/LDAP/Kopano/MailDir/SQL/more
https://z-push.org

This is something I've been batting around implementation ideas on for a little while now. There's a ton of variability provider-to-provider to account for on automating some of it, so I was leaning toward more capable cluster managers that are already available off the shelf. Easily the most capable is Kubernetes, but it comes with a lot of added complexity. It's distinctly possible based on the way Cloudron works to entertain some of this stuff, and I've been sketching out a number of different ideas. Nothing is formally roadmapped afaik right now.

That said, it would be helpful in thinking about options what you see as the changes in your experience that these sorts of ideas would enable. Adding an additional node, which seems to be what 3 of your 5 ideas are focused on (load balancing, hot stand-by, and auto-scaling), may or may not be the best approach to minimize downtime depending on how the "normal" use would pan out. It's already not all that difficult to keep an alternate machine restored from backups as a standby, but given the way the system handles app-level failures, it's hard to say in what cases that would be useful; there's added difficulty in reversing that failover and keeping it real-time.

Ultimately, what probably does make the most sense to close the gap on those goals while not messing too much with the underlying architecture and existing packaging is some sort of coordinated cluster manager that keeps the single-container approach but allows the system to reallocate those app containers across k different servers. Something short of Kubernetes could achieve this pretty easily, but will need a lot of work to pull off. For these reasons, I've started looking more at Hashicorp's Nomad as a potential solution to the cluster management side of things, but I'm still in the very early stages of what a Cloudron implementation would look like. At its full potential, this could enable things like multi-region and even multi-provider deployments. Ideally, the details of managing this would be hidden away behind the Cloudron interface, but I've not even yet begun to start spiking out an actual implementation.

I'd love some more thoughts and feedback on the approach generally though!

I'm reworking this now that 6 is out and proxyAuth is an option. Currently got the latest version building and running on the latest node. Waiting for some details on how to do proxyAuth configuration to not break webhooks (rather important for this one!) and then I'll need to get to fixing up the websockets, but overall is looking okay. Switching from file-based to env-based configuration only because it seems better supported by the docs as well.

LDAP groups would be huge. Been dying for that a couple years now

I had a breakthrough with the dumb websockets issue. Hooray! This one should be ready shortly. I know it's been highly requested and hotly anticipated (for me as well) so it's my top packaging to finish. At this point, after a few other tweaks, I'm fairly sure I've got this working. I'll do some final testing tonight, but I expect that I should have an initial build together by this weekend.

I've extracted the following from one of my projects: https://gist.github.com/jimcavoli/b390565eb98f62faae821c83c8e87100

It has some added substitution for using secrets for all configurable values (I hard-coded a couple of them in the actual project), but is otherwise exactly what I use. It has a built-in cache registry that tries to minimize the build time, some simplistic retry logic, and as written is triggered when a new release is published on the repo. I've had a pretty good experience using it, so figured it might be handy for others, in case you've got some fully-custom app you're deploying from a private registry. The only built-in assumption is that you use the Dockerfile.cloudron naming scheme, but you could edit that as well if you like.

Not only is this an awesome find and great-looking app (wish I knew of this in May), but something I have a distinct use for. As such, I've begun an initial packaging effort.

I would like to be able to configure the autoexpunge option for certain special folders globally for all mailboxes, to allow the mail server to clean up after users who don't purge their Junk or Trash folders periodically. Ideally, this could be optionally configurable for any of the predefined folders so that a clear retention policy, to whatever degree the administrator desires, can be applied to all mailboxes.

Likewise - this seems tantalizingly close to ready - and it's high up my list of things I'd like to get to deploying. What's the remaining to-do list or best way(s) to contribute at this point?

Given the split of box vs app concerns, and the new addition of being able to separate the mail server from the my subdomain, it would be a great added feature to have the option to check a box for setting up proxied records when using the Cloudflare DNS provider.

Previous discussion: https://forum.cloudron.io/topic/2806/is-the-cloudflare-auto-dns-setup-secure-using-dns-only-as-opposed-to-proxied/

So I have an initial packaging for this done at https://git.cloudron.io/jimcavoli/n8n-app

HOWEVER, I'm honestly not sure I'd be comfortable putting this software into production as-is. It's pretty weak on some security features, but maybe its not the end of the world for people and I'm just super paranoid. There seems to be an undocumented way to do JWT auth, which I'm not going to even try to get into that, since I'm only aware of it from looking at the config file handling typescript code. The only supported authentication right now is basic auth as documented - with a single username/password set by ENV or config file (I went with the latter since it's easier for end-users to edit in /app/data/.n8n/config by terminal).

Either way, everything basically works, and by launching via supervisord with the working directory set to /app/data/output we're able to contain its binary file writing to system (probably a bad thing to do in prod as well, but it works).

Custom nodes can be added to /app/data/custom, the config file is JSON at /app/data/.n8n/config, and the package writes cloudron-provided postgresql configuration to that file at launch.

Some stuff only works in Chrome. That's just an issue with the app. Something about they way they're handling web sockets means other browsers see "Connection lost" in the top right, which is where the Activation toggle should be. Most other things actually work fine, but that's necessary for executing workflows in-browser manually and activating them.

I packaged this one because it seems to have some popularity in asks, but it definitely deserves some due diligence before heading to production for anyone or the app store. It's also pre-1.0 so not sure how much is changing how fast, and the setup as is was a pretty delicate thing to get done. Maybe my concerns are overplayed, maybe not, but either way, there's something we can start to kick the tires on for this app now.

@marcusquinn That statement could be applied to at least 75% of things about Nextcloud.

I recently stumbled across the MIT-licensed SPFToolbox project and it got me thinking a lot more about more comprehensive mail server features and management tools that would be good to have in Cloudron. SPFToolbox has some nice functionality for running checks for all sorts of things, but its blacklist checker is what started to get my mind running about that feature and potentially others that would be awesome additions to the Cloudron email system to help administrators manage deliverability and so on.

This probably starts to creep into a bigger re-vamp of the email management area of the product, but IMO since mail servers objectively suck to maintain, the ease of use of the Cloudron mail system is a huge selling point. While it's probably not realistic to target everything that services like MXToolbox do, but there could be some more built-in and automated to make life even easier.

Some thoughts out of the gates:

• Blacklist monitoring
• Rspamd - Haraka is ready (https://github.com/haraka/haraka-plugin-rspamd) - with some of its handy modules:
  • Possibly include web ui to shortcut the configuration management; definitely an "advanced" option though
  • Antivirus - https://rspamd.com/doc/modules/antivirus.html
  • Phishing - https://rspamd.com/doc/modules/phishing.html
  • Greylisting - https://rspamd.com/doc/modules/greylisting.html
  • Metric Exporter - https://rspamd.com/doc/modules/metric_exporter.html
    • would let rspamd feed metrics into graphite for graphing in the box ui
  • I'd favor probably pushing some of what are currently haraka plugins' responsibilities around the SPF/DKIM/DMARC space down to rspamd as well given its much higher configurability/visibility if well-implemented
• Perhaps getting into automatic cryptographic signing/encryption with something like CipherMail in the mix - definitely needs some more thought
  • This might be best done by rethinking the way haraka fits in the MTA chain - maybe making other MTA-interfaced apps available via the app store like this one would be a good thing, then in the mail server admin, you could choose which one(s) of those installed are inserted for each domain?

I'm just sort of thinking out loud here, and would like to see what others think about those ideas or any other ideas about the mail server here.

Initial packaging: https://git.cloudron.io/jimcavoli/snipeit-app

Love the conversation this has kicked off, and I think there's a few good things to consider here:

• The main thing I was originally aiming at first was better visibility into the mail subsystem and second to that more control over those various components
• Expanding the capability of the mail system to include additional processing by farming out additional processing to external servers like CipherMail, Proxmox, etc. could be done easily for even sparsely-resourced servers. However, optionally enabling certain processing like Antivirus on the same machine is still likely a good idea.

A lot of us are also running fairly beefy servers for large production setups and it seems disingenuous to rule out completely more resource-intensive operations from the core packaging just because some machines at the lower end couldn't support them. Making them optionally available, even subject to certain resource constraints and so on, is exactly what I'm hoping we can get to - a lot more control over the mail system so that administrators can choose how much in terms of resources to invest in that system. A combination of more inspectable, optional services available on the core offering as well as allowing external smtp-based components to slot into the workflow sounds like the best of all worlds.

Still pending; I missed an extension in the earlier ask, but that's been merged, so hopefully this will release shortly after the next Cloudron patch version. It's at the top of my list, so as soon as I can get it working, I'll update here.

Recently, I accidentally found myself studying this problem. I've relocated backups to GCS recently from DigitalOcean Spaces for one machine...suffice it to say I found the bottleneck in that process. Previously, it appeared to be some traffic management into spaces, and/or the fact that it was heading to the SFO2 region from NYC3 (you know...because...geography). After turning on backups into GCS in the awesome us multi-region automatic replication (nearline), it became very obvious that the main limiting factor was a 10MB/s cap on the disk speed at DO.

Seriously; here's their graph over the last 7 days for Disk I/O performance (it's pretty obvious where the backups are):

The main reason this even showed up is that GCS ingest is way faster from a bandwidth perspective:

Too bad I don't have the old Spaces graph to show as well, but suffice it to say, it wasn't great. So the GCS switchover actually moved the first bottleneck, getting at the main root of the issue.

I'll update on how things go one the server in question gets itself moved into a GCP instance - by my rough math, there should be a noticeable performance bump in at least backups, but likely systemwide once it transitions into the GCP volumes, which are rated at least 50% faster in the case of the small volumes, and in the big one (apps data), should have a network performance ceiling that is roughly 6x higher than the existing DO volumes. I know this is more on the production/operator side than the personal side of usage, and the problem of "throw more, bigger resources at it" is not one most folks can/would take on a NAS/local server and home internet connection, but it's some interesting data and an intriguing problem in any case.

Yeah, I think I'll pick this one back up once I'm done faffing about with OpenSlides. Especially with the NextCloud integration, but mostly just because I sort of hate osTicket's prevalence with a fiery passion. I find it to be way under-capable and over-used as a general rule, and I don't love that the interface is basically as it was circa like 2008 either. Zammad for the win, hopefully soon!

It would be a good addition to the ingress handling on box to be able to optionally configure mutual TLS authentication for connections to the server. This would allow those of us who do use Cloudflare to enable Authenticated Origin Pulls, and would further allow others who perhaps would like to have a remotely located server only accessible to certain network(s) via a proxy/gateway to do so without the overhead and technically not recommended approach of a VPN connection to the box itself. Similarly, this relieves the need to depend on expensive private ingress solutions (generally also VPN-based) into otherwise inaccessible VPCs of most cloud providers.

This would necessarily have to only apply to the HTTP/S side of inbound traffic, I expect, which would be reasonable, since it is a rather specific protocol layering and I don't believe such a mechanism is necessary or supported for some of the other services that can be operated on a Cloudron installation. This may or may not also need to exclude the actual my.example.com management interface, also a fair compromise to my mind.

Started to try to package this, but stopped almost immediately since it's going to be a lot of effort/figuring out due to the many backing services, several of which are not readily available as adding in Cloudron today. List is in https://github.com/mistio/mist-ce/blob/v4.3.8/docker-compose.yml but includes things like elasticsearch, memcached, and rabbitmq. Obviously some could be put in-container with the app, but a couple are a bit too heavy-duty imo to do that to. Sticking a pin in it for the time being.

@jdaviescoates Yep; done with OpenSlides on my end. Just waiting for it to get moved into the app store. I've got Loomio and Zammad up next.

It does appear that nearly all features are working in my test build. There is one last challenge remaining here - a potentially notable one. Inbound email for loomio is, in its usual deployment form, handled by a custom sub domain with an MX pointing to a nodejs mailin server to convert messages to webhooks. My plan for the cloudron packaging is to use the recvmail with a custom poller process that will grab emails and POST them as required to the app.

However, this will require a patch to the underlying software as well. The patch to make loomio use the configured CLOUDRON_MAIL_TO while leveraging the +-delimited subaddresses feature would be similar to https://github.com/loomio/loomio/compare/master...piratas-ar:pipe_to_api but with app/helpers/email_helper.rb using the ENV var rather than the hard-coded "loomio" shown in the linked patch. It's a pretty minimal change to get the packaging working so that all the various loomio services operate out of the singular cloudron container, so I'm comfortable pressing ahead with that approach, but if anyone can think of a better solution, please let me know!

Okay, so this is back in my crosshairs to one extent or another, and that's good since I don't know of anyone else packaging on a regular basis who spends all day in Ruby like I tend to

The main thing to point out here is that while I definitely can package this, Decidim itself is not an app, but a constellation of Rails engines (it's a Ruby on Rails framework thing - https://guides.rubyonrails.org/engines.html if you want to read), so it has to be packaged up inside of a host Rails app to actually be of any use. I think such a thing could be written and done to a fairly positive result, with reasonably easy maintenance, but that would be my main concern.

I expect this will likely not be something I'm ready to pick up for a while, so curious to gauge interest in this app specifically, as well as any other feedback about dealbreakers and/or maintenance concerns.

@doodlemania2 Sure thing! Also, didn't know it was inotify under the hood - that has a fraught history with dockerized runtimes, so this is likely your best option anyway

@girish I’m still around - I can pick this back up in the next week or two

Group-/sub- admin accounts remain high on my list and I certainly look forward to seeing that in 4.5. Overall, this is a really good list of features that is clearly being developed and prioritized with a lot of weight to community feedback, which I think deserves some major applause!

Just to follow up, here's a sample of normal backups followed by a Cloudron upgrade, which itself triggered another backup run, and the corresponding relevant network and disk graphs:

All in all, it's definitely fast-er but not insanely performant. CPU utilization vs load hints that it may in fact be down to inefficient utilization of cores to some extent, but there is definitely a fair bit more bottleneck coming from the network still.

Nothing earth-shattering either way, and gains were more mild than I would have guessed, but all in all, not a bad outcome.

An initial skeletal packaging of Grafana is up at https://git.cloudron.io/jimcavoli/grafana-app and everything works as expected. There's an outstanding issue around outgoing mail for notifications...details are on the chat server...but essentially, it's waiting on a fix to STARTTLS handling in the mail add-on. After that's fixed, this should be pretty much ready to move forward.

So far:

• Cloudron LDAP for SSO works and Cloudron admins are automatically mapped as Grafana admins
• App settings are stored in a postgres database
• Provision for user-specified configuration by environment variables set in /app/data/env
• Ability to add plugins to /app/data/plugins
  • A thin wrapper for grafana-cli is also provided and set first in PATH - this also allows simply opening the terminal and pasting the grafana-cli commands from the plugins directory to work as expected
• Installs and uses the new grafana-image-renderer plugin automatically (no "using phantomJS" deprecation warnings)

@benoit A far better job than if I tried to write anything in French! I have a particular interest in this sort of MSP model to help improve the access to the platform - many small businesses or groups could see big benefits from Cloudron but cannot afford the dedicated IT pros to operate/support it, so I think such options are a great part of the ecosystem. I have an interest in doing something similar for local clients as well in the future, or at least to standardize my deployment of some custom applications.

I finally got mine...weird though; I had to go into settings to turn it on. Forget where exactly, since I did that a couple days ago, but super appreciate the idea, love the thread, and happily continuing to package several more things (OpenSlides is complete, and I've resumed work on Zammad). Just for the sake of interesting trivia, I've also done a fully custom build that actually builds & deploys itself when a GH release is tagged on its repo, as well as a spike on a fully custom multi-protocol SSO tool (read IdP) intended for Cloudron-only deployment...more on that someday in the future if it lives on.

I totally understand the caveats, and this discussion is just what I was hoping to get to with the ask. I think that it being the user's responsibility to configure group mappings if they want to use that feature is a very reasonable approach that strikes the right balance of maintainability and functionality. It's worth noting to people that it's an advanced thing you should only be working on if you know what you're doing and that it's not something that Cloudron can or should support beyond basic information about how the LDAP server side works.

A lot of this varies app-to-app, and frankly, I think it's appropriate to leave the nuances of the choices a user might make about how those apps behave to said user. Some apps are super powerful here, like Metabase, which can basically automate all of the role/group assignments for you if configured right, ranging all the way back to EspoCRM, which is basically non-existent in its support for group mappings besides basic login filters, which is already better handled by Cloudron anyway, and plenty of others like osTicket that are somewhere in between.

I think good points have been raised about the security concerns and sync issues, and it's worth making it clear where the line is on what's provided vs. what's possible. Furthermore, as packages update into the future and more support for group mappings is added, it would be unreasonable imo to expect Cloudron packages to anticipate everyone's preferences/needs. Patterns of use will vary hugely based on how the systems are deployed and by whom. The points above all sounds like you've gotten a pretty clear idea over the years of this one coming up about how to equalize the flexibility and clarify the boundaries for expectations with such a feature, all of which sound exceedingly reasonable, whether groups are implicitly all LDAP or explicitly configured in or not (minor detail to my mind).

I believe this should run on cloudron 6 without issue, but I'm waiting for that update to hit the machine I use to make sure and then we should be able to get this out. The new 2.5 update has some excellent features as well! (which I see no issues with running in this package as soon as it's ready to go)

Just pushed updates to https://git.cloudron.io/jimcavoli/glpi-app that include a fix in the manifest as well as the version to the newly released GLPI 9.5.3

You could also use the source for Firefox Relay itself: https://github.com/mozilla/fx-private-relay

Would work best if we package up FF accounts though...that ask has been sitting for a hot minute. I wonder at this point if it's better to pack a whole bunch of these FF services into one mega-container or doing them each individually. Probably the latter, though configuring them together feels like it shouldn't require manual input either, but at this point that seems unavoidable. Maybe I'll get to it sometime soon, but my list is getting pretty long.

Got 7.0.1 loaded up on my testbed machine...going to re-update the packaging as needed and ensure recvmail is integrated properly, then we should be good to go here. Hoping for O(days) on that, may be O(weeks) given schedules the next few weeks.

@privsec In theory, it should - lots of other moving parts there, but definitely give it a try post-update and report back your findings!

@robi Yeah, if it's automatic or nearly automatic "here's some interesting things" you want, it's worth getting the data model set up with some added detail in the Metabase Admin, which is easy enough (it does a pretty good job of inferring common conventions), and then browsing through the data and doing different visualizations is dead easy, plus it'll try to do some automatic "X-Rays" as it calls the auto-generated dashboards. Here's an example of a table that I haven't customized the data model on at all, but it did a good job with, as an example:

Edit: Ugh, no GIFs allowed. Here's a sequence of static shots:

I'd suggest playing with both - there's necessarily going to be a fair bit of preference at play here.

Just wanted to mention how much I love the fact that even before being 100% ready to process contributed translations that we've got commitments on at least 5 languages! That's awesome. It would be good perhaps for those of us that use the product and can contribute any translation to set some goals for completing those that we can get started. So by my count so far, we've got people ready to work on:

• de
• fr
• it
• nl (not in weblate yet)
• es (not in weblate yet)
• he (not in weblate yet, RTL)

Big ones there are definitely going to be easy to complete look like de, es, and fr, which, considering en is already in the mix, probably covers at least one language of most of our user base. I wonder if we could dig up some folks to tackle any of hi, zh, ja, and ar since those would all be potentially valuable places to have native-language support, with large populations and well-developed internet access. I am uniquely un-qualified to work any of those, however.

Couple useful resources/citations on expansion:

• https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers
• https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers (somewhat better than above; includes portions of that data as well)
• https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

There is an open ask on the App wishlist for Decidim specifically, if you want to also upvote that and/or have a stab at packaging

I had updated a DMARC record for a Cloudron domain to include reporting emails and more detailed policy, but after about a day, this had been changed back, presumably by the Cloudron, to the simplified version that it had by default. Is there any way to maintain more advanced DMARC while running the Cloudron mail server?

With all the activity on this thread, is it likely that Bitwarden will see release in the App Store any time soon? Even as an "unstable" package for easier trial by others?

Related: while re-working the n8n packaging, I happened upon what would probably be reasonably common, where there are selected sub-paths of / which should not be authenticated - example being we want / to require auth, but not /webhook/* paths. It's at least non-obvious if not unsupported by the current docs on how to do this with proxyAuth

@mervinrasquinha FYI, I use it on multiple instances, including at DigitalOcean - they won't block port 25 but they will require your droplet to be named "my.example.com" to get a PTR record, and this will only map back to the droplet-assigned IP address, not a floating IP. That is not a big deal if you're already using that IP in DNS and don't have a problem with it. For anyone interested in more purposefully obscuring the backend side even through DNS (say with Cloudflare in my case), this eventually proves way too irritating to keep said node at DigitalOcean. Interestingly, the machine I'm talking about has actually had a SendGrid relay up for over a year anyway just to help with deliverability (mail servers are hard at anything approaching scale), but even then, the whole PTR IP thing has been a thorn in my side. That's nothing to do with Cloudron - it's actually pretty flexible in how it handles these situations - my ire about that is squarely aimed at DigitalOcean being so inflexible as to just be getting in the way of a pretty strong deliverability requirement. That issue has been a complaint from many customers over the years, but they haven't (and I expect won't) relitigated it to any different result. Curious how you've found it after a bit now - the big machine that I've referred to is getting moved to another cloud provider, but I still have a smaller personal one over at DigitalOcean, and I'm questioning whether that's worth keeping either at this point.

@girish Looks like accounts is now able to be run self-hosted as well now: https://mozilla-services.readthedocs.io/en/latest/howtos/run-fxa.html

The Cloudron LDAP server already presents a memberOf overlay in its user records, including cn=users,ou=groups,dc=cloudron and maybe cn=admins,ou=groups,dc=cloudron depending on the user's role on the Cloudron side.

The memberOf property would return CNs for all groups, both Cloudron-internal and user-added of which the record is a member. Ideally, the groups tree should be searchable as well and would return all the user-added groups..

This feature would allow for automatic mapping of users to groups/roles/permissions in a growing number of Cloudron applications, as well as simplifying the ongoing management thereof for administrators.

The main issue with Nextcloud Talk that I see is that it's part of the Nextcloud-as-a-monolith model that they push, for understandable reasons. However, a lot of organizations have serious needs around chat with deeper integrations. For example, Rocket.Chat can enable one-click video conferencing, on top of all the other myriad of features, right there where users already are communicating with each other and with services, bots, and notifications by using either BBB or Jitsi, which is great, and means we don't need to have users switch tools just for video calling. Talk lacks this kind of integration in general, which just makes it tough, and it's (imo) not quite mature and suited as the alternatives described.

Similarly, between BBB and Jitsi, there are lots of options to do more advanced things than just integrate them with another chat client, like embedding those conferences into web pages via Jitsi's API for that or BBB's Wordpress plugin / API or into an LMS like Moodle (also on the wishlist) via plugins (for BBB or Jitsi). Jitsi also has the ability to live stream in addition to record meetings (BBB can also do recording). Basically, if I'm going to spend valuable server resources (and transitively money) to run a video conferencing solution, I want more mileage/"bang for my buck" than Nextcloud meet offers.

I think Talk is a great starting point for anyone with casual interest, limited needs, or just exploring video conferencing as a tool, but once we get to the proverbial big leagues with heavier-duty use cases, it's hugely beneficial to have one of these more fully featured tools. That's also striking at one of the huge advantages of the Cloudron platform - everyone can deploy the right-sized solution for their needs with ease and spend the energy on evaluating and transitioning tools as it's necessary, rather than getting mired in the administrative overhead of operating an existing one.

As a parting thought, I'll add that today I find myself leaning more toward Jitsi than BBB after (finally) a positive experience with an event leveraging the public meet.jit.si and thinking about the live streaming capabilities...frankly, as I've sworn up and down repeatedly in this thread, either would be great. If the hardware demands are too extreme on BBB, then let's go Jitsi. The control and privacy are really the banner features, imo, and both do an excellent job on those core requirements.

Take a look at the existing thread on adding resource support in SOGo - it's like 80-90% of what you're describing: https://forum.cloudron.io/topic/3626/shared-resources

An initial skeletal packaging of metabase is up at https://git.cloudron.io/jimcavoli/metabase-app and everything works as expected. It runs via Java, so it's a bit of a memory hog...unfortunately I couldn't find a good solution other than to set the minimum at about 1G which seems to leave enough to get it running reliably...could be lower perhaps, but I'd question its usability at such a scale.

Otherwise:

• Cloudron LDAP for SSO works - automatically mapping administrators doesn't, but that's not really the end of the world since you have to create an admin via the setup wizard on first run anyway
• Cloudron mail for email notifications works, both on-demand and scheduled
• App settings are stored in a postgres database
• Encryption key is generated at install to enable credential encryption at rest by default
• Update checking disabled by default
• Provision for user-specified configuration by environment variables set in /app/data/env
• Ability to add Oracle / Vertica / other plugins to /app/data/plugins

Just pointing out that this might be better served by using something like a proper gateway and load balancing solution in front of the apps like Kong rather than NGINx on the box. An add-on for a basic auth screen could just be a config tweak to the box ingress which hits an auth wall - added advantage would be much more flexible routing to apps (sub-path, etc.) and flexible options like having multiple DNS names resolving to the straight A record for things like apps that can serve multiple domain names off one instance.

@robi From what I can tell, Portainer seems like a management interface for many orchestrators, which seems a level removed from the actual cluster scheduler itself, and therefore a bit higher-level than the next step we'd need in the cloudron journey to clustered operation. Frankly, even though I've advocated (and will likely continue to ) for a largely HashiCorp-based approach, the first/easiest thing might be to experiment with Docker Swarm. I'm not a particular fan of Swarm, but to be fair it's been a while since I seriously evaluated it. Still a big fan of Nomad specifically for this particular use case, and I think it is the best fit for the problem. I do have a bit of work done on the "HashiStack" approach already, but it's going to be a pretty seismic change if I get it finished, and I've not yet explored all the tendrils from the management/box side that will need to be updated. I can try to get some more serious progress laid down on that around the Christmas holidays, I hope.

@yusf Will do!

@atrilahiji said in What's coming in 6.0 (take 2):

2. no way to integrate with cloudron mail like the Rainloop app in Nextcloud.

On that specific point, Nextcloud Mail does fine in my experience if the users have their cloudron email as their primary email, then you can do similar to the following (my.demo.com used in place of mail server name):

So it can depend a lot on your setup, but I'll freely give you that no sieve support is incredibly frustrating, plus I constantly can't find features that I feel like should be there, and even when it's "working" the visual design is so weird to me that things still feel wrong. I mean, I'd give it like a 4/10 and "would not recommend to a friend" but for some users/clients...it's evidently good enough?

The rolling average in my experience is definitely hot garbage, but sometimes it's acceptable garbage.

@dfldadm I've built a couple custom apps that target Cloudron as a deployment platform, and published a sample of how to build/deploy to a Cloudron from GitHub Actions. Several of us would be happy to help you get that figured out if you run into any issues. In my experience, it's been roughly as easy as Heroku to operate once you get that initial setup done.

@girish Works really well; repo forthcoming. I'm still working locally. The main trick just seems to be setting a reasonable floor for the memory limit; I think it's going to be 768M or so as a minimum to ensure the workers all stay up and responsive for a reasonable handful of connections. It makes heavy use of web sockets so it's a hair resource intensive, but given the nature of it, it shouldn't be a big deal for folks to deploy, test, scale up temporarily for an event, and scale back or remove after it's done. The app is rather specifically designed that each installation is one event, something they may change in the future, but for now, really makes running it on Cloudron so much more sensible than any other methodology. (their documentation on how to run it is garbage, basically though; really pushing the hosted version with the dearth of docs)

I'll just finish a little more testing, especially around file uploads and media handling, tonight, and that repo will be linked here following.

k8s is not a great fit imo for cloudron without introducing much bigger changes...there are roads to that runtime with some intermediary schedulers as well though, which is why I like Nomad in this space the most. I've actually been working up a prototype using the HashiStack Consul/Nomad (plus or minus vault) to provide a distributed runtime, but that's a reasonably long way off seeing any sort of integration into the core of things. It's a big shift on its own, and needs a lot of refinement. Obviously so would a k8s approach. In the immediate term, managing across multiple full-on cloudron instances is fairly clean, and if implemented correctly, could actually still be useful in that world as well. It's the first, easiest, smallest thing to do and therefore in my opinion is valuable, regardless of where the higher-powered distributed runtime ideas go.

Repo with initial packaging: https://git.cloudron.io/jimcavoli/openslides-app

I'd regard this as pretty ready to go at this point - all packaging choices were in line with the production configurations recommended by the project. I've tested pretty much everything except SAML manually. User management is independent for the time being as described previously. Also notable is that after some testing, I found 524288000 left enough headroom as a memoryLimit floor that the app was usable without constant restarts for light duty (not going to service a 1000 person assembly, probably, but fine for prepping an event and then deciding how to scale up from there). Other notes are in the README of the packaging repo. Also recommend building with buildkit turned on if you don't normally - the JS compilation takes a short eternity, but the Dockerfile takes pretty good advantage of buildkit multistage builds for parallelizing as well as limiting bloat in the final container.

@girish yeah, after kicking the tires on it, it's definitely aimed at bigger use cases than Snipe...and with more plugin development could be a much more robust option. The existing plugins for integration with tools like FusionInventory and OCS are compelling concepts at least, much like the JAMF integration, but this all gets a bit stymied by my lack of working plugins so far. It also does have a pretty robust in-built change control and service desk/ticketing, which is the biggest departure. Snipe is a more limited ITIL tool and designed to meet that need; GLPI is aimed at almost exhaustively comprehensive ITIL/ITSM in one system. I think there's plenty of room in the world (and likely on the platform) for both, but GLPI is sort of kneecapped without plugin support getting fixed from being clearly better for those large use cases.

@esawtooth This has been an issue for other apps as well, so there's a gitignore-style include-exclude sort of rule logic for proxyAuth coming soon if not done already. cc @girish for the latest status on that

Probably can remove this one from the list - it's been carrying a "no maintenance" notice on it and has been abandoned code-wise since 19 December 2018, and that death-notice banner went into the readme 05 May 2020.

Or as a GIF:

On the plus side, decidim is still alive and well.

@girish Thanks for fixing that up - packaging to date is at https://git.cloudron.io/jimcavoli/loomio-app