欢迎光临，若觉得本博客的内容对您有帮助，请多点击边栏的Google广告，并提供意见及建议，谢谢！
Jul
30
通常我们都是在现有系统的环境中，对当前硬件平台的软件进行编译为RPM 的工作。但由于各种原因，例如硬件不支持，机器不够，磁盘空间问题等，我们可能需要进行跨平台编译的工作。类似的，为不同发行版进行编译也是常有的问题。Mock 是一套在Fedora 上用于实现跨平台、跨版本编译RPM的工具，其支持Build FC1-6、RH7.3、RH9、RHEL3-5、CentOS 1-5 等平台工作。我现用于在Asianux 3.0 上。
Dec
25
OpenVZ是一个非常出色的单内核，多根分区虚拟机系统。根据使用不同的系统模板。可实现同一机器上同时运行不同的Linux发行版本，而且管理简单，资源控制也很方便，适用于ISP环境下的大规模应用。基础配置可以看[原]在红旗上运行OpenVZ虚拟环境 。
不过，作为Virtuozzo的开源版本，不知有意还是无意的，OpenVZ提供的可用OS系统模板不多，默认只有Fedora Core 3/4/5、Centos4，这不足以满足我们的需求。这里就以创建基于Asianux 2.0 SP2的系统为例，说明如何创建VPS OS模板。
不过，作为Virtuozzo的开源版本，不知有意还是无意的，OpenVZ提供的可用OS系统模板不多，默认只有Fedora Core 3/4/5、Centos4，这不足以满足我们的需求。这里就以创建基于Asianux 2.0 SP2的系统为例，说明如何创建VPS OS模板。
Aug
12
通常情况下，安装RDAC都是参考源码进行安装的。虽然步骤很简单，Readme也很清楚，但始终觉得不适合备份，以及大规模部署。所以，参考Dag Wieers的spec脚本，生成了一个供红旗使用的脚本。经测试，能正常使用，并自动生成mpp-%{kernel}smp.img文件。
Jun
28
前面的[原]自己制作rpm软件包（1）和[原]自己制作rpm软件包（2），两篇文章比较详细的介绍了rpmbuild命令的使用，以及.spec文件的编写。而[原]关于rpm打包的一个补充也描述了，针对特定的平台如何加入变量、修改标准宏，然后再进行编译的情况。
而实际上，通常我们都希望一个套件只针对一个.spec文件，这可以很方便的管理。所以，我们可以在.spec中加入条件判断语句，以便根据不同的条件，执行相对应的编译和打包动作。
而实际上，通常我们都希望一个套件只针对一个.spec文件，这可以很方便的管理。所以，我们可以在.spec中加入条件判断语句，以便根据不同的条件，执行相对应的编译和打包动作。
Jun
21
需要自定义Linux发行版光盘的原因有很多，例如：想学习、想自己发布产品、为管理方便、更新Bug软件包等等。而最近由于工作的需要，也研究了一下Linux发行光盘的构造。这里主要是对沿用红帽发行方式的版本，例如CentOS等。他们都是使用anaconda安装环境的。下面的说明也只针对该环境，以组合红旗两CD光盘为1张DVD光盘为例说明。
另外，网上也有很多可以参考的资料，在附录中有链接。不过，若完全按照这些资料的步骤，会在最后执行buildinstall时出现很多的rpm依赖问题。所以，我绕过了这个脚本，使用更简单、更简单的方式处理。
另外，网上也有很多可以参考的资料，在附录中有链接。不过，若完全按照这些资料的步骤，会在最后执行buildinstall时出现很多的rpm依赖问题。所以，我绕过了这个脚本，使用更简单、更简单的方式处理。
Jun
12
正如前面日志中写到的，我们在编写.spec脚本的时候，应该尽量使用对应操作系统平台的标准宏命令。但有些时候，标准的宏中定义的写法未必可以满足我们的要求，此时就需要给标准的宏添加参数。下面以maildrop这个套件为例说明。
一、举例
maildrop是一个邮件投递代理（MDA）软件，其可搭配postfix实现过滤和强大的功能。maildrop的邮箱大小限额是用off_t来表示，而off_t在32平台上是32位有符号整数。所以最大只能为2^31次方。也就是最大2GB。如果要突破这个限制，需要在编译的时候增加下述的环境变量：
一、举例
maildrop是一个邮件投递代理（MDA）软件，其可搭配postfix实现过滤和强大的功能。maildrop的邮箱大小限额是用off_t来表示，而off_t在32平台上是32位有符号整数。所以最大只能为2^31次方。也就是最大2GB。如果要突破这个限制，需要在编译的时候增加下述的环境变量：
引用
CPPFLAGS="-D_FILE_OFFSET_BITS=64"
Jun
4
上一篇日志写到，为什么要制作rpm包，以及如何使用.src.rpm文件生成rpm包。最后部分还看到.src.rpm的内容，实际上就是由.tar.gz源码、补丁软件和.spec脚本组成的。由此知道，使用.spec生成rpm包是比较简单的，因为.src.rpm通常都是由软件开发者或者第三方的专业制作人根据源码调试好的，所以，只要处理好平台兼容性和相关的版本，不会遇到太大的问题。
但我觉得单纯明白用.spec生成rpm是不够的。常见有两个原因值得我们去了解用如何用源码制作rpm：
但我觉得单纯明白用.spec生成rpm是不够的。常见有两个原因值得我们去了解用如何用源码制作rpm：
引用
1、并不是所有的软件都提供.rpm方式的。
这是最常见的原因。负责任的开发者应提供rpm方式的二进制软件包，以便用户选择使用。但也很常见就是软件作者只是发布了源码，最后一部分的编译和安装需要用户自行解决。我不想深究对错问题，反正知道有这样的情况就可以了；
2、自行打包一些文件或自己开发了一套软件
当然，使用tar包或cpio等也可以打包文件，甚至比制作rpm要简单很多。但如果您想在安装的过程中就把一套额外的软件部署完毕，那使用rpm方式通常是是唯一的方法。而且rpm还有数据库协助软件升级、文件校验等，结合yum升级方式，没有理由不选择rpm，特别是对于最终用户，我认为提供rpm包是最佳的方法。
这是最常见的原因。负责任的开发者应提供rpm方式的二进制软件包，以便用户选择使用。但也很常见就是软件作者只是发布了源码，最后一部分的编译和安装需要用户自行解决。我不想深究对错问题，反正知道有这样的情况就可以了；
2、自行打包一些文件或自己开发了一套软件
当然，使用tar包或cpio等也可以打包文件，甚至比制作rpm要简单很多。但如果您想在安装的过程中就把一套额外的软件部署完毕，那使用rpm方式通常是是唯一的方法。而且rpm还有数据库协助软件升级、文件校验等，结合yum升级方式，没有理由不选择rpm，特别是对于最终用户，我认为提供rpm包是最佳的方法。
Jun
1
我们都知道，在目前的Linux环境下，要安装新软件，通常有两种方式：一是使用源码安装；二是使用rpm软件包。使用源码安装可以让用户了解编译过程，及定制一些模块，和修改编译参数，但其工作量通常都很大，而且要求用户有足够的计算机知识。而rpm软件包方式则相对来说比较简单，也易于管理和升级。所以，当前Linux发行版的前十中，有八个都是使用基于二进制软件包方式的（deb和rpm格式可以互转）。同样的，红旗也是基于rpm的打包方式。
下面要写的，就是如何制作自己的rpm包。这通常是为了减轻工作上带来的麻烦，例如分发软件到客户手上，或统一版本升级等。
一、关于rpm包
下面要写的，就是如何制作自己的rpm包。这通常是为了减轻工作上带来的麻烦，例如分发软件到客户手上，或统一版本升级等。
一、关于rpm包
引用
1、rpm包：简单来说，就是把已经编译好的二进制代码整合到一个文件里面，并且加入一些判断，如安装位置、依赖或冲突的软件包、安装前或后自动运行的脚本等等；
2、兼容性：由于rpm包在制作的时候，是在特定的发行版或硬件上编译的，所以，不同发行版、或同一发行版不同版本号的rpm包一般都是不能互相兼容的，甚至由于spec宏的问题，使用.src.rpm编译也未必可以成功；
3、大部分的软件作者在发布源代码的同时，也会提供rpm或.spec文件，除非没有.spec文件，否则不建议自行编写，并且在编写的时候，应使用标准宏，以提高可读性。
2、兼容性：由于rpm包在制作的时候，是在特定的发行版或硬件上编译的，所以，不同发行版、或同一发行版不同版本号的rpm包一般都是不能互相兼容的，甚至由于spec宏的问题，使用.src.rpm编译也未必可以成功；
3、大部分的软件作者在发布源代码的同时，也会提供rpm或.spec文件，除非没有.spec文件，否则不建议自行编写，并且在编写的时候，应使用标准宏，以提高可读性。
Jun
20
最近找到几个新的软件包，觉得挺好用，也刚编译成rpm包，希望在所有使用到的机器上部署。后来发现，需要每一台机器去安装一遍，即使可以远程安装，这也是挺麻烦的。决定参考Redhat的升级机制，把yum也迁移到红旗上来。说做就做，效果还是不错的。
一、原理
yum是一个用于管理rpm包的后台程序，用python写成，可以非常方便的解决rpm的依赖关系。在建立好yum服务器后，yum客户端可以通过http、ftp方式获得软件包，并使用方便的命令直接管理、更新所有的rpm包，甚至包括kernel的更新。它也可以理解为红旗环境下的apt管理工具。
一、原理
yum是一个用于管理rpm包的后台程序，用python写成，可以非常方便的解决rpm的依赖关系。在建立好yum服务器后，yum客户端可以通过http、ftp方式获得软件包，并使用方便的命令直接管理、更新所有的rpm包，甚至包括kernel的更新。它也可以理解为红旗环境下的apt管理工具。
