以原始码的方式来安装软件,是利用厂商释出的Tarball来进行软件的安装。
不过,你每次安装软件都需要侦测操作系统与环境、设定编译参数、实际的编译、最后还要依据个人喜好的方式来安装软件到定位。这过程是真的很麻烦的。
如果厂商先在他们的系统上面编译好了用户所需要的软件,然后将这个编译好的可执行的软件直接释出给用户来安装,如此一来,由于本来就使用厂商的 Linux distribution ,所以当然系统(硬件与操作系统)是一样的,那么就可以直接使用厂商提供的编译过的可执行文件。
如果在安装的时候还可以加上一些与这些程序相关的信息,将他建立成为数据库,那就可以进行安装、反安装、升级与验证等等的相关功能啰(类似Windows底下的【新增移除程序】)。
在 Linux 上面至少就有两种常见的这方面的软件管理员,分别是 RPM 与 Debian 的 dpkg 。CentOS 主要以 RPM 为主。
Linux 开发商先在固定的硬件平台与操作系统平台上面将需要安装或升级的软件编译好,然后将这个软件的所有相关文件打包成为一个特殊格式的文件,在这个软件文件内还包含了预先侦测系统与相依软件的脚本,并提供记载该软件提供的所有文件信息等。最终将这个软件文件释出。【客户端取得这个文件后,只要透过特定的指令来安装,那么该软件文件就会依照内部的脚本来侦测相依的前驱软件是否存在,若安装的环境符合需求,那就会开始安装】,安装完成后还会将该软件的信息写入软件管理机制中,以达成未来可以进行升级、移除等动作。
dpkg:
这个机制最早是由 Debian Linux 社群所开发出来的,透过dpkg 的机制,Debian 提供的软件就能够简单的安装起来,同时还能提供安装后的软件信息,实在非常不错。只要是衍生于 Debian 的其他 Linux distributions 大多使用 dpkg 这个机制来管理软件的,包括 B2D, Ubuntu等等。
RPM:
这个机制最早是由 Red Hat 这家公司开发出来的, 很多distributions使用这个机制来作为软件安装的管理方式。包括Fedora, CentOS, SuSE等等知名的开发商。
CentOS 系统使用的软件管理机制为 RPM 机制,而用来作为在线升级的方式则为yum。
RPM 全名是【RedHat Package Manager】简称则为 RPM 。
RPM 是以一种数据库记录的方式来将所需要的软件安装到Linux系统的一套管理机制。
最大的特点是:将要安装的软件先编译过,并且打包成为 RPM 机制的包装文件,透过包装好的软件里头默认的数据库记录,记录这个软件要安装的时候必须具备的相依属性软件,当安装在 Linux主机时,RPM 会先依照软件里头的数据查询 Linux 主机的相依属性软件是否满足,若满足则予以安装,若不满足则不予安装。
安装的时候就将该软件的信息整个写入 RPM 的数据库中,以便未来的查询、验证与反安装。优点是:
1.由于已经编译完成并且打包完毕,所以软件传输与安装上很方便(不需要再重新编译);
2.由于软件的信息都已经记录在 Linux 主机的数据库上,很方便查询、升级与反安装。
但是这也造成些许的困扰。由于 RPM 文件是已经包装好的数据,也就是说,里面的数据已经都【编译完成】了!所以,该软件文件几乎只能安装在原本默认的硬件与操作系统版本中。
也就是说,主机系统环境必须要与当初建立这个软件文件的主机环境相同才行。所以,通常不同的 distribution 所释出的 RPM 文件,并不能用在其他的 distributions 上。更有甚者,相同 distribution 的不同版本之间也无法互通。
因此,这样可以发现这些软件管理机制的问题是:
1.软件文件安装的环境必须与打包时的环境需求一致或相当;
2.需要满足软件的相依属性需求;
3.反安装时需要特别小心,最底层的软件不可先移除,否则可能造成整个系统的问题;
如果真的想要安装其他 distributions 提供的好用的 RPM 软件文件,还有SRPM 。
SRPM 是 Source RPM 的意思,也就是这个RPM 文件里面含有原始码。这个SRPM 所提供的软件内容【并没有经过编译】,它提供的是原始码。
通常 SRPM 的扩展名是以 ***.src.rpm
这种格式来命名的。不过,虽然SRPM 提供的是原始码,但是他仍然含有该软件所需要的相依性软件说明、以及所有 RPM 文件所提供的数据。同时,他与 RPM 不同的是,他也提供了参数配置文件(就是configure 与makefile)。所以,如果下载的是SRPM,那么要安装该软件时,就必须要:
先将该软件以 RPM 管理的方式编译,此时 SRPM 会被编译成为 RPM 文件。然后将编译完成的RPM 文件安装到Linux系统当中。
通常一个软件在释出的时候,都会同时释出该软件的 RPM 与SRPM。RPM 文件必须要在相同的 Linux 环境下才能够安装,而 SRPM 既然是原始码的格式,自然就可以透过修改 SRPM 内的参数配置文件,然后重新编译产生能适合 Linux 环境的 RPM 文件,如此一来,就可以将该软件安装到我们的系统当中,而不必与原作者打包的 Linux环境相同了。
![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/5c8aaffa5b3d40adbd8fee06773cde31.png #pic_center)
RPM 与 SRPM 的格式分别为:XXXXX.rpm
与 XXXXX.src.rpm
透过档名就可以知道这个软件的版本、适用的平台、编译释出的次数。
例如 rp-pppoe-3.11-5.el7.x86_64.rpm
:
软件名称:每一个软件的名称;
版本信息:每一次更新版本就需要有一个版本的信息,通常又分为主版本跟次版本。以上面为例,主版本为 3,在主版本的架构下更动部分原始码内容,而释出一个新的版本,就是次版本啦。以上面为例,就是11。所以版本名就为3.11;
释出版本次数:通常就是编译的次数。由于同一版的软件中,可能由于有某些 bug 或者是安全上的顾虑,所以必须要进行小幅度的 patch 或重设一些编译参数。设定完成之后重新编译并打包成RPM 文件。因此就有不同的打包数出现了;
操作硬件平台:由于RPM可以适用在不同的操作平台上,但是不同的平台设定的参数还是有所差异性,并且,可以针对比较高阶的 CPU 来进行优化参数的设定,这样才能够使用高阶CPU所带来的硬件加速功能。所以就有所谓的 i386, i586, i686,x86_64 与noarch等的文件名出现了;
由于 RPM 是透过预先编译并打包成为 RPM 文件格式后,再加以安装的一种方式,并且还能够进行数据库的记载。所以 RPM 有以下的优点:
RPM 内含已经编译过的程序与配置文件等数据,可以让用户免除重新编译的困扰;
RPM 在被安装之前,会先检查系统的硬盘容量、操作系统版本等,可避免文件被错误安装;
RPM 文件本身提供软件版本信息、相依属性软件名称、软件用途说明、软件所含文件等信息,便于了解软件;
RPM 管理的方式使用数据库记录RPM 文件的相关参数,便于升级、移除、查询与验证。
为什么RPM 在使用上很方便呢?我们前面提过,RPM这个软件管理员所处理的软件,是由软件提供者在特定的 Linux作业平台上面将该软件编译完成并且打包好。那使用者只要拿到这个打包好的软件,然后将里头的文件放置到应该要摆放的目录,就可以完成安装。
为了解决这种具有相关性的软件之间的问题(就是所谓的软件相依属性),RPM就在提供打包的软件时,同时加入一些讯息登录的功能,这些讯息包括软件的版本、打包软件者、相依属性的其他软件、本软件的功能说明、本软件的所有文件记录等等,然后在 Linux系统上面亦建立一个RPM 软件数据库,
如此一来,当要安装某个以 RPM 型态提供的软件时,在安装的过程中,RPM 会去检验一下数据库里面是否已经存在相关的软件了,如果数据库显示不存在,那么这个RPM 文件【预设】就不能安装。这就是 RPM 类型的文件最为人所诟病的【软件的属性相依】问题。
为了重复利用既有的软件功能,因此很多软件都会以函式库的方式释出部分功能,以方便其他软件的呼叫应用。此外,为了节省用户的数据量,目前的 distributions 在释出软件时,都会将软件的内容分为一般**使用与开发使用(development)**两大类。
所以会常常看到有类似 software-x.x.rpm 与 software-devel-x.x.rpm 之类的档名。而预设情况下,大部分的 software-devel-x.x.rpm 都不会安装,因为终端用户大部分不会去开发软件。
RPM 相依属性的问题的解决:将这些相依属性的软件先列表,在有要安装软件需求的时候,先到这个列表去找,同时与系统内已安装的软件相比较,没安装到的相依软件就一口气同时安装起来——YUM机制。
CentOS(1)先将释出的软件放置到 YUM 服务器内,然后(2)分析这些软件的相依属性问题,将软件内的记录信息写下来(header)。然后再将这些信息分析后记录成软件相关性的列表列表。这些列表数据与软件所在的本机或网络位置可以称呼为容器或软件仓库或软件库(repository)。当客户端有软件安装的需求时,客户端主机会主动的向网络上面的 yum 服务器的软件库网址下载清单列表,然后透过列表列表的数据与本机 RPM 数据库已存在的软件数据相比较,就能够一口气安装所有需要的具有相依属性的软件了。
当客户端有升级、安装的需求时,yum 会向软件库要求清单的更新,等到清单更新到本机的 /var/cache/yum 里面后,等一下更新时就会用这个本机清单与本机的RPM 数据库进行比较,这样就知道该下载什么软件。接下来 yum 会跑到软件库服务器(yum server)下载所需要的软件(因为有记录软件所在的网址),然后再透过RPM 的机制开始安装软件。
一般来说,RPM类型的文件在安装的时候,会先去读取文件内记载的设定参数内容,然后将该数据用来比对 Linux 系统的环境,以找出是否有属性相依的软件尚未安装的问题。
若环境检查合格了,那么 RPM 文件就开始被安装到你的 Linux 系统上。安装完毕后,该软件相关的信息就会被写入 /var/lib/rpm/ 目录下的数据库文件中了。未来如果有任何软件升级的需求,版本之间的比较就是来自于这个数据库,而如果想要查询系统已经安装的软件,也是从这里查询的。同时,目前的 RPM 也提供数字签名信息,这些数字签名也是在这个目录内记录。
软件内的文件:
rpm -ivh package_name
另外,如果在安装的过程当中发现问题,或者已经知道会发生的问题,而还是【执意】要安装这个软件时,可以使用如下的参数【强制】安装上去:
以 -Uvh 或 -Fvh 来升级即可,而 -Uvh 与 -Fvh 可以用的选项与参数,跟 install 是一样的。
RPM 在查询的时候,其实查询的地方是在 /var/lib/rpm/ 这个目录下的数据库文件。另外,RPM 也可以查询未安装的 RPM 文件内的信息。
rpm -a #已安装软件
rpm -q[licdR] 已安装的软件名称 # 已安装软件
rpm -qf 存在于系统上面的某个文件名 # 已安装软件
rpm -qp[licdR] 未安装的某个文件名 # 查阅 RPM 文件
在查询的部分,所有的参数之前都需要加上 -q
才是所谓的查询!查询主要分为两部分,一个是查已安装到系统上面的的软件信息,这部份的信息都是由 /var/lib/rpm/ 所提供。另一个则是查某个 rpm 文件内容,等于是由 RPM 文件内找出一些要写入数据库内的信息就是了,这部份就得要使用 -qp
(p是package 的意思)。
验证(Verify)的功能主要在于提供系统管理员一个有用的管理机制。作用的方式是【使用 /var/lib/rpm 底下的数据库内容来比对目前 Linux 系统的环境下的所有软件文件】也就是说,当有数据不小心遗失,或者是因为误杀了某个软件的文件,或者是不小心不知道修改到某一个软件的文件内容,就用这个简单的方法来验证一下原本的文件系统,了解这一阵子到底是修改到哪些文件数据了。
rpm -Va
rpm -V 已安装的软件名称
rpm -Vb 某个 RPM 文件的档名
rpm -Vf 在系统上面的某个文件
示例:
会发现在档名之前有个 c ,然后就是一堆奇怪的文字了。c 代表的是 configuration,就是配置文件的意思。至于最前面的几个信息是:
S:(file Size differs) 文件的容量大小是否被改变;
M:(Mode differs) 文件的类型或文件的属性(rwx)是否被改变?如是否可执行等参数已被改变
5 :(MD5 sum differs) MD5这一种指纹码的内容已经不同
D:(Device major/minor number mis-match)装置的主/次代码已经改变
L:(readLink(2) path mi s-match) Link 路径已被改变
U:(User ownership differs)文件的所属人已被改变
G:(Group ownership differs)文件的所属群组已被改变
T:(mTime differs)文件的建立时间已被改变
P:(caPabilities differ)功能已经被改变
所以,如果当一个配置文件所有的信息都被更动过,那么他的显示就会是:
至于那个 c 代表的是【Config file】的意思,也就是文件的类型,文件类型有底下这几类:
c:配置文件(config file);
d:文件数据文件( documentation);
g:鬼文件~通常是该文件不被某个软件所包含,较少发生(ghost file);
l:许可证文件 ( license file);
r:自述文件(read me)
软件开发商原厂所推出的软件也会有一个厂商自己的签章系统,只是这个签章被数字化了而已。厂商可以数字签名系统产生一个专属于该软件的签章,并将该签章的公钥(public key)释出。
当要安装一个RPM文件时:
1.首先你须要先安装原厂释出的公钥文件;
2.实际安装原厂的 RPM 软件时,rpm 指令会去读取 RPM 文件的签章信息,与本机系统内的签章信息比对;
3.若签章相同则予以安装,若找不到相关的签章信息时,则给予警告并且停止安装喔。
CentOS 使用的数字签名系统为 GNU 计划的 GnuPG (GNU Privacy Guard, GPG)。GPG 可以透过哈希运算,算出独一无二的专属密钥系统或者是数字签名系统。
CentOS的数字签名位于:
由于不同版本 GPG 密钥文件放置的位置可能不同,不过档名大多是以 GPG-KEY 来说明的,因此可以简单的使用 locate 或 find 来找寻。
那安装完成之后,这个密钥的内容会基本上都是使用 pubkey 作为软件的名称的。
反安装就是将软件卸载。要注意的是,【解安装的过程一定要由最上层往下解除】。
重建数据库:
由于RPM文件常常会安装/移除/升级等,某些动作或许可能会导致 RPM 数据库 /var/lib/rpm/ 内文件破损。可以使用 --rebuilddb 这个选项来重建:
rpm --rebuilddb # 重建数据库
yum是透过分析 RPM 的标头资料后,根据各软件的相关性制作出属性相依时的解决方案,然后可以自动处理软件的相依属性问题,以解决软件安装或移除与升级的问题。
由于 distribution 必须要先释出软件,然后将软件放置于 yum 服务器上面,以提供客户端来要求安装与升级之用的。因此想要使用 yum 的功能时,必须要先找到适合的 yum server 才行。而每个 yum server 可能都会提供许多不同的软件功能,那就是【软件库】。
透过 yum 这个指令。
查询功能:yum [list|info|search|provides|whatprovides] 参数
如果想要查询利用 yum 来查询原版 distribution 所提供的软件,或已知某软件的名称,想知道该软件的功能,可以利用 yum 相关的参数为:
yum [option] [查询工作项目] [相关参数]
安装/升级功能: yum [install | update]软件
yum [option] [安装与升级的工作项目] [相关参数]
移除功能:yum [remove] 软件
yum remove pam-devel
因此,当要找软件库所在网址时,最重要的就是该网址底下一定要有个名为 repodata 的目录存在,该目录就是分析 RPM 软件后所产生的软件属性相依数据放置处。
[base]:代表软件库的名字。中括号一定要存在,里面的名称则可以随意取。但是不能有两个相同的软件库名称,否则yum会不晓得该到哪里去找软件库相关软件列表文件。
name:只是说明一下这个软件库的意义而已,重要性不高;
mirrorlist=:列出这个软件库可以使用的映射站台,如果不想使用,可以批注到这行;
baseurl=:这个最重要,因为后面接的就是软件库的实际网址。mirrorlist 是由 yum 程序自行去捉映像站台,baseurl 则是指定固定的一个软件库网址;
enable=1:就是让这个软件库被启动。如果不想启动可以使用 enable=0;
gpgcheck=1:指定是否需要查阅 RPM 文件内的数字签名;
gpgkey=:就是数字签名的公钥文件所在位置,使用默认值即可。
测试一下这些软件库是否正常的运作中:
修改软件库产生的问题与解决之道
由于修改系统默认的配置文件,事实上,应该要在 /etc/yum.repos.d/ 底下新建一个文件,该扩展名必须是.repo才行。但因为我们使用的是指定特定的映像站台,而不是其他软件开发商提供的软件库,因此才修改系统默认配置文件。
但是可能由于使用的软件库版本有新旧之分,yum 会先下载软件库的清单到本机的 /var/cache/yum 里面去。那修改了网址却没有修改软件库名称(中括号内的文字),可能就会造成本机的列表与 yum 服务器的列表不同步,此时就会出现无法更新的问题。
需要清除掉本机上面的旧数据即可,透过yum的clean项目来处理即可:
yum clean [packages|headers|all]
yum [群组功能] [软件群组]
查阅目前软件库与本机上面的可用与安装过的软件群组:
可以手动选择是否需要升级,也可以啊!透过【yum -y update】来自动升级,-y
很重要,因为可以自动回答 yes来开始下载与安装。然后再透过 crontab 的功能来处理即可。
RPM 与Tarball各有其优缺点,不过,如果有RPM的话,那么优先权还是在于RPM安装上面,毕竟管理上比较便利,但是如果软件的架构差异性太大,或者是无法解决相依属性的问题,不如直接以tarball 来安装。
1.安装:yum install (软件);
2.启动:systemctl start (软件);
3.开机启动:systemctl enable (软件);
4.防火墙:firewall-cmd --add-service=“(服务)”; firewall-cmd --permanent --add-service=“(服务)”;
5.测试:用软件去查阅服务正常与否;
新版的 rpm 已经将 RPM 与 SRPM 的指令分开了,SRPM 使用的是 rpmbuild 这个指令,而不是rpm。
假设下载了一个SRPM 的文件,又不想要修订这个文件内的原始码与相关的设定值,利用 rpmbuild 配合选项可以直接编译并安装。
选项主要有底下两个:
要注意的是,这两个选项都没有修改过 SRPM 内的设定值,仅是透过再次编译来产生 RPM 可安装软件文件而已。一般来说,如果编译的动作顺利的话,那么编译过程所产生的中间暂存盘都会被自动删除,如果发生任何错误,则该中间文件会被保留在系统上,等待用户的除错动作。
一般来说,如果有需要用到 SRPM 的文件,大部分的原因就是…需要重新修改里面的某些设定,让软件加入某些特殊功能等等的。所以,此时就得要将 SRPM 拆开,编辑一下编译配置文件,然后再予以重新编译。
SRPM 既然含有 source code ,那么其中必定有配置文件,所以首先必需要知道,这个 SRPM 在进行编译的时候会使用到哪些目录,这样才能够来修改嘛。
从CentOS 6.x 开始,因为每个用户应该都有能力自己安装自己的软件,因此 SRPM 安装、设定、编译、最终结果所使用的目录都与操作者的家目录有关。
假设用 root 的身份来进行 SRPM 的操作,那么应该就会使用到下列的目录:
此外,在编译的过程当中,可能会发生不明的错误,或者是设定的错误,这个时候就会在 /tmp 底下产生一个相对应的错误档,可以根据该错误档进行除错的工作。等到所有的问题都解决之后,也编译成功了,那么刚刚解压缩之后的文件,就是在 /root/rpmbild/,{SPECS,SOURCES,BUILD} 等等的文件都会被杀掉,而只剩下放置在/root/rpmbuild/RPMS底下的文件了。
在 /root/rpmbuild/SOURCES 里面会放置原始档 (tarball) 以及相关的修补档(patch file),而编译需要的步骤大抵就是 ./configure, make, make check, makeinstal l等,这些动作写入在SPECS目录中。
vim net.spec
ntp.sepc 这个文件主要的将 SRPM 编译成 RPM 的配置文件,他的基本规则:
1.整个文件的开头以 Summary 为开始,这部份的设定都是最基础的说明内容;
2.然后每个不同的段落之间,都以%来做为开头,例如 %prep 与%install等;
系统整体信息
上面几个资料通常都必需要写。但是如果软件没有相依属性的关系时,那么就可以不需要那个 Requires。根据上面的设定,最终的档名就会是【{Name}-{Version}-{Release}.{Arch}.rpm】的样式。
%description:
将软件做一个简短的说明。
%prep:
pre 这个关键词原本就有【在…之前】的意思,因此这个项目在这里指的就是【尚未进行设定或安装之前,要编译完成的 RPM 事先做的事情】,就是 prepare 的简写。
工作事项主要有:
1.进行软件的补丁(patch)等相关工作;
2.寻找软件所需要的目录是否已经存在?确认用的;
3.事先建立软件所需要的目录,或者事先需要进行的任务;
4.如果待安装的 Linux 系统内已经有安装的时候可能会被覆盖掉的文件时,那么就必需要进行备份(backup) 的工作了。
%build:
build 就是建立。这个段落就是在谈怎么 make 编译成为可执行的程序。一般来说,如果会使用SRPM来进行重新编译的行为,通常就是要重新 .configure 并给予新的参数设定,因此这部份就可能会修改到。
%install:
编译完成(build)之后,就是要安装了。安装就是写在这里,也就是类似 Tarball 里面的 make install 的意思;
%files:
这个软件安装的文件都需要写到这里来,当然包括了【目录】。所以连同目录请一起写到这个段落当中以备查验呢。此外,也可以指定每个文件的类型,包括文件档(%doc后面接的)与配置文件(%config 后面接的)等等。
%changelog:
这个项目主要则是在记录这个软件曾经的更新纪录。星号(*
)后面应该要以时间,修改者,email与软件版本来作为说明,减号(-
)后面则是要作的详细说明。
要将在 /root/rpmbuild 底下的数据编译或者是单纯的打包成为 RPM 或 SRPM 时,就需要 rpmbuild 指令与相关选项。
rpmbuild -ba ntp # 编译并同时产生 RPM 与 SRPM 文件
rpmbuild -bb ntp # 仅编译成 RPM 文件
这个时候系统就会这样做:
1.先进入到 BUILD 这个目录中,亦即是: /root/rpmbuild/BUILD 这个目录;
2.依照 *.spec 文件内的 Name 与 Version 定义出工作的目录名称,并进入该目录;
3.在新建的目录里面,针对 SOURCES 目录下的来源文件,也就是 *.spec里面的 Source 设定的那个文件,以 tar 进行解压缩;
4.再来开始 %build 及 %install 的设定与编译;
5.最后将完成打包的文件给他放置到该放置的地方去,如果系统是x86_64 的话,那么最后编译成功的*.x86_64.rpm文件就会被放置在 /root/rpmbuild/RPMS/x86_64 里面;如果是 noarch 那么自然就是 /root/rpmbuild/RPMS/noarch目录下。
《鸟哥的Linux私房菜-基础篇》学习笔记