@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…

@kratkale Ok, I finally got the time to get into fog-client development again. I am trying to answer your questions step by step.

About port naming: The field Printer Port is what you see in the Windows printing dialog as “Port name”. So if you put in 9100 it will be named 9100 but if you put in an IP the port will be named exactly as you want it. On the other hand if you want to specify a different TCP port for printing you put in x.x.x.x:9111 in the Printer IP field. I will change the field labels in the FOG web UI to make this clear.

Changing the printer setup on FOG changes sometimes nothing. (e.g. the name of the inf file - the printer …) My solution was to deploy the computer again …

I am not exactly sure if I get what you mean. Let’s see… If you change any of the settings in the FOG web UI while the fog-client is running on the computer the changes won’t be sent out to the client immediately. This is something I hope to change in the future but that’s how it is right now. But if you change things and then reboot the client machine it should use the changed settings!

-) Group management with Printers: If I update a group with the option “only Assigned Printers” the clients are not updated. The are still in the mode “No Printer Management”

This is a known issue I just fixed a couple of days ago. It will be in the next release!

-) How to install a local pdf Printer, when I use the option: “Only Assigned Printers”

Find out the settings used in the PDF printer (using the fog-client PrinterManagerHelper.exe or manually from the printer properties…) and set it up in FOG as well?! Should work I suppose.

@george1421, @Sebastian-Roth the only thing I foresee and maybe missed. Selinux won’t automatically be disabled because you made the change to the config file, it would require a reboot of the machine first. I would also, suggest changing from disabled to permissive. Disabling forces the file system to be unsupported and require being reestablished should you turn selinux back on. Placing into permissive mode keeps the file system contexts active and does not hinder usage. Plus you enter the command setenforcing 0 to switch selinux into permissive mode for the current running session which doesn’t require immediate reboot.

DERP — Don’t mind me, I’m dumb. Looked again and see you do have it set to permissive and do run the setenforce command.