@BSZAdmin hello, I have the same issue, can you please help me? How did you fix it?

@chanstag A proper dhcp/pxe boot process should be this.

PXE client - Discover DHCP Server - Offer PXE client - Request DHCP Server - ACK.

That second pcap is discover, offer 1, offer 2, discover. Meaning that the pxe client didn’t get what it needed to even get an IP address.

So a couple things I’ve gleaned from looking at the pcap.

If your dhcp server is running on your router, its not responding to the dhcp discover from the pxe booting computer. You have a non-fog created dhcp server running on the fog server. Its responding with an IP address but its not sending the boot file or next server information. The FOG created dhcp server will send the proper boot information. You have dnsmasq installed on the FOG server, and it IS responding correctly. But because there is a dhcp server also running at the same IP address the target computer is getting confused and taking the dhcp offer and not the proxy dhcp offer. Your target pxe booting computer is a uefi type BC (00007). Not really important, but dnsmasq should be sending ipxe.efi to the target computer so it can boot.

@seniorvodka There seems to be no image defined for the host…

Yes they are assigned

ftp_proxy=http://10.andsoon.:1234
same with http and https
and
noproxy=10.fog_ip

@jgiovann Great you figured this is a spanning treee thing! Seems like I was to focused on the issue might be routing problems that I didn’t notice the message udhcpc: no lease, failing.

In a real production network (where turning off spanning tree is not be allowed), is it therefore possible to re-configure the FOG server to wait longer or retry more times before it gives up the registration retry loop ?

The problem cannot be solved in the registration retry loop I think but we’d need to tell the dhcp client to wait longer. But from my point of view you should be able to solve this by setting the client ports to “port fast”. There er different names for this but what it essentially does is disable spanning tree for particular ports where you surely know there are no other switches connected but only clients. On those ports you never ever need spanning tree because single clients connected to a port can never cause a loop (which spanning tree was invented to prevent from)!

@gfontenot You didn’t happen to mention what version you were upgrading from. But in my simple mind, I would just copy the raw image files from the old FOG server to the new FOG server making sure the directory permissions and owner is set correctly on the copied files. Then from the webgui, export the image definitions into a csv file, and then import them into your new fog server. You will need to reregister all of your hosts again, but then you don’t get a bunch of legacy settings over to your new fog server. If that route doesn’t work, you can always import the DB like you did before.

@maouu Run getenforce and post output here…

Which server OS do you have?

For snapins you need to check the permissions of /opt/fog/snapins

@Paulo-Guedes Ahh, I just saw that a fix was actually added upstream in Juli this year: https://lkml.org/lkml/2018/7/23/671 (just didn’t notice it a little further down the code)

Can you confirm this is fixing your issue? Have you used one of the official FOG kernels since then? Which versions?

@pietroaretino Sorry for the late reply. We’ve lost track of this issue. Let’s see if we can work this out for you.

I’m just trying to upload a zip file of MS-Office 2016 install.

I am wondering if it’s just file size issue? I have just installed FOG 1.5.5.3 on Debian an created a couple of SnapinPacks. First smaller ones than bigger ones. All working great up to 250 MB. So I can’t replicate the issue as you describe it.

Would you mind updating to FOG 1.5.5 or even the dev-branch (currently 1.5.5.3) to see if you still see the issue? We’ve adjusted some of the php-fpm config values since then. So maybe this is fixed for you already.

Curl calls in themselves aren’t inherently insecure to my knowledge, they can be without validated input like you said. I just go with the practice of turning features off for securities sake rather than leaving it all on and running on default settings unless something we use needs to use it in which case I don’t mind turning it on unless there’s a huge security risk attached.

TL;DR I just try to keep my systems locked down until areas need to be enabled for programs, instead of leaving everything default.

@astrugatch said in Active Directory after image deployment not working.:

If I am installing FOG for the first time (as opposed to upgrading) and I enter the DNS name as part of the new installer and having the CA generate a cert with the DNS/hostname does HTTPS become the default.

Ahh, now I get you. No haven’t changed the default to be HTTPS as it would involve compiling the iPXE binaries as well. Think that is the next step. I will consider removing the iPXE binaries from the repo and simply rely on compiling them on each install altogether. iPXE code is usually fairly stable. What do you think @Tom-Elliott ?

@Sebastian-Roth Thanks! That saves a lot of space so I can upgrade from 1.5.4.

@Abuelika Not need to say sorry or even delete the post. It’s perfectly fine to ask and I think it’s great to have this here in the forums so others might find it and can help themselves as well.

@svalding Did you ever get this solved? rEFInd 0.11.4 is out and you might give it a try.

@george1421
Finally, I did the decrypter 😛
Thanks for the code!

@vince-villarreal Two other points.

You can build a usb boot drive with iPXE, but again that still relies on dhcp having the right settings to instruct ipxe on how to find the fog server.

You can also build a FOS usb boot disk, that will boot you right into FOS bypassing PXE altogether. But there are some caveats with this approach. If you can overlook the caveats and just want to capture and deploy (no multicast, no direct imaging from iPXE menus, etc) it will work for you.

One last comment, fog doesn’t like it when/if you change the IP address of the fog server once the FOG management console is installed. There are work arounds, but its best to have it at its assigned (forever) address when you install FOG.

Thanks for everyones help. I decided to try it on an actual device and add the -Wait at the end and that worked. @jflippen your way worked as well. For what ever reason my VM was would both say complete right after the start of script. When I attempted to run it on a physical PC it worked without any issues and completed with the delays.

make sure clients have boot rom enabled in the BIOS - otherwise they won’t boot at all.

in my environment :-
066 points to fog /tftp server
067 bootfile = undionly.kpxe

@hancocza I totally missunderstood this whole topic right from the start. It would have helped a lot of you’d clearly mentioned that you are using a custom SSL certificate. Might be obvious but I did not get it.

So what you describe here has nothing to do with FOG as far as I understand it. The password input stuff is something Ubuntu is doing when you start the apache webserver and you have a password protected private key. We as in the FOG installer does not add anything to that. So my guess is that Ubuntu changed things with one of the latest updates.

Probably you just need to install the correct extra package to make this work again…