2012年3月27日星期二

AutoProxy与SOCKS代理DNS

Firefox的network.proxy.socks_remote_dns选项可设置在使用SOCKS5代理的时候,DNS解析是在本地设置的服务器上还是在SOCKS代理服务器上。用AutoProxy时,对Twitter这样DNS被污染的网站,按理说socks_remote_dns必须为真才能打开。可是在about:config里面把这个选项关掉后,Twitter还是能打开。

后来怀疑是Autoproxy的问题。以安全模式启动Firefox后,插件都被禁用,该开关选项生效了。开着,Twitter能打开;关了,Twitter打不开。

用Wireshark抓包,可以看到用AutoProxy(版本0.4b2.2011041023)的时候,不管socks_remote_dns是什么值,都看不到DNS数据包。又在用户档案的extensions/autoproxy@autoproxy.org里面查找这个选项,在chrome/content/proxy.js里面看到:
/**
 * Refresh proxy name & available proxy servers
 *
 * newProxyInfo(type, host, port, socks_remote_dns, failoverTimeout, failoverProxy)
 */
proxy.server = []; proxy.getName = [];
for each (var conf in proxy.validConfigs) {
  proxy.getName.push(conf.name);
  proxy.server.push(pS.newProxyInfo(conf.type, conf.host, conf.port, 1, 0, null));
}
可以看到AutoProxy确实把socks_remote_dns设置成了1,所以在about:config里面设置也无效了。这样做的好处是用户无需知道这个选项,也可以打开被DNS污染的网站,但是最好在文档里说明一下。

2012年3月26日星期一

Bash提示符的Bug

当用户在passwd文件中的家目录最后有"/"时,Bash的提示符中"\w"指代的家目录不能缩写为"~",而是原样显示目录。我汇报了这个bug,但是作者并没承认,更没打算修复。

如果咬文嚼字,这个还真可以不算bug。Bash的手册里这么写的:
\w    the current working directory, with $HOME abbreviated with a tilde (uses the value of the PROMPT_DIRTRIM variable) 
因为这种情况下,"current working directory"是去掉"/"的,而$HOME还是有"/"的:
user@host /export/home/pan$ echo $PWD
/export/home/pan
user@host /export/home/pan$ echo $HOME
/export/home/pan/
这俩变量不相等,所以没有缩写,即使它们在“物理上”是同一个目录。但是这个问题修复了的话,可以让这种特别情况下的提示符依旧缩写,对用户更友好。

2012年3月24日星期六

Dropbox的Case Conflict

修改了主页后,用rsync同步,看到如下的画面:
*deleting   images/rms/17am/7.JPG
*deleting   images/rms/17am/4.jpg
*deleting   images/rms/17am/3.JPG
*deleting   images/rms/17am/2.JPG
*deleting   images/rms/17am/12.JPG
*deleting   images/rms/17am/10.JPG
*deleting   images/rms/17am/1.JPG
<f+++++++++ images/rms/17am/1.jpg (Case Conflict 1)
       66998 100%    3.19MB/s    0:00:00 (xfer#9, to-check=103/1237)
<f+++++++++ images/rms/17am/10.jpg (Case Conflict 1)
       90494 100%    3.92MB/s    0:00:00 (xfer#10, to-check=101/1237)
<f+++++++++ images/rms/17am/12.jpg (Case Conflict 1)
      101524 100%    4.21MB/s    0:00:00 (xfer#11, to-check=99/1237)
<f+++++++++ images/rms/17am/2.jpg (Case Conflict 1)
       76399 100%    2.91MB/s    0:00:00 (xfer#12, to-check=97/1237)
<f+++++++++ images/rms/17am/3.jpg (Case Conflict 1)
       83717 100%    3.07MB/s    0:00:00 (xfer#13, to-check=95/1237)
<f+++++++++ images/rms/17am/4.JPG (Case Conflict 1)
       20923 100%  756.76kB/s    0:00:00 (xfer#14, to-check=93/1237)
<f+++++++++ images/rms/17am/7.jpg (Case Conflict 1)
       77626 100%    2.74MB/s    0:00:00 (xfer#15, to-check=91/1237)
这些图片没有改,怎么要传送,而且出现了Case Conflict 1的字眼。

在rsync的手册里面翻了两下没看出来原因,到这这几个图片所在网页才明白。原来我的缩略图叫1.jpg,而放在同一个目录的大图叫1.JPG,其它几个图片也是如此命名的。最近用了Dropbox,这些文件同步的时候被Dropbox改名了,两个文件扩展名大小写改成一样,其中一个的文件名后加上了(Case Conflict 1)。这应该是Dropbox为了和Windows、OSX等系统下对大小写不敏感的文件系统兼容而为。

那我只好避免这种命名方式了。

2012年3月9日星期五

Bash长行换行问题

发现Bash命令行里面敲的字符超过一行的话,后面的字符不会从下一行开始,而是从提示符开始覆盖。这样覆盖一行后,再输入才会换行。初步锁定问题在PS1变量上,PS1是:
\e[35m\u@\h \w$ \e[0m
如果没有颜色的PS1就没有问题。

后来搜索到解决办法了,要用\[\]把非打印字符括起来,这样Bash就不会糊涂不知道光标在哪里了。其实Bash的手册里面有介绍\[\]在提示符中的作用。

2012年3月1日星期四

SSH登录太慢

从CentOS 6.2用ssh连接Solaris 10很慢,加上-v参数后看到:
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
debug1: An invalid name was supplied
debug1: Next authentication method: publickey
......
是两个GSSAPI的认证等待失败导致登录很慢。看了Solaris上的sshd_config(4)GSSAPIAuthentication默认打开,CentOS上的ssh_config(5)GSSAPIAuthentication默认也是关闭,但是/etc/ssh/ssh_config中却打开了该选项,这导致ssh尝试了GSSAPI认证。

解决办法很多,要么在服务器端的sshd_config中关掉该选项,要么在客户机的~/.ssh/config或者ssh_config中关掉,或者用ssh -o GSSAPIAuthentication=no来登录。真是:*nix is like a box of chocolate, you never know what you are gonna get.

2012年2月24日星期五

Iptables的nat表

Iptables的nat表,看其名字,乃是Network Address Translation的缩写。我用过nat表的几次都是路由器在不同网段之间转发报文需要做NAT。现在碰到如下的情况:
笔记本电脑是配置成一个网桥的,两个网卡配置在一个网段,只需开启内核的转发和Proxy ARP两边网络即可打通,无需用iptables做NAT。

现在要用Dell作透明代理,要把192.168.2.5这边发出的所有对80端口的访问,转到Dell的3128端口。一般是用下面的一条iptables规则:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
可是这里没有地址转换,是不是不应该用nat表?经过研究,其实nat表不一定必须要做NAT。iptables的手册里面写着:
nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of three built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering locally-generated packets before routing), and POSTROUTING (for altering packets as they are about to go out).
例如PREROUTING链,在数据包进入的时候就要穿越,所以上面的iptables规则自然是可以用在网桥上的。
iptables的报文处理顺序
用iptables,一定要搞清楚报文处理顺序了,这样就能真正理解其用法了。推荐Linux Home Networking上的上图。

Squid+Nginx地址结尾的斜杠问题

前面用Squid(3.1)作反向代理,端口在3128;后面是Nginx(0.8.54),端口在8080。Squid的配置如下:
http_port 3128 vhost
cache_peer 10.146.18.213 parent 8080 0 originserver
对于HTML文件,工作正常。但是对目录,如果在访问地址后面有"/",访问正常;但是如果去掉"/",则URL会由
http://cache.fatduck.org:3128/dvorak
变成:
http://cache.fatduck.org:8080/dvorak/
相当于浏览器是从Nginx而不是从Squid得到了应答。而在生产环境中,Nginx的监听端口8080可能是被防火墙阻止的,这样没有"/"的话,这个请求就得不到应答,难于看到问题。
没有"/"时的HTTP报头
我的理解是Squid转给了Nginx,Nginx对目录请求自动在后面加了"/",这样301之后就不返回请求给Squid了。解决办法是让配置Nginx,让它在目录后面显式地增加"/":
if (-d $request_filename) {
        rewrite ^(.*[^/])$ $1/ break;
}
之后的报头就没有301了:
解决问题后的HTTP报头
这样URL不会变,还是http://cache.fatduck.org:3128/dvorak,甚至连最后的"/"都没有,尽管我们在Nginx里面重写URL加了"/"。