Posts made by makemrproper

Hi

I can't understand how I as an operator shall use the backup system Cloudron offers.

Yesterday I made a mistake and deleted an app I shouldn't have deleted (root cause).

Question time:
Given that I only remember the name of the container, how can I restore the backup of the container?
I don't have the UUID, I don't have the BackupID. I have full access to the object storage, api keys, secrets and encryption key.

My object storage is teeming with backups, Cloudron is set to do it every 6 hours. And this succeeds day in and day out. Great!

However It is not clear to me how to restore these backups.

In my Object storage I have backup archives like this

They seem to follow the naming convention of the uuid for the contiainer, OK that makes sense.

When I am going to restore my backups I have to provide these fields:

As far as I can tell, as an operator I need to keep track of what was the UUID of the container I deleted, in order to restore it. In addition I must also know what is the BackupID. More on that.

When I upload one of my backup config files, there seems to be reference to a BackupID ?
For one of my backups, this is the BackupID
2020-06-13-064435-141/box_2020-06-13-065422-378_v5.2.4 <--- If I don't have the Backup Config File how can I generate this ID? Or how to I find the ID of the container I accidentally deleted?

The only surefire way I can think of is to download the backup configuration file for every container and keep them in a folder on my onedrive for whenever disaster strikes such as now. Is this the way every one else are doing it?

Is there a place I can get an overview and piece together the variables and be able to do a restore of the container?

in order not to get stuck in the future, I now will need to do the following when I put an application in production (business critical):

• Create a spreadsheet containing a list of all my containers.
• Keep track of the UUID for each container.
• Download the backup configuration file for each container.
• Explicitly store the BackupID in the spreadsheet per application.
• Maybe there are more fields I must keep track of as well (???).
• Randomly test the restore capability of each container monthly.

Unless there are some elegant solutions here?

Guys this was my first brush with disaster recovery for an application I host on Cloudron and it not go down well.
If it wasn't for my random DigitalOcean Droplet snapshot(backups) and DigitalOcean scheduled VM backups, I would have been screwed here. I was not able to find the right backup archive and the right values to enter to correctly restore backup.

If anything this is a defect toward the documentation, because I cannot figure it out by reading this: https://cloudron.io/documentation/backups/ document. All of the great backup functionality in Cloudron didn't help me.

In Risk Management we use the Bowtie risk causal model and focus on our Barrier Management. The backups of Cloudron was supposed to be a recovery barrier.

This is not uncommon in IT, disaster recovery is a key think to test out. Unfortunately for me I hadn't done all the testing necessary as I didn't see myself ending up in this scenario (making a mistake and deleting a container I actually needed).

Caution. There are dragons.

Although this approach worked perfectly.

I just totally screwed up.
To do a little cleanup, I deleted the "old" container with my 7.2 LAMP application.
Little did I know that my migrated 7.3 app was still persisting data to the 7.2 database instance!
It was all my fault, but this was not obvious to me. Make sure to check which Mysql database your 7.3 version is actually connecting to!

This has now led me down the disaster recovery path to try and fish out a backup package of the 7.2 version.
About to write another post about this situation. (link to disaster recovery thread)

The devs of Vanilla provided me with this solution

*If you create a file /conf/bootstrap.after.php and put that into this file, it will be executed on each request:

<?php
Gdn::database()->query("SET sql_mode = '';");*

Confirmed. I just tested @nebulon 's suggested method here, and it worked flawlessly.

I did the following steps to

Upgrade my LAMP application from PHP 7.2 to PHP 7.3

• Backed up my LAMP with php7.2.
• Downloaded the "Backup Configuration" JSON file for the backup of the old container
• Created a new LAMP container.
• Went to Backups -> Restore
• Uploaded the "backup configuration file" downloaded from the old container
• Entered the secret for my storage block storage space
• Clicked restore

After that everything worked, and I was on PHP 7.3
The LAMP application I migrated was a regular forum; Vanillaforums php/mysql stack.

Thanks @nebulon

Hi

I have now switched all my trivial sites and business critical systems over to container hosting provisioned by Cloudron. It's great!

Last step on this journey is to verify and test; perform a complete restore of the backup of the platform.
I currently take backups of cloudron every 6 hours and all containers every 6 hours. It seems to work pretty great, no errors.

However I am not sure how to proceed when doing a full restore of the entire Cloudron instance.
Here is my backup config:

I don't see any restore backups functionality in the web frontend of Cloudron.
Okay. Do I download the backup archive, uncompress the file and upload the contents to my server manually?
Where should I place those files?

I can download backup json configuration file, what's it for?

My end goal is to set up a daily sync between the backup location and a failover server on a different private cloud provider, maybe even to an on-prem machine in the office, just to be sure. These restored systems will contain the entire Cloudron instance restored from backups and it will be performed daily. But first I need to understand the various moving parts here.
I found some documentation here, but this was not enough for me to help myself with this topic.

Thanks for your answers.

Trying to solve it in the code:
The problem is; Modern PHP code does not allow direct SQL queries anymore. Its now modern to use prepared statements.
I could never be bothered to dive further into PHP than that, so I guess the joke is on me. But I can't just easily run
SET sql_mode = ''; because of this, and the vanillaforums code is modern enough to be way to convoluted to figure out how to deal with it.

EDIT:
Problem solved!
I was successful at adding this SQL code as a prepared statement.

SET sql_mode = '';

I managed to do my first prepared statement today, maybe its not a real prepared statement, but at least half way.

For the record, I got Vanillaforums to work by adding the following code after line 156 (but this can change), rather than line number it was added to the function newPDO in file $vanillaforums-root/library/database/class.database.php.

The entire function looks like this now:

     *
     *
     * @param $dsn
     * @param $user
     * @param $password
     * @return PDO
     * @throws Exception
     */
    protected function newPDO($dsn, $user, $password) {
        try {
            $pDO = new PDO(strtolower($this->Engine).':'.$dsn, $user, $password, $this->ConnectionOptions);
            $pDO->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0);
            $pDO->query("set time_zone = '+0:0'");
            $pDO->query("SET sql_mode = ''");

Thanks for your support!

Hey. Thank you for responding. Okay challenge accepted.

If I ever package something generic I'll make sure to upstream the code / publish it.

Hi

How do I disable Strict Mode on the Mysql database instance that my LAMP container connects to?

I have now tried "everything" without any success.

At least for the LAMP container in question, which will be hosting Vanillaforums, I need to disable Mysql strict mode.

From inside the container, and accessing the Mysql command interpreter:

SHOW VARIABLES LIKE 'sql_mode';

+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                                     |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+

Question
How do I change the sql_mode both runtime and as a permanent setting on each reboot - for my LAMP container?
I guess I need root access to the mysql for the database engine running for the container, but from where do I access it and how do I reset it?

Documentation:

Although this document is very nicely written and contains a lot of useful information in general cases, it didn't help me unfortunately: https://cloudron.io/documentation/apps/lamp/

I have tried to change it in the mysql server running in the regular Ubuntu system, but that didn't work. I later understood that's only used for internal purposes, so I guess I shouldn't have messed with it. It would be good if Cloudron internals were documented explicitly somewhere, such as the internal Mysql database.

Thanks. I'm really enjoying my subscription.

Hi

Any plans to create a LAMP stack with Postgres?

It would make hosting all my favorite Postgres enabled applications possible.

I guess it would make it LAPP or something.

Thanks!

Great! Somebody is taking action. Fantastic.

But please note @girish @samir - The current work focuses on packaging an old version of Odoo!
For some reason it is being packaged for Odoo version 10.
In that case release a package for all the latest 4 major versions 10, 11, 12 and 13
Latest version (2020) is version 13.
Issue: https://git.cloudron.io/altsyst/odoo-ce-app/issues/1
https://git.cloudron.io/altsyst/odoo-ce-app/issues/1

Sigh

So you take the best value propositions and hide it behind the most expensive tier.
Please understand that these things are price elastic. I cannot afford to spend this amount per month on hobby projects - I am not a business, but I use Gitlab and Nodebb.

Don't steal from your own bright future.

How do I go back to the old unsupported unlimited version???

I have a ton of applications running already, and now they won't renew SSL certs. I am also unable to add more apps, to verify that the SSL is working or not.

This is trashing existing users.

I am this far from pulling the plug here. Freemium-sweetner-plan is what this is, not a real positive development for my use case.

@gustavomarcante
Pretty sweet license too. LGPL.
The team has 40 developers
They have consistently produced releases.

@girish said in What's coming in 3.0:

Setup redirects. Currently, one has to use the LAMP app or Surfer to setup redirects from naked domain towww or vice-versa. We are adding a setting that will make this easy.

This sounds great, and I think it is what I really need.
Will this make it possible to define subdomains, say cool-unsupported-webapp.mydomain.com that are

• not a cloudron packaged app
• hosted by a local httpserver like lighttpd, nginx or apache
• but covered by the smooth Let's Encrypt certificate handling in Cloudron?

Thanks in advance

Hi

In my non-humble opinion, this is the best wiki out there. It produces beautiful documents.
It is a pure joy to use and combines the best experience from all other libre open source wiki's I have used.
Mind you, I also like Mediawiki and Dokuwiki - but they do not come close to BookStack.

It is light on resources and requires minimal configuration, an SQLITE db is supported. It would not be difficult to "port" to Cloudron.

Therefore I would like to propose the inclusion of BookStack. Please consider it!
Screenshots:

Overview

Example documentation pack

Page editor - yummy

Powerful search