@Tanguy Lets first identify that the database engine is at fault here. Lets just do the first step in the tutorial.
SELECT TABLE_NAME,ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'fog' and ENGINE = 'MyISAM';
If the query responds with MyISAM then this is the problem. If it responds with INNODB, then lets discuss.
If its the data engine, you can make this change while the system is up and running, no need to schedule downtime.
@Tanguy OK here is what I’m thinking. We had a performance issue a while ago with earlier releases of FOG, where the default sql server data engine was being used instead of a higher performance version.
The conditions were > 300 computers with the fog client installed. When you looked at top and sorted by P cpu there would be many php-fpm services running as well as high CPU usage on mariadb. This is because the default ISAM db engine uses table style locking on an update, where INNODB uses row level locking. Switching over to INNODB resolved this issue. I don’t remember which version of FOG is when the Devs switched over to using innodb by default. I did write a tutorial on how to update your db design that you might want to use to see if you are still using the ISAM engine or the INNODB database engine. If you are using the INNODB engine, then we will need to debug this issue since its something different than what we’ve seen before.
https://forums.fogproject.org/topic/16099/configure-fog-database-to-use-innodb-engine?_=1698321484681
@Tanguy How many client computers do you have in your environment that have the fog client installed on them?
@zaboxmaster Another opiton might be to access the windows registry to read out the version. Within the FOG OS (FOS) linux there is the linux reged program. That can be used to read/edit the windows registry.
Below is an example from one of my tutorials on post install scripts to update a registry key. That is only meant to show you what is needed to make the program work.
egfile=“/ntfs/Windows/System32/config/SOFTWARE”
key=“\Microsoft\Windows\CurrentVersion\DevicePath”
devpath=“%SystemRoot%\DRV;%SystemRoot%\inf;”;
reged -e “$regfile” &>/dev/null <<EOFREG
ed $key
The question is how would I go about doing this if at all possible?
Where would the best place be to run it from? FOG.MAN.REG ???
Is the Windows mounted at all during registration?
Is it possible, yes
Best place, yes probably a customized version of fog.man.reg (I have a tutorial on how to slide an updated version of that into FOS Linux at deploy time). To make the inventory also query the target OS.
No windows os partition is not mounted during inventory. For FOG inventory its not needed. BUT I have a tutorial on how to find and mount the partition during a post install script for driver injection that you can use as the basis for the inventory process.
I want to transfer the “Gold” Images from the server in the other site. Can I just copy and paste the Images Folder from from the other Linux Machine?
The short answer is yes, but there is something you need to know.
FOG Images are made up of two components. The first is the raw data files that are kept in /images directory on your fog server. The second part is the metadata kept in the database. You need both to make the image functional. You can copy the files over by hand, but you will need to either recreate the metadata on the target system by hand (not a difficult task) or export the the image definitions from the source computer and import them on the destination computer
Now one other tidbit that is not supported by the developers, but it works. If on your master server you add the remote fog server as a storage node. The main fog server will be a master node and the remote server is a storage node (just in the context of this configuration), the master node will copy any image marked as exportable all storage nodes in its storage group. This will get the raw images over to the target system using the standard fog image replication. But the thing it doesn’t do is copy over the image definitions. You will need to do this using the export and import method, or by manually creating the image definitions by hand. Using this method you can have golden images pushed out by HQ and each site will still be able to create their own golden images too.
@boros Ok there are two things here.
On installing fog there are 3 phases. 1. Start the FOG installer from the linux CLI and answer the preinstall questions. 2. GO to the Web UI and execute the action there to create/update the database. 3. Return back to the fog server console CLI and complete the installation. If you miss/skip part 3 you won’t have the required services installed. The /tftpboot directory will be blank. There won’t be any FOS linux os (bzImage and init.xz) in /var/www/html/fog/service/ipxe directory. The quick fix for this is to simply rerun the installer and completing all three steps.
The second one you have to remember is that WDS uses a netboot service, which is akin to proxydhcp. ProxyDHCP overrides the dhcp settings provided by the dhcp server for netbooting (options 66 and 67). A quick check is to have a witness computer on the same subnet as the pxe booting computer. Run wireshark on that witness computer using the capture filter of port 67 or port 68 or use display filter of bootp. Look to see if you are getting multiple OFFER packets. If only one look into the one OFFER packet to see if dhcp option 60 is present. That signals a proxydhcp packet. If it exists that tells the client to contact the dhcp server after the dhcp exchange for pxe boot information on port 4011.
@Eliza In the FOG web user interface. In the FOG menu FOG Configuration and then along the left menu Select Kernel update.
@Eliza OK on tuesday I want you to update the FOS linux kernel. Its under Fog Configuration -> Kernel Update. My guess is that you have an older version of the linux kernel. The latest version of the FOS linux kernel is 6.2, If you have version 4.19 or 5.5 it might be to old for your new hardware.
@Eliza Can you post a picture of the error message when you try to upload your image? I don’t understand why 10th generation cpu causes a problem.
I need to ask what version of FOG and what version of the FOS Linux kernel are you using?
@introloud said in Configure FOG Server's DHCP service?:
I’m gonna try both unicast and multicast to a couple of machines first but I doubt that it’d be any different since it’s on a simple network right now.
This is simple and complex to explain. But a unicast image is sending an image form the fog server to a single target computer. Lets say for example that take 50MB/s of network bandwidth. If you start up a second unicast deployment to a second target computer that will take another 50MB/s of network bandwidth. Now lets add a third simultaneous unicast deployment, Now you are sitting at 150MB/s of network bandwidth usage and 1GbE only has 125MB of available bandwidth, so you will get collisions and throughput slowdowns.
Now lets say you setup a multicast session with those 3 same computers. The image is now being sent out as a multicast. You can have as many receivers as you want, because only one image is being sent out you only consume 50MB/s of network bandwidth. If a receiver is late to the stream, they simply miss the stream and will not be imaged during that streaming session. Using a multicast streaming method you can image 30 computers in about the time it take to image 2 computers using unicasting.
They will be in the same VLAN but probably may have different subnet masks
Strictly speaking you would normally have only one subnet mask per VLAN unless you are doing supernetting for some reason.
imaging task to multiple machines, and have them reboot to get into network boot
Typically you would configure the computers to boot through PXE then boot to the hard drive. That way if FOG had any actions for the computer it could do it while the fog menu is displayed. If there were no jobs then it would just boot the hard drive. You would have the FOG client installed on the target computer so when the schedule task starts the target computer would be instructed to reboot via the fog client program.
@FoxNBeard said in General A to Z support (FOG):
It would install with the Administrator account activated. Through the unattend.xml I was able to figure out how to have it make a second user with administrator priviledges, but I couldn’t seem to solve how to not have the administrator account active and only the user.
Use the setupcomplete.cmd batch file to do this. With something like this in batch
REM Rename the default administrator account to something else
wmic useraccount where name='administrator' rename slipperyjim
net localgroup administrators slipperyjim /add
REM Rename the guest user account
wmic useraccount where name='guest' rename debbiedowner
REM Create a fake administrator account for hackers to bang on
net user Administrator NeG@tiveNancy-F@nT@#13s /ADD /comment:"Built-in account for administering the computer/domain" /PASSWORDCHG:NO /active:NO /Y
REM Be sure to remove from administrators and users groups, add to guest group to limit access
net localgroup Administrators Administrator /delete
net localgroup Guests Administrator /add
net localgroup Users Administrator /delete
REM create new System Admin user
net user sysstarr "1cecr3am-SanWitch0" /add /EXPIRES:NEVER /PASSWORDCHG:NO /active:YES /Y
net localgroup Administrators sysacce55 /add
wmic useraccount where Name='sysacce55' set PasswordExpires=FALSE
REM Disable slipperyjim (real admin/root user account)
net user slipperyjim /active:no
I presume due to limited knowledge, I couldn’t figure out how to let MDT install both updates and applications correctly.
There is a task sequence to apply windows updates. It helps if you have a local WSUS server to cache the packages. When I was just getting started in imaging this site helped out quite a bit. https://www.deploymentresearch.com/
I was wondering if I was able to manually configure a VM and pull an image to FOG that way?
Yes developing your golden image on a VM is the best choice so you can use snapshots to fix o-crap moments while perfecting your golden image.
Hostname was identical to the original machine (Although I think, unless wrongly configured, the hostname changer in FOG was active).
This is true because fog is a block level cloner, it knows nothing about the target system. To use the hostname changer will you will to register the computer with FOG and have the FOG client installed. That is not something you probably want as a system builder. You can have FOG set a name of the computer at deploy time via using a custom FOG post install script that will inject a new host name into the unattend.xml file at deployment time.
Yes I would still sysprep your windows system. For full disclosure I have not had to build an image for Windows 11 yet, so I might be incorrect here. BUT I would also build your golden image so that its protected from getting to the internet. I have seen on windows 10 if the workstation can get to the internet it will try to down stuff causing sysprep to fail.
I would spend my time getting MDT to do what you want it to do to give you the perfect golden image. The capture and deploy with FOG is the easy part (kind of). If you want to do more of the advanced stuff like editing the unattend.xml file on the fly it will take some time but I have examples for that.
@FoxNBeard Quite a few MSPs and system builders use fog for image deployment. So its possible to do, but it WILL take WORK on your side to setup the environment to get an efficient work flow. Once you have everything setup correctly you can go from bare metal to first user login in about 12 minutes. With a 25GB golden image push in about 4.5 minutes, the reset of the time is windows, being windows…
I would first start with a golden image, load all of your common apps into the golden image except Enterprise AV or any app that utillize a unique ID for each device. These apps need to be installed post deployment. You may need one of these golden images per customer if they have different core application mixes. The goal here is to be able to take a bare metal computer to a finished image as quick as possible for a system builder. So spend a little more time on the front end setting up your environment and reclaim the benefits on the back end.
I would suggest that you use Microsoft’s MDT for golden image creation. MDT will take about 1hr to create your golden image because it builds the golden image from the master DVD image, much like you would do by hand, but in an automated manner. Using MDT you will be able to customize your golden image builds on a per customer basis. I know this sounds counter intuitive, but use MDT to build a predictable and repeatable golden image. MDT will install all of the latest windows update if needed for you. Then you will only be out of date from the last time you created the golden image. Capture the golden image with FOG and then use FOG for the one to many deployments. Develop your golden image in a virtual machine environment to make the golden image hardware neutral. If you need hardware specific drivers, fog can place them on the target computer so that Windows OOBE/WinSetup can find and install them.
FOG uses block level cloning, which is super fast but not deploy time flexible. MDT uses file level cloning, which is deploy time flexible but slow. Each tool has its best use case and they fit together well.
In your golden image use an unattend.xml file to configure the workstation, like creating user accounts, tweaking the windows environment, or installing apps. This is all windows os tuning and standard windows deployment, not related to FOG.
Now back to fog, you have the golden image captured and stored in FOG. Normally you need to register each computer you want to image with FOG so you can deploy an image to it. But in your case once you load the target OS on the computer FOG will never see that computer again, so registering and deploying with FOG just adds extra steps. There is a process I use called “Load and Go”. This is where you pxe boot a target computer and pick “Deploy image” from the FOG iPXE menu. You would then select the image and then FOG will deploy to that system without requiring it to be registered. Once the image has been deployed then FOG forgets all about the target system. There are some caveats here like post install activities like deploying snapins (apps) and a few other FOG maintenance functions which you won’t use in your case. So make the golden image fully self contained. FOG will only push the image to the target computer quickly then forget about the computer using the Load and Go method.
So how might you deploy post install apps, use the setupcomplete.cmd or in the unattend.xml file under the auto login / first run section to call Chocolatey to do its thing to the computer.
@errbravosix Would you provide a complete ltsp.conf file because what you provided here shouldn’t have fixed the problem directly,
BUT from the original config, if you would have modified it to this for the pxe-service section:
pxe-service=X86PC,"Boot to FOG (BIOS)",undionly.kpxe,172.16.1.15
pxe-service=X86-64_EFI,"Boot to FOG (EFI)",ipxe.efi,172.16.1.15
pxe-service=BC_EFI,"Boot to FOG (EFI)",ipxe.efi,172.16.1.15
Then that config should have worked. dnsmasq is a bit cryptic with its optional parameters I do have to say.
BUT I can say if you have it working then its working so no need to change anything. Good job finding the solution.
@introloud said in Configure FOG Server's DHCP service?:
I can now edit the /etc/dhcp/dhcpd.conf file to create the configuration files right?
If you picked enable the dhcp server during the fog install it “should” automatically create that file with the proper settings. Make sure when you install fog you start the installer with the linux console, go to the web ui when instructed, then return to the linux console to finish the last part of the setup (which is the spot where the configuration files are created and the /tftpboot directory is populated. If you don’t do that last part your system will not be installed correctly. You can just restart the fog installer and install it again to fix the missing bits.
If I’m understanding correctly, dnsmasq would only supply pxe boot information, leaving the ip assignments to the main dhcp
Yes that is correct, If you use the proper dnsmasq configuration it will put dnsmasq in proxydhcp mode where only the pxe boot information will be supplied to the target computer. https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server If you type slow it takes about 10 minutes to install dnsmasq on your fog server.
@errbravosix The more research I do the more I’m thinking that your config file should just work.
I did put together an alternate configuration for dnsmasq. As long as the dnsmasq server is running on the fog server this config should also justwork.
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# inspect the vendor class string and match the text to set the tag
dhcp-match=set:efi-x86_64,option:client-arch,7
dhcp-match=set:efi-x86_64,option:client-arch,9
dhcp-match=set:efi-x86,option:client-arch,6
dhcp-match=set:bios,option:client-arch,0
# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=tag:efi-x86_64,ipxe.efi
dhcp-boot=tag:efi-x86,i386-efi/ipxe.efi
dhcp-boot=tag:bios,undionly.kpxe
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Buscando Servidor de Imagens", 5
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC,"Boot to FOG (BIOS)",undionly.kpxe
pxe-service=X86-64_EFI,"Boot to FOG (EFI)",ipxe.efi
pxe-service=BC_EFI,"Boot to FOG (EFI)",ipxe.efi
dhcp-range=172.16.1.50,172.16.1.52,255.255.255.0
@introloud When you install FOG it does prompt you if you want to install the dhcp server. You can also do it after the fact. Just install the isc-dhcp server from your linux server’s distro repo. Then refer to this configuration file. Fog would use this template to create the configuration file. Make sure you update the ip addresses specific to your network. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1
Also be aware that you can run dnsmasq to supply the pxe boot only information and still keep your main dhcp server untouched. So if you wanted to connect your fog server to your business network that is also possible.
@errbravosix said in FOG server Withou dhcp services:
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,172.16.1.15
dhcp-boot=net:UEFI,ipxe.efi,172.16.1.15
dhcp-boot=net:UEFI64,ipxe.efi,172.16.1.15
In your LTSP.conf Update this section to:
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,172.16.1.15,172.16.1.15
dhcp-boot=net:UEFI,ipxe.efi,172.16.1.15,172.16.1.15
dhcp-boot=net:UEFI64,ipxe.efi,172.16.1.15,172.16.1.15
Lets see if that gives you a successful pxe boot.
@errbravosix said in FOG server Withou dhcp services:
enable the true dhcp on my pfsense, everthing works fine
This is because pfsense is filling out both the bootp and dhcp parts for pxe booting.
dhcp just work on legacy no problem
This can be explained because the legacy bios firmware is probably only looking at the bootp fields and not only looking at dhcp fields for pxe boot info.
The issue “I think” is specifically with dnsmasq and its configuration. There is something missing to tell it to also send dhcp fields and not just boot fields. I’ve just not used dnsmasq this way before I don’t know off the top of my head the answer.
@errbravosix OK I see the problem but not sure right away how to fix.
In the ethernet header we are seeing both the next-server [172.16.1.15] and boot-file [ipxe.efi] fields populated. But there are no dhcp options of 66 and 67. The PXE roms in computers can either look at the header or at the dhcp options or both to find the boot server. Its up to the rom manufacturer where to look.
What dnsmasq is doing at the moment is only filling out the ethernet header fields, this is BOOTP method. and not filling out the DHCP method fields. In your ltsp.conf file the field match is happening because its picking ipxe.efi for the boot file. Whats missing is the sending the dhcp options too. So its 80% working, we just need the remaining 20% to have a functional solution.
@errbravosix From the DISCOVER packet I see this is an EFI system.
What I need to see is in the OFFER, the ethernet header section is there a value for next-server and boot-file? And then in the dhcp options section is there a value for dhcp option 66 and 67? Your screen shot doesn’t show that. We really don’t need the other two packets for seeing what is going wrong.