月与灯依旧

Koji 是 Fedora 的包编译管理工具。功能十分强大，使用 Mock 作为底层，用于批量编译软件包。下面介绍使用方法。本文的实验环境为CentOS 6.4 64bit。

架构

1，我们都知道 rpmbuild 是 Linux 平台下一款编译 RPM 包的工具，而 Mock 则是在 rpmbuild 之上封装了一层（查看 Mock 的使用方法），利用 yum 来下载一个最小的系统环境，从而实验跨系统的编译工作。而 Koji 则是在 Mock 之上再次进行了封装，由 Koji Server 统一管理，将大量编译任务交给若干个安装了 Mock 的编译机来完成，这些编译机也叫 Koji Builder。

2，本例使用两台服务器（服务端+编译机）配合完成，本例将服务端称之为 Koji Server，将编译机称之为 Koji Builder。

3，本例中的 Koji Server 由 Postgresql 数据库（用来记录软件包的信息）、KojiHub（主程序）、KojiWeb（依赖于Httpd） 等组件组成。Kojira 用于管理和维护yum库，装在哪里都行。本文中的实例是将 Kojira 与 KojiHub 装在同一台服务器上。

4，本例中的 Koji Builder 运行着 Kojid 这个编译守护程序，以及底层的 Mock。

5，KojiHub 是整个体系的核心，通过 XML-RPC 运行于 Apache 的 mod_python 模块下。KojiHub 采用被动方式，仅仅接受 XML-RPC 请求，依赖编译守护模块和其他模块来进行交互。这意味着，无须在 KojiHub 里指定 Koji Builder 的IP地址信息，因为 KojiHub 是被动通信的，需要 Koji Builder 主动与之“联系”。 koji 是一个用 python 写的程序，用户通过 koji 命令，来查询信息或者执行编译工作。

6，Koji 各组件之间的通信使用SSL证书，所以本文的第一步就是为各组件创建证书。 (more…)

Read More

RHEL/CentOS的系统可以通过yum来安装软件，但官方的资源库里软件较少，这时我们就需要第三方的软件库了。熟悉Linux的人应该都知道，RHEL/CentOS系统有三个大的第三方资源库，分别是EPEL，RPMForge和RPMFusion。下面简单介绍一下。

EPEL(Extra Packages for Enterprise Linux)，翻译过来就是“企业版 Linux 附加软件包”，这是一个由Fedora小组负责创建和维护的资源库。由于Fedora是受Redhat赞助的，因此这个库也可以理解成Redhat的官方的库。里面的软件数量已达到5000多个。可以看看它的中文简介。我的感觉是，如果你想获得高质量，高稳定性的软件库，可以考虑使用EPEL。本博客曾经有一篇博文介绍了EPEL软件库的安装方法。

RPMForge被CentOS社区认为是最安全也是最稳定的一个第三方软件库。该库现在已经拥有超过10000种的CentOS的软件包，该库的特点是软件数量多，已达上万种。本博客以前曾介绍过安装RPMForge的方法。根据CentOS官方的说法，RPMForge/RepoForge的计划已终止。不被维护。不要使用。

RPMFusion官网介绍称提供Redhat和Fedora Project不愿意ship的软件，但据CentOS官方称，这个软件库里面的软件稳定性不如rpmforge，因此建议选用！该软件库为当前所有Fedora和rhel5、6以预编译的方式提供软件。你可以用yum等工具使 用这个仓库。RPM Fusion有两个仓库，一个free,另外一个nofree。free是自由软件，nofree有版权，nofree仓库只有少数的软件，很少用到。

注意：不要同时安装若干种资源库，否则会引起错乱。如果一定要装，请考虑yum-priorities插件，它可以设置yum在调用软件源时的顺序。

更多的第三方源请参考CentOS推荐的第三方源列表。

RHEL的源码包下载: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/

Read More

通过一个简单的小例子，讲述一下Linux的patch原理。

假设有个系统源码，位于mm/slab.c

[root@os1 tmp]# ls mm
slab.c
[root@os1 tmp]# cp -r mm newmm
[root@os1 tmp]# vim newmm/slab.c    #手动更新一下系统源码，随便作点改动，作为新版本

ZXXXXXX            /*手动添加这一行*/
/*
 * linux/mm/slab.c
 * Written by Mark Hemment, 1996/97.
 * ([email protected])
 *
 * kmem_cache_destroy() + some cleanup - 1999 Andrea Arcangeli
 *
 * Major cleanup, different bufctl logic, per-cpu arrays
 *      (c) 2000 Manfred Spraul
……

提取patch

[root@os1 tmp]# diff -u mm/slab.c newmm/slab.c  > t.patch

看看patch里都有什么

[root@os1 tmp]# more t.patch

--- mm/slab.c	2013-11-04 23:28:25.646753453 +0800
+++ newmm/slab.c	2013-11-04 23:38:50.355752475 +0800
@@ -1,3 +1,4 @@
+ZXXXXXX
 /*
  * linux/mm/slab.c
  * Written by Mark Hemment, 1996/97.

更新一下patch吧

[root@os1 mm]# cd mm
[root@os1 mm]# patch -p1 < ../t.patch
patching file slab.c
[root@os1 mm]# more slab.c   #看看原始文件发生了什么变化

ZXXXXXX
/*
 * linux/mm/slab.c
 * Written by Mark Hemment, 1996/97.
 * ([email protected])
 *
 * kmem_cache_destroy() + some cleanup - 1999 Andrea Arcangeli
 *
 * Major cleanup, different bufctl logic, per-cpu arrays
 *	(c) 2000 Manfred Spraul

原文件竟然被更新了耶！

Read More

在进行编包的时候大多数人会使用rpmbuild命令在本机进行编译，这样可以使一些依赖及本地相关包的修改可以生效，但在开发过程中必须模拟用户的环境或是构建一个“干净的”环境（既没有任何其他依赖的改动，直接从yum下载构建一个纯用户环境），这样我们就需要mock命令来构建这样一个编译的纯环境来进行编译软件包。

1，安装mock
mock的安装方法比较简单，请参照这篇文章即可。安装完成以后，系统会自动多出一个名为mock的组。

2，mock使用方法
mock编译过程不要用root身份，先建立一个普通的用户，然后把用户加入mock组。

[root@test ~]# useradd mockbuilder 
[root@test ~]# usermod -a -G mock mockbuilder 
[root@test ~]# su - mockbuilder

注意：如果强行使用root身份执行mock命令，python将会抛出“RuntimeError: mock will not run from the root account”的错误。

使用内置的mock配置文件来进行编译

mock 的配置文件在/etc/mock/目录下，系统默认内置了fedora、epel-5、epel-6等系统的配置文件，通过查看这些.cfg的配置文件，可以了解到Mock的原理，即软件使用yum来下载一个最小化的系统，并放入chroot环境中。

下面以编译fedora 15 64位系统的软件包来举例（对应的配置文件为fedora-15-x86_64.cfg） (more…)

Read More