Yes we've done silent installations of both WAS and MQ. I'm not sure about the procedure for generating the response files as the teams that look after WAS and MQ had already created them. We just added them into BLPackages along with the binaries and what not for the installs, and then added external commands to run the installers with the silent option and the path to the relevant response files.
Hi - We are also looking to have WebSphere and MQ installations from BladeLogic (via packages). We setup an MQ package, but we are getting complaints from our deployers saying that the job takes much longer through BladeLogic than it does using the old scripted method. The BladeLogic job actually has a script that will copy the binaries from one server to the target server. So it's not actually copying the binaries from the depot. Will we see a significant performance increase if we move the binaries to the depot? In my mind, it's still going to be a file copy, which is what is taking the longest.
The old scripted method they use sets up a mount point and runs the installation directly from there, so there was no copying involved.
We had the same issue. An unattended installation of WAS or MQ isn't necessarily going to be any quicker through BladeLogic regardless whether you copy the file via a script, or add the files to the depot.
To be honest, I'm not sure how mounting the source remotely and installing it from there is going to be quicker either as the same binaries being deployed to the targets are having to make their way from the source across the network.
We pointed out however, that the efficiencies are earned in BladeLogic when you want to deploy multiple WAS or MQ installations at once. I'm guessing using a scripted method, the deployer would still have to do one server at a time more or less.
One way we got around the issue of having everything copied from our main fileserver or datastore was to replicate a copy of the software on our main datastore to geographically located servers in each of our datacentres which also act as NSH repeaters, pxe and tftp servers for BladeLogic. We then setup a server property called LOCAL_DATASTORE_HOST and used an NSH script to set this to be the name of the server holding a copy of the data that was local to the target. As our server naming standard includes characters that can be used to determine physical location this was fairly easy to do. We then just referenced the property in our depots specifying that the location of the source would be ??TARGET.LOCAL_DATASTORE_HOST??.
This helped to alleviate a lot of the problems we encountered when deploying software to targets at remote sites.
Regards - Lee
If you are using 7.4.x you can use the 'network deploy' feature which is similar to what you describe. w/ 'depot software' object types (custom software, msi, rpms) you could define a parameterzied network path (nsh, nfs, cifs) to copy the files from during staging, or actually mount the network path (for cifs and nfs) and run the install directly from there (assuming the target can mount the network path). it's basically what lee describes but baked into the product.
lee - have you guys looked at the 'network deploy' option since 7.4.x came out ?
Yeah I looked into this a few months back, but we had some problems with it. It would work intermitantly and fail for now apparent reason on some occassions. Can't remember the exact details, but we couldn't reliably reproduce it so getting help from support was tricky. I left it in the end as I had other ways of achieving the same result.
What we are doing now however, is deploying WAS applications using BladeLogic. To achieve this, we've created a Custom Software depot, and added it to a BlPackage, we're using the "Copy to agent at staging" option for the Custom Software with a parameterized path (this points to a base directory on a Windows server where all application release files are placed by developers who check them out of version control). Obviously we're still copying the files to the target, but what this allows us to do is make part of the path to the files a local property of the BlPacakge, so we can use it to deploy any application components, simply by changing a "SOURCE_DIR" local property to point to the relevant subdirectory which contains the apps we want to deploy.
Because the directory created on the target is under /tmp/stage/DBKey_of_custom_software_object/ we can guarantee where the files will end up on each deployment, and as part of the install commands of the custom software is a simple shell script which loops through all of the files in this directory and for each one it finds, unpacks it, and runs a python deployment script provided by the developers that actually installs the app into the WAS environment.