I am writing a bash script to set up a production server. The tasks at hand include compiling software, creating users and directories, copying files over, etc.
I am wondering what other things I should do. Perhaps logging to a file? checking for a 0 exit status? What can I add to actually make this script great and not just "it works" ?
Maybe you should rethink how you deploy your software to the production server:
Compiling software should be done in your development environment, not on the production server. There's no need to install compilers on production servers. And there are a lot of reasons not to do it (mainly security reasons).
Use a package management system to deploy your software. If you're on linux use deb, rpm, or whatever package manger is used by your distribution. This will give you full control on what version is installed, and also provide dependency features.
The package that installs your software should bring with it all the files your software needs (unless these files can be provided by other packages), and also set up users, directories, permissions, and anything else your software needs.
Basically you can write your bash script in the post install and post remove section of the package.
Make sure to test that once installed, the package brings and creates everything needed to run the program, and that uninstalling the package, removes all the files, and undoes what the postinstall script did.
Make sure upgrading the package from version X to X+1 works as expected.
Regarding the script itself. You should of course check for exit status of the commands you run. You can use a Wrapper script so that you don't have to repeat the exit code checking, and logging for each command.
Good luck!
At my work, we have shell scripts to automate pretty much everything when it comes to building a server. The install of the OS is fully automated based on some profiles and whatnots. Patching, adding users, etc, is all scripted to make life easier.
However when we need to deploy an enterprise application, these servers are "application servers" mind you, that is a totally different process. We deal with a totally different set of admins, middleware guys. We provide them binaries that were promoted through from dev, to qa, and then to prod.
Its perfectly normal to automate the setup of the box but you don't want to be "building" applications on a production box. If for anyreason the performance hit any live application would see when the box goes about a big nasty compile process. :D
@Tom: An example of a stable and successful Linux distribution would be Gentoo, where all binaries are compiled on the server before install (no binaries exist in the distribution). It has been used by large production servers such as isohunt.com.
Building binaries on the server is a good idea as it makes sure your binaries are optimized at some level for the host platform, provided the installer provides the correct flags to the compiler.
Having GCC on a server hurt no one IMO :)
@Lars:
You should-
Keep a logging file, with additions to steps needed to rectify errors and move forward.
At the start of the development process, handle exceptions via messages to stdout, and provide for handlers as you test the script.
On the whole, try to ease the work for your user, who really may be unaware of the micromanagement your script performs (copying files, installing daemons, creating filesystems, setting perminssions, blah) and would have only your installer to complete the process successfully.
Testing the script on several systems will make sure it will work