1.8.4 changes

Fix display of DNS records when not using cloudron-smtp
Fixes #492
2017-12-07 20:17:35 +05:30 · 2017-12-07 20:13:28 +05:30 · 2017-12-07 20:12:34 +05:30 · 2017-11-23 02:48:16 +01:00 · 2017-11-23 02:48:16 +01:00 · 2017-11-23 02:48:12 +01:00
353 changed files with 35767 additions and 15905 deletions
@@ -715,3 +715,426 @@
 * Remove tutorial
 * Restart mail container on certificate change

+[0.97.0]
+* Fix missing app icon issue
+* Fix issue where box sends out crash reports incessantly
+* (API) Allow memory limit to be set to -1 (unlimited)
+* (API) Move developmentMode flag from manifest to apps route
+
+[0.98.0]
+* Send stat on whether email is enabled
+* Fix bug where heartbeat was sent for self-hosted Cloudrons
+* Make Cloudron function even when disk is full
+* Fix thunderbird connection issue
+* Send more detailed logs for backup failures
+* Restart nginx if it crashed automatically
+* Support all DNS providers for managed Cloudrons
+* Add granular configuration for auto-updates
+
+[0.99.0]
+* Fix bug where ports <= 1023 were not reserved
+* Cleanup graphs UI
+* Polish webadmin UI
+* Fix bug where hard disk size was detected incorrectly
+
+[0.99.1]
+* Fix bug with duplicate nginx configs
+
+[0.100.0]
+* Improve DNS notifications for email
+* Do not enable HSTS for subdomains
+
+[0.100.1]
+* Fix crash when fetching mail records
+* Fix crash in LDAP server when username and displayName are empty
+
+[0.101.0]
+* New base image 0.10.0
+* Better error handling of unpurchase errors
+* Validate that cloudron domain name is a subdomain of public suffic list
+* Add canada and london to S3 backup regions
+* Bundle Font Awesome as part of webadmin
+* Fix crash in custom certiicate validation
+* Get A+ rating in SSL Check
+* More robust detection and injection of SPF record
+* Add azure, lightsail, linode, ovh, vultr to provider list
+
+[0.102.0]
+* Fix issue where SPF record check was only done 5 times (updated 'async')
+* Make auto-generated self-signed cert load quickly on Firefox
+* Ensure we download docker images and have an app data volume on app re-configure
+* Improve certificate renewal erorr message
+* Fix disk usage graph
+* Show Repair UI for errored apps
+
+[0.102.1]
+* Add terms link when signing up for Cloudron.io account
+* Fix issue where Cloudrons with many apps (> 35) were unable to backup
+* Improve wording of DNS Setup
+
+[0.103.0]
+* Do not send crash logs and other notifications to support@cloudron.io for self-hosted instances
+* Make auto-generated self-signed cert load quickly on Firefox (take 2)
+
+[0.104.0]
+* (mail) Fix crash when sending mails to groups with just 1 user
+* (ldap) Add isadmin attribute to better map users in apps
+* (ldap) Hide users which have not yet set a username in ldap searches
+* (core) Add SSH authorized_keys management
+* (core) Add additional security related headers to the nginx reverse proxy
+* (ui) Add remote SSH support option
+* (ui) Fix eventlog display
+* (ui) Fix CNAME setup information
+
+[0.105.0]
+* Always show email related checks
+* Show outbound SMTP port 25 status
+* Hide remote feature for normal users
+* Only list users via ldap searches who have access to the app
+* Fix installation issue on servers with a differente locale set
+
+[0.105.1]
+* Fix crash when setupToken is not provided in activate API
+* Add inline Docker GPG key
+* Re-download icon when repairing app
+* Fix issue where pre-installed apps were not installed correctly
+* Fix issue where new cloudrons could not be activated
+
+[0.106.0]
+* (mail) Fix email forwarding to external domains
+* (mail) Set maximum email size to 25MB
+* Remove SimpleAuth addon
+
+[0.107.0]
+* Support CSP for webinterface and OAuth views
+* (mail) Fix issue where Cloudron is only used to send emails
+
+[0.108.0]
+* Redirect to /setupdns.html when restoring
+* Fix setting custom avatar
+* Do not allocate more than 4GB swap
+* Generate real passwords for sendmail/recvmail addons
+* Rate limit all authentication routes to prevent password brute force
+* Generate 128 byte password for MySQL multi-db addon
+
+[0.109.0]
+* Add Referrer-policy
+* Add tooltip for admin email field explaining it is local & private
+* Verify AMI instance id during DNS setup instead of admin account setup
+* Split platform and app data folders and get rid of btrfs volumes
+
+[0.110.0]
+* Fix disk usage graphs
+* Add --data-dir to cloudron-setup that allows customizing data location
+* Add UI to restore from any app backup
+* (mysql) Use utf8mb4 encoding for databases and backups
+* Allow installing a new app from a backup
+* Fix download of large files (> 1GB)
+* Fix app backup regression
+
+[0.120.0]
+* Update Docker to 17.03.1-ce
+* Rework backup backend logic
+* Add UI to download logs
+* Fix crash when checking mail dns settings
+* Allow backup retention duration to be configured
+* Add minio backend for backups
+* Fix issue where Cloudron's with errored apps won't backup when using fs backend
+* Fix DNS check issue where PTR records was read from hosts file
+
+[0.120.1]
+* Fix managed Cloudron backup cleanup
+
+[0.130.0]
+* Use Cloudron DNS server only for containers created by Cloudron
+* Make Cloudron always start even if DNS credentials are invalid
+* Show warning if DNS configuration is not valid
+* Drop the '.enc' extension for non-encrypted backups
+* Do not encrypt backups when the backup key is empty
+* Do a multipart S3 download for slow internet connections
+* Support naked domains as external location
+
+[0.130.1]
+* Fix app configure dialog regression
+
+[0.130.2]
+* Fix app configure dialog regression and dns setup screen
+
+[0.130.3]
+* Show error message if setup fails due to reserved username
+* (security) Do not print password in the logs in the configure route
+* Fix restore of unencrypted backups
+* Fix bug where FS backups have incorrect extension for unencrypted backups
+
+[0.140.0]
+* HTTP2 support
+* Condense the dns checks in the settings view
+* Document new app store submission guidelines
+
+[0.150.0]
+* Disable dnsmasq on OVH
+* Scale redis memory based on the app's memory limit
+* (security) Do not print the ssl cert in debug logs
+* Add noop storage backend to temporarily disable backups
+* Replace native-dns module with dig to prevent spurious crashes
+* Cleanup unfinished and errored backups
+* Set a timelimit of 4 hours for backup to finish
+
+[0.160.0]
+* Fix disk graphs when using device mapper
+* Prevent email view from flickering
+* Prepare for 1.0
+
+[1.0.0]
+* Make selfhosting great again
+
+[1.0.1]
+* Notification improvements
+
+[1.0.2]
+* Notification improvements
+
+[1.1.0]
+* Add support for email catch-all
+* Support Cloudrons on subdomains
+
+[1.1.1]
+* Notification improvements
+
+[1.1.2]
+* Notification improvements
+
+[1.1.3]
+* Notification improvements
+
+[1.2.0]
+* Relay emails optionally via external SMTP server email (mailgun, sendgrid etc)
+* (experimental) Preserver the docker storage driver across updates
+* Reduce mysql password length to 48
+
+[1.2.1]
+* Set max ttl of unbound to 5 minutes
+* Fix issue where mail container does not cleanup LDAP connections properly
+* Update node to 6.11.1
+
+[1.3.0]
+* Add option to configure robots.txt for each app from the web interface
+* Make sure zoneName is not lost across updates
+* Save manually triggered app backups under a datetime prefix
+* Optionally disable FROM validation check in the mail container. This will allow apps to send emails with arbitrary FROM addresses
+* Set X-Forwarded-Port in the reverse proxy. This fixes a problem with plugins of certain apps (like Jetpack)
+* Send a weekly activity digest about pending and applied Cloudron and app updates
+
+[1.4.0]
+* (mail) Update Haraka to 2.8.14. Contains many stability fixes
+* Exoscale SOS can now be used for backup storage
+* Fix cron pattern that made Cloudron erroneously send out weekly digest mails every hour on wednesday
+* Add Cloudflare DNS backend (thanks @abhishek)
+* Ensure Cloudron is only be installed on EXT4 root file system (required by Docker)
+* Mark app package major releases as blocking and require approval by Cloudron admin
+
+[1.4.1]
+* Do not display backup region when using minio and exoscale SOS
+* Fix javascript error in email view
+* Add html version of the digest email
+* Fix issue where collectd was collecting information about devicemapper mounts
+
+[1.5.0]
+* Update node to 6.11.2
+* Add a new view to display platform and app logs
+* Rework web UI to use flexbox
+* Add motd message to warn admins that to not run 'apt upgrade'
+* Switch default storage backend for new Cloudrons to overlay2
+* Add a custom graphite plugin to collect disk usage statistics
+* Rotate logs of all apps automatically
+
+[1.6.0]
+* Allow apps to have 'network' capability (thanks @mehdi)
+* Fix crash in collectd disk usage collection script
+* Fix layout issues in update and oauth views
+* Use maxsize rule instead of size in lograte configs
+* Make it possible to skip backups per-app
+* Hide restore button for noop backend
+* Add popups and warnings for noop backend
+* Add webterminal to shell into apps from the admin UI
+* Update Haraka for a few crash fixes
+
+[1.6.1]
+* Patch release for 1.6.0 to fix regressions
+* Allow apps to have 'network' capability (thanks @mehdi)
+* Fix crash in collectd disk usage collection script
+* Fix layout issues in update and oauth views
+* Use maxsize rule instead of size in lograte configs
+* Make it possible to skip backups per-app
+* Hide restore button for noop backend
+* Add popups and warnings for noop backend
+* Add webterminal to shell into apps from the admin UI
+* Update Haraka for a few crash fixes
+
+[1.6.2]
+* Allow apps to have 'network' capability (thanks @mehdi)
+* Fix crash in collectd disk usage collection script
+* Fix layout issues in update and oauth views
+* Use maxsize rule instead of size in lograte configs
+* Make it possible to skip backups per-app
+* Hide restore button for noop backend
+* Add popups and warnings for noop backend
+* Add webterminal to shell into apps from the admin UI
+* Update Haraka for a few crash fixes
+
+[1.6.3]
+* Fixes selection issue while clicking on empty flexbox space
+* Indicate directories can be downloaded in the web terminal
+* Do not show app update indicator for normal users
+* Display email notice when using Cloudflare DNS
+* Set MX records correctly when using Cloudflare DNS
+* Fix bug where webterminal can incorrectly appear in main view
+* Do not crash if DNS credentials are invalid
+
+[1.6.4]
+* More descriptive Postmark email relay form
+* Fix file upload in chrome
+* Support Ctrl/Cmd+v webterminal pasting
+* Ensure unbound always starts up
+* Add option to run app in repair mode
+
+[1.6.5]
+* DigitalOcean DNS: Add pagination
+* Cloudflare DNS: Optimize listing of DNS entries
+* Update node to 6.11.3
+* App volumes can now be symlinked individually to external storage
+* Periodically check if IP is blacklisted and notify admins
+* Do not ask password when re-configuring app (since it is non-destructive)
+* Move mail data inside boxdata directory. This makes the no-op backend more useful
+* Remove collectd stats when app is uninstalled
+
+[1.7.0]
+* Add rsync format for backups. This feature allows incremental backups
+* Add Google DNS backend (thanks @syn)
+* Add DigitalOcean spaces backup storage backend
+* Add Cloudscale and Exoscale as supported VPS providers
+* Display backup progress and status in the web interface
+* Preliminary IPv6 support
+* Add IP RBL status to web interface
+* Add auto-update pattern `Every wednesday night`
+* Update Haraka to 2.8.15. This fixes the issue where emails were bounced with the message 'Send MAIL FROM first'
+* Do not overwrite existing subdomain when app's location is changed
+* Add button to send test email
+* Fix crash in carbon which made graphs disappear on some Cloudrons
+
+[1.7.1]
+* Add rsync format for backups. This feature allows incremental backups
+* Add Google DNS backend (thanks @syn)
+* Add DigitalOcean spaces backup storage backend
+* Add Cloudscale and Exoscale as supported VPS providers
+* Display backup progress and status in the web interface
+* Preliminary IPv6 support
+* Add IP RBL status to web interface
+* Add auto-update pattern `Every wednesday night`
+* Update Haraka to 2.8.15. This fixes the issue where emails were bounced with the message 'Send MAIL FROM first'
+* Do not overwrite existing subdomain when app's location is changed
+* Add button to send test email
+* Fix crash in carbon which made graphs disappear on some Cloudrons
+
+[1.7.2]
+* Add rsync format for backups. This feature allows incremental backups
+* Add Google DNS backend (thanks @syn)
+* Add Cloudscale and Exoscale as supported VPS providers
+* Display backup progress and status in the web interface
+* Preliminary IPv6 support
+* Add IP RBL status to web interface
+* Add auto-update pattern `Every wednesday night`
+* Update Haraka to 2.8.15. This fixes the issue where emails were bounced with the message 'Send MAIL FROM first'
+* Do not overwrite existing subdomain when app's location is changed
+* Add button to send test email
+* Fix crash in carbon which made graphs disappear on some Cloudrons
+* Fix issue where OAuth SSO did not work when alternate domain was used
+
+[1.7.3]
+* Add rsync format for backups. This feature allows incremental backups
+* Add Google DNS backend (thanks @syn)
+* Add Cloudscale and Exoscale as supported VPS providers
+* Display backup progress and status in the web interface
+* Preliminary IPv6 support
+* Add IP RBL status to web interface
+* Add auto-update pattern `Every wednesday night`
+* Update Haraka to 2.8.15. This fixes the issue where emails were bounced with the message 'Send MAIL FROM first'
+* Do not overwrite existing subdomain when app's location is changed
+* Add button to send test email
+* Fix crash in carbon which made graphs disappear on some Cloudrons
+* Fix issue where OAuth SSO did not work when alternate domain was used
+
+[1.7.4]
+* Add rsync format for backups. This feature allows incremental backups
+* Add Google DNS backend (thanks @syn)
+* Add DigitalOcean spaces backup storage backend
+* Add Cloudscale and Exoscale as supported VPS providers
+* Display backup progress and status in the web interface
+* Preliminary IPv6 support
+* Add IP RBL status to web interface
+* Add auto-update pattern `Every wednesday night`
+* Update Haraka to 2.8.15. This fixes the issue where emails were bounced with the message 'Send MAIL FROM first'
+* Do not overwrite existing subdomain when app's location is changed
+* Add button to send test email
+* Fix crash in carbon which made graphs disappear on some Cloudrons
+* Fix issue where OAuth SSO did not work when alternate domain was used
+* Changelog is now rendered in markdown format
+
+[1.7.5]
+* Expose a TLS relay port from mail container for Go applications
+
+[1.7.6]
+* Port bindings cannot be configured in update route anymore
+* Implement LDAP group compare
+* Pre-releases are now offered by appstore and not handled in box code anymore
+* LDAP pagination support. This will fix the warnings in NextCloud and Rocket.Chat
+* Check if directories can be created in the backup directory
+* Do not set the HTTPS agent when using HTTP with minio backup backend
+* Fix regression where a new domain config could not be set in the UI
+* New mail container release that fixes email sending with SOGo
+* Show 404 page for unknown domains
+
+[1.7.7]
+* Allow setting app memory till memory limit
+* Make the dkim selector dynamic
+* Fix issue where app update dialog did not close
+* Fix LE cert renewal failures
+* Send user and cert info in digest emails
+* Send oom, app failures and other important mails to cloudron owner's alt mail
+
+[1.8.0]
+* Fix group email bounce when a group has users that have not signed up yet
+* Do not restrict app memory limit to 4GB
+* Fix display of the latest backup in the weekly digest
+* Add UI to select users for access restriction
+* Update docker to 17.09
+* Update node to 6.11.5
+* Display package version of installed apps in the info dialog
+
+[1.8.1]
+* Update node modules
+* Allow a restore operation if app is already restoring
+* Remove pre-install bundle support since it was hardly used
+* Make the test email mail address configurable
+* Allow admins to access all apps
+* Send feedback via appstore API (instead of email)
+* Show documentation URL in the app info dialog
+* Update Lets Encrypt agrement URL (https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)
+
+[1.8.2]
+* Update node modules
+* Allow a restore operation if app is already restoring
+* Remove pre-install bundle support since it was hardly used
+* Make the test email mail address configurable
+* Allow admins to access all apps
+* Send feedback via appstore API (instead of email)
+* Show documentation URL in the app info dialog
+* Update Lets Encrypt agrement URL (https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)
+
+[1.8.3]
+* Ensure domain database record exists
+
+[1.8.4]
+* Fix issue where internal email was not delivered when email relay is enabled
+* Fix display of DNS records when email relay is enabled
+
@@ -630,7 +630,7 @@ state the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.

    box
-    Copyright (C) 2016 Cloudron UG
+    Copyright (C) 2016,2017 Cloudron UG

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as published
@@ -46,10 +46,14 @@ Try our demo at https://my-demo.cloudron.me (username: cloudron password: cloudr
 ## Installing

 You can install the Cloudron platform on your own server or get a managed server
-from cloudron.io.
+from cloudron.io. In either case, the Cloudron platform will keep your server and
+apps up-to-date and secure.

-* [Selfhosting](https://cloudron.io/references/selfhosting.html)
-* [Managed Hosting](https://cloudron.io/pricing.html)
+* [Selfhosting](https://cloudron.io/references/selfhosting.html) - [Pricing](https://cloudron.io/pricing.html)
+* [Managed Hosting](https://cloudron.io/managed.html)
+
+The wiki has instructions on how you can install and update the Cloudron and the
+apps from source.

 ## Documentation

@@ -0,0 +1,193 @@
+#!/bin/bash
+
+set -eu -o pipefail
+
+assertNotEmpty() {
+    : "${!1:? "$1 is not set."}"
+}
+
+readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+readonly SOURCE_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")"/.. && pwd)"
+export JSON="${SOURCE_DIR}/node_modules/.bin/json"
+
+INSTANCE_TYPE="t2.micro"
+BLOCK_DEVICE="DeviceName=/dev/sda1,Ebs={VolumeSize=20,DeleteOnTermination=true,VolumeType=gp2}"
+SSH_KEY_NAME="id_rsa_yellowtent"
+
+revision=$(git rev-parse HEAD)
+ami_name=""
+server_id=""
+server_ip=""
+destroy_server="yes"
+deploy_env="prod"
+image_id=""
+
+args=$(getopt -o "" -l "revision:,name:,no-destroy,env:,region:" -n "$0" -- "$@")
+eval set -- "${args}"
+
+while true; do
+    case "$1" in
+    --env) deploy_env="$2"; shift 2;;
+    --revision) revision="$2"; shift 2;;
+    --name) ami_name="$2"; shift 2;;
+    --no-destroy) destroy_server="no"; shift 2;;
+    --region)
+        case "$2" in
+        "us-east-1")
+            image_id="ami-6edd3078"
+            security_group="sg-a5e17fd9"
+            subnet_id="subnet-b8fbc0f1"
+            ;;
+        "eu-central-1")
+            image_id="ami-5aee2235"
+            security_group="sg-19f5a770" # everything open on eu-central-1
+            subnet_id=""
+            ;;
+        *)
+            echo "Unknown aws region $2"
+            exit 1
+            ;;
+        esac
+        export AWS_DEFAULT_REGION="$2"    # used by the aws cli tool
+        shift 2
+        ;;
+    --) break;;
+    *) echo "Unknown option $1"; exit 1;;
+    esac
+done
+
+# TODO fix this
+export AWS_ACCESS_KEY_ID="${AWS_ACCESS_KEY}"
+export AWS_SECRET_ACCESS_KEY="${AWS_ACCESS_SECRET}"
+
+readonly ssh_keys="${HOME}/.ssh/id_rsa_yellowtent"
+readonly SSH="ssh -o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ${ssh_keys}"
+
+if [[ ! -f "${ssh_keys}" ]]; then
+    echo "caas ssh key is missing at ${ssh_keys} (pick it up from secrets repo)"
+    exit 1
+fi
+
+if [[ -z "${image_id}" ]]; then
+    echo "--region is required (us-east-1 or eu-central-1)"
+    exit 1
+fi
+
+function get_pretty_revision() {
+    local git_rev="$1"
+    local sha1=$(git rev-parse --short "${git_rev}" 2>/dev/null)
+
+    echo "${sha1}"
+}
+
+function wait_for_ssh() {
+    echo "=> Waiting for ssh connection"
+    while true; do
+        echo -n "."
+
+        if $SSH ubuntu@${server_ip} echo "hello"; then
+            echo ""
+            break
+        fi
+
+        sleep 5
+    done
+}
+
+now=$(date "+%Y-%m-%d-%H%M%S")
+pretty_revision=$(get_pretty_revision "${revision}")
+
+if [[ -z "${ami_name}" ]]; then
+    ami_name="box-${deploy_env}-${pretty_revision}-${now}"
+fi
+
+echo "=> Create EC2 instance"
+id=$(aws ec2 run-instances --image-id "${image_id}" --instance-type "${INSTANCE_TYPE}" --security-group-ids "${security_group}" --block-device-mappings "${BLOCK_DEVICE}" --key-name "${SSH_KEY_NAME}" --subnet-id "${subnet_id}" --associate-public-ip-address \
+    | $JSON Instances \
+    | $JSON 0.InstanceId)
+
+[[ -z "$id" ]] && exit 1
+echo "Instance created  ID $id"
+
+echo "=> Waiting for instance to get a public IP"
+while true; do
+    server_ip=$(aws ec2 describe-instances --instance-ids ${id} \
+        | $JSON Reservations.0.Instances \
+        | $JSON 0.PublicIpAddress)
+
+    if [[ ! -z "${server_ip}" ]]; then
+        echo ""
+        break
+    fi
+
+    echo -n "."
+    sleep 1
+done
+
+echo "Got public IP ${server_ip}"
+
+wait_for_ssh
+
+echo "=> Fetching cloudron-setup"
+while true; do
+
+    if $SSH ubuntu@${server_ip} wget "https://cloudron.io/cloudron-setup" -O "cloudron-setup"; then
+        echo ""
+        break
+    fi
+
+    echo -n "."
+    sleep 5
+done
+
+echo "=> Running cloudron-setup"
+$SSH ubuntu@${server_ip} sudo /bin/bash "cloudron-setup" --env "${deploy_env}" --provider "ami" --skip-reboot
+
+wait_for_ssh
+
+echo "=> Removing ssh key"
+$SSH ubuntu@${server_ip} sudo rm /home/ubuntu/.ssh/authorized_keys /root/.ssh/authorized_keys
+
+echo "=> Creating AMI"
+image_id=$(aws ec2 create-image --instance-id "${id}" --name "${ami_name}" | $JSON ImageId)
+[[ -z "$id" ]] && exit 1
+echo "Creating AMI with Id ${image_id}"
+
+echo "=> Waiting for AMI to be created"
+while true; do
+    state=$(aws ec2 describe-images --image-ids ${image_id} \
+        | $JSON Images \
+        | $JSON 0.State)
+
+    if [[ "${state}" == "available" ]]; then
+        echo ""
+        break
+    fi
+
+    echo -n "."
+    sleep 5
+done
+
+if [[ "${destroy_server}" == "yes" ]]; then
+    echo "=> Deleting EC2 instance"
+
+    while true; do
+        state=$(aws ec2 terminate-instances --instance-id "${id}" \
+            | $JSON TerminatingInstances \
+            | $JSON 0.CurrentState.Name)
+
+        if [[ "${state}" == "shutting-down" ]]; then
+            echo ""
+            break
+        fi
+
+        echo -n "."
+        sleep 5
+    done
+fi
+
+echo ""
+echo "Done."
+echo ""
+echo "New AMI is: ${image_id}"
+echo ""
@@ -31,7 +31,7 @@ function create_droplet() {

    local image_region="sfo1"
    local ubuntu_image_slug="ubuntu-16-04-x64"
-    local box_size="512mb"
+    local box_size="1gb"

    local data="{\"name\":\"${box_name}\",\"size\":\"${box_size}\",\"region\":\"${image_region}\",\"image\":\"${ubuntu_image_slug}\",\"ssh_keys\":[ \"${ssh_key_id}\" ],\"backups\":false}"

@@ -26,10 +26,10 @@ debconf-set-selections <<< 'mysql-server mysql-server/root_password_again passwo
 apt-get -y install \
    acl \
    awscli \
-    btrfs-tools \
    build-essential \
    cron \
    curl \
+    dmsetup \
    iptables \
    logrotate \
    mysql-server-5.7 \
@@ -39,34 +39,41 @@ apt-get -y install \
    rcconf \
    swaks \
    unattended-upgrades \
-    unbound
+    unbound \
+    xfsprogs
+
+# this ensures that unattended upgades are enabled, if it was disabled during ubuntu install time (see #346)
+# debconf-set-selection of unattended-upgrades/enable_auto_updates + dpkg-reconfigure does not work
+cp /usr/share/unattended-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades

 echo "==> Installing node.js"
-mkdir -p /usr/local/node-6.9.2
-curl -sL https://nodejs.org/dist/v6.9.2/node-v6.9.2-linux-x64.tar.gz | tar zxvf - --strip-components=1 -C /usr/local/node-6.9.2
-ln -sf /usr/local/node-6.9.2/bin/node /usr/bin/node
-ln -sf /usr/local/node-6.9.2/bin/npm /usr/bin/npm
+mkdir -p /usr/local/node-6.11.5
+curl -sL https://nodejs.org/dist/v6.11.5/node-v6.11.5-linux-x64.tar.gz | tar zxvf - --strip-components=1 -C /usr/local/node-6.11.5
+ln -sf /usr/local/node-6.11.5/bin/node /usr/bin/node
+ln -sf /usr/local/node-6.11.5/bin/npm /usr/bin/npm
 apt-get install -y python   # Install python which is required for npm rebuild
 [[ "$(python --version 2>&1)" == "Python 2.7."* ]] || die "Expecting python version to be 2.7.x"

 # https://docs.docker.com/engine/installation/linux/ubuntulinux/
 echo "==> Installing Docker"
-apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
-echo "deb https://apt.dockerproject.org/repo ubuntu-xenial main" > /etc/apt/sources.list.d/docker.list
-apt-get -y update
-apt-get -y install docker-engine=1.12.5-0~ubuntu-xenial # apt-cache madison docker-engine
-apt-mark hold docker-engine
+
+# create systemd drop-in file
+mkdir -p /etc/systemd/system/docker.service.d
+echo -e "[Service]\nExecStart=\nExecStart=/usr/bin/dockerd -H fd:// --log-driver=journald --exec-opt native.cgroupdriver=cgroupfs --storage-driver=overlay2" > /etc/systemd/system/docker.service.d/cloudron.conf
+
+curl -sL https://download.docker.com/linux/ubuntu/dists/xenial/pool/stable/amd64/docker-ce_17.09.0~ce-0~ubuntu_amd64.deb -o /tmp/docker.deb
+# apt install with install deps (as opposed to dpkg -i)
+apt install -y /tmp/docker.deb
+rm /tmp/docker.deb
+
 storage_driver=$(docker info | grep "Storage Driver" | sed 's/.*: //')
-if [[ "${storage_driver}" != "devicemapper" ]]; then
-    echo "Docker is using "${storage_driver}" instead of devicemapper. Trying to fix this."
-    systemctl stop docker
-    rm -rf /var/lib/docker
-    sed -e 's,^ExecStart=.*$,ExecStart=/usr/bin/docker daemon -H fd:// --log-driver=journald --exec-opt native.cgroupdriver=cgroupfs --storage-driver=devicemapper,' -i /lib/systemd/system/docker.service
-    systemctl daemon-reload
-    systemctl start docker
+if [[ "${storage_driver}" != "overlay2" ]]; then
+    echo "Docker is using "${storage_driver}" instead of overlay2"
+    exit 1
 fi

 echo "==> Enable memory accounting"
+apt-get -y install grub2
 sed -e 's/^GRUB_CMDLINE_LINUX="\(.*\)"$/GRUB_CMDLINE_LINUX="\1 cgroup_enable=memory swapaccount=1 panic_on_oops=1 panic=5"/' -i /etc/default/grub
 update-grub

@@ -90,3 +97,11 @@ if ! apt-get install -y collectd collectd-utils; then
    sed -e 's/^FQDNLookup true/FQDNLookup false/' -i /etc/collectd/collectd.conf
 fi

+# Disable bind for good measure (on online.net, kimsufi servers these are pre-installed and conflicts with unbound)
+systemctl stop bind9 || true
+systemctl disable bind9 || true
+
+# on ovh images dnsmasq seems to run by default
+systemctl stop dnsmasq || true
+systemctl disable dnsmasq || true
+
@@ -13,8 +13,7 @@ var appHealthMonitor = require('./src/apphealthmonitor.js'),
    async = require('async'),
    config = require('./src/config.js'),
    ldap = require('./src/ldap.js'),
-    server = require('./src/server.js'),
-    simpleauth = require('./src/simpleauth.js');
+    server = require('./src/server.js');

 console.log();
 console.log('==========================================');
@@ -33,7 +32,6 @@ console.log();
 async.series([
    server.start,
    ldap.start,
-    simpleauth.start,
    appHealthMonitor.start,
 ], function (error) {
    if (error) {
@@ -48,13 +46,11 @@ var NOOP_CALLBACK = function () { };
 process.on('SIGINT', function () {
    server.stop(NOOP_CALLBACK);
    ldap.stop(NOOP_CALLBACK);
-    simpleauth.stop(NOOP_CALLBACK);
    setTimeout(process.exit.bind(process), 3000);
 });

 process.on('SIGTERM', function () {
    server.stop(NOOP_CALLBACK);
    ldap.stop(NOOP_CALLBACK);
-    simpleauth.stop(NOOP_CALLBACK);
    setTimeout(process.exit.bind(process), 3000);
 });
@@ -1,384 +0,0 @@
-# Overview
-
-Addons are services like database, authentication, email, caching that are part of the
-Cloudron runtime. Setup, provisioning, scaling and maintanence of addons is taken care of
-by the runtime.
-
-The fundamental idea behind addons is to allow sharing of Cloudron resources across applications.
-For example, a single MySQL server instance can be used across multiple apps. The Cloudron
-runtime sets up addons in such a way that apps are isolated from each other.
-
-# Using Addons
-
-Addons are opt-in and must be specified in the [Cloudron Manifest](/references/manifest.html).
-When the app runs, environment variables contain the necessary information to access the addon.
-For example, the mysql addon sets the `MYSQL_URL` environment variable which is the
-connection string that can be used to connect to the database.
-
-When working with addons, developers need to remember the following:
-* Environment variables are subject to change every time the app restarts. This can happen if the
-Cloudron is rebooted or restored or the app crashes or an addon is re-provisioned. For this reason,
-applications must never cache the value of environment variables across restarts.
-
-* Addons must be setup or updated on each application start up. Most applications use DB migration frameworks
-for this purpose to setup and update the DB schema.
-
-* Addons are configured in the [addons section](/references/manifest.html#addons) of the manifest as below:
-```
-    {
-      ...
-      "addons": {
-        "oauth": { },
-        "redis" : { }
-      }
-    }
-```
-
-# All addons
-
-## email
-
-This addon allows an app to send and recieve emails on behalf of the user. The intended use case is webmail applications.
-
-If an app wants to send mail (e.g notifications), it must use the [sendmail](/references/addons#sendmail)
-addon. If the app wants to receive email (e.g user replying to notification), it must use the
-[recvmail](/references/addons#recvmail) addon instead.
-
-Apps using the IMAP and ManageSieve services below must be prepared to accept self-signed certificates (this is not a problem
-because these are addresses internal to the Cloudron).
-
-Exported environment variables:
-```
-MAIL_SMTP_SERVER=       # SMTP server IP or hostname. Supports STARTTLS (TLS upgrade is enforced).
-MAIL_SMTP_PORT=         # SMTP server port
-MAIL_IMAP_SERVER=       # IMAP server IP or hostname. TLS required.
-MAIL_IMAP_PORT=         # IMAP server port
-MAIL_SIEVE_SERVER=      # ManageSieve server IP or hostname. TLS required.
-MAIL_SIEVE_PORT=        # ManageSieve server port
-MAIL_DOMAIN=            # Domain of the mail server
-```
-
-## ldap
-
-This addon provides LDAP based authentication via LDAP version 3.
-
-Exported environment variables:
-```
-LDAP_SERVER=                                # ldap server IP
-LDAP_PORT=                                  # ldap server port
-LDAP_URL=                                   # ldap url of the form ldap://ip:port
-LDAP_USERS_BASE_DN=                         # ldap users base dn of the form ou=users,dc=cloudron
-LDAP_GROUPS_BASE_DN=                        # ldap groups base dn of the form ou=groups,dc=cloudron
-LDAP_BIND_DN=                               # DN to perform LDAP requests
-LDAP_BIND_PASSWORD=                         # Password to perform LDAP requests
-```
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `ldapsearch` client within the context of the app:
-```
-cloudron exec
-
-# list users
-> ldapsearch -x -h "${LDAP_SERVER}" -p "${LDAP_PORT}" -b  "${LDAP_USERS_BASE_DN}"
-
-# list users with authentication (Substitute username and password below)
-> ldapsearch -x -D cn=<username>,${LDAP_USERS_BASE_DN} -w <password> -h "${LDAP_SERVER}" -p "${LDAP_PORT}" -b  "${LDAP_USERS_BASE_DN}"
-
-# list admins
-> ldapsearch -x -h "${LDAP_SERVER}" -p "${LDAP_PORT}" -b  "${LDAP_USERS_BASE_DN}" "memberof=cn=admins,${LDAP_GROUPS_BASE_DN}"
-
-# list groups
-> ldapsearch -x -h "${LDAP_SERVER}" -p "${LDAP_PORT}" -b  "${LDAP_GROUPS_BASE_DN}"
-```
-
-## localstorage
-
-Since all Cloudron apps run within a read-only filesystem, this addon provides a writeable folder under `/app/data/`.
-All contents in that folder are included in the backup. On first run, this folder will be empty. File added in this path
-as part of the app's image (Dockerfile) won't be present. A common pattern is to create the directory structure required
-the app as part of the app's startup script.
-
-The permissions and ownership of data within that directory are not guranteed to be preserved. For this reason, each app
-has to restore permissions as required by the app as part of the app's startup script.
-
-If the app is running under the recommeneded `cloudron` user, this can be achieved with:
-```
-chown -R cloudron:cloudron /app/data
-```
-
-## mongodb
-
-By default, this addon provide mongodb 2.6.3.
-
-Exported environment variables:
-```
-MONGODB_URL=          # mongodb url
-MONGODB_USERNAME=     # username
-MONGODB_PASSWORD=     # password
-MONGODB_HOST=         # server IP/hostname
-MONGODB_PORT=         # server port
-MONGODB_DATABASE=     # database name
-```
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `mongo` shell within the context of the app:
-```
-cloudron exec
-
-# mongo -u "${MONGODB_USERNAME}" -p "${MONGODB_PASSWORD}" ${MONGODB_HOST}:${MONGODB_PORT}/${MONGODB_DATABASE}
-
-```
-## mysql
-
-By default, this addon provides a single database on MySQL 5.6.19. The database is already created and the application
-only needs to create the tables.
-
-Exported environment variables:
-```
-MYSQL_URL=            # the mysql url (only set when using a single database, see below)
-MYSQL_USERNAME=       # username
-MYSQL_PASSWORD=       # password
-MYSQL_HOST=           # server IP/hostname
-MYSQL_PORT=           # server port
-MYSQL_DATABASE=       # database name (only set when using a single database, see below)
-```
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `mysql` client within the context of the app:
-```
-cloudron exec
-
-> mysql --user=${MYSQL_USERNAME} --password=${MYSQL_PASSWORD} --host=${MYSQL_HOST} ${MYSQL_DATABASE}
-
-```
-
-The `multipleDatabases` option can be set to `true` if the app requires more than one database. When enabled,
-the following environment variables are injected:
-
-```
-MYSQL_DATABASE_PREFIX=      # prefix to use to create databases
-```
-
-## oauth
-
-The Cloudron OAuth 2.0 provider can be used in an app to implement Single Sign-On.
-
-Exported environment variables:
-```
-OAUTH_CLIENT_ID=      # client id
-OAUTH_CLIENT_SECRET=  # client secret
-```
-
-The callback url required for the OAuth transaction can be contructed from the environment variables below:
-
-```
-APP_DOMAIN=           # hostname of the app
-APP_ORIGIN=           # origin of the app of the form https://domain
-API_ORIGIN=      # origin of the OAuth provider of the form https://my-cloudrondomain
-```
-
-OAuth2 URLs can be constructed as follows:
-
-```
-AuthorizationURL = ${API_ORIGIN}/api/v1/oauth/dialog/authorize # see above for API_ORIGIN
-TokenURL = ${API_ORIGIN}/api/v1/oauth/token
-```
-
-The token obtained via OAuth has a restricted scope wherein they can only access the [profile API](/references/api.html#profile). This restriction
-is so that apps cannot make undesired changes to the user's Cloudron.
-
-We currently provide OAuth2 integration for Ruby [omniauth](https://github.com/cloudron-io/omniauth-cloudron) and Node.js [passport](https://github.com/cloudron-io/passport-cloudron).
-
-## postgresql
-
-By default, this addon provides PostgreSQL 9.4.4.
-
-Exported environment variables:
-```
-POSTGRESQL_URL=       # the postgresql url
-POSTGRESQL_USERNAME=  # username
-POSTGRESQL_PASSWORD=  # password
-POSTGRESQL_HOST=      # server name
-POSTGRESQL_PORT=      # server port
-POSTGRESQL_DATABASE=  # database name
-```
-
-The postgresql addon whitelists the hstore and pg_trgm extensions to be installable by the database owner.
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `psql` client within the context of the app:
-```
-cloudron exec
-
-> PGPASSWORD=${POSTGRESQL_PASSWORD} psql -h ${POSTGRESQL_HOST} -p ${POSTGRESQL_PORT} -U ${POSTGRESQL_USERNAME} -d ${POSTGRESQL_DATABASE}
-```
-
-## recvmail
-
-The recvmail addon can be used to receive email for the application.
-
-Exported environment variables:
-```
-MAIL_IMAP_SERVER=     # the IMAP server. this can be an IP or DNS name
-MAIL_IMAP_PORT=       # the IMAP server port
-MAIL_IMAP_USERNAME=   # the username to use for authentication
-MAIL_IMAP_PASSWORD=   # the password to use for authentication
-MAIL_TO=              # the "To" address to use
-MAIL_DOMAIN=          # the mail for which email will be received
-```
-
-The IMAP server only accepts TLS connections. The app must be prepared to accept self-signed certs (this is not a problem because the
-imap address is internal to the Cloudron).
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `openssl` tool within the context of the app:
-```
-cloudron exec
-
-> openssl s_client -connect "${MAIL_IMAP_SERVER}:${MAIL_IMAP_PORT}" -crlf
-```
-
-The IMAP command `? LOGIN username password` can then be used to test the authentication.
-
-## redis
-
-By default, this addon provides redis 2.8.13. The redis is configured to be persistent and data is preserved across updates
-and restarts.
-
-Exported environment variables:
-```
-REDIS_URL=            # the redis url
-REDIS_HOST=           # server name
-REDIS_PORT=           # server port
-REDIS_PASSWORD=       # password
-```
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `redis-cli` client within the context of the app:
-```
-cloudron exec
-
-> redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" -a "${REDIS_PASSWORD}"
-```
-
-## scheduler
-
-The scheduler addon can be used to run tasks at periodic intervals (cron).
-
-Scheduler can be configured as below:
-```
-    "scheduler": {
-        "update_feeds": {
-            "schedule": "*/5 * * * *",
-            "command": "/app/code/update_feed.sh"
-        }
-    }
-```
-
-In the above example, `update_feeds` is the name of the task and is an arbitrary string.
-
-`schedule` values must fall within the following ranges:
-
- * Minutes: 0-59
- * Hours: 0-23
- * Day of Month: 1-31
- * Months: 0-11
- * Day of Week: 0-6
-
-_NOTE_: scheduler does not support seconds
-
-`schedule` supports ranges (like standard cron):
-
- * Asterisk. E.g. *
- * Ranges. E.g. 1-3,5
- * Steps. E.g. */2
-
-`command` is executed through a shell (sh -c). The command runs in the same launch environment
-as the application. Environment variables, volumes (`/tmp` and `/run`) are all
-shared with the main application.
-
-If a task is still running when a new instance of the task is scheduled to be started, the previous
-task instance is killed.
-
-
-## sendmail
-
-The sendmail addon can be used to send email from the application.
-
-Exported environment variables:
-```
-MAIL_SMTP_SERVER=     # the mail server (relay) that apps can use. this can be an IP or DNS name
-MAIL_SMTP_PORT=       # the mail server port
-MAIL_SMTP_USERNAME=   # the username to use for authentication as well as the `from` username when sending emails
-MAIL_SMTP_PASSWORD=   # the password to use for authentication
-MAIL_FROM=            # the "From" address to use
-MAIL_DOMAIN=          # the domain name to use for email sending (i.e username@domain)
-```
-
-The SMTP server does not require STARTTLS. If STARTTLS is used, the app must be prepared to accept self-signed certs.
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `swaks` tool within the context of the app:
-```
-cloudron exec
-
-> swaks --server "${MAIL_SMTP_SERVER}" -p "${MAIL_SMTP_PORT}" --from "${MAIL_SMTP_USERNAME}@${MAIL_DOMAIN}" --body "Test mail from cloudron app at $(hostname -f)" --auth-user "${MAIL_SMTP_USERNAME}" --auth-password "${MAIL_SMTP_PASSWORD}"
-```
-
-## simpleauth
-
-Simple Auth can be used for authenticating users with a HTTP request. This method of authentication is targeted
-at applications, which for whatever reason can't use the ldap addon.
-The response contains an `accessToken` which can then be used to access the [Cloudron API](/references/api.html).
-
-Exported environment variables:
-```
-SIMPLE_AUTH_SERVER=    # the simple auth HTTP server
-SIMPLE_AUTH_PORT=      # the simple auth server port
-SIMPLE_AUTH_URL=       # the simple auth server URL. same as "http://SIMPLE_AUTH_SERVER:SIMPLE_AUTH_PORT
-SIMPLE_AUTH_CLIENT_ID  # a client id for identifying the request originator with the auth server
-```
-
-This addons provides two REST APIs:
-
-**POST /api/v1/login**
-
-Request JSON body:
-```
-{
-  "username": "<username> or <email>",
-  "password": "<password>"
-}
-```
-
-Response 200 with JSON body:
-```
-{
-  "accessToken": "<accessToken>",
-  "user": {
-    "id": "<userId>",
-    "username": "<username>",
-    "email": "<email>",
-    "admin": <admin boolean>,
-    "displayName": "<display name>"
-  }
-}
-```
-
-**GET /api/v1/logout**
-
-Request params:
-```
-?access_token=<accessToken>
-```
-
-Response 200 with JSON body:
-```
-{}
-```
-
-For debugging, [cloudron exec](https://www.npmjs.com/package/cloudron) can be used to run the `curl` tool within the context of the app:
-```
-cloudron exec
-
-> USERNAME=<enter username>
-
-> PASSWORD=<enter password>
-
-> PAYLOAD="{\"clientId\":\"${SIMPLE_AUTH_CLIENT_ID}\", \"username\":\"${USERNAME}\", \"password\":\"${PASSWORD}\"}"
-
-> curl -H "Content-Type: application/json" -X POST -d "${PAYLOAD}" "${SIMPLE_AUTH_ORIGIN}/api/v1/login"
-```
@@ -1,88 +0,0 @@
-# Introduction
-
-The Cloudron platform is designed to easily install and run web applications.
-The application architecture is designed to let the Cloudron take care of system 
-operations like updates, backups, firewalls, domain management, certificate management
-etc. This allows app developers to focus on their application logic instead of deployment.
-
-At a high level, an application provides an `image` and a `manifest`. The image is simply
-a docker image that is a bundle of the application code and it's dependencies.  The manifest 
-file specifies application runtime requirements like database type and authentication scheme.
-It also provides meta information for display purposes in the [Cloudron Store](/appstore.html) 
-like the title, icon and pricing.
-
-Web applications like blogs, wikis, password managers, code hosting, document editing, 
-file syncers, notes, email, forums are a natural fit for the Cloudron. Decentralized "social" 
-networks are also good app candidates for the Cloudron.
-
-# Image
-
-Application images are created using [Docker](https://www.docker.io). Docker provides a way
-to package (and containerize) the application as a filesystem which contains it's code, system libraries 
-and just about anything the app requires. This flexible approach allows the application to use just 
-about any language or framework.
-
-Application images are instantiated as `containers`. Cloudron can run one or more isolated instances
-of the same application as one or more containers.
-
-Containerizing your application provides the following benefits:
-* Apps run in the familiar environment that they were packaged for and can have libraries
-and packages that are independent of the host OS.
-* Containers isolate applications from one another.
-
-The [base image](/references/baseimage.html) is the parent of all app images.
-
-# Cloudron Manifest
-
-Each app provides a `CloudronManifest.json` that specifies information required for the
-`Cloudron Store` and for the installation of the image in the Cloudron.
-
-Information required for container installation includes:
-* List of `addons` like databases, caches, authentication mechanisms and file systems
-* The http port on which the container is listening for incoming requests
-* Additional TCP ports on which the application is listening to (for e.g., git, ssh,
-irc protocols)
-
-Information required for the Cloudron Store includes:
-* Unique App Id
-* Title
-* Version
-* Logo
-
-See the [manifest reference](/references/manifest.html) for more information.
-
-# Addons
-
-Addons are services like database, authentication, email, caching that are part of the
-Cloudron. Setup, provisioning, scaling and maintenance of addons is taken care of by the
-Cloudron.
-
-The fundamental idea behind addons is to allow resource sharing across applications.
-For example, a single MySQL server instance can be used across multiple apps. The Cloudron
-sets up addons in such a way that apps are isolated from each other.
-
-Addons are opt-in and must be specified in the Cloudron Manifest. When the app runs, environment
-variables contain the necessary information to access the addon. See the
-[addon reference](/references/addons.html) for more information.
-
-# Authentication
-
-The Cloudron provides a centralized dashboard to manage users, roles and permissions. Applications
-do not create or manage user credentials on their own and instead use one of the various
-authentication strategies provided by the Cloudron.
-
-Authentication strategies include OAuth 2.0, LDAP or Simple Auth. See the
-[Authentication Reference](/references/authentication.html) for more information.
-
-Authorizing users is application specific and it is only authentication that is delegated to the
-Cloudron.
-
-# Cloudron Store
-
-Cloudron Store provides a market place to publish and optionally monetize your app. Submitting to the
-Cloudron Store enables any Cloudron user to discover, purchase and install your application with
-a few clicks.
-
-# What next?
-
-* [Package an existing app for the Cloudron](/tutorials/packaging.html)
@@ -1,113 +0,0 @@
-# Overview
-
-Cloudron provides a centralized dashboard to manage users, roles and permissions. Applications
-do not create or manage user credentials on their own and instead use one of the various
-authentication strategies provided by the Cloudron.
-
-Note that authentication only identifies a user and does not indicate if the user is authorized
-to perform an action in the application. Authorizing users is application specific and must be
-implemented by the application.
-
-# Users & Admins
-
-Cloudron user management is intentionally very simple. The owner (first user) of the
-Cloudron is `admin` by default. The `admin` role allows one to install, uninstall and reconfigure
-applications on the Cloudron.
-
-A Cloudron `admin` can create one or more users. Cloudron users can login and use any of the installed
-apps in the Cloudron. In general, adding a cloudron user is akin to adding a person from one's family
-or organization or team because such users gain access to all apps in the Cloudron. Removing a user
-immediately revokes access from all apps.
-
-A Cloudron `admin` can give admin privileges to one or more Cloudron users.
-
-Each Cloudron user has an unique `username` and an `email`.
-
-# Strategies
-
-Cloudron provides multiple authentication strategies.
-
-* OAuth 2.0 provided by the [OAuth addon](/references/addons.html#oauth)
-* LDAP provided by the [LDAP addon](/references/addons.html#ldap)
-* Simple Auth provided by [Simple Auth addon](/references/addons.html#simpleauth)
-
-# Choosing a strategy
-
-Applications can be broadly categorized based on their user management as follows:
-
-* Multi-user aware
-  * Such apps have a full fledged user system and support multiple users and groups.
-  * These apps should use OAuth or LDAP.
-  * LDAP and OAuth APIs allow apps to detect if the user is a cloudron `admin`. Apps should use this flag
-    to show the application's admin panel for such users.
-
-
-* No user
-  * Such apps have no concept of logged-in user.
-  * The Cloudron provides a `website visibility` setting that allows a Cloudron admin to optionally
-    install an OAuth proxy in front of such applications. In such a case, a user visiting the website first
-    authenticates with the OAuth proxy and once authenticated is allowed into the application.
-  * When an OAuth proxy is installed, such applications can use the `X-Authenticated-User` header from the
-    [ICAP Extensions](https://tools.ietf.org/html/draft-stecher-icap-subid-00#section-3.4) de facto standard.
-    This value can be used for display purposes or creating meta data for a document.
-
-
-* Single user
-  * Such apps only have a single user who is usually also the `admin`.
-  * These apps can use Simple Auth or LDAP since they can authenticate users with a simple HTTP or LDAP request.
-  * Such apps _must_ set the `singleUser` property in the manifest which will restrict login to a single user
-    (configurable through the Cloudron's admin panel).
-
-# Public and Private apps
-
-`Private` apps display content only when they have a signed-in user. These apps can choose one of the
-authentication strategies listed above.
-
-`Public` apps display content to any visiting user (e.g a blog). These apps have a `login` url to allow
-the editors & admins to login. This path can be optionally set as the `configurePath` in the manifest for
-discoverability (for example, some blogs hide the login link).
-
-Some apps allow the user to choose `private` or `public` mode or some other combination. Such configuration
-is done at app install time and cannot be changed using a settings interface. It is tempting to show the user
-a configuration dialog on first installation to switch the modes. This, however, leads the user to believe that
-this configuration can be changed at any time later. In the case where this setting can be changed dynamically
-from a settings ui in the app, it's better to simply put some sensible defaults and let the user discover
-the settings. In the case where such settings cannot be changed dynamically, it is best to simply publish two
-separate apps in the Cloudron store each with a different configuration.
-
-# External User Registration
-
-Some apps allow external users to register and create accounts. For example, a public company chat that
-can invite anyone to join or a blog allowing registered commenters.
-
-Such applications must track Cloudron users and external registered users independently (for example, using a flag).
-As a thumb rule, apps must provide separate login buttons for each of the possible user sources. Such a design prevents
-external users from (inadvertently) spoofing Cloudron users.
-
-Naively handling user registration enables attacks of the following kind:
-* An external user named `foo` registers in the app.
-* A LDAP user named `foo` is later created on the Cloudron.
-* When a user named `foo` logs in, the app cannot determine the correct `foo` anymore. Making separate login buttons for each
-login source clears the confusion for both the user and the app.
-
-# Userid
-
-The preferred approach to track users in an application is a uuid or the Cloudron `username`.
-The `username` in Cloudron is unique and cannot be changed.
-
-Tracking users using `email` field is error prone since that may be changed by the user anytime.
-
-# Single Sign-on
-
-Single sign-on (SSO) is a property where a user logged in one application automatically logs into
-another application without having to re-enter his credentials. When applications implement the
-OAuth strategy, they automatically take part in Cloudron SSO. When a user signs in one application with
-OAuth, they will automatically log into any other app implementing OAuth.
-
-Conversely, signing off from one app, logs them off from all the apps.
-
-# Security
-
-The LDAP and Simple Auth strategies require the user to provide their plain text passwords to the
-application. This might be a cause of concern and app developers are thus highly encouraged to integrate
-with OAuth. OAuth also has the advantage of supporting Single Sign On.
@@ -1,94 +0,0 @@
-# Overview
-
-The application's Dockerfile must specify the FROM base image to be `cloudron/base:0.9.0`.
-
-The base image already contains most popular software packages including node, nginx, apache,
-ruby, PHP. Using the base image greatly reduces the size of app images.
-
-The goal of the base image is simply to provide pre-downloaded software packages. The packages
-are not configured in any way and it's up to the application to configure them as they choose.
-For example, while `apache` is installed, there are no meaningful site configurations that the
-application can use.
-
-# Packages
-
-The following packages are part of the base image. If you need another version, you will have to
-install it yourself.
-
-* Apache 2.4.18
-* Composer 1.2.0
-* Go 1.5.4, 1.6.3
-* Gunicorn 19.4.5
-* Java 1.8
-* Maven 3.3.9
-* Mongo 2.6.10
-* MySQL Client 5.7.13
-* nginx 1.10.0
-* Node 0.10.40, 0.12.7, 4.2.6, 4.4.7 (installed under `/usr/local/node-<version>`) [more information](#node-js)
-* Perl 5.22.1
-* PHP 7.0.8
-* Postgresql client 9.5.4
-* Python 2.7.12
-* Redis 3.0.6
-* Ruby 2.3.1
-* sqlite3 3.11.0
-* Supervisor 3.2.0
-* uwsgi 2.0.12
-
-# Inspecting the base image
-
-The base image can be inspected by installing [Docker](https://docs.docker.com/installation/).
-
-Once installed, pull down the base image locally using the following command:
-```
-    docker pull cloudron/base:0.9.0
-```
-
-To inspect the base image:
-```
-    docker run -ti cloudron/base:0.9.0 /bin/bash
-```
-
-*Note:* Please use `docker 1.9.0` or above to pull the base image. Doing otherwise results in a base
-image with an incorrect image id. The image id of `cloudron/base:0.9.0` is `d038af182821`.
-
-# The `cloudron` user
-
-The base image contains a user named `cloudron` that apps can use to run their app.
-
-It is good security practice to run apps as a non-previleged user.
-
-# Env vars
-
-The following environment variables are set as part of the application runtime.
-
-## API_ORIGIN
-
-API_ORIGIN is set to the HTTP(S) origin of this Cloudron's API. For example,
-`https://my-girish.cloudron.us`.
-
-## APP_DOMAIN
-
-APP_DOMAIN is set to the domain name of the application. For example, `app-girish.cloudron.us`.
-
-## APP_ORIGIN
-
-APP_ORIGIN is set to the HTTP(S) origin on the application. This is origin which the
-user can use to reach the application. For example, `https://app-girish.cloudron.us`.
-
-## CLOUDRON
-
-CLOUDRON is always set to '1'. This is useful to write Cloudron specific code.
-
-## WEBADMIN_ORIGIN
-
-WEBADMIN_ORIGIN is set to the HTTP(S) origin of the Cloudron's web admin. For example,
-`https://my-girish.cloudron.us`.
-
-# Node.js
-
-The base image comes pre-installed with various node.js versions.
-
-They can be used by adding `ENV PATH /usr/local/node-<version>/bin:$PATH`.
-
-See [Packages](/references/baseimage.html#packages) for available versions.
@@ -1,93 +0,0 @@
-# Best practices
-
-## Overview
-
-This document explains the spirit of what makes a Cloudron app.
-
-## No Setup
-
-Cloudron apps do not show a setup screen after installation and should choose reasonable
-defaults.
-
-Databases, email configuration should be automatically picked up using [addons](/references/addons.html).
-
-Admin role for the application can be detected dynamically using one of the [authentication](/references/authentication.html)
-strategies.
-
-## Image
-
-The Dockerfile contains a specification for building an application image.
-
-  * Install any required software packages in the Dockerfile.
-
-  * Create static configuration files in the Dockerfile.
-
-  * Create symlinks to dynamic configuration files under `/run` in the Dockerfile.
-
-  * Docker supports restarting processes natively. Should your application crash, it will
-    be restarted automatically. If your application is a single process, you do not require
-    any process manager.
-
-  * The main process must handle `SIGTERM` and forward it as required to child processes. `bash`
-    does not automatically forward signals to child processes. For this reason, when using a startup
-    shell script, remember to use `exec <app>` as the last line. Doing so will replace bash with your
-    program and allows your program to handle signals as required.
-
-  * Use `supervisor`, `pm2` or any of the other process managers if you application has more
-    then one component. This excludes web servers like apache, nginx which can already manage their
-    children by themselves. Be sure to pick a process manager that forwards signals to child processes.
-
-  * Disable auto updates for apps. Updates must be triggered through the Cloudron Store. This allows the admin
-    to manage updates and downtime in a central location (the Cloudron Webadmin).
-
-## File system
-
-The Cloudron runs the application image as read-only. The app can only write to the following directories:
-
-  * `/tmp` - use this for temporary files.
-
-  * `/run` - use this for runtime configration and any dynamic data.
-
-  * `/app/data` - When the `localstorage` addon is enabled, any data under this directory is automatically backed up.
-
-## Logging
-
-Cloudron applications stream their logs to stdout and stderr. In contrast to logging
-to files, this approach has many advantages:
-
-  * App does not need to rotate logs and the Cloudron takes care of managing logs
-  * App does not need special mechanism to release log file handles (on a log rotate)
-  * Integrates better with tooling like `cloudron cli`
-
-This document gives you some recipes for configuring popular libraries to log to stdout. See 
-[base image](/references/baseimage.html#configuring) on how to configure various libraries to log to stdout/stderr.
-
-
-## Memory
-
-By default, applications get 256MB RAM (including swap). This can be changed using the `memoryLimit` field in the manifest.
-
-Design your application runtime for concurrent use by 10s of users. The Cloudron is not designed for concurrent access by
-100s or 1000s of users.
-
-## Startup
-
-  * Apps must not present a post-installation screen on first run. It should be already pre-configured for
-    a specific purpose.
-
-  * Do not run as `root`. Apps can use the `cloudron` user which is part of the [base image](/references/baseimage.html)
-    for this purpose or create their own.
-
-  * When using the `localstorage` addon, the application must change the ownership of files in `/app/data` as desired using `chown`. This
-    is necessary because file permissions may not be correctly preserved across backup, restore, application and base image
-    updates.
-
-  * Addon information (mail, database) is exposed as environment variables. An application must use these values directly
-    and not cache them across restarts. If the variables are stored in a configuration file, then the configuration file
-    must be regenerated on every application start. This is usually done using a configuration template that is patched
-    on every startup.
-
-## Authentication
-
-Apps should integrate with one of the [authentication strategies](/references/authentication.html).
-This saves the user from having to manage separate set of users for different apps.
@@ -1,47 +0,0 @@
-# Cloudron Button
-
-The `Cloudron Button` allows anyone to install an application with
-the click of a button on their Cloudron.
-
-The button can be added to just about any website including the application's website
-and README.md files in GitHub repositories.
-
-## Prerequisites
-
-The `Cloudron Button` is intended to work only for applications that have been
-published on the Cloudron Store. The [basic tutorial](/tutorials/basic.html#publishing)
-gives an overview of how to package and publish your application for the
-Cloudron Store.
-
-## HTML Snippet
-
-```
-<img src="https://cloudron.io/img/button32.png" href="https://cloudron.io/button.html?app=<appid>">
-```
-
-_Note_: Replace `<appid>` with your application's id.
-
-## Markdown Snippet
-
-```
-[![Install](https://cloudron.io/img/button32.png)](https://cloudron.io/button.html?app=<appid>)
-```
-
-_Note_: Replace `<appid>` with your application's id.
-
-
-## Button Height
-
-The button may be used in different heights - 32, 48 and 64 pixels.
-
-[![Install](/img/button32.png)](https://cloudron.io/button.html?app=io.gogs.cloudronapp)
-
-[![Install](/img/button48.png)](https://cloudron.io/button.html?app=io.gogs.cloudronapp)
-
-[![Install](/img/button64.png)](https://cloudron.io/button.html?app=io.gogs.cloudronapp)
-
-or as SVG
-
-[![Install](/img/button.svg)](https://cloudron.io/button.html?app=io.gogs.cloudronapp)
-
-_Note_: Clicking the buttons above will install [Gogs](http://gogs.io/) on your Cloudron.
@@ -1,469 +0,0 @@
-# Overview
-
-Every Cloudron Application contains a `CloudronManifest.json`.
-
-The manifest contains two categories of information:
-
-* Information about displaying the app on the Cloudron Store. For example,
-  the title, author information, description etc
-
-* Information for installing the app on the Cloudron. This includes fields
-  like httpPort, tcpPorts.
-
-A CloudronManifest.json can **only** contain fields that are listed as part of this
-specification. The Cloudron Store and the Cloudron *may* reject applications that have
-extra fields.
-
-Here is an example manifest:
-
-```
-{
-  "id": "com.example.test",
-  "title": "Example Application",
-  "author": "Girish Ramakrishnan <girish@cloudron.io>",
-  "description": "This is an example app",
-  "tagline": "A great beginning",
-  "version": "0.0.1",
-  "healthCheckPath": "/",
-  "httpPort": 8000,
-  "addons": {
-    "localstorage": {}
-  },
-  "manifestVersion": 1,
-  "website": "https://www.example.com",
-  "contactEmail": "support@clourdon.io",
-  "icon": "file://icon.png",
-  "tags": [ "test", "collaboration" ],
-  "mediaLinks": [ "https://images.rapgenius.com/fd0175ef780e2feefb30055be9f2e022.520x343x1.jpg" ]
-}
-```
-
-# Fields
-
-## addons
-
-Type: object
-
-Required: no
-
-Allowed keys
-* [ldap](addons.html#ldap)
-* [localstorage](addons.html#localstorage)
-* [mongodb](addons.html#mongodb)
-* [mysql](addons.html#mysql)
-* [oauth](addons.html#oauth)
-* [postgresql](addons.html#postgresql)
-* [redis](addons.html#redis)
-* [sendmail](addons.html#sendmail)
-
-The `addons` object lists all the [addons](addons.html) and the addon configuration used by the application.
-
-Example:
-```
-  "addons": {
-    "localstorage": {},
-    "mongodb": {}
-  }
-```
-
-## author
-
-Type: string
-
-Required: yes
-
-The `author` field contains the name and email of the app developer (or company).
-
-Example:
-```
-  "author": "Cloudron UG <girish@cloudron.io>"
-```
-
-## changelog
-
-Type: markdown string
-
-Required: no (required for submitting to the Cloudron Store)
-
-The `changelog` field contains the changes in this version of the application. This string
-can be a markdown style bulleted list.
-
-Example:
-```
-  "changelog": "* Add support for IE8 \n* New logo"
-```
-
-## configurePath
-
-Type: path string
-
-Required: no
-
-The `configurePath` can be used to specify the absolute path to the configuration / settings
-page of the app. When this path is present, an absoluted URL is constructed from the app's
-install location this path and presented to the user in the configuration dialog of the app.
-
-This is useful for apps that have a main page which does not display a configuration / settings
-url (i.e) it's hidden for aesthetic reasons. For example, a blogging app like wordpress might
-keep the admin page url hidden in the main page. Setting the configurationPath makes the
-configuration url discoverable by the user.
-
-Example:
-```
-  "configurePath": "/wp-admin"
-```
-
-## contactEmail
-
-Type: email
-
-Required: yes
-
-The `contactEmail` field contains the email address that Cloudron users can contact for any
-bug reports and suggestions.
-
-Example:
-```
-  "contactEmail": "support@testapp.com"
-```
-
-## description
-
-Type: markdown string
-
-Required: yes
-
-The `description` field contains a detailed description of the app. This information is shown
-to the user when they install the app from the Cloudron Store.
-
-Example:
-```
-  "description": "This is a detailed description of this app."
-```
-
-A large `description` can be unweildy to manage and edit inside the CloudronManifest.json. For
-this reason, the `description` can also contain a file reference. The Cloudron CLI tool fills up
-the description from this file when publishing your application.
-
-Example:
-```
-  "description:": "file://DESCRIPTION.md"
-```
-
-## developmentMode
-
-Type: boolean
-
-Required: no
-
-Setting `developmentMode` to true disables readonly rootfs and the default memory limit. In addition,
-the application *pauses* on start and can be started manually using `cloudron exec`.  Note that you
-cannot submit an app to the store with this field turned on.
-
-This mode can be used to identify the files being modified by your application - often required to
-debug situations where your app does not run on a readonly rootfs. Run your app using `cloudron exec`
-and use `find / -mmin -30` to find file that have been changed or created in the last 30 minutes.
-
-## healthCheckPath
-
-Type: url path
-
-Required: yes
-
-The `healthCheckPath` field is used by the Cloudron Runtime to determine if your app is running and
-responsive. The app must return a 2xx HTTP status code as a response when this path is queried. In
-most cases, the default "/" will suffice but there might be cases where periodically querying "/"
-is an expensive operation. In addition, the app might want to use a specialized route should it
-want to perform some specialized internal checks.
-
-Example:
-```
-  "healthCheckPath": "/"
-```
-## httpPort
-
-Type: positive integer
-
-Required: yes
-
-The `httpPort` field contains the TCP port on which your app is listening for HTTP requests. This
-is the HTTP port the Cloudron will use to access your app internally.
-
-While not required, it is good practice to mark this port as `EXPOSE` in the Dockerfile.
-
-Cloudron Apps are containerized and thus two applications can listen on the same port. In reality,
-they are in different network namespaces and do not conflict with each other.
-
-Note that this port has to be HTTP and not HTTPS or any other non-HTTP protocol. HTTPS proxying is
-handled by the Cloudron platform (since it owns the certificates).
-
-Example:
-```
-  "httpPort": 8080
-```
-
-## icon
-
-Type: local image filename
-
-Required: no (required for submitting to the Cloudron Store)
-
-The `icon` field is used to display the application icon/logo in the Cloudron Store. Icons are expected
-to be square of size 256x256.
-
-```
-  "icon": "file://icon.png"
-```
-
-## id
-
-Type: reverse domain string
-
-Required: yes
-
-The `id` is a unique human friendly Cloudron Store id. This is similar to reverse domain string names used
-as java package names. The convention is to base the `id` based on a domain that you own.
-
-The Cloudron tooling allows you to build applications with any `id`. However, you will be unable to publish
-the application if the id is already in use by another application.
-
-```
-  "id": "io.cloudron.testapp"
-```
-
-## manifestVersion
-
-Type: integer
-
-Required: yes
-
-`manifestVersion` specifies the version of the manifest and is always set to 1.
-
-```
-  "manifestVersion": 1
-```
-
-## mediaLinks
-
-Type: array of urls
-
-Required: no (required for submitting to the Cloudron Store)
-
-The `mediaLinks` field contains an array of links that the Cloudron Store uses to display a slide show of pictures of the application.
-
-They have to be publicly reachable via `https` and should have an aspect ratio of 3 to 1.
-For example `600px by 200px` (with/height).
-
-```
-  "mediaLinks": [
-    "https://s3.amazonaws.com/cloudron-app-screenshots/org.owncloud.cloudronapp/556f6a1d82d5e27a7c4fca427ebe6386d373304f/2.jpg",
-    "https://images.rapgenius.com/fd0175ef780e2feefb30055be9f2e022.520x343x1.jpg"
-  ]
-```
-
-## memoryLimit
-
-Type: bytes (integer)
-
-Required: no
-
-The `memoryLimit` field is the maximum amount of memory (including swap) in bytes an app is allowed to consume before it
-gets killed and restarted.
-
-By default, all apps have a memoryLimit of 256MB. For example, to have a limit of 500MB,
-
-```
-  "memoryLimit": 524288000
-```
-
-## maxBoxVersion
-
-Type: semver string
-
-Required: no
-
-The `maxBoxVersion` field is the maximum box version that the app can possibly run on. Attempting to install the app on
-a box greater than `maxBoxVersion` will fail.
-
-This is useful when a new box release introduces features which are incompatible with the app. This situation is quite
-unlikely and it is recommended to leave this unset.
-
-## minBoxVersion
-
-Type: semver string
-
-Required: no
-
-The `minBoxVersion` field is the minimum box version that the app can possibly run on. Attempting to install the app on
-a box lesser than `minBoxVersion` will fail.
-
-This is useful when the app relies on features that are only available from a certain version of the box. If unset, the
-default value is `0.0.1`.
-
-## postInstallMessage
-
-Type: markdown string
-
-Required: no
-
-The `postInstallMessageField` is a message that is displayed to the user after an app is installed.
-
-The intended use of this field is to display some post installation steps that the user has to carry out to
-complete the installation. For example, displaying the default admin credentials and informing the user to
-to change it.
-
-## optionalSso
-
-Type: boolean
-
-Required: no
-
-The `optionalSso` field can be set to true for apps that can be installed optionally without using the Cloudron user management.
-
-This only applies if any Cloudron auth related addons are used. When set, the Cloudron will not inject the auth related addon environment variables.
-Any app startup scripts have to be able to deal with missing env variables in this case.
-
-## tagline
-
-Type: one-line string
-
-Required: no (required for submitting to the Cloudron Store)
-
-The `tagline` is used by the Cloudron Store to display a single line short description of the application.
-
-```
-  "tagline": "The very best note keeper"
-```
-
-## tags
-
-Type: Array of strings
-
-Required: no (required for submitting to the Cloudron Store)
-
-The `tags` are used by the Cloudron Store for filtering searches by keyword.
-
-```
-  "tags": [ "git", "version control", "scm" ]
-```
-
-## targetBoxVersion
-
-Type: semver string
-
-Required: no
-
-The `targetBoxVersion` field is the box version that the app was tested on. By definition, this version has to be greater
-than the `minBoxVersion`.
-
-The box uses this value to enable compatibility behavior of APIs. For example, an app sets the targetBoxVersion to 0.0.5
-and is published on the store. Later, box version 0.0.10 introduces a new feature that conflicts with how apps used
-to run in 0.0.5 (say SELinux was enabled for apps). When the box runs such an app, it ensures compatible behavior
-and will disable the SELinux feature for the app.
-
-If unspecified, this value defaults to `minBoxVersion`.
-
-## tcpPorts
-
-Type: object
-
-Required: no
-
-Syntax: Each key is the environment variable. Each value is an object containing `title`, `description` and `defaultValue`.
-An optional `containerPort` may be specified.
-
-The `tcpPorts` field provides information on the non-http TCP ports/services that your application is listening on. During
-installation, the user can decide how these ports are exposed from their Cloudron.
-
-For example, if the application runs an SSH server at port 29418, this information is listed here. At installation time,
-the user can decide any of the following:
-* Expose the port with the suggested `defaultValue` to the outside world. This will only work if no other app is being exposed at same port.
-* Provide an alternate value on which the port is to be exposed to outside world.
-* Disable the port/service.
-
-To illustrate, the application lists the ports as below:
-```
-  "tcpPorts": {
-    "SSH_PORT": {
-      "title": "SSH Port",
-      "description": "SSH Port over which repos can be pushed & pulled",
-      "defaultValue": 29418,
-      "containerPort": 22
-    }
-  },
-```
-
-In the above example:
-* `SSH_PORT` is an app specific environment variable. Only strings, numbers and _ (underscore) are allowed. The author has to ensure that they don't clash with platform profided variable names.
-
-* `title` is a short one line information about this port/service.
-
-* `description` is a multi line description about this port/service.
-
-* `defaultValue` is the recommended port value to be shown in the app installation UI.
-
-* `containerPort` is the port that the app is listening on (recall that each app has it's own networking namespace).
-
-In more detail:
-
-* If the user decides to disable the SSH service, this environment variable `SSH_PORT` is absent. Applications _must_ detect this on
-  start up and disable these services.
-
-* `SSH_PORT` is set to the value of the exposed port. Should the user choose to expose the SSH server on port 6000, then the
-  value of SSH_PORT is 6000.
-
-* `defaultValue` is **only** used for display purposes in the app installation UI.  This value is independent of the value
-   that the app is listening on. For example, the app can run an SSH server at port 22 but still recommend a value of 29418 to the user.
-
-* `containerPort` is the port that the app is listening on. The Cloudron runtime will _bridge_ the user chosen external port
-  with the app specific `containerPort`. Cloudron Apps are containerized and each app has it's own networking namespace.
-  As a result, different apps can have the same `containerPort` value because these values are namespaced.
-
-* The environment variable `SSH_PORT` may be used by the app to display external URLs. For example, the app might want to display
-  the SSH URL. In such a case, it would be incorrect to use the `containerPort` 22 or the `defaultValue` 29418 since this is not
-  the value chosen by the user.
-
-* `containerPort` is optional and can be omitted, in which case the bridged port numbers are the same internally and externally.
-  Some apps use the same variable (in their code) for listen port and user visible display strings. When packaging these apps,
-  it might be simpler to listen on `SSH_PORT` internally. In such cases, the app can omit the `containerPort` value and should
-  instead reconfigure itself to listen internally on `SSH_PORT` on each start up.
-
-## title
-
-Type: string
-
-Required: yes
-
-The `title` is the primary application title displayed on the Cloudron Store.
-
-Example:
-```
-  "title": "Gitlab"
-```
-
-## version
-
-Type: semver string
-
-Required: yes
-
-The `version` field specifies a [semver](http://semver.org/) string. The version is used by the Cloudron to compare versions and to
-determine if an update is available.
-
-Example:
-```
-  "version": "1.1.0"
-```
-
-## website
-
-Type: url
-
-Required: yes
-
-The `website` field is a URL where the user can read more about the application.
-
-Example:
-```
-  "website": "https://example.com/myapp"
-```
@@ -1,61 +0,0 @@
-# Configuration Recipes
-
-## nginx
-
-`nginx` is often used as a reverse proxy in front of the application, to dispatch to different backend programs based on the request route or other characteristics. In such a case it is recommended to run nginx and the application through a process manager like `supervisor`.
-
-Example nginx supervisor configuration file:
-```
-[program:nginx]
-directory=/tmp
-command=/usr/sbin/nginx -g "daemon off;"
-user=root
-autostart=true
-autorestart=true
-stdout_logfile=/var/log/supervisor/%(program_name)s.log
-stderr_logfile=/var/log/supervisor/%(program_name)s.log
-```
-
-The nginx configuration, provided with the base image, can be used by adding an application specific config file under `/etc/nginx/sites-enabled/` when building the docker image.
-
-```
-ADD <app config file> /etc/nginx/sites-enabled/<app config file>
-```
-
-Since the base image nginx configuration is unpatched from the ubuntu package, the application configuration has to ensure nginx is using `/run/` instead of `/var/lib/nginx/` to support the read-only filesystem nature of a Cloudron application.
-
-Example nginx app config file:
-```
-client_body_temp_path /run/client_body;
-proxy_temp_path /run/proxy_temp;
-fastcgi_temp_path /run/fastcgi_temp;
-scgi_temp_path /run/scgi_temp;
-uwsgi_temp_path /run/uwsgi_temp;
-
-server {
-  listen 8000;
-
-  root /app/code/dist;
-
-  location /api/v1/ {
-    proxy_pass http://127.0.0.1:8001;
-    proxy_http_version 1.1;
-    proxy_set_header Upgrade $http_upgrade;
-    proxy_set_header Connection "upgrade";
-    proxy_read_timeout 86400;
-  }
-}
-
-```
-
-## supervisor
-
-Use this in the program's config:
-
-```
-[program:app]
-stdout_logfile=/dev/stdout
-stdout_logfile_maxbytes=0
-stderr_logfile=/dev/stderr
-stderr_logfile_maxbytes=0
-```
@@ -1,383 +0,0 @@
-# Overview
-
-The Cloudron platform can be installed on public cloud servers from EC2, Digital Ocean, Hetzner,
-Linode, OVH, Scaleway, Vultr etc. Running Cloudron on a home server or company intranet is work
-in progress.
-
-If you run into any trouble following this guide, ask us at our [chat](https://chat.cloudron.io).
-
-# Understand
-
-Before installing the Cloudron, it is helpful to understand Cloudron's design. The Cloudron
-intends to make self-hosting effortless. It takes care of updates, backups, firewall, dns setup,
-certificate management etc. All app and user configuration is carried out using the web interface.
-
-This approach to self-hosting means that the Cloudron takes complete ownership of the server and
-only tracks changes that were made via the web interface. Any external changes made to the server
-(i.e other than via the Cloudron web interface or API) may be lost across updates.
-
-The Cloudron requires a domain name when it is installed. Apps are installed into subdomains.
-The `my` subdomain is special and is the location of the Cloudron web interface. For this to
-work, the Cloudron requires a way to programmatically configure the DNS entries of the domain.
-Note that the Cloudron will never overwrite _existing_ DNS entries and refuse to install
-apps on existing subdomains.
-
-# CLI Tool
-
-The [Cloudron tool](https://git.cloudron.io/cloudron/cloudron-cli) is useful for managing
-a Cloudron. <b class="text-danger">The Cloudron CLI tool has to be run on a Laptop or PC</b>
-
-## Linux & OS X
-
-Installing the CLI tool requires node.js and npm. The CLI tool can be installed using the following command:
-
-```
-npm install -g cloudron
-```
-
-Depending on your setup, you may need to run this as root.
-
-On OS X, it is known to work with the `openssl` package from homebrew.
-
-See [#14](https://git.cloudron.io/cloudron/cloudron-cli/issues/14) for more information.
-
-## Windows
-
-The CLI tool does not work on Windows. Please contact us on our [chat](https://chat.cloudron.io) if you want to help with Windows support.
-
-# Provider
-
-DigitalOcean and EC2 (Amazon Web Services) are frequently tested by us.
-
-Please use the below links to support us with referrals:
-* [Amazon EC2](https://aws.amazon.com/ec2/)
-* [DigitalOcean](https://m.do.co/c/933831d60a1e)
-
-In addition to those, the Cloudron community has successfully installed the platform on those providers:
-* [Amazon Lightsail](https://amazonlightsail.com/)
-* [hosttech](https://www.hosttech.ch/?promocode=53619290)
-* [Linode](https://www.linode.com/?r=f68d816692c49141e91dd4cef3305da457ac0f75)
-* [OVH](https://www.ovh.com/)
-* [Scaleway](https://www.scaleway.com/)
-* [So you Start](https://www.soyoustart.com/)
-* [Vultr](http://www.vultr.com/?ref=7063201)
-
-Please let us know if any of them requires tweaks or adjustments.
-
-# Installing
-
-## Choose Domain
-
-A domain name is required when installing the Cloudron. Currently, only Second Level Domains
-are supported. For example, `example.com`, `example.co.uk` will work fine. Choosing a domain
-name at any other level like `cloudron.example.com` will not work.
-
-The domain name must use one of the following name servers:
-* AWS Route 53
-* Digital Ocean
-* Wildcard - If your domain does not use any of the name servers above, you can manually add
-a wildcard (`*`) DNS entry.
-
-You will have to provide the DNS API credentials after you complete the installation.
-
-## Create server
-
-Create an `Ubuntu 16.04 (Xenial)` server with at-least `1gb` RAM. Do not make any changes
-to vanilla ubuntu. Be sure to allocate a static IPv4 address for your server.
-
-### Linode
-
-Since Linode does not manage SSH keys, be sure to add the public key to
-`/root/.ssh/authorized_keys`.
-
-### Scaleway
-
-Use the [boot script](https://github.com/scaleway-community/scaleway-docker/issues/2) to
-enable memory accouting.
-
-## Setup `my` subdomain
-
-The Cloudron web interface is installed at the `my` subdomain of your domain.
-Add a `A` DNS record for the `my` subdomain with the IP of the server created
-above. Doing this will allow the Cloudron to start up with a valid TLS certificate.
-
-## Run setup
-
-SSH into your server and run the following commands:
-
-```
-wget https://cloudron.io/cloudron-setup
-chmod +x cloudron-setup
-./cloudron-setup --provider <digitalocean|ec2|generic|scaleway>
-```
-
-The setup will take around 10-15 minutes.
-
-**cloudron-setup** takes the following arguments:
-
-* `--provider` is the name of your VPS provider. If the name is not on the list, simply
-choose `generic`. In most cases, the `generic` provider mostly will work fine.
-If the Cloudron does not complete initialization, it may mean that
-we have to add some vendor specific quirks. Please open a
-[bug report](https://git.cloudron.io/cloudron/box/issues) in that case.
-
-Optional arguments for installation:
-
-* `--domain` is the domain name in which apps are installed. Currently, only Second Level
-Domains are supported. For example, `example.com`, `example.co.uk`, `example.rocks` will
-work fine. Choosing a domain name at any other level like `cloudron.example.com` will not
-work.
-
-* `--tls-provider` is the name of the SSL/TLS certificate backend. Defaults to Let's encrypt.
-Specifying `fallback` will setup the Cloudron to use the fallback wildcard certificate.
-Initially a self-signed one is provided, which can be overwritten later in the admin interface.
-This may be useful for non-public installations.
-
-Optional arguments used for update and restore:
-
-* `--version` is the version of Cloudron to install. By default, the setup script installs
-the latest version. You can set this to an older version when restoring a Cloudron from a backup.
-
-* `--restore-url` is a backup URL to restore from.
-
-## Finish setup
-
-Once the setup script completes, the server will reboot, then visit your server by its IP address to complete the installation.
-
-Please note the following:
-
-1. The website will show a certificate warning, which needs to be accepted. Then a DNS setup page will be shown, which allows to setup
-the Cloudron with a domain.
-
-2. If you see a login screen, instead of a setup screen, it means that someone else got to your Cloudron first and set it up
-already! In this unlikely case, simply delete the server and start over.
-
-Once the setup is done, you can access the admin page in the future at `https://my.<domain>`.
-
-## DNS
-
-Cloudron has to be given the API credentials for configuring your domain under `Certs & Domains`
-in the web UI.
-
-### Route 53
-
-Create root or IAM credentials and choose `Route 53` as the DNS provider.
-
-* For root credentials:
-  * In AWS Console, under your name in the menu bar, click `Security Credentials`
-  * Click on `Access Keys` and create a key pair.
-* For IAM credentials:
-    * You can use the following policy to create IAM credentials:
-
-```
-{
-    "Version": "2012-10-17",
-    "Statement": [
-        {
-            "Effect": "Allow",
-            "Action": "route53:*",
-            "Resource": [
-                "arn:aws:route53:::hostedzone/<hosted zone id>"
-            ]
-        },
-        {
-            "Effect": "Allow",
-            "Action": [
-                "route53:ListHostedZones",
-                "route53:GetChange"
-            ],
-            "Resource": [
-                "*"
-            ]
-        }
-    ]
-}
-```
-
-### Digital Ocean
-
-Create an API token with read+write access and choose `Digital Ocean` as the DNS provider.
-
-### Other
-
-If your domain *does not* use Route 53 or Digital Ocean, setup a wildcard (`*`) DNS `A` record that points to the
-IP of the server created above. If your DNS provider has an API, please open an
-[issue](https://git.cloudron.io/cloudron/box/issues) and we may be able to support it.
-
-## Backups
-
-The Cloudron creates encrypted backups once a day. Each app is backed up independently and these
-backups have the prefix `app_`. The platform state is backed up independently with the
-prefix `box_`.
-
-By default, backups reside in `/var/backups`. Please note that having backups reside in the same
-physical machine as the Cloudron server instance is dangerous and it must be changed to
-an external storage location like `S3` as soon as possible.
-
-### Amazon S3
-
-Provide S3 backup credentials in the `Settings` page and leave the endpoint field empty.
-
-Create a bucket in S3 (You have to have an account at [AWS](https://aws.amazon.com/)). The bucket can be setup to periodically delete old backups by
-adding a lifecycle rule using the AWS console. S3 supports both permanent deletion
-or moving objects to the cheaper Glacier storage class based on an age attribute.
-With the current daily backup schedule a setting of two days should be sufficient
-for most use-cases.
-
-* For root credentials:
-    * In AWS Console, under your name in the menu bar, click `Security Credentials`
-    * Click on `Access Keys` and create a key pair.
-* For IAM credentials:
-* You can use the following policy to create IAM credentials:
-
-```
-{
-    "Version": "2012-10-17",
-    "Statement": [
-        {
-            "Effect": "Allow",
-            "Action": "s3:*",
-            "Resource": [
-                "arn:aws:s3:::<your bucket name>",
-                "arn:aws:s3:::<your bucket name>/*"
-            ]
-        }
-    ]
-}
-```
-
-### Minio S3
-
-[Minio](https://minio.io/) is a distributed object storage server, providing the same API as Amazon S3.
-Since Cloudron supports S3, any API compatible solution should be supported as well, if this is not the case, let us know.
-
-Minio can be setup, by following the [installation instructions](https://docs.minio.io/) on any server, which is reachable by the Cloudron.
-Do not setup Minio on the same server as the Cloudron, this will inevitably result in data loss, if backups are stored on the same instance.
-
-Once setup, minio will print the necessary information, like login credentials, region and endpoints in its logs.
-
-```
-$ ./minio server ./storage
-
-Endpoint:  http://192.168.10.113:9000  http://127.0.0.1:9000
-AccessKey: GFAWYNJEY7PUSLTHYHT6
-SecretKey: /fEWk66E7GsPnzE1gohqKDovaytLcxhr0tNWnv3U
-Region:    us-east-1
-```
-
-First create a new bucket for the backups, using the minio commandline tools or the webinterface. The bucket has to have **read and write** permissions.
-
-The information to be copied to the Cloudron's backup settings form may look similar to:
-
-<img src="/docs/img/minio_backup_config.png" class="shadow"><br/>
-
-
-# Email
-
-Cloudron has a built-in email server. By default, it only sends out email on behalf of apps
-(for example, password reset or notification). You can enable the email server for sending
-and receiving mail on the `settings` page. This feature is only available if you have setup
-a DNS provider like Digital Ocean or Route53.
-
-Your server's IP plays a big role in how emails from our Cloudron get handled. Spammers
-frequently abuse public IP addresses and as a result your Cloudron might possibly start
-out with a bad reputation. The good news is that most IP based blacklisting services cool
-down over time. The Cloudron sets up DNS entries for SPF, DKIM, DMARC automatically and
-reputation should be easy to get back.
-
-## Checklist
-
-* Once your Cloudron is ready, setup a Reverse DNS PTR record to be setup for the `my` subdomain.
-
-    * AWS/EC2 - Fill the PTR [request form](https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request.
-
-    * Digital Ocean - Digital Ocean sets up a PTR record based on the droplet's name. So, simply rename
-    your droplet to `my.<domain>`. Note that some new Digital Ocean accounts have [port 25 blocked](https://www.digitalocean.com/community/questions/port-25-smtp-external-access).
-
-    * Scaleway - Edit your security group to allow email. You can also set a PTR record on the interface with your
-    `my.<domain>`.
-
-* Check if your IP is listed in any DNSBL list [here](http://multirbl.valli.org/). In most cases,
-you can apply for removal of your IP by filling out a form at the DNSBL manager site.
-
-* Finally, check your spam score at [mail-tester.com](https://www.mail-tester.com/). The Cloudron
-should get 100%, if not please let us know.
-
-# Updates
-
-Apps installed from the Cloudron Store are automatically updated every night.
-
-The Cloudron platform itself updates in two ways: update or upgrade.
-
-### Update
-
-An **update** is applied onto the running server instance. Such updates are performed
-every night. You can also use the Cloudron UI to initiate an update immediately.
-
-The Cloudron will always make a complete backup before attempting an update. In the unlikely
-case an update fails, it can be [restored](/references/selfhosting.html#restore).
-
-### Upgrade
-
-An **upgrade** requires a new OS image. This process involves creating a new server from scratch
-with the latest code and restoring it from the last backup.
-
-To upgrade follow these steps closely:
-
-* Create a new backup - `cloudron machine backup create <domain>`
-
-* List the latest backup - `cloudron machine backup list <domain>`
-
-* Make the backup available for the new cloudron instance:
-
-  * `S3` - When storing backup ins S3, make the latest box backup public - files starting with `box_` (from v0.94.0) or `backup_`. This can be done from the AWS S3 console as seen here:
-
-    <img src="/docs/img/aws_backup_public.png" class="shadow haze"><br/>
-
-    Copy the new public URL of the latest backup for use as the `--restore-url` below.
-
-    <img src="/docs/img/aws_backup_link.png" class="shadow haze"><br/>
-
-  * `File system` - When storing backups in `/var/backups`, you have to make the box and the app backups available to the new Cloudron instance's `/var/backups`. This can be achieved in a variety of ways depending on the situation: like scp'ing the backup files to the machine before installation, mounting the external backup hard drive into the new Cloudron's `/var/backup` OR downloading a copy of the backup using `cloudron machine backup download <domain>` and uploading them to the new machine. After doing so, pass `file:///var/backups/<path to box backup>` as the `--restore-url` below.
-
-* Create a new Cloudron by following the [installing](/references/selfhosting.html#installing) section.
-  When running the setup script, pass in the `--encryption-key` and `--restore-url` flags.
-  The `--encryption-key` is the backup encryption key. It can be displayed with `cloudron machine info`
-
-Similar to the initial installation, a Cloudron upgrade looks like:
-```
-$ ssh root@newserverip
-> wget https://cloudron.io/cloudron-setup
-> chmod +x cloudron-setup
-> ./cloudron-setup --domain <domain> --provider <digitalocean|ec2|generic|scaleway> --encryption-key <key> --restore-url <publicS3Url>
-```
-
- * Finally, once you see the newest version being displayed in your Cloudron webinterface, you can safely delete the old server instance.
-
-# Restore
-
-To restore a Cloudron from a specific backup:
-
-* Select the backup - `cloudron machine backup list <domain>`
-
-* Make the box backup public (this can be done from the S3 console). Also, copy the URL of
-  the backup for use as the `restore-url` below.
-
-* Create a new Cloudron by following the [installing](/references/selfhosting.html#installing) section.
-  When running the setup script, pass in the `version`, `restore-key` and `restore-url` flags.
-  The `version` field is the version of the Cloudron that the backup corresponds to (it is embedded
-  in the backup file name).
-
-* Make the box backup private, once the upgrade is complete.
-
-# Debug
-
-You can SSH into your Cloudron and collect logs:
-
-* `journalctl -a -u box` to get debug output of box related code.
-* `docker ps` will give you the list of containers. The addon containers are named as `mail`, `postgresql`,
-   `mysql` etc. If you want to get a specific container's log output, `journalctl -a CONTAINER_ID=<container_id>`.
-
-# Help
-
-If you run into any problems, join us at our [chat](https://chat.cloudron.io) or [email us](mailto:support@cloudron.io).
@@ -1,354 +0,0 @@
-# Introduction
-
-The Cloudron is the best platform self-hosting web applications on your server. You
-can easily install apps on it, add users, manage access restriction and keep your
-server and apps updated with no effort.
-
-You might wonder that there are so many 1-click app solutions out there and what is so special
-about Cloudron? As the name implies, 1-click installers simply install code into a server
-and leave it at that. There's so much more to do:
-
-1. Configure a domain to point to your server
-2. Setup SSL certificates and renew them periodically
-3. Ensure apps are backed up correctly
-4. Ensure apps are uptodate and secure
-5. Have a mechanism to quickly restore apps from a backup
-6. Manage users across all your apps
-7. Get alerts and notifications about the status of apps
-
-... and so on ...
-
-We made the Cloudron to dramatically lower the bar for people to run apps on servers. Just provide
-a domain name, install apps and add users. All the server management tasks listed above is
-completely automated.
-
-If you want to learn more about the secret sauce that makes the Cloudron, please read our
-[architecture overview](/references/architecture.html).
-
-# Use cases
-
-Here are some of the apps you can run on a Cloudron:
-
-* RSS Reader
-* Chat, IRC, Jabber servers
-* Public forum
-* Blog
-* File syncing and sharing
-* Code hosting
-* Email
-
-Our list of apps is growing everyday, so be sure to [follow us on twitter](https://twitter.com/cloudron_io).
-
-# Activation
-
-When you first create the Cloudron, the setup wizard will ask you to setup an administrator
-account. Don't worry, a Cloudron adminstrator doesn't need to know anything about maintaining
-a server! It's the whole reason why we made the Cloudron. Being a Cloudron administrator is
-more analagous to being the owner of a smartphone. You can always add more administrators to
-the Cloudron from the `Users` menu item.
-
-<img src="/docs/img/webadmin_domain.png" class="shadow">
-
-The Cloudron administration page is located at the `my` subdomain. You might want to bookmark
-this link!
-
-# Apps
-
-## Installation
-
-You can install apps on the Cloudron by choosing the `App Store` menu item. Use the 'Search' bar
-to search for apps.
-
-Clicking on app gives you information about the app.
-
-<img src="/docs/img/app_info.png" class="shadow">
-
-Clicking the `Install` button will show an install dialog like below:
-
-<img src="/docs/img/app_install.png" class="shadow">
-
-The `Location` field is the subdomain in which your app will be installed. For example, if you use the
-`mail` location for your web mail client, then it will be accessible at `mail.<domain>`.
-
-Tip: You can access the apps directly on your browser using `mail.<domain>`. You don't have to
-visit the Cloudron administration panel.
-
-`Access control` specifies who can access this app.
-
-* `Every Cloudron user` - Any user in your Cloudron can access the app. Initially, you are the only
-   user in your Cloudron. Unless you explicitly invite others, nobody else can access these apps.
-   Note that the term 'access' depends on the app. For a blog, this means that nobody can post new
-   blog posts (but anybody can view them). For a chat server, this might mean that nobody can access
-   your chat server.
-
-* `Restrict to groups` - Only users in the groups can access the app.
-
-## Updates
-
-All your apps automatically update as and when the application author releases an update. The Cloudron
-will attempt to update around midnight of your timezone.
-
-Some app updates are not automatic. This can happen if a new version of the app has removed some features
-that you were relying on. In such a case, the update has to be manually approved. This is simply a matter
-of clicking the `Update` button (the green star) after you read about the changes.
-
-<img src="/docs/img/app_update.png" class="shadow">
-
-## Backups
-
-<i>If you self-host, please refer to the [self-hosting documentation](/references/selfhosting.html#backups) for backups.</i>
-
-All apps are automatically backed up every day. Backups are stored encrypted in Amazon S3. You don't have
-to do anything about it. The [Cloudron CLI](https://git.cloudron.io/cloudron/cloudron-cli) tool can be used
-to download application backups.
-
-## Configuration
-
-Apps can be reconfigured using the `Configure` button.
-
-<img src="/docs/img/app_configure_button.png" class="shadow">
-
-Click on the wrench button will bring up the configure dialog.
-
-<img src="/docs/img/app_configure.png" class="shadow">
-
-You can do the following:
-* Change the location to move the app to another subdomain. Say, you want to move your blog from `blog` to `about`.
-* Change who can access the app.
-
-Changing an app's configuration has a small downtime (usually around a minute).
-
-## Restore
-
-Apps can be restored to a previous backup by clicking on the `Restore` button.
-
-<img src="/docs/img/app_restore_button.png" class="shadow">
-
-Note that restoring previous data might also restore the previous version of the software. For example, you might
-be currently using Version 5 of the app. If you restore to a backup that was made with Version 3 of the app, then the restore
-operation will install Version 3 of the app. This is because the latest version may not be able to handle old data.
-
-## Uninstall
-
-You can uninstall an app by clicking the `Uninstall` button.
-
-<img src="/docs/img/app_uninstall_button.png" class="shadow">
-
-Note that all data associated with the app will be immediately removed from the Cloudron. App data might still
-persist in your old backups and the [CLI tool](https://git.cloudron.io/cloudron/cloudron-cli) provides a way to
-restore from those old backups should it be required.
-
-## Embedding Apps
-
-It is possible to embed Cloudron apps into other websites. By default, this is disabled to prevent
-[Clickjacking](https://cloudron.io/blog/2016-07-15-site-embedding.html).
-
-You can set a website that is allowed to embed your Cloudron app using the app's [Configure dialog](#configuration).
-Click on 'Show Advanced Settings...' and enter the embedder website name.
-
-# Custom domain
-
-When you create a Cloudron from cloudron.io, we provide a subdomain under `cloudron.me` like `girish.cloudron.me`.
-Apps are available under that subdomain using a hyphenated name like `blog-girish.cloudron.me`.
-
-Domain names are a thing of pride and the Cloudron makes it easy to make your apps accessible from memorable locations like `blog.girish.in`.
-
-## Single app on a custom domain
-
-This approach is applicable if you desire that only a single app be accessing from a custom
-domain. For this, open the app's configure dialog and choose `External Domain` in the location dropdown.
-
-<img src="/docs/img/app_external_domain.png" class="shadow">
-
-This dialog will suggest you to add a `CNAME` record. Once you setup a CNAME record with your DNS provider,
-the app will be accessible from that external domain.
-
-## Entire Cloudron on a custom domain
-
-This approach is applicable if you want all your apps to be accessible from subdomains of your custom domain.
-For example, `blog.girish.in`, `notes.girish.in`, `owncloud.girish.in`, `mail.girish.in` and so on. This
-approach is also the only way that the Cloudron supports for sending and receiving emails from your domain.
-
-For this, go to the 'Domains & Certs' menu item.
-
-<img src="/docs/img/custom_domain_menu.png" class="shadow">
-
-Change the domain name to your custom domain. Currently, we require that your domain be hosted on AWS Route53.
-
-<img src="/docs/img/custom_domain_change.png" class="shadow">
-
-Moving to a custom domain will retain all your apps and data and will take around 15 minutes. If you require assistance with another provider,
-<a href="mailto:support@cloudron.io">just let us know</a>.
-
-# User management
-
-## Users
-
-You can invite new users (friends, family, colleagues) with their email address from the `Users` menu. They will
-receive an invite to sign up with your Cloudron. They can now access the apps that you have given them access
-to.
-
-<img src="/docs/img/users.png" class="shadow">
-
-To remove a user, simply remove them from the list. Note that the removed user cannot access any app anymore.
-
-## Administrators
-
-A Cloudron administrator is a special right given to an existing Cloudron user allowing them to manage
-apps and users. To make an existing user an administator, click the edit (pencil) button corresponding to
-the user and check the `Allow this user to manage apps, groups and other users` checkbox.
-
-<img src="/docs/img/administrator.png" class="shadow">
-
-## Groups
-
-Groups provide a convenient way to group users. It's purpose is two-fold:
-
-* You can assign one or more groups to apps to restrict who can access for an app.
-* Each group is a mailing list (forwarding address) constituting of it's members.
-
-You can create a group by using the `Groups` menu item.
-
-<img src="/docs/img/groups.png" class="shadow">
-
-To set the access restriction use the app's configure dialog.
-
-<img src="/docs/img/app_access_control.png" class="shadow">
-
-You can now send mails to `groupname@<domain>` to address all the group members.
-
-# Login
-
-## Cloudron admin
-
-The Cloudron admin page is always located at the `my` subdomain of your Cloudron domain. For custom domains,
-this will be like `my.girish.in`. For domains from cloudron.io, this will be like `my-girish.cloudron.me`.
-
-## Apps (single sign-on)
-
-An important feature of the Cloudron is Single Sign-On. You use the same username & password for logging in
-to all your apps. No more having to manage separate set of credentials for each service!
-
-## Single user apps
-
-Some apps only work with a single user. For example, a notes app might allow only a single user to login and add
-notes. For such apps, you will be prompted during installation to select the single user who can access the app.
-
-<img src="/docs/img/app_single_user.png" class="shadow">
-
-If you want multiple users to use the app independently, simply install the app multiple times to different locations.
-
-# Email
-
-The Cloudron has a built-in email server. The primary email address is the same as the username. Emails can be sent
-and received from `<username>@<domain>`. The Cloudron does not allow masquerading - one user cannot send email
-pretending to be another user.
-
-## Enabling Email
-
-By default, Cloudron's email server only allows apps to send email. To enable users to send and receive email,
-turn on the option under `Settings`. Turning on this option also allows apps to _receive_ email.
-
-Once email is enabled, the Cloudron will keep the the `MX` DNS record updated.
-
-<img src="/docs/img/enable_email.png" class="shadow">
-
-## Receiving email using IMAP
-
-Use the following settings to receive email.
-
-  * Server Name - Use the `my` subdomain of your Cloudron
-  * Port - 993
-  * Connection Security - TLS
-  * Username/password - Same as your Cloudron credentials
-
-## Sending email using SMTP
-
-Use the following settings to send email.
-
-  * Server Name - Use the `my` subdomain of your Cloudron
-  * Port - 587
-  * Connection Security - STARTTLS
-  * Username/password - Same as your Cloudron credentials
-
-## Email filters using Sieve
-
-Use the following settings to setup email filtering users via Manage Sieve.
-
-  * Server Name - Use the `my` subdomain of your Cloudron
-  * Port - 4190
-  * Connection Security - TLS
-  * Username/password - Same as your Cloudron credentials
-
-The [Rainloop](https://cloudron.io/appstore.html?app=net.rainloop.cloudronapp) and [Roundcube](https://cloudron.io/appstore.html?app=net.roundcube.cloudronapp)
-apps are already pre-configured to use the above settings.
-
-## Aliases
-
-You can configure one or more aliases alongside the primary email address of each user. You can set aliases by editing the
-user's settings, available behind the edit button in the user listing. Note that aliases cannot conflict with existing user names.
-
-<img src="/docs/img/email_alias.png" class="shadow">
-
-Currently, it is not possible to login using the alias for SMTP/IMAP/Sieve services. Instead, add the alias as an identity in
-your mail client but login using the Cloudron credentials.
-
-## Subaddresses
-
-Emails addressed to `<username>+tag@<domain>` will be delivered to the `username` mailbox. You can use this feature to give out emails of the form
-`username+kayak@<domain>`, `username+aws@<domain>` and so on and have them all delivered to your mailbox.
-
-## Forwarding addresses
-
-Each group on the Cloudron is also a forwarding address. Mails can be addressed to `group@<domain>` and the mail will
-be sent to each user who is part of the group.
-
-## Marking Spam
-
-The spam detection agent on the Cloudron requires training to identify spam. To do this, simply move your junk mails
-to a pre-created folder named `Spam`. Most mail clients have a Junk or Spam button which does this automatically.
-
-# Graphs
-
-The Graphs view shows an overview of the disk and memory usage on your Cloudron.
-
-<img src="/docs/img/graphs.png" class="shadow">
-
-The `Disk Usage` graph shows you how much disk space you have left. Note that the Cloudron will
-send the Cloudron admins an email notification when the disk is ~90% full.
-
-The `Apps` Memory graph shows the memory consumed by each installed app. You can click on each segment
-on the graph to see the memory consumption over time in the chart below it.
-
-The `System` Memory graph shows the overall memory consumption on the entire Cloudron. If you see
-the Free memory < 50MB frequently, you should consider upgrading to a Cloudron with more memory.
-
-# Activity log
-
-The `Activity` view shows the activity on your Cloudron. It includes information about who is using
-the apps on your Cloudron and also tracks configuration changes.
-
-<img src="/docs/img/activity.png" class="shadow">
-
-# Domains and SSL Certificates
-
-All apps on the Cloudron can only be reached by `https`. The Cloudron automatically installs and
-renews certificates for your apps as needed. Should installation of certificate fail for reasons
-beyond it's control, Cloudron admins will get a notification about it.
-
-# API Access
-
-All the operations listed in this manual like installing app, configuring users and groups, are
-completely programmable with a [REST API](/references/api.html).
-
-# Moving to a larger Cloudron
-
-When using a Cloudron from cloudron.io, it is easy to migrate your apps and data to a bigger server.
-In the `Settings` page, you can change the plan.
-
-<insert picture>
-
-# Command line tool
-
-If you are a software developer or a sysadmin, the Cloudron comes with a CLI tool that can be
-used to develop custom apps for the Cloudron. Read more about it [here](https://git.cloudron.io/cloudron/cloudron-cli).
@@ -1,621 +0,0 @@
-# Overview
-
-This tutorial provides an introduction to developing applications
-for the Cloudron using node.js.
-
-# Installation
-
-## Install CLI tool
-
-The Cloudron CLI tool allows you to install, configure and test apps on your Cloudron.
-
-Installing the CLI tool requires [node.js](https://nodejs.org/) and
-[npm](https://www.npmjs.com/). You can then install the CLI tool using the following
-command:
-
-```
-    sudo npm install -g cloudron
-```
-
-Note: Depending on your setup, you can run the above command without `sudo`.
-
-## Testing your installation
-
-The `cloudron` command should now be available in your path.
-
-Let's login to the Cloudron as follows:
-
-```
-$ cloudron login
-Cloudron Hostname: craft.selfhost.io
-
-Enter credentials for craft.selfhost.io:
-Username: girish
-Password:
-Login successful.
-```
-
-## Your First Application
-
-Creating an application for Cloudron can be summarized as follows:
-
-1. Create a web application using any language/framework. This web application must run a HTTP server
-   and can optionally provide other services using custom protocols (like git, ssh, TCP etc).
-
-2. Create a [Dockerfile](http://docs.docker.com/engine/reference/builder/) that specifies how to create 
-   an application ```image```. An ```image``` is essentially a bundle of the application source code
-   and it's dependencies.
-
-3. Create a [CloudronManifest.json](/references/manifest.html) file that provides essential information
-   about the app. This includes information required for the Cloudron Store like title, version, icon and 
-   runtime requirements like `addons`.
-
-## Simple Web application
-
-To keep things simple, we will start by deploying a trivial node.js server running on port 8000.
-
-Create a new project folder `tutorial/` and add a file named `tutorial/server.js` with the following content:
-```javascript
-var http = require("http");
-
-var server = http.createServer(function (request, response) {
-  response.writeHead(200, {"Content-Type": "text/plain"});
-  response.end("Hello World\n");
-});
-
-server.listen(8000);
-
-console.log("Server running at port 8000");
-```
-
-## Dockerfile
-
-A Dockerfile contains commands to assemble an image.
-
-Create a file named `tutorial/Dockerfile` with the following content:
-
-```dockerfile
-FROM cloudron/base:0.9.0
-
-ADD server.js /app/code/server.js
-
-CMD [ "/usr/local/node-0.12.7/bin/node", "/app/code/server.js" ]
-```
-
-The `FROM` command specifies that we want to start off with Cloudron's [base image](/references/baseimage.html).
-All Cloudron apps **must** start from this base image.
-
-The `ADD` command copies the source code of the app into the directory `/app/code`.
-While this example only copies a single file, the ADD command can be used to copy directory trees as well.
-See the [Dockerfile](https://docs.docker.com/reference/builder/#add) documentation for more details.
-
-The `CMD` command specifies how to run the server. There are multiple versions of node available under `/usr/local`. We
-choose node v0.12.7 for our app.
-
-## CloudronManifest.json
-
-The `CloudronManifest.json` specifies
-
-* Information about displaying the app on the Cloudron Store. For example,
-  the title, author information, description etc
-
-* Information for installing the app on the Cloudron. This includes fields
-  like httpPort, tcpPorts.
-
-Create the CloudronManifest.json using the following command:
-
-```
-$ cloudron init
-id: io.cloudron.tutorial                       # unique id for this app. use reverse domain name convention
-author: John Doe                               # developer or company name of the for user <email>
-title: Tutorial App                            # Cloudron Store title of this app
-description: App that uses node.js             # A string or local file reference like file://DESCRIPTION.md
-tagline: Changing the world one app at a time  # A tag line for this app for the Cloudron Store
-website: https://cloudron.io                   # A link to this app's website
-contactEmail: support@cloudron.io              # Contact email of developer or company
-httPort: 8000                                  # The http port on which this application listens to
-```
-
-The above command creates a CloudronManifest.json:
-
-File ```tutorial/CloudronManifest.json```
-
-```json
-{
-  "id": "io.cloudron.tutorial",
-  "author": "John Doe",
-  "title": "Tutorial App",
-  "description": "App that uses node.js",
-  "tagline": "Changing the world one app at a time",
-  "version": "0.0.1",
-  "healthCheckPath": "/",
-  "httpPort": 8000,
-  "addons": {
-    "localstorage": {}
-  },
-  "minBoxVersion": "0.0.1",
-  "manifestVersion": 1,
-  "website": "https://cloudron.io",
-  "contactEmail": "support@cloudron.io",
-  "icon": "",
-  "mediaLinks": []
-}
-```
-
-You can read in more detail about each field in the [Manifest reference](/references/manifest.html).
-
-# Installing
-
-## Building
-
-We now have all the necessary files in place to build and deploy the app to the Cloudron.
-Building creates an image of the app using the Dockerfile which can then be used to deploy
-to the Cloudron.
-
-Building, pushing and pulling docker images is very bandwidth and CPU intensive. To alleviate this
-problem, apps are built using the `build service` which uses `cloudron.io` account credentials.
-
-**Warning**: As of this writing, the build service uses the public Docker registry and the images that are built
-can be downloaded by anyone. This means that your source code will be viewable by others.
-
-Initiate a build using ```cloudron build```:
-```
-$ cloudron build
-Building io.cloudron.tutorial@0.0.1
-
-Appstore login:
-Email: ramakrishnan.girish@gmail.com         # cloudron.io account
-Password:                                    # Enter password
-Login successful.
-
-Build scheduled with id 76cebfdd-7822-4f3d-af17-b3eb393ae604
-Downloading source
-Building
-Step 0 : FROM cloudron/base:0.9.0
- ---> 97583855cc0c
-Step 1 : ADD server.js /app/code
- ---> b09b97ecdfbc
-Removing intermediate container 03c1e1f77acb
-Step 2 : CMD /usr/local/node-0.12.7/bin/node /app/code/main.js
- ---> Running in 370f59d87ab2
- ---> 53b51eabcb89
-Removing intermediate container 370f59d87ab2
-Successfully built 53b51eabcb89
-The push refers to a repository [cloudron/img-2074d69134a7e0da3d6cdf3c53e241c4] (len: 1)
-Sending image list
-Pushing repository cloudron/img-2074d69134a7e0da3d6cdf3c53e241c4 (1 tags)
-Image already pushed, skipping 57f52d167bbb
-Image successfully pushed b09b97ecdfbc
-Image successfully pushed 53b51eabcb89
-Pushing tag for rev [53b51eabcb89] on {https://cdn-registry-1.docker.io/v1/repositories/cloudron/img-2074d69134a7e0da3d6cdf3c53e241c4/tags/76cebfdd-7822-4f3d-af17-b3eb393ae604}
-Build succeeded
-```
-
-## Installing
-
-Now that we have built the image, we can install our latest build on the Cloudron
-using the following command:
-
-```
-$ cloudron install
-Using cloudron craft.selfhost.io
-Using build 76cebfdd-7822-4f3d-af17-b3eb393ae604 from 1 hour ago
-Location: tutorial                         # This is the location into which the application installs
-App is being installed with id: 4dedd3bb-4bae-41ef-9f32-7f938995f85e
-
- => Waiting to start installation
- => Registering subdomain .
- => Verifying manifest .
- => Downloading image ..............
- => Creating volume .
- => Creating container
- => Setting up collectd profile ................
- => Waiting for DNS propagation ...
-
-App is installed.
-```
-
-This makes the app available at https://tutorial-craft.selfhost.io.
-
-Open the app in your default browser:
-```
-cloudron open
-```
-
-You should see `Hello World`.
-
-# Testing
-
-The application testing cycle involves `cloudron build` and `cloudron install`.
-Note that `cloudron install` updates an existing app in place.
-
-You can view the logs using `cloudron logs`. When the app is running you can follow the logs
-using `cloudron logs -f`.
-
-For example, you can see the console.log output in our server.js with the command below:
-
-```
-$ cloudron logs
-Using cloudron craft.selfhost.io
-2015-05-08T03:28:40.233940616Z Server running at port 8000
-```
-
-It is also possible to run a *shell* and *execute* arbitrary commands in the context of the application
-process by using `cloudron exec`. By default, exec simply drops you into an interactive bash shell with
-which you can inspect the file system and the environment.
-
-```
-$ cloudron exec
-```
-
-You can also execute arbitrary commands:
-```
-$ cloudron exec env # display the env variables that your app is running with
-```
-
-# Storing data
-
-For file system storage, an app can use the `localstorage` addon to store data under `/app/data`.
-When the `localstorage` addon is active, any data under /app/data is automatically backed up. When an
-app is updated, /app/data already contains the data generated by the previous version.
-
-*Note*: For convenience, the initial CloudronManifest.json generated by `cloudron init` already contains this
-addon.
-
-Let us put this theory into action by saving a *visit counter* as a file.
-*server.js* has been modified to count the number of visitors on the site by storing a counter
-in a file named ```counter.dat```.
-
-File ```tutorial/server.js```
-
-```javascript
-var http = require('http'),
-    fs = require('fs'),
-    util = require('util');
-
-var COUNTER_FILE = '/app/data/counter.dat';
-
-var server = http.createServer(function (request, response) {
-    var counter = 0;
-    if (fs.existsSync(COUNTER_FILE)) {
-        // read existing counter if it exists
-        counter = parseInt(fs.readFileSync(COUNTER_FILE, 'utf8'), 10);
-    }
-
-    response.writeHead(200, {"Content-Type": "text/plain"});
-    response.end(util.format("Hello World. %s visitors have visited this page\n", counter));
-    ++counter; // bump the counter
-    fs.writeFileSync(COUNTER_FILE, counter + '', 'utf8'); // save back counter
-});
-
-server.listen(8000);
-
-console.log("Server running at port 8000");
-```
-
-Now every time you refresh the page you will notice that the counter bumps up. You will
-also notice that if you make changes to the app and do a `cloudron install`, the `counter.dat`
-is *retained* across updates.
-
-# Database
-
-Most web applications require a database of some form. In theory, it is possible to run any
-database you want as part of the application image. This is, however, a waste of server resources
-should every app runs it's own database server.
-
-To solve this, the Cloudron provides shareable resources like databases in form of ```addons```.
-The database server is managed by the Cloudron and the application simply needs to request access to
-the database in the CloudronManifest.json. While the database server itself is a shared resource, the
-databases are exclusive to the application. Each database is password protected and accessible only
-to the application. Databases and tables can be configured without restriction as the application
-requires.
-
-Cloudron currently provides `mysql`, `postgresql`, `mongodb`, `redis` database addons.
-
-For this tutorial, let us try to save the counter in `redis` addon. For this, we make use of the
-[redis](https://www.npmjs.com/package/redis) module.
-
-Since this is a node.js app, let's add a very basic `package.json` containing the `redis` module dependency.
-
-File `tutorial/package.json`
-```json
-{
-  "name": "tutorial",
-  "version": "1.0.0",
-  "dependencies": {
-    "redis": "^0.12.1"
-  }
-}
-```
-
-and modify our Dockerfile to look like this:
-
-File `tutorial/Dockerfile`
-
-```dockerfile
-FROM cloudron/base:0.9.0
-
-ADD server.js /app/code/server.js
-ADD package.json /app/code/package.json
-
-WORKDIR /app/code
-RUN npm install --production
-
-CMD [ "/usr/local/node-0.12.7/bin/node", "/app/code/server.js" ]
-```
-
-Notice the new `RUN` command which installs the node module dependencies in package.json using `npm install`.
-
-Since we want to use redis, we have to modify the CloudronManifest.json to make redis available for this app.
-
-File `tutorial/CloudronManifest.json`
-
-```json
-{
-  "id": "io.cloudron.tutorial",
-  "author": "John Doe",
-  "title": "Tutorial App",
-  "description": "App that uses node.js",
-  "tagline": "Changing the world one app at a time",
-  "version": "0.0.1",
-  "healthCheckPath": "/",
-  "httpPort": 8000,
-  "addons": {
-    "localstorage": {},
-    "redis": {}
-  },
-  "minBoxVersion": "0.0.1",
-  "manifestVersion": 1,
-  "website": "https://cloudron.io",
-  "contactEmail": "support@cloudron.io",
-  "icon": "",
-  "mediaLinks": []
-}
-```
-
-When the application runs, environment variables `REDIS_HOST`, `REDIS_PORT` and
-`REDIS_PASSWORD` are injected. You can read about the environment variables in the
-[Redis reference](/references/addons.html#redis).
-
-Let's change `server.js` to use redis instead of file backed counting:
-
-File ```tutorial/server.js```
-
-```javascript
-var http = require('http'),
-    fs = require('fs'),
-    util = require('util'),
-    redis = require('redis');
-
-var redisClient = redis.createClient(process.env.REDIS_PORT, process.env.REDIS_HOST);
-redisClient.auth(process.env.REDIS_PASSWORD);
-redisClient.on("error", function (err) {
-  console.log("Redis Client Error " + err);
-});
-
-var COUNTER_KEY = 'counter';
-
-var server = http.createServer(function (request, response) {
-  redisClient.get(COUNTER_KEY, function (err, reply) {
-    var counter = (!err && reply) ? parseInt(reply, 10) : 0;
-    response.writeHead(200, {"Content-Type": "text/plain"});
-    response.end(util.format("Hello World. %s visitors have visited this page\n", counter));
-    redisClient.incr(COUNTER_KEY);
-  });
-});
-
-server.listen(8000);
-
-console.log("Server running at port 8000");
-```
-
-Simply `cloudron build` and `cloudron install` to test your app!
-
-# Authentication
-
-The Cloudron has a centralized panel for managing users and groups. Apps can integrate Single Sign-On
-authentication using LDAP or OAuth.
-
-Note that apps that are single user can skip Single Sign-On support. The Cloudron implements an `OAuth
-proxy` (accessed through the app configuration dialog) that optionally lets the Cloudron admin make the
-app visible only for logged in users.
-
-## LDAP
-
-Let's start out by adding the [ldap](/references/addons.html#ldap) addon to the manifest.
-
-File `tutorial/CloudronManifest.json`
-```json
-{
-  "id": "io.cloudron.tutorial",
-  "author": "John Doe",
-  "title": "Tutorial App",
-  "description": "App that uses node.js",
-  "tagline": "Changing the world one app at a time",
-  "version": "0.0.1",
-  "healthCheckPath": "/",
-  "httpPort": 8000,
-  "addons": {
-    "localstorage": {},
-    "ldap": {}
-  },
-  "minBoxVersion": "0.0.1",
-  "manifestVersion": 1,
-  "website": "https://cloudron.io",
-  "contactEmail": "support@cloudron.io",
-  "icon": "",
-  "mediaLinks": []
-}
-```
-
-Building and installing the app shows that the app gets new LDAP specific environment variables.
-
-```
-$ cloudron build
-$ cloudron install
-$ cloudron exec env | grep LDAP
-LDAP_SERVER=172.17.42.1
-LDAP_PORT=3002
-LDAP_URL=ldap://172.17.42.1:3002
-LDAP_USERS_BASE_DN=ou=users,dc=cloudron
-LDAP_GROUPS_BASE_DN=ou=groups,dc=cloudron
-```
-
-Let's test the environment variables to use by using the [ldapjs](http://www.ldapjs.org) npm module.
-We start by adding ldapjs to package.json.
-
-File `tutorial/package.json`
-```json
-{
-  "name": "tutorial",
-  "version": "1.0.0",
-  "dependencies": {
-    "ldapjs": "^0.7.1"
-  }
-}
-```
-
-The server code has been modified to authenticate using the `X-Username` and `X-Password` headers for
-any path other than '/'.
-
-File `tutorial/server.js`
-```javascript
-var http = require("http"),
-    ldap = require('ldapjs');
-
-var ldapClient = ldap.createClient({ url: process.env.LDAP_URL });
-
-var server = http.createServer(function (request, response) {
-  if (request.url === '/') {
-    response.writeHead(200, {"Content-Type": "text/plain"});
-    return response.end();
-  }
-
-  var username = request.headers['x-username'] || '';
-  var password = request.headers['x-password'] || '';
-  var ldapDn = 'cn=' + username + ',' + process.env.LDAP_USERS_BASE_DN;
-
-  ldapClient.bind(ldapDn, password, function (error) {
-    if (error) {
-      response.writeHead(401, {"Content-Type": "text/plain"});
-      response.end('Failed to authenticate: ' + error);
-    } else {
-      response.writeHead(200, {"Content-Type": "text/plain"});
-      response.end('Successfully authenticated');
-    }
-  });
-});
-
-server.listen(8000);
-
-console.log("Server running at port 8000");
-```
-
-Once we have used `cloudron build` and `cloudron install`, you can use `curl` to test
-credentials as follows:
-
-```bash
-  # Test with various credentials here. Your cloudon admin username and password should succeed.
-  curl -X 'X-Username: admin' -X 'X-Password: pass' https://tutorial-craft.selfhost.io/login
-```
-
-## OAuth
-
-An app can integrate with OAuth 2.0 Authorization code grant flow by adding
-[oauth](/references/addons.html#oauth) to CloudronManifest.json `addons` section.
-
-Doing so will get the following environment variables:
-```
-$ cloudron exec env
-OAUTH_CLIENT_ID=cid-addon-4089f65a-2adb-49d2-a6d1-e519b7d85e8d
-OAUTH_CLIENT_SECRET=5af99a9633283aa15f5e6df4a108ff57f82064e4845de8bce8ad3af54dfa9dda
-OAUTH_ORIGIN=https://my-craft.selfhost.io
-API_ORIGIN=https://my-craft.selfhost.io
-HOSTNAME=tutorial-craft.selfhost.io
-```
-
-OAuth Authorization code grant flow works as follows:
-* App starts the flow by redirecting the user to Cloudron authorization endpoint of the following format:
-```
-https://API_ORIGIN/api/v1/oauth/dialog/authorize?response_type=code&client_id=OAUTH_CLIENT_ID&redirect_uri=CALLBACK_URL&scope=profile
-```
-
-  In the above URL, API_ORIGIN and OAUTH_CLIENT_ID are environment variables. CALLBACK_URL is a url of the app
-to which the user will be redirected back to after successful authentication. CALLBACK_URL has to have the
-same origin as the app.
-
-* The Cloudron OAuth server authenticates the user (using a password form) at the above URL. It also establishes
-that the user grants the client's access request.
-
-* If the user authenticated successfully, it will redirect the browser to CALLBACK_URL with a `code` query parameter.
-
-* The app can exchange the `code` above for a `access token` by using the `OAUTH_CLIENT_SECRET`. It does so by making
-  a _POST_ request to the following url:
-```
-https://API_ORIGIN/api/v1/oauth/token?response_type=token&client_id=OAUTH_CLIENT_ID
-```
-with the following request body (json):
-```json
-{
-    "grant_type": "authorization_code",
-    "code": "<the code received in CALLBACK_URL query parameter>",
-    "redirect_uri": "https://<HOSTNAME>",
-    "client_id": "<OAUTH_CLIENT_ID>",
-    "client_secret": "<OAUTH_CLIENT_SECRET>"
-}
-```
-
-  In the above URL, API_ORIGIN, OAUTH_CLIENT_ID and HOSTNAME are environment variables. The response contains
-the `access_token` in the body.
-
-* The `access_token` can be used to get the [user's profile](/references/api.html#profile) using the following url:
-```
-https://API_ORIGIN/api/v1/profile?access_token=ACCESS_TOKEN
-```
-
-  The `access_token` may also be provided in the `Authorization` header as `Bearer: <token>`.
-
-An implementation of the above OAuth logic is at [ircd-app](https://github.com/cloudron-io/ircd-app/blob/master/settings/app.js).
-
-The following libraries implement Cloudron OAuth for Ruby and Javascript.
-
- * [omniauth-cloudron](https://github.com/cloudron-io/omniauth-cloudron)
- * [passport-cloudron](https://github.com/cloudron-io/passport-cloudron)
-
-# Beta Testing
-
-Once your app is ready, you can upload it to the store for `beta testing` by
-other Cloudron users. This can be done using:
-
-```
-  cloudron upload
-```
-
-The app should now be visible in the Store view of your cloudron under
-the 'Testing' section. You can check if the icon, description and other details
-appear correctly.
-
-Other Cloudron users can install your app on their Cloudron's using
-`cloudron install --appstore-id <appid@version>`. Note that this currently
-requires your beta testers to install the CLI tool and put their Cloudron in
-developer mode.
-
-# Publishing
-
-Once you are satisfied with the beta testing, you can submit it for review.
-
-```
-  cloudron submit
-```
-
-The cloudron.io team will review the app and publish the app to the store.
-
-# Next steps
-
-Congratulations! You are now well equipped to build web applications for the Cloudron.
-
-# Samples
-
-  * [Lets Chat](https://github.com/cloudron-io/letschat-app)
-  * [Haste bin](https://github.com/cloudron-io/haste-app)
-  * [Pasteboard](https://github.com/cloudron-io/pasteboard-app)
@@ -1,491 +0,0 @@
-# Overview
-
-This tutorial outlines how to package an existing web application for the Cloudron.
-
-If you are aware of Docker and Heroku, you should feel at home packaging for the
-Cloudron. Roughly, the steps involved are:
-
-* Create a Dockerfile for your application. If your application already has
-  a Dockerfile, you should able to reuse most of it. By virtue of Docker, the Cloudron
-  is able to run apps written in any language/framework.
-
-* Create a CloudronManifest.json that provides information like title, author, description
-   etc. You can also specify the addons (like database) required
-  to run your app. When the app runs on the Cloudron, it will have environment
-  variables set for connecting to the addon.
-
-* Test the app on your Cloudron with the CLI tool.
-
-* Optionally, submit the app to [Cloudron Store](/appstore.html).
-
-# Prerequisites
-
-## Install CLI tool
-
-The Cloudron CLI tool allows you to install, configure and test apps on your Cloudron.
-
-Installing the CLI tool requires [node.js](https://nodejs.org/) and
-[npm](https://www.npmjs.com/). You can then install the CLI tool using the following
-command:
-
-```
-    sudo npm install -g cloudron
-```
-
-Note: Depending on your setup, you can run the above command without `sudo`.
-
-## Login to Cloudron
-
-The `cloudron` command should now be available in your path.
-
-You can login to your Cloudron now:
-
-```
-$ cloudron login
-Cloudron Hostname: craft.selfhost.io
-
-Enter credentials for craft.selfhost.io:
-Username: girish
-Password:
-Login successful.
-```
-
-# Basic app
-
-We will first package a very simple app to understand how the packaging works.
-You can clone this app from https://git.cloudron.io/cloudron/tutorial-basic.
-
-## The server
-
-The basic app server is a very simple HTTP server that runs on port 8000.
-While the server in this tutorial uses node.js, you can write your server
-in any language you want.
-
-```server.js
-var http = require("http");
-
-var server = http.createServer(function (request, response) {
-  response.writeHead(200, {"Content-Type": "text/plain"});
-  response.end("Hello World\n");
-});
-
-server.listen(8000);
-
-console.log("Server running at port 8000");
-```
-
-## Dockerfile
-
-The Dockerfile contains instructions on how to create an image for your application.
-
-```Dockerfile
-FROM cloudron/base:0.9.0
-
-ADD server.js /app/code/server.js
-
-CMD [ "/usr/local/node-4.2.1/bin/node", "/app/code/server.js" ]
-```
-
-The `FROM` command specifies that we want to start off with Cloudron's [base image](/references/baseimage.html).
-All Cloudron apps **must** start from this base image. This approach conserves space on the Cloudron since
-Docker images tend to be quiet large.
-
-The `ADD` command copies the source code of the app into the directory `/app/code`. There is nothing special
-about the `/app/code` directory and it is merely a convention we use to store the application code.
-
-The `CMD` command specifies how to run the server. The base image already contains many different versions of
-node.js. We use Node 4.2.1 here.
-
-This Dockerfile can be built and run locally as:
-```
-docker build -t tutorial .
-docker run -p 8000:8000 -ti tutorial
-```
-
-## Manifest
-
-The `CloudronManifest.json` specifies
-
-* Information for installing and running the app on the Cloudron. This includes fields like addons, httpPort, tcpPorts.
-
-* Information about displaying the app on the Cloudron Store. For example, fields like title, author, description.
-
-Create the CloudronManifest.json using `cloudron init` as follows:
-
-```
-$ cloudron init
-id: io.cloudron.tutorial                       # unique id for this app. use reverse domain name convention
-author: John Doe                               # developer or company name of the for user <email>
-title: Tutorial App                            # Cloudron Store title of this app
-description: App that uses node.js             # A string or local file reference like file://DESCRIPTION.md
-tagline: Changing the world one app at a time  # A tag line for this app for the Cloudron Store
-website: https://cloudron.io                   # A link to this app's website
-contactEmail: support@cloudron.io              # Contact email of developer or company
-httPort: 8000                                  # The http port on which this application listens to
-```
-
-The above command creates a CloudronManifest.json:
-
-File ```tutorial/CloudronManifest.json```
-
-```json
-{
-  "id": "io.cloudron.tutorial",
-  "title": "Tutorial App",
-  "author": "John Doe",
-  "description": "file://DESCRIPTION.md",
-  "changelog": "file://CHANGELOG",
-  "tagline": "Changing the world one app at a time",
-  "version": "0.0.1",
-  "healthCheckPath": "/",
-  "httpPort": 8000,
-  "addons": {
-    "localstorage": {}
-  },
-  "manifestVersion": 1,
-  "website": "https://cloudron.io",
-  "contactEmail": "support@cloudron.io",
-  "icon": "",
-  "tags": [
-    "changme"
-  ],
-  "mediaLinks": [ ]
-}
-```
-
-You can read in more detail about each field in the [Manifest reference](/references/manifest.html). The
-`localstorage` addon allows the app to store files in `/app/data`. We will explore addons further further
-down in this tutorial.
-
-Additional files created by `init` are:
-* `DESCRIPTION.md` - A markdown file providing description of the app for the Cloudron Store.
-* `CHANGELOG` - A file containing change information for each version released to the Cloudron Store. This
-  information is shown when the user updates the app.
-
-# Installing
-
-We now have all the necessary files in place to build and deploy the app to the Cloudron.
-
-## Building
-
-Building, pushing and pulling docker images can be very bandwidth and CPU intensive. To alleviate this
-problem, apps are built using the `build service` which uses `cloudron.io` account credentials.
-
-**Warning**: As of this writing, the build service uses the public Docker registry and the images that are built
-can be downloaded by anyone. This means that your source code will be viewable by others.
-
-Initiate a build using ```cloudron build```:
-```
-$ cloudron build
-Building io.cloudron.tutorial@0.0.1
-
-Appstore login:
-Email: ramakrishnan.girish@gmail.com         # cloudron.io account
-Password:                                    # Enter password
-Login successful.
-
-Build scheduled with id e7706847-f2e3-4ba2-9638-3f334a9453a5
-Waiting for build to begin, this may take a bit...
-Downloading source
-Building
-Step 1 : FROM cloudron/base:0.9.0
- ---> be9fc6312b2d
-Step 2 : ADD server.js /app/code/server.js
- ---> 10513e428d7a
-Removing intermediate container 574573f6ed1c
-Step 3 : CMD /usr/local/node-4.2.1/bin/node /app/code/server.js
- ---> Running in b541d149b6b9
- ---> 51aa796ea6e5
-Removing intermediate container b541d149b6b9
-Successfully built 51aa796ea6e5
-Pushing
-The push refers to a repository [docker.io/cloudron/img-062037096d69bbf3ffb5b9316ad89cb9] (len: 1)
-Pushed 51aa796ea6e5
-Pushed 10513e428d7a
-Image already exists be9fc6312b2d
-Image already exists a0261a2a7c75
-Image already exists f9d4f0f1eeed
-Image already exists 2b650158d5d8
-e7706847-f2e3-4ba2-9638-3f334a9453a5: digest: sha256:8241d68b65874496191106ecf2ee8f3df2e05a953cd90ff074a6f8815a49389c size: 26098
-Build succeeded
-Success
-```
-
-## Installing
-
-Now that we have built the image, we can install our latest build on the Cloudron
-using the following command:
-
-```
-$ cloudron install
-Using cloudron craft.selfhost.io
-Using build 76cebfdd-7822-4f3d-af17-b3eb393ae604 from 1 hour ago
-Location: tutorial                         # This is the location into which the application installs
-App is being installed with id: 4dedd3bb-4bae-41ef-9f32-7f938995f85e
-
- => Waiting to start installation
- => Registering subdomain .
- => Verifying manifest .
- => Downloading image ..............
- => Creating volume .
- => Creating container
- => Setting up collectd profile ................
- => Waiting for DNS propagation ...
-
-App is installed.
-```
-
-Open the app in your default browser:
-```
-cloudron open
-```
-
-You should see `Hello World`.
-
-# Testing
-
-The application testing cycle involves `cloudron build` and `cloudron install`.
-Note that `cloudron install` updates an existing app in place.
-
-You can view the logs using `cloudron logs`. When the app is running you can follow the logs
-using `cloudron logs -f`.
-
-For example, you can see the console.log output in our server.js with the command below:
-
-```
-$ cloudron logs
-Using cloudron craft.selfhost.io
-16:44:11 [main] Server running at port 8000
-```
-
-It is also possible to run a *shell* and *execute* arbitrary commands in the context of the application
-process by using `cloudron exec`. By default, exec simply drops you into an interactive bash shell with
-which you can inspect the file system and the environment.
-
-```
-$ cloudron exec
-```
-
-You can also execute arbitrary commands:
-```
-$ cloudron exec env # display the env variables that your app is running with
-```
-
-### DevelopmentMode
-
-When debugging complex startup scripts, one can specify `"developmentMode": true,` in the CloudronManifest.json.
-This will ignore the `RUN` command, specified in the Dockerfile and allows the developer to interactively test
-the startup scripts using `cloudron exec`.
-
-**Note:** that an app running in this mode has full read/write access to the filesystem and all memory limits are lifted.
-
-
-# Addons
-
-## Filesystem
-
-The application container created on the Cloudron has a `readonly` file system. Writing to any location
-other than the below will result in an error:
-
-* `/tmp` - Use this location for temporary files. The Cloudron will cleanup any files in this directory
-  periodically.
-
-* `/run` - Use this location for runtime configuration and dynamic data. These files should not be expected
-  to persist across application restarts (for example, after an update or a crash).
-
-* `/app/data` - Use this location to store application data that is to be backed up. To use this location,
-  you must use the [localstorage](/references/addons.html#localstorage) addon. For convenience, the initial CloudronManifest.json generated by
-  `cloudron init` already contains this addon.
-
-## Database
-
-Most web applications require a database of some form. In theory, it is possible to run any
-database you want as part of the application image. This is, however, a waste of server resources
-should every app runs it's own database server.
-
-Cloudron currently provides [mysql](/references/addons.html#mysql), [postgresql](/references/addons.html#postgresql),
-[mongodb](/references/addons.html#mongodb), [redis](/references/addons.html#redis) database addons. When choosing
-these addons, the Cloudron will inject environment variables that contain information on how to connect
-to the addon.
-
-See https://git.cloudron.io/cloudron/tutorial-redis for a simple example of how redis can be used by
-an application. The server simply uses the environment variables to connect to redis.
-
-## Email
-
-Cloudron applications can send email using the `sendmail` addon. Using the `sendmail` addon provides
-the SMTP server and authentication credentials in environment variables.
-
-Cloudron applications can also receive mail via IMAP using the `recvmail` addon.
-
-## Authentication
-
-The Cloudron has a centralized panel for managing users and groups. Apps can integrate Single Sign-On
-authentication using LDAP or OAuth.
-
-Apps can integrate with the Cloudron authentication system using LDAP, OAuth or Simple Auth. See the
-[authentication](/references/authentication.html) reference page for more details.
-
-See https://git.cloudron.io/cloudron/tutorial-ldap for a simple example of how to authenticate via LDAP.
-
-For apps that are single user can skip Single Sign-On support by setting the `"singleUser": true`
-in the manifest. By doing so, the Cloudron will installer will show a dialog to choose a user.
-
-For app that have no user management at all, the Cloudron implements an `OAuth proxy` that
-optionally lets the Cloudron admin make the app visible only for logged in users.
-
-# Best practices
-
-## No Setup
-
-A Cloudron app is meant to instantly usable after installation. For this reason, Cloudron apps must not
-show any setup screen after installation and should simply choose reasonable defaults.
-
-Databases, email configuration should be automatically picked up from the environment variables using
-addons.
-
-## Dockerfile
-
-The app is run as a read-only docker container. Because of this:
-* Install any required packages in the Dockerfile.
-* Create static configuration files in the Dockerfile.
-* Create symlinks to dynamic configuration files under /run in the Dockerfile.
-
-## Process manager
-
-Docker supports restarting processes natively. Should your application crash, it will be restarted
-automatically. If your application is a single process, you do not require any process manager.
-
-Use supervisor, pm2 or any of the other process managers if you application has more then one component.
-This **excludes** web servers like apache, nginx which can already manage their children by themselves.
-Be sure to pick a process manager that forwards signals to child processes.
-
-## Automatic updates
-
-Some apps support automatic updates by overwriting themselves. A Cloudron app cannot overwrite itself
-because of the read-only file system. For this reason, disable auto updates for app and let updates be
-triggered through the Cloudron Store. This ties in better to the Cloudron's update and restore approach
-should something go wrong with the update.
-
-## Logging
-
-Cloudron applications stream their logs to stdout and stderr. In practice, this ideal is hard to achieve.
-Some programs like apache simply don't log to stdout. In those cases, simply log to `/tmp` or `/run`.
-
-Logging to stdout has many advantages:
-* App does not need to rotate logs and the Cloudron takes care of managing logs.
-* App does not need special mechanism to release log file handles (on a log rotate).
-* Integrates better with tooling like cloudron cli.
-
-## Memory
-
-By default, applications get 256MB RAM (including swap). This can be changed using the `memoryLimit`
-field in the manifest.
-
-Design your application runtime for concurrent use by 50 users. The Cloudron is not designed for
-concurrent access by 100s or 1000s of users.
-
-## Authentication
-
-Apps should integrate with one of the [authentication strategies](/references/authentication.html).
-This saves the user from having to manage separate set of credentials for each app.
-
-## Startup Script
-
-Many apps do not launch the server directly, as we did in our basic example. Instead, they execute
-a `start.sh` script (named so by convention) which launches the server. Before starting the server,
-the `start.sh` script does the following:
-
-  * When using the `localstorage` addon, it changes the ownership of files in `/app/data` as desired using `chown`. This
-    is necessary because file permissions may not be correctly preserved across backup, restore, application and base image
-    updates.
-
-  * Addon information (mail, database) exposed as environment  are subject to change across restarts and an application
-    must use these values directly (i.e not cache them across restarts). For this reason, it usually regenerates
-    any config files with the current database settings on each invocation.
-
-  * Finally, it starts the server as a non-root user.
-
-The app's main process must handle SIGTERM and forward it as required to child processes. bash does not
-automatically forward signals to child processes. For this reason, when using a startup shell script,
-remember to use exec <app> as the last line. Doing so will replace bash with your program and allows
-your program to handle signals as required.
-
-# Beta Testing
-
-## Metadata
-
-Publishing to the Cloudron Store requires apps to have meta data specified in the `CloudronManifest.json`.
-
-The `cloudron` tool will notify if any such information is missing, prior to uploading.
-See more information for each field [here](/references/manifest.html).
-
-## Upload for Testing
-
-Once your app is ready, you can upload it to the store for `beta testing` by
-other Cloudron users. This can be done using:
-
-```
-  cloudron upload
-```
-
-You should now be able to visit `/#/appstore/<appid>?version=<appversion>` on your
-Cloudron to check if the icon, description and other details appear correctly.
-
-Other Cloudron users can install your app on their Cloudron's using
-`cloudron install --appstore-id <appid@version>`.
-
-# Publishing
-
-Once you are satisfied with the beta testing, you can submit it for review.
-
-```
-  cloudron submit
-```
-
-The cloudron.io team will review the app and publish the app to the store.
-
-# Updating the app
-
-## Versioning
-
-To create an update for an app, simply bump up the [semver version](/references/manifest.html#version) field in
-the manifest and publish a new version to the store.
-
-The Cloudron chooses the next app version to update to based on the following algorithm:
-* Choose the maximum `patch` version matching the app's current `major` and `minor` version.
-* Failing the above, choose the maximum patch version of the next minor version matching the app's current `major` version.
-* Failing the above, choose the maximum patch and minor version of the next major version
-
-For example, let's assume the versions 1.1.3, 1.1.4, 1.1.5, 1.2.4, 1.2.6, 1.3.0, 2.0.0 are published.
-
-* If the app is running 1.1.3, then app will directly update to 1.1.5 (skipping 1.1.4)
-* Once in 1.1.5, the app will update to 1.2.6 (skipping 1.2.4)
-* Once in 1.2.6, the app will update to 1.3.0
-* Once in 1.3.0, the app will update to 2.0.0
-
-The Cloudron admins get notified by email for any major or minor app releases.
-
-## Failed updates
-
-The Cloudron always makes a backup of the app before making an update. Should the
-update fail, the user can restore to the backup (which will also restore the app's
-code to the previous version).
-
-# Cloudron Button
-
-The [Cloudron Button](/references/button.html) allows anyone to install your application with the click of a button
-on their Cloudron.
-
-The button can be added to just about any website including the application's website
-and README.md files in GitHub repositories.
-
-# Next steps
-
-Congratulations! You are now well equipped to build web applications for the Cloudron.
-
-You can see some examples of how real apps are packaged here:
-
-  * [Lets Chat](https://git.cloudron.io/cloudron/letschat-app)
-  * [Haste bin](https://git.cloudron.io/cloudron/haste-app)
-  * [Pasteboard](https://git.cloudron.io/cloudron/pasteboard-app)
@@ -2,17 +2,18 @@

 'use strict';

-var ejs = require('gulp-ejs'),
-    gulp = require('gulp'),
-    del = require('del'),
-    concat = require('gulp-concat'),
-    uglify = require('gulp-uglify'),
-    serve = require('gulp-serve'),
-    sass = require('gulp-sass'),
-    sourcemaps = require('gulp-sourcemaps'),
-    cssnano = require('gulp-cssnano'),
+var argv = require('yargs').argv,
    autoprefixer = require('gulp-autoprefixer'),
-    argv = require('yargs').argv;
+    concat = require('gulp-concat'),
+    cssnano = require('gulp-cssnano'),
+    ejs = require('gulp-ejs'),
+    gulp = require('gulp'),
+    rimraf = require('rimraf'),
+    sass = require('gulp-sass'),
+    serve = require('gulp-serve'),
+    sourcemaps = require('gulp-sourcemaps'),
+    uglify = require('gulp-uglify'),
+    url = require('url');

 gulp.task('3rdparty', function () {
    gulp.src([
@@ -40,19 +41,30 @@ gulp.task('3rdparty', function () {
 // JavaScript
 // --------------

+if (argv.help || argv.h) {
+    console.log('Supported arguments for "gulp develop":');
+    console.log(' --client-id <clientId>');
+    console.log(' --client-secret <clientSecret>');
+    console.log(' --api-origin <cloudron api uri>');
+
+    process.exit(1);
+}
+
 gulp.task('js', ['js-index', 'js-setup', 'js-setupdns', 'js-update'], function () {});

 var oauth = {
-    clientId: argv.clientId || process.env.CLOUDRON_CLIENT_ID || 'cid-webadmin',
-    clientSecret: argv.clientSecret || process.env.CLOUDRON_CLIENT_SECRET || 'unused',
-    apiOrigin: argv.apiOrigin || process.env.CLOUDRON_API_ORIGIN || ''
+    clientId: argv.clientId || 'cid-webadmin',
+    clientSecret: argv.clientSecret || 'unused',
+    apiOrigin: argv.apiOrigin || '',
+    apiOriginHostname: argv.apiOrigin ? url.parse(argv.apiOrigin).hostname : ''
 };

 console.log();
 console.log('Using OAuth credentials:');
-console.log(' ClientId:     %s', oauth.clientId);
-console.log(' ClientSecret: %s', oauth.clientSecret);
-console.log(' Cloudron API: %s', oauth.apiOrigin || 'default');
+console.log(' ClientId:      %s', oauth.clientId);
+console.log(' ClientSecret:  %s', oauth.clientSecret);
+console.log(' Cloudron API:  %s', oauth.apiOrigin || 'default');
+console.log(' Cloudron Host: %s', oauth.apiOriginHostname);
 console.log();


@@ -131,7 +143,7 @@ gulp.task('js-update', function () {
 // --------------

 gulp.task('html', ['html-views', 'html-update', 'html-templates'], function () {
-    return gulp.src('webadmin/src/*.html').pipe(gulp.dest('webadmin/dist'));
+    return gulp.src('webadmin/src/*.html').pipe(ejs({ apiOriginHostname: oauth.apiOriginHostname }, { ext: '.html' })).pipe(gulp.dest('webadmin/dist'));
 });

 gulp.task('html-update', function () {
@@ -184,7 +196,8 @@ gulp.task('watch', ['default'], function () {
 });

 gulp.task('clean', function () {
-    del.sync(['webadmin/dist', 'setup/splash/website']);
+    rimraf.sync('webadmin/dist');
+    rimraf.sync('setup/splash/website');
 });

 gulp.task('default', ['clean', 'html', 'js', '3rdparty', 'images', 'css'], function () {});
@@ -0,0 +1,32 @@
+#!/usr/bin/env node
+
+'use strict';
+
+var tar = require('tar-fs'),
+    fs = require('fs'),
+    path = require('path'),
+    zlib = require('zlib');
+
+if (process.argv.length < 4) {
+    console.error('Usage: tarjs <cwd> <dir>');
+    process.exit(1);
+}
+
+var dir = process.argv[3];
+var cwd = process.argv[2];
+
+console.error('Packing directory "'+ dir +'" from within "' + cwd + '" and stream to stdout');
+
+process.chdir(cwd);
+
+var stat = fs.statSync(dir);
+if (!stat.isDirectory()) throw(dir + ' is not a directory');
+
+var gzipStream = zlib.createGzip({});
+
+tar.pack(path.resolve(dir), {
+    ignore: function (name) {
+        if (name === '.') return true;
+        return false;
+    }
+}).pipe(gzipStream).pipe(process.stdout);
@@ -1,5 +1,5 @@
-var dbm = require('db-migrate');
-var type = dbm.dataType;
+'use strict';
+
 var url = require('url');

 exports.up = function(db, callback) {
@@ -1,5 +1,4 @@
-var dbm = require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 var fs = require('fs'),
    async = require('async'),
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE users ADD COLUMN resetToken VARCHAR(128) DEFAULT ""', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('DELETE FROM tokens', [], function (error) {
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE authcodes ADD COLUMN expiresAt BIGINT NOT NULL', function (error) {
@@ -13,4 +12,4 @@ exports.down = function(db, callback) {
        if (error) console.error(error);
        callback(error);
    });
-};
+};
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE appPortBindings ADD COLUMN environmentVariable VARCHAR(128) NOT NULL', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE appPortBindings DROP COLUMN containerPort', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('DELETE FROM tokens', [], function (error) {
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps DROP COLUMN version', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps DROP COLUMN healthy, ADD COLUMN health VARCHAR(128)', [], function (error) {
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN lastBackupId VARCHAR(128)', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN createdAt TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    // everyday at 1am
@@ -8,5 +7,4 @@ exports.up = function(db, callback) {

 exports.down = function(db, callback) {
    db.runSql('DELETE * FROM settings WHERE name="autoupdate_pattern"', [ ], callback);
-}
-
+};
@@ -1,6 +1,6 @@
-dbm = dbm || require('db-migrate');
+'use strict';
+
 var safe = require('safetydance');
-var type = dbm.dataType;

 exports.up = function(db, callback) {
    var tz = safe.fs.readFileSync('/etc/timezone', 'utf8');
@@ -12,4 +12,3 @@ exports.up = function(db, callback) {
 exports.down = function(db, callback) {
    db.runSql('DELETE * FROM settings WHERE name="time_zone"', [ ], callback);
 };
-
@@ -1,5 +1,5 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';
+
 var async = require('async');

 exports.up = function(db, callback) {
@@ -1,5 +1,5 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';
+
 var async = require('async');

 exports.up = function(db, callback) {
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN lastManifestJson VARCHAR(2048)', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps CHANGE lastManifestJson lastBackupConfigJson VARCHAR(2048)', [], function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN oldConfigJson VARCHAR(2048)', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('DELETE FROM settings', [ ], callback);
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN oauthProxy BOOLEAN DEFAULT 0', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,5 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';
+
 var async = require('async');

 exports.up = function(db, callback) {
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps CHANGE accessRestriction accessRestrictionJson VARCHAR(2048)', [], function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps MODIFY manifestJson TEXT', [], function (error) {
@@ -1,5 +1,5 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';
+
 var async = require('async');

 exports.up = function(db, callback) {
@@ -1,4 +1,4 @@
-dbm = dbm || require('db-migrate');
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE users ADD COLUMN displayName VARCHAR(512) DEFAULT ""', function (error) {
@@ -1,4 +1,4 @@
-dbm = dbm || require('db-migrate');
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN memoryLimit BIGINT DEFAULT 0', function (error) {
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    var cmd = "CREATE TABLE groups(" +
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
 	var cmd = "CREATE TABLE IF NOT EXISTS groupMembers(" +
@@ -1,6 +1,5 @@
 'use strict';

-var dbm = global.dbm || require('db-migrate');
 var async = require('async');

 var ADMIN_GROUP_ID = 'admin'; // see groups.js
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    var cmd = "CREATE TABLE backups(" +
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE backups ADD COLUMN configJson TEXT', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-var dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE backups DROP COLUMN configJson', function (error) {
@@ -14,4 +13,3 @@ exports.down = function(db, callback) {
        callback(error);
    });
 };
-
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE backups CHANGE filename id VARCHAR(128)', [], function (error) {
@@ -1,4 +1,4 @@
-dbm = dbm || require('db-migrate');
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE users MODIFY username VARCHAR(254) UNIQUE', [], function (error) {
@@ -1,7 +1,5 @@
 'use strict';

-var dbm = dbm || require('db-migrate');
-
 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN altDomain VARCHAR(256)', function (error) {
        if (error) console.error(error);
@@ -1,13 +1,12 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    var cmd = "CREATE TABLE eventlog(" +
            "id VARCHAR(128) NOT NULL," +
-            "source JSON," +
+            "source TEXT," +
            "creationTime TIMESTAMP," +
            "action VARCHAR(128) NOT NULL," +
-            "data JSON," +
+            "data TEXT," +
            "PRIMARY KEY (id))";

    db.runSql(cmd, function (error) {
@@ -1,4 +1,4 @@
-dbm = dbm || require('db-migrate');
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE users ADD COLUMN showTutorial BOOLEAN DEFAULT 0', function (error) {
@@ -1,8 +1,5 @@
 'use strict';

-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
-
 exports.up = function(db, callback) {
 	var cmd = 'CREATE TABLE mailboxes(' +
 				'name VARCHAR(128) NOT NULL,' +
@@ -1,5 +1,6 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';
+
+var async = require('async');

 // imports mailbox entries for existing users
 exports.up = function(db, callback) {
@@ -1,5 +1,4 @@
-dbm = dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps DROP COLUMN lastBackupConfigJson', function (error) {
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps MODIFY installationProgress TEXT', [], function (error) {
@@ -1,4 +1,4 @@
-dbm = dbm || require('db-migrate');
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN xFrameOptions VARCHAR(512)', function (error) {
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.all('SELECT id FROM users', function (error, results) {
@@ -14,4 +13,3 @@ exports.up = function(db, callback) {
 exports.down = function(db, callback) {
    db.runSql('DELETE * FROM settings WHERE name="mail_config"', [ ], callback);
 };
-
@@ -1,6 +1,6 @@
 'use strict';

-var dbm = dbm || require('db-migrate');
+var async = require('async');

 exports.up = function(db, callback) {
    async.series([
@@ -71,4 +71,3 @@ exports.down = function(db, callback) {
        });
    });
 };
-
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps ADD COLUMN sso BOOLEAN DEFAULT 1', function (error) {
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE apps DROP COLUMN oauthProxy', function (error) {
@@ -1,5 +1,4 @@
-var dbm = global.dbm || require('db-migrate');
-var type = dbm.dataType;
+'use strict';

 exports.up = function(db, callback) {
    db.runSql('ALTER TABLE users DROP COLUMN showTutorial', function (error) {
@@ -0,0 +1,15 @@
+'use strict';
+
+exports.up = function(db, callback) {
+    db.runSql('ALTER TABLE apps ADD COLUMN debugModeJson TEXT', function (error) {
+        if (error) console.error(error);
+        callback(error);
+    });
+};
+
+exports.down = function(db, callback) {
+    db.runSql('ALTER TABLE apps DROP COLUMN debugModeJson ', function (error) {
+        if (error) console.error(error);
+        callback(error);
+    });
+};
@@ -0,0 +1,15 @@
+'use strict';
+
+exports.up = function(db, callback) {
+    db.runSql('ALTER TABLE backups MODIFY dependsOn TEXT', [], function (error) {
+        if (error) console.error(error);
+        callback(error);
+    });
+};
+
+exports.down = function(db, callback) {
+    db.runSql('ALTER TABLE backups MODIFY dependsOn VARCHAR(4096)', [], function (error) {
+        if (error) console.error(error);
+        callback(error);
+    });
+};
@@ -0,0 +1,16 @@
+'use strict';
+
+exports.up = function(db, callback) {
+    db.runSql('ALTER TABLE appAddonConfigs ADD COLUMN name VARCHAR(128)', function (error) {
+        if (error) console.error(error);
+        callback(error);
+    });
+};
+
+exports.down = function(db, callback) {
+    db.runSql('ALTER TABLE appAddonConfigs DROP COLUMN name', function (error) {
+        if (error) console.error(error);
+        callback(error);
+    });
+};
+
@@ -0,0 +1,14 @@
+'use strict';
+
+var url = require('url');
+
+exports.up = function(db, callback) {
+    var dbName = url.parse(process.env.DATABASE_URL).path.substr(1); // remove slash
+
+    // by default, mysql collates case insensitively. 'utf8_general_cs' is not available
+    db.runSql('ALTER DATABASE ' + dbName + '  DEFAULT CHARACTER SET=utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci', callback);
+};
+
+exports.down = function(db, callback) {
+    callback();
+};
@@ -0,0 +1,95 @@
+'use strict';
+
+var async = require('async');
+
+// from apps.js DO NOT UPDATE WHEN apps.js changes, as this is part of db migration!!
+function postProcess(result) {
+    try {
+        result.manifest = JSON.parse(result.manifestJson);
+        delete result.manifestJson;
+
+        result.oldConfig = JSON.parse(result.oldConfigJson);
+        delete result.oldConfigJson;
+
+        result.portBindings = { };
+        var hostPorts = result.hostPorts === null ? [ ] : result.hostPorts.split(',');
+        var environmentVariables = result.environmentVariables === null ? [ ] : result.environmentVariables.split(',');
+
+        delete result.hostPorts;
+        delete result.environmentVariables;
+
+        for (var i = 0; i < environmentVariables.length; i++) {
+            result.portBindings[environmentVariables[i]] = parseInt(hostPorts[i], 10);
+        }
+
+        result.accessRestriction = JSON.parse(result.accessRestrictionJson);
+        if (result.accessRestriction && !result.accessRestriction.users) result.accessRestriction.users = [];
+        delete result.accessRestrictionJson;
+
+        // TODO remove later once all apps have this attribute
+        result.xFrameOptions = result.xFrameOptions || 'SAMEORIGIN';
+
+        result.sso = !!result.sso; // make it bool
+
+        result.debugMode = JSON.parse(result.debugModeJson);
+        delete result.debugModeJson;
+    } catch (e) {
+        console.error('Failed to get restoreConfig for app.', e);
+        console.error('Falling back to empty values to make the update succeed.');
+        result.manifest = null;
+    }
+}
+
+// from apps.js DO NOT UPDATE WHEN apps.js changes, as this is part of db migration!!
+var APPS_FIELDS_PREFIXED = [ 'apps.id', 'apps.appStoreId', 'apps.installationState', 'apps.installationProgress', 'apps.runState',
+    'apps.health', 'apps.containerId', 'apps.manifestJson', 'apps.httpPort', 'apps.location', 'apps.dnsRecordId',
+    'apps.accessRestrictionJson', 'apps.lastBackupId', 'apps.oldConfigJson', 'apps.memoryLimit', 'apps.altDomain',
+    'apps.xFrameOptions', 'apps.sso', 'apps.debugModeJson' ].join(',');
+
+exports.up = function(db, callback) {
+    async.series([
+        db.runSql.bind(db, 'ALTER TABLE backups ADD COLUMN restoreConfigJson TEXT'),
+        // fill all the backups with restoreConfigs from current apps
+        function addRestoreConfigs(callback) {
+            console.log('Importing restoreConfigs');
+
+            var appQuery = 'SELECT ' + APPS_FIELDS_PREFIXED + ',' +
+                'GROUP_CONCAT(CAST(appPortBindings.hostPort AS CHAR(6))) AS hostPorts, GROUP_CONCAT(appPortBindings.environmentVariable) AS environmentVariables' +
+                ' FROM apps LEFT OUTER JOIN appPortBindings ON apps.id = appPortBindings.appId' +
+                ' GROUP BY apps.id ORDER BY apps.id';
+
+            db.all(appQuery, function (error, apps) {
+                if (error) return callback(error);
+
+                apps.forEach(postProcess);
+
+                async.eachSeries(apps, function (app, next) {
+                    if (app.manifest === null) return next();
+
+                    db.all('SELECT * FROM backups WHERE type="app" AND id LIKE "%app%\\_' + app.id + '\\_%"', function (error, backups) {
+                        if (error) return next(error);
+
+                        // from apps.js:getAppConfig()
+                        var restoreConfig = {
+                            manifest: app.manifest,
+                            location: app.location,
+                            accessRestriction: app.accessRestriction,
+                            portBindings: app.portBindings,
+                            memoryLimit: app.memoryLimit,
+                            xFrameOptions: app.xFrameOptions || 'SAMEORIGIN',
+                            altDomain: app.altDomain
+                        };
+
+                        async.eachSeries(backups, function (backup, next) {
+                            db.runSql('UPDATE backups SET restoreConfigJson=?,creationTime=creationTime WHERE id=?', [ JSON.stringify(restoreConfig), backup.id ], next);
+                        }, next);
+                    });
+                }, callback);
+            });
+        }
+    ], callback);
+};
+
+exports.down = function(db, callback) {
+    db.runSql('ALTER TABLE backups DROP COLUMN restoreConfigJson', callback);
+};
@@ -0,0 +1,22 @@
+'use strict';
+
+exports.up = function(db, callback) {
+    db.all('SELECT value FROM settings WHERE name="backup_config"', function (error, results) {
+        if (error || results.length === 0) return callback(error);
+
+        var backupConfig = JSON.parse(results[0].value);
+        if (backupConfig.provider === 'filesystem') {
+            backupConfig.retentionSecs = 2 * 24 * 60 * 60; // 2 days
+        } else if (backupConfig.provider === 's3') { // S3
+            backupConfig.retentionSecs = -1;
+        } else if (backupConfig.provider === 'caas') {
+            backupConfig.retentionSecs = 10 * 24 * 60 * 60; // 10 days
+        }
+        db.runSql('UPDATE settings SET value=? WHERE name="backup_config"', [ JSON.stringify(backupConfig) ], callback);
+
+    });
+};
+
+exports.down = function(db, callback) {
+  callback();
+};
--- a/Show More
+++ b/Show More