It is possible to script the installation of hardware management agents using the UDA as the source of the code...
and the kickstart file to automate the installation. In this example, I’ve scripted the installation of the HP Insight Management Agents, mainly because that’s the hardware type I run on. However, these principles could be applied to other vendors' hardware agents. Personally, I don’t possess any IBM Hardware or any modern Dell hardware to create a similar script and then test it properly. I would like for someone, using the exact same method below for consistency, to validate/document the process for IBM/Dell servers. This way I can give the sample code to Carl, the developer of the UDA, as a template from which he can automate this manual process for the next UDA release. I am hoping that Carl will be able to write an upload, extract and edit function to the UDA.
Step One: First enable NFS on the UDA
Login to the UDA as root
- Edit the exports file with: nano -w /etc/exports
- Copy and Paste existing line
- Paste and change the path to be /var/public/smbmount/DISK2
- Save the file and exit nano
- Restart the NFS service with: service nfs restart
Be careful with setting RW on NFS exports as it's very easy with the rm command to delete files unintentionally with scripts. I know because I have done it!
I store my ISOs for deploying ESX in a second disk mounted in the UDA. You could use the first disk in the UDA for this purpose, but watch out for space. I intended to also apply patches via this mount point. The first disk in the UDA is not very big and doesn’t have much free space inside it. Initially, I put the source of the agent in /var/public/www/esx which is where the ISOs are mounted, but decided if I also wanted to use the UDA’s NFS service to script the patching of an ESX host, it would be safe to put the patch files in the second disk where I have plenty of free-space.
The reason I share this out as rw rather than ro is I also use this location for storing my ESX patches in the tar.gz format. These get extracted and installed using the %post section of the kickstart script and of course, for them to be extracted properly we need rw on the NFS export.
Step Two: Download Agent, Upload the UDA, Extract/Enable the Input file
- Download from HP’s website the HP SIM Agent, the current version is 7.7.0 and available from here:
- Upload the .tgz file to UDA using WinSCP to /var/public/smbmount/DISK2
- Extract the HP SIM Agent with: tar -xzvf hpmgmt-7.7.0-vmware3x.tar
- Navigate into /var/public/www/esx/hpmgmt/770 and rename the hpmgmt.conf.example input file to be hpmgmt.conf with: mv hpmgmt.conf.example hpmgmt.conf
- Review your settings in the input file which is used to automate the HP SIM Agent installation
Step 3: Modify your kickstart file(s)
- In the %post section where you normally create virtual switches and so on, add the following code
# Connect to UDA Source
service portmap start && service nfs start
esxcfg-firewall -e nfsClient
mount 192.168.3.150:/var/public/smbmount/DISK2 /tmp/udasource
# Copy down the HP SIM to /tmp
# Execute the installer
mkdir /tmp/hpmgmt/770 -p
cp /tmp/udasource/hpmgmt/770/* /tmp/hpmgmt/770
./installvm770.sh –silent –inputfile hpmgmt.conf
# Clean up after using NFS on the UDA
# Unmount udasource, remove mounting point, stop services, close firewall
rm service nfs stop && service portmap stop
esxcfg-firewall -d nfsClient
Basically, the first part of the script mounts the NFS share on the UDA to copy the hardware agent down to the local ESX host. This is necessary because each agent install creates a log file per host. As the NFS is read-only, these log files would not be created properly. Additionally, it would take some work to make a true over-the-network create a log file that held separately for each ESX node you install a hardware agent to. The second part of the script executes the installer silently, and the third part of the script cleans up the system, closing off ports and removing mounting points. You might also notice that the portmap and nfs services are stopped and started in reverse order. This is deliberate as nfs has a service dependence on NFS.