Posts made by jk

@nebulon Great, it's much better now!

On the Cloudron blog, when the dark mode is enabled, the links are barely readable.

I suggest using a lighter colour for the links in that case.

@girish Yes, that's me. Thanks!

@girish Sorry for reopening this after quite a while.

If have the exact same problem when I am not using the docker client, but the RedHat-built containers projects (podman / skopeo / buildah / etc).

The solution is the exact same patch, but then with container instead of docker. I tried to create a pull request for it, but apparently I have no right to fork the box code and make one.

Either way, on my server, the code looks like this now:

in nginxcoonfig.ejs:

    location @proxy-auth-login {
        if ($http_user_agent ~* "docker") {
            return 401;
        }
        if ($http_user_agent ~* "container") {
            return 401;
        }
        return 302 /login?redirect=$request_uri;
    }

in proxyauth.js

function isBrowser(req) {
    const userAgent = req.get('user-agent');
    if (!userAgent) return false;

    // https://github.com/docker/engine/blob/master/dockerversion/useragent.go#L18
    return !userAgent.toLowerCase().includes('docker') && !userAgent.toLowerCase().includes('container');
}

Would it be possible to patch this too with the next box release?

@thetomester13 Thanks I'm glad I've been of help!

Hello,

Thank you for packaging n8n. I've been playing a bit with it and tried to send an email. I'd liked it to be able to send emails like any other application.

This took a bit of fiddling, so I thought to write it up. Also, since it is not obvious how to do it, I would like this to be added to the n8n cloudron documentation so that the next user does not have to do the same research as I had to do.

When setting up the email credentials, an expression is required for each of the fields:

• User: {{$env["CLOUDRON_MAIL_SMTP_USERNAME"]}}
• Password: {{$env["CLOUDRON_MAIL_SMTP_PASSWORD"]}}
• Host: {{$env["CLOUDRON_MAIL_SMTP_SERVER"]}}
• Port: {{$env["CLOUDRON_MAIL_SMTP_PORT"]}}
• SSL/TLS: disabled

To set an expression, click the gear icon next to the field, and click Add expression.

Then, in the expression field, paste the expression as listed before. The warning in red can be ignored, this will work fine when executing it.

Then, in a Send Email node, set the From Email field to the following expression: My App <{{$env["CLOUDRON_MAIL_FROM"]}}>.

This will send an email with the name My App, and the address that is set in the cloudron settings.

Then, if you have set up the To and Subject, when you execute the node, you should get an email.

Even though I am usually very happy with Cloudron and its support, I was less impressed with it this time.

In the end, it looks like this only needed a direct data migration (db and /app/data/), which should be fairly easy given one has full control over the platform.

So I don't understand why the app packagers have chosen not to do this in this case, and thereby make it such an arduous process. Especially given the care that is usually taken to make upgrades smooth.

It took a while, but finally the migration succeeded.

None of the original approaches worked. In the end, I had to manually create a DB backup from the host (SSH to cloudron host, docker exect postgresql, pg_dump from there), modify it and import it into the db of the new app.

That was quite an arduous process, even though the DB schema had not changed between the two versions.

So for future reference, I think this is the "streamlined" version:

• Download the file /app/data/data/site-credentials-secret-key.txt from the old app, and upload it to the new app.
• Open the web terminal for both apps, and do the following for each:
  • Click the postgres button
  • Put "echo" before the psql command and run it. This will give the full login command for the app.
  • Copy the command
• Login to the cloudron host, and get a root shell.
• Execute this command: docker exec -it postgres /bin/bash
• Log in to the database of the new app and clear all tables
• Exit this database
• Run the following command: PGPASSWORD=<old_app_password> pg_dump -h postgresql -p 5432 -U <old_app_username> -a <old_app_schema> > /tmp/backup.sql
• Run the following command: psql -d <new_app_schema> < /tmp/backup.sql

After that, you should be able to log in to the new app, and have everything as it was.

Thank you. Some busy days ahead, but I'll try this soon and report back.

Hi,
I read in the app updates section for Wallabag that in order to upgrade the app, one needs to create a new app with the latest version and then export and import.

I have tried to do that, but I'm stuck at the export step. First, the app was OOM-killed. Then I increased it's memory to 8GB and restarted the app. That didn't help.

I found out that in /etc/apache2/sites-enabled/wallabag.conf the PHP memory limit is hardcoded to 64MB. That is not enough to export all ~17500 entries into a single file.

Putting the app into recovery mode still does not allow me to change that file and try again.

Do you have any suggestions on how to solve this?

Thank you!

Wow, that was fast! Thank you.

One small nit: I would add that the composer command needs to be run from within the plugin installation directory.

I also forgot one step:

chown -R www-data: ., also in the plugin installation directory.

Hello!

I am trying to install the carddav plugin for Roundcube, but this fails because the plugin requires separate dependencies.

I got it working by manually installing these dependencies in the plugin directory. This at first also failed, because composer requires a lot of RAM for its dependency resolutions mechanism.

So the full steps to do this in full were:

• Increase memory in app settings (I tried with 2GB)
• Open the terminal and run: cd /app/data/plugins/carddav && composer install --no-dev --optimize
• Update the /app/data/customconfig.php file (as listed in de docs)
• Decrease memory

Afterwards, this worked fine.

So I suggest adding a little bit of documentation to the Roundcube documentation page listing this.

I had the benefit of having year of professional experience in PHP development to figure this out, but not every user might.

Thank you for your great work. I've been a happy user of Cloudron for years now!

@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?