Shulou(Shulou.com)06/01 Report--

Linux package Management

The hierarchical structure of our linux operating system from the bottom to the top:

First of all, the bottom layer is the hardware, and the computing power of the computer is designed and implemented in the hardware logic, and the chips produced by different manufacturers, even if they are the same type of chips produced by the same manufacturer, they provide us with different computing interfaces. We have basically talked about embedded development, so if there is no system to use, it is mainly hardware-oriented and program-oriented. And this kind of program can only adapt to one or several limited chips, especially single-chip microcomputer. now, in many embedded development processes, there is already a universal layer to implement, but this kind of single-chip microcomputer is still oriented to hardware programming.

Then above the bottom layer is the operating system layer that encapsulates the hardware interface. After the system layer encapsulates the underlying hardware interface, it outputs upward through system calls (system call), but the system calls are still very low-level. In order to speed up the development operation, a half-layer called "lib call" is added above the operating system layer. Note that this is not the whole layer, but half-layer, because for programmers We can write programs for half-tier "libraries", or we can write programs for our operating system, and then on top of the library is the application, which really brings us some productivity. our kernel cannot complete any specific operations. among these many application types, we know that there is a relatively unique class, which mainly allows users to interact with the host. Any operation called shell that uses the operating system to complete a task is done through an application, so we say that when we really implement the operation and maintenance operation in the future, in addition to system management and library call management, in fact, as operation and maintenance personnel, it is to constantly install and configure an application package on our operating system, and then let the application package run and provide services. Or use this tool to complete the process of some specific corresponding operation. For our operation and maintenance staff, installing and uninstalling the management package is the most basic and fundamental task to achieve a lot of later work, so first of all we should learn to flexibly implement the installation and management operation of the package.

Any program running, it is possible to provide two formats of packages on the package, which we call source packages or binary packages, so we will have to review the previously mentioned API and ABI,API called application development interface, and ABI called application binary interface. As we said, API hierarchy compatibility is not necessarily ABI level compatibility. Because some operating systems, the format in which they execute programs, or identify the format for binary systems, is not the same, such as linux and similar unix (Unix-like) their operating systems are generally the same, their ABI is the same, but they are far from windows. For example, executable programs on windows systems are all exe or msi, while those on linux are in elf format. So they are not compatible at the ABI level, so we say that even if we use a high-level programming language to write programs, even if they are compatible with the source format, once they are compiled, they are originally in the format above linux, but they still can't run on windows. So there is a package that has been compiled on linux, which is in binary format, and we can't install it on windows. On the other hand, if a package is compiled on windows and it is a file in exe format, can it run on linux? It's hard, too. We can smooth out the difference between the two with the help of virtualization. For example, today's various applications are almost all developed for library calls, rarely directly through system calls. Even if it is achieved through system calls, that is no problem. There are many programs on windows that simulate linux libraries, and there are also many programs on linux that simulate windows libraries.

For example, now there is a linux operating system, it doesn't matter if we install a WinE, this wine can simulate the windows library on linux. So we can use wine to run windows applications. For example, the various games you want to play on the linux can even provide us with an installation path to simulate the C disk D disk E on the windows. But this is just a library virtual layer. We can also provide a linux runtime environment on windows. It is called cywin, which runs a cywin on top of windows, and it can provide a running environment to run a simulated linux. So if there are some programs that can only run on linux, we can also run on windows based on cywin, such as docker. This is not a normal solution, and the normal solution is that because abf libraries are incompatible, at least at the binary level they are not compatible. So they have no way to install the block system to implement the system call.

Library-level virtualization: we can use library-level virtualization to smooth out their differences. For example, on linux we can provide windows libraries with the help of wine so that we can run windows applications. On Windoes, we simulate the running environment of linux with the help of Cywin. As a result, those binaries can also run across systems.

System-level development:

Services and applications: httpd,vsftpd,nginx

Go

Application-level development

Java/Python/perl/ruby/php

Java:hadoop,hbase, (their operation requires that jvm is the java virtual machine)

Python:openstack (openstack is a cloud operating system)

Pvm (Python virtual machine) is required to run Python programs.

Run perl: (dependent on perl)

Run ruby: (dependent on the ruby interpreter)

Run php: (dependent on the php interpreter)

C _ blank + program format:

Source code: program code in text format

Binary format: program code in text format-> compiler-> binary format (binary program, library file, configuration file, help file)

(binary format We only mean that his preface and library are binary, and his configuration files and help files are text, of course. We know that one of the important philosophies of Linux is to save configuration information in text files. The benefit of this is that when we configure any application in the future, we only need to rely on a text editor. )

So if we want to install the application in the future, it will obviously be installed differently for the content of our two formats. We know that the source code cannot be run, so we have to compile it and install it and run it. For the source code, we have to manually complete the process of "program code in text format-> compiler-> binary format". If someone else provided us with a file in binary format, we would not need to do the above process ourselves. Because what we get is directly in runnable format. What if unfortunately only the source code is provided? Then we'll just have to compile it ourselves. If you want to be able to compile on your own, it depends on the compiled development environment. Because compilation depends on the compiler, on the header file, on the development library. Our library is also in source code format, so there are two kinds of files for the library. And then we compiled it into a binary format.

So our compiler development environment depends on: compiler, header file, development library.

If what we get is in binary format, then we don't need to compile it, we can just put it in the directory and run it.

So if we are going to perform a source code compilation installation, then we need to prepare a few additional steps. At the very least, we have to find ways to ensure that our compilation environment is complete. Providing a compilation environment is quite painstaking work.

Let's learn about package installation, first understand how the binary format is installed, and then learn how to compile and install the source code. The above is the format of the C program.

What if it's an application-level program format?

So let's take JAVA and Python as an example, then JAVA and Python applications have the same format.

Java/python program format:

source code

Binary system

By the same token, if it is in source code format, it can only be compiled, and if it is in binary format, it can be used directly.

But their compilation is different in that they compile not in binary format, or in a binary format that can be run directly on CPU, but in a program format that they can run on a virtual machine (jvm/pvm). That is, it is converted into a runnable binary format through a virtual machine. There is an extra layer in the middle, so the performance is very poor. In other words, the performance of C language is relatively poor. Generally speaking, whether it is the C format source code or the java format source code, they usually have more than one program file. Then why is there more than one?

In the future, our program files will have intricate dependencies when compiling, resulting in 100 program source files. It is very likely that we will compile the first one, the third one, and the second one. Because the first and the third are dependent on the second. The result is who compiles first and then compiles. As users, we don't have the ability to manage their compilation order. So a variety of source code usually uses a project management tool. Or project building tools.

Project build tools:

The most famous project building tool is called make.

Java: the most classic project build tool is called maven

In this way, the project build tool must also rely on the project development environment to build. For java, he also has his own development environment. He also needs a development environment. Only for these two programming languages. Their development environment usually refers to the virtual machine of the corresponding application and the compiler above the virtual machine. Java source code compilation also requires a development environment, but there is no header file, they also need: compiler, card library. This is also the format of our package.

In order to reduce the difficulty of primary users, what should we do?

We should use the package manager to assist in the management of these end users.

Package Manager:

Source code-> target binary format-> organized into one or a limited number of "package" files

Install, upgrade, uninstall, query, (even support on linux) validation

Package Manager:

What are the general types of package managers?

For windows, most applications are in exe format. The application in this format provides us with an installation interface, and we just need to click next, and when we uninstall, we can uninstall the application in our control panel. why can we only see the next step to complete the installation? He is actually packaged into a single exe file through a package manager, we know that after we install it, it is indeed scattered into multiple may be placed under a path under the program/files directory, each application has a directory in which all kinds of files are stored, there are binary libraries, for windows, their library is dll files, dynamic link libraries, dynamic link, and for linux, it is called so. )

At present, linux has three main branches:

Debian:dpt,dpkg, ".dep"

Redhat:redhat package manager, abbreviated as: rpm, ".rpm"; rpm ispackage manager

S.u.S.E:rpm, ".rpm"

Gentoo:ports

ArchLinux:

Source code:

Naming method: name-VERSION.tar.gz

VERSION:major.minor.release / / Major version number. The second edition number. Release version

Rpm package naming format:

Name-VERSION-release.arch.rpm / / release is the release of the rpm package.

VERSION:major.minor.release

Release.arc: refers to the release number of the rpm package

Release.os:2.el7.i386.rpm

Archetecture: architecture, i386, x64 (amd64), ppc,noarch

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

Changelog:

Unpacking: main package and subpackage

Main package: name-VERSION-release.arch.rpm

Subcontractor: name-function-VERSION-release.arch.rpm

Function:devel,utils,libs.

Dependencies:

X,y,z

X-dependence-> YBI Z

Y-dependence-> A _

C-> y

Front-end tools: automatically resolve dependencies

Front-end tools for rpm package manager on yum:rhel series systems

Apt-get (apt-cache): a front-end tool for dep package manager

Zypper:suse 's rpm Manager front-end tool

Front-end tools for rpm package Manager on dnf:Fedora 22 + system

Package Manager:

Function: package each component file of the compiled application into one or more package files, so that it is more convenient to implement package installation, upgrade, uninstall, query and other management operations.

1. Component manifest of packages (each package is implemented separately)

List of documents

Scripts that run when installing or uninstalling

2 Database (public)

Name and version of the package

Dependency relationship

Function description

Install the file path and check code information of each file generated

Rpm database for CentOS series systems: path

/ var/lib/rpm

[root@centos7 ~] # ls / var/lib/rpm

Basenames _ _ db.002 Group Obsoletename Requirename Triggername

Conflictname _ _ db.003 Installtid Packages Sha1header

_ _ db.001 Dirnames Name Providename Sigmd5

[root@centos7 ~] #

Explanation:

Group: package group. We can divide the program into a group. In the future, we can install all of the package group and uninstall the package group.

Name: the name of each program

Check code of Sigmd5:MD5

Triggername: trigger name

The way to get the package:

(1) CD-ROM of the system distribution or official file server (or mirror site):

Http://mirrors.aliyun.com

Http://mirrors.sohu.com

Http://mirrors.163.com

(2) the official site of the project

Example: take thhp as an example: site httpd.apache.org

Or:

Website www.zabbix.com

Open the website www.zabbix.com website, click "Download" directly in the navigation bar of our website, and open a page. The front "Zabbix Packages" is zabbix's rpm package, and then "Zabbix Sources" is the source package.

So the official sites of many projects also provide rpm packages, and we must be careful that if we can then install with rpm packages, we must not use source packages to compile and install.

(3) third-party organization: EPEL

EPEL: red Hat official community organizations maintain, other than the distribution of CDs they find more useful, more important, more famous packages, will be made into rpm packages in EPEL.

In fact, many official sites in China have such epel.

For example, let's take "mirrors.aliyun.com" as an example:

"mirrors.aliyun.com" also has epel on the mirrored Aliyun site, and there are many additional supplements for our centos in epel.

(a) EPEL

(B) search engines

Http://pkgs.org (this is a very important one in the field of rpm)

Rpmfind.net (if you want to search which portfolio, search directly. )

Rpm.pbone.net

In the above dialog box, we can enter the correct content to query, and we can also use the following

Advanced RPM Search

To make an advanced query.

(4) make the rpm package manually.

Note: no matter which way to get the rpm package above, as long as it is obtained through the Internet, then we can assume that even if the original author has not made any changes or modifications in it, because we now often use some download tools, such as Xunlei, then there is something wrong with this tool, why the download speed of this tool is very block, because they may not be downloaded from the official original site. Or it was downloaded from an incomplete official site, in fact, from a user who has already downloaded it, if it cannot be downloaded from the official site, and at this time he just searched for this file from a certain user, and he will also send it to you, but this file may have been carefully modified by other users to make a back door, so we will download files with high personality security on the Internet in the future. Such as the bank official site plug-ins, as well as Alipay certificates, we should not be using Xunlei download. Less use of these tools in the future, especially those downloaded with PHP, is quite dangerous, so we download a tool we do not know whether it is officially provided or not?

At least all the data has not been tampered with, so what should we do?

We recommend that we do a MD5 check and provide a MD5 verifier to verify its legitimacy and source legitimacy.

The integrity of the package needs to be verified

The rpm command management package on CentOS systems:

Installation, upgrade, uninstall, query and verification, database maintenance

The "install, upgrade, uninstall, query and verify" mentioned above are all implemented with the rpm command.

Format: rpm [OPTIONS] [PACKAGE_FILE]

Option used for installation:-i=--install

Options used for upgrade:-U=--update,-F=--freshen

Uninstall:-e=--erase

Query:-q=--query

Check:-V=--verify

Database maintenance:-- builddb,--initdb

Installation:

You must have a corresponding file when you install it.

Rpm {- I |-- install} [install-options] PACKAGE_FILE...

You should use the option-ivh when actually installing

Rpm-ivh PACKAGE_FILE.

GENERAL OPTIONS (generic option)

-vRose verbose; (output trust information)

-vv: (output more detailed process information)

[install-options]

-h:hash marks output progress bar; each # represents 2% progress

-- test: if we don't want to actually install, we can test the installation, check and report dependencies, conflict messages, etc., just to see if there is any potential for conflict.

-- nodeps: ignore dependencies; not recommended

-- replacepkgs: reinstall (if a package was installed, but then we changed its configuration file and made a mistake, we deliberately uninstalled it and then reinstalled it, but we have a better way to reinstall it directly. )

-- noscripts:

-- oldpackage: for downgrade

-- justdb: just upgrading the database.

Note that the rpm package can come with scripts:

There are four types of scripts:

If none of these four categories want to be executed:-- noscripts

Preinstall: run the script before the installation process starts,% pre-- nopre

Postinstall: script run after the installation process is complete,% post-- nopost

Preuninstall: the uninstall process actually starts executing the script that was run before,% preun-- nopreun

Postuninstall: script run after the uninstall process is complete,% postun-- nopostun

-- nosignature: do not check the signature information or the validity of the source

-- nodigest: do not check package integrity information

Give an example to demonstrate:

[root@centos6 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%]

[root@centos6 Packages] # cat / etc/shells

/ bin/sh

/ bin/bash

/ sbin/nologin

/ bin/dash

/ bin/tcsh

/ bin/csh

/ bin/zsh

[root@centos6 Packages] #

Demonstrate reinstalling replacepkgs:

We have installed zsh before, so let's edit zsh's configuration file "/ etc/zshrc" first, for example, we delete a few lines, and then save it, because after we execute "wq", his configuration file information cannot be restored. Well, at this time, we

[root@centos6 media] # vim / etc/zshrc / / delete part of the configuration file of zsh first

[root@centos6 media] # cat / etc/zshrc

[root@centos6media] # rpm-ivh-- replacepkgs / media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm

[root@centos6media] # cat / etc/zshrc / / found that the content of the configuration file has not been restored. At this time, because our system is reinstalling the software without deleting the original configuration file, then the system will think that the modification of our configuration file is purposeful, and we should also remember that replacepkgs cannot modify the original configuration file. So we need to delete the configuration file before reinstalling it.

[root@centos6media] # rm-f / etc/zshrc

[root@centos6 media] # rpm-ivh-- replacepkgs/media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm

[root@centos6media] # cat / etc/zshrc / / Discovery configuration file contents have been restored

#

# / etc/zshrc is sourced in interactiveshells. It

# should contain commands to set upaliases, functions

# options, key bindings, etc.

#

# # shell functions

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

# Set prompts

PROMPT=' [% nasty% m]% ~% #'# default prompt

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

# bindkey-v # vi key bindings

# bindkey-e # emacs key bindings

Bindkey''magic-space # also do history expansion on space

_ src_etc_profile_d ()

{

# Make the * .sh things happier,and have possible ~ / .zshenv options like

# NOMATCH ignored.

Emulate-L ksh

# from bashrc, with zsh fixes

If [[!-o login]]; then # We're not a login shell

For i in / etc/profile.d/*.sh; do

If [- r "$I"]; then

. $I

Fi

Done

Unset i

Fi

}

_ src_etc_profile_d

Unset-f _ src_etc_profile_d

[root@centos6 media] #

Do not check signature demo:

[root@centos6 media] # rpm-ivh-- replacepkgs/media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm

Warning: / media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm: Header V3RSA/SHA1 Signature, key ID c105b9de: NOKEY

Preparing... # [100%]

1:zsh # 100%

When reinstalling the package above, there was a warning, we need to check the validity and integrity of the file, to check the two options of the file, to rely on a secret key file, to rely on the public key of the maker of the package.

[root@centos6 media] # rpm-ivh--replacepkgs-- nosignature/media/Packages/zsh-4.3.11-4.el6.centos.2.x86_64.rpm

Preparing... # [100%]

1:zsh # # [100%]

[root@centos6 media] #

When installed above, the warning disappears.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.