This is resolved. I found that I needed to add the corresponding storage node to the location under the “locations” tab

@namihulu help me，please

@george1421 Yes, really because of the substitution of certificates! Reinstalled fog and everything worked. https I was offered to enable the fog installer.

@anwoke8204 In this article https://www.cherryservers.com/blog/how-to-configure-ubuntu-firewall-with-ufw There is a section about logging. It kind of indicates that the default deny policy logs blocked packets in /var/log/ufw* files. Lets see if there is something there regarding to what nfsv3 is trying to do. I don’t have ufw enabled on my fog servers so I have not run into this issue before.

It looks like you have all of the rules/ports enabled.

Thanks for your support.

I will try to test changing the kernel in the 1.5.10 machine when come back to office.

The kernels are different between the two different machines. If the downgrade kernel not work I will try to capture the info on debug mode.

Captura de Pantalla 2023-07-31 a las 8.16.56.png

I decided to drop it after all the headaches. If I try this again later, I’ll try your steps. Thanks for the tips!

Jerome

@george1421

You legend that worked 🙂

Thanks a lot, great project you guys have here!

Aydan

@Tim-Reynolds Thanks for the update and great you got this fixed.

@george1421 said in How to setup ProxyDHCP with FOG:

@wildcat2083 You need to ensure that there isn’t a dhcp server already running on your fog server.

ensure that dnsmasq is not
systemctl stop dnsmasq

now check to see if something is bound to the dhcp port
netstat -an | grep :67

If you see a response like 0.0.0.0:67 then there is still a dhcp server on the fog server.

You can also run this command to see if the isc-dhcp server is in memory. ps aux | grep dhcp If it returns isc-dhcp and a process ID then its still running.

My bet if you look at the log file in /var/log/syslog (or /var/log/messages) it will say that dnsmasq can’t bind to the port :67

Here is the output of ps aux | grep dhcp
kristal 110299 0.0 0.0 17732 2408 pts/0 S+ 15:27 0:00 grep --color=auto dhcp

and its telling me

Starting dnsmasq - A lightweight DHCP and caching DNS server…
Jul 23 15:22:49 kristal-virtual-fog dnsmasq[109913]: dnsmasq: failed to create listening socket for port 53: Address already in use
Jul 23 15:22:49 kristal-virtual-fog dnsmasq[109913]: failed to create listening socket for port 53: Address already in use
Jul 23 15:22:49 kristal-virtual-fog dnsmasq[109913]: FAILED to start up
Jul 23 15:22:49 kristal-virtual-fog systemd[1]: dnsmasq.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
Jul 23 15:22:49 kristal-virtual-fog systemd[1]: dnsmasq.service: Failed with result ‘exit-code’.
Jul 23 15:22:49 kristal-virtual-fog systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.

kristal@kristal-virtual-fog:/etc/init.d$ netstat -an | grep :67
udp 0 0 192.168.5.214:68 192.168.5.1:67 ESTABLISHED
kristal@kristal-virtual-fog:/etc/init.d$

That ^^^^^^^ is then i install dnsmasq via apt install

EDIT::: I got dnsmasq installed but when i try to boot with a vmware pxe, the dhcp works but then when it gets to tftp it cant find the file and im never greeted with the boot menu

9d5799a9-118f-4b12-aca4-1bb4306debf3-image.png

EDIT2:
After tinkering I learned I needed to follow this section
DNSMASQ settings for iPXE
This information pertains to FOG 0.33 and the new iPXE boot method.

In order to continue to use dnsmasq to dole out ip addresses and to help find the boot file, some changes need to be made to force the boot file to load the iPXE boot file.

FIRST Update the schema by navigating to your fog management page and install the update.

Make the following changes to your ltsp.conf file

and I had to do this line
cd /tftpboot
sudo ln -s undionly.kpxe undionly.0

Once I performed these and restarted the dnsmasq service, dhcp worked as proxy and it did indeed serve up the proper file allowing fog to proceed

You can disregard the questions in my previous post. IT’S WORKING!!!

I downgraded refind to version 0.11.0. That was the solution for the HP Elitedesk 705 g4 model.

THANK YOU to anyone on this thread who tried to help me. Particularly @george1421. I really appreciate it!

@george1421 I searched for that setting everywhere on the MSI Z690-a and could not find it… apparently they moved it. Finally found it and disabled it, FOG inventoried perfectly! Thanks for the quick fix

@george1421 Thanks a ton for those words (OK that iso image seems to be only a legacy/bios boot media.)

I figured out one thing I was doing very wrong.
I was PXE booted in UEFI… when hitting F12 to boot the PC, I automatically selected the IPV4 under UEFI, and not the “network boot” under legacy, both of which show up in my F12 menu. Both of which FOG PXE boot works with.

Well, after using the legacy, the dell iso image (that only shows CD.txt) works flawlessly. Now I think everything will work that requires legacy for me, as some things seems you can’t use PXE UEFI with (perhaps not supported by the manufacturer, some programs like Memtest require spending thousands of dollars to get the “site edition” that works with PXE, etc). Keeping in mind your words in other posts about the size limitations of isos (2gb?), the ones I wish to use should all be small enough. I think we can mark this as solved.

Thanks so much for your help.

HI @Sebastian-Roth Sebastian, yeah sorry about the double submission it was by accident. I will sent you the details that you requested soon. thanks

@typotony Sorry I’m late to the party.

I haven’t built a “helper” command yet for removing fog images, but I do have Get-FogImages

https://fogapi.readthedocs.io/en/latest/commands/Get-FogImages/

If you setup the fogapi powershell module, you can use that to get a list of the current images.

You can delete the records of the fog images from the database via

Remove-FogObject

i.e. this would delete ALL your images

$images = get-fogimages $images | Foreach-object { Remove-fogobject -type object -coreObject image -idofobject $_.data.id }

That little snippet is untested but should be enough to get you started.

I’m pretty sure the api command won’t remove the files from the server though.

However, I believe the path to the files, or at least the relative path is in a child property of the data property when you run Get-FogImages.
So if you set this up to run on the linux based fog server using the powershell api module, you could script something that runs in a cronjob to delete from the database and then the files.

i.e. (again untested as I’m away from my test environment, so the property names are guesses, but it should point you in the right direction)

Get-FogImages | % { if ($_.data.name -eq "removeMe") { Remove-fogobject -type object -coreObject image -idofobject $_.data.id rm -fr $_.data.path } }

This, if run on the fog server where you have configured the fogapi module (see my signature for doc links), would find images named “removeMe” and then delete them from the database and then the files from the server.