@fogmania Well done!!

@joe-schmitt That fixed it. Thank you… Sometimes the most obvious gets overlooked.

James P…

But, back on your original post. You can either define the VL Key in the proper field for the host, or you can define it in the global key configuration in the fog configuration->AD (I believe). You can also use the FOG group set function to assign a key to a group of existing computers. This will update the key in the individual host management page.

As you can see there are a number of ways to go about doing what you need.

@xenorites That is indeed the best reference for the fog api. I would recommend, however, use the api sparingly as 1.6 will need new documentation. (This is because we’re moving to datatables, so most of the api is switched around to allow easier integration with datatables.)

@ally_uk You can do it with a single network card, just be aware there are a few more steps than standard.

As for your question about dhcp server, you must pick Y to install the proper proper programs. There will be a small risk of dhcp confusion while you are installing fog this way so as soon as FOG is installed unplug the fog server from the business network and plug it into your imaging network.

I started writing these instructions for centos 7, then I realized if you are not familiar with linux the instructions may be pretty daunting. Here is a different guide: https://wiki.fogproject.org/wiki/index.php?title=Installation As much as it pains me to say this, probably ubuntu or fedora would be a better choice if you are a gui based user. The link above is the basic installation jumping off point for a number of operating systems.

Once fog is installed and your fog server is in the imaging network. You will need to first change the fog server IP address to one consistent with the imaging address. For this example I’ll use 192.168.101.x/24. So for the fog server we will use 192.168.101.1 for the fog server.

Update the fog server IP address then reboot. Edit the FOG IP address in
/tftpboot/default.ipxe
/opt/fog/.fogsettings Edit the FOG IP server and subnet range in for the isc-dhcp server. The file will look similar to this one: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1 Now off to the FOG webgui. You need to update the IP address in 2 places in the FOG configuration page and then for the IP address in the storage node configuration.

I can tell you finding a second interface will save you quite a bit of pain, even a usb ethernet network adapter will work.

I think it is a BUG, I have to do it twice befor it is permanent saved.

Another Question:
Howto sort iPXE Menu Item Settings ?

0_1522673895600_32b8ec19-c0b9-44e8-822d-dd4214236248-grafik.png

@george1421 My reference image is NOT 1709 and once attached to the domain that update has been blocked by our WUS. Too many problems with it.

Just for clarity, FOG is not a backup system (1 for 1). It is an imaging solution ( 1 to many). It may not be the best use case for your goals.

I can suggest if you ARE looking for a backup solution look at Veeam Agent (free). With this software you can backup your computer to a NAS and create a disaster recover boot drive. If your computer fails, you can boot from the boot drive, connect to your NAS and then recover your computer.

What makes Veeam better than FOG, is how it backs up your disks. FOG does a whole disk clone, where Veeam does a file level backup. Meaning that you can recover any individual file from the backup, where with FOG you would have to restore the entire disk just to recover one file. Veeam is really worth a look.

Will FOG run on a Raspberry Pi 2 or 3, yes. I have a FOG-Pi server setup in my home for development work. For a single capture or deploy it works well in a home lab setup.

Hi ,

just to say that I deployed the same Image to a new SATA disk and the 3rd partition (Swap) had a fixed size as Expected.

So I guess that was a mistake on my side.

Problem solved !

@lof said in ..and one FOG-VM to rule them all.:

I changed the network configuration for my vm in VMware Workstation from Bridged over to NAT’d in order to test

Yeah that would be why. Broadcast messages do not traverse to different broadcast domains by default - because that would create network storms (yes, that’s a real technical term). You need the VM to be in bridged mode so it can hear DHCP requests.

You do not need to ‘burn things down’. Just switch it to bridged. The MakeFogMobile scripts will reconfigure everything for you when a new IP is received.

here is some one that pxe booted the pi or some thing like pxe
https://blog.mythic-beasts.com/2016/08/05/sneak-preview-from-mythic-labs-raspberry-pi-netboot/

@compman while that’s true, in practice zstd at a higher compression level will return a faster overall process when the bottleneck is the network.

Upgrade worked perfectly ! Great. thanks

@poizzon said in BIOS and UEFI boot, in VMware WinPE boot:

What would be the best place for a WinPE folder ?
I also noticed that after the upgrade, the WinPE directory is moved to the backup, and I always have to manually move back to it.

This might get you going here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/7

Finally got it to properly move the image thank you all for your help

I have config the mysql to log the queries and seems that some queries are fool.

180228 16:38:32 364 Connect root@localhost as anonymous on fog 364 Query USE `fog` 364 Query SET SESSION sql_mode='' 365 Connect root@localhost as anonymous on fog 365 Query USE `fog` 364 Quit 365 Query SET SESSION sql_mode='' 366 Connect root@localhost as anonymous on fog 366 Query USE `fog` 365 Quit 366 Query SET SESSION sql_mode='' 366 Query SELECT `vValue` FROM `fog`.`schemaVersion` 366 Query SELECT `pName` FROM `plugins` WHERE `plugins`.`pInstalled`='1' AND `plugins`.`pState`='1' ORDER BY LOWER(`plugins`.`pName`) ASC 366 Query SELECT `settingValue` FROM `globalSettings` WHERE `globalSettings`.`settingKey` IN ('FOG_DEFAULT_LOCALE','FOG_HOST_LOOKUP','FOG_MEMORY_LIMIT','FOG_REAUTH_ON_DELETE','FOG_REAUTH_ON_EXPORT','FOG_TZ_INFO','FOG_VIEW_DEFAULT_SCREEN') ORDER BY LOWER(`globalSettings`.`settingKey`) ASC 366 Query SELECT COUNT(`hosts`.`hostID`) AS `total` FROM `hosts` WHERE `hostPending` = '1' LIMIT 1 366 Query SELECT COUNT(`COLUMN_NAME`)AS`total`FROM`information_schema`.`COLUMNS`WHERE`TABLE_SCHEMA`='fog'AND`TABLE_NAME`='hostMAC'AND`COLUMN_NAME`='hmMAC' 366 Query SELECT COUNT(`hostMAC`.`hmID`) AS `total` FROM `hostMAC` WHERE `hmPending` = '1' LIMIT 1 366 Query SELECT `settingValue` FROM `globalSettings` WHERE `globalSettings`.`settingKey` IN ('FOG_URL_AVAILABLE_TIMEOUT','FOG_URL_BASE_CONNECT_TIMEOUT','FOG_URL_BASE_TIMEOUT') ORDER BY LOWER(`globalSettings`.`settingKey`) ASC 366 Query SELECT `globalSettings`.* FROM `globalSettings` WHERE `settingKey`='FOG_QUICKREG_PENDING_MAC_FILTER' 366 Query SELECT COUNT(`hostMAC`.`hmID`) AS `total` FROM `hostMAC` WHERE `hmMAC` IN ('40:b0:34:39:57:ac') AND `hmPending` IN ('0','') LIMIT 1 366 Query SELECT `hmMAC` FROM `hostMAC` WHERE `hostMAC`.`hmMAC` IN ('40:b0:34:39:57:ac') AND `hostMAC`.`hmPending` IN ('0','') ORDER BY `hostMAC`.`hmID` ASC 366 Query SELECT `hmMAC` FROM `hostMAC` WHERE `hostMAC`.`hmMAC` IN ('40:b0:34:39:57:ac') AND `hostMAC`.`hmIgnoreImaging`='1' ORDER BY `hostMAC`.`hmID` ASC 366 Query SELECT `hostMAC`.* FROM `hostMAC` WHERE `hmMAC`='40:b0:34:39:57:ac' 366 Query SELECT `hmHostID` FROM `hostMAC` WHERE `hostMAC`.`hmPending` IN ('0','') AND `hostMAC`.`hmMAC` IN ('40:b0:34:39:57:ac') ORDER BY `hostMAC`.`hmID` ASC 366 Query SELECT `hosts`.*,`hostMAC`.*,`images`.*,`os`.*,`imagePartitionTypes`.*,`imageTypes`.*,`hostScreenSettings`.*,`hostAutoLogOut`.*,`inventory`.* FROM `hosts` LEFT OUTER JOIN `hostMAC` ON `hostMAC`.`hmHostID`=`hosts`.`hostID` LEFT OUTER JOIN `images` ON `images`.`imageID`=`hosts`.`hostImage` LEFT OUTER JOIN `os` ON `os`.`osID`=`images`.`imageOSID` LEFT OUTER JOIN `imagePartitionTypes` ON `imagePartitionTypes`.`imagePartitionTypeID`=`images`.`imagePartitionTypeID` LEFT OUTER JOIN `imageTypes` ON `imageTypes`.`imageTypeID`=`images`.`imageTypeID` LEFT OUTER JOIN `hostScreenSettings` ON `hostScreenSettings`.`hssHostID`=`hosts`.`hostID` LEFT OUTER JOIN `hostAutoLogOut` ON `hostAutoLogOut`.`haloHostID`=`hosts`.`hostID` LEFT OUTER JOIN `inventory` ON `inventory`.`iHostID`=`hosts`.`hostID` WHERE `hostID`='7502' AND `hostMAC`.`hmPrimary` = '1' 366 Query SELECT COUNT(`hookEvents`.`heName`) AS `total` FROM `hookEvents` WHERE `hookEvents`.`heName`='QUEUED_STATES' AND `hookEvents`.`heName` <> '0' 366 Query SELECT COUNT(`hookEvents`.`heName`) AS `total` FROM `hookEvents` WHERE `hookEvents`.`heName`='PROGRESS_STATE' AND `hookEvents`.`heName` <> '0' 366 Query SELECT `taskID` FROM `tasks` LEFT OUTER JOIN `images` ON `images`.`imageID`=`tasks`.`taskImageID` LEFT OUTER JOIN `os` ON `os`.`osID`=`images`.`imageOSID` LEFT OUTER JOIN `imagePartitionTypes` ON `imagePartitionTypes`.`imagePartitionTypeID`=`images`.`imagePartitionTypeID` LEFT OUTER JOIN `imageTypes` ON `imageTypes`.`imageTypeID`=`images`.`imageTypeID` LEFT OUTER JOIN `hosts` ON `hosts`.`hostID`=`tasks`.`taskHostID` LEFT OUTER JOIN `hostMAC` ON `hostMAC`.`hmHostID`=`hosts`.`hostID` LEFT OUTER JOIN `hostScreenSettings` ON `hostScreenSettings`.`hssHostID`=`hosts`.`hostID` LEFT OUTER JOIN `hostAutoLogOut` ON `hostAutoLogOut`.`haloHostID`=`hosts`.`hostID` LEFT OUTER JOIN `inventory` ON `inventory`.`iHostID`=`hosts`.`hostID` LEFT OUTER JOIN `taskTypes` ON `taskTypes`.`ttID`=`tasks`.`taskTypeID` LEFT OUTER JOIN `taskStates` ON `taskStates`.`tsID`=`tasks`.`taskStateID` LEFT OUTER JOIN `nfsGroupMembers` ON `nfsGroupMembers`.`ngmID`=`tasks`.`taskNFSMemberID` LEFT OUTER JOIN `nfsGroups` ON `nfsGroups`.`ngID`=`nfsGroupMembers`.`ngmGroupID` WHERE `tasks`.`taskHostID`='7502' AND `tasks`.`taskStateID` IN ('0','1','2','3') AND `hostMAC`.`hmPrimary` = '1' ORDER BY LOWER(`tasks`.`taskName`) ASC 366 Query SELECT `hostMAC`.* FROM `hostMAC` WHERE `hmMAC`='40:b0:34:39:57:ac' 366 Quit

In one second queries

Hi George!

Thank you for your quick repsonse. I get what you are saying. I agree that I would prefere not to mess with the windows registry externally if there is another way to do things.
We don’t sysprep the systems, seems less hassle in our situation. But, the bread crumbs you mention can be picked up by any system I suppose, not just OOBE, but a snapin script for example…

But, which bread crumbs are your refering to? and how would you go about leaving that trail?

@junkhacker While we removed the settable feature from FOG, the database still relies on it I believe.

If anything there is still a hook that could be tied into to “authorize” against.

USER_TYPE_HOOK and USER_TYPE_VALID are the events to go against. This was part the reason why I went ahead with it, because there are ways around it anyway.

USER_TYPE_HOOK is typically used for just checking and changing the type, as in the case of LDAP users vs. normal fog gui users.

USER_TYPE_VALID is the simplest one with would allow you to hook against whether the user is valid for that particular are or not.

@wayne-workman

Thanks for the suggestions! I have tried adjusting settings and not sitting on the dashboard, but still our nodes are sending data to the master server and bringing everything else to a crawl. I setup a new storage node at another location and during storage replication it copied data over a 1Mbps as I had set. That is good, everything running as I expected. Once that is complete it starts acting like the others with random bursts which nearly brings some of the networks down. I tried adjusting sleep settings in FOG Configuration but that made no difference. It’s sending the same amount of data back to the main server as the others were, I’m just not sure what. In the last 2 hours it has sent 3.3GB to the master node with no one logged in to the web GUI or even in the office.

This would be OK every few hours, but I am not sure what other settings to change or services to schedule.

0_1519395373497_Error_LIB.PNG