@juelson Yes and what didn’t work? From your other thread you are using fog 1.4.4. That should support uefi systems, but it probably won’t see your nvme drives. For UEFI systems you need to send a different boot loader than for bios. For bios, dhcp option 67 should be undionly.kpxe that will pxe boot a bios based computer. For uefi based systems you need to have dhcp option 67 set to ipxe.efi. or snp.efi. Since you are using a really old version of FOG with new hardware you might be out of luck until you upgrade to FOG 1.5.x branch.

Points of interesting.

You need to update your FOS Linux kernel to 5.15.x series for the latest hardware support (FOG Web UI -> Kernel update) You need FOG 1.5.9 to update your version of iPXE to the latest version. In the Dell firmware set the disk mode to ahci mode. The default of raid-on will not work with FOG. Disable secure boot in the uefi frimware.

@george1421 Got it. I set up the rules using ufw with the ports from that list. I only tested a Full Reg and Inv so far. It hangs on Running Init Scripts for while then skips it, I think that is the script that pulls the serial number from the bios and auto-populates it as the hostname. I confirmed this when I disabled ufw and that step went right through without delay.

@george1421 So the second part of this is; I would create a custom FOG iPXE menu item to test this next bit. Since refind exists in the http path we can use the http protocol to grab the files you need.

I would start out by cloning the FOG provided refind.conf file to… for this example refind2.conf. Place any files you want to load in the http path on the fog server but not in the fog file path because an upgrade will delete your custom files. For this example lets create a new directory with
mkdir /var/www/html/crefind place your cloned refind2.conf file in there plus any other files you want to load onto the refind vhd.

set http-path http://${fog-ip} set custrefind-path ${http-path}/crefind set refind-path ${http-path}/forg/service/ipxe kernel ${refind-path}/refind_x64.efi imgfetch --name refind.conf ${custrefind-path}/refind2.conf refind.conf imgfetch --name os_linux.png ${custrefind-path}/os_linux.png os_linux.png imgfetch --name theme.conf ${custrefind-path}/theme.conf theme.conf boot || goto MENU

Understand I did not debug this menu at all, I just glued the bits together. So it might work or might now. But the idea is correct. Remember in your refind2.conf file the ipxe vhd has no paths so everything is stored in the root of the vhd. So this config file stanza
icon /EFI/refind/themes/rEFInd-minimal-drunkcj/icons/os_linux.png
Needs to be rewritten as
icon os_linux.png

@george1421 Thanks ! I found the problem few minutes after this post, with this subject
https://forums.fogproject.org/topic/12356/refind-conf-doesn-t-appear-to-be-used

@brakcounty I guess you will have to look into implementing NFSv4 then: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3

I read everything written here and thought about this: If earlier such manipulations were possible, is there a chance that Windows still did not provide for something. Is it possible to hack the system and change the memory size for updating? How is this even possible? I used to contact raid data recovery to recover the data I lost during the system update process and thought that even if they can retear the data, is it impossible to change the amount of memory used by this data?

@suzabi said in Abusing FOG as RMM (with public access)?:

Is it built for scenarios like this, or is it better to use it only with an active VPN? But in this case, remote wipe would be impossible.

FOG was not designed with that scenario in mind. I would not suggest to run a FOG server facing the internet unless you know what you do - being able to secure the whole setup.

I don’t think remote wipe will work because it needs PXE boot to start into such a task and it’s very unlikely someone sets things up in their own network after stealing a device.

Using FOG behind a VPN is good practice if you have different locations. But you might think about using separate FOG servers as well because imaging across the internet can be a pain if connection speed is limited.

@george1421 great answer, thanks a lot

@primofamilia In general when storage node #3 comes back online all changed images will be resynced to the #3 site from the master node. This will happen all automatically. You will have to do nothing more than bring storage node #3 back online.

With that said if your new site #3 will have a different IP address range, or more specifically the storage node will have a different IP address than at the legacy site you will have a little fixing up to do to bring the node back online. But its not that hard to do.

@george1421 said in Possible to secure /var/www/* ipxe boot contents?:

apache stop file browsing

Yes I will place this here to save a search for anyone who stumbles upon this post.
https://www.vultr.com/docs/how-to-disable-directory-browsing-on-apache/

@sebastian-roth Where do I “use –recreate-CA and –recreate-keys keys” switches? Like this?
.\installfog.sh --recreate-CA --recreate-keys?

@george1421 the good thing is, you only need to do the reg hack and app removal on the GI, once you sysprep the GI and capture it, when you deploy it, you have to do nothing and you can deploy to multiple laptops, vms etc

the pic i shows you shows a laptop with TPM enabled, using the deployed image
20220414_181954.jpg

@jack-mills Thank you. This is the solution.

In short, during the installation process, the installer will ask for server address with the default to ‘fogserver’. You will need to replace ‘fogserver’ with the IP address of your FOG server (i.e. the http://<FOG_ADDRESS>/fog/management).

If you’ve already installed FOG client, in order to change the ‘fogserver’ variable, you need to remove then reinstall FOG to get the window prompt asking for the server address.

I’m not sure how I missed that in my notes. Thanks again.

That is all I need to know. Thank you all

@Sebastian-Roth actually I didn’t touch anything anymore. It suddenly started to work. Very strange.