芳草苑

Category: 小小草

IT 技术领域学海无涯。其实任何领域都学海无涯，无非 IT 发展太快了，让我有更多嘘唏。希望我掌握的技术有如小小草，虽然渺小，却有旺盛的生命力。

  • eu domain transfer

    最近被 Lycos.co.uk 搞得够呛。它突然洗手不干了，估计是因为经济危机的关系。一个不想继续经营的公司服务质量是无法保证的，而且连个 complain 的地方都没有！

    我用到 lycos 的地方并不多，但还是在域名转移上有点麻烦。有几个 eu 域名委托 lycos 注册时，lycos 把联系人邮箱填为我的 lycos id，这个 id 已经无效了。而我一直认为 eu 域名转出需要原注册商的配合，所以反复请求 lycos 支持，而 lycos 爱理不理。事实上并不需要 lycos 配合。现在无暇去研究这个转移模式是否合理，能转成功已经谢天谢地了。

    以转到 godaddy 为例，godaddy 称之为四部曲：

    1. Initiate
    2. Authorize
    3. Accept/Decline
    4. Completion

    前两步几乎是同时完成的，只要在 godaddy 账户里点点鼠标就可以，第三步比较关键，但 godaddy 说

    The transfer is waiting for the customer to accept it at the losing registrar. If the customer does not accept the transfer at the losing registrar within 5 days, the transfer will be accepted automatically.

    这么说默认是 Accept 。如此很好，只要等上 5 天，域名就到 godaddy 账户项下了。

  • nginx has no path_info

    ngnix 0.6.35 没有实现 path_info。不知道 nginx 开发者是疏忽了，还是觉得没必要在 http server 层实现 path_info。我印象中有很多 php 程序的运行都依赖 $_SERVER[‘PATH_INFO’]，所以在 ngnix proxy pass 给 php-cgi 之前，必须设置好正确的 path_info 参数。

    我认为最好的办法还是用正则表达式在 $fastcgi_script_name 里隔离出 script_name 和 path_info，但这样计算出的 path_info 用起来不如 ngnix variable 方便，而且得在脚本的安装位置或扩展名确定时才能写出相应的正则表达式。我是 nginx 新手，在 path_info 上折腾了三天才总结出一个相对满意的方案。如果 nginx 能给我一个 in-built variable $path_info，那会省事很多。

    当然我并不想责怪 nginx（apache 已经够令人称赞了，nginx 能超越它实属不易），说不定 nginx 不搞 path_info 有它的道理。 既然这样，php 编程时就应该考虑到 path_info 是不可靠的。以前我不太注意环境参数的获得性，如今审视了一下，除了 $_SERVER[‘PATH_INFO’]以外，$_SERVER[’PHP_SELF’] 和 $_SERVER[’SCRIPT_NAME’] 也是不可靠的。

    $_SERVER[‘REQUEST_URI’] 和 $_SERVER[’SCRIPT_FILENAME’] 相对可靠。

  • Godaddy dedicated server is faster

    我刚注意到 Godaddy 注册了一个 Tax ID EU826010755，开始对 perchase from the UK 征收 VAT，当前是15% （我在 2月份时仍是免 VAT的）。我不晓得这种财务变动是否伴随着基础设施的变动，可能这种变动已经发生。因为我注意到我的 Godaddy dedicated server 莫名其妙快了很多。

  • Windows support hard link and symbolic link as well

    很多地方在解释 Linux 软连接时都喜欢把它比作 Windows 的快捷方式（当然它们是有实质区别的），而且在解释硬连接时找不到 Windows 下的对应事物。

    但，我绝没有想到 Windows XP 也能建立如同 Linux 下的硬连接（真正意义上的硬连接，最简单的办法就是下载 Link Shell Extension 来用），据说 Vista 还能建软连接。是不是我的思维太激进了，总认为 Windows 要成为末日黄花？我看到在 Linux 下很普通的技术在 Windows 里也有就觉得很惊奇。

  • Format date in merge field

    Formating date correctly is one of the troublesome work in all computer languages because remembering how to format is difficult.

    In Microsoft Word, the formatting process is –

    1. Press Alt+F9 to show the merge field code
    2. Add the format string to {MERGEFIELD mydate }
    3. The code looks like {MERGEFIELD mydate \@ “dd/MM/yyyy” }

  • I can’t find a way to assign two handlers to a script

    这可能是一个不可能实现的任务。

    Actinic 的动态部分是 perl 写的，我不想触及 perl，陆陆续续做了很多 extensions，都是 php 写的。Actinic perl 有很多漏洞，其中一个就是会把我的 php 源码暴露。可能 Actinic 的目标用户都是 htmler，根本没指望 phper 会给它写 extensions（我也是没办法，早就不想干了）。我能做的，就是尽可能地调整 php 的代码方式，做到即使源码暴露了，也不包含机要信息。

    我也不打算在 Actinic 浪费时间去研究怎么修改漏洞，只是最近把 apache module 研究了一遍，突然想重提这个历史遗留问题是否可以从 apache 方面给予弥补。漏洞的源头是 Actinic perl 读入我的 php script，当成 html 直接输出。如果能把 handler 再交给 php-cgi，那么 php tag 之间的内容就可以得到解析。

    可是 apache 是以后缀推定 handler 的，那么某个后缀怎么可以有两个 cgi handlers?

  • I can’t find a way to group releted transactions in PayPal history download

    I have tried all formats of PayPal Download History, and found “Comma Delimited – All Activity” is the most comprehensive one. I send it as an attachment for your review. My problem with this history is – every transaction has a different Transaction ID, it is not give me enough information to group related transactions. Basically, it is missing a column Parent Transation ID (or call it Related Transaction ID, whatever).

    Some virtual terminal transactions have an update transaction, some don’t (depends on whether AVS matches). I can’t use any ID number to trace a update transaction back to its parent transaction ID, so I might calculate one transaction twice.

    PayPal should improve its data download format. At least, it should provide an extra column of “Parent Transaction ID” (indicate its parent transaction if any), or “Unique Tranaction ID” (all related transactions have a unique transaction ID) for me to group related transactions.

  • Zend PHP Server is out

    事情总是很凑巧，这两天我在找 PHP Application Server，没找到理想的——

    1. Phplens 虽然有我想要的功能，但做得太粗糙，而且不免费（免费的只支持30条记录，毫无用处）。
    2. Zend Platform 高不可攀。
    3. Phpappl 虽然免费，好多年前停止更新，不敢用。

    今天 Zend 告诉我说，PHP Server 发布了（虽然还是测试版）。看来同我一样有这种需求的用户不少，被 Zend 盯上了。但各人对 application server 理解略有不同，不晓得 Zend PHP Server 是不是就是我想要的 PHP Application Server，得抽空试用一下。

  • So many bugs in ispconfig

    ispconfig 可以做 hosting account management，但给我的感觉是打磨得不够精致。如果把它应用到生产环境，如果不怕客户抱怨，如果喜欢捉虫游戏，那倒可以用 ispconfig，毕竟免费的嘛，我看功能跟 isp 自己开发的 control panel 差不多（如 godaddy 的 turbo panel）。我感觉 ispconfig 还无法跟 cPanel, plesk 相抗衡，用在开发环境还凑合。

    凭我的肉眼，我就发现了以下几个说大不大，说小不小的毛病。

    按 ispconfig installation on Fedora documentation 一步步安装完毕以后，其实并没有安装 mod_fastcgi 或 mod_fcgid （暂且算是 documentation 失误吧），但控制面板里已经可以选择 php 模式为 fastcgi。我只好自己摸索着装 mod_fcgid。

    但未装 mod_fcgid 倒没有问题，装好 mod_fcgid 重启 apache 反而会出错。因为 ispconfig.conf 里预设的 <IfModule mod_fcgid.c> 生效了，而里面一条 FCGIWrapper /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter .php 会出错。原因是 /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter 不存在，又得自己动手制作一个。

    另外一个问题是，新建第二个站点时，ispconfig 不会自动添加 namevirtualhost directive，导致 apache 启动时会有一个 warn message，但不致命。

    综 上，ispconfig 对 conf 文件生成和管理得不是很好，而 ispconfig 本身也是基于 apache 的 conf 来配置的，所以 ispconfig 一不小心就搞砸了，连 apache 都启动不起来，连更正的机会都没有了。用着 ispconfig，还得时刻准备着 ssh 手动去更正搞砸了的 conf 文件。

  • Do it inhouse

    技术方面，我喜欢亲力亲为，另一方面，我还没有资源可以让我不亲力亲为。

    我曾分析过 outsourcing seo 服务的弊端，here is another negative case of outsourcing email marketing.

    I received a newsletter from Tesco today, and happened to click on one of the embedded links. (I am not a newsletter reading fan. I seldom click on embedded links.)

    I got a “404 Not Found” error when I natigated to that url. After a few seconds, I became aware Tesco link tracking system is hosted on http://ad.doubleclick.net/, which is on my black list. I assume Tesco have a third party doing email marketing for them, otherwise Tesco on their own have no reason to use ad.doubleclick.net as a click tracking provider.