最近把一部分服务迁移到用 rancher 管理的容器集群环境里面去了，感觉还是不错的，而且 rancher 里自带的负载均衡是 haproxy，配置上域名证书后由 haproxy 来负责 https 的处理，后端就不用配 https 了。服务跑起来之后，在日志中发现出现类似下面错误：
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
出现地方是在用 HttpClient 请求我们自己的 https 域名时报错，看起来是域名的证书没法验证通过。
网上搜索了之后发现有很多相关的内容，但是很多都是因为访问自签名证书的域名而产生的问题，给出的方案都是在代码里取消了对域名证书的验证。而我们的域名签名是有效的，不应该会出现这种问题，我们也不需要为了解决自签名证书去取消验证，所以药不对症，得继续寻找答案。
玩博客玩了这么久，终于还是下决心把博客从 VPS 上迁出来搬到 GitHub Pages 上去，摆脱 WordPress 框架、php、nginx、mysql这一套玩意，用 Markdown 写写东西还是舒服不少。
服务器里 postfix 发邮件现在国内很多都用 QQ 邮箱来发，但包括 QQ 在内很多邮件服务商用 smtp 发邮件时会对 From 字段做检查，不允许和登录的 email 地址不一致，像 netdata 里面就没有设置 From 字段的地方，只能找这个方法直接替换掉了。
参考 链接 第一个答案中的方案，使用正则匹配替换即可。
先上图
感觉效果还不错，记录一下用的模板方便以后使用。
LaTeX 里面的 beamer 类型文档是专门用来做演讲 ppt、课件 notes 等文档的，生成的是 pdf 文件，metroplis 是一个简洁现代的 beamer 模板，在 2016 版本的 TexLive 安装时自带了，用起来还是挺方便的，起码比之前用的默认那几个模板好看一点我觉得:)
metroplis 这个模板默认的英文字体是 Fira Sans，最好是下载下来安装一下，效果不错，建议装上 Fira Sans ( light, regular, italic, bold, light italic 这几个字重)，Fira Mono ( medium, regular, bold 这几个字重) 。因为要写中文，xeCJK 包是少不了的，中文字体的选择，因为我是 Mac 系统，实验了一下直接用系统自带的苹方字体效果就很好，当然把字体换成冬青黑、华文黑等都还可以。和模板默认的英文字体搭配的话，主要字体用苹方-Light ，粗体用苹方-Regular 配合最好，大概因为英文主要字体的字重也是 light 的。
使用的模板如下：
|
|
主要看的讲师幻灯片 http://strata.oreilly.com.cn/hadoop-big-data-cn/public/schedule/proceedings
Alluxio(Tachyon) 依然是亮眼的新秀，大概由于是国人主导开发的，在国内接受度越来越高了。从去年开始关注这个项目，还给社区贡献了一小段时间的代码，对 alluxio 还是比较熟悉的，目前来看 alluxio 代码的健壮程度慢慢提高，用于生产环境的部署和维护没什么太大的问题，但 alluxio 还没有一个比较明确的中长期规划，有点看不到未来主要的发展方向或者什么特别的 feature list，而现有代码里比如 lineage API 的功能还很弱，实际上不是很容易利用现有代码去复现 Haoyuan 当年论文中关于 lineage 这一块的东西。目前 alluxio 的亮点除了兼容 HDFS 的 memory layer 存储，就是可接多个底层存储接口的统一视图了吧，把能接的存储都接了之后，再往下怎么扩展呢？另外既然有了分层存储的功能，不考虑自己实现一套可靠的底层分布式存储自己管理？
Hadoop 3.0 的发展展望也有点意思，除去 YARN 以外，erasure coding 大概某些企业内部早都有实现了吧。。存储虚拟化这个概念简直就是和 alluxio 抢生意嘛。。一模一样的统一文件命名空间概念，下面接多个存储接口，真的是有向 alluxio 学习的味道。长远来看，不如 Hadoop 把 alluxio 收编得了，技术架构上比较相似，也都是 java 开发的。从某些实现细节来看，alluxio 其实就是在做类似的重复工作，经典的单 master 多 slave 结构，thrift 用于 rpc 通信，master 使用 zookeeper 来 fail-over 等等。如果 HDFS 朝着 alluxio 的方向演进，变成 memory 为主的多级分层存储结构，这样就真的可以称得上 HDFS 3.0 了，以 Hadoop 的影响力，一统天下指日可待啊。。。
Spark 在数据计算处理框架领域基本上已经成业内标准了，当然流处理方面还是有不少竞争对手的，最近还听说 Google 又搞了个新项目叫 Apache Beam，又想在 Spark、Flink 什么的之上再封装一套统一的编程接口，也是爱折腾。
这世界变化太快，Big Data 在国内还没炒熟捞够项目资金呢，那边厢人家已经热热闹闹的开始喊 Fast Data 的号子了。这浪啊也是一波接着一波，赶紧接着游吧。
WordPress 换了个新主题，更新到最新版，发现国内访问速度慢成翔，主要还是几个重要域名被墙，还是得动手改造改造。
新版 wp 中大量使用了 Google fonts 里的字体，没有翻墙工具的话打开页面必卡，另外 gravatar.com 显示头像的域名同样被墙，而且各种热门模板里大多也用了 Google 字体，解决办法就是把所有地址都替换成国内的镜像地址，360提供了一个镜像网址 http://www.useso.com/ 手动直接替换掉就可以了。更简单点解决办法就是去装相关的插件，比如一个叫做 Useso take over Google ，会把地址自动替换掉，但这类插件一般都是跳转到一个第三方的地址再来做解析，能不能信赖这些网址自己要斟酌一下。
其实 wp.com 也有不少子域名被墙，这个我懒得搞了，要是有洁癖的话可以不用 jetpack 提供的网站统计功能，换成国内的统计。
这个几年前就比较流行，七牛云存储给免费用户提供了 10G 的存储空间和每月 10G 的流量，对一般个人网站来说足够用了。之前网上各种文章里都说的是使用CDN 时，可以申请一个 .qiniu.com 的二级域名来使用，但是现在这个二级域名已关闭申请，要么网站去申请备案，用自定义的域名，要么七牛现在只提供一个 .qnssl.com 的 https 二级域名。要用这个二级域名来做 CDN 加速的话，自己的站点也得用 https 才行，于是又去 letsencrypt 搞了个免费的 ssl 证书，把全站都切到 https 了，再配合wp super cache 里的 CDN 功能，访问速度的确快了不少。
(广告：七牛云存储邀请注册地址 https://portal.qiniu.com/signup?code=3loafzuwmbqs2)
现在已经是2016年了，还在用 php 5 吗？php 7 在 2015 年就已经正式发布，各种官方评测都说比之前的版本有了极大的速度提升，不如升级一下试试看咯。我试下来 WordPress 在 php 7 下直接跑没有发现任何问题，感觉还是挺靠谱的。DigitalOcean 有详细的介绍如何升级到 php 7 https://www.digitalocean.com/community/tutorials/how-to-upgrade-to-php-7-on-ubuntu-14-04 注意还需要另外装几个 php7 的模块，比如 gd, mbstring, curl 什么的，都是 php7-开头的了。
看起来变化还比较大，之前对 rdd 进行 cache(StorageLevel.OFF_HEAP) 操作是存到 tachyon 里面的，现在直接移除了，用了自己的一套实现，tachyon 现在也改名叫 alluxio 了，想在 spark 里用只能用类似 hdfs 的路径来访问 alluxio://**
实验中要用到 Hadoop 的一些压缩 codec，需要编译 Hadoop 的 native 库，做一下记录。顺便吐槽 Hadoop 发行版包里只包含32位的 native 库，请问这年头32位还有啥意义。。
Ubuntu 14.04 为例，编译需要先安装以下依赖包：
sudo apt-get install build-essential autoconf libtool zlib1g-dev libssl-dev cmake pkg-config protobuf-compiler maven
当然还要有 jdk 了。
下载 Hadoop 源码之后，运行 mvn package -Pdist,native -DskipTests -Dtar 即可。
当然更简单一点的办法，就是用别人编好的 docker 镜像了 https://hub.docker.com/r/sequenceiq/hadoop-docker/
最近准备把实验室里搭的一套 CloudStack 换成最新版的 OpenStack Liberty 版本，目的还是想把 kvm 和 XenServer 两套虚拟化环境统一一下，先做一点记录。
目前实验室的 CloudStack 环境主要的 hypervisor 还是 kvm，因为有显卡虚拟化的需求，单独分了一台支持显卡虚拟化的机器安装了 XenServer，但是之前根据 CloudStack 的文档将其加入管理的时候频繁出错，导致我不得不重装了 XenServer 并断开与 CloudStack 的连接，让其单独运行管理，现在正好借这个机会将 XenServer 也纳入到 OpenStack 的管理环境中来。
基于 KVM 的 OpenStack Compute 节点部署就不赘述了，参考官方部署文档即可。对于 XenServer，官方文档中提到有意思的一点是：除了在 dom0 上装的必要插件应用外，在每个 Xen Host 上都会创建一个 PV 类型的 Xen 虚拟机，用来运行 OpenStack 的一些组件，比如 nova-compute，nova-network 等等。
最近在弄 mesos 和 merathon 的集群化部署，节点多了手动一台台去配显然是不现实的，在 github 上找了个 ansible 的自动化部署脚本，一步到位搞定 mesos + zookeeper + haproxy + merathon 的高可用部署，看起来很容易嘛，然后问题就来了。。。
ansible 脚本里安装 mesos 和 merathon 都是利用了 mesosphere 提供的官方 apt 源来进行 apt-get 安装，比手动编译肯定是省事很多，但是！国内的网络实在是太差，访问 repos.mesosphere.io 源下载包速度慢到无法忍受，再加上节点一多，安装速度慢到你能出去旅游一圈再回来。。
痛定思痛之后，我想到找一个国内的 apt 源镜像问题不就解决了嘛！求人不如求己，不如自己搭建一个镜像，正好 ubuntu 上提供了 apt-mirror 这个工具，一般都是用来同步 ubuntu 官方源的，其实拿来同步 mesosphere 这样的第三方源也是可以的，完美！
sudo apt-get install apt-mirror 安装后修改 /etc/apt/mirror.list 文件，类似下面
############# config ##################
#
set base_path /var/spool/apt-mirror
#
set mirror_path /data/apt-mirror
# set skel_path $base_path/skel
# set var_path $base_path/var
# set cleanscript $var_path/clean.sh
# set defaultarch
# set postmirror_script $var_path/postmirror.sh
# set run_postmirror 0
set nthreads 20
set _tilde 0
#
############# end config ##############
deb http://repos.mesosphere.io/ubuntu trusty main
clean http://repos.mesosphere.io/ubuntu
指定了一下 mirror_path 即镜像下载回来存放的目录路径，后面把 mesosphere 官方源的地址写上就可以了，然后就设个 crontab 定时任务每周去同步一把咯。。。
镜像下载回来之后再设个 apache 或者 nginx 什么的提供一个 http 访问服务 http://your-web-server 指向 mirror_path 就行了，要安装 mesos 的时候，deb 源就这么写：(ubuntu 14.04)
deb http://your-web-server/repos.mesosphere.io/ubuntu trusty main
如果觉得地址太长，也可以把 web server 指向 mirror_path 里面的 repos.mesosphere.io 这个目录，这样上面那个地址就可以简化成 http://your-web-server/ubuntu 了。我这样留着，其实是为了以后再 mirror 其他的源，apt-mirror 都会放到 mirror_path 目录的子目录里。
最后，我在国内机房的机器上运行了一次同步，耗时是：
1.8 GiB will be downloaded into archive.
Downloading 41 archive files using 20 threads…
Begin time: Wed Oct 14 12:41:11 2015
[20]… [19]… [18]… [17]… [16]… [15]… [14]… [13]… [12]… [11]… [10]… [9]… [8]… [7]… [6]… [5]… [4]… [3]… [2]…[1]… [0]…
End time: Wed Oct 14 16:17:36 2015
速度太感人了。。。
总结就是：
a.需要批量部署时自建 apt 源是非常有必要的，后期可以节省大量的时间。
b.天朝网络环境真是不怎么样，有能力的还是人肉翻墙吧。。。