PRTG Maps are only white pages after PRTG Update

[Alex-P-mse]

Overview of the Issue

I use Screenly OSE for displaying maps which are provided by the monitoring software PRTG. Basically, I paste the appropriate links to the web pages and Screenly calls them up. They look like this: "https://internal-IP-address/public/mapshow.htm?id=1234&mapid=1BB8A335-the-rest-of-the-mapID" However, since we updated PRTG, the maps are only displayed as a white page. But things like the PRTG Copyright text in the buttom left corner are still there. So that means that the maps are probably not renderes correctly.

Reproduction Steps

After some research, I am 90% sure that PRTG is now using a new version of Python (3), which Screenly cannot work with. Unfortunately, Screenly is still running 2.7.16 and upgrading Screenly OSE doesn’t seem to help. I have also tried manually upgrading Python to 3.7 without success. After a reboot, the web interface shows a “504 Gateway Time-out” error and no output comes through HDMI.

Environment

• Raspberry Pi Hardware Version: 3B
• Raspberry Pi Network Setup: built-in WiFi
• Screenly OSE Version: production@d12df55 I tried updating via the curl command and the web interface but that didn't help. I get this message after finishing the upgrade. Maybe that helps

[vpetersson]

You're still on the "production" branch. This is very outdated. We are yet to merge in the work from the last few years there (for a long set of reasons). Try rerunning the installer. That should give you a much more modern browser that can hopefully support the dashboards.

[Alex-P-mse]

I ran the bash <(curl -sL https://www.screenly.io/install-ose.sh) command. I said "no" to managing the network because the pi has a fixed IP and yes to the full system upgrade because why not. This is the result: He doesn't really update that much and defaults to the production branch. Can I change that manually? The upgrade via the webinterface doesn't seem to do much either.

[vpetersson]

That's odd. Yeah I'd do a git checkout master in ~/screenly and than re-run the script from ./bin/install.sh.

[Alex-P-mse]

I don't really know much about Git. Could you tell me what this means?

[vpetersson]

You've made some local changes that needs to be removed.

First, don't run this as sudo, as that will break things. Then run:

$ cd ~/screenly
$ git reset --hard
$ git pull
$ git checkout master

[Alex-P-mse]

Unfortunately that didn't help much. Is there a recent image I could download, to reinstall screenly on the pi?

[vpetersson]

Yeah, I'd recommend that you flash out the latest version of Raspbian Bullseye (minimal) and then re-run the installer. That's probably the path of least resistance.

[kroona]

Got the same issue, but i'm using Samsung Magicinfo.

[Alex-P-mse]

This took a while... When I try to access our internal page, I get a browser error via the screenly output. "ERR_CERT_AUTHORITY_INVALID". This is strange, because I once accessed the same page with a Windows machine over the same WLAN. There is no error there and the connection is stated as "secured". I have stored all company-internal certificates at Screenly to prevent such errors, but that doesn't seem to be the cause. Maybe it's already working and the Screenly browser hasn't noticed yet. Is there a way to clear the browser's cache or can I otherwise make it ignore such errors? Or is it perhaps something completely different?

[vpetersson]

@Alex-P-mse are you using the latest version from master? If you're still on the old 'production' release, that would explain odd browser behavior.

[Alex-P-mse]

After the clean installation of Raspbian Bullseye Minimal I was able to install the master@a81db56 Version via the script.

[Alex-P-mse]

I did another new installation, because I saw a changed installation link in your github page. Now I'm on master@04ee129

[Alex-P-mse]

I did an Update via the script because ther was an "Update available" prompt on the web interface. Now I'm on master@f310406

But still no change

[vpetersson]

Got it. Yeah, hard to tell w/out having a way to reproduce this.

[Alex-P-mse]

Is there a way to tell the browser to ignore these certificate errors? He just seems to distrust this link but I know that it's safe.

[vpetersson]

You can't ignore them per se. Is the website served using a self-signed certificate?

If so, we don't really do anything special. The browser just behaves like the system. If the system trusts the certificate, so will the browser. As such, something like this should do.

[ealmonte32]

@Alex-P-mse , I replied to your Forum post: https://forums.screenly.io/t/prtg-maps-are-only-white-pages-after-prtg-update/857/3

[Alex-P-mse]

@vpetersson I used ca-certificates to import the certificate that Screenly should trust. Unfortunately this did not help. Next I tried to call the website with a curl command on the CLI and see what I get back. I got back an HTML text with the basic structure of the PRTG page and no certificate error message. This makes it seem like it's the browser itself that's causing the problems and not the system, but I could be wrong.

In parallel I also started a test phase of Screenly-Pro. The pages didn't work right away, but there is an option "Verify SSL certificates" which you can deactivate. With this it worked immediately. Is there maybe something similar in the config of the QtWebView browser?

[Alex-P-mse]

@ealmonte32 Thanks for that but I'm already further down the road. The reinstallation helped and the system runs. Now I am only struggling with the certificate error message "ERR_CERT_AUTHORITY_INVALID".

[vpetersson]

@vpetersson I used ca-certificates to import the certificate that Screenly should trust. Unfortunately this did not help. Next I tried to call the website with a curl command on the CLI and see what I get back. I got back an HTML text with the basic structure of the PRTG page and no certificate error message. This makes it seem like it's the browser itself that's causing the problems and not the system, but I could be wrong.

I just realized that installing it on the system won't make a difference. You need to do it in the viewer container, since the container doesn't share certificates with the system. Can you try repeating the same process, but within the viewer process? Granted, this will require you to either patch the Dockerfile or re-apply the patch at every upgrade.

[ealmonte32]

Vik you beat me to it, I was going to tell him the same thing, he needs to import the certificate inside the container by doing docker exec it screenly-srly-viewer bash and doing all via commands and copying it from the host to the container..

[Alex-P-mse]

I have to do what? First of all thanks for the input, but unfortunately I don't have much knowledge about docker and "doing something inside the viewer process". Can you please give me more detailed instructions on how to import the certificate into the container?

[ealmonte32]

@Alex-P-mse

I will try to help with instructions, but once i help you get into the docker container and show you where the certificates are, you must try some of the different suggestions out there on installing or trusting self-signed certificates on the container running the browser.

To get into the docker container that runs the OSE browser, do as I am doing on the screenshot to enter the screenly-srly-ose-viewer-1 with bash:

As you can see, there are the built-in trusted certificates, but you can also use the /usr/local/share/ca-certificates location and the workaround this person did here: https://forums.raspberrypi.com/viewtopic.php?p=1510313&sid=46f588ed425182825dec5c981bb28aec#p1510541

Otherwise, follow the instructions on the link vpetersson posted for you: https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list

Once you do what you need to do inside the viewer container, exit out of there and restart the viewer:

[Alex-P-mse]

So, I have tried this out. Unfortunately without success. The webview does not seem to be interested in what certificates I have set.

Is there maybe a feature in the pipeline where you can turn off SSL verification? Maybe a box to tik on or off.

[ealmonte32]

So, I have tried this out. Unfortunately without success. The webview does not seem to be interested in what certificates I have set.

When you say you have tried this out, you made your pi a CA and signed the certificate and imported it into etc/ssl/certs and all that? because it's a bit of a process..

Is there maybe a feature in the pipeline where you can turn off SSL verification? Maybe a box to tik on or off.

Sounds easy enough, but not that I can think of, because any changes to the qtwebview browser to ignore ssl for example requires a whole recompiling of it, and dealing with self-signed certificates are kind of outside the normal OSE troubleshooting because as you can see it is not that easy to deal with and very user specific situation..

[vpetersson]

When you say you have tried this out, you made your pi a CA and signed the certificate and imported it into etc/ssl/certs and all that? because it's a bit of a process..

Well, you only need to trust the CA that issued the cert.

[ealmonte32]

When you say you have tried this out, you made your pi a CA and signed the certificate and imported it into etc/ssl/certs and all that? because it's a bit of a process..

Well, you only need to trust the CA that issued the cert.

True, but he gives no specifics about the certificate so it must be a self-signed certificate, if it was issued by an internal company CA then he of course should import that CA's cert into the openssl certs and update ca-certificates, but again, not much info to go on.. 🤷🏻‍♂️

[vpetersson]

Fair -- yes if it's a fully self-signed cert than you're absolutely right.

[Alex-P-mse]

Yes I have done all these steps. We have a CA in our company that issued the certificates. I copied these into the appropriate Docker container, then opened the container's bash and then ran "update-ca-certificates". It also listed the two new certificates as "added" in the message. We use multiple pi's so we don't want to make each pi its own CA and publish all our sites multiple times so they run everywhere. Sorry for not giving you enough information.

[Alex-P-mse]

Ok we fixed the issue. We have handed over the necessary certificates at the time the site is called up. Now it works.