Provisioner fails in task add mariadb user

[m0wer]

The error is:

InvalidPrivsError: unable to parse the MySQL grant string: GRANT USAGE ON entrypoint.sh TO `wallabag`@`%` IDENTIFIED BY PASSWORD '[OMMITED]'

Which appears to be related to ansible/ansible#51356. Simply upgrading ansible inside the container solves the issue:

apk add py3-pip
pip3 install --upgrade ansible

And then the provisioner can be run again:

ansible-playbook -i /etc/ansible/hosts /etc/ansible/entrypoint.yml -c local

This error avoided the container from starting properly and the logs where showing HTTP 500 error codes.

[j0k3r]

So what do we have to do to fix it?
Can you open a PR to fix it?

[m0wer]

Works fine in master/latest since the Alpine base image was upgraded to 3.10 (from 3.9) and in that branch of Alpine ansible is updated to 2.8 (instead of 2.7). So no changes are needed.

Maybe it would be nice to update the 2.3.8 tag though.

Thanks!

[Miosame]

Not sure if I have the same issue, but wallabag after the recent update 500's now, can't find any proper logs to confirm what the issue is though - compose logs do not contain anything useful, except maybe mysql complaining about an attempt to connect:

[Warning] Aborted connection 8 to db: 'unconnected' user: 'unauthenticated' host: 'xxx' (This connection closed normally without authentication)

Provisioner however seems to finish:

wallabag_1  | Starting provisioner...
wallabag_1  | [WARNING]: Found both group and host with same name: localhost
wallabag_1  | Provisioner finished.

[paulcalabro]

@Miosame Are you pinning to 2.3.8? If so, that was causing issues for me as well. I saw @m0wer 's command and used latest instead and that resolved my issue. It would be nice if there was a new release since Docker Bench for Security complains about using latest :-) .

[Miosame]

@paulcalabro I've on purpose set recently containers like wallabag to latest and have watchtower updating them, so sadly I'm on latest from hub at least. No idea how to debug the 500, considering it logs nothing.

[paulcalabro]

@Miosame You might be able to troubleshoot the issue by examining WALLABAG_DIR/var/logs/prod.log. Additional information can be found here.

[Miosame]

@paulcalabro /var/www/wallabag/var/logs is empty, no prod.log.

[paulcalabro]

What if you attach to the container and manually run the app?

[Miosame]

@paulcalabro how would I manually run it? looking at it, it's actually symfony based (so regular php served via webserver) - though sadly enough different from laravel to be alien to me.

Moving temporarily config_dev.yml in place of config_prod.yml in /var/www/wallabag/app/config/config_dev.yml - did sadly not trigger the hoped for debug page nor cause it to dump any useful messages to docker logs or create any files in the logs folder.

[Miosame]

@paulcalabro nevermind it was some weird caddy-server issue that was causing it

[j0k3r]

Ansible has been replaced by shell script few days ago #307, so I'm closing that issue.