@Tom-Elliott Ok, we fixed it… we looked at the pcap dump here and found it was one of my colleagues and his sonicwall pulling a sarah palin and went rogue. Issue resolved.

Again my hats off to you guys and the community thank you so much!

@Pascal-Gazaille Is this with an external DHCP server? Just for the fun of it, would you want to try UEFI as well? Change from legacy BIOS to UEFI on your DELL Latitude and from undionly.kpxe to ipxe.efi on the DHCP server…

More and more UEFI is coming and it’s good for us to know how well we handle this already.

@Tom-Elliott

Cheers Tom it worked!

With any luck, I hope to have found a potential partial cause of the load. Again, this only appears to happen on Ubuntu based systems, but why I couldn’t tell you.

By moving the servicemodule-active.php file I can limit the load, but I think it’s not a suitable test because it essentially keeps the FOG Clients from doing anything related to the work the modules are expected to do.

This seems, to me, to be two part. First the servicemodule-active was calling at least 12 separate calls to the database per system. I’ve now limited this to a single call to the database to return all the values. The second part that I have no good way to test is the php versioning.

While most are running 5.6.20 (or very close to it), the values should be operating in normal ranges. However, the output of Fedora 23 system running PHP 7 (sorry I don’t feel like downgrading to php 5 for now).

PHP 7.0.5 (cli) (built: Mar 30 2016 09:13:39) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

The output of PHP 7 on Ubuntu 15.10

PHP 7.0.5-2+deb.sury.org~wily+1 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Notice the “extra line” of “With Zend OPcache v7.0.6-dev, Copyright” stuff.

I don’t know if that’s actually supposed to do that. Meaning, I believe the Zend OPcache value should match the php version as php is written by Zend (or so I thought). In either case, it’s intriguing to say the least.

Thank you for your feedback. This is all good information for the Devs. I noticed you didn’t mention the version of FOG you installed. Did you install 1.2.0 stable, or a trunk build of 1.2.0 (i.e. 1.3.0 beta). I see that you stated you installed the dev branch (which is not a term we used). Could you reply with the numbers that are listed on the cloud from the management interface gui?

I can’t speak to issue 1 of yours.

As for 2, I’ve experienced this my self where the second time you run the script the OS password for the fog user gets updated but the information stored in the database is not, creating an inconsistent (i.e. broken) install.

For 3, I wrote a kb article [ https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition ] on how to create a similar setup as you have. The issue I see is that the /images and /opt/fog/snapins folder could potentially grow out of control unless you are managing the disk space properly.

Thank you for taking the time to give the dev members great feedback and for taking the time to work with and use FOG. Its a great solution.

Thanks @george1421 and @Sebastian-Roth for your help. For now I did what Sebastain mentioned and moved the images and that worked. George, when I get more time I will review your documentation and see if that is something that I would want to do in the future.

Once again thanks!

Updating seemed to fix the issue.

@Wayne-Workman said:

I really doubt it’s the unmanaged switches fault, and I’m willing to lay 99% odds it’s a cable.

While I totally agree on what you said and fully trust in your network knowledge (I mean that!) this is not a cable issue from my point of view - not this time at least:
http://www.viktorious.nl/2013/11/05/cisco-sg200-08-nfs/
https://supportforums.cisco.com/discussion/11755791/sg200-08-firmware-issue

Other than that I found this as well: http://serverfault.com/questions/367107/cant-mount-nfs-share-over-tcp

Turns out there was a “security” feature enabled on our PowerConnect switch that took offense to NFS SYN packets with source ports < 1024 (dos-control tcpflag). Suffice it to say, disabling the feature solved the issue.

Reading this again I think this is actually the case here. Why? Because I made Miguel try telnet <fog-server-ip> 56557 (the actual NFS data port) and it worked - as telnet is not using a high source port I suppose.

@Sebastian
My HERO !!! 🙂

Tanks a lot it works

@admin
You can solve this post

@FlowLive I guess the only question I am seeing is that you are asking how to determine if the machine is a laptop or desktop. The easiest way to accomplish this is to use a script as the snap in that will check if it is a laptop and if so run the installer from a share some where. If it is a desktop then no installer is run.

Natively there is no way to have FOG determine if the machine is a laptop. But if you know what machines are laptops as you add them, you can have machines belong to multiple groups, add all laptops to a Laptop group and apply only those 3 snapins with no other setting in that particular group. Not automatic, but does work.

I quite often use scripts instead of actual files for snap ins, mostly due to old limitations of snapins back in the .32 days, so I guess it is just an old habit.

@wdmartin said:

It may not like having been put on a VirtualBox when it was originally built against an Optiplex 990.

For sure! Windows is very picky when it comes to IDE controller drivers… Not easy to get a system from bare metal to VM if you don’t adjust the drivers before capturing the image!

I got the 58 GB figure from the FOG imaging screen while it was building the second partition.

Ok, this meants the data within your second partition is 58 GB (28 GB compressed!) but does not tell you anything about the source partition/disk. It’s not an issue to put 58 GB to a 200 GB disk but a problem if the original file system used to reside on a larger disk - no matter how much free space there is!

@Ignacio Sí, trato de traducir. Explicar su problema, por favor.

@FlowLive So far the persistent groups as I laid out in the kb and link previously is working in my environment. A formal solution (authored by the devs) would be better. But if there is no plan to support persistent groups in fog 1.3 (as of today) then this solution should work for you too. You will just need to create your host consistent templates and then setup your host groups as outlined in the KB.

The issue, for others who may stumble across.

If you’re getting Private key not found but all the data seems to point that you do have a Private key file. Make sure the node (ip address or whatever) is actually a node within the system.

In @raumin’s case fog-server was not the node he was working with. The node he had defined was a NAS. NAS’s suck (plain and short) but have their own uses. (No offense to anybody using one, just they’re a bit of a pain to play with to get working with fog).

So the clients were looking at the thing @raumin is using as the GUI access point for private key. This was not a defined node (and I will try to come up with a better approach).

The fix, for now, is to always have a node for the GUI as well. You do not need to have the node enabled for things to work, and I would highly recommend against using in such a setup (NAS->Central GUI) trying to make the GUI node a “master” of the group it’s working with, unless you want it setup in such a way.

For our fix. We created a definition for the node and gave it the proper ip address. All started working immediately.

Hi Gents,

I am no expert, but hopefully my input can help a little.

First, quick MACLookUp on the MAC in the screenshot 080027 cadmus computer systems, looking for cadmus computer systems, VirtualBox came up. so that’s that. https://www.virtualbox.org/pipermail/vbox-dev/2011-August/010036.html

Just this past week i had an issue with our POS system that runs over PXE (Nothing to do with FOG).

Scenario

EXSi 5.5 Upt 2 host running Windows 7 guest and inside the guest VirtualBox. Inside VirtualBox a Virtual machine running our POS system (Point of Sale jst fyi 🙂 ) that is called via PXE.

The PXE call would time out, which i think is the problem you are having.

The way i was able to make it work was by ENABLING – PROMISCUOUS MODE – in the EXSi Host.

In Virtual box not sure how to enable, but a quick search tells me that all you have to do is change the NIC you are using the FOG with to Bridged Adapter instead of Internal Network which is most likely what you are using.
https://www.virtualbox.org/manual/ch06.html

Just to try change your FOG server network adapter to Bridged Adapter (Literally will simulate you physical NIC ) to see what happens, it wont hurt !!!

Again way far from expert, but in my case using fog, since this beautiful software uses PXE and DHCP among a lot more things. I though to myself, just to be on the safe side i will keep my FOG server completely isolated from my actual network, because in my case i just use it to clone computers and more important i already have a DHCP and PXE service already running … that would be a call for problems to put my fog server on the same network !!!

Hope this helps a little, if not well i shared something !!!

Cheers mate !!!

@andyroo54 You can edit it from the GUI on the “User Management” tab. There is no link between fog user on GUI and fog unix user.

@Wayne-Workman Yeah it’s not a big deal. It was just a nice feature of .32

Like I said it’s a small price to pay to upgrade.

It only shows we need a lot more testing. I plan on hopping onto the Ubuntu/Debian wagon soon to bang out some tutorials and videos, but I’m busy getting a fog-dhcp plugin / service / interface put together.

@Sebastian-Roth Yes Sebastian, I meant to write yesterday, fog is booting no probs now with the new trunk version. I am getting corruption of the image but that might be the OEM image I’m trying to upload. I’m going to try a win 10 soe today.