Hi,
I’m running the Xibo Docker (1.8.2) with remote mysql on CentOS 7. Xibo CMS is running fine and is able to connect to the MySQL DB. The android player can do the initial connection to the CMS as well but fails to download content.
I get the following errors alternatively in the Display management log:
Unable to start XMR queue: class java.lang.UnsupportedOperationException
XMR unresponsive, issue reconfigure.
XMR is enabled on port 9505 (public) and 50001 (private). Xibo CMS is running on local port 8989 with Apache doing a reverse proxy on SSL only (port 80 isn’t enabled).
Output of docker ps -a: IMAGE COMMAND CREATED STATUS PORTS NAMES xibosignage/xibo-cms:release_1.8.2 "/entrypoint.sh" 13 minutes ago Up 13 minutes 127.0.0.1:8989->80/tcp xibodocker_cms-web_1 xibosignage/xibo-xmr:release_1.8.2 "/entrypoint.sh" 13 minutes ago Up 5 minutes 9505/tcp, 0.0.0.0:9505->50001/tcp xibodocker_cms-xmr_1
Assuming that XMR public address is correctly configured in CMS Settings, that’s all you should need to do in docker installation regarding it.
You can issue the XMR reconfigure on the display:
Displays page -> Edit display -> Advanced tab -> Reconfigure XMR & Save the form.
I’m not sure if that’s the only problem there, you can enable auditing on the Displays (also on advanced tab) and see if there are any other errors logged.
If you’re using 1.8.2 CMS and R102 player and XMR public address is correctly configured in CMS settings, then I’m not certain why would see this message then.
XMR aside, that will not be the root cause behind your downloading problem there, at a guess it will be something with your reverse proxy config, if you’d enable auditing on the display, there should be error messages logged that should help us to tell you where exactly is the problem.
Is there any way to verify that the XMR public address is working properly? For example, can I telnet to mydomain.com:9505 and expect a response?
UPDATE: I can telnet to port 9505 successfully when polling the server via local subnet IP as well as public FQDN.
Even PortQuery returns listening on 9505.
On local subnet IP:
Starting portqry.exe -n 10.1.2.41 -e 80,443,9505 -p TCP ...
Querying target system called:
10.1.2.41
Attempting to resolve IP address to a name...
IP address resolved to xxx.mydomain.com
querying...
TCP port 80 (http service): LISTENING
TCP port 443 (https service): LISTENING
TCP port 9505 (unknown service): LISTENING
portqry.exe -n 10.1.2.41 -e 80,443,9505 -p TCP exits with return code 0x00000000.
Through Public IP / FQDN:
Starting portqry.exe -n xxx.mydomain.com -e 80,443,9505 -p TCP ...
Querying target system called:
xxx.mydomain.com
Attempting to resolve name to IP address...
Name resolved to 61.x.x.x
querying...
TCP port 80 (http service): LISTENING
TCP port 443 (https service): LISTENING
TCP port 9505 (unknown service): LISTENING
portqry.exe -n xxx.mydomain.com -e 80,443,9505 -p TCP exits with return code 0x00000000.
I think we can conclude that the XMR port is open and the service is responding. Is there any other way to check?
Secondly, I have turned on Audit logs for the Display. Where do I find the output? In the Logs section?
The following output is appearing in the Display Management screen:
ID Date Message
10442 2017-10-11 10:02 Unable to start XMR queue: class java.lang.UnsupportedOperationException/xxx.mydomain.com
10439 2017-10-11 10:02 XMR unresponsive, issue reconfigure.
10388 2017-10-11 09:56 Unable to start XMR queue: class java.lang.UnsupportedOperationException/xxx.mydomain.com
10385 2017-10-11 09:56 The Schedule has not been downloaded yet.
10382 2017-10-11 09:56 Unable to prepare next layout and unable to show splash screen. Unable to create layout
10379 2017-10-11 09:56 /data/data/uk.org.xibo.client/files/0.xlf: open failed: ENOENT (No such file or directory)
10376 2017-10-11 09:56 /data/data/uk.org.xibo.client/files/0.xlf: open failed: ENOENT (No such file or directory)
10373 2017-10-11 09:56 Cannot set the next Layout from the Schedule. Schedule Invalid
10370 2017-10-11 09:56 /data/data/uk.org.xibo.client/files/0.xlf: open failed: ENOENT (No such file or directory)
10328 2017-10-11 09:54 Unable to start XMR queue: class java.lang.UnsupportedOperationException/xxx.mydomain.com
I’m able to fetch content via the client now. I installed a Windows client separately on my own laptop and tested the connectivity with it. The clue was in the Xibo Temp Library folder in the file requiredFiles.xml.
The client was attempting to access xdms.php using non-secure http protocol.
As per your suggestions in the installation manual, I had http turned off completely in favour of https. Once I re-opened http port, the content started downloading.
This is definitely a BIG STEP UP from getting no content at all.
It is possible to let the clients fetch content over https only? I attempted turning on Force HTTPS on in Xibo CMS settings - but since I’m using Apache reverse proxy to serve https here, turning on this setting in the CMS sends the page into a redirect loop and the CMS stops loading altogether. How do I accomplish this?
Secondly, the XMR issue still appears to remain. If you see the attached screenshot - the content is downloading now, but XMR error message is still there.
That is your problem. You’re mapping port 9505 of the host machine to port 50001 of the container. The two ports aren’t interchangeable.
You need to map port 9505 of the host to port 9505 of the container, and then the network we create with docker-compose should allow port 50001 to be available to the CMS.
Certainly what that’s showing there isn’t the standard configuration we ship, so I wonder if you’re not using compose? Or what modifications you’ve made if you are please?
I’m using docker-compose with the only difference here being the ports and remote mysql. Somewhere along the way I didn’t understand the port structure for XMR correctly and did that forced mapping from 9505 → 50001 in the cmx-xmr section of this file.
Is tcp://10.1.2.41:9505 what you have configured for the XMR public address?
XMR Registered just means the Player has sent it’s public key to the CMS. It doesn’t indicate connection.
It looks like you’ve bound the XMR public port to an internal only interface. That is designed to be publicly facing, so I’d expect it to be bound just “9505:9505”
You’re sure you’re not just seeing old log messages? They can take some time to be sent to the CMS. What does the Player status screen show if you look directly at that?
I’ve removed the internal IP binding. Now the containers look like:
IMAGE COMMAND CREATED STATUS PORTS NAMES
xibosignage/xibo-cms:release_1.8.2 "/entrypoint.sh" 6 seconds ago Up 5 seconds 127.0.0.1:8989->80/tcp xibodocker_cms-web_1
xibosignage/xibo-xmr:release_1.8.2 "/entrypoint.sh" 7 seconds ago Up 6 seconds 0.0.0.0:9505->9505/tcp, 50001/tcp xibodocker_cms-xmr_1
I don’t think they’re old messages. If you look at the timestamps - they keep progressing…
There’s no errors shown on the status screen, and I’d expect the same ones to be shown if it were still a problem.
With the redactions you’ve made it’s impossible to give any more insight I’m afraid.
The simplest thing is to show a layout with a clock on it, and then request a screenshot. If the screenshot comes back within a few seconds, and has the correct time on it, then XMR is absolutely working.
Thanks. I tried the screenshot method and I am getting back different screenshots. Does that prove XMR is working and I can disregard the error message?
Were using a big pool of Android licenses - I can continue with the commercial support option, if required.
If the screenshot is coming back straight away, then yes it proves it’s working. If it’s coming back after a delay (ie the collection interval), then it’s not working.