Hi everyone,

in the past weeks I have been working with the Cloudron team to make Kopano Meet available as an app for Cloudron.

Meet is a modern video conferencing app that is designed as a so called Progressive Web App (PWA) which means that you can add it as an app to your phone/tablet/desktop directly from within Meet and without relying on external app stores. Functionality wise Meet provides 1 to 1 and group video calls as well as screensharing. We are utilising a library called "Glue" which facilitates easy integration into other applications, internal proof of concepts with this have already been done with Matrix and ownClouds new Phoenix UI (based on customer projects).

The app has been released to unstable last week and can be found at https://cloudron.io/store/com.kopano.meet.cloudronapp.html.

Looking forward to your feedback!

basic prototype now lives in https://git.cloudron.io/fbartels/bitwardenrs-app

cannot build it at the moment, though. since its stuck at

$ cloudron build                                                                                                                                                                                                                  
Building com.github.bitwardenrs@0.1.0

Build scheduled with id 9fcf31f1-04f9-445e-b687-79b2f7d54659
Waiting for build to begin, this may take a bit...

@girish is the backend maybe hanging?

edit: by now the build has finished

Hi @will,

SAML is basically "old tech". It's XML based and requires clients to generate keys through openssl which makes it in my experience both complex and difficult to set up for novice admins and also implement for developers. Apart from that SAML only works for browser based workflows.

Like I said before the one thing SAML has going for it is that its already well supported in enterprise applications. But I recently had a chat with someone involved in quite some university and government projects on the infrastructure side and he told me that he sees a trend to favour oidc over SAML recently.

An article with a comparison can be found at https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/

PS: with Kopano Meet there is actually already an OpenID Connect provider present on Cloudron as all authentication is done through OIDC in it. What we use there is Go and React, but I am confident that there is code to be reused for Node as well.

Maybe https://pleroma.social/ could be an alternative to Mastodon

From https://blog.soykaf.com/post/what-is-pleroma/:

Pleroma is a microblogging server software that can federate (= exchange messages with) other servers that support the same federation standards (OStatus and ActivityPub). What that means is that you can host a server for yourself or your friends and stay in control of your online identity, but still exchange messages with people on larger servers. Pleroma will federate with all servers that implement either OStatus or ActivityPub, like GNU Social, Friendica, Hubzilla and Mastodon.

How is it different from Mastodon?

If you are currently using Mastodon, you are probably interested in the differences between Mastodon and Pleroma. Here are some of the big ones.

Lower system requirements.
{...}
Less moving parts.
{...}
Internally ActivityPub.
{...}
Compatible with Mastodon clients (including the Mastodon frontend).

I've now spent a bit of time to get the admin page "properly" working. Registrations are now disabled in the app itself, but users that are in the cloudron admin group can login to /admin to create the required users.

Stuff like Websockets support (for folder notifications) is still missing, as well as automatic SMTP configuration but I would say the general app is "done".

Looking forward to feedback.

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

even with 1 GB of memory assigned, I get a "ran out of memory" quite often
currently the app is quite unresponsive as it's searching for favicons (as I can see from the logs)
Importing from Enpass 6 (json) worked fine for me

This probably depends quite a bit on the amount of data you throw at it. I actually started with an empty vault since password history etc would not have carried over anyways. But in my case it's easy to keep a portable version of keepass around if I need a password from the old database.

Maybe the icon caching is causing some troubles for you? You could deactivate this from the settings. Probably also a good idea to get in touch with the upstream project if they are already aware on this and if there is anything to lighten the load a bit

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

how are updates done? Or will your app eventually become an "official" cloudron app?

My idea is to have a good base so that @nebulon can make this an official app.

Hi everyone,

I was checking my cloudron backend yesterday since I wondered if I had already gotten the upgrade to the latest 4.2.x version and noticed that the automated updated failed since the server could not finish the backup run that is part of the upgrade. At that point the server had gone six days without a proper backup.

The issue was with the reverse proxy of my Minio installation (it seems that the 4.2.2 changed something in relation to max package size and that triggered a misconfiguration in my reverse proxy).

To make a long story short: I would have started looking earlier into it, if i'd had known that Cloudron had troubles backing up. For such a critical issue both a notification on the cloudron panel and an email would be nice. I do remember receiving mails in the past for certificates that could not be extended.

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?

Since all apps are running within containers there is a reverse proxy (Nginx) running that facilitates access to these apps. While it is currently not possible to configure this through the Cloudron UI (and manual modifications will likely be overwritten) I think it could be a good idea to have options to add ip access restrictions to apps and optionally also do sso on the webserver (nginx running on cloudron, not in the app) level.

Something like https://github.com/vouch/vouch-proxy/ could then do the oauth part towards the cloudron user management.

Hi @nebulon ,

I made a few tests today since I remembered that there is a dockerImage value in CloudronManifest.json, but I am not quite sure how to use it.

My current experiment is at https://github.com/fbartels/bitwarden_rs/tree/cloudron/cloudron. It uses a new Dockerfile that uses the multi stage Dockerfile as a base and uses a Cloudron Base Image for the last stage. But it seems he does not take my dockerImage. The only way he pulls in my image is by calling cloudron install --image fbartels/bitwarden-cloudron from the commandline.

For everyone else reading this. This is up until now only a build, the app is still missing all integration pieces and won't work withing Cloudron (yet).

the repository is marked as a "work in progress" and there has been no formal release as of yet. I think these two facts make it hard to really consider this for an app.

@yusf said in Nitter - A free and open source alternative Twitter front-end focused on privacy.:

I assumed it was completely statically served but maybe not?

It seems to bring some form of binary daemon. Given that this is named like the project makes it not seem like it can be served by any webserver.

Hi,

I was running short on disk space and noticed that there were quite a lot of kernel packages that I could remove from the cli by running apt autoremove.

Would be nice if this step could be added to the automatic package upgrades.

Hi,

I was noticing my server running short in disk space and during investigation I noticed that my collectd.log had grown to a size of 1.1gb.

It would be nice if the file can be added to the log rotation.

@necrevistonnezr said in Seafile selfhosted:

Was the dispute beetween the China based parent company and it's German subsidiary ever resolved?

The german company has stopped its business afair. But they have a new point of contact with https://www.datamate.org/seafile/server-plattformen/.

@necrevistonnezr said in Seafile selfhosted:

I wonder if (i) it was ever true, (ii) it's still true and (iii) supported by any reliable data / bench mark.

no numbers in it, but a general comparison can be found at https://blog.ssdnodes.com/blog/nextcloud-vs-seafile-dropbox-alternative/

I think the big challenge for solutions like Nextcloud is that all file processing is happening through php and when your php processor is busy receiving files then this will slow down ui interaction for users of the web client (even more so since EVERYTHING is php in Nextcloud). I do put some hopes into this new "infinite scale" backend that owncloud is working on, though.

Yes, I won't claim the web client is perfect, but basic also does not seem to be the right word for it.

@jdaviescoates said in What's coming in 4.5:

but nevertheless couldn't see any way of organising mail using virtual folders/ labels/ whatever you want to call them

You can do searches and "store" these to easily rerun them later. Its similar to how the the Outlook fat client is doing it.

@iamthefij said in What's coming in 4.5:

Mailpile has both those features

so does Kopano: https://kopano.com/

Hi @will,

SAML is basically "old tech". It's XML based and requires clients to generate keys through openssl which makes it in my experience both complex and difficult to set up for novice admins and also implement for developers. Apart from that SAML only works for browser based workflows.

Like I said before the one thing SAML has going for it is that its already well supported in enterprise applications. But I recently had a chat with someone involved in quite some university and government projects on the infrastructure side and he told me that he sees a trend to favour oidc over SAML recently.

An article with a comparison can be found at https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/

PS: with Kopano Meet there is actually already an OpenID Connect provider present on Cloudron as all authentication is done through OIDC in it. What we use there is Go and React, but I am confident that there is code to be reused for Node as well.

@jdaviescoates yes, the two of them are not really related. Matterbridge relays messages between different chat platforms and franz is an electron app to show multiple chat platforms.

@girish said in OAuth support:

Besides it looks like SAML is the future and does not require upstream changes for proper SSO. We will consider supporting SAML instead in a future release.

SAML (while having support in enterprise environments) is not the future, it's the past as well. The future would be openid connect.

@jdaviescoates How does Kiwi compare to the lounge? The latter is already available on Clourdon at https://cloudron.io/store/io.github.thelounge.html.