For those that would be interested. I have just created a live stream on Youtube for Sunday 21.06. 14:00 (CET). During that stream I want to show a bit how to make a Cloudron app and will use Matterbridge as the example for it.
I would timebox the whole stream to a max of two hours, lets see how far I'll get in that time, maybe I won't even need that much time.
There will be an unedited recording of the stream later on.
You can follow the stream at https://www.youtube.com/watch?v=RKcH2yJiLUo
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?
@msbt said in Proposal: Free-Tier Alterations 
:
Not sure if paying for updates defeats the purpose of having a secure system with rolling auto-updates
Exactly. I think it's bad practice to hide things like updates and 2FA behind an extra paywall.
Plus it was like this in the past already and was changed for the very same reason: you don't want to have people with vulnerable old versions out in the wild.
Hello everyone. See you on half an hour at https://youtu.be/RKcH2yJiLUo!
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!
While native support for OAuth has recently been removed from Cloudron users can still utilise OAuth 2 and OpenID Connect (oidc) to authorize users thanks to the built in OpenID Provider of the Kopano Meet app.
Under the hood Kopano Meet uses OpenID Connect to sign users into the application and this functionality is provided through Kopano Konnect, which is bundled inside of the app and pre-configured to allow Cloudron users to login. This article will show how to extend the configuration of Kopano Konnect to allow other apps to make use of OpenID Connect.
Requirements:
Nextcloud only serves as an example most users will probably already be familiar with, any other app allowing login through oidc can be configured in a similar way.
In the below configuration snippets I am going to use the domain meet.9wd.eu for my Kopano Meet installation and cloud.9wd.eu for my Nextcloud installation. Make sure to use your actual domain names during the configuration.
To modify the configuration of Konnect you need to login at your Cloudron dashboard (which is usually available at https://my.your-comain.com) and open the terminal view of the Meet app (Look for "Console Access" in the settings of Meet). Here you need to open /app/data/konnectd-identifier-registration.yaml in an editor and add the following text to the end of the file:
- id: cloud.9wd.eu
application_type: web
name: Nextcloud Cloudron
trusted: true
redirect_uris:
- https://cloud.9wd.eu/index.php/apps/sociallogin/custom_oidc/CloudronMeet
Important: the redirect url must match the "internal name" specified during the social login configuration later on
After the file has been modified restart Konnect by running supervisorctl restart kopano-konnectd (alternatively the whole meet app could be restarted, but this is faster).
The rest of the configuration is done inside of Nextcloud.
To configure Nextcloud for oidc you first need to login with an admin level user and install the "social login" app inside of Nextcloud. After the app has been installed you have go into its settings (which are located at https://cloud.9wd.eu/settings/admin/sociallogin) to configure it.
I recommend to have the following general configuration settings set in the app:
This will mean that new users will first need to login through the "traditional" Nextcloud login and then from within their user settings link their oidc login to Nextcloud. This will be further explained once oidc is generally setup in Nextcloud.
Further down in the settings add your own "custom OpenID Connect" provider. You need to fill in the following values:
redirect_uris in konnectd-identifier-registration.yamlhttps://meet.9wd.eu/.well-known/openid-configurationOnce this is setup log out with your admin user account and you will see another login button on the Nextcloud login page titled "Kopano Konnect (Cloudron)".
Before the user can use oidc to log into Nextcloud, he need to link his existing Cloudron user to it. For this log into Nextcloud like you have done in the past and afterwards go into the settings of the user. Here you will now find an option called "social login" (the url will be similar to https://cloud.9wd.eu/settings/user/sociallogin).
Users need to manually connect their existing Nextcloud account with the oidc identity.
At this menu item you will find a section called "Available providers" with a button underneath that will read "Kopano Konnect (Cloudron)". Click this button once to link your Nextcloud account to your new OpenID identity. In case you have previously not been logged into Meet you will be asked for your credentials for this (which are your normal Cloudron credentials).
Once your Nextcloud account has been linked you can easily switch between Nextcloud and Kopano Meet without having to login again.
This article has also been published on my blog.
@d19dotca said in Cachet - status page system:
I think the more common ones to Cachet is StatPing, ..
I played around with statping today. What intrigues me about it (apart from it being written in golang) is the ability to use custom webhooks and even own scripts for notifications.
App is located at https://git.cloudron.io/fbartels/statping-app/, but surely can use some more polish. But it is generally in an "it works" state.
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.
@ei8fdb I have packaged matterbride as an app before, but not for cloudron.
When fiddling with ci tools I was already thinking about live streaming my work on it. I could set something up for Sunday afternoon (CET) if there would be people interested in watching ( @JOduMonT ?).
Making an app for cloudron should be relatively easy, the one thing you have to be aware of though is that you have to configure in manually in it's config file, as there is no web UI for it (plus it requires manual setup of whatever system you want to bridge).
Hi,
I am not using it myself, but could imagine this being useful to others. Looking at their deployment structures this only needs node and a postgres database.
@yusf the problem with the export from the bitwarden cli is that this would only concern the actual password data, but would not include any of the attachments.
In that sense Bitwarden is only good enough for a whole installation disaster recovery (since Cloudron is doing regular backups, you can restore the setup as it was at a given time). If you want per user backups you could use https://github.com/vwxyzjn/portwarden however (would need the credentials of the given user, but could be used for migrations as well).
In both those cases you can most likely use another table prefix. While this is not really common for backend type of applications, the last time I looked into php based stuff it still was very common (owncloud/nextcloud uses oc_ for example).
Portainer has a mechanism that is called "templates". An admin can override the data source these templates are loaded from.
This way the cloudron admin could add another data source to the "App Store" on his Cloudron. Apps from that source could show in a dedicated category, potentially with a disclaimer above.
Plus points if the address would allow password protection (so that one could use an auth enabled surfer instance to host the file).
This is how the portainer template looks like:
https://github.com/portainer/templates/blob/master/templates-2.0.json
@nebulon yes that would be a good approach, as it would immediately be compatible with some static site builders such as Hugo.
@enigma84 inside of the app apache is serving the pages, see https://git.cloudron.io/cloudron/nextcloud-app/-/blob/master/start.sh#L190
@enigma84 said in Need a custom home page for an app.:
In my specific situation i don't want to expose default nextcloud login page.
What is the use case behind this?
Hi @svallory,
a very similar scenario was recently discussed at https://forum.cloudron.io/topic/4390/managing-ssl-certs-via-cloudron-cli/
@msbt said in Proposal: Free-Tier Alterations :
Not sure if paying for updates defeats the purpose of having a secure system with rolling auto-updates
Exactly. I think it's bad practice to hide things like updates and 2FA behind an extra paywall.
Plus it was like this in the past already and was changed for the very same reason: you don't want to have people with vulnerable old versions out in the wild.
@thetomester13 said in bitwarden_rs 1.19 has been released:
is this not available for self hosted?
Generally yes, but you always have to remember that bitwarden_rs is a volunteer driven implementation of the official serverside api. So just because Bitwarden implements a feature it does not mean the same will be available in bitwarden_rs.
@nebulon said in Managing SSL certs via Cloudron CLI:
you have to "forget" the page in your browser
yes, or visit the site in an incognito session. Clearing these entries from the profile in Chrome is slightly more complicated, but doable as well.
@nebulon said in How to add "server" locales:
You would have to change it inside the container and it looks like, that the app package needs some tweaking to support changing it
Its probably easier to just define some focus languages and to add them directly into the base image. There are some other applications that also depend on system locales so it would imho make not much sense to have an individual locale selection in all apps.