i think you should use 'automagically', not 'automatically' :)
so how are you getting the software packages and what servers they are needed on? are you getting them from a Patch Analysis Job and then performing some kind of deploy based on the results or are you just pulling down the newer firefox and making the package and pushing it out?
specifically, firefox, some adobe apps and other bits should be picked up as part of a PAJ. that would solve the 'knowing' part. i think you can do a PAJ for just the 'extra' apps (but it's kinda all or nothing).
in 7.4.4/5/6 (forget which) there's an 'auto-remediate' for the PAJ so that might just solve all your problems. just schedule the PAJ w/ the auto-remediate. that should suck down the new version of the app
but if you have apps not covered in the PAJ (really covered by shavlik) we'd need some other way (component + discovery) to 'find' the apps. and we'd need to know where to get the latest copy from. if this is where you're at, we'd need to look at writing up some blcli and an nsh script that would be scheduled in the gui.
Thanks for your response.
Our SOP for now is to only use the Shavlik XML file for Windows patching; I have therefore had to set up my own stuff for 3rd-party applications (Firefox, Adobe, etc...).
I think what I am looking for is a solution like you describe in your last paragraph. As an example, I have a Depot item and discovery/compliance jobs for the latest version of Firefox. What I want to see is a way that I can have all the servers "look at" the depot (for lack of a better way to phrase it), see which applications are there, then check themselves for compliance and sort themselves into static groups accordingly.
Wow, that was confusing.
So for example, let's say I have Firefox v4.1, Adobe Reader v 11.3, and Notepad v37.8. I have the latest software, discovery and compliance jobs, and BLpackages set up for all of those. What I would want to see is an individual server (SERVER1) go out and get a list of the current versions of all the software that I have made available in this context, then check itself to see if it has the software and the version (either via compliance or blquery), and if it has an older version, drop itself into a static group (such as "Needs_Firefox_4.1"). This way, I come in the next morning and just set up the deploy jobs to point at those static groups once I review them.
Am I dreaming? Or would it take more effort to set all this up than it would be just to do it by hand?
Ah - so I wrote this for another customer already. I think this will work for you.
take the attached, put the xml file in the /Program Files/BladeLogic/OM/br/xml/cli on the system you will run the script from.
run it like nsh populateServerGroups ""
Where Template Name is the name of the CT you're using, the Sever Group Root is the path you want your server groups created in.
This should have the logic to do the add/remove into the server group based on if the component exists on the server.
if you run this on windows you should change the line in the nsh script:
so for all of your templates, you can create 1 nsh script object and multiple nsh script jobs, 1 job for each template.
populateServerGroups.zip 5.6 K
Ah, looks good. I set up the script and a script job, but I get this output when it runs:
Error May 5, 2009 1:47:38 PM Failed to invoke the JVM
Info May 5, 2009 1:47:38 PM Could not reserve enough space for object heap
I assume this may be related to the setting you had me change (this is currently running on a Windows appserver against Windows target servers). I cannot find that setting documented anywhere, is there something else I should back it down to?
how much memory do you have in your appserver?
you can try setting it down to 768 or 512. i had some problems w/ one of the blcli commands i use in the script and the number of components that existed per template.
that setting sets the jvm heap size for the blcli for that run only. the default is 128 or 256.