Git

将同步者的公钥上传。可以使用下面的命令（需要开启 gistore 的口令认证）
```
$ ssh-copy-id -i id_rsa gistore@<REMOTE.SERVER>
```
使用 git 命令执行克隆操作。
例如下面的命令克隆 /etc/gistore/tasks/system 指向的 gistore 备份库
```
$ git clone gistore@<REMOTE.SERVER>:system
```

那么是如何实现的呢？

使用了群英汇改进的 gitosis 提供 git 库访问控制服务
利用了改进后的 map 指令，将访问的 git 库的地址映射到对应的 gistore 备份库
例如访问 system，实际访问的是 /etc/gistore/tasts/system/repo.git 指定的代码库。相关的 map 指令：
```
map readonly * = (.*):\1/repo
```

不对单个公钥连接进行身份识别，而是所有的登录用户都使用唯一帐号。这样简化了授权模型，降低了配置难度
实际上是在 /etc/ssh/sshd_config 中增加了如下设置：

# ossxp gistore backup account settings:
Match user gistore
    ForceCommand gitosis-serve gistore
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    PubkeyAuthentication yes
    #PasswordAuthentication no

以上的操作，都在安装群英汇 gistore 软件包的时候自动配置，无须人工介入。

Gistore, 备份

解决 gistore 备份数据中的 git 库（submodule）的备份

8月3日

由蒋鑫发表在 Git

没有评论

昨天在从客户现场回公司的路上，想明白了 Gistore 备份出现的 AM 标识的备份数据就是含有变更的子模组。

之前 Gistore 不能解决的一个备份问题是，当备份的数据中包含 git 库，备份数据将不会保存在 gistore 版本库中，而是以 submodule 方式加入备份库。实际的效果是，数据没有备份下来。例如：

安装了 etckeeper，用于维护 /etc 下配置文件的变更。实际上 /etc 目录本身已经是一个 git 库了
如果在 gistore 任务建立前，/etc 目录已经 git 化，则不能有效的对 /etc 进行备份
某个备份数据的目录，被人为的 git 化。这可能是在 hacking 时遗留的 git 库
我在改动服务器的某些数据（如界面模板等），经常将目录 git 化，然后再修改/比较/提交

如果不能有效的对 git化的备份目录进行备份，肯定会收到惩罚。

在最早的实现中，只是在备份之后的后处理（post_check）查找以 git 子模组方式添加的目录，并打出相应的警告信息。如何能够自动进行处理，一直排在工作队列中，昨天晚上开始了修改。

检查子模组

首先要找出哪些目录是以子模组方式添加的。最开始想到了从状态中找出 AM 标识的子模组，进行修改，但是存在问题：1. 添加没有变更的git化的目录，不会显示为 AM（添加且含修改），而显示为 A（添加）。2. 不能有效的发现 gistore 版本库中已经提交数据中以 git 子模组方式添加的目录。

于是采用分析 git submodules status 命令的输出，确定子模组。不过这个命令需要多次迭代执行（遇到无 .submodules匹配报错退出），才能找到所有的子模组。

重新以普通目录和文件方式添加子模组

首先删除已经提交的按照子模组方式保存的目录，重新添加不能直接添加子模组目录，否则仍会按照子模组方式添加。采用的方法是：

删除已经按照子模组方式添加的目录
git –git-dir=repo.git rm –cached sub/module …
在子模组目录下创建一个临时文件，并添加该临时文件
git –git-dir=repo.git –work-tree=run-time add sub/module/<TMPFILE>
对子模组目录执行添加操作
git –git-dir=repo.git –work-tree=run-time add sub/module
别忘了删除临时文件
git –git-dir=repo.git –work-tree=run-time rm sub/module/<TMPFILE>
迭代执行，直到没有子模组发现为止

Gistore 版本升级为 0.2.3，在服务器上重新安装和执行，将原来子模组方式添加的目录重新纳入备份中，放心了。

Gistore 应用：备份博客数据

我们在公司服务器上创建了一个名为 wordpress 的任务，备份 wordpress 数据库导出文件，wordpress 配置文件，wordpress 插件目录，wordpress 上传图片及附件。
将 wordpress 任务的 git 库，加入 git 服务器中，并设置权限
每个有权限的公司员工，都可以使用 git 命令克隆/同步公司服务器上的 wordpress 版本库，将博客数据保存下来

Gistore, Git, 备份

Gistore（基于 git 的数据备份软件）升级至 0.2.x

7月29日

由蒋鑫发表在 Git

没有评论

在 10年1月份的一篇 Gistore 发布声明的博客中，我介绍了我们自己开发的一个用户数据备份的小工具 Gistore。

是什么原因让我们开发备份工具呢？这是因为：

我们公司的数据备份的需要
客户数据备份需要更好用的软件
rdiff-backup 和 flexbackup 的备份方案不够好

实际上 rdiff-backup 用做数据备份，已经足够好了，你可以从我们公司的维基中看到 rdiff-backup 的使用方法：

《存储可靠性、数据备份和恢复》

但是 rdiff-backup 的解决方案的问题是：

命令难记，包括我自己在数据恢复的时候还要一遍一遍的查阅文档
之所以命令难记，实际上是因为备份工具本身的使用率很低，只有在灾难恢复时候会用到，所以命令不熟悉是一定的。
数据的异地镜像比较复杂，需要引入其它工具

为什么不用 Git 开发一款工具呢？

Git 的命令天天在用，实在是太熟悉了
Git 的数据同步太方便了，在同步过程能够实时查看进度

此次 Gistore 升级，解决了半年多的使用过程中积累问题，并且增加了易用性。

阅读全部内容 »

Gistore, Git, 备份

Git 服务器软件 gitosis 的改进

7月20日

由蒋鑫发表在 Git

没有评论

群英汇内部的 Git 服务器使用 gitosis 软件架设，能够实现针对版本库的授权，以及基于公钥的安全的无口令的版本库访问。

在 Gitosis 的使用过程中，我们根据需要对其进行了改进，以满足我们对授权和版本库管理上的需求：

增加了管理员角色，只有管理员才能够创建版本库
- 原来的实现只有 readonly 和 writable 两种权限，其中 writable 可以创建版本库。
- 我们权限分为三级：read/write/admin。拥有管理员(admin)权限，可以创建版本库，并自动具有读(read)写(write)权限
- 拥有写(write)权限也包含读(read)的权限
- 如果没有设置权限，禁止范围版本库
版本库匹配支持通配符，这样在授权的时候，可以用通配符为某个目录下的所有代码库授权
- 原有的实现，在配置文件中必须写入完整的版本库名称（路径）
- 当我们增加了管理员的概念后，增加通配符，就可以为特定的命名空间进行授权，而无须因为某个管理员要建库，还要修改授权文件
- 有了通配符后，读写权限的设置也更为简单。
- 通配符支持？，* 和 **。问号匹配一个字符，* 匹配任意字符（路径/字符除外），两个星号匹配包括路径分割符在内所有字符
增加了版本库路径映射的可用性。版本库路径映射在代码库重构中非常有用
- 增加了正则表达式匹配路径和替换映射
- 在权限检查的路径命中之后也检查路径映射，可以减轻错误配置的可能性
创建版本库只有写操作才进行，读操作不创建版本库
- 原来的实现支持即时创建版本库，在读取一个不存在的版本库时自动创建
- 读操作创建库，这会导致很多因为版本库克隆时路径输入错误导致错误建库
- 我们更改后，只允许在写版本库时并且具有 admin 权限才初始化新的代码库
版本库名称中允许出现中文（UTF-8）
- 基本上版本库命名都用英文字符，不过有个客户提出来支持中文版本库，我们就添加了这个支持

下面，拿一个配置文件来说明：

阅读全部内容 »

Git, Gitosis, 版本控制

topgit 分支的图形化显示

6月18日

由蒋鑫发表在 Git

3条评论

使用 Git + topgit 做版本控制，当 topgit分支（功能分支）非常多并且相互依赖比较复杂时，非常需要有一个直观的图形化的分支依赖图。

联想到我们使用 git 经常用到的 git glog 命令输出，如果 topgit 分支图能够有类似的显示就太好了：

| | * t/unittest
| |/
| *---.   t/message_localize
| |\ \ \
| * | | | t/auth_log_for_fail2ban
|/ / / /
| * | | t/factor_invite
|/ / /
| * | t/factor_ldap
|/ /
| * t/include_macro_for_templates
| * t/multi_language
|/
* master

正在冥思苦想如何实现时，忽然发现 topgit 的 tg-summary 中原来已经有图形输出的实现，是借用 graphviz 工具进行图形化输出…