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!

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?

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.

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

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.

Ah, I was wondering about that as well. I saw the notification, but dismissed it there (not the right time). When later wanting to reboot from the Cloudron UI I could no longer find the button.

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

@scooke said in Jitsi Meet:

but as I've been reading about it it seems like a user needs to activate some other Turn service to allow guests from outside the network... still checking.

The admin always needs to configure a turn service, that is true for all webrtc based solutions (Jitsi, Nextcloud talk, ..). But once guest access is configured in Meet users do not need to install additional apps or extensions.

@scooke said in Jitsi Meet:

I think what with the lockdown and all, having a solution like Kopano and just a link for others to join, would be wonderful.

Yes, I know. We have been flooded with requests over the past week, even doing some priorities development on a sfu (like the videobridge of jitsi) for some schools.

@avatar1024 said in Jitsi Meet:

What are the differences between Kopano and Jitsi...it seems to me the tech is similar, but one you need to install an account to use which is not as good (Kopano)

Yes, the general purpose is similar and in the end both require the additional setup of a turn service (Kopano customers can request access to a hosted turn service, which is included in the subscription). Kopano Meet has a newer more modern architecture (its also substantially younger than Jitsi, which as a company has been acquired and sold on a few times already). One of the main differences for the end user is that with Jitsi you need to install additional apps on your phone and on your desktop you need additional extensions for screensharing. Kopano Meet on the other hand is designed as a PWA, which means even though its a webpage it will offer itself to be installed as an app on devices supporting this (which is iOS, Chrome and Firefox on Android and Chrome, Firefox and Edge on the desktop). The installed app automatically refreshes if the code on the server is updated. For calling and screensharing native browser apis are used which means no need to install further software either.

Like I said guest access is just a matter of configuration, the app just has not been setup to do this automatically. The instructions for this are located at https://documentation.kopano.io/kopano_meet_manual/special_configuration.html#enabling-guest-users-for-meeting-rooms

Edit: if someone is interested in sponsoring the work needed to implement and test guest mode in the app you can reach me at felix@9wd.eu. I'll do my best to make the individual contributions as transparent as possible (or anonymous of the contributor prefers that).

@scooke said in Jitsi Meet:

OR, could a tweak be made on the Cloudon Kopano app so that guests just need the link to join?

Yes, that could definitely be configured. Meet itself supports it, it simply that the Cloudron app so far has not generated much interest, therefore I did not spend any further time on it.

@iamthefij talking about irresponsible disclosure. For the benefit of other Cloudron users it may be wiser to have a non public channel to discuss something like this.

(But it's indeed good that is was noticed and changed)

Ah, I was wondering about that as well. I saw the notification, but dismissed it there (not the right time). When later wanting to reboot from the Cloudron UI I could no longer find the button.

There is already a Firefly III app in the app store. Why do you want to have it without ldap?

@JOduMonT said in Grav CMS:

Yes I could also run my own server as I was doing before and not participating to this community

that was not at all what we were suggesting

But if you have special requirements or always immediately want to run the latest version if may be a benefit to look at the app source and simply deploy your own customised version. Your customisations and updates can then of course be made available via pull requests to the main app.

@JOduMonT said in Pandora: Secure your Cloudron:

etckeeper init is done during the installation, if I remember well, this is/was not the case on older Debian (7/8).

yes, that could indeed match up with the last time I seriously looked at it.

@JOduMonT said in Pandora: Secure your Cloudron:

byobu is arbitrary but also by default on Ubuntu, I guess is a personal choice such as Cloudron seams to prefer Mosh when it comes time to interact with a remote terminal

I am not sure of the linked chapter really establishes that mosh is preferred. It was probably simply a questions from someone and easy to add to the documentation. But mosh is also something quite different to byobu/tmux.

@JOduMonT said in Pandora: Secure your Cloudron:

At the end you are welcome to help us and propose change

Thats why I am giving feedback here

@yusf or running your own version of the grav app.

hmm. just from an observing position I am not 100% sure if all these changes are a good idea in the context of Cloudron.

If there are sensible hardening steps, they should probably be baked into the base setup of Cloudron already.

https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L43
this installs etckeeper, but as far as I can see does not configure it (at least the last time I played with it, it still required an etckeeper init of some sorts to actually record changes). Seeing the amount of configuration changes it may be a good idea to take a snapshot of the current configuration before modifying anything.

https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L22
why install non security related stuff like byobu?
this also installs packages which probably already exist on a system (like ca-certificates) and also some stuff that may be better left to cloudron, like unattended-upgrades. In the past the statement for this was that Cloudron will take care of package updates, this is to make sure that an updated package does not break compatibility.

https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L155
Moving the ssh port is security by obscurity.

https://git.cloudron.io/jodumont/pandora/-/blob/master/secure.sh#L232
pulling in unversioned changes can result in unpredicable behaviour