There's really only 2 options:
1 - setup job routing rules to run the vpc jobs on only 1 appserver that has the vpc installed, and modify the Eos that show the results to point to that appserver.
2 - setup some kind of persistent, shared mount across all the appservers from your file server. This could be done w/ NFS (I think) using the Windows Services For Unix (SFU). Or it can be done by creating a service that runs and maps the shared folder to a disk on each appserver.
On windows, you can use an SMB share rather than NFS if you use the custom-created service that Bill mentions, whose sole job is to map the share when the machine starts.
But my concern about recommending that solution is that it introduces security loop holes because of that service has to be mapped to system in order for no logins to be required or logout issues. Or has someone found another way.
It's maybe a dumb question, but is it possible to instal or use VPC while reffering to the NSH style location?
This way you use Bladelogic functionality and are able to store the data on one machine? Has anyone tried to use it this way? Or has someone already requested an RFE for this?
I really want to have the data on my fileserver . This way, I don't have to foresee additional diskspace on one of the application servers and I'm sure every application server is replacable.
The SMB idea looks like a good option but as Adam mentioned: This implies some security issues.
you can't use the nsh path for this. the vpc is going away soon, in 8.0 redhat and solaris patching were moved back into the product and aix and hpux are on there way back in...
you can setup the shared drive from the file server, mapped by your other appservers.
There IS a way to make this all work on Windows, although not using NSH. It's important to do this as one of things we're looking at in your environment is to remove the need for open RSCD security on the File Server.
Let's talk it through once I'm on site.
a small continuation on this.
John has given me a document to implement patch management on multiple appservers.
It starts by setting up a persistent mount between the machines. I've mounted the folder to P: and started to install the VPC content. The installation fail because nsh does not follow that mounted drive:
WARNING: There was an error in the cli call: Command execution failed. An error
occurred while attempting to copy the file //sc000395/P/patch/aixpu/Scripts/apc
.pl to //ablfileserver.be.srv.dev.sys/D/BMC Bladelogic/storage/scripts/2032161.1
_apc.pl.: com.bladelogic.mfw.util.BlException: No such file or directory;Cannot
access source file "//sc000395/P/patch/aixpu/Scripts/apc.pl"
/P/patch/aixpu/Scripts/apc.pl is perfectly accessible in nsh, but the FQ name isn't.
Has anyone tried this setup before? Are there things to take in account which I've forgot?
All vpc jobs needs access to the installation directory to write data like temporary files or patch analysis results files etc. As such in a multi appserver environment, the only trick is to make this VPC specific directory available to all the appservers in question so that a job running on any of the appservers can read/write this location. The best way I see it to make work will be install VPC on one of the appservers with the physical location existing on that server only and mount it on all other appservers using the service method so that it is available to all the appserver processes. This should be the easiest and quickest way to do achieve this.
This is really hard to do in a windows environment....
I agree with Bill. Using service method in windows to mount a directory comes with inherent persistency issues. Even though a session might survive when setup as a service, you will see frequent timeouts when the application server tries to communicate to the mounted share.This will result in adhoc error messages which are unclear.
hmm ok, that was mentioned to me before :s
The problem is that we don't want to have 1 appserver as a single point of failure for patch management, and we want to have all the patch content on our fileserver, not somewhere on on appserver. For that reason I was trying the setup from John's document. But apparently this has not been done before, or not nearly a solution.
Ok again an update on this. The descision has been made. We'll set up a dedicated application server just for VPC. I have with me a technical bulletin describing how this can be done and it seems quite clear. Just the description about the job routing rules is a bit to limited.
I know how to define job routing rules and it seems to me that most of them contain the word "Patch" in the name. Except for the jobs createb by the team actually doing the deployment. In my opinion it would be best to have a property on the Jobs describing that job is a Patch Management job. Does anybody have an idea how this can be done easily? I can edit the scripts, but that would place us in an unsupported situation.
Is there a possibility to configure such a thing?
You don't actually have to create a new app server to do this. You can just create the job rules to run VPC on only one of your existing app servers. You're right about the name being problematic as a rule creation criteria, so it might be better to create a new property and assign a value to it for the patch jobs. You would need to make sure that people set this property if they create new jobs though.
there should be a way to define the patch payload location to use a nsh path, which would point to the dedicated appserver.
otherwise the property is the way to go for the analysis jobs.