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:
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.
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.
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.
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.
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.
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
cfmintro, assumptions, overview, examples, design-history