Posts made by rogalskij

@sebastian-roth On my 1.5.9 server you can absolutely see the AD password. It is blanked on the setting itself, but if you go into a host and click the “join domain” you can see that password in plain text no issue. Is this a bug on my system perhaps?

@george1421 Thank you for the information George. The fields that I see it affects where you can actually view the password in plane text are as follows:

storage node general > Management Password
Hosts >pick a host > Active Directory > Domain Password
Fog Configuration > Fog Settings > Fog Storage Nodes > STORAGENODE MYSQLPASS
Fog Configuration > Fog Settings > Proxy Settings > Proxy Password
Fog Configuration > Fog Settings >TFTP Server > TFTP FTP Password

Could be others that I am missing, but these are where users of the GUI on my server can see the password in plain text. The ability to toggle this feature on or off would be great. Probably requiring an admin password to change the toggle. Thank you very much!

We have FOG 1.5.9 installed, and for security purposes we were curious if it was possible to remove the plain text viewing of passwords in the various locations this shows up? Our security requirements are fairly strict, and this would be helpful to not have the password show in plain text to those who have access to the GUI. Happens in several locations we notice, including with domain accounts for joining machines to our domain post imaging. Any thoughts or assistance is appreciated. If this is not possible, would it be possible for me to submit a feature request for this? Thank you all!

-Josh-

@george1421

We found that we had to fiddle with a good many settings in the bios including UEFI boot path security and a few others. Even then the only way we can get to it is by doing “F12” and manually choosing PXE Boot which is very strange. It works after that however. This can be closed out.

We have 15 or so Dell Latitude 5420 laptops, we have configured them for UEFI, PXE boot, AHCI, and disabled secure boot all per our normal routine.

When it starts to boot, it finds no compatible pxe boot and skips it and continues in the boot order. We are on version 1.5.9.62 of FOG, with a version 5.10.50 Kernel. It feels like the Kernel doesn’t support this particular device, but could it be something else we are missing? Anyone have any suggestions or experience with Dell Laptops this new?

@george1421 I will certainly never try to upgrade CentOS forklift style again. You were correct I upgraded Centos from version 7 to 8. After the mess it created I took your advice and ran the FOG installer using “GIT” and it cleaned up a bunch of the issues. A BOAT LOAD of things were missing after the upgrade but now they are functional. Thank you for all the assistance, FOG’s community and dev team is top notch.

After updating Centos to version 8, my fog server no longer PXE Boots for UEFI clients (that is all we have). We get the attached error, it claims the error is “PXE-E99” and that the “NBP filesize is 0” and then PXE skips right on by. I believe it is something to do with the upgrade of Centos but not sure what exactly. The interface names did change from em1 to eno1 Anyone have any suggestions? Currently unable to image at all.

@rogalskij And I answered by own question after reading this post. Very helpful and explains the difference in the kernel versions. Very helpful as always!

https://forums.fogproject.org/topic/14732/kernel-versions-4-19-143-vs-5-6-18

@george1421 I upgraded to the 5.6.18 and it fixed it! What I don’t understand is why the 5.6.18 kernel is lower in the list of kernels if it is the “latest and greatest” kernel. Shouldn’t it be on top instead of the 4.19.145? I am a bit confused by this.

Also, forgive my ignorance, but what does LTS stand for?

Tried to deploy our existing image to Dell Latitude 5410 laptops. Deploying these to the laptops manually via the “keyboard method” (not registering in the console but just going through the menus right at the laptop).

Makes it through the menu system of the server, I choose the image and then when it starts deployment, it throws an error “No network interfaces found, your kernel is most probably missing the correct driver!”

This is odd since it netbooted and I am on the latest version of FOG 1.5.9, not sure if it is a kernel issue or something else. I updated the bios and tried several of the laptops. My Kernel version is 4.19.143 which claims it is the latest in the list. Any suggestions?

@sebastian-roth

The process is as follows for a new machine never having been imaged. Desktop support tech sets all the necessary BIOS settings to get it to PXE boot. Then said technician PXE boots the machine, images it without registering it, and waits for it to reboot. After it reboots, the technician logs in locally and renames it while at the same time joining it to our Active Directory Domain.

Then I log into the console sometime later and I notice that yet another mac address has been crammed into a machine in the console.

@sebastian-roth

Sorry I didn’t respond until now. We are still having the issue. For these machines, the majority we DON’T register beforehand. These are usually imaged by our desktop team at the PC using a manual “netboot” on the machine itself and then imaging it. Then we end up with hosts in the “Pending Hosts” section or in this case they never show up there because they show up under some other previously imaged machine as shown in the image I posted. We rename the PC manually after it get’s imaged in this case.

Currently we have the default setting of “Change hostname early” set, should we disable this?

I do have the FOG client installed in my image as I thought this was the desired behavior to “capture” an image

If we need to rename the PC BEFORE imaging, how would we go about this but still utilize the manual imaging process right at the PC itself? (My desktop team prefers to image this way even when the original image on the machine is functioning correctly).

I will certainly turn this off in my image, but the mac address that shows up on another machine, is a real mac address of a machine that I just imaged. So let’s say I image a computer named “PC1” using the manual keyboard based method of FOG. Then after I go log into the console, I can’t find it under “pending” or anywhere else. That is because it’s real primary mac address is listed under “PC7” or some other host on the FOG console under “pending macs”.

We have been using FOG for a bit now, and what find is that with some machines, once we image them they don’t create hosts of their own but combine into existing hosts that already show up on the FOG Web UI. They show up as either “Pending Macs” or “Additional Macs” but either way it makes the machine not able to be found. The only real way to find where they are is by creating a new host and punching in the mac address manually and it will show you what other existing host the mac has been added to.

Is there a way to fix this globally and then prevent it from happening? I am not even sure the cause. If I delete the host with all the pending macs will the real hosts show up in the console? Very confused at the moment.

@Tom-Elliott Thank you very much! This will help us greatly as we image off hours or when others want to monitor the duration of imaging and such. Thank you so much!

Respectfully requesting a modification to the data “Image Completion Task” emails contain. The feature is excellent, one small request would be to add the following lines in the email sent:

Image Duration (in other words, how long the task took to complete)
IP Address of the host that was imaged

The image duration is the most important as sometimes we start images before leaving for the day, or sometimes our supervisor requests that sort of information about an image task. Thank you for your consideration!

@Sebastian-Roth

I suspect this already had the fog client at some point. We image the same machines over and over for various reasons in our labs and in our classrooms. Is this not supported by FOG? Is there some procedure I should be running before we image the machines or something?

From the GUI is there any way to search via mac address?

Thank you Wayne, I use a deployment program to install the client so I figured it should work just like the others in the lab did. It is odd, like 25 will work, and 4 will fail in one room. By “fail” I mean not show up in the client. Attached is the log. I notice the response module fails but I don’t know what that means.

fog.log

I have several hosts in several computer labs that don’t show up in the console when we install the FOG client. They just never show up in pending hosts or in “hosts”. It is possible we have installed the client on them previously and maybe that is the issue? I tried resetting the encryption data on all of the hosts but it didn’t change anything.

In any event, is there a way I can globally fix this? I considered that 1.5.9 might fix this issue as every update seems to fix problems all over the place but I was curious what the community thought.

I realize this post is a bit old, but I wanted to thank everyone for their suggestions and give our experience to back up what has been said in this topic already. We experienced an image that should have been about 120gb, but was showing in FOG as the full 500GB hard drive. After referencing this thread, it fixed the issue. The steps we took are below in order:

Verified that the PC didn’t have a second drive or second large partition it was capturing
Verified that bitlocker encryption was OFF using the command prompt command “manage-bde -off C:”
Ran Disk Cleanup (to get rid of old unused files)
Ran Tools > Check to scan for hard drive errors (may require reboot to fix)
Ran Tools > Tools > Optimize and defagment
Capture Image again

Once we did those steps, the newly captured image only takes up the actual amount used on the hard drive.