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?
Hello everyone. See you on half an hour at https://youtu.be/RKcH2yJiLUo!
@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.
I recently talked to the CEO of Humhub and also made him aware of Cloudron and this topic. He said that they are currently busy with investigating ways to automate deployments in container scenarios and once that is solved they would be open to collaborate on an app for Cloudron.
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.
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 @guyds,
I think that should work, there is one downside however. The cloudron dashboard is always available at my.domain.tld so when setting up your various cloudrons you cannot specify domain.tld as the domain for each of them, but would need to do server1.domain.tld (so that the cloudron dashboard would then be at my.server1.domain.tld).
After the initial setup you can then add domain.tld to the domains so you can have forum.domain.tld etc.
@jdaviescoates said in Why not make Cloudron fully open source again?:
Co-op Cloud
It's an interesting, but also really quite different approach. I like cloudron because it's so "hands off". Their system really just seems to be a deployment utility for docker swarm along with a standardised way of deployment.
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.
@nebulon thanks. works like a charm now.
Hi @derin,
if this is the full file you have posted here then this is indeed broken json. Your code is missing a last closing }.
Hi @nebulon,
that sounds like a nice and simple solution.
Primarily we want that users see the contents of the script when navigating to https://setup.domain.com, so with the above tweak we can just store the script as index.txt and instruct them to do curl https://setup.domain.com > script.sh.
So that would be covered by your solution.
Hi,
currently surfer has the ability to serve either index.html oder index.htm as its default file visiting the domain where surfer is installed.
What we want to do is to provide an install script (which should be served as text/plain or maybe rather application/x-shellscript) on one of my Cloudron domains so users can simply do a:
wget https://setup.domain.com
bash index.sh
edit: the file should be displayed in plain so application/x-shellscript would not be the desired behaviour actually.
Hi @telos-one,
by definition the code of apps running on cloudron is often located in /app/code.
But in the end a cron job for an app should be defined in the apps manifest. How this needs to look is documented at https://docs.cloudron.io/custom-apps/addons/#scheduler
@nj you could also use the imapsync docker container, which would leave no traces after running. I explained its usage in https://forum.cloudron.io/topic/3819/imapsync-can-i-install-imapsync-on-the-same-server-where-cloudron-is-installed/8?_=1620658257173
Hi @subtlecourage,
@msbt is full text search enabled for these mail apps?
@scooke I can confirm that changing the timezone for the vikunja api makes the service fail. Switching it back to gmt makes the service start again.
Seems like a case for the Vikunja bugtracker after all
@scooke that looks like the service that is providing the vikunja api is failing/has stopped. I would have expected that a restart of the whole app would have made it start up again, but if that is not the case there must be something else going on.
I would restart the app again and watch closely what kind of information are logged during the startup.
Disclaimer: not affiliated with Vikunja and also not using it