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.
http://www.openvas.org
- as usual thanks to all of the individuals and groups who purchase and use my goods and services
http://sites.google.com/site/dtbnguyen/
http://dtbnguyen.blogspot.com.au/
- as usual thanks to all of the individuals and groups who purchase and use my goods and services
http://sites.google.com/site/dtbnguyen/
http://dtbnguyen.blogspot.com.au/
