Topics created by rogalskij

@rogalskij said in OS Details no longer working:

For those experiencing the same issue on mainstream linux distros, navigate to your “resolv.conf” config file located in /etc/resolv.conf and add your individual search domains. Test a ping to a DNS name via command line on the box itself, then check your GUI again. Took about 2 minutes for it to reflect and show for me.

I’ve just done this, and now noticing a remarkable increase in performance of the 1.6 web page. Thank you!

Hi @Tom-Elliott. Do you know which settings do I need to change so outgoing email is not coming from Apache?
I changed the outgoing email for FROM EMAIL and EMAIL BINARY in the web UI to donotreply@mydomain.com. Notification email went out as apache@myfogserver.localdomain. I then set myorigin = mydomain.com in main.cf, I received the notification from donotreply@mydomain.com which looks correct but according to maillog, and full header of the email, the email was sent from apache@mydomain.com.

@rogalskij so it seems your “ipaddress” is defined as your fqdn either on the IP address for the storage node directly.

I don’t know what your storage node settings look like but should be looked at likely from:

Storage Node-> DefaultMember

HOpefully that will help.

Normally if you can dereference the DNS name all would be fine so I’m just not sure where to help out.

But at least you know what is happening now?

Thank you for letting us know.

@Tom-Elliott

Thank you, while looking at the log, I noticed an oddity and after reinstalling the FOG client, it is now fixed. I appreciate the assistance in helping me track down this problem. The tasks are working correctly when coming from the FOG server itself now. I appreciate it!

@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 My apologies. So what I meant is that, the inventory information is sent in the mail.

So for example the following information will come with the mail:

System Manufacturer Dell Inc.
System Product Latitude E5470
System Version Not Specified
System Serial Number H857NC2
System UUID 4c4c4544-0038-3510-8037-c8c04f4e4332
System Type Type: Laptop
BIOS Vendor Dell Inc.
BIOS Version 1.29.4
BIOS Date 12/21/2021
Motherboard Manufacturer Dell Inc.
Motherboard Product Name 0VHKV0
Motherboard Version A00
Motherboard Serial Number /H857NC2/CN129636920214/
Motherboard Asset Tag Not Specified
CPU Manufacturer Intel® Corporation
CPU Version Intel® Core™ i5-6300U CPU @ 2.40GHz
CPU Normal Speed Current Speed: 2400 MHz
CPU Max Speed Max Speed: 2400 MHz
Memory 7.66 GiB
Hard Disk Model SATA3 256GB SSD
Hard Disk Firmware U0506A0
Hard Disk Serial Number 2021120601747
Chassis Manufacturer Dell Inc.
Chassis Version
Chassis Serial H857NC2
Chassis Asset Not Specified

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!