开发者学堂课程【Linux 软件包安装和 yum 仓库实战:RPM 包管理-1】学习笔记,与课程紧密联系,让用户快速学习知识。
课程地址:https://developer.aliyun.com/learning/course/590/detail/8335
RPM 包管理-1
内容简介:
一、Linux 安装软件的两种方式
二、包命名和工具
三、库文件
四、包管理器
一、Linux 安装软件的两种方式
对于 Linux 来讲,安装软件主要有两种方式。
第一种是利用二进制已经编译完了的程序安装。软件包的安装方法本质上就是把那些已经编译好的二进制文件,按照规定的路径知道复制到相应的文件夹,可以直接使用。
第二种方式是源代码。需要人为的去编译,编译结束了以后,还是要安装到目录下,加以配置,之后再来使用。
大体上就是两个类,但是即使拿到的是已经编译完了二进制,真正要用的话,中间还需做些必要的工作。
例如将一些必要的文件,按照程序开发者规定好的路径放到不同的目录中,有些软件可能还要适当的去加配置才能使用,所以中间的这两个步骤。
如果让普通用户去实现,也是稍显繁琐的。因此有很多软件的开发者,就把这两个步骤,用一些方法来解决简化用户使用软件的难度,或者是简化这个过程。
其中红帽公司提出了用 RPM 的包的方式来进行软件的管理,可以轻松解决以上的问题。它把预先定义好的,已经编译完了的二进制文件利用RPM工具,自动的把那些文件复制到、安装到不同的目录下,在一些场合下,可能会增加一些配置搭配。
例如创建对应的一些用户账号等等,给用户准备好环境,直接使用即可,非常便捷。在本章中,除了 RPM 这种方式,还有一种安装方式就是 yum,实际上与 RPM这种方式是一样的只不过 yum 有自己的特点。RPM 包管理软件的常见用法。
那么在 Linux 里面,3DOS 系统中官方,光盘里面带有的这些安装包安装文件与平常 Windows 里用的各种软件不一样。
可以看到红帽的安装光盘里面,安装文件通通的都是一种格式,就是 RPM 格式。那里面有几千个文件。
全是用 RPM 方式来管理和组织安装程序的,接下来学习 Rpm 文件格式的定义。
二、包命名和工具
包:分类和拆包
Application-VERSION-ARCH.rpm: 主包
Application-devel-VERSION-ARCH.rpm 开发子包Application-utils-VERSION-ARHC.rpm其它子包Application-libs-VERSION-ARHC.rpm其它子包
包之间:可能存在依赖关系,甚至循环依赖
解决依赖包管理工具:
yum : rpm 包管理器的前端工具
apt-get : deb 包管理器前端工具
zypper: suse 上的 rpm 前端管理工具
dnf: Fedora 18+ rpm 包管理器前端管理工具
源代码: name-VERSION.tar.gzlbz2lxzVERSION: major.minor.release
rpm包命名方式:
name-VERSION-release.arch.rpm15IJ: bash-4.2.46-19.el7.x86_ 64.rpmVERSION: major.minor.release
release : release.OS
“//光盘的命名方式是这样的,名称,就是包的软件名,再加上版本号,再加上release ,release,也算是个版本号。后面是架构。再加上 rpm 后缀。光盘里面的rpm 包,它的结构基本上都是这种形式的。”
常见的 arch:
x86: i386, i486, i586, i686
x86_ 64: x64, x86 64, amd64powerpc: ppc
跟平台无关: noarch
LastLoginMon15 08:57:28 2018
[
root@centos7~
]
[
root@centos7~
]
[
rootacentos7~
]
[
root@centos7~
]
#df
Filesystem1K-blocks
Used Available Use% Mounted on
/dev/sda2
52403200 3893692
48509508
8%
/
devtmpfs
916724
0
916724
0%
/dev
tmpfs
932652
932652
0%
/
dev/
shm
tmpfs
932652
10616
922036
2%
/
run
tmpfs
932652
932652
0%/sys/fs/cgroup
/dev/sda3
31441920
34792
31407128
1%data
/dev/sda1
1038336
168556
869780
17%/boot
tmpfs
186532
32
186500
1%
/run/user/0
/dev/sr0
9176232
9176232100%/run/media/root/Centos7
x86
_
64
[root@centos7 ~]#11 /run/m
mcelog-client
mce1og.pid
mdadm/
media/
mount/
[rootdcentos7 ~]#11 /run/media/root/Centos\ 7\x86_64/
Centos_BuildTag
images/
RPM-GPG-KEY-Centos-7
discinfo
isolinux/
RPM-GPG-KEY-Centos-Testing-7
EFI/
Liveos/
TRANS.TBL
EULA
Packages/
treeinfo
GPL
repodata
[
root@centos7 ~]
#1s/run/media/root/Centos)7x86_64/Packages/
###
//Windows 的安装光盘已经挂在了当前 run 这个目录下。那在这个目录下有几千个,都是 rpm 为后缀的安装软件包。在 Windows 里,通常在 Windows 里装的软件,只是一个目录而已。
而那个目录解开以后,有好多各种各样的文件,其中有一个安装文件。setup 文件双击安装就行了。但是其他的文件有各种各样的类型。那么在系统中,这个安装包都是打包成了一个 rpm 文件。
Yum-updateboot
//软件的名称
1.1.31
//这个是版本号
版本编号是这个软件的开发者定义的。
在深度系统中,我们很多软件并不是红帽公司开发的,只是一个集成者而已。其中带有的很多软件都是第三方组织不同的组织研发出来的。那么这些组织开发自己的软件的时候,添加的这个软件的版本号,是由这个开发者来维护的。
11.e7x86_64.rpm
//实际上这个是 Cent 系统是红帽公司人为的给他添加的版本。
这个版本,简单的说,组织拿到源码以后,需要用源码进行编译成二进制。那其中编译的过程,需要尝试很多次。
Zip-3.0-11
//11是编译打包的次数。
同一个软件,中间可能经过了若干次编译,这是编译打包的过程,编译的次数介绍。
//虽然软件包是同一个,尝试编译的时候若干次编译。这个编译是基于企业版渗透思的热版本六或七的,是针对 Cpu 架构的。这是 RPM 包它的命名规范。
//要是从一个项目的官方网站看到源码,源码文件格式,没有 11.e7x86_64.rpm,此时源码由文件软件的名称和版本组成。
例如:当下载过 Linux 的源码和 httpd 的源码时,源码包的命名方式就是软件名加版本号加压缩格式。
与渗透思的安装光盘安全包命名方式是不一样的。
实际上只是在后期源码编译的时候,人为加的一些,编译的次数。
x86_64.
//这个是针对什么平台做了编译。源码拿到以后,可以在不同的平台上编译。
x86_64.
1686. rpm
1687.
//例如:可以在32位的 cpu 上编译,也可以在64位的 cpu 上编译。甚至,可以在非英特尔架构的 cpu上进行编译,都没问题。
所以编译完了以后,最终生成二进制之后,文件在什么平台上使用,就会固定下来。
在没有编译的时候,如果只是源码,可以在编译的某些平台上进行使用。
所以这就是互联网上发布的软件很多都是源码的原因,因为考虑到环境不一样。
有的用户选择使用这样的cpu架构,有的用户选择另外另外一些cpu架构。有源码,用户可自由选择平台编辑,所以互联网上很多文件都是源码发布。
//当然,渗透思的安装光盘是已经编辑完成的,因为光盘给用户的时候已经明确的告诉用户,这个光盘就是适合于64位的cpu或英特尔cpu架构的安装光盘,所以里面的这些包也都是只适合于英特尔的64位的架构的平台上去使用。除了常见的X86、64这种 cpu 架构,事实上也有一些非英特尔架构如 Powerpc、ppc。Adm 有自己的 cpu 架构。
计算机基础中很多种类型的计算机,当然,英特尔 cpu 是主流,但是也有一些其他类型的 cpu。
对于一个软件,如果它比较复杂的话。通常采用拆包的方式。
Yum-plugin 代表着 Yum-插件,实际上它本身就有各种各样的插件。
分成了很多类别。包括 Zipb 实际上是基于 matlab 的库,这是一种程序编开发库,这种库又给用户拆分成了若干个类别,若干个子类,为了使用软件的时候更加灵活,一个大类型的包往往拆分成了多种小类型子类型。
将来用到哪个子类型的包,可以单独按装,而不至于说就想装一个小的类别还需要把所有的类别都装上。
假设你有一个 application 应用程序,可能涉及到开发包工具包,以及相关的库包,把同一类型的应用程序的包给用户。
已经编译完了的二进制程序,正如在 Windows 上安装一些软件一样。Windows 安装软件不是说拿到安装程序,直接双击安装就能够顺利的安装的。在有些场景下,会发现在用户安装一些 Windows 软件,系统可能会提示用户:缺少哪些程序文件。
有的时候,系统说缺少程序之类的,用户就会收到提示。软件官方给用户提供那个软件包,可能并不是很完整的。它可能会依赖于Windows上一些现有的程序。用户需要事先把这些依赖的那些程序先装好,才能把这些软件装上。
同样的道理,在 Linux 里安装一个 RPM 包,可能也有依赖性。这种依赖性,就导致用户在装某个包的时候,安装时,会收到系统提醒。系统提醒缺 B 包时,用户先把 B 包装上。当然,用户装B包后发现B包可能又依赖于 C 包。
//这种依赖性是很严重的,不像平时在 Windows 安装软件,依赖性不多。当然因为系统要保证用户体验较好,所以大部分情况下安装软件都是比较顺利。只是偶尔个别情况下缺一些某些包,在 Linux 里面,rpm 包这种依赖性是比较多的,因为每个包都不大,所以用户安装某个包,会依赖着别的包,可能都已经有独立的 rpm包。而且这些 rpm 包不一定已经装上。,所以系统这时候,就提醒用户缺少某个包。
甚至可能还会出现循环依赖,所谓循环依赖,那就是A依赖于B,B依赖于C,C依赖于 A。当出现这样的问题时 ABC 包要一起装。
当然对于 RPM 的依赖性,没有办法来解决。可以一下子装多个包,后面跟多个包名称,但是这种包的依赖性,不能够自动的把依赖的包找到并且安装,只能一个一个的装。
用户缺什么,系统就提醒用户,然后用户再找那个依赖包再安装,装的时候还可能提醒用户依赖于别的包。对于cent OS的系统来讲,包的依赖性的解决方案就是用yum。当然渗透思的系统版本后期,不断的更迭和升级,那后期可能会有这样的一个 dnf 包的解决方案来代替。
//dnf 包是在 fedora18 这个版本以后,能够解决依赖性的包。DNF 的效率要更高,安装速度要更快。Dnf 使用和 yum 实际上基本上一样,就是命令给变成 DNF。对于非红帽的光盘,解决方案不一样。这样的一些其他的解决方案。例如 deb 可以用Apt -get。Suse 的用 zypper。不同的工具和版本,它的解决方案是不一样的。
三、库文件
查看二进制程序所依赖的库文件
ldd /PATH/TO/BINARY FILE
管理及查看本机装载的库文件
ldconfig
加载配置文件中指定的库文件
/sbin/ldconfig -p
显示本机已经缓存的所有可用库文件名及文件路径
映射关系
配置文件: /etc/ld.so.conf, /etc/ld.so.conf.d/* .conf
缓存文件: /etc/ld.so.cache
Indexof/epel/
4AS/I
11-Apr-2017 15:28
11-Apr-2017 15:28
4ES/
11-Apr-2017 15:28
49S/
11-Apr-2017 15:28
5
11-Apr-2017 15:31
5Client/
11-Apr-2017 15:31
11-Apr-2017 15:31
5Seryer
26-0ct-2017 09:49
6Serverl
26-0ct-2017 09:49
26-0ct-201700:25
7Server/
26-0ct-201700:25
project
22-Nov-2017 14:00
teetingl
30-Aug-2014 16:49
EPM-GPC-KEY-EPEL
03-ar-2007 14:11
1698
EPM-GFG-KEY-EPEL-4
03-1ar-2007 14:11
1698
RPI-GPG-KEY-EPEL-5
03-ar-2007 14:11
1698
RPM-GPG-KEY-EPEL-6
12-1ay-201001:25
1649
RPI-GPG-KEY-EPEL-6Server
12-ay-2010 01:25
1649
RPU-GPG-KEY-EPEL-7
RPI-GPG-KEY-EPEL-7Server
20-Jun-2014 18:54
20-Jun-2014 18:54
1662
1662
tnelcrelease-latest-6.noarch.rpm
05-Nov-2012 15:3114540
cpel-release-latest-7.noarch rp
02-0ct-2017 17:52
15080
fullfilelist
12-0ct-2018 21:49
170444355
fullfiletimelist-erel
12-0ct-2018 21:34
9886192
inageliat-epel
23-Nov-2016 18:20
0
四、包管理器
程序包管理器:
功能:将编译好的应用程序的各组成文件打包一个或几个程序包文件,从而
方便快捷地实现程序包的安装、卸载、查询、升级和校验等管理操作
包文件组成(每个包独有)
RPM 包内的文件
RPM 的元数据,如名称,版本,依赖性,描述等
安装或卸载时运行的脚本
数据库(公共) : /var/lib/rpm
程序包名称及版本
依赖关系
功能说明
包安装后生成的各文件路径及校验码信息
程序包的来源
管理程序包的方式:
使用包管理器: rpm
使用前端工具: yum, dnf
获取程序包的途径:
(1)系统发版的光盘或官方的服务器
CentOS 镜像:
https://www.centos.org/download/http://mirrors.aliyun.com
http://mirrors.sohu.com
http://mirrors.163.com
(2)项目官方站点
3)第三方组织:
Fedora-EPEL :
Extra Packages for Enterprise Linux
Rpmforge:RHEL 推荐,包很全
搜索引擎:
http://pkgs.org
http://rpmfind.net
http://rpm.pbone.net
https://sourceforge.net/
(4)自己制作
注意: 第三方包建议要检查其合法性
来源合法性,程序包的完整性
Rpm 包管理
CentOS 系统上使用 rpm 命令管理程序包:
安装、卸载、升级、查询、校验、数据库维护安装:
rpm {-i--instal} [install-options] PACKAGE FILE..
-V: verbose
-VV:
-h:以#显示程序包管理执行进度
rpm -ivh PACKAGE FILE...