Snapin Log Fails in Latest
-
Server
- FOG Version: 1.5.0-RC-8 v11
- OS: CEntOS 7
Description
Reports/Snapin Log produces “this page isn’t working” (HTTP ERROR 500) in Chrome
-
What’s the apache error log show?
-
The code for this report hasn’t changed at all, so if it worked for Rc7 or rc8, then I’m going guess you’re running into an “out of memory” type issue in PHP. In which case, you can update the memory needed for PHP in FOG Configuration Page->FOG Settings->General Settings->Memory Limit.
-
here’s the apache access_log entry:
10.179.100.176 - - [16/Aug/2017:14:26:41 -0400] “GET /fog/management/index.php?node=report&sub=file&f=c25hcGluIGxvZw== HTTP/1.1” 500 - “http://fogserver/fog/management/index.php?node=report” “Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36”Here’s the error_log entry:
[Wed Aug 16 14:26:44.353839 2017] [:error] [pid 54441] [client 10.179.100.176:51371] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 52476 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 261, referer: http://fogserver/fog/management/index.php?node=report
So it is a PHP memory issue. I’ll look up how to increase this. It’s set to what I’m guessing is 132Mb. I’ll set it to 512MB. RAM is not an issue.
But is there a greater issue?
Given that the Snapin log has no filtering before the web page is created, I’d think base settings would be set at least to allow many thousands of line in the initial report. If one chooses to use base images w/o much software already installed and deploy 10 snapins per host, with just 100 machines, this report would be 1000 lines log. Over time with re-imaging or more machines, one could expect the initial listing of the Snapin Report to become unmanageably huge.
I working on a preproduction installation developing images and snapins for a project. I have only 20 machines in my lab. If my installation is running into limits, maybe base limits should be higher.
My opinion is the approach used in previous versions, where a date filter as possible before requesting the report was a more scalable solution. In previous deployments of FOG, histories remained in place for a year or more and with 1000 machines or more, exporting reports from the beginning of the project to the present, as the current version initially does, would represent a lot of exported, transmit, and display cycles that would better done by an SQL query. Especially if a user is on a WAN link, the load could become prohibitive.
Just some thoughts to consider.
thanks,
Jim
-
-
@jim-graczyk The limits are set at 128MB, as this is the default for PHP as a whole. I have thought about making the limit’s higher, but as the use cases are different I feel it’s just as appropriate to leave it as “default” but adjustable. One of the upside’s to this being adjustable in the DB as it currently stands is it allows the admin’s to limit the memory usages as necessary and those settings stay regardless of system updates. Setting a higher limit isn’t hard (very easy to tell the truth) but it’s also just as easy to inform the user/admin where to make the setting and I think it’s more appropriate to let the user/admin decide what their top limit should be rather than let FOG make those determinations
While you’re correct that 10 snapins, in this case, on 20 devices would make a lot of snapins, Iam of the opinion that this is relatively an edge case. I totally understand the feasibility of what the snapins are doing, and I can actually look into the snapin history elements to gain more insight into what’s causing the memory issue, but it’s, in my experience, not a normal thing. (The not normal meaning most people I’ve helped typically only have 1 or 2 snapins. I have seen other cases where the user may have many more than 10 though these are FAR less than the number of user’s I’ve helped over time.)
Using time based model to get the snapin report makes perfect sense and I do plan on reintegrating it, but wanted to also make sure that what was in place worked and worked properly before worrying about extending how to obtain the reports. I work on the “whole” of FOG and my main focus is on making the GUI as usable as I can (as you can hopefully tell by the quick turnarounds to fix the issues almost at the time I see the new report). Yes, the reporting elements could use refinement. No, I’m probably not going to be as quick to get the refinements in as I am to get the gui layout, look, and feel mostly completed. Yes, I do plan to get these refinements in the 1.5.x series. No I doubt I will have these refinements for 1.5.0 stable. (Not saying it can’t get done, but I’m literally one guy).
-
Great, fine and wonderful.
My intention was to make you aware of the issues we’ll encounter as an installation ages or when there are lots of PCs relying on 1 FOG server. It’s clear you get it, so I’ll just wait to see what happens. My history with deployments goes back 22 years (arghhh). My first deployment was 8000 PC in 1994 (NT 3.51). I’ve used various software packages and deployment methods. I’ve needed as many as 4000 PC to be deployed at a single site, and I’ve lived with these systems for years at a time. I’ve focused on hardware independent images from the beginning and typically create two base images for a given OS; one with MS Office and one without. Both have various tools installed (7zip, Acrobat, that sort of thing). I’ve leveraged snapins to arrive at the PC each user actually needs.
I’m guessing from your comments I’m atypical.
To address issues with reports, can you point me to any doc that tells me anything about how to create reports to be imported?
Thanks for your explanations.
Jim
-
@jim-graczyk I wouldn’t consider your layout “atypical” just necessarily what I see most people using FOG for. I certainly want to make fog the best product possible and will do my best to keep fog in such a light - I hope I’m doing okay in that regard (not needing reassurance just a general rhetorical thought/question).
I fully appreciate the awareness and information given and just hope to give any insight as to where things may not be what would be expected, particularly how to fix the things as when the items seem appropriate.
I don’t really have a document on how to create reports to be imported as all reports that currently exist have been either ported from older versions of fog, or user requested reports that I just created for them. I know it’s not the best way to go about things, but it seems to have worked for now.
The best source of what is current with reports would be to look at other reports, and make adjustments as required.
The quick and dirty basics:
The location of reports, now, is in/var/www/fog/lib/reports/
The reports are class files now. With an identifier of
<classname_of_report>.report.php
For the report that’s imported to show up on the list of “usable” reports, If you wanted report name to show up as:
Classname Of Report
, your literal classname would be:
class Classname_Of_report
(in the php file). and the FIlename would be:classname_of_report.report.php
The method inside the report that kind of “does” the work is currently:
public function file() {}
Everything else is pretty much up to you.
So let’s say you wanted a literal report to be : “Classname Of Report”
and that report simply printed “Hello World” Your filename would be:
/var/www/fog/lib/reports/classname_of_report.report.php
The class would look something like:
<?php /** * Prints hello world into a report. * * PHP Version 5 * * @category Classname_Of_Report * @package FOGProject * @author Jim Graczyk <some@email.here> * @license http://opensource.org/licenses/gpl-3.0 GPLv3 * @link https://fogproject.org */ /** * Prints hello world into a report. * * @category Classname_Of_Report * @package FOGProject * @author Jim Graczyk <some@email.here> * @license http://opensource.org/licenses/gpl-3.0 GPLv3 * @link https://fogproject.org */ class Classname_Of_Report extends ReportManagementPage { /** * Display Page * * @return void */ public function file() { echo "Hello World!"; } }
A far more “useful” example I think would be:
<?php /** * Prints hello world into a report. * * PHP Version 5 * * @category Classname_Of_Report * @package FOGProject * @author Jim Graczyk <some@email.here> * @license http://opensource.org/licenses/gpl-3.0 GPLv3 * @link https://fogproject.org */ /** * Prints hello world into a report. * * @category Classname_Of_Report * @package FOGProject * @author Jim Graczyk <some@email.here> * @license http://opensource.org/licenses/gpl-3.0 GPLv3 * @link https://fogproject.org */ class Classname_Of_Report extends ReportManagementPage { /** * Display Page * * @return void */ public function file() { $this->title = _('Hello World'); $csvHead = array( _('Hello'), _('World') ); foreach ((array)$csvHead as &$csvHeader) { $this->ReportMaker->addCSVCell($csvHeader); unset($csvHeader); } $this->ReportMaker->endCSVLine(); $this->headerData = array( _('Hello'), _('World') ); $this->templates = array( '${hello}', '${world}' ); $this->data[] = array( 'hello' => _('Hello'), 'world' => _('World') ); $this->ReportMaker->appendHTML($this->process(12)); echo '<div class="col-xs-9">'; echo '<div class="panel panel-info">'; echo '<div class="panel-heading text-center">'; echo '<h4 class="title">'; echo $this->title; echo '</h4>'; echo '</div>'; echo '<div class="panel-body">'; if (count($this->data) > 0) { echo '<div class="text-center">'; printf( $this->reportString, 'Hello_world', _('Export CSV'), _('Export CSV'), self::$csvfile, 'Hello_world', _('Export PDF'), _('Export PDF'), self::$pdffile ); echo '</div>'; } $this->ReportMaker->outputReport(0); echo '</div>'; echo '</div>'; echo '</div>'; $_SESSION['foglastreport'] = serialize($this->ReportMaker); } }
-
For more information on some of the methods and class based variables please see:
All fog installations, now, should have the folder:
/var/www/fog/fogdoc
available. It is possible to build local documentation of all classes using doxygen.The command to build it would be:
cd /var/www/fog doxygen fogdoc/fogdoc
The fogdoc currently is designed to place the fogdoc in /var/www/fogdoc, so a link to your properly html root directory, or fog directory will probably yield in slightly better results for generating this documentation.