--On 14 September 2005 16:52 -0500, [EMAIL PROTECTED] wrote:
i am relatively lazy and there are a number of configurations (e.g. mailserver, backup server, etc.) which i would like to generate shell scripts for. i have thought about making these scripts for quite a while, but i have been reticent to invest the time required to make the shell script by hand.
It doesn't actually take too long by hand (assuming any nearby 2-year-olds are asleep or busy, and assuming you don't start working in /tmp and then reboot the system having forgotten it gets cleared by /etc/rc...).
Obviously the lack of automation in doing things by hand may slow things slightly, but it can be an advantage in making you consider whether actions are really necessary.
I just wrote a simple install.site to do some basic mailserver setup - pkg_add /some/dir/*.tgz, useradd an admin user, build sendmail .cf, make certs for TLS, blah blah blah - and packed it with some packages, config files, data directories (with permissions set appropriately), some SSH authorized_keys, etc in a site38.tgz. You can put variable names into config files and run them through something like perl -pi -e "s,SOME_DIR,/fs/somedir/`hostname`," to set parameters that you want changed per-machine, and of course you can read input at install-time if you need more information.
I don't think it took longer than, say, 1.5x the time to build one box (admittedly I already knew what I wanted in it as I'd done a similar setup manually recently). Per-machine installs are great afterwards - no messing around. No need to burn CDs, just turn on pxe-boot, run the installer, point it at a local ftp and install all the sets offered (site38.tgz is included by default if present).
I admit I put off doing this for a long time, thinking it would be quite a lot more involved than it was (I often used to dd partitions or whole disks/CF cards when building multiple similar boxes), but the advantages are clear, especially 1. if you deal with >1 arch (just roll a siteXX with the correct packages) and 2. at upgrade-time.
Even for general-purpose machines it's a great help just to pkg_add the things you always want, maybe 'cvs get' a ports or source tree, setup .profiles, etc.
If you can be disciplined enough to avoid changing the production boxes manually but instead update the image (ok, not realistic in every situation, but a good general rule to adopt) you know exactly what's involved to bring up a replacement or upgraded system.
If you've an existing installed system to replicate, diff -r and/or mtree can be useful in identifying which files have been touched (compare an already-configured system with a directory containing just the untarred OS and packages - you could tar xpzf the os *.tgz files, chroot to that dir, then pkg_add what you're using).
