In general, anything you can do in the COS under bash, you can do in %Pre or %Post in reference to shell syntax or shell specific commands. It is when you call on other binaries that may or may not be available at %pre or %post time that you have issues.
A good reference for bash scripting is the "Advanced Scripting Guide", goggle it, and you will see some good information and examples on general bash scripting. Some use 'sh' which is a similar form of script shell, that BASH grew out of.
I tend to write scripts in BASH, then import them into %Post, but I also only do in %Post what I absolutely MUST do. We wrote our own service (script) that runs after the first reboot of the ESX host to do all significant work. This allows for easier creation, testing and debugging, and avoids binding the OS load to the server configuration phases. As you move to more sophisticated methods for server provisioning there are some advantages to separating the initial OS load from the configuration sequence.
General rules for scripting are like programming rules...
Write functions/blocks of code to do real work if you need to do the same work over and over, it means a function is usually a good idea
Write code so only one entry and exit is done, this is a structured coding technique common to any coding environment
Write functions that do simple tasks, and leverage functions to create complex tasks
Write code in a consistent and well understood style
Remember, everyone has their own personal style of coding, so agree ahead of time what that style and approach should be, above all, be consistent
Document your code
These rules may seem a pain, but in a multiple person shop, it pays to follow them.
For example...
mkdir -p /mnt/cdrom
mount /tmp/cdrom /mnt/cdrom
cp -vR /mnt/cdrom/* /mnt/sysimage/tmp
umount /mnt/cdrom
Gets the job done... But...
declare -i STATUS=0
We are creating a directory, mounting it to the physical cd-rom
drive, and copying files, this is only done once for all files on
disc. We are lazy and never delete the directory because it is
toast after anaconda shuts down.
echo "Make Directory"
mkdir -p /mnt/cdrom
STATUS=$?
&& {
echo "Mount Disc"
mount /tmp/cdrom /mnt/cdrom
STATUS=$?
&& {
echo "Copy Files"
cp -vR /mnt/cdrom/* /mnt/sysimage/tmp
STATUS=$?
}
echo "Be nice to Anaconda... If you must"
umount /mnt/cdrom
&& STATUS=$?
}
echo "Result $"
exit $
Tells you exactly where the script may have failed, and tells the next guy that may work on the automation scripting just exactly was expected and why when the script was designed. I am not telling you, in any way that what I said above is 100% perfect, only that a bit of thought and effort up front saves a lot of time debugging and scratching you head lafter.
