Posts made by Jim Graczyk

@Tom-Elliott

Changes the PHP memory limit to 512M in php.ini. Report now displays. Solved.

Jim

@tom-elliott

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

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

Server

• FOG Version: 1.5.0-RC-8 v11 (downloaded 30 mins ago)
• OS: CEntOS 7

Description

When in Hosts Icon, with the defaults set to initially list all host, selecting a host produces a web page with only some of the tabs functional:

Note that only the blue tabs produce any response from the server.

After selecting one of the functional tabs, all tabs appear functional:

and are as far as I can tell.

Jim

Server

• FOG Version: 1.5.0
• OS: CEntOS7

Client

• Service Version: 0.11.12
• OS: Win7

Description

I’m working on a Snapin for a VPN client install (SoftEther VPN - great freeware, recommend it highly - AND I have a working installation process).

The result is the VPN Client package testing has resulted in the FOG client informing FOG about the MAC address on the VPN vNICs the software creates.

While looking for a way to Dis-Approve Pending MAC addresses, I click on the + button (Add MAC Address) on the General form of the a Host page. Doing so caused the page to list many new places to add MAC addresses:

This screen shot is at 33% and there are 28 similar pages before one get’s to the bottom of the webpage.

Upon hitting the + to add MACs, the webpage becomes unresponsive. I cannot get a new page to come up - at least not too easily - and the server and workstation show substantial increases in load. From task manager:

I’m forced to close the browser and re-log in to be able to continue.

This only appear to occur on hosts with several pending MAC addresses and it may only occur what a browser is zoomed in.

Jim

@george1421

Thanks for the clarification. We’ve been caught with storage problems frequently enough that we know to use a separate disk volume for /images. For Snapins, we defined our processes when Snaps were much less capable than they are now. We use DFS on separate windows servers and leverage Samba as links under DFS on FOG storage Nodes for smaller sites. Our approach allows for easier tweaks to any Snapin by just editing the contents of some folders. No re-uploading to FOG and re-replicating a big ball of a Snapin. The only thing that replicates are the smaller changed files via DFS.

I get the old linux ‘mandate’ to separate everything into it’s own volume, though the guys I’ve worked with didn’t do that at the disk level, but at the partition level (since most had to deal with a storage team and getting one large chunk of disk and partitioning it was easier than explaining things to the storage team). I’m good with the concept, but don’t follow it dogmatically. Instead I consider the use of the server. If the server is an appliance - does one thing for you, as FOG does - then a FOG server than boots Linux but doesn’t do FOG is of no value to the business. In this case, I don’t split volumes for everything. This goes for Windows and Linux.

I haven’t had the problem you describe were the OS won’t boot, plus with VMs, it’s exceptionally easy to mount the VHD and free up space. I find that placing any hard limit on a specific folder (volume, disk, whatever) is an act of fortune-telling that will end up shutting down the app sooner than allowing all folders supporting an app use the space that’s allocated. I monitor everything with XYMON so I get alerts on disk consumption, but even without that, the run-time for the app is longer w/o partitions.

I only partition where there can be rapid growth that necessitates expanding a volume - and the /images folder in FOG is the best example, when uploading is required (server hundred GB in one client possible).

I know my thinking is contrary to what some feel are best practices in Linux, but I’ve been happy with the results… I don’t tend to lose the service the app/service provided because I miss-guessed the space log files need by 100MB.

Just my opinion…

Thanks
Jim

@george1421

You just placed a link in a current issue regarding the separating images on a separate volume. Rather than confuse the person to whom’s thread you were responding, I thought I’d post my questions here since they pertain more to this article than to the other guy’s question.

I regret that I’m buried with a project that has taken much longer than I had hoped, so I apologize up front for not having time to thoroughly read and digest your article here, and I completely understand if you don’t have time to answer a question that is answered above some where - but we’re moving forward rapidly with a small change to FOG for which I can foresee no problem, but we’re not doing what you recommend here.

To alleviate the issue of image storage, we chose only to mount a separate disk volume (on VMs, a VHD, on hardware an actual 1-4 TB HD) as /images and configured FOG at install (I believe) to use that folder for images.

Is this a mistake? We are required to upload every PC before re-imaging with win7 or win10, so we’ll have a boat load of images and will need space accordingly. At some sites, we may have to sway out the drive, if we need to. We’ve already tested the process and it appears to work, but are we missing something? It seems you’re splitting a lot of things up and splitting images of at a different folder.

Are there any long-term problems or scalability issues you know if we leave the FOG installation as-is out to the box, and move only the /images folder to a separate disk?

Thanks,

Jim

Thanks

Jim

Server

• FOG Version: 1.5.0 RC-7 v27 (just updates)
• OS: CEntOS 7

Description

When deploying an unassigned Snapin using Single Snapin, under Basic Tasks for a Host, the following message appears when no Snapins are assigned to the host:

It appears there is a check somewhere that requires at least one snapin to be assigned before a snapin - assigned or unassigned - can be deployed.

Jim

@birvin

I would also offer the suggestion that you separate the /images folder onto a separate virtual disk. You Could do this without rebuilding. I’ve used USB disks on ‘toaster’ that are mounted as /images as well. In either case, this allows use to expand the /images folder w/o messing with the rest of the install.

Wayne is an expert, so maybe my approach is more work. I’ve backed into this problem over and again, as image space has grown (mostly from uploads, in my case), but we were able to mount the old volume as /oldimages, mount the new empty volume as /images, copy image, then unmount the /oldimages volume. If I recall, it was only a matter of mess with fstab in my case.

Just a thought.

Jim

@tom-elliott

Tom,

We’re good on the cancellation issue, but I’m still seeing a series of packets with the same start time and ever increasing durations times for each subsequent snapin.

I didn’t get that you made a change. I doubt I can be of any help with the code, but I’ll look.

The screenshot above is a single deployment of an image with several snapins. There’s a reboot after 0-W7PostImageCleanup and another after 1-UACDisable. So there are 3 “series” of snapins in this deployment.

• 2017-08-10 12:24:36 (2 snapins)

• 2017-08-10 12:25:28 (1 snapin)

• 2017-08-10 12:26:14 (6 snapins)

All scheduled as part of the image deployment and all separated only by reboots implemented by FOG as part of a snapin.

Jim

@themcv

OK - so yeah, maybe it was a DNS issue on the client side after all. One of the snapins I’m working on dorked the DNS search list.

I determined this by examining the spanins deployed to the host - 100% alignment with snapin that dorks the DNS searchlist.

Go Figure…

Thanks and sorry for the trouble…

Jim

@sebastian-roth

That depends on whether you (all) have any intention of changing the reported start time and duration for snapins when they run in a series (a single pass of the Snapin component in FOGService.

I still believe it’s unclear to have all spanins show the start time of the first snapin in a series. I’ve done some extending of FOG on the Snapin deployment side. My snapins are network installs that reside on DFS on windows servers and Samba on storage nodes. This allows dynamic editing of all snapins w/o the need to reupload anything to the FOG server and prevents snapins from requiring 2x the freespace (1 to download from FOG, 1 for the installation). The FOG Snapin is a small exe that passes needed info the the CMD (regarding where to connect to the SMB share at each site) and starts the CMD. I log the output of each CMD (>>some_log_file.log) so as to make debugging easier for creating and running snapins.

The logging process I have clearly shows each subsequent snapin starting after the previous one completes. I don’t see why this wouldn’t be how FOG records snapin execution.

So, leave this one as UNSOLVED only if you will consider making the reported times accurate based on start time, end time and duration the snapin actually has.

Mark it as SOLVED if you don’t intend to change anything or feel there’s nothing to change.

Thanks,

Jim

Sebastian,

I often work late.

I’m working on a reusable design model so we’ve abstracted a great deal. We intend to use an alias for the FOGServer to point to (…wait for it… ) the FOG server, for each deployment - we’ve just changing the Alias in DNS. We want the desktop images to be reusable and generic.

So, for all the system I mentioned that work, they are also all using fogserver as the name of the fogserver - so it’s not a DNS issue.

Jim

Server

• FOG Version: 1.5.0 RC-7 Working Updated around 10am EDT
• OS: CEntOS 7

Client

• Service Version: 0.11.12
• OS: Windows 7

Description

I’m seeing the following in fog.log on Windows 7 PCs after deploying some snapins and several reboots:

This just seems to repeat over and again. The problem appeared only after the last update. I worked late into the night last night running identical task in FOG with no problems on Win7.

I’ve reset the Encryption for the PC from FOG Web UI and I’ve rebooted the machines, but I find no solution except re-imaging.

I have static Windows 7 PCs (one’s I haven’t been working with) that aren’t having this problem, and I’ve seen the problem on no Windows 10 PCs. But I haven’t been beating on Win10 pcs today.

Anyone have any ideas what to start looking at?

Thanks,

Jim

@tom-elliott

Tom,

Thanks for the explanation. I hadn’t thought of it that way. Makes sense.

Jim

@jim-graczyk

Tom,

One more similar observations - when you cancel snapins, they’re each assigned a duration equal to the time between the snapin request being submitted and the snapin being canceled. Again, since none of the snapins actually ran, one would expect to see a duration of 0 time for each.

Jim

Tom,

Thanks for the quick fix. Imaging is back working again.

Jim

Server

• FOG Version: 1.5.0 RC-7 Version 8 Updated 10 Mins ago
• OS: CentOS7

Description

Updated around 10 am today and since couldn’t deploy an image. Saw the RC7 notice and updated again, but the issue remains:

Jim

Tom,

I’m hoping that the start time, end time and duration for the execution of each snapin would be just that. I’m not concerned with seconds. If one is lucky enough to have PCs so fast 5 snapins start and end on the same second, whoohoo.

I’m tracking what PCs are taking what time to do what snapin. Sometimes we’ll see something odd and we’ll need to check out why this happened. The value is also the long-term record plus we have timeout limits to set for each snapin. So we’re looking for long time intervals for snapin installation.

I’ll check out the change you’ve made later tonight or tomorrow.

Thanks

Jim