服务器正式启用 IPv6 啦

最近几天,我为服务器配置了 IPv6,域名也添加了 AAAA 记录的解析,也就是说我的网站终于支持 IPv6 了。当然,由于阿里云并不支持原生的 IPv6,我采用了美国 Hurricane Electric 公司提供的隧道方式接入 IPv6,因此所有流量都要在中国与美国之间绕一圈。据我测试,以这种方式接入 IPv6 的带宽还可以,服务器 2 Mbps 的上传是可以跑满的;然而延迟方面就不乐观了,大概在 350ms 左右。

我最初尝试使用 6to4 的方式接入 IPv6,不过测试下来不论是带宽还是延迟都非常不理想,只好放弃了。后来我发现,几乎所有的教育网 IPv6 出国流量都被发往了美国 HE 公司,出于减少延迟的考虑,我便申请了它免费提供的 Tunnel Broker 服务,使用 6in4 隧道方式接入 IPv6。在 CentOS 服务器上的配置我是参考了这篇文章

发表在 计算机技术 | 留下评论

将 iPad 2 固件降级到 iOS 6.1.3

前几天,有越狱大神发布了 OdysseusOTA 工具,它可以将已越狱的 iPhone 4s 通过 OTA 方式刷写 6.1.3 版本的固件。目前,这个工具对 iPad 2 的支持还没有完成。事实上,几个月前,就有人发现了可以将 iPad 2 降级到 iOS 6.1.3 的方法,不过这种方法所需要的条件更加严苛:需要用到 4.x 固件的 shsh 以及 5.0.1 固件的 shsh;而 OdysseusOTA 工具只要求机器正在运行已越狱的固件即可,无须任何 shsh。

具体步骤:

  1. 确认你拥有 iOS 4.x 以及 5.0.1 的 shsh。
  2. 利用 redsnow 0.9.15b3 将 iPad 2 降级到 iOS 5.0.1。此过程需要对应的 iOS 4.x 以及 5.0.1 的固件。
  3. 在 iPad 上检查 OTA 更新,它应该显示存在 6.1.3 的 OTA 更新。直接更新即可。
发表在 计算机技术 | 留下评论

如何证明自己不群发

        2015 春节即(yi)将(jing)来(dao)临(lai),大家都在互发短信贺新年,这时如何证明自己的信息不是群发的呢?因为我之前研究过比特币,我立刻就想到了它所用到的“工作量证明”算法。这个算法正好是用来解决这个问题的。算法大概是这样的:要寻找一个字符串,使得信息与这个字符串拼接起来的数据的某个密码学哈希值末尾有多个零。其实算法的核心原理就是利用密码学哈希的随机分布,让计算机不停工作,直到某个公认的小概率时间发生。

这看起来很抽象,下面我以这次发拜年信息为例子来说明这个算法:

  • 首先要确定要发送的信息:这回我偷了个小懒,直接用名字的汉语拼音加上 2015happynewyear 就是要发送的信息了
  • 然后规定一下加入的随机的字符串的格式:我选择了小写字母和数字作为随机字符串
  • 之后需要选择一个合适的密码学哈希算法:我选择了 SHA1 算法
  • 最后需要选择难度值:这次我选择的难度是要求哈希值末尾有 8 个零

例如我要证明 zhangboyang-2015happynewyear 不是我群发的信息,我就需要计算出消息+各种随机字符串的 SHA1 哈希值,直到遇到某个随机字符串所对应的哈希值末尾有 8 个零。
算法过程如下:

SHA1(zhangboyang-2015happynewyear/aaaaaa)
     =A9A558C5725D44C9C1A0CCD39C028DBCAF31A15C
SHA1(zhangboyang-2015happynewyear/aaaaab)
     =8F30E6253FF48D8CDD8211C778E621525D5B2A78
SHA1(zhangboyang-2015happynewyear/aaaaac)
     =6CCDC2C571D7CD9DC4078C8823DABC56A029C7BD
...more...

直到我枚举出的随机字符串为 oqkj1e,此时有

SHA1(zhangboyang-2015happynewyear/oqkj1e)
     =345EC337DADBDDBA0115669A7B7ECCF100000000

根据密码学哈希函数的特性,可以假设它产生出的哈希值是随机分布的,即可以假设产生的哈希值字符串最后 8 位十六进制数字是随机的。因此遇到 8 个数字全部是 0 的概率是 1/4294967296。此即说明算法枚举次数的期望是 4294967296。在我的计算机上,运行一次这样的算法平均消耗机时约 20 分钟。也就是说我写一条拜年信息需要约 20 分钟来计算出这个值,从而证明了我没有群发(因为要是群发的话每条消息都得花约 20 分钟,我承受不起)。

p.s. #1 要证明自己不是群发是 MHY 同学的要求 ^_^
p.s. #2 其实写一条信息平均需要的时间可以少于 20 分钟,因为我可以让它并行计算。(事实上我用了两台双核电脑来运行这个算法)
p.3. #3 羊年的第一个比特币区块大概是第 344064 号区块,它的 SHA256 哈希值前有 16 个零!

发表在 计算机技术 | 2条评论

迅盘坑爹记

这阵子想把家里一台旧的 Thinkpad T400 拿出来用,作为一个重装过 N 次系统的人,当然首先要做的事情就是给它重装系统。然而这个过程却没有我想像得那么简单,原因就在于迅盘的 Windows 7 驱动太难搞啦!

Windows 7 推出是正值迅盘走下坡路的时候,所以 Intel 没怎么考虑迅盘在 Windows 7 下的驱动问题。更坑爹的是,Intel 官方网站上给出的驱动是 2009 年的,而且是它是有 BUG 的!

这个 BUG 就是:装上这个驱动之后 Windows 各种行为会变得不正常,比如说弹出各种 UAC 提示之类的(比如打开“计算机管理”时会弹出 UAC 提示,正常情况下是不应该有这个提示的)。

解决方案(来自国外的网站,原始链接):

  1. 下载 LenovoHP 的提供的驱动。(这样做的原因是,它们的 OEM 驱动比 Intel 官方网站上的驱动要新!(╯’ – ‘)╯︵ ┻━┻)
  2. 运行它们,让它们自解压。HP 的那个自解压完毕后会启动安装程序,这时退出就可以了。(┬─┬ ノ( ‘ – ‘ノ))
  3. 把 C:\swsetup\SP48491 目录下的文件夹覆盖拷贝到 C:\DRIVERS\WIN\Turbomem\DRV 目录下。(这是因为 Lenovo 给的驱动中包含的 Intel Matrix Storage 部分不够新,需要使用 HP 的那个驱动来替换掉不够新的部分! (╯°Д°)╯︵ ┻━┻)
  4. 执行 C:\DRIVERS\WIN\Turbomem\DRV 目录下的安装程序,这样安装出来的驱动就是无 BUG 的。

p.s. 为了解决这个问题我至少给它重装了 5 次 Windows 7 系统!

发表在 计算机技术 | 2条评论

一次服务器 Kernel Panic 的经历

今天更新了一下服务器系统,然后重启了一下服务器,结果发现服务器启动失败。
打开阿里云控制终端发现是服务器 kernel panic 了,显示如下信息:

zbyzbyzby_kp

当时我怎么也想不通为何是“unable to mount root fs”,后来才意识到:是因为几天前使用 yum update 升级内核时由于内存不足导致 initramfs 创建时发生错误,既然 initramfs 都错了那么 kernel panic 也是情理之中的事情了。

事情的前因后果是这样的:
由于机器内 apache 进程占用了大量内存,剩余内存只有约 150 MB,在执行 yum update 时,yum 没有因内存不足而崩溃,软件包脚本也没有因内存不足而崩溃,但是——创建 initramfs 的时候,depmod 因为内存不足崩溃了!更要命的是,depmod 崩溃时 pty 上没有任何出错信息(错误信息在显示在 tty 上 pty 里看不到),而且 initramfs 能够被创建出来!这样,一个崩坏的 initramfs 就正大光明地进入了 /boot,然后的事情大家就都知道了。

p.s. #1 阿里云的客服态度很好~~帮我把服务器从旧的正常的内核启动了,还告诉我怎么拼手速进入 GRUB 界面。
p.s. #2 事实上 yum 也可能崩溃,此时还需要 rpm –rebuilddb 和 yum-complete-transaction 来解决问题。
p.s. #3 修复完问题之后我立马掏了 300 块钱把服务器升级到了 1GB 内存,原来的 512MB 内存实在是太捉襟见肘了。

发表在 计算机技术 | 留下评论