Skip to main content

RPM Building In rhel 6

key skill for a system administrator is being able to deploy your own custom
software. However, you first need to build an RPM package that contains your cus-
tom software. This can seem like a large undertaking at first, but after a few times
the process is pretty simple. To build an RPM, you must do the following:
Create a directory hierarchy.
Step 1.
Copy or create your source code into the directory hierarchy.
Step 2.
Create a spec file.
Step 3.
Build the RPM.
Step 4.
The hierarchy that you create must meet the rpmbuild specification, which is com-
posed of the following directories:
BUILD Contains scratch space used to compile software
RPMS Contains the binary RPM that is built
SOURCES Holds the source code for the RPM
SPECS Contains the spec file(s) (one per RPM)
SRPMS Contains the source RPM built during the process
REAL-WORLD TIP
Notice that the directory names are shown in uppercase. This is a standard that you
should follow when creating the directory hierarchy.
Wow! eBook
Chapter 6: Package Management 185
Aside from the directories we have covered, you also need to install a few packages.
Okay, enough with the theory; let’s get started.
Creating an RPM
Create an RPM by following these steps:
Install the required packages to build an RPM package:
Step 1.
# yum install –y rpm-build make
Verify the packages are installed correctly:
Step 2.
# rpm -qa | grep rpm-build
rpm-build-4.8.0-12.el6.x86_64
# rpm -qa | grep make
make-3.81-19.el6.x86_64
Create the directory hierarchy you need to build in the /usr/src/redhat
directory (this is a personal preference to build packages under the
/usr/src directory).
Create the required directories:
Step 3.
# mkdir –p /usr/src/redhat/{BUILD,RPMS,SOURCES,SPECS,SRPMS,tmp}
The tmp directory is used as a temporary build directory as well. When
building a package, you need some additional items. In the SOURCES
directory is a compressed file (.tar.gz) that contains the source files of
the software from which you want to create a package. Note that the
Red Hat exams require you to be able to build only a single-file RPM,
so you don’t need a full software source to make this work.
Create a directory with some sample files that you’d like in the package:
Step 4.
# mkdir /usr/src/redhat/mysample
# cd /usr/src/redhat/mysample
# touch first_file second_file keys config_file
Create an archive file based on your sample source:
Step 5.
# cd /usr/src/redhat
# tar cf mysample.tar.gz mysample
# mv mysample.tar.gz SOURCES/
One final step before package creation involves the creation of a spec
Step 6.
file. The spec file is the set of instructions used to create the actual
package itself. If you couldn’t guess, this file must be located in the
SPECS directory. Here is a sample spec file to use for this package:
Summary: This package is a sample for the Red Hat exams.
Name: mysample
Version: 1.0
Release: 0
Wow! eBook
186 Hands-on Guide to the Red Hat® Exams: RHCSA™ and RHCE® Cert Guide and Lab Manual
License: GPL
Packager: Joe Tester
Group: Development/Tools
Source: %{name}.tar.gz
BuildRoot: /usr/src/redhat/tmp/%{name}-%{version}
%description
This package is just a sample for the Red Hat exams.
%prep
%setup -n mysample
%install
mkdir -p “$RPM_BUILD_ROOT/opt/sample_pkge”
cp -R * “$RPM_BUILD_ROOT/opt/sample_pkge”
%files
/opt/sample_pkge
%clean
rm -rf “$RPM_BUILD_ROOT”
%post
chown user01:user01 -R /opt/sample_pkge
chmod 775 -R /opt/sample_pkge
This file definitely needs some explaining. The first main section is all
information required for a package, which you already saw in this chap-
ter when you queried information from a package. The Source and
BuildRoot are both significant because they play a role in how the pack-
age is built. The Source is the archive file that the package will use; in
this case it is named after the mysample.tar.gz file created and moved
into the SOURCES directory. BuildRoot is the directory that will be
used to actually build the software (you could use the BUILD directory
as well).
The rest of the spec file contains sections defined with a %. First up is
the %description section, which provides a description for the package
that you are trying to build (as I’m sure you guessed). The %prep and
%setup sections both move the SOURCE into the BUILD directory
and decompress the file archive. The –n option specifies the name of the
directory that will be entered into upon decompression. The %install
section is normally the place where your software is compiled and in-
stalled on your current system. When it is installed, the files need to be
collected so that they can be deployed via the package you are building,
which leads us to the %files section. Here, you need to include any file
that you want included in your package. Any directory that you specify
here also includes all files and subdirectories below it as well. Because
you are building a package with only a few files, you can just specify the
directory previously created (/opt/sample_pkge) in the %install section.
Wow! eBook
Chapter 6: Package Management 187
The last two sections aren’t required but are useful, so I have included
them here. The %clean section is responsible for cleaning up a mess
created when the package is created. In this case, the removal of
$RPM_BUILD_ROOT should suffice, as shown by the single line in this
section. Using %post enables you to run any additional scripts or com-
mands as the package is completing installation. In the example, you are
setting the permissions on the files you are creating. Notice, however,
that this would fail on any system that doesn’t have a user01 account.
There are ways to enforce requirements, but they are beyond the scope
of this book. Finally, you can run the rpmbuild command to create the
package.
Build the package with the rpmbuild command:
Step 7.
# rpmbuild –v –bb /usr/src/redhat/SPECS/sample.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.48604
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf mysample
+ tar -xvvf /usr/src/redhat/SOURCES/mysample.tar.gz
drwxr-xr-x root/root 0 2010-12-02 11:25:44 mysample/
-rw-r--r-- root/root 0 2010-12-02 11:25:44 mysample/con-
fig_file
-rw-r--r-- root/root 0 2010-12-02 11:25:44
mysample/first_file
-rw-r--r-- root/root 0 2010-12-02 11:25:44
mysample/second_file
-rw-r--r-- root/root 0 2010-12-02 11:25:44 mysample/keys
+ cd mysample
++ /usr/bin/id -u
+ ‘[‘ 0 = 0 ‘]’
+ /bin/chown -Rhf root .
++ /usr/bin/id -u
+ ‘[‘ 0 = 0 ‘]’
+ /bin/chgrp -Rhf root .
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.48604
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd mysample
+ mkdir -p /usr/src/redhat/tmp/mysample-1.0/opt/sample_pkge
+ cp -R config_file first_file keys second_file
/usr/src/redhat/tmp/mysample-
1.0/opt/sample_pkge
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/brp-strip-comment-note
Processing files: mysample-1.0-0
Requires(interp): /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires(post): /bin/sh
Wow! eBook
188 Hands-on Guide to the Red Hat® Exams: RHCSA™ and RHCE® Cert Guide and Lab Manual
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/usr/src/redhat/tmp/mysample-1.0
Wrote: /usr/src/redhat/RPMS/x86_64/mysample-1.0-0.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.48604
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd mysample
+ rm -rf /usr/src/redhat/tmp/mysample-1.0
+ exit 0
Looking through this output, you can see all the commands executed to
create the package. They should all be in line with what we have dis-
cussed so far. If everything went all right, you should now have your
new RPM package in the RPMS directory.
View the new RPM package:
Step 8.
# ls /usr/src/redhat/RPMS/x86_64/
mysample-1.0-0.x86_64.rpm QA-Keys-1.0-0.x86_64.rpm
Install the new package to ensure that it works properly:
Step 9.
# cd /usr/src/redhat/RPMS/x86_64
# rpm -ivh mysample-1.0-0.x86_64.rpm
Preparing... ########################################### [100%]
1:mysample ########################################### [100%]
Because there were no errors, the package should have installed correctly.
As always, verify the installation:
Step 10.
# rpm -qa | grep mysample
mysample-1.0-0
You can also check the directory and files themselves to ensure installation:
Step 11.
# ls/opt/sample_pkge/
config_file first_file keys second_file

Comments

Popular posts from this blog

Docker Container Management from Cockpit

Cockpit can manage containers via docker. This functionality is present in the Cockpit docker package. Cockpit communicates with docker via its API via the /var/run/docker.sock unix socket. The docker API is root equivalent, and on a properly configured system, only root can access the docker API. If the currently logged in user is not root then Cockpit will try to escalate the user’s privileges via Polkit or sudo before connecting to the socket. Alternatively, we can create a docker Unix group. Anyone in that docker group can then access the docker API, and gain root privileges on the system. [root@rhel8 ~] #  yum install cockpit-docker    -y  Once the package installed then "containers" section would be added in the dashboard and we can manage the containers and images from the console. We can search or pull an image from docker hub just by searching with the keyword like nginx centos.   Once the Image downloaded we can start a contai

Remote Systems Management With Cockpit

The cockpit is a Red Hat Enterprise Linux web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment. In RHEL 8 Cockpit is the default installation candidate we can just start the service and then can start the management of machines. For RHEL7 or Fedora based machines we can follow steps to install and configure the cockpit.  Following are the few features of cockpit.  Managing services Managing user accounts Managing and monitoring system services Configuring network interfaces and firewall Reviewing system logs Managing virtual machines Creating diagnostic reports Setting kernel dump configuration Configuring SELinux Updating software Managing system subscriptions Installation of cockpit package.  [root@rhel8 ~] #  dnf   install cockpit cockpit-dashboard  -y  We need to enable the socket.  [root@rhel8 ~] #  systemctl enable --now cockpit.socket If firewall is runnin

Containers Without Docker on RHEL/Fedora

Docker is perfectly doing well with the containerization. Since docker uses the Server/Client architecture to run the containers. So, even if I am a client or developer who just wants to create a docker image from Dockerfile I need to start the docker daemon which of course generates some extra overhead on the machine.  Also, a daemon that needs to run on your system, and it needs to run with root privileges which might have certain security implications. Here now the solution is available where we do not need to start the daemon to create the containers. We can create the images and push them any of the repositories and images are fully compatible to run on any of the environment.  Podman is an open-source Linux tool for working with containers. That includes containers in registries such as docker.io and quay.io. let's start with the podman to manage the containers.  Install the package  [root@rhel8 ~] # dnf install podman -y  OR [root@rhel8 ~] # yum