linux程序包管理初步

Posted 2020-08-20

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了linux程序包管理初步相关的知识，希望对你有一定的参考价值。

Linux程序包管理

我们linux操作系统从底层到高层的层次结构：

最底层首先是硬件，计算机的计算能力都是在硬件逻辑上设计实现的，而不同厂商生产的芯片哪怕是同一厂商生产的同一型号的芯片，他们给我们提供的计算接口都不一样，我们基本都同说过嵌入式开发，那么这种开发如果没有系统可以使用的话，主要是面向硬件，来写程序的，而这种程序只能适应一种或者几种有限的芯片，单片机尤其如此，现在很多嵌入式开发过程中，也已经有了一种通用层来实现，但是像单片机这种还是面向硬件编程的，

然后在底层之上就是将硬件接口封装起来的操作系统层，系统层将底层的硬件接口封装起来以后，通过系统调用（system call），向上输出，但是系统调用仍然很底层，为了加速开发操作，在操作系统层之上又加了半层叫“库（lib call）”，注意这里不是全层，而是半层，因为对于程序员来讲，可以面向半层“库”来写程序，也可以面向我们的操作系统来写程序，然后在库之上就是应用程序了，应用程序是给我们真正带来一些生产力的，我们的内核是不能完成任何具体的操作的，在这众多的应用类型程序中，我们知道有一类比较独特的，他主要是让用户跟主机交互的，叫shell任何利用操作系统完成任务的操作，都是通过应用程序完成的，所以我们说将来我们真正去实现运维操作的过程中，除了系统管理，库调用管理之外，其实作为运维人员来讲，就是不停的在我们的操作系统上安装配置某一应用程序包，然后让这个应用程序包运行起来，并提供服务，或者利用此工具完成某种具体相应操作的过程。那对于我们运维人员来讲，安装卸载管理程序包，是实现很多后期工作的最基础，最根本的任务，所以首先我们要学会灵活实现对于程序包的安装管理操作。

任何程序的运行，他有可能在程序包上提供两种格式的程序包，我们称之为源码包或者叫二进制包，那么我们将到这就不得不回顾一下以前讲到的API和ABI，API叫应用程序开发接口，ABI叫应用程序二进制接口。我们说过，API层次兼容未必ABI层次兼容。因为有些操作系统他们执行程序的格式，或者对二进制的是识别格式，并非是相同的，像linux跟类unix（Unix-like）他们的操作系统，一般而言是相同的，他们的ABI是相同的，但是与windows相差很远，比方说windows系统上的可执行程序都是exe或者是msi的，而linux上的是elf格式的。所以他们在ABI层次不兼容，所以我们说即使我们使用高级编程语言，去编写程序，他们即便是在源码格式兼容的，但是一旦编译成功以后，本来是linux上面的格式的，而跑到windows上一样依然无法运行。所以有一个程序包，在linux上编译好了，他是二进制格式的，我们是不能拿来装到windows之上的。反过来如果一个程序包在windows上编译好了，是一个exe格式的文件，能不能在linux系统上运行起来呢？也很难。我们可以借助虚拟化将二者的差异将其磨平了，比方说现在的各种各样的应用程序，几乎都是针对库调用来开发的，很少说是直接通过系统调用来实现。即使是通过系统调用来实现，那也没问题，现在在windows上有很多程序模拟linux的库，在linux上也有很多模拟windows库的程序。

比方说现在这里有一个linux操作系统，没关系我们装一个WinE，这个wine就能在linux上模拟出windows库来。所以我们就可以借助wine来运行windows应用程序。比方说希望在linux上玩的各种各样的游戏，甚至还能给我们提供一个安装的路径，模拟出windows上的C盘D盘E盘。但这只是一个库虚拟层。同样在windows上我们也能提供linux运行环境。叫cywin，在windows之上运行一个cywin，他能够提供运行模拟出linux的运行环境来。所以说有一些程序只能在linux上运行的话，我们也能在windows上基于cywin运行起来，比如说像docker。这都不是正常的方案，正常的方案就是，由于abf库是不兼容的，至少在二进制层次上他们是不兼容的。所以他们没有办法安装块系统来实现系统调用。

库级别的虚拟化：我们可以借助库级别的虚拟化来抹平他们的不同。比如在linux上我们可以借助于wine来提供windows库从而能够运行windows应用程序。而在Windoes上我们借助于Cywin这个程序包，来虚拟模拟出linux的运行环境。从而使得那些二进制程序也能跨系统来运行了。

系统级开发：

C/C++：服务及应用程序：httpd，vsftpd，nginx

应用级开发

java/Python/perl/ruby/php

java：hadoop，hbase，（他们的运行需要jvm就是java虚拟机）

Python：openstack（openstack是一个云操作系统）

运行Python程序需要用到pvm（Python虚拟机）

运行perl：（依赖于perl）

运行ruby：（依赖于ruby解释器）

运行php：（依赖于php解释器）

C/C++程序格式：

源代码：文本格式的程序代码；

二进制格式：文本格式的程序代码---->编译器------>二进制格式（二进制程序，库文件，配置文件，帮助文件）

（二进制格式我们仅仅是指他的陈序和库是二进制的，他的配置文件和帮助文件当然是文本的。我们知道Linux重要的哲学思想之一就是：用文本文件保存配置信息，这样带来的好处就在于，我们将来配置任何应用程序时，只需要依赖一款文本编辑器就可以。）

所以我们将来要想安装应用程序，那么针对我们两种格式的内容，他的安装方式就显然不一样，我们知道源代码不能运行，所以我们必须将其编译以后将其安装运行。对于源代码而言我们要手动把“文本格式的程序代码---->编译器------>二进制格式”这个过程手动完成。如果是别人给我们提供的是二进制格式的文件，上面的过程就不需要我们自己做了。因为我们拿到的直接是可运行格式的。万一很不幸的是对方仅提供了源代码怎么办呢？那么我们就只能自己编译了。而要想能够自己编译的话，那就依赖于编译开发环境。因为编译要依赖于编译器，依赖于头文件，依赖于开发库。我们的库也是源代码格式的，所以库也有两种文件。后来我们把它编译成了二进制格式的。

所以我们的编译开发环境依赖于：编译器，头文件，开发库。

如果我们拿到的是二进制格式的，那么就不需要编译，我们直接放到目录下就能运行起来了。

所以我们如果要执行源代码编译安装，那么我们需要额外的准备好几步。至少我们要想方设法保证我们的编译环境是完整的。而提供编译环境是相当劳心费神的工作。

我们学习程序包安装，首先了解二进制格式是怎么安装的，然后再去了解如何源代码编译安装。上面是C程序的格式。

那么如果是应用级的程序格式呢？

那么我们就以JAVA和Python为例，那么JAVA和Python应用程序格式是一样的，

java/python程序格式：

源代码

二进制

同样的道理，如果是源代码格式，那也只能编译了，如果是二进制格式那么直接使用即可

但是他们的编译不同在于，他们编译出来的不是二进制格式，或者不是能够直接在CPU上直接运行的二进制格式，而是编译成其能够在虚拟机上（jvm/pvm）运行的程序格式。也就是说通过虚拟机将其转换成能够运行的二进制格式。中间多了一层，所以性能很差。或者说比起C语言性能比较差。通常来说无论是C格式的源代码，还是java格式的源代码，通常他们的程序文件，都不止一个。那为什么不止一个？

将来我们的程序文件在编译时存在错综复杂的依赖关系，导致我们有一百个程序源文件，很有可能我们先编译第一个，在编译第三个，在编译第二个。因为第一个第三个被第二个所依赖。这样带来的结果就是谁先编译谁后编译，作为使用者我们没有能力管理他们的编译顺序。所以各种各样的源代码通常都使用一个项目管理工具。或者叫项目构建工具。

项目构建工具：

C/C++：最著名的项目构建工具就叫make

java：最经典的项目构建工具就叫maven

这样项目构建工具，也必须依赖项目开发环境才能构建。而对于java来讲他也有自己的开发环境。他也需要开发环境。只不过对于这两种的编程语言来讲。他们的开发环境，通常指的是，那个对应应用程序的虚拟机，和虚拟机上面的编译器。java源代码编译也需要开发环境，只不过是没有头文件，他们也需要：编译器，卡发库。这也是我们程序包的组成格式。

为了降低初级使用者的难度，我们应该怎样做？

我们应该使用程序包管理器，来协助这些终端用户的管理工作。

程序包管理器：

源代码---->目标二进制格式----->组织成为一个或有限几个“包”文件；

安装，升级，卸载，查询，（甚至对linux上还支持）校验

程序包管理器：

（程序包管理器大体上有哪几种呢？

对于windows来讲，大多数的应用程序都是exe格式的。这种格式应用程序给我们提供一个安装界面，我们只需点击下一步下一步即可，卸载的时候我们通过我们控制面板中的，卸载应用程序来实现，为什么我们能看到的只是下一步下一步就能完成安装呢？他其实就是通过一个程序包管理器打包成一个单个的exe文件，我们知道我们安装完以后他的确分散成多个可能放在program/files目录下某一个路径下，每一个应用程序都有一个目录，里面存放各种文件，有二进制的有库的，对于windows来说，他们的库是dll文件，动态链接库，dynamic link，而对于linux而言，叫so。）

目前linux有三大主流分支：

debian：dpt,dpkg,".dep"

redhat：redhat package manager，简称：rpm，".rpm"；rpm ispackage manager；

S.u.S.E：rpm，".rpm"，

Gentoo：ports

ArchLinux：

源代码：

命名方式：name-VERSION.tar.gz

VERSION：major.minor.release //主版本号.次版本号.发行版本

rpm包命名格式：

name-VERSION-release.arch.rpm //release是rpm包的release。

VERSION：major.minor.release

release.arc：是指rpm包的发行号

release.os：2.el7.i386.rpm

archetecture：架构，i386，x64（amd64），ppc，noarch

redis-3.0.2.targz----->redis-3.0.2-1.centos7.x64.rpm

changelog：

拆包：主包和支包

主包：name-VERSION-release.arch.rpm

支包：name-function-VERSION-release.arch.rpm

function：devel,utils,libs.....

依赖关系：

x,y,z

x------依赖--->y,z

y------依赖-------->A,B,C

c--------->y

前端工具：自动解决依赖关系；

yum：rhel系列系统上rpm包管理器的前端工具；

apt-get（apt-cache）：dep包管理器的前端工具；

zypper：suse的rpm管理器前端工具；

dnf：Fedora 22+系统上rpm包管理器的前端工具；

程序包管理器：

功能：将编译好的应用程序的各组成文件打包成一个或几个程序包文件，从而更方便的实现程序包的安装，升级，卸载，和查询等管理操作；

1.程序包的组成清单（每个程序包都单独实现）；

文件清单

安装或卸载时运行的脚本

2数据库（公共）

程序包的名称和版本；

依赖关系；

功能说明；

安装生成的各个文件的文件路径及校验码信息；

CentOS系列系统的rpm数据库：路径

/var/lib/rpm

[[email protected] ~]# ls /var/lib/rpm

Basenames __db.002 Group Obsoletename Requirename Triggername

Conflictname __db.003 Installtid Packages Sha1header

__db.001 Dirnames Name Providename Sigmd5

[[email protected] ~]#

解释：

Group：包组，我们可以将程序划分成一个组，将来可以把一个程序包组全部安上，一个组全部卸载。

Name：各个程序的名字；

Sigmd5：MD5的校验码；

Triggername：触发器名称；

获取程序包的途径：

（1）系统发行版的光盘或官方的文件服务器（或镜像站点）：

http://mirrors.aliyun.com

http://mirrors.sohu.com

http://mirrors.163.com

（2）项目的官方站点

举例：以thhp为例：站点httpd.apache.org

或者：

网站www.zabbix.com

打开网站www.zabbix.com网站，我们网站的导航栏中直接点击“Download”，打开一个页面，前面的“Zabbix Packages”是zabbix的rpm包，再往下“Zabbix Sources”是源码包。

所以说很多项目的官方站点也提供rpm包，并且我们一定注意，既然后能用rpm包安装的我们一定不要使用源码包编译安装。

（3）第三方组织：EPEL

EPEL：红帽官方的社区组织所维护的，发行光盘之外其他他们觉得比较有用比较重点，比较有名的程序包，都将制作成rpm包放在EPEL中。

其实国内的很多官方站点都有这样的epel。

举例演示，我们以“mirrors.aliyun.com”为例：

在镜像阿里云的站点上“mirrors.aliyun.com”也有epel，在epel中会为我们的centos提供了众多的额外的补充包。

（a）EPEL

（b）搜索引擎

http://pkgs.org（在rpm领域中，这是一个非常重要的）；

rpmfind.net（要想搜哪个文件包直接搜。）

rpm.pbone.net

上面对话框中，我们可以输入正确的内容来进行查询，我们还可以通过后面的

Advanced RPM Search

来进行高级查询。

（4）自己手动制作rpm包。

注意：不管上面的那种方式获得rpm包，只要是通过互联网上获得的，那么我们就可以认为即使原作者在里面没有做任何改变，或者修改，因为我们现在经常使用一些下载工具，像迅雷，那这种工具有点问题，为什么这种工具他的下载的速度非常的块，就是因为他们可能不是从官方的原站点下载的，或者是非完完全全的官方站点上下载的，其实从已经下载的用户的那里下载的，如果官方站点下载不到的话，而且这时候他恰恰搜索到某个用户的那里有这个文件，他也会传给你，但是这个文件可能被其他用户精心的修改过，制作了后门，所以以后我们在互联网上下载人格安全性较高的文件的，像银行官方站点的插件，还有像支付宝的证书等，我们就不应该在使用迅雷下载。以后这中工具少用，尤其是使用PHP下载的，是相当危险的，那么我们下载下来一个工具我们不知道他到底是不是官方提供的呢？

至少是所有的数据没有被篡改过，那怎么办呢？

我们建议要做MD5校验，提供一个MD5校验器，检验其合法性，来源合法性。

程序包的完整性要做校验；

CentOS系统上rpm命令管理程序包：

安装，升级，卸载，查询和校验，数据库的维护

上面提到的“安装，升级，卸载，查询和校验”都用rpm命令来实现。

格式： rpm [OPTIONS] [PACKAGE_FILE]

安装用到的选项：-i=--install

升级用到的选项：-U=--update, -F=--freshen

卸载：-e=--erase

查询：-q=--query

校验：-V=--verify

数据库维护：--builddb,--initdb

安装：

安装时必须有对应的文件才行。

rpm {-i|--install} [install-options]PACKAGE_FILE ...

真正安装的时候应该使用选项：-ivh

rpm -ivh PACKAGE_FILE......

GENERAL OPTIONS（通用选项）

-v：verbose；（输出相信信息）

-vv：（输出更详细的过程信息）

[install-options]

-h：hash marks输出进度条；每个#表示2%的进度；

--test：如果不想真正的安装，仅仅是检查一下有没有潜在的冲突的可能我们就可以测试安装，检查并报告依赖关系及冲突消息等；

--nodeps：忽略依赖关系；不建议；

--replacepkgs：重新安装（如果某个包安装过，但是后来我们更改了他的配置文件，出了错，那我们刻意先卸载再重新安装，但是我们还有一个更好的方法就是，直接重新安装。）

--noscripts：

--oldpackage：降级用的

--justdb：只是升级一下数据库。

注意rpm包可以自带脚本：

这些脚本有四类：

如果这四类都不想执行：--noscripts

preinstall：安装过程开始之前运行脚本，%pre --nopre

postinstall：安装过程完成以后运行的脚本，%post --nopost

preuninstall：卸载过程真正开始执行之前运行的脚本，%preun --nopreun

postuninstall：卸载过程完成之后运行的脚本，%postun --nopostun

--nosignature：不检查签名信息，不检查来源合法性；

--nodigest：不检查包完整性信息；

举例演示：

[[email protected] Packages]# rpm -ivh zsh-4.3.11-4.el6.centos.2.x86_64.rpm

warning:zsh-4.3.11-4.el6.centos.2.x86_64.rpm: Header V3 RSA/SHA1 Signature, key IDc105b9de: NOKEY

Preparing... ###########################################[100%]

1:zsh ########################################### [100%]

[[email protected] Packages]# cat /etc/shells

/bin/sh

/bin/bash

/sbin/nologin

/bin/dash

/bin/tcsh

/bin/csh

/bin/zsh

[[email protected] Packages]#

演示重新安装replacepkgs：

之前我们zsh已经安装过了，那我们先编辑一下zsh的配置文件“/etc/zshrc”，比方说我们删除其中的几行，然后保存，因为我们执行“wq”之后，他的配置文件信息就不能恢复了。那么这时，我们

[[email protected] media]# vim /etc/zshrc //先将zsh的配置文件中的内容删除一部分

[[email protected] media]# cat /etc/zshrc

[[email protected]]#rpm -ivh --replacepkgs /media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm

[[email protected]]# cat /etc/zshrc //发现配置文件内容没有恢复，这时因为我们的系统在我们没有将原先的配置文件删除，就在重装软件，那么系统就会认为我们这个配置文件修改是有目的的，我们也要记住replacepkgs是不能修改原来的配置文件的。所以我们在重装之前要先删除配置文件。

[[email protected]]# rm -f /etc/zshrc

[[email protected] media]# rpm -ivh --replacepkgs/media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm

[[email protected]]# cat /etc/zshrc //发现配置文件内容恢复了

# /etc/zshrc is sourced in interactiveshells. It

# should contain commands to set upaliases, functions,

# options, key bindings, etc.

## shell functions

#setenv() { export $1=$2 } # csh compatibility

# Set prompts

PROMPT=‘[%[email protected]%m]%~%# ‘ # default prompt

#RPROMPT=‘ %~‘ # prompt for right side of screen

# bindkey -v # vi key bindings