南靖男的时代

GitLab 汉化版升级到 7.2.1

晚了一个多星期，期间 gitlab 还做了一个小版本修复。

7.2 比 7.1 多了 Star 功能，暂时翻译成“标记”了。另外，还发现 git 的 tag 和 issue 和 label 都是“标签”，这种翻译好头痛。

除了 github 外，现在还推送到国内的 gitcafe 做镜像。

Ubuntu Vagrant Box

花了一点时间写了一个脚本自动更新 Ubuntu 官方的 Vagrant Box 到 Vagrant Cloud。

和 https://vagrantcloud.com/ubuntu 的区别在于：会自动更新版本号，而不是一个版本绑定死 current 链接。

Ubuntu Server 14.04 使用 Ruby 2.0

官方源已经提供了 ruby2.0 但是因为 debian 源处理 bug 删除了 ruby-switch 包，就无法使用 update-alternatives 来切换 ruby 版本了。

目前就只有手工切换一下，命令如下：

1
2
3
4
5
6
7
8
9
10

sudo rm /usr/bin/ruby /usr/bin/gem /usr/bin/irb /usr/bin/rdoc /usr/bin/erb
sudo ln -s /usr/bin/ruby2.0 /usr/bin/ruby
sudo ln -s /usr/bin/gem2.0 /usr/bin/gem
sudo ln -s /usr/bin/irb2.0 /usr/bin/irb
sudo ln -s /usr/bin/rdoc2.0 /usr/bin/rdoc
sudo ln -s /usr/bin/erb2.0 /usr/bin/erb
sudo gem sources --remove https://rubygems.org/
sudo gem sources -a https://ruby.taobao.org/
sudo gem update --system
sudo gem pristine --all

嗯，顺便把 rubygems 切换到淘宝镜像。不知道什么时候 packagist 也有国内镜像啊；每次本地 composer update 都是在消耗时间。

为什么要选择 Ubuntu Server？

首先，我所参与的技术团队都是这样的：

1. 没有自己的底层系统开发/定制团队；比如，自己定制特别的文件系统
2. 也没有对特定的服务端做修改；嗯，就是维护自己的 nginx、php、mysql 这一套玩意
3. 对安全有关注，但没有能力去主动寻找和解决安全问题；是的，团队很小
4. 我们只采用主流的、成熟的新技术；应该说就是最近一两年开始兴起，然后被业内主流所接受的稳定技术
5. 我们的很多项目会使用一些这样那样的小东西；虽说折腾是一个好习惯、好体验，但谁经不住折腾
6. 只有兼职的系统维护工程师；很多情况下就是我自己

其实，这差不多就是为什么要采用 Ubuntu Server 的理由了。

对于服务器版本来说，可选的大约就是 FreeBSD、CentOS、Debian、Ubuntu Server、OpenSuse、Fedora 少数几个。除开 FreeBSD，大约就是 CentOS 与 Debian/Ubuntu Server 的选择。

大多数推崇 CentOS（也包括 FreeBSD）的理由就是稳定、可定制、硬件支持广泛，而实际上隐含的是，他们不更新，对系统也没有灾难处置。

是的。大部分人就是选择一个所谓稳定的系统、安装特定的服务端，然后就不再理会了。希望这台服务器可以省事的运行五年甚至七年。

实际上，对于服务器，我们需要：

1. 及时的安全应对和更新
2. 较新的服务端应用版本以便实施新技术，而不用自行定制

是的，我只是一个系统维护工程师，不是系统开发工程师。我需要关注的是安全、稳定、可用。但我不是系统开发，我无法独立去自行同时解决服务端应用软件的安全、稳定、可用。

虽然我可以为了解决可用，选择一个较新版本的开源服务端软件自行编译安装。但是，我需要去关注这个开源项目，订阅相关安全通知，并且在第一时间自行解决问题。

同样我也可以为了解决稳定，事先通过测试比较选取相应软件的最稳定版本，然后不再更新任何东西。但是，安全呢。

服务器不是孤立的。粗放的管理方式存在极大的隐患。而解决隐患，要耗费大量的精力，也包括我的能力。我不是系统开发工程师。

如果你不相信 Ubuntu 官方源的系统开发工程师不能为你提供最新、最安全、最稳定的服务端应用，我们还有 PPA 可用。

一般由专业厂商和团队乃至应用开发团队提供的 Personal Package Archives 源比你自行去解决要专业的多。嗯，除非你本身就是应用的开发工程师，那你更专业~

部分汉化了 Gitlab

基于 6.7.2 版本，直接修改的视图和部分控制器、视图助手。也引入了几个中文本地化文件。
代码托管在 https://gitlab.com/larryli/gitlab 默认的 zh 分支。
然后自己也架设了一个 https://code.larryli.cn/ 用来管理代码。

Gitlab 对 Golang 支持不错，项目页面内嵌 go-import meta 数据。

github 版本库分离子目录为只读子版本库

Github 的官方文档有说明如何使用 git 分离一个已存在版本库的子目录到新的版本库。但这玩意就是一次性的。分离之后，父库上的子目录修改没办法自动同步到子库上。

幸好 github 上也有人提供了同步工具 git-subsplit。

使用起来很简单。

首先，你得至少有两个版本库。比如在 github 分别是 https://github.com/yourname/foo 和 https://github.com/yourname/foo-bar 其中，foo-bar 对应 foo/bar 目录。foo-bar 最好是空仓库。

然后检出 foo 到本地，创建 foo/bar 目录，增加点内容。

可以在 foo 本地目录，也可以另找一个地方，执行：

1

git subsplit init https://github.com/yourname/foo

设置父版本库。这个只需要一次执行。

等到父版本库有新的 push/pull 后，回到该目录下，执行：

1

git subsplit update

更新（pull）父版本库的变更。

最后，执行：

1

git subsplit publish bar:https://github.com/yourname/foo-bar --heads=master

同步变更到子版本库。子目录可以多层，也可以同步多个。

Golang Die

最近写小脚本越来越多，基本上都是用 Golang 了，也慢慢习惯使用了 https://gist.github.com 来存放一些脚本。
今天突然发现原来 gist 也可以直接 import 的，于是赶紧把常用的 Die Error 共用了。

// Package offers a function that die err message if err not nil.
//
//    import . "gist.github.com/9521299.git"
//    Die(err, something...)
//
package gist9521299

import (
	"fmt"
	"os"
	"path/filepath"
	"runtime"
)

// Die err message if err not nil.
//
func Die(err error, a ...interface{}) {
	if err != nil {
		_, file, line, ok := runtime.Caller(1)
		if ok {
			fmt.Fprintf(os.Stderr, "Die @%s #%d: ", filepath.Base(file), line)
		} else {
			fmt.Fprintf(os.Stderr, "Die unknown location: ")
		}
		a = append(a, err)
		fmt.Fprintln(os.Stderr, a...)
		os.Exit(1)
	}
}

// Package offers a function that dump everything.
//
//    import . "gist.github.com/9521299.git"
//    Dump(something...)
//
package gist9521299

import (
	"fmt"
	"os"
	"path/filepath"
	"runtime"
)

// Dump everything.
//
func Dump(a ...interface{}) {
	_, file, line, ok := runtime.Caller(1)
	if ok {
		fmt.Fprintf(os.Stdout, "Dump @%s #%d: ", filepath.Base(file), line)
	} else {
		fmt.Fprintf(os.Stdout, "Dump unknown location: ")
	}
	fmt.Fprintln(os.Stdout, a...)
}

Godoc.org 直接可以生成文档：

Raspberry Pi Coder 使用 StartSSL 证书

Google Creative Lab 为 Raspberry Pi 提供了 Coder 工具，默认是使用 https 访问，用的是自动生成的自签名证书。

我们知道 StartSSL 是免费为个人提供 SSL 证书的，所以可以将 Coder 的自签名证书替换为 StartSSL 的签名证书。

Coder 的证书是放在 /home/coder/coder-dist/coder-base/certs 名称分为为 server.cert 证书和 server.key 私钥。需要注意的是 Coder 目前只支持 PKCS #8 格式的私钥，需要转换。

openssl pkcs8 -topk8 -inform PEM -in startssl.key -outform PEM -nocrypt -out server.key

另外，cert 证书不支持根证书拼接，直接使用 StartSSL 提供的即可。

最后，需要注意两个文件的属主是 coder，key 私钥文件的权限是 600。