Posts made by Zer0Cool

4
Reserved for updates

3
Reserved for updates

2
Reserved for updates

1
Reserved for updates

Note: This is a Work in Progress, please bear with me while I complete the guide 6/15/2018

Base Setup

FOG version: 1.5.3
OS: CentOS 7.5.1804
FOG IP: 10.0.0.2

FOG acts as DHCP, all machines are on the same subnet as FOG, additionally installed Samba.

Goals of this Guide

My aim in this guide is to provide the steps needed to successfully PXE boot and install many OS’s using FOG and the underlying iPXE boot loader.

Most of this guide will be providing the parameters to enter in the FOG web GUI for iPXE entries. That would be either FOG Configuration | iPXE New Menu Entry or if editing an entry that exists iPXE Menu Item Settings.

This guide will make several assumptions. First, you have already installed FOG and hosts get an IP via DHCP and boot to the menu. The guide applies to the versions, base OS and other mentions above in Base Setup. Its also assumed that firewall is setup and SELinux is in permissive mode.

This guide is heavy influenced by this post here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images and I will be cross linking to it at relevant points throughout this guide. Thanks to @george1421 for his post, help and insights. I also discussed this post with him prior to making my own.

Initial Setup

I will first cover the basic setup I am using to facilitate this and then provide a post for each OS I have setup and tested. My testing was done on a physical Dell workstation, a Dell rackmount server and inside an ESXi 6.7 VM all using both BIOS and UEFI booting (when possible).

First I installed Samba using:

sudo yum install samba

I created the following directories on the FOG server:

mkdir /pxeshare
mkdir /tftpboot/os
mkdir /mnt/iso

I also made a sub directory under /tftpboot/os/ for each OS I intend to make available for PXE booting. IE: /tftpboot/os/centos, /tftpboot/os/win/7, /tftpboot/os/win/10, /tftpboot/os/fedora, etc.

I then created a symlink to the /tftpboot/os directory in two places. The commands are below:

ln -s /tftpboot/os /pxeshare/os
ln -s /tftpboot/os /var/www/html/os

The symlinks will make the OS install files in /tftpboot/os available via http and smb as well as via tftp. My experience has been that http is much faster than tftp and smb will be needed for PXE installing Windows OS’s. Feel free in the OS directions iPXE parameters to change http:// to tftp:// or whatever protocol you prefer.

A basic setup for samba in /etc/samaba/smb.conf would look like:

[global]
unix extensions = no
[pxeshare]
comment = FOG server SMB Share
path = /pxeshare
valid users = @smbgrp
guest ok = No
browsable = Yes
writable = Yes
follow symlinks = Yes
wide links = Yes

I have created a user on my FOG server strictly for SMB without the ability to login to the server (based on info found here). I have also added my user(s) on the FOG server to the smbgrp I will have setup as follows (replace ‘user’ with your desired username).

Basic setup for existing users (like the “user” you use to manage the server):

groupadd smbgrp
usermod user -aG smbgrp
smbpasswd -a user

chmod -R 0770 /pxeshare
chown -R user:smbgrp /pxeshare
chcon -R -t samba_share_t /pxeshare

Setting up a Samba user on FOG server without a home folder and with no login ability:

adduser --no-create-home --shell /sbin/nologin --user-group fogpxeu
passwd fogpxeu

The above creates the user and the password in Linux but not the smb password, which is what will be used and will be visible to anyone PXE booting Windows. To set the SMB credentials repeat the usermod and smbpasswd steps above for the fogpxeu user (or whatever name you want to give this user).

The end result is we can mount this SMB share on any machine connected to the network using any user credentials that have been added to the smbgrp and given a password for SMB. Further, we have a user that we will use for Windows PXE booting to connect to the SMB share and pull the files that cannot login to the FOG server directly.

Conclusion before Individual OS setup

At this stage we should have laid all the groundwork to make PXE booting using HTTP and SMB possible using iPXE. Below is a list of the tested OS’s that link to the directions for each (let me know if you would like me to add other OS’s):

Install

• CentOS (7.4.1708 and 7.5.1804)
• ESXi (6.5 U1 and 6.7)
• Windows (Windows 7, Windows 10, Server 2012 R2 and Server 2016)
• Fedora Workstation 28

Run

• Gparted 0.31.0
• Dban 2.3.0
• Clonezilla 2.5.5-38

Setup

• WinPE

Note: As of this posting, the iPXE menu entries created in FOG are listed in the order of creation (top to bottom in the menu) and cannot be easily reorganized. Plan ahead and create them in the order you want them to appear on hosts when PXE booting!

Other Resources:

• Creating a single iPXE menu entry that works with UEFI and BIOS found in my guide here. I use this method for entries like ESXi in which UEFI and BIOS entries need different parameters. This method allows one iPXE menu entry to behave one way if BIOS booting or another if UEFI booting, passing it different commands for either.
• Batch file for generating WinPE images with networking/smb connection here. I have altered the batch file a bit as detailed in Windows/WinPE directions.

@skydraw35 said in Host Registration:

I put the background and it work in Legacy/Bios for me !
I have a last question, when i up/receive my image, can i put the uefi ?

Not sure I follow you here. From the sounds of it registration works for you when BIOS/Legacy booted?

Are you asking if you register it via BIOS can you then deploy/capture images in UEFI mode?

I would think so, as long as you set the host machine to boot UEFI and the iPXE menu loads up. I dont think the registration of the machine is tied to BIOS/UEFI mode at all. Images and PXE booting are however, so you couldnt for example (at least not easily) capture a UEFI image and then deploy on a machine BIOS booted for example.

With the change you made to DHCP, you should test and see if UEFI now works too for registration.

@skydraw35 Worth a shot, not sure how narrow/broad the issue I had was.

Permissions is possible, however I dont know where the server writes the registration info to.

Does the same problem persist if you boot it in BIOS/Legacy mode? If it boots its unlikely to be permissions on the server.

@skydraw35 Can it boot to the menu/registration if you boot in BIOS mode instead of UEFI?

If so check this post https://forums.fogproject.org/topic/11972/ipxe-menu-colors-help/9

I couldnt boot UEFI plugged into my dedicated GPU, only my iGPU. If you only have a single GPU, try removing the background like I mention and see if UEFI boots.

@quazz Got the result:

noTftpBuild=''

Not sure if thats good or bad.

@tom-elliott said in Unable to Install Kernel 4.17.0:

Are you by chance bypassing TFTP file recreation?

Not that I know of, how would I check?

I am much more likely to believe I did something wrong than you guys, I may have goofed it up at one point and not known it.

Seems to be working now, Thanks!

@tom-elliott I owe you a beer! (or your beverage of choice). Ownership of the ipxe dir resolved it.

I am going to ask a really dumb question now (because the likely answer is I goofed up and dont recall) but why would it have been set to apache:apache as owner (all the way up the tree to like /var/www/html/fog)? Is there anything that FOG does that could have changed that without me knowing (like updating from 1.5.2 to 1.5.3)?

Thanks a million times over, I now leave work and relax thanks to you!

@tom-elliott Those settings appear correct to me;

host is proper IP in x.x.x.x format.
username: fog
password, as I mentioned matches the same credentials used in the storage node (i only have 1).
kernel dir is: /var/www/html/fog/service/ipxe/

From what I can surmise, tftp/ftp is downloading the file, whatever it tries to do with it after that is whats failing.

Whats it do with the download to “update” the kernel? From the logs/errors it seems its trying to move it and/or create a directory?

Is it possible its a permissions issue for where the kernel needs to be placed? If so whats the proper ownership/permissions?

If you have any ideas on logs to check id be happy to dig them up too, Ive checked all the ones I can think of or found researching the issue.

@tom-elliott I am concerned that left unresolved the issue could affect other, yet unknown aspects of FOG.

Manually replacing the kernel would be a valid short term fix. I would still be very interested in trying to resolve the problem.

Rolling back to a snapshot that was working a day or 2 ago exhibits the same issue. I have went back to my current snapshot/state.

I also noticed the Settings | Home | FOG Version Information is working now. Still have the error with the kernel update however.

I found this thread and tried both solutions, neither resolves my issue.

https://forums.fogproject.org/topic/11375/kernel-update-fails-oh-no-not-again/27

I did for some reason have an extra slash (double) in the path, so I removed it. Had the slash on the end of the path already. Checked the ftp password and storage password and they match, as does the entry in the file mentioned in the thread with the password in it.

I have rebooted, checked other tftp related settings in FOG (and all path fields in general), checked the xferlog file, seems tftp is grabbing the file as far as I can tell.

So I am basically in the same position still. Trying to get this worked out. Any help would be much appreciated, Thanks

This is really odd. So now the Kernel updates page loads straight away, no problem loading but still gives error trying to install kernels (even new ones with ‘addbnx’ in the name).

I also noticed I no longer get information under Settings | Home | FOG Version Information. It now just says “Failed to get latest info”. This morning and prior it would have information about my version of FOG, current version, and some other related info.

I tried rebooting and the issues persist.

I am also having issues imaging a machine, and am not sure if its somehow related. I imaged 3 identical machines yesterday with my image and snapin, all 3 worked no issue including joining domain, changing hostname and activating Windows, rebooting and running snapin to completion. Today I go to image a 4th identical machine (no changes made to anything FOG/snapin/etc) and it completes deploying the image but then seems to get stuck and either not activate Windows and/or not join the domain (despite all the information being entered for the host in FOG/web gui). It was earlier executing the snapin, but now doesnt do that either.

I have tried re-imaging this machine multiple times today along with deleting and re-registering the host many times. Is this likely related or a different issue?

@flareimp I found the documentation for DCC. It looks like you can disable devices but I do not see an option to delete them.

http://www.dell.com/support/manuals/us/en/19/command-configure-v4.1/dcc_cli_4.1.0/--disabledevice?guid=guid-dbe77d57-e1bb-4185-acb4-4b6e3852b4b7&lang=en-us

So I think your best bet is using a script based solution like in the links I gave before, either leveraging PowerShell or bcdedit, or attempting to disable the duplicates via DCC. However without DCC having the ability to delete them, you could end up with trouble later when you have a crazy number of those extra entries just disabled.

@tom-elliott Should most of us then use the regularly named kernel?

@quazz @Tom-Elliott I noticed now some new entries for kernel 4.17.0 called:

“Kernel - 4.17.0-addbnx TomElliot …”

Whats the addbnx portion mean, I couldnt find any mention of this in a search?

@joe-schmitt Providing a remote machine wont be an option for me to help, but any testing you need done I would be happy to do and report back.

If I need to setup any machines on my end for me to test with I can do that as well.

I have a more clear picture of the process you have detailed with the snapin, makes sense. I will make some alterations next week and test it out. Thanks

@joe-schmitt I think I am following what you are saying here. Are you suggesting running the removeclient.bat after having had the start.bat run? Would I be running the removeclient.bat as part of the snapin/snapin pack or via some alternate method like a windows task or manually?

As of now, the way I have it is that the uninstall is the last line of my snapin/bat and the uninstall line forces a reboot. So it does successfully run the bat/snapin commands prior to the uninstall but you are correct in that I noticed it would not run any command after which makes sense.

The issue with my approach I noticed is that by uninstalling in this fashion it leaves the tasks in the FOG task list as still running long past completion. I can of course go and manually cancel/delete them, and all is fine.

In any case, question for you @Joe-Schmitt , and I know this question is the bane of all developers existence and I by no means want you to feel like this is me putting pressure or demands on you, as I am certainly not…

When might you anticipate that the FOG client is updated for PCI/FIPS compliance?

I ask as I am trying to gauge if its worth putting effort in work arounds to my problem or if I should just wait until the FOG client is updated which will simplify my process greatly and no longer require uninstalling the client post deploy.

For what its worth I tried something similar to your suggestion but not as a snapin pack, just 2 snapins and realized as soon as the first snapin ran and rebooted the GPO was in affect and the second snapin couldnt run due to the FIPS issue. The 2nd snapin was meant to act upon a AD account, but could not because of the GPO. At the same time the commands couldnt be done in the first command as the AD account hadnt been logged into yet, thus the registry and dir’s for that user didnt exist yet. Catch 22. I couldnt figure out a way to have the bat act upon the AD users local registry entries without having first logged in as that user and/or without triggering the FIPS compliance causing the FOG client to not work.