May 27, 2003
Methods for Maintaining Software Installation
Last week I wrote about the process of gathering the list of Perl modules. Pete writes in response:
I assume you'll be recommending the use of CPAN.pm (ie "perl -MCPAN -e shell") for downloading, compiling, testing and installing the Perl modules. In fact, could even script/automate detection and installation of the necessary modules using CPAN.pm.
The paradigm we've operated under is to compile and build packages on one machine and then distribute across all machines as Solaris packages. Makes it easy to control exactly what is installed on each machine, and quickly determine package versions etc. It is more work initially to build the packages, but the ease and assurance that machines are in sync is worth it in the long run. I've been questioning this approach.
Some questions to defining how to best manage software across machines:
1) Our machines are jumpstarted, using Solaris packages (another reason we put our stuff into packages). Is there a method for executing the CPAN make/make test/make install process from a package install? I believe part of the package install includes the ability to execute a script. What if the machine isn't online when that package is installed?
2) Does the CPAN, or the make install process make it easy to remove the pieces of a particular install? If I need to pull out one module and replace it with a new module (and maybe it's been renamed or relocated) is it possible to completely pull out what was installed during make install? Typically I just make install over the older package, which probably would work but could lead to a less synchronized set of machines. I guess with good documentation the install process across machines could be more controlled.
3) Initially we were using the Sun compiler to build our packages because gcc was still in development for 64-bit compiles. We only had the compiler on one machine, which limited "make" to one machine. We now use gcc 32-bit (even though it now supports 64-bit) so this is no longer an issue. Wonder how much of the decision to build packages was based on having the one compiler.
It seems like more and more I've been coming against questions or proceedures that are simply part of deciding what kind of sysadmin practices I choose and not so much what is right. Somthing feels good about researching all the options, deciding what path works best for our needs and adding it to the unix toolbelt.
Posted by mike at May 27, 2003 3:03 PM