月与灯依旧

一，CentOS 6的光盘目录介绍

（1）Packages目录：包含安装所需的所有二进制RPM包。
（2）EFI目录：用于64位的基于EFI的系统引导。其中BOOT目录下的BOOTX64.conf为grub的配置文件，用于显示引导菜单。
（3）TRANS.TBL文件：记录当前目录的列表，用mkisofs的-T参数重新生成，主要是为了长文件名称。
（4）.discinfo文件是安装介质的识别信息。.treeinfo文件记录不同安装方式安装程序所在的目录结构，如PXE方式时，内核kernel=images/pxeboot/vmlinuz，根文件系统initrd=images/pxeboot/initrd.img。
（5）isolinux目录：有开机引导系统安装的内核（vmlinuz）及RAM镜像(initrd.img)，在引导系统时会载入内存，给系统的安装提供一个Linux安装引导平台，文件夹中还有在不同模式下显示信息的boot.msg文件，splash.jpg是特殊格式的引导过程背景图片（640*480）。安装时这个画面上的引导菜单内容在isolinux/isolinux.cfg文件中指定。按Enter会自动进入图形界面安装模式，若按Esc，会显示”boot: “命令提示符，进入用户交互模式，界面上会有各种模式操作提示。键入”linux text”，会进入文本安装模式。
（6）images目录：包含有各种引导镜像。最重要的是引导第二阶段安装需要用到的镜像文件install.img（CentOS 5中是stage2.img），anaconda程序就在这个镜像文件中。另外还有用于制作微型启动光盘的boot.iso（为节省空间CentOS 6中已经删除了，在CentOS 5中是有的），有可放置于USB或其他大容量可引导介质的VFAT分区上，制作引导工具的镜像diskboot.img（CentOS 5中有），也有用于制作PXE安装方式引导介质的pxeboot文件夹等。

系统安装的两个阶段： (more…)

Read More

定制Linux发行版的一个重要步骤，是向安装程序添加自定义的软件包，这里简要记录一下过程。本文的实验环境基于CentOS 6.4 64bit。

首先需要明白一下概念，通常来讲，一个package指一个软件包，一个group里包含了若干个package，一个category里则包含了若干个group。只要明白这点，下面就简单多了。在使用Linux安装光盘安装系统的时候，有一个自定义软件包的步骤。在此步骤中，左侧显示的是category，右则显示的是group。它们之间对应关系记录于repodata/xxx-comps.xml文件中。

repodata/xxx-comps.xml文件的写法：

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE comps PUBLIC "-//CentOS//DTD Comps info//EN" "comps.dtd">
<comps>

  <group>
   <id>组1的ID，非数字</id>
   <name>组1的名字</name>
   <description>组1的描述</description>
   <default>是否预安装，true或者false</default>
   <uservisible>是否可见，true或者false</uservisible>
   <langonly>zh</langonly>  #仅在某个语系的安装界面中显示，可选项
   <packagelist>
      <packagereq requires="依赖包" type="conditional">软件包1</packagereq>
      <packagereq type="default">软件包2</packagereq>
      <packagereq type="default">软件包3</packagereq>
   </packagelist>
  </group>
  <group>
   <id>组2的ID，非数字</id>
   <name>组2的名字</name>
   <description>组2的描述</description>
   <default>是否预安装，true或者false</default>
   <uservisible>是否可见，true或者false</uservisible>
   <packagelist>
      <packagereq requires="依赖包" type="conditional">软件包1</packagereq>
      <packagereq type="default">软件包2</packagereq>
      <packagereq type="default">软件包3</packagereq>
   </packagelist>
  </group>
……

  <category>
   <id>分类1的名字，非数字</id>
   <name>将显示在左侧列表里</name>
   <description>将显示在下面的描述栏里</description>
   <grouplist>
    <groupid>组1的ID</groupid>
    <groupid>组2的ID</groupid>
    <groupid>组3的ID</groupid>
   </grouplist>
  </category>
  <category>
   <id>分类2的名字，非数字</id>
   <name>将显示在左侧列表里</name>
   <description>将显示在下面的描述栏里</description>
   <grouplist>
    <groupid>组4的ID</groupid>
    <groupid>组5的ID</groupid>
    <groupid>组6的ID</groupid>
   </grouplist>
  </category>

</comps>

(more…)

Read More

Linux系统下创建ISO镜像文件的方法：

dd if=/dev/cdrom of=/root/name.iso
cat /dev/cdrom > /root/name.iso
cp -r /home/user name.iso            #根据目录创建，不具备boot功能
mkisofs -r -o filename.iso /home/user  #根据目录创建，具备boot功能

下面着重介绍一下最后一种方法，mkisofs是Linux系统下用于创建iso镜像的工具。

安装：

yum install mkisofs     (同时适合CentOS 5,6)
yum install genisoimage  (仅适合CentOS 6)

CentOS 6中，mkisofs改了一个名字叫genisoimage，但yum install mkisofs一样可以安装，安装的软件名却叫genisoimage。 (more…)

Read More

在上一篇中，我们搭建好了 Koji Server 端，本文开始配置 Koji Builder 端。Koji Builder 端的配置依然需要安装第三方yum源EPEL，安装方法请参考 Koji Server 端的安装过程。

一，koji builder 端的配置

[root@koji ~]# yum install koji koji-builder mock rpm-build

配置文件
/etc/kojid/kojid.conf – Kojid 守护进程配置文件
/etc/sysconfig/kojid – Kojid 守护进程

修改配置文件 /etc/koji.conf，指定证书的位置：

[koji]
server = http://10.152.11.84/kojihub
weburl = http://10.152.11.84/koji
topurl = http://10.152.11.84/kojifiles/
topdir = /mnt/koji
cert = ~/.koji/client.crt
ca = ~/.koji/clientca.crt
serverca = ~/.koji/serverca.crt

(more…)

Read More

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