Basic question needing answer for anyone using reverse Proxy

[Marshalleq]

Do you have it working which way.

a) Your existing NGINX --> Taiga Gateway (NGINX) --> Taiga Front End 

Or

b) Your existing NGINX --> Taiga Front End 

Sorry for all the spam, but fundamental questions not being answered for 18 months I think I need to be short and specific.

Thanks anyone.

[Marshalleq]

12 days later it would seem nobody (including me) on this group actually understands reverse proxy's well.  I thought the above was an easy question too!

[Ken West]

Hi,

Here's my setup. I use the Docker installation of Taiga.

I'm presenting it as an indented list so read the order as the sequence in which the request is processed and the nesting as showing containers and contents.

When I identify the ports I'm using a non-conventional notation just to be clear whether the port is on the VPS or on Docker.

• VPS - listens on port vps:443
  • Reverse Proxy - listens on port vps:443
    • Proxy forwards requests on vps:443 to port vps:9000
  • Docker - listens on port vps:9000
    • Docker forwards requests on vps:9000 to docker:80
    • Docker:nginx - listens on docker:80
      • The rest is vanilla Taiga

Notes:

1. My reverse proxy is not NGINX but that shouldn't matter
2. If you want to put the Reverse Proxy and Taiga on different machines, then just change the Reverse Proxy to forwards requests on vps:443 to port vps2:9000 and change the firewall settings on vps2 to expose port 9000

Cheers,

[Marshalleq]

Hi thanks so much for answering my question!

So just reading what you've said above, so I assume your setup is as follows?

You seem to have similar to what I'm trying to achieve: Reverse Proxy A (Existing) --> Reverse Proxy B (Taiga NGINX) --> Taiga Front End.

So my question is, does your event system work (i.e. when you drag a card to a new status in one browser, it auto updates to that new status on all other browsers viewing the same e.g. sprint)?  If so did you have to do anything special to get that to work?

I haven't been able to get that to work and have assumed it is because of the first proxy in my chain (the existing one) breaking something because everything else is standard and working and always has been - with two reverse proxies I have seen and corrected their WSS error in the code.  Other alternative is it's broken for everyone, but I would have thought I'd be hearing more about that if it was.

Thanks!

Marshalleq

[Björn Pedersen]

Hi,

you need to  make sure that for /events you are the settings needed for websockets on  all involved proxies, especially if the proxy is nginx:

    

            location ^~ /events {

                proxy_pass http://events:8888/;

                proxy_http_version 1.1;

                proxy_set_header Upgrade $http_upgrade;

                proxy_set_header Connection "upgrade";

                proxy_connect_timeout 7d;

                proxy_send_timeout 7d;

                proxy_read_timeout 7d;

        }

Otherwise websockets are not proxied correctly. You should also check in the browser that ws(s)-connections are established.

 Björn

[Björn Pedersen]

Of course the proxypasss needs to be adjusted...

[Ken West]

Hi M,

Bjorn's advice is on-the-money re events.

In my case, the Reverse Proxy forwarded "/event" requests to localhost:9000 as per the 30-min setup instructions. But you need to set the proxy settings or the websocket won't work.

[Barry Ward]

I'm really struggling to get this configured and am in a similar predicament to Marshalleq....but I don't think I'm as far progresses.  Here's where I'm at...

Installed Docked and the Taiga containers

All run up ok without error (as fat as I can tell)

I seem to be able to connect to localhost, but without an X environment I'm not 100% certain.  Although installed on a PC with a GUI and it ran up sweet.

I can 'curl -Is http://localhost:9000' and return is HTTP/1.1 200 OK, so I think localhost is good.

I'm focused on HTTP first before I add additional complexities around SSL

I just cannot get NGINX configured correctly to connect from remote.  Presumably I just need to go to my web address without any trailing ports.  Strangely even though I have a HTTP setup, by browser wants to go to HTTPS - not sure why

I have NGINX running in Docker.  I believe this uses the ./taiga-docker/taiga-gateway/taiga.conf file to configure - correct?  This file is in it's original form except I added a line to define 'server_name'.

Docker logs show no errors for this NGINX

I also have NGINX running outside the container similar to Marshaalleq's diagram, but I'm really not certain how you configure this.  Like others in this forum I find the documentation to be lacking.

What I's really like from this forum is the following...

1. confirmation that taiga docker NGINX uses  ./taiga-docker/taiga-gateway/taiga.conf for configuration?
2. a copy of someone's  ./taiga-docker/taiga-gateway/taiga.conf which is working if it differs from the originally supplied.
3. a copy of someone's external NGINX file and exactly where this is located if it's not /etc/nginx/conf.d/default.conf

Happy to kill both steps and see examples where conf files are using letsencrypt keys also

Many thanks to all in this forum as there seems to be a real desire to help amongst members.

[Marshalleq]

Hi Barry!  I'm about to go out, but would be happy to share what I have when I get back to get you to step 1 - maybe we can figure it out together.  But also, I hope some others chime in because I still don't have a properly functioning message bus.

Yeah, I don't know why, but it seems I've either upset the Taiga personal and they don't want to talk to me, or they literally don't know how to answer this question.  I did have some attempts from one of them to answer it at one point, but it was unfortunately too ambiguous to make sense of and then they went quiet.  Frustrations abound!

Anyway - talk soon!

Marshalleq

[Barry Ward]

I had a breakthrough today.  Got the site up for remote access! 

For anyone else struggling, 

1. I installed the Taiga docker as per the 30 min instructions.  
2. I installed nginx on the server site.
3. From the ./taiga-docker folder, run
   sudo docker-compose up -d
4. Create the server site taiga.conf file (per the contents below) in the folder
   /etc/nginx/sites-available/taiga.server.conf
5. Create a symbolic link per the following
   cd /etc/nginx/sites-enabled
   sudo ln -s ../sites-available/taiga.server.conf .
   
6. Restart nginx
   sudo systemctl restart nginx

In the taiga.conf file in ./taiga-docker/taiga-gateway folder, all I changed was to add a new line at the top (replace with your server name):

 server_name project._________.com;

In the /sites-available/taiga.server.conf file, I added the following:

server {

    listen 80 default_server;

    server_name _;

    large_client_header_buffers 4 32k;

    client_max_body_size 50M;

    charset utf-8;

    access_log /var/log/nginx/taiga.access.log;

    error_log /var/log/nginx/taiga.error.log;

    # Frontend

    location /.well-known {

      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/;

    }

    # Backend

    location /api {

        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_pass http://127.0.0.1:8001/api;

        proxy_redirect off;

    }

    # Django admin access (/admin/)

    location /admin {

        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_pass http://127.0.0.1:8001$request_uri;

        proxy_redirect off;

    }

    # Static files

    location /static {

        alias /home/taiga/taiga-back/static;

    }

    # Media files

    location /media {

        alias /home/taiga/taiga-back/media;

    }

    location /events {

       proxy_pass http://127.0.0.1:8888/events;

       proxy_http_version 1.1;

       proxy_set_header Upgrade $http_upgrade;

       proxy_set_header Connection "upgrade";

       proxy_connect_timeout 7d;

       proxy_send_timeout 7d;

       proxy_read_timeout 7d;

    }

}

All this got my site going.  However, have not got the following working just yet...

1. events
2. /api/v1
3. I'm not really sure where my media is?  It's not in '/home/taiga/taiga-back/media' as this is in the docker container.
4. email
5. SSL
6. Keen to modify the server default values for status (epics, user stories and tasks) to a more 'non developer' set of values across all new projects.  

Any advice around obvious issues in the config files would be appreciated.

Still work in progress

[Ken West]

Hi Barry

Re 1 and 2 - I found the "developer tools" in Chrome useful for debugging what was happening. The Network view shows you the HTTP requests and responses and the Console shows errors. It's probably the settings in your docker-compose.yml that need tweaking.

Re 3 - there is a recent post in this group on how to back up a server that I found helpful to explainhow to get the database backups and media files out of the Docker container

Re 4 - set in docker-compose.yml - it's basic a SMTP set up

Re 5 - I don't use Nginx but there should be lots of help out there for doing that

[Marshalleq]

Hi all thanks again for all the input.

Ken, can I just confirm - you do have events working in your setup and the cards change when moved on all logged in browsers?  Sorry, but I asked this earlier and didn't get a 100% straight reply.  It does help to tick a very important box.

Björn, apologies if this sounds rude, but is this a functioning thing in your environment, or are you just helping out with the theory?  I've had such poor answers to these questions in the past I've had to become extremely specific validating everything I see - I hope you understand.

Based on what has been said above, it seems to me one of two scenarios is being suggested between the two of you for a back to back proxy setup:

1 - On the first proxy add an events section, but forward it to the same port 80 of the second proxy because on the second proxy there is only 1 listening port as per the 30 minute setup

2 - On the first proxy bypass the second proxy by sending events straight to the host.

I see no other option unless I modify the 30 minute setup to include additional listening addresses.  This is the bit that makes no sense to me.  And I've tried both of them - though that was a while ago now.

Anyway, apologies again if any of that is rude - I am trying hard to get solid answers to help prevent this conversation from going round in circles.

Can anyone comment around the specifics of 1 or 2?

Many thanks,

Marshalleq.

[Ken West]

Marshalleq,

In my environment ...

• Yes, "cards change when moved on all logged in browsers".
  • In Chrome, using Developer Tools, and looking at the Network tab, I see a long-lived connection to "events". It's a websocket that allows my browser to receive notifications from Taiga
• The Reverse Proxy sends /events traffic to the same port as it sends all other traffic - namely vps:9000 (using my notation - in the Docker container that is forwarded to port 80). I think that's your option 1 but I don't understand your set up

Ken

[Ken West]

Hi Barry,

You say that /events is not working.

The 30-minute setup guide says your Nginx configuration should be ...

server {

  server_name taiga.mycompany.com;

  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;

  }

  # TLS: Configure your TLS following the best practices inside your company

  # Logs and other configurations

}

It looks like your trying to duplicate the configuration of Taiga Gateway, which is not required for the Reverse Proxy.

Also your configuration of 'location /.well-known' looks wrong. Are you attempting to use Let's Encrypt for SSL certificate management? That shouldn't be redirected to Taiga! Rather, look up examples of how to configure Let's Encrypt (or whatever that is) for Nginx.

On Saturday, 4 September 2021 at 6:33:26 pm UTC+10 Barry Ward wrote:

[Marshalleq]

Thankyou so much - that is extremely helpful and what I've been looking for!  Now I can fault find it a lot more intelligently.

I have much excitement now that maybe I can finally have it all working!

Thanks,

Marshalleq

[Marshalleq]

Update, it works!!!! Finally!!!! Yusss!

So I think I have everything going now including SSL.

I suppose a good question to ask though is which of the 30 min setup nginx proxy sections should be in my other / first / upstream proxy other than / and /events.  I assume nothing else is needed?

Thanks again - hopefully I can help you a bit more too now Barry.

:D

Marshalleq

[Marshalleq]

So, I now need this tool - starting next week.  It's been running in the background happily, but yet again the events are not working.  I don't know what's wrong with me, this should not be this hard.  I swear nothing has changed, but I'm checking just in case.  It's a bit exasperating.  Have been trying to fault find it for nearly 2 hours so far and nothing.

[Marshalleq]

It's started working again just now, but I didn't change anything.  This is crazy.  I've even been down to the networking layer.  The only thing better I could do is dedicate a NIC in pass though.

[Pablo Ruiz Múzquiz]

It really sounds crazy.

Networking layer could be the issue (duplicate IPs, weird stuff like that sometimes happens) or struggling CPU/MEM resources that make some processes come and go (Taiga is quite frugal in those aspects but still...).

Pablo

--
Please help us keep the Taiga.io Community open and inclusive, follow our Code of Conduct:
https://github.com/taigaio/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
---
You received this message because you are subscribed to the Google Groups "taigaio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taigaio+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/b4eda620-131c-4fbf-bdb7-53b3ab9a568fn%40googlegroups.com.

--

	Pablo Ruiz Múzquiz CEO & Co-founder  (+34) 639635072 (+44) 07719222665  kaleidos.net

Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, y pudiendo contener información confidencial sometida a secreto profesional, o cuya divulgación esté legalmente prohibida. Cualquier opinión en él contenida es exclusiva de su autor y no representa necesariamente la opinión de la empresa. Si ha recibido este mensaje por error, le rogamos nos lo comunique de forma inmediata por esta misma vía y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. El correo electrónico vía Internet no es seguro y no se puede garantizar que no haya errores ya que puede ser interceptado, modificado, perdido o destruido, o contener virus. Cualquier persona que se ponga en contacto con nosotros por correo electrónico se considerará que asume estos riesgos. KALEIDOS OPEN SOURCE se reserva las acciones legales que le correspondan contra todo tercero que acceda de forma ilegítima al contenido de cualquier mensaje externo procedente del mismo. INFORMACIÓN PROTECCIÓN DE DATOS. Responsable: KALEIDOS OPEN SOURCE (B86241973) Le informamos que sus datos identificativos y los contenidos en los correos electrónicos y ficheros adjuntos pueden ser incorporados a nuestras bases de datos con la finalidad de mantener relaciones profesionales y/o comerciales y, que serán conservados mientras se mantenga la relación. Si lo desea, puede ejercer su derecho a acceder, rectificar y suprimir sus datos y demás reconocidos normativamente dirigiéndose al correo emisor o en los datos del responsable. Para información y consultas visite nuestra web  https://kaleidos.net