@rogerbrowntdl yes a smaller mother image would be best. 1.5.9 can grow the golden image to the size of the disk but not shrink it. Or just removed the recovery partition from the golden image. If you have an imaging solution in place is the recovery partition even useful?

I started with fog the shrink option really worked so I would create my golden image on a 70 or 80GB hard drive then expand it post deployment in windows. I also developed our golden images on a VM because I could snapshot the vm before critical steps. That kept me from having to rebuild the entire image again if I botched something. Stuff happens you know.

@george1421 Let me try if it will create a conflict by using Location instead of Sites

@sebastian-roth

Updated and he has confirmed it worked. Captured from the same host twice just to make sure.

Thank you so much for looking into this!

@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 Here is a list that one of the developers created a while ago. Its still relevant so you should be able to use it as a basis of your settings:
https://forums.fogproject.org/topic/6162/firewall-configuration

If you use multicast imaging then you will need to take some additional steps.

@londonfog You only get this screen when you do a deploy image from the iPXE menu? Where a traditional unicast (by registering the target computer and then picking deploy) works correctly?

OK lets see if we can get the target computer into debug mode another way. FOG WebUI->FOG Configuration->FOG Sertings Hit the expand all button, then search for KERNEL DEBUG and enable the check box and hit save. Now pxe boot the computer and go through deploy image. Does that put you to the linux command prompt?

If not go back into the same area and uncheck that option and then search for KERNEL ARGS and paste in isdebug=yes and try it again.

Hopefully one of the methods will get us into debug mode.

@george1421 Right. I won’t mess with it since we have it set up and working.

@sebastian-roth said in How to disable "password viewing" in the web UI:

Would be interesting to hear what others think about this.

Couple thoughts…

You can create an Active Directory service account with pretty limited permissions, only allowing it to join systems to the domain, and use this for FOG. This is something everyone can begin doing right now. This reduces the blast-radius should the credentials that FOG uses became exposed or compromised.

In the great majority of enterprise I.T. systems I work in, you can retrieve a credential “ID” (like username or access key) but cannot retrieve the credential “secret” (like a password or secret key). FOG is unique in this area, because the FOG Client needs the complete credential. Though, users should be entirely prevented from retrieving this credential… more on this in points below.

Merely concealing the password with the UI, someone who already has access to the FOG server could still potentially use the API to get the password. So, concealing via the UI is just obfuscation and not real security. Concealing via the UI is likely fairly easy to do and would result in less bugs to work out, but this isn’t real security.

Best solution in my view is to store the password within the database using reversible encryption. The encryption key should be generated by the FOG Installer, and put into /opt/fog/.fogsettings. The API / web components would then use one of several ways to handle encrypting and decrypting using this key. A quick internet search reveals lots of options:

https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php https://www.educba.com/php-encryption/ https://www.tonymarston.net/php-mysql/encryption.html

After implementing, the ability to retrieve the password in any form/nature should be secured… which leads into point 5 below.

The transport layer between the FOG Client and FOG Server is already encrypted, but should someone call the server endpoint to get the credentials, we don’t want the password to appear plain-text within the server response. I’ve not looked into how this currently works so I’m unsure in this area. But, I’d think the FOG Client would first prove it’s identity with client-based authentication, and after this the FOG Server would provide the password to the FOG Client. Maybe it already works this way? No idea. I’m remembering @Joe-Schmitt talking about this, and how he worked with @Tom-Elliott to solve it… This was a long long time ago though, and my memory of it is super fuzzy.

@sebastian-roth
good point…
I realized that i put the compression in the image section to the highest level (22 :))…
i will decrease it and i will try to capture again…

the below entry, opening max connections for sql - was indeed a fix.
default is 151, and i now have been a solid 200 connections for a week with no issues.

in debian 11, i did the following :

sudo su -
mysql -D fog
SET GLOBAL max_connections = 512;

To make this a permanent solution, refer to the link in the previous post.

@c4c @george1421 I can assure you that there should be nothing special that build.sh is pulling or doing. While we have different branches like master (latest official) and dev-branch (development) in the fogproject repo this is not the case in the fos repo. I always use fos master to build stuff. If I do really fance new things I create short temporary branches but merge those into master again as soon as things are ready to go.

One thing I just noticed in George’s desciption is using make -j4 to build. The official manual states that “Buildroot does not support top-level parallel build” (reference). Though I can’t really think of this causing the problem described.

If you work more on this you should also read this part of the manual: https://buildroot.org/downloads/manual/manual.html#full-rebuild - e.g.:

When a package is removed from the configuration, Buildroot does not do anything special. It does not remove the files installed by this package from the target root filesystem or from the toolchain sysroot. A full rebuild is needed to get rid of this package.

@george1421 said in Host status is unknow 2:

@eliaspereira So does it work now that you fixed name resolution on the FOG server?

At first, yes.

Thanks again for the great help!!!

@george1421 If I do everything manually as I’ve been doing, it works fine. Just looking to save some keystrokes. The boot.wim I’m building using MS Endpoint Config Manager Console does not have any task sequences but instead contacts the MG/DP for available task sequences and goes from there. Its easier this way. If we start to make stand-alone TS ISOs the wim files will become too large for ipxe.

@cwentwo Ok great on the single subnet.

I have a tutorial here on using the FOG server to capture the pxe boot information. On this system that fails to pxe boot follow this tutorial on how to setup the packet capture. Upload the captured file to a file share site with public read with the link and then either post the link here or DM me the link using FOG chat. I’ll take a look at the pcap to see what the client isn’t being told correctly.

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The filter used will specifically only collect the pxe booting process and nothing else. The total packet count of a healthy PXE boot is about 8 packets captured.

@george1421 You were right, it was a problem with DHCP, our System team solved it by comparing it with another site, I don’t know the details, but it’s working now, Thank you for your help!

Vamos la, o IP esta 192.168.0.100, não estou usando roteador, as port 66 r 67 ja esta configuradas .

A versão que esta sendo usado e 1.5.9.

Estou usando direto em um cabo de rede, porem não inicia o pxe.

@gjo on the host itself, you can look in the fog client log. You can also look at the “PC properties” and see it’s domain status. in Active Directory Users and Computers, you should see the new computer object. A note on this you might not be aware of, FOG will rename the system to whatever name you have set in the FOG Server for that host, it does this just before domain joining.

When I was doing a lot of imaging, we would set the hostname during Host Registration.

@eliaspereira said in wake on lan not working:

fogserver is in a different vlan from the vlans

This is going to be your first problem. The wol magic packet is not a proper IP packet so it typically can’t traverse a router. There is a way to send WOL packet but you need to send as a directed broadcasts. On most routers this “feature” is disabled because it could be used to abuse your networks.

Are you using (or wanting to use) WOL to wake up computers for imaging or just to wake up computers at a specific time?

Understand this subnet issue is a limitation of the WOL protocol and not FOG.

@reggiep9000 Which version of FOG do you use? We might have an issue similar to what you described with the latest dev-branch.

About FTP logging: https://forums.fogproject.org/post/130241

@joanmarzo Laptop bios/firmware settings.