Best posts made by george1421

@lebrun78 OK I just had a chat with the developers over this.

zstd is used for decompression of both legacy and new images (as of FOG 1.3.5). You have the option of using industry standard gzip for image compression or the new zstd for image compression. If the industry standard gzip compression is used, you “could use” any zip program to extract the image from the FOG archive (not very common and only done for a very specific reason).

The newer zstd format can achieve better data throughput (target hard drive compression and decompression) than by using the gzip format. They (the developers) switched to zstd based on a feature request to make FOG imaging even faster (the FOG Project is all about going faster) and with a tighter packed image on the FOG server (smaller disk space used on the FOG server’s hard drive).

The real decision not really a decision. Use zstd and live with the faster deployment speeds, or use gzip and deploy as the same zippy speeds the previous versions of FOG 1.3.x supported.

Really its not a decision use zstd and worry about other things in the world.

@ecicerkofski Then my recommendation is to update to 1.3.0-rc8. Its the same process as you used to install/upgrade the trunk version. 7645 should work, but it is a thousand or so commits behind current.

The second part (once you get updated) is to follow jhuesser guidance.

Yes there is: https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog

You will use the FOG postinstall scripts to send the drivers to the target computer.

In my tutorial for installing dnsmasq on Centos this is what I have for the dhcp-boot line:

dhcp-boot=undionly.kpxe,,<fog_server_IP>

Also you need to ensure that you are running dnsmasq 2.76 with has reportedly added the required code for pxe-uefi booting alongside legacy (bios) code.

I have not tried this with dd-wrt either but this extension should work with dnsmasq

dhcp-match=set:efi-x86_64,option:client-arch,7
dhcp-boot=tag:efi-x86_64,ipxe.efi

which sets up a flag if the client matches arch 7 (x86_64 uefi) and then sends ipxe.efi instead of undionly.kpxe. You may need additional arch added for IA32 uefi systems too. Wayne has added the info to the FOG wiki page https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#General
Look at the top for the isc dhcp server to an idea of what is going on.

@Tom-Elliott said in Imaging computers at 1.5Gbps:

I just have to say,

HOLY SHIT!

Ditto…

Of course me being a bit OCD, I have to know was this transfer rate done with FOG standard compression or the new (as of 1.3.4) zstd file compression? To get the best speeds from the zstd compression you need to capture and deploy using the zstd drivers. If this was done with the legacy data compressor, what was your compression index number?

The reason why I asked the 20 questions is that what you have is might impressive. If others want to duplicate your test, it would be good to know the conditions.

@scouseboy99 Just to be clear here, you built two complete FOG servers and then assigned one as a master node and one as a slave node? If this is the case you have a non-standard setup. There are valid reasons for setting up this configuration and it does work well with one caveat.

The typical setup would be to setup the remote server as a FOG storage node from the installer. A fog storage node is a full fog server but without a local database. In this configuration the storage node uses the database from the master node so its aware of all images that is replicated to itself.

In your setup you have two independant FOG databases. The replicator will still copy the images from the master node to the remote fog node just like with a remote storage node. The problem comes is that there is no (current) way for the master fog server to update the database on the remote fog server. There is a way to manage this. You can export the image definitions from the master FOG server and then manually import them into the remote fog server to synchronize the image definitions in the remote database. It sounds a bit complicated, but its not. You just have to remember if you add a new image to the master node, the image WILL be replicated to the remote fog server, you just need to manually add/import the image definition into the remote fog server’s database.

@avicitiffany You have the wrong tool. The FOG Project is used for copying windows images to computers. I has nothing to do with graphic arts.

First of all Welcome to the FOG Forums.

Second, the new version of FOG (1.3.x) make it much easier to manage the FOG iPXE menu. This is now done through the FOG Configuration part. There is a section for iPXE menu management.

As for the iso images there are many success stories of how to implement this. I wrote a tutorial on how to pxe boot into a Windows MDT ISO image. The concept is similar to what you want. https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

Here is also the FOG Wiki page that discusses this topic: https://wiki.fogproject.org/wiki/index.php?title=Include_any_ISO_in_the_FOG_Bootmenu

There are many other examples of how to specifically boot other iso and utilities with FOG in the forum. Can you tell us exactly what you are trying to boot via an iso image?

@fry_p The issue is really NFS v3 (period). NFS v3 is not a secure protocol at all.

The FOS engine uses nfs to capture and deploy images to the target computers.

The /images directory is read only. The /images/dev is read write.

Images currently being captured are written to /images/dev/<mac_address>

Once the capture is done, the FOS engine connects to FOG via FTP and moves the files from /images/dev/<mac_address> to /images/image name. Its a bit of ingenious code that does this since a linux move is just a rename of the directory path so there is no copying about of multi-gigibyte files once the upload is over.

With current NFS v3 the only option you have is that you can restrict who can mount the nfs share to a certain IP range. But anyone in that range can mount the share (using unix) without restriction.

So now you have to ask yourself what are the risks to having this share open to world read/write on /images/dev and world read on /images? Are you storing any PII or GDPR regulated data on those shares? What are your true risks here.

The better answer would be for FOG to support NFSv4 with kerberos authentication. That’s possible but not currently implemented in FOG. That setup also puts a bit more burden on the FOG server OS to have kerberos setup.

I have also thought about NFS via a SSH (TLS) tunnel. But that based on research seems to cause a serious performance impact of image throughput. I also thought about imaging over openvpn, but that would require FOS to support an openvpn client. This openvpn route does open some interesting possibilities, but from a performance standpoint I think NFSv4 is probably the right answer.

@justeverything There is an option for that to change from the view mode to list mode.

FOG Configuration->FOG Settings->FOG View Settings change FOG_VIEW_DEFAULT_SCREEN to List

@Junkhacker said in [Seeking Volunteers] Bench Testing! Our trip to the best results!:

oh, also, i disagree with george about how fast an “ideal setup” can be with a single GbE network and one unicast:

Boy, who made Mr. Hacker grumpy today?

While we all know this already, but the number show in Partclone (GB/m) is actually a composite score of network transfer rate, decompression rate, and the speed to write the image onto the storage media.

In a typical 1GbE network if someone said they were getting between 6.0 and 6.7GB/m deploy rate, based on my experience I would say that’s normal.

If we just look at the numbers, a 1GbE network has a theoretical maximum throughput of 125MB/s. In practice I see 110 to 120MB/s. So lets use 120MB/s x 60 seconds = 7.2GB/m. So a 1GbE link can only transmit a maximum of 7.2GB/m. So in theory its not possible to get a deployment rate faster than 7.2GB/m. Your video showed 10GB/m, how is that possible? That is because the partclone number is a composite number which also includes image expansion and writing to the storage media. If you have a fast target computer with a fast disk, the target computer can take that 7.2GB/m data stream, expand it and write it to disk just as fast as the data can get to the target computer.

Welcome to FOG and the FOG Forums.

first lets get the easy part out of the way. Depending on how the firmware is configured legacy, or uefi that decides which iPXE FOG menu program you set for dhcp option 67 {boot-file}. For legacy/bios mode you send the undionly.kpxe file name, and for uefi mode you send ipxe.efi. If you send the wrong iPXE kernel the menu won’t load correctly. Setting up window 2012 dhcp server for uefi/bios coexistence (i.e. sending the right boot file name based on the pxe booting computer): https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

As for uefi/legacy. What image format you capture uefi/bios you must deploy to the same. If you capture a uefi image you must deploy it to a uefi computer. You can’t mix and match.

Wayne also touched on the fog client. If you are syspreping the image you must install the fog client and set the service to disabled. We need to do this so the fog client doesn’t start up too soon in the OOBE process. We use the setupcompleted.cmd file to re-enable and start the service. The setupcomplete.cmd batch file is called at the end of OOBE. If the FOG service starts too early in the OOBE process you will get an error like windows unexpectedly restarted or another one I can’t remember the exact syntax. But you will get a botched install. Guidance on FOG Client and sysprep: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

As for win10, when you sysprep it, instruct sysprep to shutdown the computer when its done. Then pxe boot and capture with fog. If you just shutdown win10, the computer isn’t really powered off, but in an enhanced sleep state, which will break your deployment (or the capture will fail because of a dirty disk [i.e. the disk wasn’t closed properly before capture]).

Exit mode only impacts booting through the fog ipxe menu. On my campus I don’t booth through the FOG iPXE menu, but instead when we image we must press F12 and select pxe boot. This is done to avoid an accidental image of a system if the wrong one was selected in the FOG management GUI. The point is you don’t need to boot through the iPXE menu if you don’t want/need unattended imaging.

As for building your reference image on physical hardware. Typically you will create your reference image on a VM to avoid any hardware specific drivers being baked into your reference image. Then during image deployment (with FOG) you can inject the correct drivers into your image. Inject is not the proper term, its more like placing the files onto the target computer in a place where windows OOBE will find them and install them.

@luiztpd No the project is not closed. The developers are not as aggressively sending out updates with new releases. Right now the project is in a maintenance mode. The developers are working on the 1.5.10 release that will be out in early spring 2022.

The dev-branch is where the release candidate for 1.5.10 currently lives its something line 1.5.9.114 or later. The kernels are up to date with the latest hardware. The only thing we are seeing that “needs” to be updated right now is iPXE to support the latest hardware, but we have a tutorial on how to update that for the FOG Admins to use.

@darkrelic The error says your os distribution no longer has php5 available. It also appears from the log your version of kubuntu is based on ubuntu 16.04.

There is a wiki page for installing fog on ubuntu 16.04: https://wiki.fogproject.org/wiki/index.php?title=Ubuntu_16.04

I think your key is to run the installer with this command line: php_ver='7.0' php_verAdds='-7.0' ./installfog.sh -y

Great job Devs. Its been a long road to get here, with a bucket full of new features over 1.2.0.

Well done!

If you follow these instructions and capture a pcap of the pxe booting process we can tell what is going down the wire. For this test your dhcp server, fog server, and pxe booting client should be on the same subnet so that we can see the entire pxe booting conversation. Capture the pcap and post to a google drive or dropbox. Either post the link here or send me an IM and I will take a look at it and tell you what is going on.

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@Junkhacker This is exactly what I was thinking when I had to pause earlier.

At the top you will have a major test for hardware inclusuion in this group

iseq ${serial} <labSerial1> &&  goto chainboot ||
iseq ${serial} <labSerial2> &&  goto chainboot ||
...
iseq ${serial} <labSerial64> &&  goto chainboot ||

If there isn’t a match then the original (old default) menu is selected.

goto fog.local

If there is a match then the flow jumps down to the label

:chainboot

Sets the next server (dhcp option 66) and boot filename (dhcp option 67) to the new values required for OpenSLX and then chain boots (fwiw that should be on one line, its a bit deceiving because of the line wrap, that is all one line) into the new environment.

@Junkhacker Simply Brillant!!

@jhalbert If this is a windows 10 box, there is a feature somewhere in the config settings where the it will generate a random mac address for its network adapters. This is a nasty and not very usefulness feature for fog. @x23piracy Did you have this with a system at your site?

Just a couple of thoughts of the top of my head.

1. For the root password in the db. By default pick a random password and then give the user the option to change it, akin to how the fog installer picks the network adapter, but then lets the user change it. The fog installer should warn the user to write this password down someplace because its important and would be needed for database repair.
2. The fogdb user’s password should be managed like the fogproject linux user’s password. Its owned and set by the fog installer, but is recorded in the .fogsettings file. If the fogdb user’s owns the fog db, then there really is never a reason to use the db’s root user any more.
3. For the db’s root user password resets, I don’t think we need to reinvent the wheel here. Maybe provide a wiki with examples for the big three centos, debian, and ubuntu (current minus 2 releases if there is any changes) and then say for other distros they will need to google the answer. Lets not kill our selves trying to be all things to everyone. If the fog admin has deviated from the recommended distros then they should have enough skills to reset the root password. Its not that complicated.

I agree with Sebastian, shut the FOG server down and see if this behavior still exists. I know these win10 machines will turn them selves on at random times to do system “stuff” then power off. It is a bit unnerving when that happens.

Thinking about it a bit more you can probably capture if its the fog server doing this by installing tcpdump onto your fog server then launching it with the following command.
sudo tcpdump ether proto 0x0842 or udp port 9
You should see no output from the above command, unless there are wol packets floating about.

or to dump it into a pcap file for later review. You may have to run the command for 24 hrs to see when and what is generating wol commands.
sudo tcpdump -w wol.pcap ether proto 0x0842 or udp port 9

Since WOL is ethernet based and not IP based you should see the mac address of the device sending the magic packets.