If you've ever been involved with Linux Server Administration than you'll be more than aware of the many and varied automation/configuration options out there such as 'Chef', 'Babushka', and 'Puppet'. I've recently been working on similar technologies but to better comprehend and implement them I've had to review how the current systems work and their capabilities.
'Puppet' seems to operate in a client/server architecture using so called 'manifests' which are basically a set of instructions pertaining as to what actions you would like to complete. For instance, the remote installation of a package, the creation of a file, the setting of a certain set of permissions and so on. The 'manifests' themselves are then compiled (checked for syntax and other errors) and then applied to relevant 'nodes' within your network. Due to its relative maturity it is often available in most of the popular distribution repositories.
'Chef' has obviously been more Debian orientated. It took a while before I actually found a set of RPMs for my system. Prior to that though, I tried creating RPMs using the GIT repository with a set of autobuild 'Ruby' scripts. However, due to the state of the respositories of the time the build seemed to be broken. I used this as a learning opportunity with regards to RPM packaging (I used to create DPKG packages years ago for another project and have done some minimal RPM packaging. DPKG are basically 'ar' and RPM are basically 'cpio' archive files respectively if you're curious (much like the ZIP and other archival format)). I didn't do any research prior to testing my theories prior to test my problem solving abilities. Basically, symlinks aren't a viable means of dealing with naming issues in packaging. Copying files/directories (though this would violate best practice) and changing of version strings in the SPEC file are the more 'valid' option. As indicated in the SPEC file itself RPM is very 'Makefile' like in the way that it is structured. In fact, if you've ever written a 'Makefile' you'll be very much at home. Use 'rpmlint' in order to check for possible problems, 'rpmdev-extract' to extract a SPEC file from an existing SRPM, and 'rpmbuild' with relevant options in order to build an installable RPM.
Obviously, I found a relevant repository later on but it was very interesting getting a better idea of the process of creating RPMs. Check out 'alien' and 'checkinstall' if you have time which, by the way is an easy manual Perl install if you can't find the required package for your distribution. There is a web based interface that seems fairly sparse, a Command Line Interface (CLI), as well as what seems to be an extensive set of online 'recipes' to allow for all sorts of remote configuration, with support for Perl as well as support for automated provisioning of servers. Note that this extra functionality seems to come at the cost of some simplicity. There are a myriad of tools that are used, certificate systems that need to be setup, and unlike 'Puppet' you will definitely need to read through at least the Quick Start documentation in order to use it. Even then, the instructions make extra assumptions... Also, as with any other large, complex Open Source project its in constant state development and may have 'issues' from time to time.
'Babushka' seems to be a work in progress and feels like a stripped down version of a more complete configuration management system. Even the documentation is incomplete at this stage. However, it deals with most of the more important issues such as remote installation of packages, dependencies, and remote configuration.
If none of these options appeal than its fairly easy to build a custom configuration/automation system using Python's 'paraminko', Perl's 'Net::SSH', and Ruby's 'Net::SSH' libraries.