(Obligatory link to where I wrote up my experiences)
If it were me, I'd split up the tasks and let different tools handle each stage:
- Debian-installer with preseed to get the disks formatted, the bare OS loaded, and some kind of configuration management software installed.
- Let the configuration management software take care of the rest of the package installations and configuration.
- Make sure you have .deb versions of any custom software you want installed, put them on an accessible web, ftp, or ssh site, and install those via the configuration management software.
Honestly, I'd rethink your position on Puppet (and maybe Chef, but I wouldn't recommend cfengine -- I looked at it in 2007 because I thought it would be easier to get running on Solaris. But as soon as I saw Puppet was comparably easy to set up, I tossed cfengine aside).
You don't have to hand everything over to configuration management software, just what makes sense.
- If all you want Puppet to do is to keep an Apache config file in sync from a master copy, and restart the httpd process anytime you make a new version, it'll do it.
- If you want to ensure that all servers in a particular class have a particular set of packages installed, and be able to change that set in one place and have all those servers install the packages you added to the list, it'll do that, too.
If you wanted to optimize on the least initial pain, then
- Make individual packages for PHP, nginx, etc. and put those in a .deb repository. I can't see any reason to make one giant package.
- Use Debian-installer with preseed to install the base OS plus your custom packages at install time.
For making your own deb files, there are at least two options. Both require appropriate deb-src entries in /etc/apt/sources.list:
- Take the current version of the package from your release, modify its build procedure, and then rebuild.
- Take the current version from testing or unstable, optionally modify its build procedure, and then rebuild.
For option 1, you should be able to do
apt-get build-dep somepackage; apt-get source somepackage to get the build dependencies and sources to any package in your current release. Head into the source folder for the package, and edit
debian/rules with your configuration changes. Edit
debian/changelog to bump the version number higher and add your notes. Then run
dpkg-buildpackage to build the new binaries and sources.
For option 2, it's basically the same procedure, except that the build dependencies may be more complicated to satisfy. Testing or unstable may have a newer version of Boost, glibc, or whatever. Sometimes a package will depend on those newer versions that you don't have. Sometimes you can remove the version number requirement from
debian/control and build without problems. If that doesn't work, then you have to recursively port the build dependencies back to your release.
There's also a chance that your package is already in Debian's backports repository, in which case, you get a newer version of a package ready to install (or modify and rebuild) on your current release. For example, Debian lenny has nginx 0.6.32, but lenny-backports has 0.7.67. Squeeze has 0.7.67, but there's no nginx for squeeze-backports at all.