cloudron-cli in cron

[vladimir.d]

@subven said in cloudron-cli in cron:

You can create a personal token and pass it to the cron cli command via --token Dunno how it works with 2FA enabled but there should be no need to manually log in.

EDIT: Just noticed that you want to run the cli command on the Cloudron host. The CLI tool is not intended to run on the Cloudron host itself!

Token seems to work very well.
What are drawbacks of using CLI tool on the Cloudron host?

@girish said in cloudron-cli in cron:

Is the use case here to have some sort of a demo app instance that keeps resetting state ?

Instead of using the CLI tool, maybe you can just use the REST API for this. It's just a POST request. Something like:

curl -X POST -H 'Authorization: Bearer <token>' -d '{"backupId": "id"}' https://my.domain.com/api/v1/apps/<appid>/restore

Yes, it's for a demo app instance and yes, REST API is a graceful solution.
I wonder if there is also a REST API call to get appid by CLOUDRON_APP_DOMAIN?

[vladimir.d]

@girish said in cloudron-cli in cron:

Is the use case here to have some sort of a demo app instance that keeps resetting state ?

Instead of using the CLI tool, maybe you can just use the REST API for this. It's just a POST request. Something like:

curl -X POST -H 'Authorization: Bearer <token>' -d '{"backupId": "id"}' https://my.domain.com/api/v1/apps/<appid>/restore

I created a token in the profile and got backupId using the REST API call:

curl -X GET -H 'Authorization: Bearer <token>' https://my.domain/api/v1/apps/<appid>/backups

I get the following error on the backup restore REST API call:

{
  "status": "Bad Request",
  "message": "backupId must be non-empty string"
}

So I'm sure the token and backupId are correct and valid.
The CLI tool successfully restores the backup copy by the same token and backupId.
What am I missing?

[subven]

@vladimir-d said in cloudron-cli in cron:

I wonder if there is also a REST API call to get appid by CLOUDRON_APP_DOMAIN?

Take a look at the API documentation for Cloudron ^^

@vladimir-d said in cloudron-cli in cron:

What are drawbacks of using CLI tool on the Cloudron host?

It should be avoided to install anything on the host server manually. Second you get yourself in a situation where you have circular dependency which is never a good thing.

@vladimir-d said in cloudron-cli in cron:

The CLI tool successfully restores the backup copy by the same token and backupId.

You did something like: '{"backupId": "2022-11-11-030000-618/app_archiv.domain.com_v2.2.1"}'?

[vladimir.d]

@subven said in cloudron-cli in cron:

You did something like: '{"backupId": "2022-11-11-030000-618/app_archiv.domain.com_v2.2.1"}'?

No, I put Id value from the backup list response, e.g. a backup list response from REST API documentation:

{
  "backups": [
    {
      "id": "string",
      "remotePath": "2022-10-24-060000-679/app_cubby.nebulon.space_v1.0.1",
      "label": "My important backup",
      "identifier": "e7d4cc36-9ac0-4f93-8534-62514abe5d9c",
      "creationTime": 0,
      "type": "app",
      "state": "normal",
      "format": "rsync",
      "preserveSecs": 604800,
      "encryptionVersion": "string",
      "dependsOn": [
        null
      ],
      "manifest": null
    }
  ]
}

Do you mean remotePath value is being used as backupId in the backup restore request?

[subven]

@vladimir-d said in cloudron-cli in cron:

Do you mean remotePath value is being used as backupId in the backup restore request?

Nah just want to make sure you're using the right thing. Do you use the current Cloudron version (v7.3.2)?

Here are some examples:

Curl (Windows PS)

PS C:\Windows\system32> curl.exe -X POST -H 'Authorization: Bearer aheregoesyourmagictokenhehehehhe1' -d "backupId=app_19c44041-367d-4977-a68b-9c6e24326f38_v2.2.1_9439b666029210f32d06c19e7f1af7ed337daa8ba75ed7740236ab53220235b5" https://my.domain.com/api/v1/apps/19c44041-367d-4977-a68b-9c6e24326f38/restore
{
  "taskId": "11075"
}

CLI tool

PS C:\Windows\system32> cloudron restore --app 19c44041-367d-4977-a68b-9c6e24326f38 --backup app_19c44041-367d-4977-a68b-9c6e24326f38_v2.2.1_9439b666029210f32d06c19e7f1af7ed337daa8ba75ed7740236ab53220235b5

 => Queued
 => Downloading icon .
 => Restoring addons .
 => Wait for health check .

App is restored

[girish]

@vladimir-d I think this might be because of the missing Content-Type header (I didn't put that in my original post). Looks like it might not be parsing the input as json.

curl -H 'Content-Type: application/json' -X POST -H 'Authorization: Bearer token' https://my.cloudron.domain/api/v1/apps/<appid>/restore -d '{"backupId": "app_219fa028-e694-4b0f-a050-e95de64868cb_v2.25.0_blah" }'

[girish]

@subven said in cloudron-cli in cron:

curl.exe -X POST -H 'Authorization: Bearer aheregoesyourmagictokenhehehehhe1' -d "backupId=app_19c44041-367d-4977-a68b-9c6e24326f38_v2.2.1_9439b666029210f32d06c19e7f1af7ed337daa8ba75ed7740236ab53220235b5" https://my.domain.com/api/v1/apps/19c44041-367d-4977-a68b-9c6e24326f38/restore

Ah nice, I just tested this and the above works as well. It's using form encoding I guess (which is curl's default?).

[vladimir.d]

still have no luck.

If I add -H 'Content-Type: application/json' to the backup restoring request I get:

{ "status": "Internal Server Error", "message": "Cannot read properties of null (reading 'manifest')" }

I tried to send the request using curl and postman, the response is the same. Cloudron is v7.3.2

ps. the CLI tool works well though.

[girish]

@vladimir-d Can you post your entire request? Something else is off.

[vladimir.d]

@girish sorry, a school boy mistake, the Content-Type header did the trick, but I made a typo in the backupId, that's why I got the error.