So there is a currently unresolved issue with the check_snmp nagios plugin where it doesn’t use the snmp.conf file. I use v3 of the protocol, and don’t want to have to put the big long string everywhere in the nagios configuration file:
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -w 2 -c 4 -u "cpu" -P 3 -L authPriv -a MD5 -U snmpmonitor -A "have a look at what I have to offer" -x des -X "have a look at what I have to offer" -o .18.104.22.168.4.1.2021.11.10.0
So I came across little vps a while back, and finally placed an order last week. So far, I’m extremely impressed with their control panel’s functionality, especially their pv-grub option for running your own xen kernel. Their support takes a little while to respond, but for hosting at such a low price, what do you expect?
Bottom line up front; the GPL license is viral.
I have had a lot of discussions with people about software licensing, and it amazes me how few of them really understand them, especially the GPL. I’ll do a quick comparison of licenses:
EULA: sharing is evil
BSD: sharing is not evil
GPL: not sharing is evil
Disclaimer: I have no affiliation with ksplice, I’m just a guy who knows something about hot-patching the linux kernel and figured out how this ksplice thing works. I strongly agree with the sentiment that the ksplice raw utilities is not for general use. In fact, Ksplice says in the distribution of these tools:
Without the appropriate expertise and safety infrastructure, the raw utilities can create subtly incorrect rebootless updates, which can have serious consequences.
I have lots of respect for Ksplice, Inc, and hold nothing personal against any of the people that work there. Their software is spectacularly awesome. The following is simply my opinion on a matter of principle, and respectfully state the facts as I see them.
I contacted Ksplice a few months ago and they basically told me that they will no longer be updating their git repository, yet be releasing updates in binary-form only. I had to ask myself; is Ksplice, Inc in violation of the GPL?
For the past two months, I’ve been working on this project:
This kernel modules implements Trusted Path Execution (TPE), a security feature that anyone who is looking for an easy, single solution that will prevent all kinds of exploits. The short of it is, a user can’t execute code that they can write to. Meaning, if they download, compile, or otherwise write a file on the system with executable code, they can not execute it. This single handedly closes the door on a whole range of system exploits.
Following up on my previous post on the matter, here are some details on what the 4 grsec features I ported to a centos 5 kernel looks like.
First off, since I’m patching syscalls in heavy use, first try to insert might look like this:
[root@localhost ~]# ksplice-apply ksplice-grsec.tar.gz
Error applying Ksplice update grsec:
Ksplice has aborted the upgrade because it appears that the code that you are
trying to patch is continuously in use by the system. More specifically,
Ksplice has been unable to find a moment when one or more of the to-be-patched
functions is not on a thread's kernel stack.
Process klogd(pid 2060) is using the following symbols changed by update grsec:
So I finally got the official response from ksplice about my previous post on the topic:
“Ksplice does not provide support for the raw Ksplice utilities.”
This also means that they won’t be updating their git repository either. It is obvious to me that they have updated their code internally, but have no intention of releasing it to anyone else.
So for the time being, we are all SOL on the matter. Maybe they will change their mind in the future, but I doubt it. Can’t blame a business for wanting to keep things close to their chest.
There are problems assosiated with upgrading a RHEL/CentOS 5 system so that it can properly build a recent linux kernel, due to it requiring a somewhat current build chain (binutils, gcc, etc). Rather than continue to back-port these RPM packages from fedora to my CentOS 5 machines, which is what I’ve done in the past, I have opted to just upgrade and use a new operating system.
As a proof of concept, I pulled 4 features from the grsecurity patch and back-ported them to the CentOS 5.6 kernel. I built the resulting patch with ksplice and inserted the resulting tarball into the kernel. The features work brilliantly. It’s been running on my server the past few days with no issues so far.
The features I did it with are: Trusted Path Execution (TPE), dmesg restrictions, TCP/UDP blackhole, and disabled privileged IO.