What process modified my file on linux?

On windows, you can use sysinternals' procmon to figure out how your files changed.  It ends up on linux there is tool that can do the same thing.

First, make sure auditd is installed, on RHEL5, I would do:

• yum install audit

Next, let's set up the rule file the follow in terms of what kind of calls we want to monitor for by:

• sudo vim /etc/audit/audit.rules

You rule file should look like the following.  In the example below, I want to monitor the filemonitorme in /var/ so I set up a monitor that looks for writes and attribute changes.  This will tell me what process touched the file, but sometimes I would want to know what was the argument to that process.  You can get a log of all processes using the line immediately above by setting a watch on execve call.

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 2000

# Feel free to add below this line. See auditctl man page
-a always,exit -S execve
-w /var/monitorme -p wa

Now you are ready to start auditd.

• sudo /etc/init.d/auditd restart  (invokes both stop and start)

You can look at the log file inside the /var/log/audit directory:

• sudo less /var/log/audit/audit.log

A problem I ran into with auditd logs is that it would often give me a parent process id, but doesn't tell me what the parent is, so in order to figure that out, I regularly logged out all processes into a separate file so I can figure out what the parent proces is later:

• watch -n 1 "ps -ef >> ~/pslog"

Undo and Recover from a Rebase Mistake

I had 3 local commits and I wanted to squash them.  So naturally I did:

git rebase -i

However, it was 6pm and I was tired so instead of putting little s in front of each commit I wanted to squash, I pressed dd twice in vim, which deleted both of those lines.  What happened next is that I lost those two commits in the local branch.

Luckily underneath, git still has those two commits:

git reflog

But the dag does not show them as expected:

git dag --all

To fix it, I took the commit that I wanted in git reflog and merged it with my current branch:

git merge 1482cc4

And then did a rebase correctly.

Leaving Microsoft

Today is my last day at Microsoft.  I will be starting to work on AWS Identity Access Management in a month so I am moving my blog away from http://blogs.technet.com/b/softienerd/ to here.  Stay tuned for more.