There's too little information to give you much of a handle. For instance, what is considered "installed software"? If I grab some sources from the web (or usenet...), compile them, and store the resulting binary somewhere below my homedirectory, is that "installed software"? Is it "installed software" if it's installed in /usr/local/bin? What if it's in /usr/local/bin, but chmodded 700? If a package installs 50 binaries, are those 50 pieces of software, or just one? But how would you find out? Perhaps you only have to consider software installed using the package manager(s) on the machine - in that case, look up the appropriate commands for the managers. Or perhaps you want to know if certain functionality is available - then you may want to look at autoconf (or something similar).
Should I use OOP?
Whether you use OOP or not isn't an interesting question at this moment. You first have to hammer out the specifications of your problem. Your last question is like I have to design a house. Please help me in designing it as efficient and clean as possible. Do I need a wheelbarrow? | [reply] |
A module file with all the subroutines, while each sub just return true/false for the corresponding software check it performs.
So you want to have a subroutine per potentially installed software package? What about software that's installed, but you don't think to include it in your module? Is it acceptable to only find one-way deltas?
Forgive my pessimism, but that's a disaster. It'll be run forever, but only updated a couple times. And your versions won't be consistently updated across all your servers. Your admin staff will soon replace it, but won't bother turning it off.
You could write a subroutine that's a subroutine factory: creating subroutines for each package on-the-fly, based on some constantly updated master list... presumably a DB table. That would work a lot better, be much more flexible, and stand some chance of being maintained. But it still leaves the problem of one-way deltas.
| [reply] |
I don't usually recommend other languages at PM, but in this case it's more of a product. Have you looked at cfengine, puppet or facter (the last one has a cpan module too). They should do what you want and more, it depends on how far you want to take it. We use puppet at work for server management and once you have taken some time to do the ground work it is a breeze to install x numbers of new modules/packages on the server farm by changing a single class definition.
Confucius says kill mosquito unless cannon
| [reply] |
Since I thought it was a typo and so spent some time looking in the wrong place, it's probably appropriate to mention that the CPAN module marcussen mentions is called pfacter.
| [reply] |
| [reply] |