Linux source Pack make the RPM package Apache

First, look at the use and configuration of Yum

Recently, as a result of the server needs, the intranet needs to build intranet Yum source.

To build intranet Yum source needs to be divided into the following steps, as follows:

1. What is Yum

2, repo file is what

3, Repo document content detailed

4, Yum server-side configuration

5, Yum Client configuration

6, Save the Yum installed package

7, update the RPM package

First, what is Yum?

Yum (full name Yellowdog Updater Modified) is a shell front-end package manager used in CentOS, Redhat, and Fedora operating systems.

Yum mainly manages RPM-based packages, it can automatically upgrade, install, delete rpm packages, and it can automatically find and solve the relationship between the RPM package, and without administrators, manually to install each RPM package, so that administrators in the maintenance of Linux host more relaxed and comfortable.

Yum can obtain the necessary information from the Repo warehouse through an HTTP or FTP protocol from one or more repo files, and then download the relevant packages. In this way, local users can easily upgrade and maintain their systems when they have an Internet connection by setting up different repo warehouses.

The repo warehouse can be created by Createrepo or Yum-arch commands, and can be used as a Yum source by someone else's already created repo warehouse, where we explore the Createrepo warehouse created by the repo command.

For help on the use of the Yum command, we can view it through the man Yum Command, as follows:

Mans Yum

Ii. What is the repo document?

Through the first chapter, we know that the repo file is a configuration file for the Yum source (software warehouse) in the CentOS, Redhat, and Fedora operating systems, and that a repo file typically defines one or more software sources.

For example, where we will download the packages that need to be installed or upgraded, the repo files are configured in a related configuration that will be Yum read and applied.

Three, repo document content detailed

The contents of a standard CentOS repo file are as follows:

[Base]

name=centos-$releasever-base

mirrorlist=http://mirrorlist.centos.org/?release= $releasever &arch= $basearch &repo=os

#baseurl =http://mirror.centos.org/centos/$releasever/os/$basearch/

Enabled=1

Gpgcheck=1

Gpgkey=file:///etc/pki/rpm-gpg/rpm-gpg-key-centos-6

Each option is described as follows:

[Base]

This option defines the name of a software source that can be customized and unique across all repo files on that server. Note: There should be no spaces inside the brackets.

name=centos-$releasever-base

This option defines the name of the software warehouse, $releasever variable defines a release, usually a 5,6,7 number.

mirrorlist=http://mirrorlist.centos.org/?release= $releasever &arch= $basearch &repo=os

This is the address list for the specified mirror server, which is usually turned on. We can try to replace $releasever and $basearch with our own versions and schemas, such as 6.6 and x86_64, open in the browser, and we can see a list of mirrored server addresses available for a long series of mirrors. As follows:

By choosing a mirrored server address that you can access faster, copy and paste it into the baseurl option in the repo file, we get a faster update speed.

#baseurl =http://mirror.centos.org/centos/$releasever/os/$basearch/

The first character in this line is # indicates that the row has been commented and will not be read, which means specifying a baseurl (the source's mirror server address).

BaseURL usually have the following four formats, as follows:

Baseurl= http://mirrors.aliyun.com/centos/6.6/os/x86_64/

Using the HTTP protocol mirroring server address

Baseurl= ftp://ftp.sjtu.edu.cn/centos/6.6/os/x86_64/

Using the FTP protocol to mirror server addresses

Baseurl= rsync://mirror.zol.co.zw/centos/

Use rsync mirror server address

Baseurl= file:///ilanni/yum/

Using the mirror server address of this computer

The first two of these are the most we use. About this we can refer to the CentOS official website to give the reference, as follows:

Enabled=1

This option indicates that the software source is enabled in this repo file, and the default option is to not write. However, if the enabled value is 0, the software source is disabled.

Note: You can define multiple software sources in a repo file.

Gpgcheck=1

This option indicates a GPG checksum for the RPM package downloaded through the software source, if the Gpgcheck value of 0 indicates no GPG checksum.

gpgkey= file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

This option defines the GPG key file for validation.

Through the above repo document's explanation, I believe you will feel, actually centos repo document is really very simple. With a preliminary understanding, we can carry out the following experiment.

We now ask to build a Yum source in the company intranet. The Yum source needs to be configured with two sources: one is a centos optical mirror source, one is a mirror source for special RPM software, and the Yum Source is accessed through HTTP.

This experiment: Yum server 192.168.1.247 centos, client 192.168.1.248 CentOS.

Iv. Yum Server-side configuration

To meet these requirements, we first build the Yum server and configure the Web server on that server.

We use Apache on this Web server, and of course it is possible to use Nginx.

4.1 Configuring the Web server

On the Yum server, we now install Apache directly using Yum. As follows:

Yum-y Install httpd

Of course, you can also use the source method to install Apache, about Apache source code installation can refer to the "mud: the source of Apache installation."

After the Apache installation is complete, we will start Apache. As follows:

/ETC/INIT.D/HTTPD start

wget http://192.168.1.247

With the above diagram, we can clearly see that the Apache server has started normally.

4.2 Installation Createrepo

What is Createrepo? Createrepo is a software package that creates warehouses under Linux. Create is the meaning of creation, repo is the abbreviation of repository, is the meaning of the warehouse.

You can create a software warehouse on a yum server only if you install the Createrepo software.

Createrepo installation is very simple, we now install through the Yum, as follows:

Yum-y Install Createrepo

Once the Createrepo is installed, we can create the Repo warehouse.

4.3 Disc mirroring

Copy the locally downloaded CD image to the Yum server, where we copied it through the Xftp tool, as follows:

Create the location where the software source is located, as follows:

Mkdir-p/var/www/html/yum

ll/var/www/html/yum/

Create a disc-mounted directory, as follows:

Mkdir/iso

Mount-o Loop centos-6.6-x86_64-minimal.iso/iso/

ll/iso/

Copy all the files under the CD to the/var/www/html/yum/directory, as follows:

cp-rv/iso/*/var/www/html/yum/

Now we are going to visit the directory to see if it will work as shown below:

wget Http://192.168.1.247/yum

We can see clearly from the above figure that the directory can be accessed normally.

Note: We did not create the Yum database and information index file here because the CD already has Yum database and information index file, we do not need to go through the Createrepo command. In fact, Yum's database and information index files are all under the Repodata folder. As follows:

For the effect of the optical disc mirroring experiment, we take the Curl software in the CD-ROM image package as an example. As follows:

ll |grep Curl

4.4 Special software Mirroring

In the front we also require a special Yum source to store special software, here we take lrzsz this software as an example.

The yum source is stored in the location/var/www/html/ilanni/directory, and then the Lrzsz the software's RPM package is placed under the/var/www/html/ilanni/directory, as follows:

Mkdir-p/var/www/html/ilanni

cp/var/cache/yum/x86_64/6/base/packages/lrzsz-0.12.20-27.1.el6.x86_64.rpm/var/www/html/ilanni/

ll/var/www/html/ilanni/

Now let's create the Yum database and information index file for the special Yum Source, switch to the/var/www/html/ilanni/directory and execute the CREATEREPO command as follows:

Createrepo./

Tree repodata/

Now we are going to visit the directory to see if it will work as shown below:

wget Http://192.168.1.247/ilanni

We can see clearly from the above figure that the directory can be accessed normally.

All of the above configuration is done on the Yum server, and now we are going to switch to the Yum client to do the operation.

V. Yum Client Configuration

Yum Client's operation is much simpler, we only need to modify the client's repo file.

Enter the/etc/yum.repos.d/directory and back up the original repo files as follows:

Rename. Repo. Repo.bak *.repo

Then in the directory, create a new repo file Ilanni.repo, which reads as follows:

[CENTOS6]

Name=centos6

baseurl=http://192.168.1.247/yum/

Enabled=1

Gpgcheck=0

[Ilanni]

Name=ilanni

baseurl=http://192.168.1.247/ilanni/

Enabled=1

Gpgcheck=0

Note: The file name can be changed, but the suffix must be. Repo.

After the repo file has been modified, we will conduct the relevant test.

Install the Curl software as follows:

Yum-y Install Curl

Install the Lrzsz software as follows:

Yum-y Install Lrzsz

With the above test, we can clearly see that the client has downloaded the packages we need from the Yum server.

Note: If the client yum install the package, the prompt cannot find the software. It is strongly recommended that the Yum clean all and yum list commands be executed on the client.

Where Yum clean all means to clear the Yum source cache, yum list indicates that all packages are listed.

Above is the step that we build Yum source in intranet.

Six, save the Yum installed package

When we use Yum to install the software, the package will be removed automatically after installation.

In order to save the Yum installed package, we need to modify the Yum configuration file yum.conf, modify the Keepcache to 1. As follows:

Vi/etc/yum.conf

Cachedir represents the cache location of the RPM package.

VII. Update RPM Package

After we have built the intranet Yum source, will often encounter these two kinds of situations. One is the software version of the update, and the second is the new software.

Regardless of the above situation, we need to first delete the original Yum server Yum database and information index files, and then through the Createrepo command to recreate Yum database and information index files.

Here we take the new software as an example, the software is lftp.

As follows:

cp/var/cache/yum/x86_64/6/base/packages/lftp-4.0.9-1.el6_5.1.x86_64.rpm/var/www/html/ilanni/

ll/var/www/html/ilanni/

rm-fr/var/www/html/ilanni/repodata/

createrepo/var/www/html/ilanni/

Now we're going to switch to the client and do the following:

Yum Clean All

Yum List |grep lftp

Yum-y Install Lftp

With the above diagram, it is obvious that the client has installed the LFTP software.

Linux source Pack making Apache RPM package

I. Installation of Rpm-build

Check the relevant information to know that the source package to make the RPM package needs to use the RPM packaging tool rpm-build.

Rpm-build through the Rpmbuild command according to the local source code package, through the spec file rules can be produced into the source code package RPM package.

Now let's install the Rpm-build package as follows:

Yum-y Install Rpm-build

After the Rpm-build is installed, we will check the Rpm-build RPM package information. As follows:

cd/var/cache/yum/x86_64/6/updates/packages/

Note: The Yum installation software is removed by default after installation, but we can modify the yum.conf file so that it is not deleted.

Cat/etc/yum.conf

View Rpm-build's RPM package information, such as software name, version, build date, feature description, size, and so on. As follows:

Rpm-qpi rpm-build-4.8.0-38.el6_6.x86_64.rpm

View the Rpm-build RPM contains the installed directories and files as follows:

RPM-QPL rpm-build-4.8.0-38.el6_6.x86_64.rpm

View the profile of the Rpm-build RPM package, which is not displayed if the RPM package does not have a configuration file.

RPM-QPC rpm-build-4.8.0-38.el6_6.x86_64.rpm

View the Rpm-build RPM package dependencies as follows:

RPM-QPR rpm-build-4.8.0-38.el6_6.x86_64.rpm

In addition, if you want to see which RPM package this file belongs to, we can also use the following command. As follows:

Rpm-qf/etc/init.d/iptables

We can also view the RPM commands in detail using the man rpm. As follows:

Mans rpm

Second, the spec rules file content detailed

The spec file is the core of the entire RPM package, and it acts like a makefile file when the source code compiles the program.

The spec file contains the information necessary to create an RPM package, including which files are part of the package and which directory they are installed in, and so on.

Note: Spec files must be created by ordinary users and are strongly recommended for use with VI or VIM commands.

Let's start by creating a Httpd.spec file, using the VI command, as follows:

VI Httpd.spec

WhoAmI

Pwd

With the above figure, we can clearly see that the current Httpd.spec file has the option of the spec file. All we need to do is to fill out the spec file according to these options and save it after filling it out.

Note: When you create a new spec file, the system defaults to creating a spec file template. Only the template is empty, if you do not fill in the content, it is not possible to save the file.

Below we begin to explain spec file related options, spec file content is generally divided into the following parts:

Define the RPM package information, define the source code package, define the RPM package dependencies, work before packing, compile and install the RPM package, the files generated after installation, the scripts to be executed before and after the installation, and the software change log

2.1 To define the RPM package information

RPM package information, which mainly defines what is displayed when users query the RPM package information. It contains the function description of the RPM package, software version, copyright information and software authorization type, and so on.

Detailed information is as follows:

Name defines the RPM package and must be filled in.

Version defines the edition number of the RPM package, and it is recommended that the name of the source package be aligned.

Release defines the version number of the RPM itself, using the default value.

Summary defines some of the details about the RPM package.

%description defines some descriptive information about the RPM package.

Group identifies the type of package to which it belongs.

License software licensing types, such as the GPL, commercial, shareware.

The URL defines the home page of the software author.

The most important of the RPM package information is NVR, which is name, version, release. Because the last generated RPM package name is based on these three.

RPM name form, as follows: name-version-release.rpm.

2.2 Definition Source Package

Source0 is used to define the source package needed to make the RPM package. If you have multiple source packages when making an RPM package, use source and number blending, such as:

Source0:tbsys-src.tar.gz

Source1:tbnet-src.tar.gz

Source2:tair-2.1.0-src.tar.gz

Attention:

Source0 must be filled in, and the name must be filled with the name of the download source package exactly the same, but also note that only the tar.gz source package, in order to make RPM package.

2.3 Defining the RPM package dependencies

The RPM package relies on the base library during the manufacturing process, and the RPM package sometimes requires additional packages when it is installed. All of these can be controlled by the following options.

Buildrequires defines the basic libraries that are relied upon when making RPM packages. This option is optional.

Requires defines the packages that are relied upon to install the RPM package. This option is optional.

Attention:

It is important to point out here that the requires defines the software packages that are dependent on the Yum installation.

When we use Yum to install software A, Yum will check the RPM package after downloading A's RPM package (the RPM package will give the base library and software on which to install the RPM package).

If you check that the installation of a is dependent on software B, then Yum will automatically download and install B. b After the installation is complete, a will continue to be installed. If it is the intranet Yum source, we just need to put B in the intranet Yum source can.

If you check that A's installation does not require additional software support, then Yum will automatically install a.

2.4 Compile and install the RPM package

This step is very important, similar to the one installed with the source code./configure, make, make install. Mainly includes%build,%install and other options. As follows:

%build defines the actions when compiling a package

%install defines the installation package, using the default value.

BuildRoot defines the virtual directory to use when installing or compiling, it is recommended that you use the default value. As follows:

% (MKTEMP-UD%{_TMPPATH}/%{NAME}-%{VERSION}-%{RELEASE}-XXXXXX)

This parameter is important because, during the process of generating the RPM package, the software is installed on the path described above when the make install is executed. When you package, you also rely on the virtual directory to operate on the root directory.

2.5 Files generated after installation

When the RPM package is installed, the relevant directories and files are created, and we can define them here.

%files defines the relevant directories and files that are created when the RPM package is installed.

%defattr (-,root,root) must be noted in this option. It is the property of the specified installation file, which is (Mode,owner,group), the default value, 0644 for the text file, and 0755 for the executable file.

2.6 Scripts to be executed before and after the installation

%PREP specifies the script to be executed before the RPM package is installed. We do other things before the software is packaged. Like extracting tar.gz files. %prep is mainly used in conjunction with the%setup q command, it is recommended that you use the default value.

%POST specifies the script to be executed after the RPM package is installed. After we install the RPM package, perform the software initialization action, we can through%post to achieve the goal. For example: Apache after installation, will apachectl copy into httpd and other operations. This option is not present in the default spec template file.

%PREUN specifies the script to execute before the RPM package is unloaded, which is primarily used when software upgrades are performed. This option is not present in the default spec template file.

%postun specifies the script to execute after the RPM package is unloaded. This option is not present in the default spec template file.

2.7 Software change Log

%changelog is primarily used for software change logs. This option is optional.

If you use the%changelog option, be sure to start with a *-end. The time format is as follows:

* Day of the week, XXX

--

Examples are:

* Tue Mar 2015 ilanni2.2.27

--

Note: The week and month must use English, and is abbreviated, otherwise will be an error. As follows:

Three, Httpd.spec file example

The following is the system provided by the spec file as a template, the Apache source code package made into RPM package. The Apache spec file is as follows:

Name:httpd

version:2.2.27

Release:1%{?dist}

Summary:compiled from 2.2.27 by Ilanni

Group:system environment/daemons

License:gpl

Url:http://www.ilanni.com

Source0:httpd-2.2.27.tar.gz

BuildRoot:% (Mktemp-ud%{_tmppath}/%{name}-%{version}-%{release}-xxxxxx)

BUILDREQUIRES:GCC, gcc-c++, Openssl-devel

%description

Apache Web server. Compiled from 2.2.27 by Ilanni

%prep

%setup-q

%build

./configure--prefix=/usr/local/httpd--enable-so--enable-rewrite--enable-cgi--enable-ssl- Enable-suexec--with-suexec-caller=daemon--with-suexec-docroot=/usr/local/httpd/htdocs

Make%{?_smp_mflags}

%install

RM-RF%{buildroot}

Make install Destdir=%{buildroot}

%clean

RM-RF%{buildroot}

%files

%defattr (-,root,root,-)

/usr/local/httpd/bin/*

/usr/local/httpd/build/*

/usr/local/httpd/cgi-bin/*

%config/usr/local/httpd/conf/*

/usr/local/httpd/error/*

/usr/local/httpd/htdocs/*

/usr/local/httpd/icons/*

/usr/local/httpd/include/*

/usr/local/httpd/lib/*

%dir/usr/local/httpd/logs

%doc/usr/local/httpd/man/*

%doc/usr/local/httpd/manual/*

/usr/local/httpd/modules/*

%post

Cp/usr/local/httpd/bin/apachectl/etc/init.d/httpd

Sed-i ' 1a # chkconfig:2345 '/etc/init.d/httpd

Sed-i ' 2a # description:apache Web server '/etc/init.d/httpd

Chkconfig--add httpd

%preun

/ETC/INIT.D/HTTPD stop

Chkconfig--del httpd

%changelog

* Tue Mar 3 2015 Ilanni 2.2.27

--

Iv. Generate related Catalogs

To generate the relevant directory for the RPM package, we can create it either by hand or through the Rpmbuild command. As follows:

Rpmbuild Httpd.spec

Note: When using Rpmbuild to generate the relevant directory of the RPM package, the error is not needed to control it.

Tree rpmbuild/

With the above diagram, we can clearly see that the Rpmbulid command has generated the relevant directory.

The role of each directory is as follows:

Build is used to store the extracted files.

BuildRoot a virtual directory to use when installing or compiling.

RPMs is used to store binary packages made by Rpmbuild.

Sources is used to store source code, patches, icons and other files.

Specs is used to store spec files for managing the RPM production process.

Srpms is used to store source code packages made by Rpmbuild.

V. Copy files to the specified directory

When the related directory is created, we now need to copy the Apache source file and spec file to the specified directory. As follows:

CP httpd-2.2.27.tar.gz rpmbuild/sources/

CP Httpd.spec rpmbuild/specs/

Six, generate RPM package

Once the above configuration is complete, we will now start to generate the RPM package, using the Rpmbuild command. As follows:

Rpmbuild-ba Rpmbuild/specs/httpd.spec

With the above figure, we can clearly see that the RPM package has been successfully produced.

The newly generated RPM package is stored in the rpmbuild/rpms/directory, while the source RPM package is stored in the rpmbuild/srpms/directory.

Note: The Rpmbuild BA command means that the *.RPM package and src.rpm package are compiled and made.

Vii. test generation of RPM package

After the RPM package is finished, we will test the RPM package. As follows:

cp/home/ilanni/rpmbuild/rpms/x86_64/httpd-2.2.27-1.el6.x86_64.rpm./

RPM-IVH httpd-2.2.27-1.el6.x86_64.rpm

Through the above figure, we can clearly see that the source produced by the RPM has been properly installed.