up vote 0 down vote favorite
share [g+] share [fb]

I often seem to be dealing with "almost virgin" Linux installations: VMs that were created for a purpose, used briefly, but after a while we're not sure exactly what's on it.

What I'd like to be able to do is quickly (in keystrokes, if not time) get a quick picture of what's happened on a box since creation. Basically that would mean:

  1. Packages installed since initial server creation
  2. Folders and files created by users (especially in places like /usr/local, but they could really be anywhere).

I'm not sure how to do either of these things. Particularly the 2nd one: what would be a good way to distinguish between files created as a normal part of system activity (logs, pid files...) and those that a user had expressly created?

I tried this*:

find / -printf '%p %u\n' 2>/dev/null | grep -E `users | tr ' ' '|'`

But that turns up a lot of uninteresting stuff in /proc. I guess I could narrow the search to just /home and /usr, but that might be too prescriptive.

Suggestions? Better ways?

link|improve this question
44% accept rate
The VMs are almost all either RHEL or Ubuntu, btw. – Steve Bennett Feb 9 at 23:24
If you are going to narrow your search, I think /etc, and /var would probably be far more interesting locations, if you are generally using packages. Almost everything needs to start, which almost always means there is a script either /etc or in a crontab (/var/spool/crontab). – Zoredache Feb 10 at 0:51
Can you clarify what you mean when you say "files created by the user"? If you're talking about anything they could possibly create (including stuff in their home directories) this becomes a pretty daunting challenge... – voretaq7♦ Feb 10 at 4:45
Let's imagine you created a VM, installed some stuff, did some development work, and configured a few things: Apache, SSH, a bit of Python, etc. And now you want to know everything you did. Not to 100% degree of certainty, but a pretty clear idea: X files in their home directory, Y apps under /usr/local, Z conf files under /etc/httpd/... etc etc. – Steve Bennett Feb 13 at 5:04
feedback

3 Answers

up vote 1 down vote

The fastest (and most robust) way I can think of:

  1. Install radmind or tripwire or something along those lines.
  2. Create a baseline.
  3. Run the tool against that baseline at some later point to see what changed (and if you're using 1radmind`, to optionally revert the changes).

Note that part of (2) is identifying things that you don't care about (things in /proc, /sys, /dev, /tmp, log files, etc.) -- Expect to spend some time on this.

link|improve this answer
Not a bad idea, but step 2 doesn't really work, as the VMs aren't under my control. Is there no way to work out what's happened "since server creation" without explicitly running a baseline at that point? – Steve Bennett Feb 10 at 0:46
Not really -- Detecting changes with either radmind or tripwire requires that you have a baseline (made against a virgin system) to work against. – voretaq7♦ Feb 10 at 4:41
feedback
up vote 1 down vote

You could try using a look like Blueprint to reverse-engineer your systems. By default, it wil pick up package differences and config file changes. It's heavier than a few keystrokes, but is another option.

link|improve this answer
Giving this a go atm. Easy to install and run, but it's showing less changes than I expected, perhaps because I ran the baseline without root. – Steve Bennett Feb 10 at 1:45
My understanding of Blueprint is that it only tells you what changed in files managed by the package management system, which could explain why you're not seeing as many changes as you expect. I could also be entirely wrong though (I've never used Blueprint, only paged through the docs briefly) -- @ewwhite probably knows for sure :) – voretaq7♦ Feb 10 at 4:43
feedback
up vote 0 down vote

If you can get a timestamp of when the box was 'finished installing' (maybe from /var/log/dpkg.log?) you could do a find and find files that have been modified since then.

link|improve this answer
This works in most cases -- Only thing to be aware of is root can change timestamps (If the "users" are plain vanilla users there should be no issue, otherwise paranoia dictates using something that checksums files) – voretaq7♦ Feb 10 at 18:49
Well, paranoia is not really an issue - I'm assuming whoever has worked on the system was acting in good faith and isn't doing anything too crazy. – Steve Bennett Feb 13 at 5:02
feedback

Your Answer

 
or
required, but never shown
discard

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