Why is FSChange (file system change monitor) a deprecated feature in Splunk 5.0?

[BP9906]

Why is FSChange a deprecated feature in Splunk 5.0?

[sloshburch]

This might be a good forward looking solution: http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html

[cervelli · Accepted solution]

The fschange input is deprecated in 5.0 for two reasons.

First, it does not run predictably on all platforms. Since it has been that way for some time, many felt that was a form of 'implicit' deprecation. We prefer to be open whenever possible, so we decided the time had come to signal that this feature had too many caveats.

Second, it does not do what is generally required for audit use cases, which is track the user/account making the change. Most OS/FS pairs provide high quality, out-of-the-box tools to do this already. In fact our guidance has been to use those tools in most cases, leaving little room for a Splunk-maintained feature.

We are considering migrating the file metadata capabilities of fschange into monitor. That won't help the second point, but would be parity with fschange. If you would like to weigh in to support that, please file an enhancement request with our support team; both so we know your use case, and can get back to you personally.

[fquintella]

I agree that this is a usefull feature and that we should keep it.

[gkanapathy]

Please note that if you want to monitor changes to file content (i.e. fullEvent = true), you can get better and more consistent results using a regular file monitor:// rather than fschange, by setting props.conf settings CHECK_METHOD to modtime (or entire_md5). You should also set LINE_BREAKER to (?!) or (*FAIL), but you need to do this for fschange as well.

[the_wolverine]

The decision has already been made as fschange is already deprecated in 5.0 -- miracles do happen and maybe Splunk will redo it and it will work as expected in a future release.

[ahattrell_splun]

Can I ask, if you've not already done so, that you log a case with Support to ensure that your request is counted in the official ER stats. I'd encourage anyone that needs this functionality to do the same.

[dvb]

I fully agree with dabbank!

[dabbank]

With a Splunk Universal Forwarder installed on most production machines already the fschange monitor is an easy-to-use approach to monitor changes of certain configuration files.
Together with "fullEvent = true" you even get a full history. To implement the same functionality with OS out-of-the-box tools like Linux inotify is not quite as handy.
If "most OS/FS pairs provide high quality" support for this, why is it so hard then to do this right in Splunk?

I hereby request to keep the fschange input in Splunk and fix open issues instead of throwing in the towel.

[cervelli]

Per the support agreement, (http://www.splunk.com/web_assets/pdfs/support/SplunkSupportAgreement.pdf) until the second major release (e.g. 6.0) or 24 months, whichever is more. As 4.3 went GA Jan 2012, that would mean Jan 2014.

[kristian_kolb]

How long is that? This slightly related a previous question I had. http://splunk-base.splunk.com/answers/55847/splunk-support-and-end-of-life

[cervelli]

There is no decision on when to remove fschange. The input will be supported for at least as long as 4.3.x is supported.

[responsys_cm]

When is Splunk planning on dropping support for fschange completely?