Site5 主机的 ImageMagick 模块的问题

我在之前的文章里说过，我在 Site5 的实验用的主机上测试 Movable Type 发布时的 CPU 负载问题时，意外的发现在 MT 的 Dashboard 里面提示我说找不到 Image::Magick 模块，并且在 Site5 的论坛上没有找到答案。

我当时说应该不影响是用，但还是觉得如果能解决了最好，于是在晚上就在 Google 上搜索，找到了一篇文章。文章里说如果 ImageMagick 模块无法使用，可以在 mt-config.cgi 里面加上一句 ImageDriver NetPBM 来使用 NetPBM 来代替 ImageMagick。我测试了之后果然可以，可以正确的处理我的头像了。我没有测试在加上这一句之前有没有在发布文章时插入图像不成功的经历，反正加上后我测试发布一篇带图像的文章是没问题，包括生成缩略图、改变大小等操作。

然后我又在 Settings 里面随便点点，却发现在 Feedback 下面还有错误提示。原来是说，因为没有 ImageMagick 模块，所以 CAPTCHA 就无法使用了。我目前的 blog 也没有使用 CAPTCHA 来过滤垃圾留言，用 Typepad AntiSpam 就能过滤绝大多数留言了，而有些人工的弄一些英文的通用留言用语的，数量就不多，我手工过滤也能过滤出来。不过我想，虽然今天不用，难保哪一天会用到？总之如果能把事情解决是最好，于是抱着这种想法，我就去了 Site5 的首页找到在线的客服 livechat。

虽然我发信息过去的时候是半夜，不过 Site5 提供 24×7 的客服服务。我在输入自己的名字、邮箱地址、我的域名、以及问题之后，系统会把我的问题分配给一位客服，然后会在浏览器里出现一个对话窗口，我就在里面同他交谈。

客服首先问我我在上一步填写域名是不是指向我目前发生问题的主机，我说是，然后他进行了一些操作，估计是在后台重新安装了一下 ImageMagick，然后让我重试一下。我刷新了一下 MT，还是有问题。然后他问我是不是我需要的是个其它名字的模块，我于是提供给他这个网址，他在过了五、六分钟之后让我再试一次，如果不行的话就让我告诉他出问题的网址，他们好调查原因。我试过后问题依旧，于是就把 MT 我的帐户的名字和密码改了，告诉对方。结果对方却莫名奇妙的说需要 “submit a ticket to have this fixed for you”。我莫名其妙的想了一阵子，才觉得应该是这位客服没有权限来处理这种（或许是）涉及到客户提供的网址的问题，所以向上级提交了一个 “ticket” 来申请相关的权限。

我在等待的时候，却突然发现 chat 窗口变成了给这位客服评分的窗口，我也收到了一封措辞“冠冕堂皇”的来自 “Site5 Level 1 Support” 的感谢邮件。本来有些安心的我更加莫名其妙了。什么意思？问题就这样放着不管了吗？这样子就算解决了啊？我当下有点气愤，这算什么客服？于是我也在评分表上照实填写，服务态度、语言的语法、还有是否一直在问我相关的问题都给高分，至于是否给我提供了有用的信息和是否解决了问题嘛，低一点算了。

在提交了评分之后，我正在安慰自己没有 ImageMagick 一样用的时候，却发现我的邮箱里收到了 “Site5 Level 1 Support” 的又一封邮件，说他们已经安装了相关的 Perl 模块，让我试验一下。这时我才意识到我可能是错怪了刚才那位客服：他 “submit a ticket” 不是为了申请权限，而是直接把我的问题转移给了上一级的客服，由上一级的客服来帮助我。我于是又打开了一个 livechat，说我刚才不小心的关闭了 chat 窗口，问怎么回复问题。结果正巧碰到了同一位客服，他告诉我直接回复那封邮件就行了。我在这次评分时，全都给了高分，算是我刚才错误的补偿吧。不过 Site5 用了 “ticket” 这个莫名其妙的词来表示“问题（problem）”这个含义，并把假设询问的用户都知道这个词的含义，也算有一部分的责任吧。

我于是回复那封邮件说还是有问题，对方叫我清空 cache 再试一遍，我照做了之后自然还是不行。等我再次回复后过了一会，就收到了一封 Site5 自动发送的信，发信人是 “Site5 Level 2 Support”，说是因为我的情况复杂，这个 “ticket” 需要系统管理员的关注，因此被加入到 Level 2 的 queue 中了。果然 Site5 的客服是层级式的，这一级解决不了的问题就送给上一级。这个 Level 2 可能人手不多，我是在收到这封自动邮件之后大约四十分钟之后才收到进一步邮件，说是在看我的问题，等有结果后马上通知我。然后又过了将近三个半小时，我收到邮件说 ImageMagick 的 Perl 模块不支持 64 位环境，所以解决问题是一是我用一个替代品，二是把我的帐号转移到 32 位的服务器上。

到了这时我就觉得比较满意了。考虑到我对这个模块的需求状况，以及我这个帐号只是用来测试的，我就给对方回信说不用麻烦了，并客气的感谢对方。一会对方也回信说不客气之类的套话。

总之这是我在这两天之中遇到的第二次 64 位兼容性问题了。我在 07 年玩 Gentoo 的时候，其中有一个最关键的参数就是选择机器的 Arch。我当时的 CPU 好像是 T7300，好像是可以使用 x86_64 了，但我还是选择了 i386 架构，原因是从文档上看到还是 32 位上的软件多。当时我觉得自然而然，没有在意这个问题。结果两年后的今天，64 位大行其道，我却忽略了这个问题。不过这两个问题也给我上了印象深刻的两节课。