@florent 0.13.3.1 is the version I already tested previously.

@sebastian-roth Thanks for your answer. I wait then 🙂

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

@cwentwo You are amazing! That did it! Thank you!

@dima1002
use Debian 10 instead of debian 11
it’s php-gettext for Debian 10 , but it’s php-php-gettext for Debian 11

@myles said in Issues with one time PXE Boot on HP Workstations:

The time it takes for PXE boot to fail might be something we can get away with, but for them to watch an undesired PXE boot to happen will almost certainly trigger complaints,

This process of pxe boot into FOG and then fog menu timeout (default of 5 seconds) should take no longer than 15 seconds to start booting windows. If it taking minutes then something is wrong. As I mentioned I don’t have the client computer boot through the ipxe menu, but the IT tech select pxe boot when imaging is needed. This way the users computer boots normal 99% of the time, without delay.

Also I mentioned that changing the boot order isn’t what FOG does, but I also said a FOG Postinstall script is all you need. Changing the boot order is simply one line script. The (kind of) instructions for the uefi boot manager is here: https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples

If you want to do a little debugging using the efibootmgr program you can easily with FOG. Just schedule another capture deploy (doesn’t matter) but before you press the schedule task button, tick the debug checkbox. Now schedule the task. PXE boot the target computer. After several screens of text you need to clear with the enter key you will be dropped to the FOS Linux command prompt. From there look at/follow section 2 from the link I provided. That will give you an idea of what command parameters you need. Once you find the parameters you need to give you the boot order you desire then…

On the FOG server, in /images/postdownloadscripts/ directory there is a file called fog.postdownload Just add that efibootmgr command to the end of that file. Save it and test to see if it gives you the desired results.

Now you might need to make that call to the efibootmgr a bit more intelligent in that lets say you have two different sets of hardware that have different uefi boot orders. You might need to have different efibootmgr commands for different models or manufactures of computers. We can deal with that later if in general the basis work as you need.

Finally you will need to kill that debug task you scheduled at the beginning of this debugging because that job will stay active until imaging is complete in debug mode.

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

@sebastian-roth said in Fog quick image password not working:

If you mess with the code it will break PXE booting for any client.

@Strahd if you get into a situation where the file doesn’t get updated correctly and its messed up, simply rerun the FOG installer script and it will fix (return it back to the standard programming code) things for you.

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

@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

@dashwell Well you said you updated from an older version and you think the update is causing this problem. While I still don’t think the update caused this I still was wondering what version you used before.

Back to the problem: The error is pretty clear. The image was taken from a larger size disk. Probably using an older version of FOG which did only shrink but not rearange partitions (to fill the empty gaps). The version you currently use (20220203) is capable of rearanging partitions but you need to re-capture the image with that version to make use of it. So I suggest you grab a machine with a disk large enough, deploy that old image to it. Then create a new image definition within the FOG web UI (to keep the old one as backup), set this new image for the machine you just deployed the old image to, schedule a capture to the fresh image definition and then try to deploy this new image to smaller size drives.

@george1421 said in No Network Interfaces Found: Intel i225-lm Kernel:

you simply need to upgrade your FOS linux kernel to 5.15.x series. You do that from the web ui -> FOG Configuration -> Kernel update

Confirmed this fixed the problem. Solution is to perform the above steps @george1421 wrote.

@Redbob Yeah the wiki is really dated. We really need people from the community help us sort through it and move it all to the new documentation platform: https://docs.fogproject.org/en/latest/

Would you be keen to help us?

@joanmarzo Laptop bios/firmware settings.

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

@Daniel-1 You might want to open a new topic and post more details (version of FOG and fog-client used, fog.log) rather than re-opening a ten year old topic.

@koni said in Can't pxe boot UEFI:

But I didn’t find the pxelinux.cfg

That is correct you should not find pxelinux.cfg because that is for the syslinux boot loader not iPXE. To add items to the iPXE menu you do that via the web ui in FOG Configuration -> iPXE Menu, menus. There is no need to hand edit the boot menus.

Just for reference: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

@iamvincepr0 Look to see in the target computer firmware that mac address pass through is enabled. The issue is that ipxe is seeing the built in mac address of the computer, but FOS linux (that does the inventory) is only seeing the mac address of the usb dongle.

Also you will probably want to upgrade your FOS Linux kernel to 5.15.x version (FOG WebUI -> FOG Configuration -> Kernel update This will give you the latest hardware drivers for newly released computer hardware.

@john-l-clark said in Lenovo L13W Yoga not booting to FOG:

Ok I have found with the MAC passthrough in the Bios turned on we are not able to boot to FOG unless we were on the same subnet.

This is interesting. My intuition is telling me it might be an MTU issue. We have seen that with tftp, Where (typically) on the other side of a VPN WAN link the MTU of the data packet is less than the block size of tftp. The block size of 1468 comes to mind for tftp. When the network MTU dips below that level it causes fragmentation of the tftp packet, then the transfer fails.

Using the instructions I provided before for collecting a pcap on the fog server, you are interested in udp port 69. Start the packet capture and then pxe boot the target computer on the remote subnet. See if it attempts to contact the fog server. The tftp query will be 2 times before data is transferred, the first time the client queries the tftp server on the size of the file and the second time it asks for the file. My bet is that it will ask for the file size, but then the file is never sent.

@george1421 said in Error capturing Win 10 image after updating to the latest dev version - Resize Test fails:

Would it just create a larger disk image?

Yes exactly.

If yes then 7 or 8 might be a good start if size is the only penalty.

Ok, will 7 do for now.

@x23piracy Sorry for the long delay! This is a known issue in an older version of FOG and fixed in 1.5.9 and later.