When running python migrate.py migrate through ./appctl bash, I receive the following error:
django.db.utils.OperationalError: FATAL: password authentication failed for user "misago_0E8PvwP04cSVmYBY"
Fresh install following misago.gitbook.io/docs/setup/misago, also occurs and the end of setup when migrating the database.
Debian 9
Wrong section, my bad, please move :)
Thanks for the report. Did you by chance attempt to reinstall your Misago site without removing docker containers first? This is one possibility for password not working.
Other possibility is thar updates made by Docker-Postgresql maintainers breaking the setup script in some way - I've already experienced such change when they added password length limit.
Happened first time and I removed the containers and images when retrying, still same issues.
Here's line generating password for database: github.com/rafalp/misago_docker/blob/master/wizard/postgres.py#L13
It was 100 characters before, but that was causing issue just like one you've reported, so I've lowered it to 80, making it work. Perhaps something has changed again in recent releases, and 80 characters is not supported anymore either?
Could you please edit the wizard to use, say, 60 characters, clear docker and try again?
Same issue with a 60 character password.
Okay, trying this around, can you try with 10 characters? Can you also confirm that attempt is made with clean state - eg. your config directory is empty, and docker is clean (no images or volumes)?
I appreciate the help 👍
I edited wizard/postgres.yml (get_random_string(10)) before setup but the password seems to still be 80 characters long (in config/postgres.env), also noticed this during setup:
Step 5/11 : RUN wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O - | apt-key add - && sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main" >> /etc/apt/sources.list.d/pgdg.list' && apt-get update && apt-get install -y --allow-unauthenticated vim libffi-dev libssl-dev libjpeg-dev libopenjp2-7-dev locales cron postgresql-client-10 gettext && apt-get clean
---> Running in e16f3dab7899
key 7FCC7D46ACCC4CF8:
2 signatures not checked due to missing keys
OK
both key.. and 2 sig.. are in red, not sure if this is related to the issue. I'm definitely clearing the docker container/images and cloning a fresh copy of Misago each time.
It won't work if you just edit wizard/postgres.py. You need to clear config directory and clear all volumes (eg. docker-compose down && docker system prune -a).
Then you should try appctl setup and follow all instructions.
I'll also give this a try over the weekend. If you don't mind, could you also confirm if you are using digital ocean's docker image as shown in the docs?
⬆ thats me installing misago_docker on digital ocean droplet following the setup guide. Everything works as advertised for me.
./appctl psql also works:
So does ./appctl bash followed with python manage.py migrate:
Looks like everything works as advertised by the manual, but I'm testing stuff from manual on instance that uses Ubuntu 18.04 for host OS. I'll try with Debian Stretch next.
I've got myself empty box with Debian 9.6, installed docker and docker-compose on it manually, and it works as well:
I can't really tell what went wrong for you. I've tried both Ubuntu and Debian 9.6 boxes, and got Misago up and running in both instances. Perhaps something has been interrupted and docker just ignored it during setup? Maybe your docker installation is not up to date? Or you've deleted containers but missed volumes/configs on the retry?
I don't know how possible it would be, but maybe something didn't install right during containers creation but docker just carried on as usual. Then next setup step failed, but you've missed docker volumes and/or config directory contents? Or you've tried to salvage the situation using other means that deleting everything and trying appctl setup again with clean docker and misago_docker directories?
As for the 2 signatures not checked due to missing keys, I have also experienced this issue when installing my test instances, but both of them worked anyway.
Hey, so I ran into this issue to and reading though here helped. It was pruning the volumes that I missed. Cleared the config and rebuilt the containers and had the same issue as @fluster. Cleaned the volumes and it worked as expected.
A nice one liner to clean everything up docker wise:
docker stop $(docker ps -qa) && docker system prune -af --volumes
I am happy to hear that fix worked for you, @eXamadeus !