In each of these roles, one of the aspects of keeping up with the product is evaluating it for myself. In engineering I also did quite a bit of Quality Assurance (QA) testing as well. David in his comment asked if The Zone Manager could be used for QA testing. I responded that The Zone Manager is an ideal tool for that very purpose.
For this post, I thought it would be cool to give you a basic QA setup script that I have used to test the zip install, CLI setup and web admin setup of DSEE 6.2. With the following invocation of The Zone Manager, I add a sparse zone named dsee, disable all un-necessary services, setup TCP/IP and name services, read-only mount /data, remotely install tomcat5 from Blastwave, and finally runs my ds setup script.
# zonemgr -a add -n dsee6 -z /zones -P sundsee6 -s lock \Note that the ds1 parameter passed to the script is the instance name given to the ds instance setup by the script. Also sundsee6 is the password given for the DSCC console and the rootdn user (cn=Directory Manager)of the directory server instance.
-G tomcat5 -I "192.168.0.10|bfe0|24|dsee6" -r /data \
-C /etc/resolv.conf -C /etc/nsswitch.conf \
-X "/data/scripts/dsSetup.sh ds1 sundsee6"
The dsSetup.sh script installs DSEE6 from the zip file located in /data/images, sets up a directory server instance named ds1, and sets up the Directory Service Console (DSCC).
Once dsSetup.sh finishes running, you can login to the DSCC via the URL: http://192.168.0.10:8080/dscc
Here is a screen shot of the DSCC login page.
Here is a screen shot of what it looks like once you have logged in.
There are lots of great things to see in the new directory console. However, one of my absolute favorites is the ability to see the replication topology. Kudos once again to engineering for that tremendous feature.
The value of zones and The Zone Manager relative to software quality assurance is that you can in a repeatable and automated way create a fresh new image of Solaris configured to your specifications, install your product and test it any way you like. Tear down the zone and repeat the process for every build of your software product. Some may think this is overkill. However if your software installs packages, changes system configuration files, or in any way doesn't cleanly clean up after itself during un-installation you have no way of guaranteeing that each QA run starts from the same starting point.
David, I hope that you find this QA example useful.