Displays lost authorization after update 1.8.12

[halonso]

Hi all,

Recently we have updated from Xibo CMS 1.8.9 to 1.8.12. Everything seems working fine but we have a problem with displays and their authorization.

After update I realized that majority of the displays losted the authorization to display content. I’ve authorized all displays again but… same problem. After some time (hours), many of displays changed to unauthorized again and again.

Any idea?

Thanks in advance!

[alex]

Is this a Docker install? A custom install, or on Cloud?

[halonso]

Docker install. We have 340 displays and from last Friday approx 40 of them lost authorization again.

Thanks for your help

[alex]

So to be clear, if you go to the Displays page the displays have a cross in the authorised column?

Or do you mean that they have a cross in the Logged In column?

Did you perhaps set a limit on the number of displays that can be licensed in the database?

[halonso]

So to be clear, if you go to the Displays page the displays have a cross in the authorised column?
Yes. See the image I’ve just taken.

Did you perhaps set a limit on the number of displays that can be licensed in the database?
I don’t know how to do that… I believe not. How can I check it?

[alex]

You can run the following SQL:

select * from setting where setting like 'MAX%';

See this guide for instructions on running SQL:

How can I run a SQL command when using a Docker Install?

While troubleshooting an issue you maybe asked to run a SQL statement on your database Docker container, or you may want to run a statement yourself for another purpose. To do either of these things there are two options. Using the command line Using the GUI called PhpMyAdmin Command Line Before you can run a statement inside the docker container you will need to find the container name. This can be done using the docker ps command. The resulting output will show a list of running docker con…

[halonso]

Thanks, here is the result:

It’s curious because we didn’t have the problem with Xibo 1.8.9.

[alex]

Is the count of displays increasing without you adding new Players?

[halonso]

No… number of displays remains constant. They lost auth randomly…

I’ve checked container log and saw this:

Configuring Maintenance
crontab: can’t open ‘/etc/crontabs/apache’: Permission denied
Running maintenance
Starting cron
Starting webserver

Maybe a problem?

Thanks!

[alex]

No that’s normal.

It’s not behaviour we’ve seen elsewhere, so I’m not sure what to suggest really. We’re discussing it here now.

[alex]

What Player types and versions are you using please?

Can you also go through the audit log and look for any instances of displays being deauthorised there.

Please also enable auditing on some displays that are authorised now, but that you think may become deauthorised, so we can capture any logs that might show us why that has happened.

[halonso]

Android Player with R104.

I see this events in audit log from February 1:

And this event (When I reauthorize displays, maybe):

{"licensed":"0 > 1"}

But not the inverse event.

I’m going to enable auditing on some displays…

[halonso]

Hi Alex, I’ve been auditing some displays. After 2 days one of this lost it’s authorization but I can’t see anything relevant in log:

ID	Date	User	Entity	EntityId	Message	Object
332553	18/02/2019 6:03		Display	102	Display Saved	{“display”:“TEST_1 > TEST_2”}
332555	18/02/2019 6:04		Display	102	Display Saved	[]
332556	18/02/2019 6:04		Display	102	Display Saved	[]
332559	18/02/2019 6:04		Display	102	Display Saved	[]
332560	18/02/2019 6:04		Display	102	Display Saved	[]
334455	18/02/2019 12:27		Display	102	Display Saved	[]
334457	18/02/2019 12:28		Display	102	Display Saved	[]
334458	18/02/2019 12:28		Display	102	Display Saved	[]
334964	18/02/2019 14:02		Display	102	Display Saved	[]
335734	18/02/2019 15:15		Display	102	Display Saved	[]
335769	18/02/2019 15:19	xibo_admin	Display	102	Display Saved	{“licensed”:“0 > 1”}
335776	18/02/2019 15:20	xibo_admin	Display	102	Display Saved	{“auditingUntil”:“0 > 1551308400”}
336050	18/02/2019 16:29		Display	102	Display Saved	{“auditingUntil”:"1551308400 > "}
336255	18/02/2019 17:57		Display	102	Display Saved	[]
336256	18/02/2019 17:57		Display	102	Display Saved	[]
336740	19/02/2019 5:16		Display	102	Display Saved	[]
336741	19/02/2019 5:17		Display	102	Display Saved	[]
336742	19/02/2019 5:17		Display	102	Display Saved	[]
336743	19/02/2019 5:17		Display	102	Display Saved	[]
336744	19/02/2019 5:17		Display	102	Display Saved	[]
336745	19/02/2019 5:17		Display	102	Display Saved	[]
336746	19/02/2019 5:17		Display	102	Display Saved	[]
337316	19/02/2019 7:01		Display	102	Display Saved	[]
337845	19/02/2019 8:52		Display	102	Display Saved	[]
338165	19/02/2019 10:40		Display	102	Display Saved	[]
338293	19/02/2019 11:17		Display	102	Display Saved	[]
338539	19/02/2019 12:48		Display	102	Display Saved	[]
338708	19/02/2019 13:25		Display	102	Display Saved	[]
338760	19/02/2019 13:44		Display	102	Display Saved	[]
338762	19/02/2019 13:45		Display	102	Display Saved	[]
338763	19/02/2019 13:45		Display	102	Display Saved	[]
338764	19/02/2019 13:45		Display	102	Display Saved	[]
338765	19/02/2019 13:45		Display	102	Display Saved	[]
338901	19/02/2019 14:05		Display	102	Display Saved	[]
340016	19/02/2019 18:21		Display	102	Display Saved	[]
340240	19/02/2019 21:00		Display	102	Display Saved	[]
340504	20/02/2019 6:11		Display	102	Display Saved	[]
340505	20/02/2019 6:11		Display	102	Display Saved	[]
340506	20/02/2019 6:11		Display	102	Display Saved	[]
342033	20/02/2019 12:41		Display	102	Display Saved	[]
342035	20/02/2019 12:42		Display	102	Display Saved	[]
342036	20/02/2019 12:42		Display	102	Display Saved	[]
342038	20/02/2019 12:43		Display	102	Display Saved	[]
342039	20/02/2019 12:43		Display	102	Display Saved	[]
342040	20/02/2019 12:43		Display	102	Display Saved	[]
342041	20/02/2019 12:43		Display	102	Display Saved	[]
342042	20/02/2019 12:43		Display	102	Display Saved	[]
342043	20/02/2019 12:43		Display	102	Display Saved	[]
342044	20/02/2019 12:43		Display	102	Display Saved	[]
342045	20/02/2019 12:43		Display	102	Display Saved	[]
342047	20/02/2019 12:43		Display	102	Display Saved	[]
342048	20/02/2019 12:43		Display	102	Display Saved	[]
342049	20/02/2019 12:43		Display	102	Display Saved	[]
342050	20/02/2019 12:43		Display	102	Display Saved	[]
342052	20/02/2019 12:43		Display	102	Display Saved	[]
342053	20/02/2019 12:43		Display	102	Display Saved	[]
342054	20/02/2019 12:43		Display	102	Display Saved	[]
342055	20/02/2019 12:43		Display	102	Display Saved	[]
342056	20/02/2019 12:43		Display	102	Display Saved	[]
342057	20/02/2019 12:43		Display	102	Display Saved	[]
342059	20/02/2019 12:44		Display	102	Display Saved	[]
342062	20/02/2019 12:44		Display	102	Display Saved	[]
342064	20/02/2019 12:44		Display	102	Display Saved	[]
342065	20/02/2019 12:45		Display	102	Display Saved	[]
342066	20/02/2019 12:45		Display	102	Display Saved	[]
342067	20/02/2019 12:45		Display	102	Display Saved	[]
342068	20/02/2019 12:45		Display	102	Display Saved	[]
342070	20/02/2019 12:45		Display	102	Display Saved	[]
342071	20/02/2019 12:45		Display	102	Display Saved	[]
342522	20/02/2019 14:14		Display	102	Display Saved	[]
342946	20/02/2019 15:10		Display	102	Display Saved	[]
342947	20/02/2019 15:10		Display	102	Display Saved	[]
343062	20/02/2019 15:28		Display	102	Display Saved	[]

We have a task that calls Xibo API and change the name of displays after some events to be able to join dynamic groups and change their schedule. This is the meaning of first line.

I can see the {“licensed”:“0 > 1”} (me ) event, but not the inverse that could cause the mistake …

Anyway, I don’t know what is the meaning of “Display Saved” event many times a day in the same display.

Thanks

[alex]

Display Saved is probably your API script running.

Can you give us some details of exactly the calls that is making?

[halonso]

Hi Alex, of course:

Our task is executing in every display with our own Android App.

The app only knows the device MAC address, so first call is GET API /display/ route using macAddress parameter (1).

When we know display ID we make another GET call to /display/ to get the display object. (2)

Finally we make a PUT call to /display/ sending display object with the name changed. (3)

Task is executed one o two times a day as much. So I don’t understand why “Display Saved” is listed many times in a short time.

[alex]

We’d need to see the actual parameters you’re passing back when you write to the CMS.

I presume you’re passing in to that call that the display should be licenced?

All I can suggest is stop the task running and see if the display saves go away. I’m not aware anything else will be regularly causing that to happen.

[halonso]

Hi Alex, nothing rare in parameters writed to CMS.

I’ve solved the problem, provisionally, activating auto authorization of displays and in the past days no display losted authorization.

Thanks