Topics created by rogalskij

@rogalskij FOG uses the distribution’s tftp server. This is to ensure the services used by FOG is supported by your linux distribution vendor.

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

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

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

@rogalskij The FOG developers are expecting the Linux kernel developers will take 5.10.x to LTS status. When they do the FOG developers will make 5.10.x the standard kernel in FOG. ref: https://www.kernel.org/

FWIW, there was quite a few new drivers added to 5.9.x series (almost as many as was added to 5.5.x), so 5.10.x LTS can’t come fast enough because FOG will start running into that hardware soon.

@rogalskij While I can understand that your techs want to get it imaged as fast as possible I would still suggest they take on small hurdle at the beginning and save a lot of time later on.

See if you can tell them to PXE boot and choose “Perform Full Host Registration and Inventory” instead of direct deploy. This will ask for the hostname to be used within FOG (and als set in Windows!) as well as image ID and even set all the information for automatic AD joining. At the end of registration you can tell it to schedule a deploy so it does one reboot and deploys without any further interaction.

If you set things up correctly your techs would take maybe 2-3 minutes for the full registration but after that they can walk away and it does the deploy, rename, join domain (fog-client) without any further action required.

Beside that you won’t have additional MAC flooding that single host…

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

You should certainly be able to search in the GUI by MAC address, however sometimes even then the host won’t display due to other issues. Using SQL, you can always find items.

Please have a read through the topic Sebastion mentioned. You might also look at this Wiki article: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

@Sebastian-Roth Thank you for all you and everyone does. I agree with you this was a good choice to make a second topic out of. This is working well now and I greatly appreciate all the assistance!

@Tom-Elliott Thank you for all the assistance. I actually ended up testing dev versions 1.5.7.102, and 1.5.8 and I can confirm both indeed fix the issue. Both versions now start all the services correctly after several reboots. Thank you for all your assistance Tom and everyone!

@rogalskij said in Email to user who does the imaging:

Is there a variable we could set in the “Email Address” field, like “{USER}@emaildomain.edu” or something of that nature?

Unfortunately there is no variable at the moment. But it’s a tiny change to make this work. I just pushed a fix to the dev-branch. Whatever version you run you can either wait for FOG 1.5.8 to be release soon or add this change manually. Don’t worry about the schema update you see in this commit further up. No need to add this.

I appreciate the quick reply Tom. I was just curious if there was already a quick check box to turn this off or not. I think I will hold off on it and just let my team know they need to be sure to approve hosts after installing the client. I appreciate your insight and look forward to a possible feature addition in the future!

Found the issue! After some research and discussion with Cisco, we had to add “PIM” to the vlan on our core, even though both the server and client are both on the same vlan!

Used the command - ip pim sparse-dense-mode on vlan 1 interface and it started working like a charm! I really appreciate everyone’s assistance here. This will help our institution so very much.

@Quazz and @george1421 Thank you both. I appreciate the assistance. I tried ipxe.efi and it worked! I now have my Dell Optiplex models PXE booting using UEFI just the way I was hoping. Only oddities is the screens are a bit smaller, and the PXE boot shortcut is now “esc” instead of my custom shortcut. That is a small first world problem however. Thank you all again this community is fantastic!

As always, the community comes through! Not sure how this got askew, but following these directions I was able to fix the issues. The image pulled correctly and at the end updated the database info. The image is good, I am all set. Thank you again this was awesome!

This is exactly what I was looking for. Added the LDAP plugin, then added the ldap php module and modified to the php config. I now have it working. This helped greatly thank you!