Not sure, but at least apache might also install files into /etc. If you call make -n install in the apache dir it will tell you.

To be on the safe side you might for example

* collect all software in a partition you export through nfs. Then you would compile on the source machine once and only do the install step on all the other machines

* do a 'ls -1lR / >/tmp/xyz' on the machine before and after (use a different xyz for before and after) and diff the resulting files. You should get a good overwiev where changes happend

Thanks for the advice jethro.

Not sure, but at least apache might also install files into /etc. If you call make -n install in the apache dir it will tell you.

If it does, it probably does so under /usr/local/etc since my custom apache2 is installed under /usr/local/apache

The tip about ls -1lR is gold.

--

when small people start casting long shadows, it is time to go to bed

In my experience install and copy, especially for a large bundle, isn't reliable. You'd (a) have to do a diff on all directories where files might be found (b) insure that there was no other cause for the differences you find (c) insure that none of data generated by the installation process (e.g. configuration files) contains machine specific or network node specific information). In addition to /etc, some applications place material in various places in /var, /lib, /usr and its subdirectories, /usr/local and its subdirectories, etc, etc. The snapshot approach also presents several maintenance problems. Every time an application gets updated the snapshot has to be regenerated. It is hard to uninstall. Upgrades can be a nightmare because snapshot images are better at adding files than deleting them.

When all software comes from a single source (CPAN, Debian, Ubuntu, etc) then the packaging system can usually handle dependencies. Even CPAN has support for creating a software bundle that can be used to automatically download a bunch of dependencies for your main program.

When software comes from multiple sources things can get a lot more complicated. However, many of the *nix OS (Debian, Suse) provide a way you can download software and bundle it into system supported packages on your own. There are even CPAN modules that can do that (search CPAN for rpm), though I don't know how reliable they are. If at all possible, try to use those packaging systems.

There are also a number of services on the web that purport to multi-source software from many repository and vendor websites. However, I don't think these are likely to meet your needs. The ones I've seen are all for MsWin desktop apps and rely on not-so-reliable techniques like html scraping to guess at the download location.

You may also want to investigate some of the cluster management systems. There are several open source systems available for distributing software and updates over large numbers of look-alike machines. I don't know how compatible any of these are with Apple Xserve, but you can look into Puppet for starters if your are interested.

Another creative solution I've seen to this problem is to bundle the application stack into a "virtual appliance". Instead of installing the applications directly on the machine, one installs the appliance. This, of course, means that all service requests go through a double layer. That may cause an unacceptable performance hit. Then again it may not. Virtual machines these days are pretty fast. You will still need to rebundle and reinstall every time one of the components of the stack gets updated. However, since you are installing a complete self-contained system rather than overlaying a snapshot on an existing system, you will avoid most of the other issues with snapshot generation and updates mentioned above.

In the end you may need to consider writing your own installation script to download and install applications for each machine. I've been on projects where this turned out to be the only viable solution. But this too is fraught with dangers: testing such a script and insuring it is reliable may take as much time or more than hand installing. It also needs to be updated from time to time so that it fetches whatever happens to be the latest version of app X that you have approved. An update feature for security patches is not a bad idea either. As you can see, this quickly turns into an application in its own right.

It might be worth it all the same if you are upgrading repeatedly, scaling up over a large number of machines, or need to factor in time spent on system failures. Manual installation isn't foolproof and it is hard to guarantee uniform installation procedures when software is installed manually. It may also be worth the effort if your solution can be reused to deal with other systems maintenance issues down the road or in other server clusters in your company.

On the other hand, as boring as the idea of manually installing and compiling on each machine may be, it may in fact be the most practical for your organization.

Best, beth

This is a standard unix thing to do, and since Apple are now based around Darwin (a BSD clone) it should be simple (Caveat and full disclosure - not an apple boy, they may have done something to break this model - but its standard under any other Unix).

The following is what I'd do in BSD, Linux or any of the other Unices I've worked on.

Simply create your own stack in /opt directory. You do this using the "configure --prefix=/opt/stackname" option. Which creates everything under /opt/stackname. You end up with an /etc, a /var, and so on, all under you main dir. Then you just copy your stack (i.e. everything under the prefix). Assuming the boxes are genuinely identical then it will be fine.

This is also a good way for making software uninstalls easy - you just delete the ../stackname directory and you know you've got everything. (note though that if you do this you have to treat /opt the way you would /var, i.e. if you normally put /var on it's own partition so that logs (for example) don't fill up all your working space, then you should do the same to /opt)

Also given the next couple of comments I should say that this is, obviously, separate to package management systems.

stevemayes, this is precisely what I was thinking. Since, user installed software, by default, ends up in /usr/local, esp. when using Gnu make and Autoconf, I thought I could just tarball /usr/local and copy it over to the other machines. For subsequent updates, as noted in another reply, I could rsync any updates from the "mommy" machine. In fact, as far as I can see, /usr/local/ ends up getting its own etc, include, lib, var and so on, mirroring the tree under /. My only worry about CPU architecture, (dual core Xeon vs. quad core Xeon), but that seems to be not a problem... after all, I routinely copy regular applications between machines... the only hitch is that one can't exchange applications between PowerPC and Intel.

Perhaps threaded perl might be affected on multicore machines, but that is an area I know nothing about. And, I guess, if I have to ask, I should stay out of that mess completely anyway.

I will go ahead with the above strategy... I will download and compile everything on one server, and when everything is working there, I will tarball/gzip the entire /usr/local/ directory and copy it over to the other machines and test there. If everything works, I am good.

Many thanks all.

--

when small people start casting long shadows, it is time to go to bed

Packages are only part of the solution. Packages don't distribute or install themselves. Nor do they figure out which box needs which package. Instead, you may want to use cfengine which will detect which packages are needed but not installed on a box, then uses yum to retrieve the package from a certral location, and then runs the appropriate package manager to install the package.

That's fine for the first copy, but we use rsync regularly to keep things up to date after you make changes. It will make good use of the network, copying only the changes.

I would suggest using sudo updatedb; locate SomeModule.pm to discern where your site perl libraries are. I would think that if the hardware and OS remain the same, you could likely tarball your site lib and move it over en-masse.

-- Hugh