This repository was archived by the owner on Apr 15, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Configuration File Tracking
License
lutter/cft
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
** Read INSTALL first !!
Overview
========
This tool (cft, pronounced 'sift') follows a sysadmin as she makes changes
to the system. Its basic workings are inspired by Gnome's sabayon, a tool
that watches a user make configuration changes to their desktop and
collects them into a reusable bundle. Instead of the desktop though, cft is
focused on traditional system admins and how they maintain machines, mostly
with command line tools. Cft uses puppet[2] 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.
Changes are grouped into 'sessions' to let the admin indicate that they are
fixing the mailserver, the webserver etc. Basic flow is
tux:1# cft begin SESSION
tux:2# cft orig SESSION /etc/mail
tux:3# vi ...
tux:4# cft finish SESSION
tux:5# cft manifest SESSION
tux:6# cft manifest -b myball.tgz SESSION
In full words:
1) Admin starts a session with 'cft begin SESSION', which sets everything up
for watching teh admin perform changes; it also saves some system state
for later comparison by the digest phase. All data about a session is
(for now) stored in /tmp/cft/SESSION
2) Admin then squirrels away original files they find important with
'cft orig SESSION DIR|FILE...' This can be done repeatedly and at any point,
though be careful to not clobber originals after making changes. For now,
original files are not used any further
3) Make changes with whatever tools you would usually make them without cft
4) Finish session with 'cft finish SESSION'
5) Generate a manifest from the session and print it on stdout
6) Bundle the manifest and all needed supporting files into a tarball,
e.g. for upload to a central puppetmaster
Behind the scenes
=================
Cft draws information from two sources: notifications about file changes it
receives from gamin while the admin is changing the system, and structural
differences between puppet resources before and after the admin makes their
changes.
For example, when the admin edits '/etc/postfix/main.cf', gamin tells cft
that the file has changed. When generating a manifest, cft will include the
file and all its current properties (owner, mode, etc.) in the generated
manifest, something like
file { "/etc/postfix/main.cf":
owner => root, mode => 0644,
source => "..location of copy of modified file.."
}
If the admin changes resources that puppet understands at a
deeper level (e.g. users or services), cft uses puppet's understanding of
these resources for the generated manifest. For example, if the admin
enables a service and starts that service with
# chkconfig foo on
# service foo start
the generated manifest will contain a puppet resource of the form
service { foo: enable => true, ensure => running }
Future work
===========
Cft is quite is quite immature at this stage; in fact, it only understands
puppet's user and service type currently. Obviously, it needs to deal with
_all_ of puppet's standard types. It might even be desirable to merge some
of cft's type digestion back into puppet.
A second are that needs improvement is better integration into an admin's
workflow: at present, cft only produces a tarball. If the machine on which
the changes were made is controlled by a puppetmaster, cft should offer
simple mechanisms to integrate the changes back onto the central
server. Suggestions for how that should work from a user's point of veiw
are mroe than welcome.
Legal/License
=============
Cft is under the GPL; the exact license covering all of cft can be found in
the file COPYING
[1] http://www.gnome.org/~seth/blog/sabayon
[2] http://reductivelabs.com/projects/puppet
About
Configuration File Tracking
Resources
License
Stars
Watchers
Forks
Packages 0
No packages published