Have you though about setting a server property and then building a custom inventory report?
or add this info into the os_config script and include it that way.
I had to something similar.
Use blquery to retrieve SW info and update OS_config to gather for reports.
What OS's are you trying to do inventory for?
I've used server properties which is the only easy way if you want to export as csv and open in a spreadsheet and reported on these which allows you to do a report like:
If you want I'll send you some sample scripts.
Its a shame we can't currently do this with server components and parts. You can get a list of components and if the discovery uses instances then you can get the version in the component name for example - but you can't get much more information into it than that.
modifying os_config and the pdd will let you do the same thing. it handles multi-valued entries much better then the properties and keeps the property dictionary clean :)
The initial requirement from customer was:
all software on all platforms. :)
Now we restricted to:
most expensive software on all platforms.
So it will still have to be all platforms, but only 20-30 software products.
Of course, using pkginfo, or blquery will show only OS installed software, such as Veritas, or HP Openview, and will exclude all the custom installed software (hope you understand what I mean) such as Oracle or Apache, that don't leave any trace in the OS.
For that particular software, we'll have to go for a find script, and we are already able to retrieve relevant information.
Unfortunately, I'll have to fight with RDLs, if I want to populate reports with such information.
Have a look at this script. It does a find for software in an environment based on a series of potential paths that you can try (as opposed to doing a find from '/'). It might be worth giving a shot if the applications you're looking for aren't listed in the standard objects we provide.
appfind_2.nsh 5.3 K
I had a look at the script you provided, and I may decide to use it in the mid-term.
However, at the beginning, the customer is not able to narrow down the list of possible paths for an application, so we'll end up running a "find /".
What we're considering now, is to run a weekly (or monthly) "find /", and then have the script grepping the resulting file.
I'm still open to suggestions about how to report on this custom software (we have many of them: Oracle, Apache, Connect Direct, TWS, $Universe etc.).
We are thinking to build csv files through our script and then populate those csv files to the report server through a custom RDL. Is that feasible, and recommended?
There are a couple options as I see it. If you go the script approach which does a find, you could output the results into a file on the target. Then you could update os_config to cat that file so that it would show up in reports.
The other option would be to have it create a .sig file on the remote host for each app that you find (that's how the script above works). Then what you do is create a Component Template with a signature that looks for that .sig file for each app, and discover it across the entire environment. Then you could just get a report on the # of Components you have for each app. I think I prefer this route, as it allows you to manage each application using a Component Template.
I also prefer the second option.
We're actually already going into this direction.
We're also building extended objects that show up version number and, where applicable, license information.
I would like (actually, I need) to include this information in reports, which is not exactly straightforward, as I understand.
One very inelegant option we were considering for version number (but I don't think we'll go this way) was to create a compliance rule such as: version number should be empty), and then show up a compliance report with all the servers that are non-compliant tho this rule.
We would then have the version number in the "Reason for failure" field.
However, as I said, this looks very twisted, if that's the right word.