阿里云
为了无法计算的价值
打开APP
阿里云APP内打开
学习中心> Linux软件包安装和yum仓库实战> 正文

Linux软件包安装和yum仓库实战

6课时 |
12364人已学 |
免费
课程介绍

内容简介:

一、Linux安装软件的两种方式

二、包命名和工具

三、库文件

四、包管理器

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

Last    Login    Mon    15 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.

  1. rpm

//例如:可以在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

 

(4)自己制作

注意: 第三方包建议要检查其合法性

来源合法性,程序包的完整性

Rpm  包管理

CentOS  系统上使用 rpm 命令管理程序包:

安装、卸载、升级、查询、校验、数据库维护安装:

rpm {-i--instal} [install-options] PACKAGE FILE..

-V: verbose

-VV:

-h:以#显示程序包管理执行进度

rpm -ivh PACKAGE FILE...

我的学习进度
请登录后查看您的学习进度!
立即登录
本课程相关云产品