Cloudron Forum

@jdaviescoates said in Odoo - distributed business apps:

But in my limited experience of playing around with it I found it severely lacking, and with a terribly confusing UX.
Pretty much all the things it does are done MUCH better by other tools that focuses on doing that task rather than hacking together an Odoo module that kinda sorta does it.

This is wrong.

It is not confusing and provides a clean UX.

The functionality that it offers out of the standard modules are great, and provides plenty of value as they come.

I have used them for business scenarios on and off for 10 years.

If one wants to customize a system, one needs to learn this which is in itself a tradecraft. In Odoo's case it is similar to customizing Salesforce. This requires a developer attitude.

Please if you want to continue down this rabbit hole discussion, please list tools which are much better suited that replace Odoo.

@LoudLemur No I don't like Axelor. I like Odoo.

@girish This is still a huge problem.

My production server have failing applications again due to disk space filling up. Luckily DigitalOcean's backup functionality saves my setup this time again. If I had relied only on Cloudron for backups it would have been disaster time.

I am not asking you for help to fix it or to blame anyone. But this needs an engineered solution by upstream, you guys.

You could for instance recommend that we make use of separate storage volumes on the system drive. This brings the TCO cost down, for storage. Recommendations and verified testing from you would be valuable for us as customers.

I can imagine hundreds of other customers of yours that are seeing the same issue.

Also:
Your assertion above that disk space is cheap is true for physical drive storage, but not for VPS server storage. For me to double disk space from 80gb to 160gb it also doubles my yearly VPS cost. I would believe a sizable portion of your users are hosting Cloudron on a VPS.
Of course you could temporarily invalidate this problem by recommending 160GB storage capacity. This might alienate some potential users.

Now onwards to repair my Cloudron install and apps!

edit:
Solving the root cause

Used ncdu to browse every container

• Gained 1gb of storage by deleting /usr/local/share/.cache/yarn/ on a container volume
• Gained 500mb of storage by deleting Anaconda distribution package cache within a container volume

Analysis: There seems to be space wasteful ways of letting the Metor spread around old versions of libraries and builds (?).

@msbt Odoo Community edition hosted on Cloudron would be a massive value add to the Cloudron portfolio. I totally recommend using Cloudron in a business to structure and improve processes. Unless your company has the budget to run Salesforce, or Service Now to do the same.

Here is my SOLUTION:

It does not solve the root cause why you are running out of space, but with this methodology you will buy yourself time.

Generate 3 files of 2 gigabytes each.
This is one way of generating these files:
fallocate -l 2G /storage-padding-buffer-2-gb-file1.img
fallocate -l 2G /storage-padding-buffer-2-gb-file2.img
fallocate -l 2G /storage-padding-buffer-2-gb-file3.img

When your server is out of storage, you may delete one or all of these padding files, so that regain the space you need to rescue the server.

I have had the same issue with cloudron, because over time, storage will run out.
For now I chose not to update the storage of my VPS server because it will double my hosting cost for this node, from USD400 to USD800 per year. That's digital ocean pricing for you, but I digress.

This is a systems engineering issue and isn't caused by Cloudron. However I would not have anything against an elegant solution from the team if it were possible :).

I want to say I am working on a post to describe I work with a massive cleanup, and exactly which steps I took to regain loads of space. TLDR; use ncdu, analyze all containers and identify where apps are storing logs and rotating these, clear NPM package cache in each container. More to cone

@mastadamus Confirmed. This happened to me today, when I tried to install Crowdsec with Nginx bouncer onto my Cloudron VM.

Thank heavens for a good backup strategy. Digital Ocean snapshots to the rescue.

To have Crowdsec working with my Cloudron install would be a massive value add.

I am not even sure why Nginx failed to start afterwards. I did however note that the install modified or wiped a lot of the Nginx configs which were already in place and perhaps modified by Cloudron. But I haven't tried to dive any deeper.

Latest major version of Odoo Open Source is now v14

"One click" install script by a community contributor: https://github.com/Yenthe666/InstallScript

Edit: Release notes:

@girish Boom! Back up and running
Well this was a joyous outcome. Thanks a bunch Girish!

@girish

Output of node --version:
v8.10.0

npm cache verify states:

| New major version of npm available! 6.14.10 → 7.20.3 │
| Changelog: https://github.com/npm/cli/releases/tag/v7.20.3 │
│ Run npm install -g npm to update!

You were spot on

@jdaviescoates Odoo is not primarily a website builder for ecommerce to run a webshop. It is a fully fledged ERP with loads of functionality to operate a business. It would be a major value add if Cloudron team would package it and get it onto the Cloudron appstore. It would definitely attract paying Cloudron customers.

Problem description

I cannot reach the control plane of Cloudron!

Context description

I just upgraded my VPS from Ubuntu 1604 to 1804 after Cloudron recommended it.

The OS upgrade went well. I followed the instructions provided by you after a VM snapshot. All good. lsb-release -a now shows 1804. Next stop 2004. But not before I fix this issue, and snapshot my VPS again.

Runtime environment description

Ubuntu 1804 Ubuntu untouched vanilla, upgraded from 1604 untouched vanilla.
My containers are up and running, and I can reach them.

Debug description

Here is the output in /home/yellowtent/platformdata/logs/box.log

2021-08-04T20:18:51.562Z box:settings initCache: pre-load settings
Error starting server { BoxError: Could not save dhparams.pem: Cannot read property 'isPromise' of undefined
    at initSecrets (/home/yellowtent/box/src/blobs.js:80:78)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  name: 'BoxError',
  reason: 'FileSystem Error',
  details: {},
  message: 'Could not save dhparams.pem: Cannot read property \'isPromise\' of undefined' }
2021-08-04T20:18:55.567Z box:server ==========================================
2021-08-04T20:18:55.568Z box:server            Cloudron 6.3.5
2021-08-04T20:18:55.568Z box:server ==========================================
2021-08-04T20:18:55.656Z box:settings initCache: pre-load settings
Error starting server { BoxError: Could not save dhparams.pem: Cannot read property 'isPromise' of undefined
    at initSecrets (/home/yellowtent/box/src/blobs.js:80:78)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  name: 'BoxError',
  reason: 'FileSystem Error',
  details: {},
  message: 'Could not save dhparams.pem: Cannot read property \'isPromise\' of undefined' }

Deep down in the bowels of Nodejs forums I encountered that it could have something to do with a NodeJS module that needed to behave according to a certain version. Source: https://github.com/TrilonIO/angular-application-insights/issues/31

Question / request for hlep
Any help on this would be much appreciated!

Some analysis:

Is this an npm cache issue? should I clear the npm cache? How do I do this? Invoke npm cache clean?

@nebulon Thanks, okay so I buy the game and use it as a client for connecting to my self hosted instance. Got it. Cheers for your ultra quick reponse :).

Hi

I have not been able to find documentation about this package.

How can I connect to the server after I have set this package up on Cloudron?

Do I buy the game, and then connect to my server instance from within the game? Or is it a manual command line flag where I specify hostname and port?

It would be good with some pointers in the package information, on a wiki here... You know a little more meat on the bone as far as documentation. The game looks great! And it seems like something I'd absolutely would want to try to host myself.

@jimcavoli said in CiviCRM | Open source constituent relationship management for non-profits, NGOs and advocacy organizations:

This runs as a WordPress plugin. I've run it with no major issues on Cloudron-installed WP before. If anyone wants to give it a spin and file any particular bug reports noticed, then that's an option, but is likely best positioned to be taken care of after other WordPress package changes that are in process right now

I recommend the Drupal version.

Hi

Adguard seems like a solid software project.

I understand they sell apps and have various licensing options.

However I can't find any details about the self hosted version, which is offered through Cloudron (great work on packaging it!).

What is the license it is made available to us users as?
Is this a freemium model or is it more open or even libre?

CiviCRM is very good.

Update:
I was able to restore the containers to a healthy state.
I did not solve the root cause, and I do not know if this will occur again.
"Repair" "Restart" and so on did not work.

Solution:
Restore container from backup and all was well. The last backup point was performed 4 days ago, when the problem started occurring.

Hi

I have suddenly been seeing more and more apps ending up in an unrecoverable state. Last week I had 1 app in this state. Today I'm seeing 4 apps in the same error condition. Luckily none of my business critical containers are affected yet. It seems to be "spreading" Please help!!!

ERRORS as seen from the web interface
I am seeing this from the Container Info view in the web interface, per container. The error message and condition is the same across all four containers.

Task Error

If a configuration, update, restore or backup action resulted in an error, you can retry the task.

An error occurred during the configure operation: Docker Error: removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts

ERRORS as seen in the LOG

The log for the container contains these recent entries:

Dec 13 10:05:30 box:apptask hostname.com error reconfiguring : BoxError: removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts

Dec 13 10:05:30 box:apptask hostname.com updating app with values: {"installationState":"error","error":{"message":"removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts ","reason":"Docker Error","taskId":"6632","installationState":"pending_configure"}}

Dec 13 10:05:30 box:taskworker Task took 3.779 seconds

Dec 13 10:05:30 box:tasks setCompleted - 6632: {"result":null,"error":{"stack":"BoxError: removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts \n at Object.callback (/home/yellowtent/box/src/docker.js:686:64)\n at /home/yellowtent/box/node_modules/dockerode/lib/volume.js:81:12\n at /home/yellowtent/box/node_modules/docker-modem/lib/modem.js:265:7\n at getCause (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:287:7)\n at Modem.buildPayload (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:256:5)\n at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:232:14)\n at IncomingMessage.emit (events.js:203:15)\n at endReadableNT (_stream_readable.js:1145:12)\n at process._tickCallback (internal/process/next_tick.js:63:19)","name":"BoxError","reason":"Docker Error","details":{},"message":"removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts "}}

Dec 13 10:05:30 box:tasks 6632: {"percent":100,"result":null,"error":{"stack":"BoxError: removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts \n at Object.callback (/home/yellowtent/box/src/docker.js:686:64)\n at /home/yellowtent/box/node_modules/dockerode/lib/volume.js:81:12\n at /home/yellowtent/box/node_modules/docker-modem/lib/modem.js:265:7\n at getCause (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:287:7)\n at Modem.buildPayload (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:256:5)\n at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:232:14)\n at IncomingMessage.emit (events.js:203:15)\n at endReadableNT (_stream_readable.js:1145:12)\n at process._tickCallback (internal/process/next_tick.js:63:19)","name":"BoxError","reason":"Docker Error","details":{},"message":"removeVolume: Error removing volume: (HTTP code 500) server error - remove e33adee2-f48d-48e8-8777-e281413d2576-localstorage: volume has active mounts "}}

Environment info
HOST: DigitalOcean
The server has
RAM: 4gb out of 8 gb ram free
DISK: 20gb out of 80gb disk storage free
CPU: 10:38:57 up 31 min, 1 user, load average: 0.26, 0.64, 1.84
Uptime: Just performed a few reboots, to be sure, up 31 minutes
OS: Ubuntu 1604
Docker: Docker version 19.03.12, build 48a66213fe

@samir Any progress update on this?

Do you need help?

Did you see my issue mentioned above?

What will it take to roll this out with a newer version?

Would it work to replace the shell script in your Cloudron package with one that points towards Odoo v14?
Here is the script: https://github.com/Yenthe666/InstallScript/blob/14.0/odoo_install.sh

@girish Would you know the answer?

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