A vulnerability in Linux kernels prior to 2.6.37-rc3-next-20101125 allows a local user to cause a denial of service attack on your server. So this is a good time to cross check the level of access you’ve granted to the users on your server. If you’ve recently been experiencing high loads and server crashes, with no apparent network activity, you could be among one of the very few victims of this attack
Linux has always been blessed. As we have a large number of people working for the betterment of the product, we’ll have bug fixes/security updates every now and then. This has got 2 sides.
- The good part- if you keep on upgrading; you will have a more secure, bug-free product.
- The bad part- if you never upgrade; the whole world knows the security vulnerabilities of the outdated version. I guess this could be as good as tweeting your root password.
So, we’ve got to update the systems as and when the updates arrive. But, an update once in a month will mean a reboot once a month, which will mean monthly server downtime. This is where Ksplice comes into the picture.
Your Kernel just crashed or one of your drive is not working!! What do you do?
Well, this article gives an introduction to some kernel debugging tools for Linux. These tools makes the kernel internals more transparent. These tools help you to trace the kernel execution process and examine its memory and data structures.
The tools discussed here are :
1. Kernel debugger, kdb
2. Kernel GNU debugger, kgdb
3. GNU debugger, gdb
4. JTAG- based debuggers.
“Kernel compilation is a tough nut to crack” – Most frequently this would be followed by a sigh if the recompiled kernel is not booting up. Though the nut has the look of a tough one to crack, kernel recompilation is still an inescapable affair that every Linux system administrator runs into, sooner or later. I too had to. With this article, I intend to walk you through the phases of compiling a kernel. I am sure it will inspire confidence in you so that compiling a kernel is no longer a “mission impossible”.