SOLVED FOG 1.5.0 RC2 Reports and History Problems

  • Server

    • FOG Version: 1.5.0 RC2
    • OS: CEntOS 7


    • 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.



  • @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.


  • Senior Developer

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

  • 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.


  • Senior Developer

    @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
    ./ - y

  • 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?



  • Senior Developer

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

  • 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.



  • Senior Developer

    @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;