[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

need help in identifying changed files in pacakges, + general pacakging questions

I'm trying to develop a system of identifying all the files belonging to packages
that have changed on a system.

This is very important if you want to save a current configuration.  For example
I go in and tweak various files here and there (init scripts) or change config
files (sendmail, etc...).  I'd like to identify all these and put them in some
sort of archive, so that I can reproduce the state of the machine if I have
to do a fresh reinstall, or transfer the config to another machine.

 At first I thought I could look at the creating time, mod time, but if a
person edits a file, all times will be set to the same.  

By taking a quick look around the /var/lib/dpkg/info I noticed several types of
files that look promising.  First are the md5sum files but:::

# /bin/ls -1 | cut -d"." -f1 | sort |uniq |wc
    212     212    1684
# /bin/ls -1| grep md5 | cut -d"." -f1 | sort |uniq |wc
     72      72     548

not all packages have md5sums.  Maybe md5sums should be generated during the
package installation process if one is not available.  There are also two files
in the 131 dist "comerr2.checksums    e2fsprogs.checksums".  What is with
the different file extension.

Another type of file that looked interesting is the .conffiles but I realized
that for X apps the app-default is usually not included in the conffiles, which
I think they should be, but maybe I misunderstand the role of conffiles.   That
would be isolate the configuration related files from the applications related
files.  For example the XTerm xdefaults from the xterm executable, or the man
page, which should not be changed.  The files that are not suppose to be changed
should be watched with tripwire, if it's not done already.  Any comments?

One possible way of keeping track of modified packages would be to touch
all the files a package with the installation date, and keep track of the
installation date, then you'd just have to look at the dates for the files
to identify whether or not the file was modified since installation or not,
if somebody didn't want the change to be noticed (intentionally) they could
touch the file manually.

Another option would be to set up something along the same line as tripwire
to track changes, but md5sum on /usr would be quite CPU intensive, and would
prevent the SA from circumventing the system easily, which is handy.

Is there any type of audit trail in place for package addition, upgrade, 
deletion?  This is a pretty broad topic, but might as well throw it in 
for good measure.

BTW, I happen to feel pretty strongly about these issues, and having been
an SA for some years, and having to deal with production type environments,
I can say that these issues are also very important to a great many other
people as well.


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: