CFM Examples

These cover only a minimal set of functionality but should demonstrate some of the commoner functionality and provide help in getting started. You are advised to read cfmintro, assumptions, cfmdb, and cfm man/html pages in that order.

Having been duly advised, here are some examples:


INITIAL CFMDB SETUP

  1. Install cfm:      rpm -ivh cfm-*.rpm
  2. Define CFMROOT:   export CFMROOT=/cm/cfm
                 or:   setenv CFMROOT /cm/cfm
  3. Make the dir:     mkdir $CFMROOT 
  4. Create the cfmdb: cfmdb --initdb
  5. Populate cfmdb:   cfmdb -ira
  6. Add hosts:        cfmdb -ih <host>

  You now have a functional cfm installation.
  You really should read the man/html pages.

  Step 4 above creates the $CFMROOT/CFMROOT admin dir and copies five 
  template config files from /etc/cfm/ into it. You can read doc in
  these files for details.

  Step 5 uses info from the rpmdb to create an entry in the cfmdb
  for each config file installed as part of an rpm on your host.
  The name of the rpm owning each config file is used as its set tag.

  Step 6 adds your host to the hostsets list in the cmfdb and adds an 
  entry in the cfmdb tagged with your hostname for each of the
  host specific files identified in $CFMROOT/CFMROOT/hsfiles.
  NOTE: The daemon symlinks are also initialized by step 6 using your
  hostname as the set tag. Tho sometimes this is a catch-22, before
  performing this step it is advisable that you insure the symlinks
  are correctly set. Use of the chkconfig cmd is recommended. See
  chkconfig manpage for details of using `chkconfig --list', and
  `chkconfig <daemon> reset'. You will need to execute this cmd on
  each host that is to be added to the cfmdb. It captures the host
  specific files on the executing host.

  NOTE: Older version of the OS typically required running 
        rpm --setperms dev
        rpm --setugids dev
  after initial installation to restore mode and ownership on the /dev
  dir files to those specified in the rpms. This has never caused a 
  problem on any system in my short years of using it. Your mileage 
  shouldn't vary.


Monitoring

The default cfm installation will perform a set of three scans on a daily basis under cron control. The three scans are:

   cfmhs .;   - host relative
   cfmds .;   - database relative 
   cfmvs .;   - file params verification

 Read the results of all three scans will be found in $CFMROOT/status
 in text files <hostname>_[hdv].

 All three of the scans will detect changes in file content.
 The database relative scan will detect files missing from the host.
 The host relative scan will detect new files not yet under cfm control.
 The file params verification will detect changes to ownership/permissions.
 You may also execute these manually. The first two exeucte in about
 one minute, the third in about 10 min.

You may use the `cat' cmd to examine the output of the individual scans. They contain a list of filenames which produced errs during the scan and a summary line.

 To see a summary of all the scans after the cron job completes execute 
   cfmsr $hosts
 where $hosts is the list of hosts in your cfmdb.
 This will display the summary lines for errs detected by all 3 scans
 on each host.

 [root@dante status]# cfmsr $hosts
 ================  DATABASE relative reports  ============================
 ==    Errs reported here are for missing files or uncaptured changes.
 ## 000803 dante      cfmd report:  chkd     844 files,  found      1 errs
 ## 000803 moses      cfmd report:  chkd     811 files,  found      0 errs
 ================  HOST relative reports  ================================
 ==    Errs reported here are for uncontrolled files or uncaptured changes.
 ## 000803 dante      cfmh report:  chkd     777 files,  found      1 errs
 ## 000803 moses      cfmh report:  chkd     779 files,  found      1 errs
 ================  VERIFY (filtered) reports  ============================
 ==    Errs reported here are for uncontrolled changes to file params.
 ## 000803 dante      cfmv report:  chkd   72434 files,  found      2 errs
 ## 000803 moses      cfmv report:  chkd   66469 files,  found      4 errs

 Here:
 The database relative scans shows 1 altered file on dante.
 The host relative scans shows 1 altered file on dante and 1 on moses.
 The verify scans show 2 errs on dante and 4 on moses.


Analysiis & Repair of cfmhs & cfmvs errs

Use `cfmefl' to extract the list of filenames with errs from the database relative scan's log for dante. Use the list as args to the cfm cmd with an update option. Cfm will display a diff for each err and prompt for your choice of corrective action.

 [root@dante status]# cd $CFMROOT/status
 [root@dante status]# cfm -u `cfmefl dante_d`
 ## s:dante,h:dante  r:/cm/cfm61/Linux-2/etc/aliases,v
 125c125
 < other:               rsmith,tbrown
 ---
 > other:               rsmith,tbrown,joe
 ###-- s:dante,h:dante r:/cm/cfm61/Linux-2/etc/aliases,v
 --- ci|co to/from aliases,v [ci|co|n](n) ?: 

The /etc/aliases file on dante has had `joe' added to the `other' alias and the implementor failed to check the change in to cfm. That action can be taken now at the prompt by entering `ci'. Alternately the previous file can be restored from the cfmdb by indicating `co' at the prompt. The 3rd option, `n', which is the default is to do nothing.

 --- ci|co to/from aliases,v [ci|co|n](n) ?: ci
 /cm/cfm61/Linux-2/etc/aliases,v  <--  aliases
 new revision: 1.1.4.14; previous revision: 1.1.4.13
 enter log message, terminated with single '.' or end of file:
 >> add new associate joe to alias other
 >> .
 done
 ==========================================================================
 ## 000803 dante      Summary Report:  chkd       1 files,  found      0 errs

Here the sysadmin has uploaded the change to the cfmdb and added an appropiate note. All such notes can be examined using the the `cfm -l' cmd. Cfm now indicates the file is in sync with the database. If there were other errs the sysadmin would be prompted in like fashion, once per file. The procedure may then be repeated for the dante_h list; errs fixed while processing the first list will be skipped with an ok report.


Analysis & Repair of verify errs.

Examine the cfmvs scan.

 [root@dante status]# cat dante_v
 SM5....T c /etc/sudoers
 .M.....T   /usr/share/pixmaps/gnome-gimp.png
 =========================================================================
 ## 000803 dante      cfmv report:  chkd   72434 files,  found      2 errs

These errs indicate unacceptable changes have been made to 2 packaged files. The report indicates the size, mode, checksum, and timestamps have been altered on /etc/sudoers. Cfmvs uses the `rpm -V' cmd and filters the output to eliminate reporting of changes that are acceptable. Since /etc/sudoers is a config file (indicatd by the c in the rpm -V output), the S, 5, and T would be filtered, but the mode change is unacceptable and was not filtered. See /etc/cfm/cfm.cf for filtering details.

Examine /etc/sudoers verify err with cfmugm.

 [dmetz@dante status]$ cfmugm /etc/sudoers
 /etc/sudoers
  S: 294 679
  T: 945191263 968855049
  5: 491b3f2a66cfd92d861e2dc0262aadbe bf1a4b511bc907589a1c80696c64f33a
  M: 0100440 0100640

This indicates the mode should be 0440 vice 0640. Use cfmugm to restore it.

 [root@dante status]# cfmugm -m /etc/sudoers

And then check the result.

 [root@dante status]# cfmugm /etc/sudoers
 /etc/sudoers
  S: 294 679
  T: 945191263 968855049
  5: 491b3f2a66cfd92d861e2dc0262aadbe bf1a4b511bc907589a1c80696c64f33a

Examine the /usr/share/pixmaps/gnome-gimp.png verify err with cfm

 [root@dante status]# cfmugm  /usr/share/pixmaps/gnome-gimp.png
 ### /usr/share/pixmaps/gnome-gimp.png[0] rpmdb internal conflicts follow:
  [1]
   T: 949953314 952528496
   M: 0100755 0100644
 /usr/share/pixmaps/gnome-gimp.png
   T: 949953314 952528496

This indicates the 1st rpmdb entry [0] conflicts with the 2nd [1] in the timestamp and mode fields. And that the installed file has an altered timestamp relative to the [0] rpmdb entry. The installed file can NOT be changed by cfmugm to make the mode agree with both the [0] and [1] rpmdb entries. This is a packaging err. The system admin has two choices: he can leave the err and ignore it during his daily review; or he can set the /etc/cfm/cfm.cf filter to block reporting the both the mode and timestamp err. In either event he should report the packaging err to the respective packagers of the rpms so they can resolve the conflict. If the filter is adjusted the system admin needs to re-enable the filter after the conflict is fixed by the packagers.


Summary

In summary, it takes one cmd to display the presence/absence of errs for all hosts on the net. To correct the errs it normally takes one additional cmd per scan per host which yields a display with detailed diff info about the change and a prompt to select an appropiate action for each err. Filtering may be used to accomodate specific errs which are not to be corrected for some reason. Ususally verify errs for non-config files are corrected by replacing the packages.


cfmdb statistics

You may ask the cfm database what it contains.

 [root@dante status]# cfmdb -qch
 ## cfmdb counts -- sets: 208,  rcsfiles: 1015,  file ver instances: 4567
 borg ref borg-pnp borg met smp <rpm> all dmetz
 vader ref vader-pnp vader met <rpm> all dmetz
 dustpuppy ref dustpuppy-pnp dustpuppy met smp <rpm> all dmetz
 deathstar ref deathstar-pnp deathstar met <rpm> all dmetz
 snowcrash ref snowcrash-pnp snowcrash met smp <rpm> all dmetz
 darth ref darth-pnp darth met <rpm> all dmetz
 jedi ref jedi-pnp jedi met smp <rpm> all dmetz
 master ref master-pnp master beomas smp beowulf apache <rpm> all dmetz
 mcfarland ref mcfarland-pnp mcfarland met <rpm> all dmetz
 zig ref zig-pnp zig met <rpm> all dmetz
 jabba ref jabba-pnp jabba met <rpm> all dmetz
 monet ref monet-pnp monet smp <rpm> all dmetz
 lassen ref lassen-pnp lassen smp <rpm> all dmetz
 larson ref larson-pnp larson met smp <rpm> all dmetz
 mosb ref mosb-pnp mosb met <rpm> all dmetz
 yoda ref yoda-pnp yoda smp met apache <rpm> all dmetz
 taz ref taz-pnp taz met <rpm> all dmetz
 dante ref dante-pnp dante <rpm> all dmetz
 itchy ref itchy-pnp itchy smp <rpm> all dmetz
 scratchy ref scratchy-pnp scratchy <rpm> all dmetz

 Looks like 
   208 sets       roughly corresponding to the number of rpm pkgs
   1015 rcsfiles  these are the rcs versions files. One per filename.
   4567 file version instances.
 This data is used by 20 supported hosts


See Also

cfmintro, assumptions, overview, examples, design-history