Thomas Ribbrock <[EMAIL PROTECTED]> writes: > I have a question on my mind: What do ye folks out there use as a system > logbook? What I mean is something to keep notes of what RPMs you installed/ > upgraded/removed (and when), which configuration files you changed, etc.pp. > - basically notes how you keep the system running.
I use two techniques, one home grown and the other makes use of a complex tool called `cvs' Home grown: Consists of homeboy scripting that allows me to easily write short segments of info with special headers and footer to several specific files. Works like this: My scripting allows me to type a command in an xterm `keyw -i "Important words and identifying phrases" <enter> After pressing enter my script prompts me for the body of my comments if needed. >>> User In put here <<< Here I type any information or changes I've made in summary. Then press ^d. When ^d is pressed an exit `trap' writes the special format around my input. So I end up with a segment like this written to file: Keywords: Important words and indentifying phrases CURRENT_DATE "Any information I typed in gets positioned here on as many lines as necessary" && The segment is closed off with a double ampersand. The above segment is written to specific log file in the format shown. So that log file contains may such small segments. My scripting also allows me to quickly search this file for keywords in the keywords line and returns any segments with that keyword present. Can also be searched by date. The sripting makes heavy use of the unix util awk. And is suprisingly fast and efficient. That technique handles my observation and personel notes about stuff. I can make the basic script available on a web site if anyone is interested. But understand, it is not a polished professional piece, more a homegrown working script. It does some half assed built in documentation. CVS technique: IMPORTANT CAVEATE: Only try the following technique after extensive experimentation with `cvs' to ensure you understand how it works before applying this technique to important config files. I use `cvs' (Concurrent Versions System) to keep track of important config files. `cvs' is a fully developed complex system designed to keep track of changes to many files in one place. It requires some study, but once you have the basic idea you can use it to keep track of changes and allow referencing past settings in earlier versions. It works like this for me: (See `info cvs' for details) I setup a local cvs repository on one machine, building an internal file system in it that somewhat mirrors my install. Just enough to have similar directories to hold the base documents that resemble my install. Here, I mean a base (known as cvsroot) with subdirs resembling my install: cvsroot/machine_name/etc cvsroot/machine_name/home/$USER cvsroot/machine_name/root/bin And a misc directory to hold configs that are from unusual places (not /etc) cvsroot/machine_name/misc In this repository I keep the actual config files under cvs control. The details of doing this are lengthy but only need be done once or as needed after that. (See `info cvs' for full instruction look for `import' ) Then one `checks out' a working copy of the cvs structure and files. `cvs checkout MODULE_NAME <==(machine_name in my setup) This checked out module is then what houses the real config files. I place symlinks in the OS file system pointing to files inside the checked out module. NOTE: Do not do the above unless you understand how cvs works So things like /etc/fstab, /etc/profile or /etc/syslog.conf are really symlinks to the checked out working config file in cvs. lrwxrwxrwx [...] /etc/fstab -> /home/reader/t/209/etc/fstab lrwxrwxrwx [...] /etc/profile -> /home/reader/t/209/etc/profile lrwxrwxrwx [...] /etc/syslog.conf -> /home/reader/t/209/etc/syslog.conf If I edit one of those I'm really editing the checked out cvs copy. After a series of edits or important single edits one must commit the changes by issuing a command like `cd MODULE_NAME;cvs commit', cvs then presents you witn an interface that allows you to commit them to cvs control, make comments to a log if you like etc. Once commited cvs allows an easy and accurate way to view earlier versions or quickly compare any earlier version with the current version. Any version with any other version etc etc. This adds some tedium to making config changes to be sure, but is one very good way to have a really good record of what has been done or changed. One learns after while when it is important to `commit' and when its ok to be lazy. As I mentioned, cvs is a complex program and requires some study and experimentation. I don't recommend actually symlinking any thing as described above until you fully understand how it works. One can do the same thing and keep config files where they belong, it just means an extra step of copying the config to your working cvs module and committing it. _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
