Archive

Archive for the ‘Internet’ Category

Curl奇怪的403错误

July 1st, 2009

自己用的小PHP应用,使用curl抓网页下来处理,为了穿墙方便,使用Privoxy作为代理,便于选择哪些网站使用proxy、哪些不用。但今天却遇到了奇怪的问题,访问google baidu这些网站居然都返回403错误,而访问其他的一些网站没事,如果设置为不使用proxy则都能正常访问。

难道google baidu就不让用proxy连接么?显然不可能,所以打开curl的信息输出(curl_setopt($this->mSh, CURLOPT_VERBOSE, 1);)看看,得到以下结果:

*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 8118 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:80
> CONNECT www.baidu.com:80 HTTP/1.0
Host: www.baidu.com:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

< HTTP/1.0 403 Connection not allowable
< X-Hint: If you read this message interactively, then you know why this happens ,-)
< 
* The requested URL returned error: 403
* Received HTTP code 403 from proxy after CONNECT
* Closing connection #0
... Failed.

可以看到proxy服务器工作正常,的确是baidu返回了403错误,但原因肯定还在我这边。终于,从网上(1of2, 2of2)得到了点启发──我使用的是proxytunnel而非proxy。

在代码中,有这么一句:

	curl_setopt($this->mSh, CURLOPT_HTTPPROXYTUNNEL, true);
	curl_setopt($this->mSh, CURLOPT_PROXY, $phost);

php文档中没有详细说明,不过man curl中有详细解释,两者都是代理,proxytunnel(-p参数)允许其他协议通过http代理传输,而proxy(-x参数)则只能走http协议。所以我猜测,google baidu的服务器和curl的proxytunnel不和,所以返回403。

禁用掉上面2行代码的第一句后,curl访问恢复正常。

比较奇怪的是,几种操作系统下还不一样,一台MAC OSX就要显式的禁用proxytunnel才可以,curl版本:

$ curl --version
curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

而另外一台ubuntu则完全不受影响,怎么都能用,curl版本:

$ curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

MT主机上的centos也没事,curl版本:

$ curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

看来不完全是curl版本问题,MAC OSX的确与众不同啊。

还有一个原因也会导致curl返回403错误,如果设置了:

	curl_setopt($ch, CURLOPT_NOBODY, true);

则需要紧跟着设置:

	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

不然会因为http服务器不允许 HEAD 命令而返回403错误。参考:Trouble with a cURL request in PHP。MAC OSX上curl之所以特殊,也不排除是这种原因吧。

Related posts

Develop, Internet, PHP , , , , , ,

teamol=WebCollab

March 1st, 2009

Team Online 项目管理系统

如果你曾经在国内某个php源码下载网站下载过一个叫teamol的团队任务分配软件,不知你有没有注意到,它和国外开源项目WebCollab之间似乎有着亲密的联系。

本来我也没注意,可这个teamol下载回来以后安装颇不顺利,文档TeamOL setup.doc和安装界面有不一样的地方,虽然国内开源项目用doc写文档不算奇怪,但这个文档内容也太少了。代码注释中有个“官方网站”http://www.inodea.cn是打不开的,代码中很多地方标的版本号是0.1,可下载时我记得说的出3.0或者3.2版本。

开始安装以后有个地方卡壳了,还没安装数据库,就要从数据库里信息来验证用户是否有权限安装。hack安装之后,path配置也有问题,模板中还有一些错误,比如明明这段函数内没有$title这个变量却多次使用,要知道即使是global $title也是没有值的。

反正歪歪扭扭总算把程序配置得能运转了,开始试试,功能倒还有点让我满意的意思,除了日期选择的弹出窗口我极其不喜欢。然后我就发现了一件让我大跌眼镜的事情,这么一个错误百出或者说有点像半成品的“国产开源”作品,居然不仅有英、中文支持,还有一个看似排版比较成熟的英文帮助页面:

webcollab-help

好奇的我挑了帮助页面中的一句话上G一搜,便找到了WebCollab。仔细比较下来,两者的目录结构也几乎一样:

dir structure of teamol and webcollab

结果应该不用我说了,也或许teamol的作者原想只是以webcollab为蓝本边学习边制作一个全新的系统吧,从注释中的版本0.1和修改过使用frame的页面框架中能够看出作者还是付出了些劳动的。

回到主题,用于小组内工作任务分配跟踪,倒是可以试试WebCollab,界面是简陋了点,基本的内容算是都有了。但这类软件,至今没找到一个特别好用的,包括很多在线的GTD或者项目管理系统。

WebCollab login

Related posts

Internet, PHP , , ,

用ssh打通反向隧道,内网也可对外提供服务

July 10th, 2008

一般正规一点的网络环境,大多是这样的:防火墙后分为内网和中立区(DMZ),并且内网和DMZ虽然都能访问外网,互相却是无法直接访问的。内网和DMZ的区别就是,来自外网的访问,都通过防火墙上的规则映射到DMZ里的服务器上,而内网一般是不允许这样的。

现在需要解决的问题就是,在防火墙只能给DMZ开端口,内网和外网不可直接互访的情况下,如果让内网的机器对外提供服务。

ssh是很神奇的,使用它创建的隧道,可以起到代理的作用,数据流的方向是:

本机 -> 隧道 -> 外网

应用到我们的问题中,如果把隧道反过来,就是:

外网 -> DMZ -> 隧道 -> 内网

这就需要用到ssh的反向隧道,它在服务器上打开一个监听端口,这个端口的访问会被隧道传输到本地,结果再通过隧道传到服务器上,从监听端口返回给客户。这样,在我们的应用中,内网机器通过外网访问DMZ服务器,创建ssh反向隧道,就能够对外提供服务了。当然,防火墙上要将相应端口映射到DMZ的服务器上。

比如,在内网登录DMZ服务器:

ssh -R 8082:localhost:82 fwolf@svr5.tld -o ControlPath=/tmp/ssh_svr5_reverse_tunnel

这样,访问DMZ服务器svr5的8082端口,就是在访问本机的82端口。之所以带上-o ControlPath,是为了和其它访问svr5的进程使用不同的master模式(如果不是第一次创建这个master,而是使用了原来的连接的sockts,肯定就不会创建隧道了)。

有几个问题还需要注意一下:

  • 如果DMZ上监听端口小于1000的话,就必须用root用户登录DMZ服务器,比如root@svr5.tld
  • DMZ服务器上的sshd必须开启GatewayPorts选项,在文件/etc/ssh/sshd_config中加入GatewayPorts yes
  • 记得不要idle,参考中有在服务端设置的方法。
  • 如果放在其它脚本,比如/etc/rc.local中执行的话,除了配置自动登录,还可以带上-fN参数,放到后台去。

参考

Update @ 2008-07-25

注意,由于使用了反向隧道,所以ssh隧道实际作用相当于一个代理,访问的来源也自然就都成了127.0.0.1,如果同时还启用了denyhosts,千万记得要把本机地址127.0.0.1放入白名单/etc/hosts.allow,不然就会成为其他登录失败的牺牲品(失败的登录,其来源也成了loopback的地址):

ssh_exchange_identification: Connection closed by remote host
Fatal error: Lost connection with the server

没办法,为了网络通道的畅通,只能牺牲一部分安全性了。

Related posts

Internet, Linux, Tools , , , , , , , ,

使用了无效的ssl证书,feedburner无法抓取feed的解决方法

June 26th, 2008

始终割舍不下https,虽然它会多消耗一些资源,但毕竟可以让网站免于某些风暴,不过M.zdpress提出了一个我没有注意到的问题,feedburner无法抓取feed了,试了一下,果然:

Feedburner retrieve https feed using self-signed ssl error

可以看出错误的原因是使用了无效的证书(当然无效,同时猜测fb使用的是Java),从证书这边着手看来是没希望了,只能换其他的方式。

前端时间在GFans里听到过可以用Google Reader实现类似feed重烧或转发的功能,遂想用这个来试一试。

首先在GR中订阅自己的feed,然后给它打上一个tag(标签),也有的地方叫folder(目录),都一样,注意tag名最好唯一、专用,不要和其他的重复,比如我就直接用blog名作标签名称。GR不像FB,证书无效也没有关系。

然后在Settings->Tags中找到这个标签,点后面的广播图标,private就变成了public,后面的链接也随之出现了:

Share a tag in google reader

在后面的几个链接中点email a link,填上自己的邮箱,发送,会收到一封信,里面有两个链接:

• View my shared items
• Subscribe to a feed of my shared items

使用其中第二行的链接,形式类似:

https://www.google.com/reader/public/atom/user/12175931868835525338/label/Fwolf%27s%20Blog

这个地址打开基本就是你原来feed的原貌!只是多了GR的一些附加信息,比如Blog标题从Fwolf's Blog变成了"Fwolf's Blog" via Fwolf in Google Reader、文章标题后来多出了个时间,我觉得这些是可以接受的,文章的内容基本不走样。

最重要的是,这个地址虽然也是https的,但它的证书是Google用于GR的,是有效的,是FB承认的,所以在FB中修改你原来的种子,把这个地址设置为Original Feed,FB就可以正常更新了。

回顾一下,其实道理很简单,就是用GR“重烧”了一个种子,转发给FB而已。至于Blog程序自带的feed地址就不用再说了吧,其他feed阅读网站也可以使用同样的方式达到目的。

最后,感谢妖精的提示,嘿嘿。

Related posts

Internet , , , ,

麻烦一连串儿

June 23rd, 2008

主机不是被封了么,有些朋友就又了其它的选择,退出合租,用其它的空间,这很正常,可其中偏偏有位台湾朋友,当初打款过来的时候就费了些周折,还一下子交了2年的,现在只用了一年,虽然人家说剩下的钱不要了,咱也无功不受禄,还是要转回去。台湾朋友更大度,你帮我捐给四川的同胞吧,由此,麻烦开始了。

先想,捐款还是到壹基金吧,反正哪儿不是捐啊,于是找到网站,一看,能用支付宝,ok,继续。

可我支付宝里没钱,从银行划过来吧,选充值,选建行,充值错误,选择证书的时候空白,哦,原来的证书忘记安装了,还在以前用vmware虚拟的另外一个虚拟机下。

好在我早有准备,证书都导出来了,找到,导入,嗯?怎么导入以后哪里也找不到呢?

左试又试,原来导入位置不能选“个人”,让系统根据证书类型自己判断,然后导入的证书就出现在“其它人”里面了,“其他人”这个位置似乎不对,不管,支付,选证书的时候还是空白。

换一种导入方式,在资源管理器打开证书再导入,一看无法验证颁发者,咋回事?上网查,原来没有导入ccb的根证书。要想把原来虚拟机上的根证书导出来,还得跑vmware。

可惜,升级到ubuntu 8.04 hardy之后,原来的vmware早跑不起来了,框框折腾2小时未果,最后好歹弄了个vmware-player,算是让虚拟机转起来了,导出了ccb的根证书。

再次导入我自己的证书,仍然如故,属于“其他人”,再上网查啊查,原来导出的时候没有导出私钥,ok再开vmware虚拟机,连私钥一起导入,到这边再导入终于出现在了“个人”中。

再支付,又失败,原来建行最近把不是用usbkey的用户的网上额度都搞成0了,我自然是懒得去买key,就是买来了也不知道和virtualbox搭不搭伙。不过咱还有招,信用卡的网上支付应该没有被停,选建行的信用卡,支付。

嗯,有效期是YY/MM格式还是MM/YY格式呢?试试吧,一试不要紧,被锁了,打电话让信用卡中心解锁,ok后让等待5分钟。

5分钟后再试,又被锁住,两种有效期格式没有一种是对的?虽然卡没在手上,但日期肯定没记错,遂再call信用卡中心,解锁之后小心翼翼的问人家,上次是啥原因被锁的,回答:CVV2输入错误。

昏倒,回家找我的卡片去,然后再来继续这些麻烦。

都说计算机是高效的,可也不知是现代人的需求也提高了,还是计算机真的本身就是麻烦;互联网虽然方便,可网速慢的时候更加要命,有时候我甚至感觉上网3小时至少有1小时是在等待(我不上一般大众网站,都是国内外技术性网站,或者连公司的网,都不快,把铁通算上,更慢了),真是应了那句话,天下本无事,庸人自扰之,可现在离开计算机互联网我们还能活么?

Update @ 当日晚

按照支付宝登录控件之后还要重启电脑,寒。。。

操作成功,大功告成,感谢我们的台湾同胞。

顺便,贴一个我们主机跑unixbench的成绩,感觉还不错,当然现在没什么负载:

==============================================================
BYTE UNIX Benchmarks (Version 4.1-wht.1)
System -- Linux fwolf.com 2.6.9-023stab044.4-enterprise #1 SMP Thu May 24 17:41:23 MSD 2007 i686 i686 i386 GNU/Linux
/dev/vzfs             20000000   5340312  14659688  27% /

Start Benchmark Run: Mon Jun 23 23:30:38 CST 2008
 23:30:38 up 6 days,  2:03,  3 users,  load average: 0.12, 0.08, 0.01

End Benchmark Run: Mon Jun 23 23:40:49 CST 2008
 23:40:49 up 6 days,  2:13,  2 users,  load average: 14.06, 5.94, 2.60


                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7 22753013.6      603.9
Double-Precision Whetstone                      83.1     1622.9      195.3
Execl Throughput                               188.3     4793.9      254.6
File Copy 1024 bufsize 2000 maxblocks         2672.0    78447.0      293.6
File Copy 256 bufsize 500 maxblocks           1077.0    21706.0      201.5
File Read 4096 bufsize 8000 maxblocks        15382.0   710319.0      461.8
Pipe-based Context Switching                 15448.6   205785.2      133.2
Pipe Throughput                             111814.6   793752.1       71.0
Process Creation                               569.3    14796.3      259.9
Shell Scripts (8 concurrent)                    44.8      848.6      189.4
System Call Overhead                        114433.5   898962.9       78.6
                                                                 =========
     FINAL SCORE                                                     207.1

Related posts

Internet, Living , , , , ,