Fix crash when renewAll is called when cloudron is not setup yet

This works around issue in FreeOTP app which crashed when
the same name is used.

https://github.com/freeotp/freeotp-ios/issues/69
https://github.com/freeotp/freeotp-android/issues/69

.gitattributes

@@ -1,6 +1,7 @@
 # following files are skipped when exporting using git archive
 test export-ignore
-docs export-ignore
+.jshintrc export-ignore
+.gitlab export-ignore
 .gitattributes export-ignore
 .gitignore export-ignore
 

.gitignore

@@ -1,7 +1,6 @@
 node_modules/
 coverage/
 webadmin/dist/
-setup/splash/website/
 installer/src/certs/server.key
 
 # vim swap files

.gitlab/issue_templates/Bug.md

@@ -0,0 +1,6 @@
+Please do not use this issue tracker for support requests and bug reports.
+This issue tracker is used by the Cloudron development team to track actual
+bugs in the code.
+
+Please use the forum at https://forum.cloudron.io to report bugs. For
+confidential issues, please email us at support@cloudron.io.

.gitlab/issue_templates/Feature.md

@@ -0,0 +1,7 @@
+Please do not use this issue tracker for support requests and feature reports.
+This issue tracker is used by the Cloudron development team to track issues in
+the code.
+
+Please use the forum at https://forum.cloudron.io to report bugs. For
+confidential issues, please email us at support@cloudron.io.
+

.jshintrc

@@ -2,6 +2,7 @@
     "node": true,
     "browser": true,
     "unused": true,
+    "multistr": true,
     "globalstrict": true,
     "predef": [ "angular", "$" ],
     "esnext": true

CHANGES

@@ -691,3 +691,610 @@
 * Fix bug where DNS mail record warning was shown by mistake
 * Make cloudron-setup finish with `manual` DNS provider
 
+[0.92.1]
+* Remove DO specific grub cmd line
+* Fix License text
+
+[0.93.0]
+* Smoother upgrades
+
+[0.94.0]
+* Cloudron domain can now be set after installation
+* Backups are now organized by directory
+* Document upgrading from Filesystem backend
+* Send certificate renewal errors, OOM errors to cloudron admins
+* Email bounce alerts are sent to the Cloudron owner
+
+[0.94.1]
+* Suppress upgrade emails
+* Enable unattended upgrades
+* Standardize on using devicemapper for docker storage backend
+* Show detailed backup progress
+* Fix DNSBL issue in mail container
+* Fix issue where bounce emails were not sent to aliases
+* 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
+
+[1.8.5]
+* Fix issues where unused addons were not cleaned on an app update causing uninstall to fail
+* Change UI text from 'Waiting' to 'Pending'
+
+[1.9.0]
+* Prepare Cloudron for supporting multiple domains
+* Add Cloudron restore UI
+* Do not put app in errored state if backup fails
+* Display backup progress in CaaS
+* Add Google Cloud Storage backend for backups
+* Update node to 8.9.3 LTS
+* Set max email recepient limit (in outgoing emails) to 500
+
+[1.9.1]
+* Prepare Cloudron for supporting multiple domains
+* Add Cloudron restore UI
+* Do not put app in errored state if backup fails
+* Display backup progress in CaaS
+* Add Google Cloud Storage backend for backups
+* Update node to 8.9.3 LTS
+* Set max email recepient limit (in outgoing emails) to 500
+* Put terminal and app logs viewer to separate window
+
+[1.9.2]
+* Prepare Cloudron for supporting multiple domains
+* Add Cloudron restore UI
+* Do not put app in errored state if backup fails
+* Display backup progress in CaaS
+* Add Google Cloud Storage backend for backups
+* Update node to 8.9.3 LTS
+* Set max email recepient limit (in outgoing emails) to 500
+* Put terminal and app logs viewer to separate window
+
+[1.9.3]
+* Prepare Cloudron for supporting multiple domains
+* Add Cloudron restore UI
+* Do not put app in errored state if backup fails
+* Display backup progress in CaaS
+* Add Google Cloud Storage backend for backups
+* Update node to 8.9.3 LTS
+* Set max email recepient limit (in outgoing emails) to 500
+* Put terminal and app logs viewer to separate window
+
+[1.9.4]
+* Fix typo causing LE cert renewals to fail
+
+[1.10.0]
+* Migrate mailboxes to support multiple domains
+* Update addon containers to latest versions
+* Add DigitalOcean Spaces region Singapore 1 (SGP1)
+* Configure Exoscale SOS to use new SOS NG endpoint
+* Fix S3 storage backend CopySource encoding rules
+
+[1.10.1]
+* Migrate mailboxes to support multiple domains
+* Update addon containers to latest versions
+* Add DigitalOcean Spaces region Singapore 1 (SGP1)
+* Configure Exoscale SOS to use new SOS NG endpoint
+* Fix S3 storage backend CopySource encoding rules
+
+[1.10.2]
+* Migrate mailboxes to support multiple domains
+* Update addon containers to latest versions
+* Add DigitalOcean Spaces region Singapore 1 (SGP1)
+* Configure Exoscale SOS to use new SOS NG endpoint
+* Fix S3 storage backend CopySource encoding rules
+
+[1.11.0]
+* Update Haraka to 2.8.17 to fix various crashes
+* Report dependency error for clone if backup or domain was not found
+* Enable auto-updates for major versions
+
+[2.0.0]
+* Multi-domain support
+* Update Haraka to 2.8.18
+* Split box and app autoupdate pattern settings
+* Stop and disable any pre-installed postfix server
+* Migrate altDomain as a manual DNS provider
+* Use node's native dns resolve instead of dig
+* DNS records can now be a A record or a CNAME record
+* Fix generation of fallback certificates to include naked domain
+* Merge multi-string DKIM records
+* scheduler: do not start cron jobs all at once
+* scheduler: give cron jobs a grace period of 30 minutes to complete
+
+[2.0.1]
+* Multi-domain support
+* Update Haraka to 2.8.18
+* Split box and app autoupdate pattern settings
+* Stop and disable any pre-installed postfix server
+* Migrate altDomain as a manual DNS provider
+* Use node's native dns resolve instead of dig
+* DNS records can now be a A record or a CNAME record
+* Fix generation of fallback certificates to include naked domain
+* Merge multi-string DKIM records
+* scheduler: do not start cron jobs all at once
+* scheduler: give cron jobs a grace period of 30 minutes to complete
+* Rework the eventlog view
+* App clone now clones the robotsTxt and backup settings
+
+[2.1.0]
+* Make S3 backend work reliably with slow internet connections
+* Update docker to 18.03.0-ce
+* Finalize the Email and Mailbox API
+* Move mailbox settings from users to email view
+* mail: fix issue where hosts with valid SPF for a Cloudron domain are unable to send mail to Cloudron
+* mail: fix crash when bounce emails have a null sender
+* Add CSP header for dashboard
+* Add support for installing private docker images
+
+[2.1.1]
+* Make S3 backend work reliably with slow internet connections
+* Update docker to 18.03.0-ce
+* Finalize the Email and Mailbox API
+* Move mailbox settings from users to email view
+* mail: fix issue where hosts with valid SPF for a Cloudron domain are unable to send mail to Cloudron
+* mail: fix crash when bounce emails have a null sender
+* Add CSP header for dashboard
+* Add support for installing private docker images
+
+[2.2.0]
+* Add 2FA support for the admin dashboard
+* Cleanup scope management in REST API
+* Enhance user creation API to take a password
+* Relax restriction on mailbox names now that it is decoupled from user management
+
+[2.2.1]
+* Add 2FA support for the admin dashboard
+* Add Gandi & GoDaddy DNS providers
+* Fix zone detection logic on Route53 accounts with more than 100 zones
+* Warn using when disabling email
+* Cleanup scope management in REST API
+* Enhance user creation API to take a password
+* Relax restriction on mailbox names now that it is decoupled from user management
+* Fix issue where mail container incorrectly advertised CRAM-MD5 support
+
+[2.3.0]
+* Add Name.com DNS provider
+* Fix issue where account setup page was crashing
+* Add advanced DNS configuration UI
+* Preserve addon/database configuration across app updates and restores
+* ManageSieve port now offers STARTTLS
+
+[2.3.1]
+* Add Name.com DNS provider
+* Fix issue where account setup page was crashing
+* Add advanced DNS configuration UI
+* Preserve addon/database configuration across app updates and restores
+* ManageSieve port now offers STARTTLS
+* Allow mailbox name to be set for apps
+* Rework the Email server UI
+* Add the ability to manually trigger a backup of an application
+* Enable/disable mail from validation within UI
+* Allow setting app visibility for non-SSO apps
+* Add Clone UI
+
+[2.3.2]
+* Fix issue where multi-db apps were not provisioned correctly
+* Improve setup, restore views to have field labels
+

LICENSE

@@ -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  yellowtent
+    Copyright (C) 2016,2017,2018 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

README.md

@@ -9,10 +9,6 @@ a complex task.
 We are building the ultimate platform for self-hosting web apps. The Cloudron allows
 anyone to effortlessly host web applications on their server on their own terms.
 
-Support us on
-[![Flattr Cloudron](https://button.flattr.com/flattr-badge-large.png)](https://flattr.com/submit/auto?user_id=cloudron&url=https://cloudron.io&title=Cloudron&tags=opensource&category=software)
-or [pay us a coffee](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=8982CKNM46D8U)
-
 ## Features
 
 * Single click install for apps. Check out the [App Store](https://cloudron.io/appstore.html).
@@ -33,9 +29,9 @@ or [pay us a coffee](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_
 * Trivially migrate to another server keeping your apps and data (for example, switch your
   infrastructure provider or move to a bigger server).
 
-* Comprehensive [REST API](https://cloudron.io/references/api.html).
+* Comprehensive [REST API](https://cloudron.io/documentation/developer/api/).
 
-* [CLI](https://git.cloudron.io/cloudron/cloudron-cli) to configure apps.
+* [CLI](https://cloudron.io/documentation/cli/) to configure apps.
 
 * Alerts, audit logs, graphs, dns management ... and much more
 
@@ -46,34 +42,28 @@ 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/documentation/installation/) - [Pricing](https://cloudron.io/pricing.html)
+* [Managed Hosting](https://cloudron.io/managed.html)
+
+**Note:** This repo is a small part of what gets installed on your server - there is
+the dashboard, database addons, graph container, base image etc. Cloudron also relies
+on external services such as the App Store for apps to be installed. As such, don't
+clone this repo and npm install and expect something to work.
 
 ## Documentation
 
-* [User manual](https://cloudron.io/references/usermanual.html)
-* [Developer docs](https://cloudron.io/documentation.html)
-* [Architecture](https://cloudron.io/references/architecture.html)
+* [Documentation](https://cloudron.io/documentation/)
 
 ## Related repos
 
 The [base image repo](https://git.cloudron.io/cloudron/docker-base-image) is the parent image of all
 the containers in the Cloudron.
 
-The [graphite repo](https://git.cloudron.io/cloudron/docker-graphite) contains the graphite code
-that collects metrics for graphs.
-
-The addons are located in separate repositories
-* [Redis](https://git.cloudron.io/cloudron/redis-addon)
-* [Postgresql](https://git.cloudron.io/cloudron/postgresql-addon)
-* [MySQL](https://git.cloudron.io/cloudron/mysql-addon)
-* [Mongodb](https://git.cloudron.io/cloudron/mongodb-addon)
-* [Mail](https://git.cloudron.io/cloudron/mail-addon)
-
 ## Community
 
-* [Chat](https://chat.cloudron.io/)
+* [Forum](https://forum.cloudron.io/)
 * [Support](mailto:support@cloudron.io)
 

baseimage/createAMI

@@ -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 ""

baseimage/createDOImage

@@ -10,7 +10,7 @@ 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"
 
-installer_revision=$(git rev-parse HEAD)
+revision=$(git rev-parse HEAD)
 box_name=""
 server_id=""
 server_ip=""
@@ -28,7 +28,7 @@ eval set -- "${args}"
 while true; do
     case "$1" in
     --env) deploy_env="$2"; shift 2;;
-    --revision) installer_revision="$2"; shift 2;;
+    --revision) revision="$2"; shift 2;;
     --name) box_name="$2"; destroy_server="no"; shift 2;;
     --no-destroy) destroy_server="no"; shift 2;;
     --) break;;
@@ -73,7 +73,7 @@ function get_pretty_revision() {
 }
 
 now=$(date "+%Y-%m-%d-%H%M%S")
-pretty_revision=$(get_pretty_revision "${installer_revision}")
+pretty_revision=$(get_pretty_revision "${revision}")
 
 if [[ -z "${box_name}" ]]; then
     # if you change this, change the regexp is appstore/janitor.js
@@ -138,13 +138,13 @@ cd "${SOURCE_DIR}"
 git archive --format=tar HEAD | $ssh22 "root@${server_ip}" "cat - > /tmp/box.tar.gz"
 
 echo "Executing init script"
-if ! $ssh22 "root@${server_ip}" "/bin/bash /root/initializeBaseUbuntuImage.sh ${installer_revision} caas"; then
+if ! $ssh22 "root@${server_ip}" "/bin/bash /root/initializeBaseUbuntuImage.sh caas"; then
     echo "Init script failed"
     exit 1
 fi
 
 echo "Shutting down server with id : ${server_id}"
-$ssh202 "root@${server_ip}" "shutdown -f now" || true # shutdown sometimes terminates ssh connection immediately making this command fail
+$ssh22 "root@${server_ip}" "shutdown -f now" || true # shutdown sometimes terminates ssh connection immediately making this command fail
 
 # wait 10 secs for actual shutdown
 echo "Waiting for 10 seconds for server to shutdown"

baseimage/digitalocean.sh

@@ -29,9 +29,9 @@ function create_droplet() {
     local ssh_key_id="$1"
     local box_name="$2"
 
-    local image_region="sfo1"
+    local image_region="sfo2"
     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}"
 

baseimage/initializeBaseUbuntuImage.sh

@@ -2,293 +2,110 @@
 
 set -euv -o pipefail
 
-readonly USER=yellowtent
-readonly USER_HOME="/home/${USER}"
-readonly INSTALLER_SOURCE_DIR="${USER_HOME}/installer"
-readonly INSTALLER_REVISION="${1:-master}"
-readonly PROVIDER="${2:-generic}"
-readonly USER_DATA_FILE="/root/user_data.img"
-readonly USER_DATA_DIR="/home/yellowtent/data"
-
 readonly SOURCE_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 
+readonly arg_provider="${1:-generic}"
+readonly arg_infraversionpath="${SOURCE_DIR}/${2:-}"
+
 function die {
     echo $1
     exit 1
 }
 
-[[ "$(systemd --version 2>&1)" == *"systemd 229"* ]] || die "Expecting systemd to be 229"
-
-echo "==== Create User ${USER} ===="
-if ! id "${USER}"; then
-    useradd "${USER}" -m
-fi
-
 export DEBIAN_FRONTEND=noninteractive
 
-echo "=== Upgrade ==="
 apt-get -o Dpkg::Options::="--force-confdef" update -y
 apt-get -o Dpkg::Options::="--force-confdef" dist-upgrade -y
-apt-get install -y curl iptables
 
-# Setup firewall before everything. docker creates it's own chain and the -X below will remove it
-# Do NOT use iptables-persistent because it's startup ordering conflicts with docker
-echo "=== Setting up firewall ==="
-# clear tables and set default policy
-iptables -F # flush all chains
-iptables -X # delete all chains
-# default policy for filter table
-iptables -P INPUT ACCEPT # accept by default to allow network drives to persist
-iptables -P FORWARD ACCEPT # TODO: disable icc and make this as reject
-iptables -P OUTPUT ACCEPT
+echo "==> Installing required packages"
 
-# NOTE: keep these in sync with src/apps.js validatePortBindings
-# allow ssh, http, https, ping, dns
-iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-# caas has ssh on port 202
-if [[ "${PROVIDER}" == "caas" ]]; then
-    iptables -A INPUT -p tcp -m tcp -m multiport --dports 25,80,202,443,587,993,4190 -j ACCEPT
-else
-    iptables -A INPUT -p tcp -m tcp -m multiport --dports 25,80,22,443,587,993,4190 -j ACCEPT
-fi
-iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-iptables -A INPUT -p udp --sport 53 -j ACCEPT
-iptables -A INPUT -s 172.18.0.0/16 -j ACCEPT # required to accept any connections from apps to our IP:<public port>
+debconf-set-selections <<< 'mysql-server mysql-server/root_password password password'
+debconf-set-selections <<< 'mysql-server mysql-server/root_password_again password password'
 
-# loopback
-iptables -A INPUT -i lo -j ACCEPT
-iptables -A OUTPUT -o lo -j ACCEPT
+# this enables automatic security upgrades (https://help.ubuntu.com/community/AutomaticSecurityUpdates)
+apt-get -y install \
+    acl \
+    awscli \
+    build-essential \
+    cron \
+    curl \
+    dmsetup \
+    iptables \
+    logrotate \
+    mysql-server-5.7 \
+    nginx-full \
+    openssh-server \
+    pwgen \
+    rcconf \
+    swaks \
+    unattended-upgrades \
+    unbound \
+    xfsprogs
 
-# prevent DoS
-# iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
+# 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
 
-# log dropped incoming. keep this at the end of all the rules
-iptables -N LOGGING # new chain
-iptables -A INPUT -j LOGGING # last rule in INPUT chain (log and drop)
-iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables Packet Dropped: " --log-level 7
-iptables -A LOGGING -j DROP
-
-echo "==== Install btrfs tools ==="
-apt-get -y install btrfs-tools
-
-echo "==== Install docker ===="
-# install docker from binary to pin it to a specific version. the current debian repo does not allow pinning
-# IMPORTANT: docker 1.11.x breaks the --dns option hack that we use below
-curl https://get.docker.com/builds/Linux/x86_64/docker-1.10.2 > /usr/bin/docker
-apt-get -y install aufs-tools
-chmod +x /usr/bin/docker
-groupadd docker
-cat > /etc/systemd/system/docker.socket <<EOF
-[Unit]
-Description=Docker Socket for the API
-PartOf=docker.service
-
-[Socket]
-ListenStream=/var/run/docker.sock
-SocketMode=0660
-SocketUser=root
-SocketGroup=docker
-
-[Install]
-WantedBy=sockets.target
-EOF
-cat > /etc/systemd/system/docker.service <<EOF
-[Unit]
-Description=Docker Application Container Engine
-After=network.target docker.socket
-Requires=docker.socket
-
-[Service]
-ExecStart=/usr/bin/docker daemon -H fd:// --log-driver=journald --exec-opt native.cgroupdriver=cgroupfs --dns 127.0.0.1 --dns-search=.
-MountFlags=slave
-LimitNOFILE=1048576
-LimitNPROC=1048576
-LimitCORE=infinity
-
-[Install]
-WantedBy=multi-user.target
-EOF
-
-echo "=== Setup btrfs data ==="
-if ! grep -q loop.ko /lib/modules/`uname -r`/modules.builtin; then
-    # on scaleway loop is not built-in
-    echo "loop" >> /etc/modules
-    modprobe loop
-fi
-truncate -s "8192m" "${USER_DATA_FILE}" # 8gb start (this will get resized dynamically by cloudron-system-setup.service)
-mkfs.btrfs -L UserHome "${USER_DATA_FILE}"
-mkdir -p "${USER_DATA_DIR}"
-mount -t btrfs -o loop,nosuid "${USER_DATA_FILE}" ${USER_DATA_DIR}
-
-systemctl daemon-reload
-systemctl enable docker
-systemctl start docker
-
-# give docker sometime to start up and create iptables rules
-# those rules come in after docker has started, and we want to wait for them to be sure iptables-save has all of them
-sleep 10
-
-# Disable forwarding to metadata route from containers
-iptables -I FORWARD -d 169.254.169.254 -j DROP
-
-# ubuntu will restore iptables from this file automatically. this is here so that docker's chain is saved to this file
-mkdir /etc/iptables && iptables-save > /etc/iptables/rules.v4
-
-echo "=== Enable memory accounting =="
-if [[ "${PROVIDER}" == "digitalocean" ]] || [[ "${PROVIDER}" == "caas" ]]; then
-    sed -e 's/GRUB_CMDLINE_LINUX=.*/GRUB_CMDLINE_LINUX="console=tty1 root=LABEL=DOROOT notsc clocksource=kvm-clock net.ifnames=0 cgroup_enable=memory swapaccount=1 panic_on_oops=1 panic=5"/' -i /etc/default/grub
-    update-grub
-elif [[ "${PROVIDER}" == "ec2" ]] || [[ "${PROVIDER}" == "generic" ]]; then
-    sed -e 's/GRUB_CMDLINE_LINUX=.*/GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1 panic_on_oops=1 panic=5"/' -i /etc/default/grub
-    update-grub
-fi
-
-# now add the user to the docker group
-usermod "${USER}" -a -G docker
-
-echo "==== Install nodejs ===="
-# Cannot use anything above 4.1.1 - https://github.com/nodejs/node/issues/3803
-mkdir -p /usr/local/node-4.1.1
-curl -sL https://nodejs.org/dist/v4.1.1/node-v4.1.1-linux-x64.tar.gz | tar zxvf - --strip-components=1 -C /usr/local/node-4.1.1
-ln -s /usr/local/node-4.1.1/bin/node /usr/bin/node
-ln -s /usr/local/node-4.1.1/bin/npm /usr/bin/npm
+echo "==> Installing node.js"
+mkdir -p /usr/local/node-8.9.3
+curl -sL https://nodejs.org/dist/v8.9.3/node-v8.9.3-linux-x64.tar.gz | tar zxvf - --strip-components=1 -C /usr/local/node-8.9.3
+ln -sf /usr/local/node-8.9.3/bin/node /usr/bin/node
+ln -sf /usr/local/node-8.9.3/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"
 
-echo "==== Downloading docker images ===="
-if [ -f ${SOURCE_DIR}/infra_version.js ]; then
-    images=$(node -e "var i = require('${SOURCE_DIR}/infra_version.js'); console.log(i.baseImages.join(' '), Object.keys(i.images).map(function (x) { return i.images[x].tag; }).join(' '));")
+# https://docs.docker.com/engine/installation/linux/ubuntulinux/
+echo "==> Installing Docker"
 
-    echo "Pulling images: ${images}"
-    for image in ${images}; do
-        docker pull "${image}"
-    done
-else
-    echo "No infra_versions.js found, skipping image download"
+# 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}" != "overlay2" ]]; then
+    echo "Docker is using "${storage_driver}" instead of overlay2"
+    exit 1
 fi
 
-echo "==== Install nginx ===="
-apt-get -y install nginx-full
-[[ "$(nginx -v 2>&1)" == *"nginx/1.10."* ]] || die "Expecting nginx version to be 1.10.x"
+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
 
-echo "==== Install build-essential ===="
-apt-get -y install build-essential rcconf
+echo "==> Downloading docker images"
+if [ ! -f "${arg_infraversionpath}/infra_version.js" ]; then
+    echo "No infra_versions.js found"
+    exit 1
+fi
 
-echo "==== Install mysql ===="
-debconf-set-selections <<< 'mysql-server mysql-server/root_password password password'
-debconf-set-selections <<< 'mysql-server mysql-server/root_password_again password password'
-apt-get -y install mysql-server-5.7
-[[ "$(mysqld --version 2>&1)" == *"5.7."* ]] || die "Expecting mysql version to be 5.7.x"
+images=$(node -e "var i = require('${arg_infraversionpath}/infra_version.js'); console.log(i.baseImages.join(' '), Object.keys(i.images).map(function (x) { return i.images[x].tag; }).join(' '));")
 
-echo "==== Install pwgen and swaks awscli ===="
-apt-get -y install pwgen swaks awscli
+echo -e "\tPulling docker images: ${images}"
+for image in ${images}; do
+    docker pull "${image}"
+done
 
-echo "==== Install collectd ==="
+echo "==> Install collectd"
 if ! apt-get install -y collectd collectd-utils; then
     # FQDNLookup is true in default debian config. The box code has a custom collectd.conf that fixes this
     echo "Failed to install collectd. Presumably because of http://mailman.verplant.org/pipermail/collectd/2015-March/006491.html"
     sed -e 's/^FQDNLookup true/FQDNLookup false/' -i /etc/collectd/collectd.conf
 fi
-update-rc.d -f collectd remove
 
-# this simply makes it explicit that we run logrotate via cron. it's already part of base ubuntu
-echo "==== Install logrotate ==="
-apt-get install -y cron logrotate
-systemctl enable cron
+# 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
 
-echo "=== Prepare installer revision - ${INSTALLER_REVISION}) ==="
-rm -rf /tmp/box && mkdir -p /tmp/box
-curl "https://git.cloudron.io/cloudron/box/repository/archive.tar.gz?ref=${INSTALLER_REVISION}" | tar zxvf - --strip-components=1 -C /tmp/box
-mkdir -p "${INSTALLER_SOURCE_DIR}"
-cp -rf /tmp/box/installer/* "${INSTALLER_SOURCE_DIR}" && rm -rf /tmp/box
-chown "${USER}:${USER}" -R "${INSTALLER_SOURCE_DIR}"
-echo "${INSTALLER_REVISION}" > "${INSTALLER_SOURCE_DIR}/REVISION"
+# on ovh images dnsmasq seems to run by default
+systemctl stop dnsmasq || true
+systemctl disable dnsmasq || true
 
-echo "==== Install cloudron-version tool ===="
-npm install -g cloudron-version@0.1.1
+# on ssdnodes postfix seems to run by default
+systemctl stop postfix || true
+systemctl disable postfix || true
 
-# Restore iptables before docker
-echo "==== Install iptables-restore systemd script ===="
-cat > /etc/systemd/system/iptables-restore.service <<EOF
-[Unit]
-Description=IPTables Restore
-Before=docker.service
-
-[Service]
-Type=oneshot
-ExecStart=/sbin/iptables-restore /etc/iptables/rules.v4
-RemainAfterExit=yes
-
-[Install]
-WantedBy=multi-user.target
-EOF
-
-# Allocate swap files
-# https://bbs.archlinux.org/viewtopic.php?id=194792 ensures this runs after do-resize.service
-# On ubuntu ec2 we use cloud-init https://wiki.archlinux.org/index.php/Cloud-init
-echo "==== Install cloudron-system-setup systemd script ===="
-cat > /etc/systemd/system/cloudron-system-setup.service <<EOF
-[Unit]
-Description=Box Setup
-Before=docker.service collectd.service mysql.service sshd.service nginx.service
-After=cloud-init.service
-
-[Service]
-Type=oneshot
-ExecStart="${INSTALLER_SOURCE_DIR}/systemd/cloudron-system-setup.sh"
-RemainAfterExit=yes
-
-[Install]
-WantedBy=multi-user.target
-EOF
-
-systemctl daemon-reload
-systemctl enable iptables-restore
-systemctl enable cloudron-system-setup
-
-# Configure systemd
-sed -e "s/^#SystemMaxUse=.*$/SystemMaxUse=100M/" \
-    -e "s/^#ForwardToSyslog=.*$/ForwardToSyslog=no/" \
-    -i /etc/systemd/journald.conf
-
-# When rotating logs, systemd kills journald too soon sometimes
-# See https://github.com/systemd/systemd/issues/1353 (this is upstream default)
-sed -e "s/^WatchdogSec=.*$/WatchdogSec=3min/" \
-    -i /lib/systemd/system/systemd-journald.service
-
-sync
-
-# Configure time
-sed -e 's/^#NTP=/NTP=0.ubuntu.pool.ntp.org 1.ubuntu.pool.ntp.org 2.ubuntu.pool.ntp.org 3.ubuntu.pool.ntp.org/' -i /etc/systemd/timesyncd.conf
-timedatectl set-ntp 1
-timedatectl set-timezone UTC
-
-# Give user access to system logs
-apt-get -y install acl
-usermod -a -G systemd-journal ${USER}
-mkdir -p /var/log/journal  # in some images, this directory is not created making system log to /run/systemd instead
-chown root:systemd-journal /var/log/journal
-systemctl restart systemd-journald
-setfacl -n -m u:${USER}:r /var/log/journal/*/system.journal
-
-# DO uses Google nameservers by default. This causes RBL queries to fail (host 2.0.0.127.zen.spamhaus.org)
-# We do not use dnsmasq because it is not a recursive resolver and defaults to the value in the interfaces file (which is Google DNS!)
-echo "==== Install unbound DNS ==="
-apt-get -y install unbound
-
-echo "==== Install ssh ==="
-apt-get -y install openssh-server
-
-# caas has ssh on port 202 and we disable password login
-if [[ "${PROVIDER}" == "caas" ]]; then
-    # https://stackoverflow.com/questions/4348166/using-with-sed on why ? must be escaped
-    sed -e 's/^#\?PermitRootLogin .*/PermitRootLogin without-password/g' \
-        -e 's/^#\?PermitEmptyPasswords .*/PermitEmptyPasswords no/g' \
-        -e 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/g' \
-        -e 's/^#\?Port .*/Port 202/g' \
-        -i /etc/ssh/sshd_config
-
-    # required so we can connect to this machine since port 22 is blocked by iptables by now
-    systemctl reload sshd
-fi

box.js

@@ -5,17 +5,15 @@
 require('supererror')({ splatchError: true });
 
 // remove timestamp from debug() based output
-require('debug').formatArgs = function formatArgs() {
-    arguments[0] = this.namespace + ' ' + arguments[0];
-    return arguments;
+require('debug').formatArgs = function formatArgs(args) {
+    args[0] = this.namespace + ' ' + args[0];
 };
 
 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('==========================================');
@@ -34,7 +32,6 @@ console.log();
 async.series([
     server.start,
     ldap.start,
-    simpleauth.start,
     appHealthMonitor.start,
 ], function (error) {
     if (error) {
@@ -49,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);
 });

crashnotifierservice.js

@@ -2,6 +2,8 @@
 
 'use strict';
 
+var database = require('./src/database.js');
+
 var sendFailureLogs = require('./src/logcollector').sendFailureLogs;
 
 function main() {
@@ -10,7 +12,12 @@ function main() {
     var processName = process.argv[2];
     console.log('Started crash notifier for', processName);
 
-    sendFailureLogs(processName, { unit: processName });
+    // mailer needs the db
+    database.initialize(function (error) {
+        if (error) return console.error('Cannot connect to database. Unable to send crash log.', error);
+
+        sendFailureLogs(processName, { unit: processName });
+    });
 }
 
 main();

docs/references/addons.md

@@ -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"
-```

docs/references/architecture.md

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

docs/references/authentication.md

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

docs/references/baseimage.md

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

docs/references/bestpractices.md

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

docs/references/button.md

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

docs/references/manifest.md

@@ -1,468 +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 Inc <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 port
-is exposed to the world via subdomain/location that the user chooses at installation time. 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"
-```

docs/references/recipes.md

@@ -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
-```

docs/references/selfhosting.md

@@ -1,380 +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/)
-* [Linode](https://www.linode.com/)
-* [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://git.cloudron.io/cloudron/box/raw/3d4e3638/scripts/cloudron-setup
-chmod +x cloudron-setup
-./cloudron-setup --domain <domain> --provider <digitalocean|ec2|generic|scaleway>
-```
-
-The setup will take around 10-15 minutes.
-
-`cloudron-setup` takes the following arguments:
-
-* `--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.
-
-* `--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:
-
-* `--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 `https://my.<domain>` to complete the installation.
-
-Please note the following:
-
-1. The website should already have a valid TLS certificate. If you see any certificate warnings, it means your Cloudron was not created correctly.
-
-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 `appbackup_`. The platform state is backed up independently with the
-prefix `backup_`.
-
-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>`.
-
-    * 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 and thus involves creating the Cloudron from scratch.
-This process involves creating a new server with the latest code and restoring it from the
-last backup. Currently only Cloudrons using the **S3 backup storage** support upgrades.
-Read more about [backup storage](#s3), otherwise contact us in our [chat](https://chat.cloudron.io).
-
-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 latest box backup (files starting with `backup_`) public. 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/>
-
-* 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://git.cloudron.io/cloudron/box/raw/3d4e3638/scripts/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).

docs/references/usermanual.md

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

docs/tutorials/node.md

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

docs/tutorials/packaging.md

@@ -1,492 +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
-```
-
-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>`.
-
-# 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)

gulpfile.js

@@ -1,175 +0,0 @@
-/* jslint node:true */
-
-'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'),
-    autoprefixer = require('gulp-autoprefixer'),
-    argv = require('yargs').argv;
-
-gulp.task('3rdparty', function () {
-    gulp.src([
-        'webadmin/src/3rdparty/**/*.js',
-        'webadmin/src/3rdparty/**/*.map',
-        'webadmin/src/3rdparty/**/*.css',
-        'webadmin/src/3rdparty/**/*.otf',
-        'webadmin/src/3rdparty/**/*.eot',
-        'webadmin/src/3rdparty/**/*.svg',
-        'webadmin/src/3rdparty/**/*.gif',
-        'webadmin/src/3rdparty/**/*.ttf',
-        'webadmin/src/3rdparty/**/*.woff',
-        'webadmin/src/3rdparty/**/*.woff2'
-        ])
-        .pipe(gulp.dest('webadmin/dist/3rdparty/'))
-        .pipe(gulp.dest('setup/splash/website/3rdparty'));
-
-    gulp.src('node_modules/bootstrap-sass/assets/javascripts/bootstrap.min.js')
-        .pipe(gulp.dest('webadmin/dist/3rdparty/js'))
-        .pipe(gulp.dest('setup/splash/website/3rdparty/js'));
-});
-
-
-// --------------
-// JavaScript
-// --------------
-
-gulp.task('js', ['js-index', 'js-setup', 'js-update'], function () {});
-
-var oauth = {
-    clientId: argv.clientId || 'cid-webadmin',
-    clientSecret: argv.clientSecret || 'unused',
-    apiOrigin: argv.apiOrigin || ''
-};
-
-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();
-
-
-gulp.task('js-index', function () {
-    // needs special treatment for error handling
-    var uglifyer = uglify();
-    uglifyer.on('error', function (error) {
-        console.error(error);
-    });
-
-    gulp.src([
-        'webadmin/src/js/index.js',
-        'webadmin/src/js/client.js',
-        'webadmin/src/js/appstore.js',
-        'webadmin/src/js/main.js',
-        'webadmin/src/views/*.js'
-        ])
-        .pipe(ejs({ oauth: oauth }, { ext: '.js' }))
-        .pipe(sourcemaps.init())
-        .pipe(concat('index.js', { newLine: ';' }))
-        .pipe(uglifyer)
-        .pipe(sourcemaps.write())
-        .pipe(gulp.dest('webadmin/dist/js'));
-});
-
-gulp.task('js-setup', function () {
-    // needs special treatment for error handling
-    var uglifyer = uglify();
-    uglifyer.on('error', function (error) {
-        console.error(error);
-    });
-
-    gulp.src(['webadmin/src/js/setup.js', 'webadmin/src/js/client.js'])
-        .pipe(ejs({ oauth: oauth }, { ext: '.js' }))
-        .pipe(sourcemaps.init())
-        .pipe(concat('setup.js', { newLine: ';' }))
-        .pipe(uglifyer)
-        .pipe(sourcemaps.write())
-        .pipe(gulp.dest('webadmin/dist/js'));
-});
-
-gulp.task('js-update', function () {
-    // needs special treatment for error handling
-    var uglifyer = uglify();
-    uglifyer.on('error', function (error) {
-        console.error(error);
-    });
-
-    gulp.src(['webadmin/src/js/update.js'])
-        .pipe(sourcemaps.init())
-        .pipe(uglifyer)
-        .pipe(sourcemaps.write())
-        .pipe(gulp.dest('webadmin/dist/js'))
-        .pipe(gulp.dest('setup/splash/website/js'));
-});
-
-
-// --------------
-// HTML
-// --------------
-
-gulp.task('html', ['html-views', 'html-update', 'html-templates'], function () {
-    return gulp.src('webadmin/src/*.html').pipe(gulp.dest('webadmin/dist'));
-});
-
-gulp.task('html-update', function () {
-    return gulp.src(['webadmin/src/update.html']).pipe(gulp.dest('setup/splash/website'));
-});
-
-gulp.task('html-views', function () {
-    return gulp.src('webadmin/src/views/**/*.html').pipe(gulp.dest('webadmin/dist/views'));
-});
-
-gulp.task('html-templates', function () {
-    return gulp.src('webadmin/src/templates/**/*.html').pipe(gulp.dest('webadmin/dist/templates'));
-});
-
-// --------------
-// CSS
-// --------------
-
-gulp.task('css', function () {
-    return gulp.src('webadmin/src/*.scss')
-        .pipe(sourcemaps.init())
-        .pipe(sass({ includePaths: ['node_modules/bootstrap-sass/assets/stylesheets/'] }).on('error', sass.logError))
-        .pipe(autoprefixer())
-        .pipe(cssnano())
-        .pipe(sourcemaps.write())
-        .pipe(gulp.dest('webadmin/dist'))
-        .pipe(gulp.dest('setup/splash/website'));
-});
-
-gulp.task('images', function () {
-    return gulp.src('webadmin/src/img/**')
-        .pipe(gulp.dest('webadmin/dist/img'));
-});
-
-// --------------
-// Utilities
-// --------------
-
-gulp.task('watch', ['default'], function () {
-    gulp.watch(['webadmin/src/*.scss'], ['css']);
-    gulp.watch(['webadmin/src/img/*'], ['images']);
-    gulp.watch(['webadmin/src/**/*.html'], ['html']);
-    gulp.watch(['webadmin/src/views/*.html'], ['html-views']);
-    gulp.watch(['webadmin/src/templates/*.html'], ['html-templates']);
-    gulp.watch(['webadmin/src/js/update.js'], ['js-update']);
-    gulp.watch(['webadmin/src/js/setup.js', 'webadmin/src/js/client.js'], ['js-setup']);
-    gulp.watch(['webadmin/src/js/index.js', 'webadmin/src/js/client.js', 'webadmin/src/js/appstore.js', 'webadmin/src/js/main.js', 'webadmin/src/views/*.js'], ['js-index']);
-    gulp.watch(['webadmin/src/3rdparty/**/*'], ['3rdparty']);
-});
-
-gulp.task('clean', function () {
-    del.sync(['webadmin/dist', 'setup/splash/website']);
-});
-
-gulp.task('default', ['clean', 'html', 'js', '3rdparty', 'images', 'css'], function () {});
-
-gulp.task('develop', ['watch'], serve({ root: 'webadmin/dist', port: 4000 }));

installer/README.md

@@ -1,27 +0,0 @@
-# Installer
-
-This subfolder contains all resources, which persist across a Cloudron update.
-Only code and assets, which are part of the updater belong here.
-
-Installer is the name which got inherited from times, where this folder contained
-much more infrastructure components, like a local webserver to facilitate updates.
-
-
-## installer.sh
-
-The main entry point for initial provisioning and also updates (not upgrades).
-
-It is called from:
- * cloudron-setup (during initial provisioning, restoring or upgrade)
- * cloudron.js in the box code (during an update)
-
-Two arguments need to be supplied in this order:
- 1. The public url to download the box release tarball `--sourcetarballurl`
- 2. JSON object which contains the user-data `--data`
-
-
-## cloudron-system-setup.sh
-
-This is the systemd unit file script hook, which persists Cloudron updates.
-Mostly it revolves around setting up various parts of the filesystem, like btrfs
-volumes and swap files

installer/scripts/installer.sh

@@ -1,100 +0,0 @@
-#!/bin/bash
-
-set -eu -o pipefail
-
-if [[ ${EUID} -ne 0 ]]; then
-    echo "This script should be run as root." > /dev/stderr
-    exit 1
-fi
-
-readonly BOX_SRC_DIR=/home/yellowtent/box
-readonly DATA_DIR=/home/yellowtent/data
-readonly CLOUDRON_CONF=/home/yellowtent/configs/cloudron.conf
-
-readonly script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-readonly json="${script_dir}/../../node_modules/.bin/json"
-readonly curl="curl --fail --connect-timeout 20 --retry 10 --retry-delay 2 --max-time 300"
-
-readonly is_update=$([[ -f "${CLOUDRON_CONF}" ]] && echo "yes" || echo "no")
-
-# create a provision file for testing. %q escapes args. %q is reused as much as necessary to satisfy $@
-(echo -e "#!/bin/bash\n"; printf "%q " "${script_dir}/installer.sh" "$@") > /home/yellowtent/provision.sh
-chmod +x /home/yellowtent/provision.sh
-
-arg_source_tarball_url=""
-arg_data=""
-arg_data_file=""
-
-args=$(getopt -o "" -l "sourcetarballurl:,data:,data-file:" -n "$0" -- "$@")
-eval set -- "${args}"
-
-while true; do
-    case "$1" in
-    --sourcetarballurl) arg_source_tarball_url="$2";;
-    --data) arg_data="$2";;
-    --data-file) arg_data_file="$2";;
-    --) break;;
-    *) echo "Unknown option $1"; exit 1;;
-    esac
-
-    shift 2
-done
-
-if [[ ! -z ${arg_data_file} ]]; then
-    arg_data=$(cat "${arg_data_file}")
-fi
-
-box_src_tmp_dir=$(mktemp -dt box-src-XXXXXX)
-echo "Downloading box code from ${arg_source_tarball_url} to ${box_src_tmp_dir}"
-
-for try in `seq 1 10`; do
-    if $curl -L "${arg_source_tarball_url}" | tar -zxf - -C "${box_src_tmp_dir}"; then break; fi
-    echo "Failed to download source tarball, trying again"
-    sleep 5
-done
-
-if [[ ${try} -eq 10 ]]; then
-    echo "Release tarball download failed"
-    exit 3
-fi
-
-# ensure ownership baked into the tarball is overwritten
-chown -R root.root "${box_src_tmp_dir}"
-
-for try in `seq 1 10`; do
-    # for reasons unknown, the dtrace package will fail. but rebuilding second time will work
-
-    # We need --unsafe-perm as we run as root and the folder is owned by root,
-    # however by default npm drops privileges for npm rebuild
-    # https://docs.npmjs.com/misc/config#unsafe-perm
-    if cd "${box_src_tmp_dir}" && npm rebuild --unsafe-perm; then break; fi
-    echo "Failed to rebuild, trying again"
-    sleep 5
-done
-
-if [[ ${try} -eq 10 ]]; then
-    echo "npm rebuild failed"
-    exit 4
-fi
-
-if [[ "${is_update}" == "yes" ]]; then
-    echo "Setting up update splash screen"
-    "${box_src_tmp_dir}/setup/splashpage.sh" --data "${arg_data}" # show splash from new code
-    ${BOX_SRC_DIR}/setup/stop.sh # stop the old code
-fi
-
-# ensure we are not inside the source directory, which we will remove now
-cd /root
-
-# switch the codes
-rm -rf "${BOX_SRC_DIR}"
-mv "${box_src_tmp_dir}" "${BOX_SRC_DIR}"
-chown -R yellowtent.yellowtent "${BOX_SRC_DIR}"
-
-# create a start file for testing. %q escapes args
-(echo -e "#!/bin/bash\n"; printf "%q " "${BOX_SRC_DIR}/setup/start.sh" --data "${arg_data}") > /home/yellowtent/setup_start.sh
-chmod +x /home/yellowtent/setup_start.sh
-
-echo "Calling box setup script"
-"${BOX_SRC_DIR}/setup/start.sh" --data "${arg_data}"
-

installer/systemd/cloudron-system-setup.sh

@@ -1,49 +0,0 @@
-#!/bin/bash
-
-set -eu -o pipefail
-
-readonly USER_HOME="/home/yellowtent"
-readonly APPS_SWAP_FILE="/apps.swap"
-readonly USER_DATA_FILE="/root/user_data.img"
-readonly USER_DATA_DIR="/home/yellowtent/data"
-
-# detect device of rootfs (http://forums.fedoraforum.org/showthread.php?t=270316)
-disk_device="$(for d in $(find /dev -type b); do [ "$(mountpoint -d /)" = "$(mountpoint -x $d)" ] && echo $d && break; done)"
-
-existing_swap=$(cat /proc/meminfo | grep SwapTotal | awk '{ printf "%.0f", $2/1024 }')
-
-# all sizes are in mb
-readonly physical_memory=$(free -m | awk '/Mem:/ { print $2 }')
-readonly swap_size=$((${physical_memory} - ${existing_swap})) # if you change this, fix enoughResourcesAvailable() in client.js
-readonly app_count=$((${physical_memory} / 200)) # estimated app count
-readonly disk_size_gb=$(fdisk -l ${disk_device} | grep "Disk ${disk_device}" | awk '{ printf "%.0f", $3 }')
-readonly disk_size=$((disk_size_gb * 1024))
-readonly system_size=10240 # 10 gigs for system libs, apps images, installer, box code and tmp
-readonly ext4_reserved=$((disk_size * 5 / 100)) # this can be changes using tune2fs -m percent /dev/vda1
-
-echo "Disk device: ${disk_device}"
-echo "Physical memory: ${physical_memory}"
-echo "Estimated app count: ${app_count}"
-echo "Disk size: ${disk_size}"
-
-# Allocate swap for general app usage
-if [[ ! -f "${APPS_SWAP_FILE}" && ${swap_size} -gt 0 ]]; then
-    echo "Creating Apps swap file of size ${swap_size}M"
-    fallocate -l "${swap_size}m" "${APPS_SWAP_FILE}"
-    chmod 600 "${APPS_SWAP_FILE}"
-    mkswap "${APPS_SWAP_FILE}"
-    swapon "${APPS_SWAP_FILE}"
-    echo "${APPS_SWAP_FILE}  none  swap  sw  0 0" >> /etc/fstab
-else
-    echo "Apps Swap file already exists"
-fi
-
-echo "Resizing data volume"
-home_data_size=$((disk_size - system_size - swap_size - ext4_reserved))
-echo "Resizing up btrfs user data to size ${home_data_size}M"
-umount "${USER_DATA_DIR}" || true
-# Do not preallocate (non-sparse). Doing so overallocates for data too much in advance and causes problems when using many apps with smaller data
-# fallocate -l "${home_data_size}m" "${USER_DATA_FILE}" # does not overwrite existing data
-truncate -s "${home_data_size}m" "${USER_DATA_FILE}" # this will shrink it if the file had existed. this is useful when running this script on a live system
-mount -t btrfs -o loop,nosuid "${USER_DATA_FILE}" ${USER_DATA_DIR}
-btrfs filesystem resize max "${USER_DATA_DIR}"

migrations/20141021192552-db-create.js

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

migrations/20141021192554-db-init.js

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

migrations/20150303114527-users-add-resetToken.js

@@ -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);
     });
 };
-

migrations/20150303160528-tokens-expires-bigint.js

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

migrations/20150303171203-authcodes-add-expiresAt.js

@@ -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);
     });
-};
+};

migrations/20150308054950-appportbindings-add-environmentVariable.js

@@ -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);
     });
 };
-

migrations/20150309023251-appportbindings-drop-containerport.js

@@ -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);
     });
 };
-

migrations/20150311120713-tokens-rename-userid-to-identifier.js

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

migrations/20150323044254-apps-drop-version.js

@@ -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);
     });
 };
-

migrations/20150323174906-apps-alter-health.js

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

migrations/20150326072904-apps-add-lastBackupId.js

@@ -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);
     });
 };
-

migrations/20150404093025-apps-add-createdAt.js

@@ -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);
     });
 };
-

migrations/20150430165335-settings-default-autoupdatepattern.js

@@ -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);
-}
-
+};

migrations/20150430210225-settings-default-timezone.js

@@ -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);
 };
-

migrations/20150615075901-users-add-unique-constraints.js

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

migrations/20150615134751-users-adjust-username-and-email-constraints.js

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

migrations/20150618192028-apps-add-lastManifestJson.js

@@ -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);
     });
 };
-

migrations/20150710044740-apps-rename-lastBackupConfigJson.js

@@ -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);
     });
 };
-

migrations/20150710170847-apps-add-oldConfigJson.js

@@ -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);
     });
 };
-

migrations/20150719014338-settings-remove-all.js

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

migrations/20151013073519-apps-add-oauthProxy.js

@@ -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);
     });
 };
-

migrations/20151015232915-clients-add-type.js

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

migrations/20151016131005-apps-rename-accessRestriction.js

@@ -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);
     });
 };
-

migrations/20151113091257-apps-alter-manifestJson.js

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

migrations/20151126111337-apps-alter-jsons.js

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

migrations/20160119113143-users-add-displayName.js

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

migrations/20160205135326-apps-add-memoryLimit.js

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

migrations/20160208031241-groups-add-table.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 groups(" +

migrations/20160208100000-groupMembers-add-table.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 IF NOT EXISTS groupMembers(" +

migrations/20160208164735-groups-add-admin.js

@@ -1,9 +1,8 @@
 'use strict';
 
-var dbm = global.dbm || require('db-migrate');
 var async = require('async');
 
-var ADMIN_GROUP_ID = 'admin'; // see groups.js
+var ADMIN_GROUP_ID = 'admin'; // see constants.js
 
 exports.up = function(db, callback) {
 	async.series([

migrations/20160307172229-backups-add-table.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(" +

migrations/20160330215005-backups-add-configJson.js

@@ -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);
     });
 };
-

migrations/20160404052453-backups-drop-configJson.js

@@ -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);
     });
 };
-

migrations/20160404191651-backups-rename-filename-to-id.js

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

migrations/20160405083451-users-drop-username-null.js

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

migrations/20160419070047-apps-add-altDomain.js

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

migrations/20160430062446-eventlog-add-table.js

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

migrations/20160506111925-users-add-showTutorial.js

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

migrations/20160527010012-mailboxes-add-table.js

@@ -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,' +

migrations/20160528090040-mailboxes-import-existing-users.js

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

migrations/20160614021819-apps-drop-lastBackupConfigJson.js

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

migrations/20160621032914-apps-alter-installationProgress.js

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

migrations/20160714130142-apps-add-xFrameOptions.js

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

migrations/20160831051352-settings-default-mailconfig.js

@@ -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);
 };
-

migrations/20160921205726-mailboxes-add-ownerId.js

@@ -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) {
         });
     });
 };
-