The following migrations are already released in 1.8.3:
20171116203507-apps-rename-newConfigJson-to-updateConfigJson.js
20171116224051-apps-rename-lastBackupId-to-restoreConfigJson.js
For new cloudrons this will first remove the previously added group and
mailbox entry from the db migration scripts and readds it once we have a
domain on owner creation
This adds domains table and adjusts the apps and mailboxes table accordingly
Also ensure we explicitly set the table collation, this is required
for the foreign key from apps table (utf8) and the newly created
domains table, which by default now would be utf8mb4
Put db table constraint for mailboxes.domain
Update the schema file
App backup can take a long time or possibly not work at all. For such
cases, do not stop the app or leave it in some errored state.
newConfigJson is the new config to be updated to. This ensures that
the db has correct app info during the update.
* Install in subdomain 'test'
* Move to subdomain 'test2'
* Move to another existing subdomain 'www' (this should be detected as conflict)
* Move to subdomain 'www2' (this should not remove 'www'). This is why dnsRecordId exists.
We already store JSON blobs there and the gce dns backend
will require a larger blob for a certificate.
Since we use innodb the storage format in TEXT will only be different
if the data is large
This skips the app from a backup when doing a full box backup and
simply reuses the previous backup.
The app can still be explicitly backed up using 'cloudron backup'
and explicitly restored using 'cloudron restore --backup'.
When restoring the box, it all depends on the app's last backup.
Fixes#311
We use only mysql, so updating this means a lot of unused db backends
like sqlite do not need to be built with gyp anymore.
Note that this version is not yet released as stable, but works fine for
us. The outstanding issues are not related to our use-case from what I
can tell.
Fixes#82
The core issue we want to solve is to debug a running app.
Let's make it explicit that it is in debugging mode because
functions like update/backup/restore don't work.
Part of #171
When turned off, it will put the app in a writable rootfs. This
allows us to debug live/production apps (like change start.sh) and
just get them up and running. Once turned off, this app cannot be
updated anymore (unless the force flag is set). This way we can
then update it using the CLI if we are convinced that the upcoming
update fixes the problem.
Part of #171
