RedHat系列RPM软件打包实例(一)

  对于Linux操作系统,由于软件大部分都是开源软件构成,所以软件打包算是维护一个发行版的绝大多数任务。在Linux那个远古的时代,大家告诉你软件的安装都是下载源码、配置、编译和安装。

  下面以Fedora 22为例子演示,CentOS可能会有一些差异,暂且不表。且是在本地进行打包的,没有用到Fedora的Koji系统。

1.配置环境

1.1 安装打包软件

1
user@localhost  ~ sudo dnf install fedora-packager @development-tools rpmdevtools

1.2 配置打包环境

  手册强烈建议不要使用root打包,以防破坏系统;也不要使用系统常用用户打包,以防上传一些用户的私密信息;所以建议建立一个专门打包的普通用户。

1
2
3
4
5
6
7
8
9
 user@localhost  ~ sudo useradd makerpm
user@localhost  ~ sudo usermod -a -G mock makerpm
user@localhost  ~ sudo passwd makerpm
user@localhost  ~ su makerpm
Password:
[makerpm@localhost ~]$ rpmdev-setuptree
[makerpm@localhost ~]$ ls
rpmbuild
[makerpm@localhost ~]$

然后打包环境就建立好了。

2.编写spec文件

2.1 参考已经打好的包

  Fedora发布的软件都是包含源代码的,所以可以借鉴这些包的打包脚本,先模仿再创作是最便捷的学习方式。

1
2
3
4
[makerpm@localhost dist]$  dnf download --source p7zip
[makerpm@localhost dist]$ mkdir p7zip-9.20.1-8.fc22
[makerpm@localhost dist]$ cd p7zip-9.20.1-8.fc22/
[makerpm@localhost p7zip-9.20.1-8.fc22]$ rpm2cpio ../p7zip-9.20.1-8.fc22.src.rpm | cpio -i

然后慢慢品味p7zip.spec吧!

2.2 准备打包的源代码包

  起始环境建立好之后,打包的过程,就是编写spec文件的过程。
  使用的材料是上一次的strtest工程进行打包,注意包的命名规范:name-version.tar.gz

1
2
3
4
5
user@localhost  ~/Study/project/to_linux  mv strtest strtest-1.0.1
user@localhost  ~/Study/project/to_linux  tar czvf strtest-1.0.1.tar.gz strtest-1.0.1
user@localhost  ~/Study/project/to_linux  sudo cp strtest-1.0.1.tar.gz /home/makerpm/rpmbuild/SOURCES/
user@localhost  ~/Study/project/to_linux  sudo chown makerpm:makerpm /home/makerpm/rpmbuild/SOURCES/strtest-1.0.1.tar.gz
user@localhost  ~/Study/project/to_linux 

利用autotools自动生成项目的Makefile

Linux下的软件,大多要不是各个发行版打好包的,要不是源代码下来后,

1
./configure && make && make install

  三步曲来完成安装的。对于一个工程,简单的话可以手写Makefile,但是随着项目不断的增长,需要跟踪的文件越来越多的时候,手动维护Makefile会比较的麻烦;同时随着各个发行版和平台的差异性的处理也很尽善尽美;(当然我主要是对Makefile不太熟悉,用这个工具可以傻瓜生成Makefile,是我最大的动力!

1.安装autotools

  在我的地沟油下,是被打包成下面两个文件的:

1
sudo dnf install automake  autoconf

2.建立代码目录,添加测试的源代码文件

  这里直接无耻地照搬了这里的两个测试文件str.h和str.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 user@localhost  ~/Study/project/to_linux/test_project  mkdir include src
user@localhost  ~/Study/project/to_linux/test_project  cat include/str.h
#include <stdio.h>
int str(char *string);
user@localhost  ~/Study/project/to_linux/test_project  cat src/str.cpp
#include "str.h"

int str(char *string){
printf("\n----PRINT STRING----\n\"%s\"\n",string);
return 0;
}

int main(int argc , char **argv){
char str_read[1024];
printf("Please INPUT something end by [ENTER]\n");
scanf("%s",str_read);
return str(str_read );
}
user@localhost  ~/Study/project/to_linux/test_project 

3.生成configure.ac

  autoscan工具在给定目录及其子目录树中检查源文件,若没有给出目录,就在当前目录及子目录树中进行检查,并生成一个configure.scan文件。我们将这个文件命名为configure.ac(有的也命名成configure.in文件,但是.ac是新名字,建议用这个哦!)

1
user@localhost  ~/Study/project/to_linux/test_project  mv configure.scan configure.ac

修改之,添加或者修改如下条目(最终的修改结果会在文末贴出)

1
2
3
4
AC_INIT([strtest], [1.0], [taozhijiang@gmail.com])
AM_INIT_AUTOMAKE
AC_PROG_CXX
AC_CONFIG_FILES([Makefile])

4.执行aclocal

5.创建Makefile.am

  这是另外一个比较讲究的文件。
  一个工程可以创建多个可执行文件,每个可执行文件可以依赖自己的源文件、编译参数等信息。
  AUTOMAKE_OPTIONS提供了三个strictness等级,分别是foreign, gnu(默认), gnits三个,主要差异是对目录下的NEWS、README等要求,以及编译的输出等级等,foreign是最小等级。
  详情请见info automake 3.2 Strictness

5.1 方案1

  我们简单使用的文件如下:

1
2
3
4
5
AUTOMAKE_OPTIONS = foreign

bin_PROGRAMS = strtest
strtest_SOURCES = src/str.cpp
strtest_CPPFLAGS = -I include/ -include ./WINTYPES.H

  下面很明显啦,就是每个执行文件的名字,及其源代码和额外的编译参数。

开源的个人密码管理器软件KeePass

  这个文章的标题都建立了好久了,一直没有去写。觉得就是一个软件推荐,十分的没有技术含量啊。但是用了这么久,感觉确实好用,因此整理出来推荐给大家。

一、KeePass的优点

1.1 主流的密码管理器

  感觉主流的密码管理器,主要分成两类:保存在网络的和保存在本地的。

  • 前者以LastPass作为代表,所有的数据信息加密保存到云端,所以优势就是共享和更新比较的方便,但是缺点就是,万一你的密码或者供应商的数据和加密信息泄漏,你就完全被暴露了。LastPass这家公司曾经是出过此类安全问题的,有兴趣的同学可以扒扒这段历史
  • 后者主要以1Password和LastPass作为代表。主要区别是1Password是公司的商业产品,需要很多很多美刀,支持主流的平台(Linux除外),所以基本是高帅富的钟爱,这一点在AppStore的排行榜就可以看见。后者是社区化的开源产品,所有平台都支持(甚至黑莓、WindowsPhone都支持,良心软件啊!),Linuxer的首选,但是没有商业支持,所以死活完全自理。这一类是将密码数据库加密存储到本地,不会传递到互联网上,所以理论上是最安全的。你也可以将加密数据库存储到dropbox等网盘中,实现多设备的同步操作。
    以上列出的管理器,都有浏览器插件支持,后面再叙述。

1.2 KeePass的优势

  • 开源
      虽然我没有精力去查看他的源代码到底安不安全,有没有后门,但是开源的东西公布在网上,我相信大众的智慧会保证产品的质量,同时众目睽睽之下没有人会做这种留后门之类的事情。
  • 支持Linux
      曾经是Linux的忠实拥憋,现在还看见很多人折腾它。虽然现在都在“瘟都死”下学习娱乐,但对这种真正负责任的跨平台印象还是不错的。多平台多软件选择可以参见文档。
  • 免费
      1Password几十上百刀的价格确实把我吓尿了。对于生活在一个“软件不要钱”的国度,我买过的最贵的软件就是Windows序列号RMB10,以及Runtastic二十多块钱折扣时候买的。
  • 保存在本地,安全
      人家说在世界,尤其是天朝,互联网是有国界但是没有隐私的。所以我变得“焦虑、多疑”,我只相信数据在我的手中才是安全的。所以当前我的电脑插了一个SD卡,密码数据文件放在SD卡中,SD卡可以随身携带。

在Windows下通过虚拟机搭建Linux内核的学习和调试环境

  其实,这边文章在我的linux的repo里面已经介绍了,此处着重进行归纳和整理。

本文重点

  • Windows下虚拟机的嵌套
  • 内核编译和ramfs镜像的制作
  • Qemu使用特定内核启动

一、Windows下面VMware虚拟机嵌套KVM虚拟机

  像我之前用Gentoo,然后搭建个KVM的虚拟机,编译启动内核是十分方便的。但是碍于现在在Windows环境工作的原因,使用Gentoo作为桌面系统,还是有些不方便的。
  此外还有的一个原因,是感觉自己过了那种折腾的年龄了。往昔那种优化美化Linux桌面,寻求各种方式替代Windows的应用软件,对我已经没有任何的吸引力了。(我已老矣)
  在Windows下,至少需要一个Host来交叉编译内核,然后再找个Host启动跟踪这个内核,在一台机器上面如果用虚拟机,势必涉及到虚拟机的嵌套(因为如果开两个虚拟机,我还不知道调试的虚拟机怎么指定内核来启动,除非你将新内核拷贝到测试机覆盖文件系统上的内核,显然很麻烦!!!)Qemu+KVM就是这帮搞Linux的维护开发的,看看Qemu的启动参数就能吓尿你,所以用这家伙学内核乃是正道。
  默认的VMware是不支持这种嵌套虚拟化的,需要修改虚拟机的配置文件。我用的VMware Workstation 9,测试添加这些内容可行

1
2
3
apic.xapic.enabled = "FALSE"    
vcpu.hotadd = "FALSE"
hypervisor.cpuid.v0 = "FALSE"

  然后在VMware里面安装你的Guest(将来也是Host)的系统吧!(我用的地沟油,贱兔太浪费时间和精力了)
  然后用qemu或者virt-manager再建立一个真正的Guest系统,我同样使用的Fedora。怎么用qemu或者virt-manager装系统,我不想说,你可以去参考archlinux或者gentoo的wiki。