Re: Holding on
Almost every Linux distribution already includes a built-in way to set up tens, hundreds or thousands of machines with the same initial configuration: its own native package manager!
On a .deb-based Linux distribution (Ubuntu-derived; this technique almost certainly can also be modified for .rpm-based distributions [Red Hat-derived], but I don't know enough about the internals of RPM), you just need to create your own .deb package, which depends on all the packages you want installed. And when this is installed, it will automatically pull in all its own dependencies. (In a really big organisation with requirements for different package sets in different departments, you might want to have something like $COMPANY-base, $COMPANY-sales, $COMPANY-lab and so forth; just make sure the various departmental packages depend on the company-wide base package.)
Begin by creating the skeleton package structure, making appropriate substitutions:
$ mkdir ${PKG_NAME}_1.0-0_amd64
$ mkdir ${PKG_NAME}_1.0-0_amd64/DEBIAN
$ mkdir -p ${PKG_NAME}_1.0-0_amd64/usr/share/doc/${PKG_NAME}
The folder structure under ${PKG_NAME}_1.0-0_amd64 will be copied into the root folder when the package is installed.
Use your favourite editor to create ${PKG_NAME}_1.0-0_amd64/DEBIAN/control:
Package: ${PKG_NAME}
Version: 1.0-0
Section: base
Priority: optional
Architecture: amd64
Depends: build-essential,firefox-esr,libreoffice,vlc,audacity
Maintainer: Julie Montoya <bluerizlagirl@example.co.uk>
Description: ${COMPANY} standard packages
The Depends: line is where the magic is at! Package names should be as you would supply to apt-get, and separated by commas. If you need more packages than you can fit on one line, or a longer description, just indent the second and subsequent lines with a single space.
After the control file, generate ${PKG_NAME}_1.0-0_amd64/usr/share/doc/${PKG_NAME}/README:
This README can contain anything you think you will have forgotten the next time you come to install this.
You can even create ${PKG_NAME}_1.0-0_amd64/DEBIAN/postinst:
#!/bin/bash
# This is a shell script which will be run after everything has been copied to its proper place in the file system
This would be an excellent opportunity to replace any configuration files under /etc/ with some of your own from a folder like ${PKG_NAME}_1.0-0_amd64/usr/share/${PKG_NAME}/etc (which by now will have been copied to /usr/share/${PKG_NAME}/etc). This might not be strictly the proper way to do it (which would be to repackage everything concerned, with different default configs) but it's good enough. Any other scripts you want to place in /usr/bin can of course be placed under ${PKG_NAME}_1.0-0_amd64/usr/bin .
Now you just need to build your package;
$ dpkg-deb -b {PKG_NAME}_1.0-0_amd64
And it's ready for copying to and installing on as many machines as you like!
Even if you need a package that is too new to have been included in the distribution's own repository, that's not a total deal-breaker. Just make your own .deb for it! (Let's call it ${FOREIGN_PKG_NAME}_0.0-1_all -- it should be -all, not -amd64, because it's not architecture-dependent until it's been built). It's similar to the above. Git clone the package source into ${FOREIGN_PKG_NAME}_0.0-1_all/usr/src/${FOREIGN_PKG_NAME}_0.0-1 and use postinst to build and install it -- but be sure to give the right arguments to configure to ensure it installs under /usr and not under /usr/local , because this time you're installing a proper, managed package. So have something like this in ${FOREIGN_PKG_NAME}_0.0-1_all/DEBIAN/postinst:
#!/bin/sh
OLD_FOLDER=$(pwd)
cd /usr/src/${FOREIGN_PKG_NAME}_0.0-1
./configure --prefix=/usr
make install
cd $OLD_FOLDER # tidying up after yourself never hurts
exit
You
should also have a file
${PKG_NAME}_0.0-1_all/DEBIAN/prerm -- this will be run before removing the package, and should make uninstall, make clean and rm anything you created (outside of /etc , which is special; configuration files ordinarily persist even after the package that created them is removed) that wasn't copied directly from your package's own folder structure. But you can get away without it
if and only if you are never going to remove your homemade packages.
Depending how many machines you need to manage, it might or might not be worth creating your own local repository mirror, and/or your own custom installer USB image with the packages you want already on it.