Recommended PXE best practices?

[number_one]

As a new FOG user, are there any quick tips to make sure there aren’t any catastrophes related to users booting PXE with a FOG server in an existing production network ?

I’ll be using an existing DHCP server that redirects PXE requests to the FOG server and I want to be dead certain that a random user isn’t going to be able to accidentally image their computer when booting up. There is is much info out there and so many complex configurations related to PXE so I thought I’d just ask for any quick pointers.

And if I missed a post or WIKI page that covers this I apologize.

[Tom Elliott]

[quote=“number_one, post: 28807, member: 24434”]As a new FOG user, are there any quick tips to make sure there aren’t any catastrophes related to users booting PXE with a FOG server in an existing production network ?

I’ll be using an existing DHCP server that redirects PXE requests to the FOG server and I want to be dead certain that a random user isn’t going to be able to accidentally image their computer when booting up. There is is much info out there and so many complex configurations related to PXE so I thought I’d just ask for any quick pointers.

And if I missed a post or WIKI page that covers this I apologize.[/quote]

In 0.32 and earlier the PXE boot system was a little more “dangerous” in that it had all options by default. What I mean by this is it had:

Boot to Hard disk
Run Memtest86+
Quick host registration and Inventory
Perform Full host registration and inventory
Quick Image
Client System information
Debug Mode

The user could, if the host wasn’t registered, perform full host registration and inventory, join their system to FOG and have it perform an image of their system without knowing any information. They could also boot the system into debug mode, and completely wipe their systems or erase passwords if they knew what they were doing. So, yes, there were ways to have regular users hurt their systems. This was not typical though as it does require some knowledge of computers and linux. But there was always the possibility. Unless of course you added pass codes to each of the menu’s.

With 1.0.0, we started actually limiting options. If a host is registered, it only presents:

Boot to Hard Disk
Run Memtest86+
Quick Image
Quick Deletion
Client System information.

The Quick Image and Quick deletion options require the FOG username and Password natively to be successfully entered to run. So the user could run a memtest operation or boot into the Client system information, but the only real harm with these would be loss in production, no damage to the system.

If the host is not registered, it only presents:

Boot to Hard Disk
Run Memtest86+
Quick registration and inventory
Full registration and Inventory Client System information
Client System information.

With quick registration the user “could” register their system to fog, and if you’ve enabled the QUICKREG_AUTOPOP stuff their systems could be imaged for them, based on the circumstances, but that’s about the only threat. Full Registration could occur, but if you set it up to image there, it will prompt for username and password of the FOG System to allow imaging.

You’ll notice options are removed and display for the variants of the host. You’ll also notice the debug option is not available in the default menu system. So while Quick registration, if setup on the FOG Server with an IMG id, the system COULD be imaged, this is really the only time this could happen.

That all being said, where I work we have around 2500 systems that are imaged with fog. We have never had a person “play” with the menu options in 0.32 with or without the passwording of the menu options. They typically just boot the system and wait until it’s booted into Windows. 0.32 you can simple password encode the menus. You could also Hide the menu structure if you’re that worried.

1.x.x you can Keysequence the menus, meaning they’re not available to the user in the first place, until a preset key sequence is pressed AND a valid fog username and password are entered. You can also have a No Menu option which simply checks if there’s tasks for the host, if not, just boot to the hard disk. So there are many ways you can prevent and/or stop this “issue” altogether if needed.

Hope this explains it.