Login reports white page
-
Normally, now, the problem is not something wrong in the code at all, rather there’s more information than can be presented immediately.
-
This can’t be it, as the host I tested had only four login entrys.
-
@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.
-
Thanks for your offer, but this is not possible due to privacy policies.
-
@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
-
+-------+----------+------------+----------+---------------------+--------+----- -------+---------+ | 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
-
@Polii123 Do you have any apache errors in your error log about memory? Like ‘memory exhausted’ or anything similar?
-
No, nothing like that.
-
@Tom-Elliott I’m out of ideas here.
-
@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. -
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.
-
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).
-
@Polii123 Any work in RC 6 for the problem?
-
@Tom-Elliott
Works perfectly now! Thanks a lot!