Cft 0.2.1

Cft project watches a system administrator as she makes changes to a system.

  Add it to your Download Basket!

 Add it to your Watch List!


Rate it!
send us
an update
GPL (GNU General Public License) 
David Lutterkort
ROOT \ System \ System Administration
Its basic principle is heavily influenced by Gnome's Sabayon. Instead of the desktop though, cft is focused on traditional system administrators and how they maintain machines, mostly with command line tools.

Cft uses puppet as its backbone for expressing the configuration of a system, and for understanding in greater detail what changes the admin has made to the system. Sites that already use puppet to manage their configuration can easily integrate cft's output into the overall site configuration; for sites that use some other means of configuration management, cft's output provides a complete record of changes made and serves as a good starting point of integrating the changes back into the site's configuration.


In lieu of colorful screenshots, a simple example will explain in more detail how cft works: cft organizes changes in sessions to let the user better indicate what aspect of the system they are fixing (the webserver, the mailserver etc.) A simple session to fix the configuration of postfix and to start and enable the service might entail root running the following commands:

tux:1# cft begin postfix
tux:2# yum -y install postfix
tux:3# vi /etc/postfix/
tux:4# chkconfig postfix on
tux:5# service postfix start
tux:6# cft finish postfix

Note that the user only had to issue two additonal commands to begin and finish the session, everything else in the session is exactly the same as if the changes had been made without cft. The command cft begin postfix tells cft to start a session called postfix, and the last command cft finish postfix tells it to do the final bookkeeping necessary for analysing the results.

Once the commands above have been issued, running cft manifest postfix will print the changes in the form of a puppet manifest:

tux:6# cft manifest postfix
class postfix {
package { 'postfix.i386':
ensure => '2:2.3.3-2'

service { 'postfix':
enable => 'true',
pattern => 'postfix',
ensure => 'running'

file { '/etc/aliases.db':
group => 'smmsp',
owner => 'root',
mode => '0640',
source => '/tmp/cft/postfix/after/etc/aliases.db'

file { '/etc/postfix/':
group => 'root',
owner => 'root',
mode => '0644',
source => '/tmp/cft/postfix/after/etc/postfix/'

This manifest tells puppet that puppet should enable and start the postfix service, and that the two files should be copied from the location mentioned as the source and receive the given owner, group, and mode. cft takes care of copying all modified files into a safe location so that they can be copied off the machine into a central location. The mention of the file aliases.db is somewhat spurious: it gets automatically recreated by the init script for postfix, and cft treats it exactly as if the user had created the file.
To facilitate moving the changes onto a central serevr, cft can also convert a session into a tarball that contains both the puppet manifest and all the files that are mentioned in it, in this case aliases.db and Fancier, more convenient methods of integrating changes back into a central puppet server are planned for the future.



What's New in This Release:

Many unneeded attributes have been removed from the generated manifest. Previously finished sessions can now be resumed (with 'cft begin -r SESSION').
The RPM package set has been pruned to only leaf packages; packages that were updated/installed and depend on other packages that were updated/installed during the session are not included in the manifest.

Last updated on May 9th, 2007

#watch system administrator #guard system administrator #system administration #Cft #watch #guard #system

Add your review!