• Members 10 posts
    Oct. 31, 2019, 9:37 a.m.

    I'm trying to build the form with misago_docker, and use appctl setup method to do so.
    Everything went well, except the last step - [docker-compose run --rm misago ./.run initialize_default_database]
    I got this error:psycopg2.OperationalError: FATAL: password authentication failed for user "misago_TjY0iVs5eGNcKuRb"
    What should I do? What is the correct password?

  • Oct. 31, 2019, 2:27 p.m.

    Hi!

    Can you say what commands did you run, starting with git clone to get misago-docker on your server? For most of users misago-docker just works, but few reported the issue with password authentication failing, which I've couldn't ever reproduce :( Did you try running docker-compose up before using ./appctl? This will cause PostgreSQL database to initialize with default user - something that's not going to work with appctl.

    To recover you will need to run docker volume ls and find a volume which name ends with misago-database. Then you will need to use docker volume rm VOLUME_NAME

    After that you should be able to run docker-compose run --rm misago ./.run initialize_default_database manually to populate database. You will have to follow this with ./appctl collectstatic. After this you will be able to run ./appctl restart

  • Members 10 posts
    Oct. 31, 2019, 4:16 p.m.

    At first, I just use [git clone] to get the misago-docker, and run ./appctl setup to set up the server.
    But error occurred as I mentioned, just before the last step.
    After that, I tried to figure it out why this error could happen.
    I use [docker exec -it POSTGRES_CONTAINER_NAME “/bin/bash”] to get a shell, and tried to log into the Postgres DB manually, it said the role “misago_...” not exists.
    I clone the dev version again, and set up the dev version on my server, it turns out to be good, and I can log into the Postgres DB manually with the role “misago”
    Now, I still don’t understand why the POSTGRES_CONTAINER didn’t add role/user successfully, it seems the PostgreSQL DB didn’t initialized well, is it because of the DB config file?How could I solve this problem?

  • Nov. 2, 2019, 5:37 a.m.

    Sorry, I don't know. I've never managed to reproduce this error myself so I could investigate this properly.

    I am thinking that creating randomized username and password on setup was a mistake - we could preset those inside docker-compose.yml and let site owners override them if they so wish. It should be safe anyway as long as we make sure its impossible to connect to PostgreSQL from outside docker network or maybe the internet (so host's psql is still usable).

  • Members 10 posts
    Nov. 2, 2019, 9:24 a.m.

    There is a good news, you guess what? I have solved the problem.
    After connecting into the postgres_docker and modifying the content of the docker-compose.yml, it turned out that the username and password in postgres.env is wrong.
    But don't worry, it's not really wrong. The username and password stored in the postgres.env is re-generated, not the first-time-generated one.
    Because I interrupted the setup process many times, and I just delete the container to re-setup, in fact I should delete the volume at the same time.(The postgres container will not re-initialized once the volume is up)
    Reference:

    https://github.com/docker-library/postgres/issues/537
    
    https://stackoverflow.com/questions/48629799/postgres-image-is-not-creating-database/54200233#54200233
    
    https://github.com/docker-library/postgres/issues/453#issuecomment-393939412
    

    But there is another thing still works strangely, I think docker-compose down should stop & delete the container/volume, but in fact it isn't. I need to delete the volume on my own, I'm still a little confused about it, why the location of the docker container located at the default place, but not the place referred in docker-compose.yml

  • Nov. 3, 2019, 6:05 p.m.

    Because I interrupted the setup process many times

    Did you interrupt setup process when installing Misago first time? This is one of two ways one can break PostgreSQL connection in their app.

    I think docker-compose down should stop & delete the container/volume, but in fact it isn't.

    This is by design. You more often than not destroy and recreate images than you want to loose application data stored in volumes.

  • Members 10 posts
    Nov. 18, 2019, 1:35 p.m.

    The Mountpoint of my misago_docker_misago-database is /var/lib/docker/volumes/misago_docker_misago-database/_data
    But the value of the volumes(postgres) in the docker-compose.yaml is misago-database:/var/lib/postgresql/data
    Why they are not the same?

  • Nov. 18, 2019, 9:02 p.m.

    Because volume path is path within container's filesystem.