How to determine the last time a Solaris machine was patched

Is this patch mantained/supported by the developer anymore?

It appears that a equivalent feature (xt_time) is now part of the kernel. It appears to be compiled in and functional on the current Debian Lenny kernel.

2  *      xt_time
3  *      Copyright © CC Computer Consultants GmbH, 2007
4  *      Contact: <jengelh@computergmbh.de>
5  *
6  *      based on ipt_time by Fabrice MARIE <fabrice@netfilter.org>
7  *      This is a module which is used for time matching

Is it used at all by anyone?

Probably, but like many of the obscure features, it probably isn't being used by many people. I am not using it, so I can't tell you much.

Has anyone managed to apply and use it?

The precense of xt_time in the kernel, and being available in the distributed Debian kernel does seem to indicate that it can be applied and is functional. It appears to have been in there since October 2007.

On which kernel/iptables versions does it work?

I believe if you are looking at using xt_time without a lot of work, then you need to be looking at 2.6.24+. If you are willing to roll up your sleeves and do some back-porting, you may be able to get it to work for whatever kernel you are currently running.

HOW IN THE F**CKING WORLD IS IT POSSIBLE THAT THE MAIN FIREWALL SUBSYSTEM IN THE LINUX KERNEL IS SO LOUSILY..

The main functionality of netfilter is fine, and the most of the docs from years ago are just as useful today. Linux is a volunteer effort. If someone doesn't want to write or update documentation, then nobody will. If you want to donate some of your time to the cause, I bet they would accept some help in getting things up to date.

THE PROJECT SITE HOSTS LOTS OF INCOMPATIBLE THINGS WITHOUT ANY WARNING

I suspect the fact that is no in the stable kernel is a big enough warning to deter most people. Building/patching a kernel is not a trivial task to be undertaken lightly.

THE OFFICIAL EXTENSIONS HOWTO JUST DOESN'T BEAR ANY RESEMBLANCE TO REALITY?!?

Welcome to the Internet. You could send them a nice email and ask them to at least put something on the page about the old system being obsolete.

(First, a disclaimer: I work for Ksplice.)

We use it on our own production infrastructure, naturally, but more importantly, so do our our 500+ corporate customers (number as of Dec '10).

One sysadmin asks the same question on a Red Hat Enterprise Linux user mailing list, and is met with a number of answers, a few of which are excerpted below:

We've been running Ksplice in production for a few months on a dozen or so hosts. So far it works as advertised.

and

I have > 500 machines under my control, about 445 of them are connected to uptrack (rhel 4 & 5). We used ksplice to block a few root exploits before we had a chance to reboot machines. Since we are still testing we rolled out the new kernel anyway but I've run for weeks ksplice'd without a problem.

One concern expressed by folks is not about the stability, but rather its integration with existing auditing and monitoring tools:

The only "gotcha" about using ksplice is that there aren't any "ksplice-aware" auditing tools available yet.

As you might expect, this is now an area in which we're investing heavily.