FOG 1.5.0 RC2 Reports and History Problems

[Jim Graczyk]

Server

• FOG Version: 1.5.0 RC2
• OS: CEntOS 7

Client

• Service Version: 0.11.12
• OS: Win10Pro & Win7Pro

Description: Snapin and Imaging Reports Failing, Problem with Snapin History in Host Area

Just (accidentally) upgraded to 1.5.0 RC2 on one FOG Server and 2 Storage nodes from v1.4.2. All CEntOS 7. Location Plugin was already installed in 1.4.2 pre-upgrade (maybe was installed initially on v1.3.4). Each Storage node is at a separate Location, in a separate storage group.

Snapin Report is blank / empty while Snapin History on Host lists snapin installs that I know happened. I was anxious to see if the Snapin report got some date and time filtering, but I see only No results found. There may be a data integrity issue. The Snapin History listing in the host area lists blanks in the Snapin column for old and new snapin tasks that have Queued status. This is odd since the v.1.4.2 system had no queued tasks when we took it down to upgrade it.

A side comment - I was hoping the Snap Log file would no longer spit out the complete history of all snapins ever deployed by the server when one initially requests the report (as v1.4.2 did). This change from previous versions of FOG made the report unusable. The list quickly become GIGANTIC, which takes a long time to arrive over slow connections and time-consuming to scroll thru.

I’m receiving an HTTP error 500 on when I select Image Log. The image history in the Host area appears to be correct.

If you need screenshots, I’ll post them.

Thanks,

Jim

[Sebastian Roth]

@Jim-Graczyk Could you please check if there are any entries left in the database. Open a command line mysql connection (just run mysql -u root -p and enter the password when asked for, find the password in /var/www/fog/lib/fog/config.class.php). Then

mysql> use fog;
...
mysql> select * from snapinTasks;
...

[Jim Graczyk]

There are several screens worth of results to the query (397 rows in set).

Getting a log out is not simple, but if you want a list, I’ll post it.

Several records have stReturnDetails == Pending… and Caneled due to new tasking
stState values include 1, 4, and 5. All records with Pending… and Canceled stReturnDetails have stStatus of 5, but not all redocrd with stStates of value 5 have Pending or Cancelled… stReturnDetail values.

Many records have stCompletDate == 0000-00-00 00:00:00
Very few of the records returned have stCheckInDates after the upgrade to 1.5.0 RC2, so I’m guessing the problem is old, but the reports still returned something in 1.3.4 and 1.4.2.

I have no need for this task history at this time (I will later, but not now). If I need to delete records please provide syntax.

thanks,

Jim

[Tom Elliott]

Pretty sure this was already reported and is fixed in the working branch, though updating and keeping us informed would be much better, thanks.

[Jim Graczyk]

Tom,

I regret that I accidentally upgraded to 1.5.0 RC2 - it was stupidity on my part - I only found the wiki to the ‘latest’ FOG release. What does one ‘checkout’ to get the working releases? How does one know when a new working release is made?

Thanks,

Jim

[Tom Elliott]

@Jim-Graczyk Not stupidity, you did everything fine.

I know in the past dev-branch WAS the “bleeding edge”, but to hopefully make things more proper, master branch in github has been made into the “stable”, dev-branch is for semi-stable (pre-release) type builds, and working is now the “bleeding edge”.

master = “latest stable”

dev-branch = “latest development release” = RC’s, could be stable as well sometimes

working = “Bleeding edge” = Where I am constantly ‘working’ on things. (Sometimes might match dev-branch and master.

My train of thought, push working stuff into working branch.
As working becomes ready for more testing, merge working into dev-branch. When working is ready for “official” release, merge working into dev-branch, merge dev-branch into master.

Seems a bit odd, but doing the separation like this allows me to push in master from dev-branch even if I don’t merge dev-branch from working first (hopefully making things more controllable).

This is all github/git based commands.

To checkout a specific branch:

git checkout <branchname>

In your case:

git checkout working
git pull
cd bin
./installfog.sh - y

[Jim Graczyk]

Upgraded to the latest working branch version.

The Image Log (under Reports) now works and appears to display correct data.

The Snapin Log (under Reports) still shows “No results found”.

Also found that the User Tracking Report has problems that were also seen in 1.5.0.RC2. I think the host name isn’t making it to the report. When you run the report with just a host selected, the list shows usernames that have logged in but the first column, host name is blank. When you run it with just a username selected, get only one row with the host blank and the user equal to the selected user. When you select both a hostname and a user name, you get only 1 row with no hostname and the username you selected.

I would expect this report to list host, user and a timestamp for all records reports choices.

Jim

[Tom Elliott]

@Jim-Graczyk Pull again, I noticed that already and it should be fixed.

[Jim Graczyk]

@Tom-Elliott

Looks like the reports now work. Thanks.

I do suggest that the user tracking report would be much more useful if it listed all record chronologically and showed the timestamp field. The summary report of who ever login in on a machine or what machine a user ever logged into is less valuable than the detailed report that one could filter at the headers based on any of the fields. This makes the snapin log work, and that would work here as well - imho.

Thanks a bunch… please make this one as Solved.

Jim