November 15, 2006

清理scuttle 的垃圾书签

无论是blog系统，还是论坛，经常都充斥着要命的spam，各种类型都有。extmail.org上的scuttle很早前就已经开始遭殃。后来发现这些注册的家伙可能是通过程序注册的，所以加了个安全认证码的东西，注册要输入认证码，后来好了一段时间，最近又跑来一大堆spam信息。无奈！

于是花了半小时写了个垃圾脚本（无奈啊，连接到服务器好慢，网通与电信之间的距离永远是那么遥远...）干掉这些spam。

详细的脚本：

run.sh:

#!/bin/sh
MYSQL="mysql -u root -pyourpassword"

die() {
        echo "Usage: $0 user_id"
        exit 255
}

[ -z "$1" ] && die && return 1

./get_bookID.sh $1|$MYSQL|grep -P "\d+" > "$1"_bID.txt
./list_cateID.sh $1|$MYSQL|grep -P "\d+" > "$1"_id.txt
./del_id.sh $1|$MYSQL
rm -rf $1*.txt

get_bookID.sh:

#!/bin/sh
echo "use app_bookmark; SELECT bID from scBookmarks WHERE uID='$1';"

list_cateID.sh:

#!/bin/sh
echo "use app_bookmark;"

for bid in `cat $1_bID.txt`;do
        echo "SELECT id FROM scCategories WHERE bId='$bid';"
done

del_id.sh:

#!/bin/sh
echo "use app_bookmark;"
for bid in `cat $1_bID.txt`;do
        echo "DELETE FROM scCategories WHERE bId='$bid';"
        echo "DELETE FROM scBookmarks WHERE bId='$bid';"
done

其实可以合并写在一起，不过无所谓，反正能用就拉倒了。没空折腾。反正有了这个烂得掉渣的小脚本，以后看见谁不顺眼干掉谁。哦，忘记了，还得禁止这些家伙的id。实在以后要再泛滥，发书签时也得加认证码？！

Posted by hzqbbc at 08:39 AM | Comments (1)

October 08, 2006

解决IBM thinkpad笔记本恢复系统时报“Product Recovery 无法恢复系统”之类的错误

昨天我的IBM 本子无缘无故在改了系统内存偏重于系统缓存后，就报“lsass.exe 终结点格式无效“的错误，无论如何都修复不了。于是只好进入一键恢复（Thinkpad rescue and recovery）里恢复，可是到了最后要format c盘的步骤时，居然提示”Product Recovery 无法恢复系统”之类的错误，晕倒！

上网查了不少论坛的帖子，其他人都是can't not find xxx module，引起的原因大多是因为分区超过3个。而我的机器分区没超过3个（不算隐藏分区），如何是好？

回忆了一下，昨天自己曾经做过的事情，就是用ghost 备份过系统，难道因此就有问题？那IBM这个RnR软件就太糟糕了吧，后来又想起在做ghost前，我将c盘根目录下的IBMtools及IBMshare等目录都删除了，会不会这个RnR系统需要检测这些文件？

为了证实这个猜测，我进入winxp里，将做好backup的这些目录（一共1.5GB+之多！）复制到c盘，然后再重新启动，进入RnR里，重新进行系统恢复，这次居然没有报错！看来真的是这个问题哦！

但是为什么它需要扫描这些文件呢？那如果我的系统都烂了，文件都丢失了，检测不到这些目录就不许恢复系统，那还要这个一键恢复有何意义？难道要先format掉c盘再进入RnR就可以恢复系统了吗？这个方法还没测试过。。找个时间测试吧。郁闷...

Posted by hzqbbc at 08:29 AM | Comments (1)

September 17, 2006

Acrobat + MS word + HyperSnap = 文档利器

昨天下载了Mantis 中文手册（西西辛苦所著pdf版，感谢！），高兴之余发现里面的图分辨率实在很低，很难看清楚，顿生重新做一次这个手册的念头。于是凑齐HyperSnap和Acrobat 5.0 及ms word，测试了一下截图、生成pdf等功能，为重做手册准备。

但是做下来发现了几个问题：

PDF生成后，里面的图片分辨率低，和西西所做一样，看不清，痛苦
不知道如何截取需要滚屏的网页或应用程序，对于大篇幅的图毫无办法

后来经过摸索，并得到了bdwy的帮助后，解决了问题。方法也很简单：

PDF图象清晰度问题

在word里要输出pdf，可以选择打印==> Acrobat Distiller，然后点Distiller的属性==>Adobe PDF设置==>转换设置那，将默认的CJKScreen换成Press，那么页面分辨率就从可怜的600dpi改为2400dpi，输出的pdf图象质量将大为改善。

截滚屏图形的方法

在HyperSnap ==> 捕捉==>捕捉设置==>捕捉==>窗口捕捉时自动滚屏（勾上即可）

然后保存，选一个需要滚屏的网页，然后按ctrl+shift+w，此时点一下鼠标左键，然后HyperSnap就会自动的滚屏，一直滚到底。到底后再点一次左键即可完成捕捉。回到HyperSnap的界面里，图象就全部抓下来了，至于需要取部分内容者，只需要进行裁减即可，非常方便。

以后做ExtMail的使用手册时，都可以用这几个软件搭配了！:-)

Posted by hzqbbc at 03:01 PM | Comments (1)

Acrobat + MS word + HyperSnap = 文档利器

昨天下载了Mantis 中文手册（西西辛苦所著pdf版，感谢！），高兴之余发现里面的图分辨率实在很低，很难看清楚，顿生重新做一次这个手册的念头。于是凑齐HyperSnap和Acrobat 5.0 及ms word，测试了一下截图、生成pdf等功能，为重做手册准备。

但是做下来发现了几个问题：

PDF生成后，里面的图片分辨率低，和西西所做一样，看不清，痛苦
不知道如何截取需要滚屏的网页或应用程序，对于大篇幅的图毫无办法

后来经过摸索，并得到了bdwy的帮助后，解决了问题。方法也很简单：

PDF图象清晰度问题

在word里要输出pdf，可以选择打印==> Acrobat Distiller，然后点Distiller的属性==>Adobe PDF设置==>转换设置那，将默认的CJKScreen换成Press，那么页面分辨率就从可怜的600dpi改为2400dpi，输出的pdf图象质量将大为改善。

截滚屏图形的方法

在HyperSnap ==> 捕捉==>捕捉设置==>捕捉==>窗口捕捉时自动滚屏（勾上即可）

然后保存，选一个需要滚屏的网页，然后按ctrl+shift+w，此时点一下鼠标左键，然后HyperSnap就会自动的滚屏，一直滚到底。到底后再点一次左键即可完成捕捉。回到HyperSnap的界面里，图象就全部抓下来了，至于需要取部分内容者，只需要进行裁减即可，非常方便。

以后做ExtMail的使用手册时，都可以用这几个软件搭配了！:-)

Posted by hzqbbc at 03:01 PM | Comments (0)

August 20, 2006

配置Mediawiki支持短URL

为了美化URL，今天花了巨多时间在这个看似简单又讨厌的问题上面。中午觉也没有睡。首先来个惯例的Step by step 安装步骤吧。

1.下载mediawiki

由于测试机是php4.3.9，为了不麻烦，偷懒用了个1.6.8的版本，支持php4.x

2.解包

tar xfz mediawiki-1.6.8.tar.gz
mv mediawiki-1.6.8 /var/www/extsuite/mediawiki

3.设计站点URL

计划要用http://wiki.extmail.org来访问整个wiki，因此所有的http://wiki.extmail.org/index.php?title=article_title 需要影射成为http://wiki.extmail.org/article_title

4.参考
http://meta.wikimedia.org/wiki/Using_a_very_short_URL

注意这个链接访问不了，必须使用代理才能访问，在这里，感叹一下我们的自由是多么脆弱。一点小小信息都不能看，Damn it :-(

5.实施
Apache的虚拟主机配置:


ServerName wiki.extmail.org
DocumentRoot /var/www/extsuite/mediawiki


Options MultiViews
AllowOverride None
Order allow,deny
Allow from all
Options FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]


Options MultiViews
AllowOverride None
Order allow,deny
Allow from all
# avoid execution of PHP scripts in upload directory
AddType text/plain .php
AddType text/plain .phps

chmod a+w config
然后访问http://wiki.extmail.org/config/
配置完毕，生成数据库后：
mv config/LocalSettings.php .

配置LocalSettings.php

正常默认就是下面：
$wgScriptPath = "";
$wgScript = "$wgScriptPath/";
$wgRedirectScript = "$wgScriptPath/redirect";

然后修改下面:
$wgArticlePath = "$wgScriptPath/$1";

include "extensions/GeshiHighlight.php";

6.配置使用/wiki/的方法

希望访问wiki 的url为http://www.extmail.org/wiki/xxx

1-5的步骤略去。给出apache 的配置:


ServerName www2.extmail.org
DocumentRoot /var/www/extsuite/html
Alias /mediawiki /var/www/extsuite/mediawiki
Alias /wiki /var/www/extsuite/mediawiki/index.php


Options MultiViews
AllowOverride None
Order allow,deny
Allow from all
Options FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

LocalSettings.php:

$wgScriptPath = "/mediawiki";
$wgScript = "/wiki";
$wgRedirectScript = "/wiki/redirect";

$wgArticlePath = "$wgScript/$1";
include_once("extensions/GeshiHighlight.php");

唯一的缺点是在登陆或退出时，URL是http://www2.extmail.org/wiki?title=xxx&xxxx=xxx

因为apache配置里将/wiki => index.php了，所以wiki?参数就和index.php?参数一致了。嘿嘿。

Posted by hzqbbc at 05:02 PM | Comments (0)

August 06, 2006

IPtables 规则错误导致DNS查询失败之解决办法

受朋友之托，检查其主机上的iptables规则引起的dns问题。主要现象是打开了如下的规则后，squid就不能正常的查找主机的ip地址，dns解析试销。

# Generated by iptables-save v1.3.4 on Sun Aug  6 11:28:42 2006
*nat
:PREROUTING ACCEPT [293:39183]
:POSTROUTING ACCEPT [5:299]
:OUTPUT ACCEPT [5:299]
COMMIT
# Completed on Sun Aug  6 11:28:42 2006
# Generated by iptables-save v1.3.4 on Sun Aug  6 11:28:42 2006
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [949:834012]
-A INPUT -p tcp -m multiport --dports 21,25,80,81,110,143,3128 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT     
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
#-A INPUT -p udp -m udp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec --limit-burst 10 -j ACCEPT      
-A INPUT -i lo -j ACCEPT        
-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT             
-A INPUT -p tcp -m state --state INVALID,NEW -j DROP        
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP      
-A INPUT -p udp -m udp -j DROP
COMMIT
# Completed on Sun Aug  6 11:28:42 2006

当屏蔽了上述规则中#-A INPUT -p udp -m udp -j ACCEPT 的规则后，squid就无法正常工作了。在机器上用nslookup 查询主机名 + 外部dns ip，发现timeout，应该是udp包无法发送到对方的dns服务器53端口。

后来man了一下iptables，发现可以用LOG来记录ip包的情况，于是打开log，增加了如下的规则集：

-A INPUT -j LOG -p udp -m udp --log-prefix "DNS monitor: "

重新启动iptables，在/var/log/message里看到如下信息：

Aug 6 12:00:12 hostname DNS monitor: IN=eth0 OUT= MAC=00:14:5e:41:e0:16:00:0d:65:98:f7:80:08:00 SRC=w.x.y.z DST=a.b.c.d LEN=124 TOS=0x00 PREC=0x00 TTL=47 ID=38895 DF PROTO=UDP SPT=53 DPT=33036 LEN=104

注意这里的SPT=53 DPT=33036，检查一下规则发现放行的是目的地53口，没有发行源端口（即sport），估计问题在这里，于是增加一条记录：

-A INPUT -p udp -m udp --sport 53 -j ACCEPT

重新启动后，正常了。看来，没有log的帮助还一时搞不明白为什么。也怪平时没仔细研究iptables，嘿嘿，通过这次也受到教训了:-)

Posted by hzqbbc at 12:01 PM | Comments (3)

February 25, 2006

Server Push blocked by Compress - 压缩模式不能实现Server Push

Server Push并不是什么新技术，而是一种老技术。早年Netscape就提出了Server Push的技术，通过HTTP 内容类型 multipart/x-mixed-replace 来标识。

但由于Netscape被迫退出市场后，IE一直没有支持这样的特性，所以想基于真正的Server Push 技术开发web 即时通信软件的梦想一直不能获得完美实现。

目前一般的Server Push实现大多是由一个长效执行的cgi程序，将变更的信息发送到客户端浏览器，此时需要此cgi程序及web server支持unbuffer，即能在任意时刻在与客户端建立的连接这个流中传递信息，并不进行缓冲。这样客户端可以即时收到信息。

过去在DMS（Damail System）中实现的无刷新进度条就是使用类似的技术。

最近重新收拾了一下过去的实现，发现居然不能用了！什么原因？

经过检查和对比，才忽然发现，原来自己的web server 打开了内容压缩（gzip，deflate）的功能，难怪怎么都无法即时获得server端的输出。

由于deflate/gzip输出必须事先获得全部的输出信息，因此web server强制性的等待cgi程序执行完毕之后，才将cgi的输出结果进行压缩，并发送到客户端。

因此客户端将一直处于“阻塞”状态，得不到任何数据。

以后得小心这个问题，或者利用apache的deflate模块里提供的功能，对于特定的后缀才进行压缩，对于cgi程序不压缩。否则Server Push就被Blocked 了 :-)

相关的一些Link:


http://home.netscape.com/assist/net_sites/pushpull.html

Posted by hzqbbc at 06:37 PM | Comments (3)

December 14, 2005

openSSH + SecureCRT HOWTO - 如何整合openSSH和SCRT

openSSH/openSSL 是现在最流行的开源软件，保护着数百万的Linux, BSD, Unix主机。而历来商业的SSH server/Client 对openSSH/openSSL的支持都不是太好，在windows下的客户端SecureCRT要支持openSSH总是有这样或那样的不足。

要么，用SecureCRT（简称SCRT）生成的公钥/密钥，然后将公钥放到openSSH Server上去，可以支持SCRT利用证书登陆到openSSH server上，但如果从另一台使用openSSH client的机器要登陆到这个openSSH server，却死活都通不过。

要么，用openSSH 生成的公钥/密钥，则安装openSSH client的机器要连接过来毫无问题，但SCRT却通不过。

为了这个问题琢磨了很久，后来在SecureCRT的官方论坛里，有人提到SecureCRT自4.0以来，已经可以支持openSSH的key了。于是怀着试试看的心情，将SCRT升级到4.1，重新做了一下配置，成功了！

实现了openSSH server + SCRT/openSSH Client 的组合，以后无论是win平台还是*nix平台，都可以方便的使用证书登陆了，实在解决了一个大问题。

How to implement?

以下简单描述一下如何配置与实现的。

配置openSSH server
以下是/etc/ssh/sshd_config的内容：

Port                            22
Protocol                        2
HostKey                         /etc/ssh/ssh_host_rsa_key
HostKey                         /etc/ssh/ssh_host_dsa_key
KeyRegenerationInterval         1h
SyslogFacility                  AUTHPRIV
LoginGraceTime                  5m
PermitRootLogin                 yes
PubkeyAuthentication            yes
AuthorizedKeysFile              .ssh/authorized_keys
IgnoreRhosts                    yes
HostbasedAuthentication         no
PasswordAuthentication          yes
PermitEmptyPasswords            no
ChallengeResponseAuthentication no
Subsystem        sftp    /usr/libexec/openssh/sftp-server

该配置允许使用证书或密码登陆，对于出差到外地但没带证书的情况就很有用了，如果想只使用证书，则将：

PasswordAuthentication          yes

改为：

PasswordAuthentication          no

利用ssh-keygen生成公钥/密钥

例如要生成用户hzqbbc的公钥/密钥，则先su 到hzqbbc用户，然后输入：

ssh-keygen -t dsa

ssh-keygen会提示文件的存放位置及密钥的加密字，按要求输入即可。以下是样例：

[hzqbbc@p4 .ssh]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/hzqbbc/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/hzqbbc/.ssh/id_dsa.
Your public key has been saved in /home/hzqbbc/.ssh/id_dsa.pub.
The key fingerprint is:
aa:0a:3c:be:7f:35:9b:4f:82:bf:1d:ca:0b:dc:bc:cc hzqbbc@p4

将id_dsa和id_dsa.pub复制到windows系统

在windows客户机上，建立C:\SSH目录，然后将id_dsa和id_dsa.pub原封不动的复制到C:\SSH里，确保文件名为id_dsa和id_dsa.pub

配置SCRT

请确认SecureCRT安装或升级到4.0以上，我目前使用的是4.1，然后开始配置。

第一步：打开要配置证书的主机名记录，选中主机名后，点图中红色方框的图标，进入该主机的详细配置界面。

第二步，Connection页中，Username填写要登陆的用户，该用户就是刚才创建证书的用户，这个必须注意。然后在Connection --> Authentication 中，Primary认证方法选PublicKey，并点开“Properties”。

第三步，选Use session public key ，意思是每个不同会话使用不同的证书，这对于管理大量主机的系统管理员较为有用。如果只是维护少量机器，可以考虑使用同一套证书。

Use identity file那里，打开“...”按钮，浏览我的电脑，找到C:\SSH目录，然后看到id_dsa和id_dsa.pub文件，选中id_dsa文件，然后确定，就可以看到路径为C:\SSH\id_dsa 了。

保存好配置，关闭SecureCRT，然后打开配置了证书的主机，正常情况下将提示要输入密钥的加密字，输入后就应该可以登陆进系统了。

同时再打开另一个SCRT窗口。登陆同样的主机，由于SCRT已缓存了证书及加密字，因此不再需要输入用户名密码，使用就很方便了！

Posted by hzqbbc at 01:13 PM | Comments (3)

October 21, 2005

SetEnv fail in Suexec - Suexec下setenv失效

有时候，最不起眼的问题却最耗时间。

早上10点多想起还没完成ExtMail的0.19 release中计划要增加的功能：per domain template ， 于是开始动手。

本来是一个非常简单的功能，几行code就搞定，利用的是Apache等webserver的SetEnv，将特定信息导入环境变量中，谁知道怪事发生了。

在httpd.conf中，有如下的配置：

SetEnv EXTMAIL_TEMPLDIR "/var/www/extmail/newhtml"

可是在perl代码里，却死活没办法通过访问$ENV{'EXTMAIL_TEMPLDIR'}来获得这个值。

开始有点怀疑是不是自己写错了，查了一下Apache的docs，看看配置指令有没问题，可又没发现问题。又在google上到处搜索，甚至搜索到了perl的beginner 的邮件列表，可是所有有关的问题都几乎是一样的答案，通过SetEnv传递环境变量。

后来，忽然想起自己的extmail是工作在SuExec+SELinux双重保护的环境里，会不会因为这个原因导致了自定义的环境变量被屏蔽掉？

于是做了一个试验，关闭了Suexec，结果就成功了。于是还是老老实实的仔细看Apache手册的env模块，才发现了根源：

Some Caveats

It is not possible to override or change the standard CGI variables using the environment manipulation directives.

When suexec is used to launch CGI scripts, the environment will be cleaned down to a set of safe variables before CGI scripts are launched. The list of safe variables is defined at compile-time in suexec.c.

For portability reasons, the names of environment variables may contain only letters, numbers, and the underscore character. In addition, the first character may not be a number. Characters which do not match this restriction will be replaced by an underscore when passed to CGI scripts and SSI pages.

第二段就写得很清晰，“the environment will be cleaned down to a set of safe variables before CGI scripts are launched.”。

只怪当时心切没耐着性子看，当时也没联想到Suexec的问题。

知道这个问题的根源以后，设计又可以继续下去

Posted by hzqbbc at 02:32 PM | Comments (0)

October 20, 2005

Email threads algorithm - 邮件线索排序算法

很早以前,一些邮件客户端,例如Netscape 等就支持邮件的线索模式，在线索模式下，可以很有条理的阅读邮件.

邮件客户端becky我曾经使用了相当长的一段时间，原因之一就是因为它支持线索模式，这样可以很方便的查看与某些朋友的邮件来往,尤其是订阅了邮件列表后，每个话题及回复都看得很清晰。

不少线索排序都是使用jwz算法. 地址: message threading

根据jwz的介绍，jwz算法相当可靠，也许在不久的将来，邮件线索排序技术将用于Extmail :-)

相关的链接