Here are some more tips and tricks for those who use Deployment Solution for Dell Servers 3+ to manage their Dell Server hardware. This article builds on its predecessor, providing more shortcuts and clues on how to make your job easier as an IT manager over Dell systems.
Tip 1) Use (w)logevents and alogs for debugging.
Nearly all scripts bundled with Deployment Solution for Dell Servers utilize the logevent messaging mechanism. This is what allows you to see the progress through the DS console and allows scripts to give warnings or fail gracefully when a problem occurs. If you know how it works, you can use this tool to help debug your own scripts, or locate problems that you may run into while using the prebuilt scripts.
Using Logevent:
Let's learn by an example using the Linux preboot:
logevent -c:255 -l:3 -ss:"Script starting."
Explanation:
The -c: parameter indicates what the return code is. For instance if you had just run a utility and are logging a message, you would pass in the return code from that utility using the -c: switch. This return code then appears in the status detail.
The -l: parameter indicates the severity of the message. Severity is defined as follows:
1 = Critical (produces a red X in status detail)
2 = Warning (produces a yellow triangle in the status detail)
3 = Information (produce a blue "i" in the status detail)
The -ss: parameter is for passing the actual message enclosed in double quotes.
Note: If the Dell environment has been set you may substitute "logevent" with the environment variable "$ALOGEV" so the call will appear as follows:
$ALOGEV -c:255 -l:3 -ss:"Script starting"
Passing messages is nearly the same in WinPE:
wlogevent -c:255 -l:3 -ss:"Script starting"
and the equivalent message using the environment variable in WinPE is:
%ALOGEV% -c:255 -l:3 -ss:"Script starting"
Note: You may see other variables such as %DFN_ERR_FILE% or %DFN_LVL_WARNING% in the Dell scripts. These are merely for ease of reading, and do not necessarily have to be used. See setdell_WinPE.bat for explanations on these variables.
By placing calls to logevent (or wlogevent in the case of WinPE) throughout a script you can provide feedback, and easily see where your scripts are failing.
Using alogs:
The term "Alogs" refer to the logs located in the Dell\alogs folder. They are arranged by machine ID (as determined by DS). To write to alogs from within a script, script the following for Linux:
echo -e "Script Starting\r" >> $DFN_LOG_FILE
or for WinPE:
echo Script Starting >> %DFN_LOG_FILE%
If you are not running under the Dell environment, or the DFN_LOG_FILE variable is not populated you can set the DFN_LOG_FILE variable as follows for Linux:
declare -x DFN_LOG_FILE=/mnt/ds/Dell/alogs/%ID%/log
or for WinPE:
set DFN_LOG_FILE=%share%:\Dell\alogs\%ID%.log
Logging to alogs is very useful if you need to record multi-line information such as the contents of a file. You can also pipe the output from utilities using the >> operator.
To view the logs merely browse to the Dell\alogs folder, and open the file that corresponds to the machine you are interested in.
Tip 2) Modify apply_dup.sh so you don't get a reboot when when a DUP doesn't apply.
Beginning in Deployment Solution for Dell Servers 3.0 SP1 it became possible to apply Dell Update Packages (DUPs) in the Dell DUP Linux preboot allowing you to upgrade firmware before deploying an OS. DUPs are downloaded through the Configuration Utility (available under Tools->Dell Tools from the console) and then the "1.5 Apply Dell Update Package" job is run from the "Pre OS-Deployment Jobs" folder. The default behavior of this job is to search for a DUP that applies and run it. If there are no DUPs that apply, it reboots and returns the machine to automation. If you are unsure exactly which DUP to download, and would prefer to have this job wait in automation on failure instead of rebooting you can modify Dell\ascripts\Linux\apply_dup.sh as follows:
Go to line 88 and find the if statement:
if [ "$RETURN_CODE" -ne "0" -a "$RETURN_CODE" -ne "1" ] ; then
$LOG_EVENT -l:2 -ss:"None of the downloaded DUPs could be applied"
RETURN_CODE="0"
fi
Change the line:
RETURN_CODE="0"
to
RETURN_CODE="5"
This will cause the job to enter a wait state if no DUPs could be applied, allowing you to download a different DUP using the Configuration Utility, and run the job again. With this modification, a reboot will only occur when the job was successful.
Tip 3) Modify FreeDOS image to automatically reboot and prevent getting stuck in an unmanaged state.
Sometimes when PXE servers are under heavy load, a server can "miss" a PXE boot and try to boot from the hard disk. If this happens to occur while performing a windows scripted OS install using the Linux preboot, your machine can get hung in an unmanaged state. You know this has occurred if your machine hasn't made any progress in the job for a long time, and when you go to the machine to see what's wrong you find it waiting at a DOS prompt.
This problem can be easily be solved by modifying the FreeDOS image that gets laid down to automatically reboot if it ever gets booted directly and not as part of the job. We can do this using the image explorer.
Step 1: Launch the image explorer by going to Tools->Image Explorer in the DS console.
Step 2: Open the following image: [Deployment Share]\Images\FreeDOS.img
Step 3: Open the file "fdconfig.sys" using notepad.
Step 4: Add the following line to the end of the file:
SHELL=C:\COMMAND.COM /K C:\reboot.bat
Step 5: Save the file and close notepad. Make sure that the file is updated in the image (you should be prompted).
Step 6: On your desktop, create a new file called "reboot.bat" and put the following lines in it:
@echo off
ECHO G=FFFF:0000 | C:\DOS\BIN\DEBUG.COM
Step 7: Save the file, and add it to the image by right clicking the area below KERNEL.SYS and clicking "Add File". You may also drag and drop it. Your modified image should appear like this:
Step 8: Save the image and close image explorer. You're done! From now on if machine miss their PXE boot after laying down this FreeDOS image during a scripted OS install using Linux, the machine will automatically reboot and try to PXE boot again.
Tip 4) Make Power Control Discoveries easier by utilizing broadcast ping for IPMI devices.
Deployment Solution for Dell Servers utilizes ipmiutil, a free utility used to contact devices that support the IPMI protocol, in the case of Dell, the Base Management Controllers or BMCs. These utilities are used to discover and send remote out-of-band power control commands to your servers.
If you have a large operation, discovering your BMC devices can take awhile, especially if you are searching a large range of IP addresses. If you want to have a better idea of what addresses your BMC devices are running on without having to wait for an exhaustive discover, use these few steps to create a "broadcast ping" script giving you near instant feedback on what BMC devices are operating on your network.
Step 1: Open File explorer and browse to [Deployment Share]\Dell\atools\power\ipmiutil
Step 2: Make sure your ipmiutils are up to date. To do this go to: http://ipmiutil.sourceforge.net and download the latest win32 version (the link is on the left-hand column). Copy the files contained in that zip file into the folder you just opened. Doing so will overwrite nearly every file within that folder.
Step 3: Make sure a file called "idiscover.exe" is present. If it isn't, and you have updated your copy if ipmiutil, then this article must be outdated. You can try using an older version of ipmiutil, but you should use at least version 2.1.
Step 4: Create a new file and name it broadcast.bat. Copy this script into it:
@echo off
idiscover.exe -a -b 192.168.255.255
pause
Step 5: Note the address in this script "192.168.255.255". This represents the subnet you want to discover. Replace this value with the desired subnet you want to cover with your broadcast ping. For instance, 192.168.255.255 will cover addresses 192.168.0.0 -> 192.168.255.255.
If you are unsure of what to enter, open a command prompt on your DS console and type ipconfig. Look at your IP address and your subnet mask. For each octet that is a "255" in your subnet mask, enter the octet of your ip address. For each octet that is a 0 in your subnet mask, enter a 255.
Step 6: Save the batch script and close notepad.
Step 7: Double click the script to see a summary of the BMC devices on your network.
You can now use this information to enter narrower ranges for your Power Control discoveries. You may even use this command to write a bash script to monitor your BMC devices.
Conclusion: As always, comments are welcome. Share your experiences, tips and tricks.