结果今天类似问题再次出现，搞得我的服务器load一下子又升高到200多:

[root@eygle logs]# uptime
20:01:37 up 23 min, 1 user, load average: 246.82, 243.49, 144.99

瞬间的并发进程有300多:

[root@eygle logs]# grep mt-search.cgi eygle_access_log.20061208 |awk '{print $1}'|wc -l
321

主要的ip地址为:58.61.164.138

再封锁了这个ip，不过如果对方不断更换地址，这样的封锁不是办法。
咨询了一下DCBA，他说可以通过robots.txt来限制一下相关目录的访问。
我告诉他，那个早就设置了，这些垃圾搜索引擎根本不看robots.txt文件的。

随后DCBA建议我修改一下Apache的规则，这是一个好办法，修改了一下，类似之前设置过的图片防盗链一样，针对mt-search.cgi的访问只允许来自站内，在httpd.conf中增加如下一段即可:

<FilesMatch "mt-search.cgi">
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

现在应该可以有效防止这些流氓搜索引擎了吧?

-The End-

用来做 egoSurf 时百度的结果比Google的要好一些，百度能够给出更多在Google中无法找到的内容，看来的确是百度更了解中文；更重要的是Google的博客搜索( blogsearch.google.com )经常间歇性的无法访问，百度的产品看来是一个很好的替代。

其实我们可以很容易的发现，只要百度不断地把Google的成功服务搬过来，在GFW的帮助下，百度就能取得不错的成绩，最近微软的MSN Space几乎无法访问，百度的空间应该又获得了快速扩张...

目前百度主要收录的都是MSN Space和百度空间的Blog，在百度上提交了一下我的博客 RSS。
博客提交地址：http://utility.baidu.com/blogsearch/submit.php

-The End-

检查一下Apache日志，发现如下一条信息:
[notice] caught SIGTERM, shutting down

然后Apache就死掉了，网站Down了12个小时。

Apache的日志中再没有其他信息，检索网上的内容，很多帖子提到是和Bug有关，但是情况各不相同。
检查系统日志，又发现了一些有价值的信息:

Dec 7 21:45:47 eygle kernel: Free swap: 0kB
Dec 7 21:45:47 eygle kernel: 524282 pages of RAM
Dec 7 21:45:47 eygle kernel: 294906 pages of HIGHMEM
Dec 7 21:45:47 eygle kernel: 5537 reserved pages
Dec 7 21:45:47 eygle kernel: 10083 pages shared
Dec 7 21:45:47 eygle kernel: 0 pages swap cached
Dec 7 21:45:47 eygle kernel: Out of Memory: Killed process 29858 (httpd).
Dec 7 21:45:47 eygle kernel: oom-killer: gfp_mask=0x1d2
Dec 7 21:45:47 eygle kernel: Mem-info:
Dec 7 21:45:47 eygle kernel: DMA per-cpu:
Dec 7 21:45:47 eygle kernel: cpu 0 hot: low 2, high 6, batch 1
Dec 7 21:45:47 eygle kernel: cpu 0 cold: low 0, high 2, batch 1
Dec 7 21:45:47 eygle kernel: cpu 1 hot: low 2, high 6, batch 1
Dec 7 21:45:47 eygle kernel: cpu 1 cold: low 0, high 2, batch 1
Dec 7 21:45:47 eygle kernel: Normal per-cpu:
Dec 7 21:45:47 eygle kernel: cpu 0 hot: low 32, high 96, batch 16
Dec 7 21:45:47 eygle kernel: cpu 0 cold: low 0, high 32, batch 16
Dec 7 21:45:47 eygle kernel: cpu 1 hot: low 32, high 96, batch 16
Dec 7 21:45:47 eygle kernel: cpu 1 cold: low 0, high 32, batch 16

居然是资源耗尽,这几乎是不可能的，SoSo的疯狂拉网页已经被成功封锁...
不过当时的系统具体信息已经不知道了，从Apache的日志中也没有看到太过频繁的访问。

哪位朋友遇到过类似的情况么?

我的Blog也遭遇了一系列的大规模复制侵权。在气愤的同时，大家也纷纷通过不同的手段来维护自己的版权，也唯有靠大家的不断努力和呼吁，中国的版权意识才能不断提高吧。

最近看Che Dong发布了一个CC声明，为每一篇文章增加了一个易于复制的版权声明。

其实我的每篇Blog之前都有一段链接及作者声明，类似:

作者:eygle
出处:http://www.eygle.com/blog [Life]
日期:December 1, 2006
本文链接:http://www.eygle.com/archives/2006/12/softcn_meeting.html

可是转载者通常熟视无睹，去掉了事。

据Che Dong说他的版权声明极为有效，效仿一下，修改了我的版权声明，方便转载者进行复制，希望这是我最后一次谈论关于版权的事情。

-The End-

这个疯狂"盗版"的网站就是以前我一直极为痛恨的ChinaITlab，上一次的编辑很虚心，接受了我的抗议，删除了部分转载的我的文章，后来我就没再追究。

可是最近我发现ChinaITlab换了编辑，他们网站的Oracle频道的"最近更新"再次成为了我的网站的最近更新:

粗略数了一下，首页上转载我的文章就超过了10篇,而且一律更改了署名，去除了我的所有作者及出处信息；看来怎样在Blog上声明也是没有用的，Fenng和Che Dong费力设计的版权声明我估计也没用了。

这一次我试图通过MSN和他们的编辑沟通一下:

eygle说:
你们从我的网站转了大量文章，而且都没有署名，甚至更改了署名
ChinaITlab 说:
可能是有收录你们网站的文章,但是数量好像不是非常多
我刚刚询问了一下其他编辑,可能是他们从别的网站上找的
那些网站又是转自你们网站,比如那些更改了署名的文章就是

而且，居然要我出示证明来证明文章是我的:
ChinaITlab 说:

可以，如果确定这些文章是你的，我们可以按照你的要求删除，不过要请你出示相关证明，因为其他网站也出现了这样的文章，我们在不能确切确认来源的情况下擅自删除。

我给出了原作链接之后，看看他们怎么说:

ChinaITlab 说:
这样的证明力度好像有点欠缺

真是肺都要气炸了，照这么说，我还没法证明我写过的东西是我写的了，这是什么强盗逻辑?

比较起来，CSDN的态度算是很好的了。

-The End-

这次的情况是这样的，当我发现服务器的http请求失去响应时登陆服务器，发现大量的Tag搜索请求：

[gqgai@eygle logs]$ top

top - 17:13:49 up 120 days, 1:43, 1 user, load average: 87.96, 175.87, 123.25
Tasks: 229 total, 55 running, 173 sleeping, 0 stopped, 1 zombie
Cpu(s): 84.4% us, 15.6% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 2074980k total, 1837916k used, 237064k free, 840k buffers
Swap: 4192956k total, 154724k used, 4038232k free, 21004k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
46 root 16 0 0 0 0 D 7.9 0.0 42:56.37 kswapd0
20279 nobody 25 0 54536 38m 3552 R 6.6 1.9 0:04.00 mt-search.cgi
20289 nobody 24 0 50976 34m 3508 R 6.6 1.7 0:03.41 mt-search.cgi
20288 nobody 25 0 49768 34m 3620 R 5.9 1.7 0:03.52 mt-search.cgi
20242 nobody 25 0 40148 33m 3544 R 4.9 1.7 0:03.29 mt-search.cgi
20253 nobody 25 0 52776 37m 3520 R 4.9 1.8 0:03.58 mt-search.cgi
20275 nobody 25 0 52552 36m 3540 R 4.6 1.8 0:03.59 mt-search.cgi
20236 nobody 25 0 51804 34m 3540 R 3.6 1.7 0:04.00 mt-search.cgi
20277 nobody 24 0 52960 36m 3620 R 3.6 1.8 0:03.83 mt-search.cgi
20223 nobody 25 0 51800 37m 3644 R 3.3 1.8 0:03.89 mt-search.cgi
20225 nobody 25 0 48364 30m 3532 R 3.3 1.5 0:03.44 mt-search.cgi
20228 nobody 20 0 45948 31m 3528 R 3.3 1.5 0:03.31 mt-search.cgi

CPU load已经达到150左右。

检查日志，发现这些请求都是来自一个ip: 60.28.235.177
经过查询，这个ip地址来自天津一个叫做Tengxun的公司:

inetnum: 60.28.235.0 - 60.28.235.255
netname: TengXun-LTD-TJ
country: CN
descr: TengXun Technology Ltd Company
admin-c: HZ19-AP
tech-c: HZ19-AP
status: ASSIGNED NON-PORTABLE
changed: ipaddr@ywb.online.tj.cn 20051229
mnt-by: MAINT-CNCGROUP-TJ
source: APNIC

route: 60.28.0.0/15
descr: CNC Group CHINA169 Tianjin Province Network
country: CN
origin: AS4837
mnt-by: MAINT-CNCGROUP-RR
changed: abuse@cnc-noc.net 20060118
source: APNIC

开始我一直怀疑TengXun是不是就是QQ的"腾迅"，经过继续查询，发现同一网段的另外一个ip地址:60.28.235.173 来自腾迅的Soso，访问该地址的80端口得到如下错误：

Forbidden
You don't have permission to access / on this server.
-------------------------------------------------------
Apache/1.3.33 Server at pic2.soso.com Port 80

看来这个地址和腾迅的SOSO有关，应该就是SoSO放出来的一只蜘蛛。

目前不清楚Soso为什么会以如此高的并发狂拖网页，而其他搜索引擎就不会如此，没有办法，只好暂时封掉SoSo的IP。

由于iptables封锁的规则存在顺序问题，所以使用iptables增加规则应该使用如下命令:
iptables -I INPUT 1 -s 60.28.235.177 -j REJECT

这样封锁的结果是:

[root@eygle ]# iptables --list -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
REJECT all -- 60.28.235.177 0.0.0.0/0 reject-with icmp-port-unreachable
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

该网址被成功封锁，感谢网友 huc 的帮忙 ：）。

-The End-

看起来，技术问题已经解决。

如果大家还记得，以前曾经有一个新闻，说美国举行听证会，对Google、Yahoo!、微软和思科四家公司在中国因为商业利益所做出的妥协进行谴责。

可是现在的结果呢？
现在的结果是Google.cn已经取代了Google.com

Wikipedia不肯改变，那就让他白发苍苍去吧。

btw:最近决定恢复英文Blog的更新，关于这一篇，英文版参考Wikipedia is Blocked again in China 。

-The End-

几天来，在中文网站上注册的、准备为网站贡献内容的新用户数量每天超过了1,200人，远远高于网站被解禁前每天平均300-400人的水平。据维基百科基金会的数据，中文网站上每天贴出的新文章数量较一周前增加了75%，现在中文文章总数已经超过了10万。

其实关于Wiki，blogspot等站点的开开封封，很多网民已经开始麻木，最近Google.com基本上也已经被强制用Google.cn取代....世界和人们就这样在学着适应规则。

关于Wiki看到一段有趣的言论，维基百科的系统管理员蒂姆斯塔林(Tim Starling)说：

“我觉得现在还不是庆贺的时候，我们已经被封锁、解禁很多次了。
我觉得，大家把这次解禁看作某种形式的自由化还为时过早。或许监管机构只是遇到了一些技术难题。”

我也倾向于同意Tim Starling的看法，也许,无他，仅仅是由于技术问题...

-The End-

不过昨天这一插件出现了一个问题，在作者的网站上发现有很多人遇到，主要症状就是链接显示错误，错误链接类似如下格式显示：

http://localhost/mt//opt/apache/mt/2.html

我猜测是程序中路径处理部分存在Bug，检查了半天也没有发现，问了DCBA他也没有发现问题，而他使用是正常的；最后考虑可能是版本的问题，将这个插件降低到版本1.1，问题解决。

这个插件的另外一个问题是，在apache日志中经常可以发现如下错误:
"my" variable $filepath masks earlier declaration in same scope at ..../pagedarchives.pl line 222

这是一个常见的错误，暂时的解决方案是将222行的：
my $filepath="$path/$pagebasename$ii$ext";
修改为：
$filepath="$path/$pagebasename$ii$ext";

即可。

这是一个不错的插件，希望作者能够尽快修正这一Bug。

-The End-

最近dcba对Lilina进行了增强，修改了Cache机制，同时修改了页面内容获取及展现，我采用了他的加强版本，重新搭建了我的Lilina聚合页面。

在搭建过程中遇到的一个主要问题是字符集问题，我的Apache设置的缺省字符集gb2312，而Lilina缺省的字符集是UTF8，为了解决这两者的兼容性问题，颇费了一些周折。

最终通过使用.htaccess文件设置解决，主要参考了Apache的官方文档：
http://httpd.apache.org/docs/2.0/howto/htaccess.html

现在我的Lilina又可以访问了。

-The End-

使用外部表可以很容易的实现网站的访问日志分析。
虽然使用Awstats等工具也可以实现，可是使用Oracle来分析我们更应该得心应手。
而且这一切还是有那么一点点Cool的。

好了，闲言少叙，让我们来看一下我分析的过程。
首先创建路径指向日志存放目录:

[oracle@jumper elog]$ pwd
/opt/oracle/elog
[oracle@jumper elog]$ ls
eygle_access_log.20061016
[oracle@jumper elog]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Wed Oct 18 08:59:35 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> create or replace directory elog
2 as '/opt/oracle/elog';

Directory created.

然后我将这个路径的访问权限授予eygle用户来进行具体操作:

SQL> grant read,write on directory elog to eygle;

Grant succeeded.

选择合适的分隔符创建外部表:

SQL> connect eygle/eygle
Connected.

SQL> create table eygle_access_log_20061016
2 ( ip_address_date varchar2(100),
3 acc_file varchar2(400),
4 acc_cdsz varchar2(20),
5 acc_url varchar2(400),
6 left_blank varchar2(10),
7 acc_agent varchar2(400))
8 organization external (
9 type oracle_loader
10 default directory ELOG
11 access parameters (
12 records delimited by newline
13 nobadfile
14 nodiscardfile
15 nologfile
16 fields terminated by '"'
17 missing field values are null
18 )
19 location('eygle_access_log.20061016')
20 ) reject limit unlimited
21 /

Table created.

此时我们就可以对eygle.com的2006年10月16日的访问日志进行分析了。

我们可以先看一下各个字段的分界结果，示例如下:

SQL> select ip_address_date from eygle_access_log_20061016
2 where rownum <11;

IP_ADDRESS_DATE
-------------------------------------------------------------
38.102.128.140 - - [16/Oct/2006:00:00:17 +0800]
66.249.65.113 - - [16/Oct/2006:00:00:19 +0800]
202.160.178.221 - - [16/Oct/2006:00:00:35 +0800]
59.36.78.100 - - [16/Oct/2006:00:00:37 +0800]
59.36.78.100 - - [16/Oct/2006:00:00:38 +0800]
72.30.61.8 - - [16/Oct/2006:00:00:38 +0800]
221.217.84.230 - - [16/Oct/2006:00:00:42 +0800]
221.217.84.230 - - [16/Oct/2006:00:00:42 +0800]
74.6.65.236 - - [16/Oct/2006:00:01:07 +0800]
74.6.73.36 - - [16/Oct/2006:00:01:09 +0800]

10 rows selected.

通过SQL析取出访问的ip地址:

SQL> select substr(ip_address_date,1,instr(ip_address_date,' ')) ip_address
2 from eygle_access_log_20061016 where rownum <11;

IP_ADDRESS
---------------------------------------------------------------------------
38.102.128.140
66.249.65.113
202.160.178.221
59.36.78.100
59.36.78.100
72.30.61.8
221.217.84.230
221.217.84.230
74.6.65.236
74.6.73.36

10 rows selected.

接下来我们就可以很容易的获得当日访问我站点的独立IP数量了:

SQL> set timing on
SQL> select count(distinct(substr(ip_address_date,1,instr(ip_address_date,' ')))) uip
2 from eygle_access_log_20061016;

UIP
----------
7534

Elapsed: 00:00:06.86

我们可以对比一下数据库表的性能。
首先将日志加载到数据库表中:

SQL> create table ealog as
2 select * from eygle_access_log_20061016;

Table created.

SQL> desc ealog;
Name Null? Type
----------------------------------------------------------------- -------- --------------------------------------------
IP_ADDRESS_DATE VARCHAR2(100)
ACC_FILE VARCHAR2(400)
ACC_CDSZ VARCHAR2(20)
ACC_URL VARCHAR2(400)
LEFT_BLANK VARCHAR2(10)
ACC_AGENT VARCHAR2(400)

SQL> select count(*) from ealog;

COUNT(*)
----------
165443

然后我们强制刷新Buffer Cache，消除Cache的影响，再次执行查询：

SQL> alter session set events = 'immediate trace name flush_cache';

Session altered.

Elapsed: 00:00:00.03
SQL> select count(distinct(substr(ip_address_date,1,instr(ip_address_date,' ')))) uip
2 from ealog;

UIP
----------
7528

Elapsed: 00:00:02.15

此时用了大约2秒的时间，也就是说，外部表的性能较数据库表大约慢了3倍左右。

继续，我们可以查询当日网站中，哪些网页是被最频繁访问的:

SQL> select replace((replace(acc_file,'GET ','http://www.eygle.com')),'HTTP/1.1') accfile,ct from (
2 select ACC_FILE,count(*) ct from eygle_access_log_20061016
3 where acc_file like '%htm%'
4 group by acc_file order by ct desc)
5 where rownum <21;

ACCFILE CT
-------------------------------------------------------------------------------- ----------
http://www.eygle.com/index-tech.htm 110
http://www.eygle.com/archives/2006/10/wish_home.html 103
http://www.eygle.com/index-ha.htm 79
http://www.eygle.com/me/fairy_tale_leaf.htm 77
http://www.eygle.com/archives/2006/11/use_oracle_external_table.html 73
http://www.eygle.com/index-sql.htm 69
http://www.eygle.com/archives/2006/10/tom_oracle_9i10g.html 68
http://www.eygle.com/archives/2008/08/my_book_services.html 63
http://www.eygle.com/archives/2006/11/welcome_friend.html 62
http://www.eygle.com/archives/2006/10/veritas_vcs_simulator.html 61
http://www.eygle.com/index-case.htm 60
http://www.eygle.com/archives/2004/08/aoaouiiciona.html 59
http://www.eygle.com/archives/2006/08/oracle_fundbook_recommand.html 52
http://www.eygle.com/archives/2006/08/5460_8174.html 49
http://www.eygle.com/archives/2004/12/gmailaeaeoa.html 48
http://www.eygle.com/archives/2005/06/howlsmovingcast.html 48
http://www.eygle.com/gbook/index.html 48
http://www.eygle.com/index-hist.htm 44
http://www.eygle.com/index-special.htm 41
http://www.eygle.com/index-f&l.htm 37
20 rows selected.

Elapsed: 00:00:06.31
SQL>

通过外部表及SQL查询，只要日志文件中存在的信息，都可以很容易的被获取和分析.

-The End-

而且还有一些数字形式的关键字，如503316480，201326592等；
这些关键字的搜索比例很高，在我的9月份不完全统计中，包含:

17655 个不同的关键字句 搜索 百分比
gb2312 5011 11.6 % 
sitehao123 728 1.6 % 
503316480 671 1.5 % 
201326592 658 1.5 % 

Che Dong对这个问题给出了解决方案，通过修改AWStats的search_engines.pm中的参数列表定义，可以过滤掉可能产生歧义的参数。

那么类似503316480，201326592的数字是什么呢？
通过Baidu搜索一下就可以找到答案，原来是图片搜索带来的参数，同样我们修改一下search_engines.pm的参数列表就可以过滤掉这些歧义参数。
我修改后再加入"ct="就可以过滤掉这些图片搜索带来的数字了:

@WordsToCleanSearchUrl= ('ct=','tn=','ie=','act=','annuaire=','btng=','cat=','categoria=','cfg=' ...

在抵达我的网站的关键字中，5460和中国同学录居然都排在了前列:

5460 91 1.2 %
中国同学录 89 1.1 %

看来同学的力量不可低估。

-The End-

这应该是chedong通过雅虎通批量导入MSN联系人后自动发送的邮件通知。

虽然雅虎通可以和MSN直接通讯，但是我还是愿意尝试一下雅虎通。毕竟在我最初接触互联网的年代（大约在1998年左右），雅虎曾经是我们的第一选择。

可是当我试图通过以前的Yahoo! ID登录Yahoo!通的时候，一个问题出现了，我早已经不记得N年前创建的Yahoo!帐号的密码了，而且我确实此前就做过很多尝试，并且把我常用的名字都注册完了，现在，我面临的难题是，怎样找回这些密码?

于是再次遭遇了雅虎糟糕的密码找回功能（也许应该怪我的记性太差）:

第一步的信息那里我就已经无法通关了，一个邮政编码足以难倒我，从大学到现在，自己已经在不下10个的邮政区域里流动过，该是哪一个呢？而且，我当初填写的真的是一个邮政编码么?

另外一个有意思的发现是，在生日的月份栏，"五月"是与众不同的显示，这个月份对于Yahoo！有着什么样的特殊含义呢？有谁知道么?

btw: 还有一个问题是，国家地区选择栏里，你要很仔细才能找到中国。

好了，经过对这个页面的仔细研究后我发现：我的密码找回永无希望了。

-The End-

整个网站，除了被攻击时损失了部分数据，现在有效的回复只有不到2000条:

mysql> select count(*) from guestbook;
+----------+
| count(*) |
+----------+
| 1944 |
+----------+
1 row in set (0.00 sec)

而垃圾留言呢?有近2000条:

mysql> select count(*) from spambook;
+----------+
| count(*) |
+----------+
| 17787 |
+----------+
1 row in set (0.00 sec)

如果我没有采取过滤措施，那么可以想象，留言板一定早已经面目全非了。
真是佩服这些无聊人士每天废寝忘食的四处散布垃圾信息:

mysql> select FROM_UNIXTIME(dateline,'%Y-%m-%d') 'date' ,count(*)    
    -> from spambook group by 1 order by 1 desc limit 20;
+------------+----------+
| date       | count(*) |
+------------+----------+
| 2006-09-23 | 2        |
| 2006-09-22 | 75       |
| 2006-09-21 | 98       |
| 2006-09-20 | 106      |
| 2006-09-19 | 90       |
| 2006-09-18 | 125      |
| 2006-09-17 | 106      |
| 2006-09-16 | 142      |
| 2006-09-15 | 111      |
| 2006-09-14 | 125      |
| 2006-09-13 | 110      |
| 2006-09-12 | 115      |
| 2006-09-11 | 123      |
| 2006-09-10 | 112      |
| 2006-09-09 | 127      |
| 2006-09-08 | 100      |
| 2006-09-07 | 116      |
| 2006-09-06 | 96       |
| 2006-09-05 | 112      |
| 2006-09-04 | 122      |
+------------+----------+
20 rows in set (0.14 sec)

让我们见识一下Top100的无聊人士都有哪些:

再看看俺的，恩，也不错（汗ing），超过了200，截个图纪念一下：

在阅读工具里面Bloglines的用户是最多的，CreatNews客户端工具的用户也不少，占到了11%。
看来Firefox的用户也为数不少，FireFox Live Bookmarks占到了13%，等到IE7正式版推出时，应该也会有不少IE的用户使用IE7作为Rss阅读工具吧。

之前我的css存在问题，使得在FireFox中显示存在字体过小的问题，感谢dcba帮我找出了问题，一举解决了Blog在FireFox中显示异常的问题。

-The End-