Cannot create project on self-hosted version, issues with `events`

Troubleshooting Self hosted Taiga
1

Expected result

I’m expecting that when I have navigated to `NEW PROJECT`, selected Kanban, filled in the form on the screenshot and clicked `CREATE PROJECT`, it will create a new project, that I will be able to navigate to through `Projects` in the top left corner.

What happened

When I click on CREATE PROJECT, I keep seeing the same page, and the spinner animation keeps going on the button.

In my browser’s developer tool console, I se the error on the screenshot.

image
image1712×592 44.1 KB

The error is also reflected in the Networktab.

If I create a public project instead, it becomes visible on the discover page but it is not functional.

All attempts on creating a project do appear in the admin/projects/project page even though they do not appear on the users side.

Specifications and configurations

The project is created with the latest version of Docker and the stablebranch of taiga-docker.

Ther server is running on Linux Mint 22.1 xia.

nginx.conf:

http {
  server {
    # Listen on port 80 (http)
	listen 80;
    server_name taiga.domain.com www.taiga.domain.com;

    # Redirect all HTTP traffic to HTTPS
    return 301 https://$host$request_uri;
  }

  server {
    # Listen 443 ssl;
    server_name taiga.domain.com www.taiga.domain.com;
    
    # SSL configuration
    ssl_certificate /etc/letsencrypt/live/taiga.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/taiga.domain.com/privkey.pem;
      
    location / {
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Scheme $scheme;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_redirect off;
      proxy_pass http://localhost:9000/;
    }
  
  # Events
    location /events {
      proxy_pass http://localhost:9000/events;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_connect_timeout 7d;
      proxy_send_timeout 7d;
      proxy_read_timeout 7d;
    }
}

taiga-docker/.env:


# Taiga's URLs - Variables to define where Taiga should be served
TAIGA_SCHEME=https  # serve Taiga using "http" or "https" (secured) connection
TAIGA_DOMAIN=taiga.domain.com  # Taiga's base URL
SUBPATH="" # it'll be appended to the TAIGA_DOMAIN (use either "" or a "/subpath")
WEBSOCKETS_SCHEME=wss  # events connection protocol (use either "ws" or "wss")

# Taiga's Secret Key - Variable to provide cryptographic signing
SECRET_KEY="a_very_random_string"  # Please, change it to an unpredictable value!!

# Taiga's Database settings - Variables to create the Taiga database and connect to it
POSTGRES_USER=postgresuser  # user to connect to PostgreSQL
POSTGRES_PASSWORD=postgrespassword  # database user's password

# Taiga's SMTP settings - Variables to send Taiga's emails to the users
# I've left out the smpt settings. Let me know if they are relevant for this.

# Taiga's RabbitMQ settings - Variables to leave messages for the realtime and asynchronous events
RABBITMQ_USER=rabbitusername  # user to connect to RabbitMQ
RABBITMQ_PASS=rabbitpassword# RabbitMQ user's password
RABBITMQ_VHOST=my_taiga_container  # RabbitMQ container name
RABBITMQ_ERLANG_COOKIE=a_very_random_value  # unique value shared by any connected instance of RabbitMQ

# Taiga's Attachments - Variable to define how long the attachments will be accesible
ATTACHMENTS_MAX_AGE=360  # token expiration date (in seconds)

# Taiga's Telemetry - Variable to enable or disable the anonymous telemetry
ENABLE_TELEMETRY=True

I hope someone is able to help me out. Please let me know if there’s any information, I should provide.

2

This seemed to be the issue. I had changed this configuration like I had changed users and passwords to not be the same as the default. I cannot remember if I initialised first time with this vhost and then changed it later but nevertheless, Taiga expected the RabbitMQ container to be called “taiga” as was the default setting.

So I’ve found the answer to this specific issue, but if someone happens to come across this thread in the future, please feel free to give some extra information on which configurations should not be changed from the default ones and which should.

I have also learned that it can be difficult to change configurations after the first launch as simply restarting the Docker image doesn’t recreate the whole instance with updated configurations:

docker-compose down
docker-compose up -d

Instead, you will sometimes have to figure out which volumes you have (docker volume ls) and remove all the relevant ones, so they can be recreated with the now configurations, which will also delete data you have on your Taiga instance. For example:

docker volume rm taiga-docker_taiga-async-rabbitmq-data taiga-docker_taiga-events-rabbitmq-data