Login reports white page

[Polii123]

Server

• FOG Version: 1.4 RC1
• OS: Debiann 8

Description

Hi

I tried to make a Login Report for a specific host, but I always get a white page when I search for entries. It doesn’t matter wich host i use or how long the timespan is. The same error occurs when choose a user instead of a host.

I had the same issue on 1.3.5 so I guess this bug is a bit older.

[Wayne Workman]

Generally white pages are caused by php syntax errors. Those would be revealed in the apache error log. So, cause the error to happen and then immediately go look in the logs here: Web Interface -> FOG Configuration -> Log Vierwer -> Apache Error Log All the logs are timestamped, you can sort them from newest to oldest. Find the one with the error and post it here.

[Polii123]

There isn’t any error related to the reports.

[Wayne Workman]

@Polii123 We can wait for @Tom-Elliott to have time to look at the issue. It’s probably still yet a syntax issue in the web code.

[Tom Elliott]

Normally, now, the problem is not something wrong in the code at all, rather there’s more information than can be presented immediately.

[Polii123]

This can’t be it, as the host I tested had only four login entrys.

[Wayne Workman]

@Polii123 If you’re willing to email me a copy of your DB, I can figure out what’s wrong with the data and/or fog. IM me for my email address.

[Polii123]

Thanks for your offer, but this is not possible due to privacy policies.

[Wayne Workman]

@Polii123 I understand. I’ll still try to help.

Get the hostname of the system you want a report for, and use it’s name in this SQL statement to get the report you want. Look closely and carefully at the data returned - we need you to spot what’s wrong with it.

mysql -D fog
select * from userTracking where utHostID in (select hostID from hosts where hostName = 'ComputerNameHere');
quit

[Polii123]

@Wayne-Workman

+-------+----------+------------+----------+---------------------+--------+-----                                                                          -------+---------+
| utID  | utHostID | utUserName | utAction | utDateTime          | utDesc | utDa                                                                         te     | utAnon3 |
+-------+----------+------------+----------+---------------------+--------+-----                                                                          -------+---------+
| 94873 |     1012 | user | 1        | 2017-03-24 14:38:46 |        | 2017                                                                          -03-24 |         |
| 94953 |     1012 | user | 0        | 2017-03-24 15:34:14 |        | 2017                                                                          -03-24 |         |
| 95046 |     1012 | user | 1        | 2017-03-24 17:13:17 |        | 2017                                                                          -03-24 |         |
| 95057 |     1012 | user | 0        | 2017-03-24 17:41:27 |        | 2017                                                                          -03-24 |         |
| 95074 |     1012 | user | 1        | 2017-03-25 06:59:53 |        | 2017                                                                          -03-25 |         |
| 95075 |     1012 | user | 0        | 2017-03-25 07:10:23 |        | 2017                                                                          -03-25 |         |
| 95450 |     1012 | user| 1        | 2017-03-27 09:33:39 |        | 2017                                                                          -03-27 |         |
| 95604 |     1012 | user | 0        | 2017-03-27 11:10:54 |        | 2017                                                                          -03-27 |         |
| 95789 |     1012 | user | 1        | 2017-03-27 13:51:00 |        | 2017                                                                          -03-27 |         |
| 96178 |     1012 | user | 1        | 2017-03-28 07:30:43 |        | 2017                                                                          -03-28 |         |
| 96268 |     1012 | user | 0        | 2017-03-28 08:11:41 |        | 2017                                                                          -03-28 |         |
| 96400 |     1012 | user | 1        | 2017-03-28 10:25:29 |        | 2017                                                                          -03-28 |         |
| 96777 |     1012 | user | 0        | 2017-03-28 15:10:47 |        | 2017                                                                          -03-28 |         |
| 97285 |     1012 | user | 1        | 2017-03-29 11:48:59 |        | 2017                                                                          -03-29 |         |
| 97330 |     1012 | user | 0        | 2017-03-29 12:10:02 |        | 2017                                                                          -03-29 |         |
| 98955 |     1012 | user | 1        | 2017-03-31 09:18:52 |        | 2017   

[Wayne Workman]

@Polii123 Do you have any apache errors in your error log about memory? Like ‘memory exhausted’ or anything similar?

[Polii123]

No, nothing like that.

[Wayne Workman]

@Tom-Elliott I’m out of ideas here.

[Wayne Workman]

@Polii123 Would you consider truncating the table to start fresh? This will most likely fix the issue immediately so you can start using the login history reports from now forward. You can take a database backup before via Web Interface -> FOG Configuration -> Configuration Save -> Export
Tom hasn’t responded, and without being able to find the problem myself, this is the only thing I can offer.

[Tom Elliott]

I don’t think truncating the table would help with anything.

That all said, I’ve refactored the code and separated it out from the main “report” page and am working to do similar actions to all reports. The idea of moving all reports into a common file before was simply to get them into an OOP based style when compared to how they were (long ago) being parsed and processed.

Now that I have a “clean” system to work with, I can actually move these reports back to the report folder, and will likely move them from ‘management/reports’ to ‘lib/reports’ so we have a common point that can be easily “pluggable” too.

[Tom Elliott]

1.4.0 RC 5 should address the problem though I will admit it initially removes a level of functionality people have probably become accustomed to.

Of note here, it will now display hostname and user.

The “Username” will remain under the user and the host will remain under the hose.

Clicking the “host” will display all login events for that host.
Clicking on the “username” will only display items for the hostname that was selected.
I will probably add another cell later on that will allow you to select a user for all hosts.

Currently it will be:

[hostname] [username]

Clicking [hostname] will show all user tracking events with this hostname.
Clicking [username] will show all user tracking events specific to this host AND user.

Future functionality (possibly):
[hostname] [username - specific to host] [username - all hosts with this user]

Hopefully this makes sense to everybody.

It will not ask about dates. This same thing will occur for imaging and snapin logs as well. (I do plan to add this back but more in a filter approach than a you must know what you want to look for first approach).

[Tom Elliott]

@Polii123 Any work in RC 6 for the problem?

[Polii123]

@Tom-Elliott
Works perfectly now! Thanks a lot!