It has been about 2 weeks since I turned on [spam v2][1] in this site to [fight back SPAM][2]. I just want to report the success of this action. After the installation, the module worked intelligently to unpublish lots of comment SPAMs everyday without any training for a few days. By the way, it turned out that SPAMers changed their patterns so the module could not classify them as SPAM correctly. So I manually marked 4 comments

One of my friend would like to set up a personal web for controlling BTQueue backend through web interface using PHPBTque. It is a good idea in case of you don't like ssh and command line. Unfortunately, he got some weird problem like "permission denied (13)". This error message was not ejected by BTQueue for sure. So where it came from is the key to fix this problem. Since the system he is running is Fedora Core 5, I guessed it should be SELinux and it is. SELinux is great in security but it is very difficult and too complicate to configure in general purpose server. Usually, I disabled SELinux in my all FC instances. By the way, other may like SELinux enough to configure SELinux for maximum security.

If you have read my blog for a while you will notice some comment spam since last week. That was not good at all and I've never happy to see them. Now, it's time to fight back! Fortunately, Drupal has a good module for this special task namely spam. And now, it is spam v2. Briefly, spam v2 is very easy to install on Drupal 4.7.2 by just downloading, extracting, enabling and configuring. How good is it? Shortly, you may think that spam v2 is a kind of SpamAssassin for Drupal because it has Bayesian and supports auto-learning. If you are not familiar with SA, the good news is that you don't need to know anything just let spam v2 do the rest. The detected spams may be reviewed later by you.

As of today, Linux Kernel 2.6.x has been hacked for lots of local root exploits. Anyway, it doesn't matter how many they are but it does matter that most of that exploits valid on most Linux stations. One serious case is that they also valid on even cluster distribution like NPACI Rocks. In other words, the whole servers in a cluster maybe exploited for cracking bigger goal, e.g., password decryption. Ones may argue that it is not that dangerous because they are local root exploits, not remote root exploits. Yes, they are. But you have to imagine the power of grid computing where you can run a job seemlessly on remote clusters with automatic executable staging. That's enough. One may exploit the whole grid instantly.

I encountered a bandwidth problem. It seems international bandwidth was quite low so I can't run even "apt-get update" successfully in reason time. Anyway, I really want to update package repositories to make everything up-to-date. So I looked for interim solution like proxy server to help me pass through this obstacle as quick as possible. I have other hosts with fast access to international sites and this host also is accessible so fast from my host. It should be possible to run a kind of web proxy there.

When I found OpenVPN, I thought it was the best and easiest VPN I had seen. However, it still requires very long configuration and port forwarding behide NAT. Luckily, it is able to run over TCP to prevent problems caused by NAT. Today, I found alternative promising solution called Hamachi. It states that it offers LAN over Internet with zero-configuration VPN and secure peer-to-peer technology. Amazing!