Posts made by jk

@girish Thanks. That was fast!

@girish It seems there is still an error in this app.

After adding a recurring transaction, the UI shows the following warning:

Message: It seems the cron job that is necessary to support recurring transactions has never run. This is of course normal when you have just installed Firefly III, but this should be something to set up as soon as possible. Please check out the help-pages using the (?)-icon in the top right corner of the page.

After looking into it, I found that the cron job is added in the CloudronManifest.json file. But looking in the application logs, showed nothing about that task actually being run.

So I opened the console, and ran the command manually:

sudo -u www-data php /app/code/artisan firefly-iii:cron

This resulted in an error. Instead of pasting the gigantic stack trace, let me summarize it:

[2020-02-08 00:24:14] local.ERROR: SQLSTATE[08006] [7] invalid port number: "${CLOUDRON_POSTGRESQL_PORT}" (SQL: select * from "recurrences" where "recurrences"."deleted_at" is null order by "active" desc, "title" asc) {"exception":"[object] (Illuminate\\Database\\QueryException(code: 7): SQLSTATE[08006] [7] invalid port number: \"${CLOUDRON_POSTGRESQL_PORT}\" (SQL: select * from \"recurrences\" where \"recurrences\".\"deleted_at\" is null order by \"active\" desc, \"title\" asc) at /app/code/vendor/laravel/framework/src/Illuminate/Database/Connection.php:669)

[stacktrace cut]

[previous exception] [object] (Doctrine\\DBAL\\Driver\\PDOException(code: 7): SQLSTATE[08006] [7] invalid port number: \"${CLOUDRON_POSTGRESQL_PORT}\" at /app/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:31)

[stacktrace cut]

[previous exception] [object] (PDOException(code: 7): SQLSTATE[08006] [7] invalid port number: \"${CLOUDRON_POSTGRESQL_PORT}\" at /app/code/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:27)

[stacktrace cut]

Any idea why this fails?

I've wished for OAuth support for quite a few times already to support SSO to non-Cloudron apps. So in that case, Cloudron would serve as the identity provider for a third-party app. Kind of like Login with Cloudron.

That would require that one can register third party apps with their client id, client secret and callback URL though.

I have a little bit of experience with Keycloak. I know that U=using Keycloak would (also) support this use case, provided a Cloudron user has access to the Keycload administration interface.

@girish thank you.

That worked for docker volume prune. The other command (docker image prune) did not actually clean anything up though, but the output of docker system df stays with 66% reclaimable.

Any further ideas?

Hi,

I have another question regardiing this. The following is the output of docker system df.

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              34                  16                  9.857GB             6.508GB (66%)
Containers          21                  18                  0B                  0B
Local Volumes       160                 36                  5.274GB             3.964GB (75%)
Build Cache         0                   0                   0B                  0B

As you can see, docker claims that a lot of storage is reclaimable.

Is it safe to run docker volume prune and docker image prune?

Thanks a lot!

@nebulon said in Cloudron 3.3 released:

(...) The current wallabag is not yet compatible with the version of Postgres Cloudron > 3.2.3 ships. So reinstallation would not work. This is the reason we block the Cloudron update for instances which have wallabag installed.

It looks like making Wallabag support a newer version of Postgresql is literally a single-line patch.

Might it make sense to carry this as a custom patch for now and be done with it?