Layouts not showing when i’m using Xibo behind a loadbalancer (zen).
So when i use it locally: 192.168.x.x im seeing my layouts.
Whenever i use it from public, behind the loadbalancer, i’m able to login, see everything, except layouts are empty. I’m able to edit them as soon as i make a new one (which also doesnt appear in my layout overview).
so basically, remotely i’m able to see the layouts as soon as i make a new one, like i said before, they will however not show in the overview of all layouts.
If it’s anything like IIS reverse proxy you will need to make sure that the headers are being passed along correctly, which if you can’t see media Items and displays i suspect it the case. There’s a very complete guide to setting up apache2 as a reverse proxy on the forum. You should be able to setup your reverse proxy corrrectly after looking at the config.
Just saw you said only layouts aren’t showing. Use console to debug what the difference is between direct connection and connection via the loadbalancer. How many front ends are you using on the load balancer? and does this happen on each different cms instance when you connect directly?
With every frontend (xibo) from version 3 and onwards. 2.3 works. I dont really do a special setup, just basic and my loadbalancer handles the https part while the backend listens on http.
Let’s just say you’re using version 3.3.3 Does every CMS front end that the LB is sending traffic to behave the same way? You can test by shutting down all but 1 of the CMS web front end, then rotate through. If each front end cms behaves the same then I’d check your LB setup. I guessing it is losing something in the header when your LB reverse proxies the content.
FWIW i’m using cloudflare’s load balancing service, with 4 VMs running xibo 4.0.0, connecting to a clustered mysql 8 database and on each front end cms i have this in my apache config.
<VirtualHost *:443>
The ServerName directive sets the request scheme, hostname and port that
the server uses to identify itself. This is used when creating
redirection URLs. In the context of virtual hosts, the ServerName
specifies what hostname must appear in the request’s Host: header to
match this virtual host. For the default virtual host (this file) this
value is not decisive as it is used as a last resort host regardless.
However, you must set it for any further virtual host explicitly.
