1

If you want to keep for example a build or server system clean, it is very useful to be able to check that all files are present and accounted for by the package metadata. At work we have a very nice tool which, if run without any parameters, simply creates a file with rm/rmdir statements for any and all files/directories not mentioned by any package (excluding some trees like /home). This is different from rpm -V and debsums, which only check the files already mentioned by a package.

Is there a tool like this for DEB/RPM/Ports/other packaging systems? DEB would be the best, but porting from another system (or our own, if nothing else exists) would probably be feasible.

PS: I am not looking for alternative architectures. The issue here is to have absolutely every file on the system accounted for. VMs and such are not applicable.

Improve this question
  • 1
    That seems really dangerous. Such a tool would have to be taught lots more exceptions than user directories like /home. For one, a naive implementation will do the wrong thing with /var/run. Any directory that can contain files not owned by a package would have to be added to the exception list, and there's no standard list that will cover all cases. I might use such a tool for auditing, but to actually let it run blind? You'd be begging for data loss. – Warren Young May 5 '11 at 10:40
  • @Warren: First, of course there are a whole bunch of exceptions, like package configuration files. Second, this is mostly used for stand-alone security-critical servers, so it's important that everything is accounted for. Third, this is used by a bottom-up custom built Linux distribution, so there's no need to cover "all cases". And I never said I let it "run blind" - On a productive system it's useful for admins to detect unsolicited changes, and on a build system it's useful to check what changed. – l0b0 May 5 '11 at 11:15
  • Re: "all cases", that's the sort of thing you implicitly ask for when you ask for an existing tool. Either an existing tool will be written specifically for a different situation or it will be general enough to be applied to any, and so require a lot of customization. Re: detecting unsolicited changes, I think you're barking up the wrong tree. If someone can modify sensitive files on your system, they can hack the package DB, too. This is why the docs for tools like AIDE (serverfault.com/questions/62539/tripwire-and-alternatives) tell you to save the DB to read-only media. – Warren Young May 5 '11 at 13:35
  • Sorry, that was bad wording on my part. I meant accidental rather than malicious changes, such as renaming a sample configuration file to the wrong name. – l0b0 May 5 '11 at 14:30
2

If what you want is a file integrity checker, then RPM will do what you want. rpm -qaV(note the uppercase V). That will go through and check:

  • file size
  • mode(permission and file type)
  • MD5 checksum
  • device number(checks if someone's hiding a file by mounting another partition there
  • readlink path(if the symlink points to a different file)
  • user ownership
  • group ownership
  • modification time

That should be a fairly comprehensive list.

rpm -qa --filesbypkg | awk '{print $2}' will list all the files on the system that have been accounted for.
find / | grep -vf /tmp/files-on-system.txt will find all files on the system that are not in the RPM database. Another way of accomplishing these two commands in one command would be rpm -qf 'find /'#replace single quote with backtick NOTE: This will also flag as erroneous files in directories like

  • /dev
  • /home
  • /proc
  • /var/run
  • /var/log
  • /var/lib
  • /tmp
Improve this answer
  • Nice, -qa + -qaV seems to do exactly what is needed. I wonder how difficult that would be to port to DEB... – l0b0 May 5 '11 at 14:30
1

On Debian and other systems using dpkg, sort -u /var/lib/dpkg/info will give you a list of all the files provided by a package. A comparison with the list of files actually present on the system reveals a large number of files that aren't provided by any package. This list is from a quick glance at one Debian squeeze machine and is by no means exhaustive.

  • The obvious suspects: /etc, /usr/local, /opt, /var, /home, /srv, mount points of all kinds.
  • A number of symbolic links that are created by package installation scripts. Often this is because the file used to be in a package and has now been replaced by an alternative: first the new package is unpacked, then the old package it replaces is removed, and finally the new package's postinst script creates the link.
  • A few uses of dpkg-divert.
  • In /boot, initrd-* (automatically regenerated from the installed kernel and extra modules), and bootloader files (/boot/grub/*).
  • In /lib/modules/*, module dependency files and symbol maps, and automatically-compiled modules (from dkms).
  • Various non-redistribuable content that is downloaded from its only authorized source when you install the package. Most of it is documentation, there are also a few fonts.
  • X11 font incides in /usr/X11R6/lib/X11/fonts.
  • CUPS backends copied from /usr/lib/cups/backend-available/ to /usr/lib/cups/backend/http/.
  • Various files that are compiled on installation: *.pyc (Python), *.elc (Emacs), *.dll (Mono), …
  • Generated documentation indices in /usr/share/doc/HTML (from dhelp).

If you want to account for every file, you'll have to track their history. To put it another way, to pass an audit, you can't just show the files you have, it's also up to you as the audited to show proof of validity for each file.

The classical approach is to use a tool like tripwire, which alerts you when a file changes. If you're after something more powerful, that lets you keep track of changes, this is exactly version control. Debian provides turnkey version control for /etc via etckeeper. It's not part of the default installation (unfortunately). Install the package, select your favorite version control system in /etc/etckeeper/etckeeper.conf, and run etckeeper init. All changes under /etc will be committed automatically every night and before and after running apt-get or other APT front-ends; you can disable these auto-commits to force the administrator to run etckeeper commit manually (and enter a log message).

Improve this answer
0

If you really want a clean, consistent build system, you might be better of with filesystem snapshots such as what LVM offers. You can install a system with file systems like /usr on LVM. Then you can create a snapshot of any file systems you want to restore to their original state via the lvsnapshot command. You can mount these snapshots as writeable in place of their normal mounts. When you want to revert to the earlier state, just umount, delete, and re-create the snapshots, and mount the new snapshots again. If you want to keep /home or other file systems at their current state, you can put them on LVM, but not create a snapshot for them.

Another approach I use when testing software deployments or custom installation disks is to use a virtual machine like VirtualBox or VMware workstation. These can take whole disk snapshots an restore them on request. It also has benefits like pausing the machine while the host reboots. Once the virtual machine is started, it resumes from the state it was when paused. VirtualBox, in particular, can take multiple disk snapshots any revert to any former snapshot while still retaining them. You could go between two or more lines of snapshots if needed.

Improve this answer
  • This is not applicable. I asked for a way to verify that the package metadata corresponds to the reality on disk. – l0b0 May 5 '11 at 11:21
  • @lObO To be fair your question is not entirely clear. You specifically mention an example your question that this is a much better replacement for. Rather than running a script to generate an rm list to return a system to a known clean state, snapshoting would be a much better solution. Based on your input it is worth proposing here particularly for anybody who might come along with the idea of doing something similar. If you have reasons to persist with your architecture fine, but lots of people think they want to do this when really they need to be doing something else. – Caleb May 5 '11 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.