Posts made by george1421

@45lightrain Firstly, let me say I have no experience with increasing hte MTU with FOG or any benefits. Where its failing is in iPXE. For some reason iPXE can’t take the larger MTU. The second challenge is with the FOS Engine (bzImage), you will need to set the mtu in there too. The FOS Linux engine is where the rubber really meets the road with MTU changes.

You could create a USB boot drive and boot directly into FOS (that would reduce the number of other things you need to address, just to see if changing the MTU would help.

I think you will be opening a lot of nuance issues in your network by upping the MTU, regardless if it helps with imaging or not. I would think it should help but unsure to what degree.

You say you are doing this to help with imaging performance. What numbers are you seeing during the partclone part of imaging? On a well managed 1GbE network you should be seeing 5.7 to 6.1 GB/Min. If you have 10GbE in your network core, and the fog server running on a healthy VM host server, with 1GbE to the desktop you should see in the area of 12-15GB/min range.

What numbers are you seeing and under what conditions?

@ccatcc Is this a new fog install or has it been in service for a while?

Will you verify that in this path on the fog server bzImage file exists? /var/www/html/fog/service/ipxe make sure bzImage is in that location.

@rodluz On that laptop, what is the processor model? From what I’m gathering (I’m a bit ignorant on arm systems) but snapdragon is akin to the word pentium. There are a few models that fit behind that banner. Is your system the x elite or one of the older processors like the 850?

FWIW It looks like snapdragon support will first be available in linux kernel 6.11

https://www.phoronix.com/news/Qualcomm-Adreno-X1-85-GPU-Linux

additional linux support docs
https://docs.qualcomm.com/bundle/publicresource/topics/80-70014-3/features.html

@MarkG said in Windows on ARM:

class “UEFI-ARM64” {
match if substring(option vendor-class-identifier, 0, 20) = “PXEClient:Arch:00011”;
filename “arm64-efi/snponly.efi”;
}

Well done working out the hard bits. It sounds like there needs to be some fog ui updates and we need to get that FOS kernel to boot cleanly. In the FOG Global configuration settings. There should be a field for log level, set that to 7 to see if there are any additional log entries that gets displayed. The default value of 0 or 4 masks most of the kernel messages. The level 7 is only used for debugging.

@stokehall said in Windows on ARM:

How do I go about this step? “Get that file name and key it into the dhcp server/s option 67 value”

The question back to you is what is your dhcp server for the imaging network? That is where you would set the value for the boot loader. BUT the OP of this thread has already done that and has proven how to get into the FOG iPXE menu, so the inits work. He has already figured out the arch type (11) for the dhcp server (what i needed the tcpdump/wireshark pcap for). Right now we have an issue with the fos linux (engine that clones disks) starting up. If I remember right the person that developed the FOG arm kernel was building it for a cortex CPU. It might not have all of the bits in it needed to boot the dell/lenovo. This is nothing unsolvable, we just need to find out about the processors in your system(s) and look at the kernel configs. This hardware is so new there aren’t a lot of info out there about it.

It would be interesting to see if you could find a live linux OS for the arm cpus and get that to boot. We could then reverse engineer the kernel settings for that live boot OS. (just thinking out loud)

@Tom-Elliott said in Windows on ARM:

So that leaves me with a few notes already:

Tom, I did some testing back in 2021 trying to get a rpi to pxe boot. I never did but here is what I found with FOG and a few changes that needed to happen: https://forums.fogproject.org/topic/14959/raspberry-pi-4-unable-to-pxe-boot

I’m only adding this here for reference.

@george1421 For debugging pxe booting issues, I need to see the output.pcap file that is generated from this tutorial. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

This task will show us the “hey I’m this kind of computer, please configure me” message. In that message I need to see what exactly the computer is saying what type it is. We will need this to figure out a long term solution to updating dhcp option 67

@stokehall ok, let me start out with neither the developers or myself have an ARM system (other than an RPi, but that is a different beast) so we will rely on the forum members to help us debug this.

With that said, let me tell you how it should work. When you pxe boot the computer it sends out to the dhcp server “hey I’m this kind of computer, please configure me” message. We need to see this message but more on that later. When the fog server or dhcp server sees this message it will send two optional dhcp fields. One is the boot server’s ip address and the second is the name of the file to bootstrap the computer. The boot loader/strap file that FOG uses is iPXE. The default ipxe files need to be hardware specific. For bios x86 systems the default should be undionly.kpxe, For uefi x86 systems ipxe.efi (or snp.efi) The first issue here is that the fog server or dhcp server always assumes your computer is x86 based. What you need to do to get past this part is to tell your dhcp server to send the ARM boot loader (full disclosure I don’t know what its called, but its on the fog server). Look on the fog server in the /tftpboot directory. Search for all files that end in efi ls -la /tftpboot/*.efi one of those efi files should have arm in the title. Get that file name and key it into the dhcp server/s option 67 value (understand this is a global setting and will send the arm file name to all pxe booting computers, but right now its just a test). With that arm boot loader in place you should get to the FOG iPXE menu. If you do then wonderful. Try to get into the hardware compatibility checker. Hopefully the ARM version of bzImage will be sent to the target computer. If you get into the hardware compatibility checker. That tests the FOS engine, if it runs it should image.

@Sab First I would have to say both fog server and fog storage node have to be on the same version. The fog storage node doesn’t have its own database, it uses the fog server’s database. There could be schema changes in the database between 1.5.10 and 1.5.9.

Unless you change the storage group around, its not possible to capture to a storage node (in the default configuration). Only the master node in a storage group captures the image, then it replicates the captured image to all storage nodes. Both the master node and storage node can deploy images.

If I had to guess, I would think that in the storage group the nas fog server is not defined as the master node. If I think I understand what you did to configure this setup.

On the fog error screen it should print out the kernel parameters sent to the FOS imaging engine. There should be a filed marked storage or storage_ip, that will point to the fog server it will try to get the image from. Make sure that is correct for your configuration.

@LLamaPie Well keep an eye on it, my concern is that there is a bug in php that allowed this to happen some how. Its in the http path and not the nfs path. Hopefully you will scan and or keep an eye on the cpu usage. When you detect a change surely review the apache logs both error and access as well as login logs to abnormal activity.

@Tom-Elliott The key is that its post the security update for FOG.

The question I have is:

1. How did that file/malware get onto the server
2. Why did it pick that specific path to hide in.
3. When was the server compromised. The date on the files in that directory may give us a clue.
4. Could it happen again? We don’t know because we don’t know how it was installed.

It almost seems intentional and deliberate to pick that specific path. I don’t think apache normally has write access to that path.

@OP is your fog server exposed directly to the internet?

@LLamaPie

/var/www/html/fog/management/.sys

Is not something that FOG creates. ref: https://github.com/FOGProject/fogproject/tree/stable/packages/web/management

.sys file / directory name means the directory is hidden unless you use the command ls -la /var/www/html/fog/management also .systmd is a hidden file made to represent systemd application.

I did find this article: https://sarperavci.com/ironshade-writeup-tryhackme/

So the question is how was this server compromised and if we don’t know it will probably happen again. What version of FOG did you have installed?

@MarkG OK let us know because there is some info that you can collect on these devices to help the developers validate the code.

@JamiesonCA092 ok it shows you have some debugging skills, so I’ll add a few new tools into your toolbox.

1. on the fos linux (target computer) when you schedule a task and tick the debug checkbox, when you pxe boot the target computer you will be dropped to the fos linux command prompt.
2. You can start the imaging process in single step mode by simply keying in fog at the command prompt.
3. The script will run until it hits a debugPause; command in the script. You can add that command in your custom script with echo statements to understand how your script is running. Pressing the enter key will cause the script to run again until the next debugPause command.
4. At the fos linux command prompt if you get the ip address of the fos linux (target computer) with ip a s and then give root a password with the passwd command (make it simple like hello, it will be reset at the next reboot). Once you have those 2 bits of into you can use putty or ssh from a second computer to the fos linux computer for debugging. Using this method you don’t have to sit in front of the target computer plus you can copy and paste using the putty/ssh session.
5. If you need to stop the fog script during hit ctrl-c to skip out of the script. At this point you can verify the environment, check the available variables, etc. When you are done looking around, then you can enter fog again to begin the imaging process once again. No reboot needed.
6. In the fog script the kernel parameters sent to fos linux are converted to bash script variables in the functs.sh script between lines 9 and 13 https://github.com/FOGProject/fos/blob/0efdd68f1783a06f3214607fc313db50747fbc43/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L9

I’m pretty sure Wayne is right that the varialbles in the postinit script are local and will be erased when the script terminates. But I would test to be sure.

One last hack I can think of is that you can hack the fog.mount script https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.mount Put the logic to decide the target’s IP address into that script. The concept of dynamically patching the fog.mount script can be found in this tutorial (which addressing the fog.man.reg script) https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg but the concept and actions are the same.

@DBCountMan In the post init or post install scripts the $mac variable contains the mac address of the target computer

To get the ip address this script will work

myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;

Getting the user id of who did it will be a bit harder since they never log into the web ui. The user ID and password they key in during the deploy image stays in ipxe and is not sent onto FOS Linux. I’d like to say that the username field can be trapped from iPXE and then pass that variable as a kernel parameter onto fos linux. Once that is done then the $username variable should exist in your fog scripts. Getting that info into the fog database is another challenge. In the post install script the /ntfs directory is mapped over to the fog servers /images/dev where you could append an echo statement into a text file.

Understand I’m taking in programming pseudo code. But I see an path here and it should work.

@MarkG In general there is basic support for ARM processors in FOG. But the realities are that there hasn’t been a viable ARM based workstation to validate the FOG configuration against. Yes there is the Raspberry Pi, but that is more of an embedded device and not a general computing computer. Since the developers don’t have one of these computers to verify the FOG code against it will take community involvement to work out the details.

When I was first testing the R-Pis I did find a few assumptions in the code that if FOG couldn’t determine the processor, it assumed a 32 bit X86 processor. Those issues have been corrected, but I’m sure there are others hidden away in 15 year old code.

So the short answer is, it might work or might not.

@DBCountMan The issue/explanation is that the unregistered hosts deployed via the ipxe menu doesn’t go through the normal task creation process so there is no database interaction. When you call the deploy image task the fog server creates the ipxe menu needed for imaging but that’s it. The fog server never “really knows” and unregistered guest was imaged.

Now what can you do on the back end? Probably a post install script could open a file in the /images/dev folder and write the mac address into a text file with the current date/time. This is possible, but I don’t have an example I can point to. If FOS Linux had a ail client it could send an email when it was done imaging too.

@JamiesonCA092 I can’t really give you a solid solution because fog isn’t designed to work the way you want it with unregistered target computers.

But I know how FOG works. There are 2 “hook” scripts. One is before imaging starts and one after the image push is complete. The bash script that is called before imaging starts is the postinit script. When this script runs all of the kernel parameters have been expanded to variables, including storageip value. This value as well as most others could be reset by this postinit script.

I have a tutorial on a postinstall script that uses the IP address of the target computer to decide what OU the target computer will connect to. That mechanics of the bash script could be the basis to update the storage IP variable. I don’t know if it works, but if you are that deep into modifying the ipxe script, creating your own bash script shouldn’t be to complicated.

Edit: Post on point. https://forums.fogproject.org/post/69725

@mentaluproar said in Could not select: Exec format error:

/var/www/html/dban/test.html

try it in /var/www/dban/test.html

different distros have a different apache2 document root.