conoha 变得不稳定,搬迁站点到 vultr ,顺便把 php 升级了php7.

WordPress 4.7 完全适配默认的 php7, 需要安装 php7.0-gd.

Dokuwiki 麻烦点,虽然它的最新版本已经适配 php7, 但很多插件太老,而且插件依赖的 php 模块需要额外安装, 比如 php7.0-mbstring, php7.0-xml。 另外,/var/log/nginx/error.log 会频繁产生 Declaration of 的 warning , 在 dokuwiki 入口手动添加了以下代码来屏蔽:

当然,别忘了把 nginx 站点配置里的 /var/run/php5-fpm.sock 改为 /var/run/php/php7.0-fpm.sock

搬完后访问速度飞快——升级到 php7 是一部分原因,但主要还是网速变快了(▭-▭)✧

听说全球网站上 https 的已经超过 50% 了,然后再考虑国内大部分网站都没上,那岂不是意味着国外网站基本都上了 https? 这也难怪 chrome 浏览器敢说不久以后会对不上 https 的网站弹不安全警告。

个人网站,首选免费 CA, 免费 CA 基本就是 Let’s Encrypt。上去看了一下,搜了很多博文,发现博文都老了,没有参考性。因为官方提供了个 certbot 工具, 于是这事情就变得非常简单:

  1. 在 ubuntu14.04 获取 certbot (吐槽一下,网站上面的分类说明也太详细了!):wget https://dl.eff.org/certbot-auto
  2. 由于用的是 nginx, 直接执行生存证书:./certbot-auto --nginx; 记得加执行权限 chmod a+x certbot-auto;这样就ok了! 看说明 --nginx还是 alpha 版,所以不放心的要事先备份下 nginx 的站点配置。执行命令后只需要选择域名与输入邮箱,没错误的话,nginx 站点配置就自动更改到 https 了。
  3. Let’s Encrypt 的证书有效期三个月,剩余一个月时需要续期,可以用 cron 添加计划任务来执行 /path/to/certbot-auto renew --quiet, 这个命令续期后,需要重启 nginx 来生效。 官网也有插件来提供续期后的 post 任务,不过个人站点就不用这么严谨了,直接加个计划任务在续期操作十分钟后重启 nginx。

OK,搞定。

花的时间比我写这个博文还少,难怪那么多网站都上 https 了。

在做一个 RESTFul API 的认证时,碰到一个问题,花了一个半小时才搞明白。

认证由于没上 https(内部用), 所以最好用类似 amazon 早前使用的 hmac-signature ,这样至少可以对 request 的 Date 进行限制,刚好使用的 API 框架 restify 的自带插件支持 http signature, 只是稍稍复杂点,于是整套认证逻辑就写了几十行代码,就可以着手进行验证,这套 API 设计时文档使用了 Swagger , 可以很方便得在 swagger.yaml 要求加上 Date Header 和 Authorization Header , swagger-ui 那边就能直接在浏览器上进行这个认证的验证测试。

然而,测试结果发现请求头里需要的 Date header 消失了,却没有任何提示。随后在本地写测试代码,却没有问题,所以怀疑是 swagger-ui 这边有 bug,心痒难绕,便一层层找依赖看代码,打日志执行调试,日志一直打到最后执行添加头的地方,却没有发现任何异常,这个 Date header 执行时就像凭空消失了一样。上 github 在 issues 里搜索,也找不到相关信息。

正无所适从时,修改发现,date 头改名为 datee 或其它,就能正常在 swagger-ui 的请求头里出现,当时想了一下,莫非是 date 头被浏览器禁止了? google 了一下,果然如此,浏览器里使用 XMLHttpRequest 时,date 头是被禁止的! 具体可看 MDN标准里已有写明。于是问题解决。

这事的教训是:

  • 不熟悉的领域出了问题,简单查看代码以及 issues 没有找到原因时,就可以先怀疑是不是自己不熟悉这个领域的标准。去查看标准或者询问相关领域熟悉的人。现在想来,如果有人知道这点,那么问一句的时间就能解决。
  • 执行最好有明确反馈。标准里规定请求出现这些被禁止的头就会直接中断请求,然而标准也说了标准只是行业建议,不是具体实现。如 MDN 上所述,在 XMLHttpRequest 里设置头时,这些被禁止的头标志是被浏览器(user agent) 完全控制的,而浏览器表现的行为是直接过滤掉这些头标志,却不给提示,这会让不了解的人感到困扰。
  • 实际上,这不算是什么问题,毕竟本地测试代码已经通过了,有问题的不过是文档页面上的接口测试使用不了认证,不能让使用者在浏览 API 文档时直接使用接口调试功能。这个问题可以记录并延后处理,优先来实现更紧急的部分。一心一意是好习惯,但做工程,团队协作,还是要统筹一下。回想起来,当时对这个问题没解决是抱着一种很焦虑的心态, 那么,记录,放入 todolist,并评估,这样应该能缓解很多。

因为业务需要,需要对酷比魔方 u27gt 超级版 u33gt 进行 root, 试过了市面上所有的一键 root 工具, 比如 “root 大师”, “KingRoot”,”root 精灵”, 以及腾讯360百度等大公司提供的 root 工具,都不成功。

无奈,考虑手动从出厂固件里 root。 google 搜索”root 原理”, 第一条结果知乎的解答还算详细。 基本是拷贝一个 4755 权限的 su 文件到 ”/system/bin/”目录,手机端可配合 ”SuperSu”应用,adb shell 则直接命令 su 即可获取 root 权限。

google 搜索 “su download”, 找到一个su更新包的下载链接, 解压出来后, 里面包含各个cpu指令集的编译后su文件,有arm, arm64, armv7,x86等版本。查看了下酷比魔方的cpu,型号是 MTK8163, 处理器模块是ARM Cortex-A53, 查看 arm 官网的介绍, 应是 ARMv8-A, 所以选择 arm64 版本的 su。

另外也下载了下 SuperSu.apk。 google play 就有,或者其它地方下载。

然后去下载出厂固件, 然而官网的 u33gt 固件链接并不能下载, 第一天官网客服电话无人, 第二天打通了, 加入官方售后群, 提供了一个百度网盘地址,顺利下载。

固件解压后, 是个纯粹的 nand flash 刷机软件, 并没有单纯的升级包固件,由于对酷比魔方的 recovery 并不了解(这需要之后研究下)。 所以首选是把其中的 “system.img” 解压并添加 su, 再打包。

尝试使用一般的镜像工具(daemon tools, ultraiso), 并不能解压;尝试在 ubuntu 下 mount 也不行。 使用命令”file system.img” 查看显示”HIT archive data”。 网上搜索看到unpack HIT archive data, 了解了原来这是个 ubifs 文件系统的 img。 linux 内核已支持了 ubifs ,并有指令 nandsim 来模拟一个 nand 设备加载为 mtd 设备。

期间碰到问题,参考这篇博客,仍然不能解决,于是去查找 nandsim 的参数设置。

结果原因是 ”nandsim” 这个指令最多只能模拟 page size 为 4k 的 nand 设备。 而我手头的 system.img 用 ”xxd system.img | more”查看, 已经是 16k 的 page size。 参考这个文章挂载 ubi 镜像及反向制作.doc,查看”nandsim”的源码, ”nandsim.c”并无最新改动。 模拟这条路走不通了!

似乎只能去找一个 16k page size 的 mtd 设备在加载 system.img。 然而柳暗花明又一村,同事在 github 上搜索到一个 ubi_reader 项目, 可顺利解开 system.img !!

在拷贝完 su, 重新生成 ubifs 与 img 的时候, mtd-utils 工具里的 mkfs.ubifs 与 ubinize 都报错,提示 leb 超过 max. google 搜索报错提示,发现是作者在源码里定义了宏限制了 2m 的最大值。而我这个为 4m, 其实有的设置是 32m, 所以这个最大限制很不合理, 也有人提了去掉这个最大值的代码,然而作者不为所动,一大堆口舌后的结论是“限制保留,如果超过,自己改源码编译”。 于是只好下载源码, 上限改为 8m(对应的两工具头文件都需要改),自行编译。因为这个项目已有 deb 包,所以可以用 ”sudo apt-get build-dep mtd-utils”来先安装依赖,然后”make”, ”make install”。

之后重新打包镜像成功。

然而打包后的新的镜像文件 system.img 线刷进去后,并不能启动,系统自动重启到 recovery 模式。 怀疑是重新打包后文件过大, 于是调整文件“MT8163_Android_scatter.txt”里的system大小,重新刷新,结果仍然不行。

转换个思路,试图通过 adb root 指令来直接获得 root 权限。 这要修改boot.img 里的 default.prop。 使用 mtk-tools 解出官方包里的 boot.img, 在default.prop里修改 ro.debuggle 等相应属性,打包成新的 boot.img。线刷进去后, adb root 有提示, 然而 adb shell 进去后仍然不是 root 身份。 怀疑这个只在 andorid 2.0 时代才 OK。 此条路显然也走不通!

未完待续。

这次总算没忘了搬迁,先怀缅下之前消失的几个博客.

搬迁倒是顺利,对于一个程序员来说,碰到的问题都不算是问题,小记录一下,方便下次搬迁

  • 运行环境倒是简单, ubuntu 14.04 只需要 sudo apt-get install php-fpm php-gd php-mysql mysql-server.
  • mysql 建立用户; 使用 mysqldump 导出 xxx.sql; 再使用 mysql -u -p dbname < xxx.sql 导入; mysql 基本操作.
  • wordpress 除了 mysql 内容, 还需要拷贝 wp-content 文件夹, 当然, 也可进入该文件夹拷贝具体的插件,主题或上传文件.
  • 由于使用了 nginx 而不是 apache, 具体的 nginx 配置需要参考 wordpress 官网文章, 但是 php pathinfo 模式需要额外修改, 可参考我在 github 上的备份
  • 修改 wp-config.php 文件, 如果没改动就照搬老博客设置. 然后直接就可以进首页了, 不需要额外 install.
  • 搬迁前后的 wordpress 版本不一致, 数据库结构可能有变动, 不过幸好 wordpress 自己处理了. 下次搬迁最好版本先一致, 搬迁完成再更新.