Difference between revisions of "Cloudron"

Revision as of 20:04, 1 May 2017

Cloudron is a powerful free-as-in-freedom cloud platform that allows you to self-host webapps efficiently while providing unified user accounts, various automated sysadmin services, tested update pathways for dozens of mature free software apps in the Cloudron appstore and a RESTful API.

At the FKI, together with a range of actors in Barcelona we are currently testing the Cloudron.

Installation instructions

Cloudron's reference documentation contains installation instructions.

We start with a clean Ubuntu machine provided by our community datacentre partner La Mar De Bits.

We point the main domain name A record with a wildcard (*) to the IP of the server. Some ISPs (like Digital Ocean and AWS/Route 53) provide an API to their DNS servers to which the Cloudron makes calls to manage the domain name. In this case we have a domain at https://dinahosting.com/, which seems to have an API for their DNS. We could check with the Cloudron team to see if they can add support for this ISP.

We download and run the installation script with: $ wget https://cloudron.io/cloudron-setup $ chmod +x cloudron-setup $ sudo ./cloudron-setup --provider generic

And after a while (15-30") we browse to the IP address of the server where we accept the generated and unrecognised SSL certificate. Then we can create an admin user and we are in the my. subdomain where we can configure all the rest.

We want to enable the email server, but when doing so a message appears: "No DNS provider is setup. Displayed DNS records will have to be setup manually." Logically so, as we had only pointed a wildcard A record to the server. So we manually add DNS records at our domain dame service provider for the MX, TXT records as detailed in the Email setup section under settings (check the "advanced" link underneath each record in settings). Only I'm not sure how to deal with the PTR .in-addr.arpa address: where can one register such reverse address lookup?

Installing apps

Cloudron has an apps store that runs by default at cloudron.io and provides dozens of mature free software apps ported to the Cloudron platform.

Rocket.chat

We click the Rocket.chat button in the store and it asks us under what subdomain we want to install it and what users will be able to use it (we choose: all). Then there is a warning: "The first user to login becomes the Rocket.Chat administrator This administrator can mark other users as administators."

Phabricator

installation at "phabricator." subdomain. Warning that the RAM is too little. Message: "This Phabricator app does not integration with Cloudron User management. To complete the installation, setup an administrative account and setup an Auth provider. If you accidentally log yourself out before adding an Auth provider, you must use the CLI tool to recover it (or simply re-install phabricator). See T8282 for more information. We simply fill in "my.femprocomuns.cat" for the domain name and confirm the creation of this authentication provider. But no, that doesn't allow users to authenticate.

You can add users using the 'People' section on the Homepage. See the https://secure.phabricator.com/book/phabricator/article/configuringaccountsand_registration/ for more information. Uploading large files

   How can I upload large files?

This app is configured to accept files upto 512MB. Note that large files need to be dragged and dropped (instead of the file upload button). See Q216"

• ISSUE: how to configure Phabricator? We should somehow configure LDAP authentication inside Phabricator in such way that it authenticates against the cloudron's LDAP user accounts.

Roundcube

We chose "mail." as its subdomain and click install. It gives a message saying: "This application is pre-setup for Cloudron email usage. Just login with your Cloudron account. Note that email is only enabled for Cloudrons using custom domains."

Email

When enabling email, all users get an email address on the server in the form of <user name<@<domain name>. This is interesting but we'd want to have that as an option and not by default. Now every email notification is sent to that new email address while users may not even have it set up and so don't receive the messages.

• ISSUE: Email accounts should be enabled on a per user basis and not by default for all.

Account Registration

By default admins can create user accounts. However we'd want a smooth self-registration process. Som reflections / criteria:

• a free account can be available but with limited resources (1 GB?) and strong measures to avoid SPAM
• full accounts require one to be or become a member/partner of the cooperative. femProcomuns has various typologies with different deposits to be made.
• additionally users can subscribe to a periodic, voluntary contribution, e.g. like Som Mobilitat does (X amount every Y months).

NextCloud

We'll want CollaboraOffice which combines own/nextCloud with LibreOffice, but for now we already set up nextCloud. " This app instance is pre-setup with an admin account. This app integrates with Cloudron authentication. Cloudron users can login and use NextCloud. However, admin status of Cloudron user is not carried over to NextCloud. For this reason, this app comes with an pre-setup admin user. This admin user can grant admin previleges to other users. username: admin password: changeme Please change the admin password on first login"

Helpful commands

Docker images and containers are not named in a descriptive manner. You can list the container running at mail.example.net like this

1. docker ps --filter "label=location=mail"