teamol=WebCollab

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

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

一般正规一点的网络环境,大多是这样的:防火墙后分为内网和中立区(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

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

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

始终割舍不下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阅读网站也可以使用同样的方式达到目的。

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

麻烦一连串儿

主机不是被封了么,有些朋友就又了其它的选择,退出合租,用其它的空间,这很正常,可其中偏偏有位台湾朋友,当初打款过来的时候就费了些周折,还一下子交了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

HTTP–>HTTPS

我无法愤怒,因为不知道该生谁的气。

几天前,网站突然无法访问了,没有响应(不是reset),一开始还以为事网络的问题,后来发现不是,用其他国外主机作跳板可以正常访问,也就是说,在出国的网络出口被DROP了。

我和我们合租的邻居们不会有什么过激的言论,也没有什么PORN的内容,咋就这样了呢。没有客服,原因也没法找了,只能先恢复访问,向MT提交了support request,很快(33分钟后)就得到了的IP,应用在主机上,谁知才2天,又完蛋了。

现在要了第3个IP(这次的响应速度更快,12分钟),同时准备把所有http访问重定向到https访问,算是有些强制吧,弄了个脚本定时执行。没办法,没有别的招数,如果再被封,我也回天无术了。

使用https方式访问网站,速度上没有太大的影响(会有一点点的,服务端加密和客户端解密要耗时),关键事客户端会弹出一个非信任证书的提示,接受或者同意或者永久同意即可,FF3会出一个提示页,上面也有按钮可以添加证书为永久信任证书。如果我们每个域名都单独购买证书的话也不是不可以,不过费用不菲。

http到https的导向其实很容易,用rewrite:

RewriteCond %{HTTPS} !on [NC]
RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

为了使用方便,专门搞了个小脚本,在每个网站的根下添加.htaccess文件,在所有子目录现有的.htaccess文件中添加/更新这段内容。

和wordpress配合使用的时候,遇到了一些麻烦,浪费了我2天2夜的时间,也许还浪费了1个IP,如果早弄好也许第2个IP就不会出事了。这个问题就是,rewrite后重定向到https又会被重定向回http,把rewriterule仔细得看过来看过去也没找到错误,后来发现问题在wordpress上,只要在设置中把2个网站地址更改为https开头就行了。原先的转向死循环就是因为rewriterule把http转向到了https,然后wordpress发现访问地址和网站地址不一样,又给转向回了http。

如果无法进入wordpress的管理界面,也可以直接更改数据库,表wp_options中,option_name为siteurl和home这两项,option_id分别是1和46。

再次赞 (MT)的服务,鄙视国内的网络侦探。

参考

好像其他人也有类似遭遇

Update @ 2008-06-26

取消了强制https,原因一来感觉https消耗的资源和影响的速度比预想中的要多,二来强制也只是相对的,有点知识的就能够绕开,三来没有证书(即使购买了证书也不可能所有域名合用),麻烦多多,FF里有吓人的警告,IE下要狂点确认,很多工具也不支持https,四来取消了强制并不代表https不可用,革命靠自觉,感觉有危险的时候用户自己就知道用https了。

新的广告交换、51.la统计和web标准

标题又有点风牛马不相及,不过还是有那么一点点关联的,再说了,一篇文章的内容相对广泛,不仅有利于SEO,而且还会给胡乱转载者以困惑,同时还不会干扰正常转载、引用的朋友,嘿嘿。

首先说今天我第一次见到的网站广告交换–BlogUpp,感觉很新颖,很方便,就顺手也弄了一个,放在右边的广告下面,感觉特点如下:

  1. 不用注册,直接输入网址,就得到一段代码,扔网站页面上就行了。
  2. 交换广告是竖向排列的两个,固定的大小和布局,至少目前没得选择,不过适合blog这种右边大条空白的情况。
  3. 加载的时候,先显示文字,然后加载图片,当然文字和图片都是从每个网站上攫取出来的,中文支持良好。
  4. 正常显示广告的情况下,一般是显示图片,鼠标滑过的时候,切换为文字内容,既用图片吸引了眼球,又能让读者根据文字内容来了解是否真的需要打开浏览,应该说这一点我觉得是它设计最好的地方。
  5. 提供两种形式的代码,一种是iframe另外一种是style+div,我鸡蛋里挑点骨头:第二种里面的target="_blank"这种用法是不符合w3c标准的。

之所以对w3c标准如此敏感,是因为下午刚刚为51.la统计代码无法通过w3c验证而头疼(验证的不是本blog的页面,选用dtd是XHTML 1.0 Strict)。先来看一下这段代码吧:

<script type="text/javascript" src="http://js.users.51.la/272422.js"></script>
<noscript><a href="http://www.51.la/?272422" target="_blank"><img alt="&#x6211;&#x8981;&#x5566;&#x514D;&#x8D39;&#x7EDF;&#x8BA1;" src="http://img.users.51.la/272422.asp" style="border:none" /></a></noscript>

w3c的validator一检查,错误就出来了,主要有两处,一处比较简单:

document type does not allow element "a" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag . 

就是说a不应该出现在这里,它属于inline元素,应该被包含在block元素中云云,img也是一样,解决方法是用p或者div元素来包含他们就可以了。

而第二个不兼容就比较棘手了:

there is no attribute "target" . 

也就是`target=”_blank”这种用法是标准不允许的,这个问题着实难解决了点。

有朋友说了,你不会用js来实现么?的确,网上有解决方式是先赋予a链接rel=xxx属性,然后用js判断属性再脚本运行时添加`target=”_blank”属性,或者直接用js打开脚本的也算一种方法。

可是各位,你们没有发现,这个链接是在<noscript>标签中么?这个标签中的代码只有在浏览器不支持js的时候才会显示,试问,在不支持js的浏览器中,刚才的js解决方案还能用么?

最终,我也没有更合适的解决方案,只有把`target=”_blank”去掉,然后在旁边注上一行字:

<noscript>
    <div>
        <a href="http://www.51.la/?272422">
            <img alt="&#x6211;&#x8981;&#x5566;&#x514D;&#x8D39;&#x7EDF;&#x8BA1;"
                src="http://img.users.51.la/272422.asp" style="border:none" />
            Tips: 在新窗口中打开链接,浏览更方便(点鼠标右键)。
        </a>
    </div>
</noscript>

我想,目前也只能用这种方式解决了吧,好在不支持js的浏览器、又是人在用的(非机器人),应该不多。

其实,51.la代码的兼容性之所以被发现,之所以不得不改,也不是我吹毛求疵,而是用了eclipse之后,它的语法检查给发现的(够强大的),实在是不习惯看到一对error和warning在下面待着,“被迫”修改代码使它们更加“标准”,我想这也是eclipse的一个优点吧。

PS: 在BlogUpp缩图中我网站的首页太难看了,一个图片也没有,hmm…,有没有好一点的wordpress两栏布局模板,突出文章内容的?偶也换换?

参考

Update @ 2008-05-12

看到妖精BlogUpp的上下布局给横过来了,猜测是自己手工改的,官网上好像没这个功能啊。。。