A system can also be registered via the command line by using the 'subscription-manager' command. To register your system either trough the GUI or form the command line follow the instructions in the Using and Configuring Red Hat Subscription Manager guide. YUM (Yellowdog Updater Modified) is an open source, widely used command-line and graphical based package management tool for RPM (RedHat Package Manager) based Linux systems, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL). It is used to install, update, remove or search. Run the command: /opt/rstudio-pm/bin/run-diagnostics. If you unpacked the software in a non-default location, then navigate to the directory and run: `./bin/run-diagnostics`. If the cause of the problem is not evident to you, then send RStudio an email to support@rstudio.com including. Both Customer Portal Subscription Management and Subscription Asset Manager use Red Hat's hosted content delivery services, with the URL Since Satellite 6 hosts its own content, the URL must be used for systems registered with Satellite 6. Zypper is able to manipulate installation repositories, search for packages, install, remove, or update packages and more. It can be used as a standalone application or inside scripts. Comment 1 Lorenzo Villani 2008-05-22 12:45:40 UTC.
This article shows you how to package a script into an RPM file for easy installation, updating, and removal from your Linux systems. Before I jump into the details, I'll explain what an RPM package is, and how you can install, query, remove, and, most importantly, create one yourself.
This article covers:
- What an RPM package is.
- How to create an RPM package.
- How to install, query, and remove an RPM package.
Linux Redhat Commands Pdf
More about automation
What is an RPM package?
RPM stands for Red Hat Package Manager. It was developed by Red Hat and is primarily used on Red Hat-based Linux operating systems (Fedora, CentOS, RHEL, etc.).
An RPM package uses the .rpm extension and is a bundle (a collection) of different files. It can contain the following:
- Binary files, also known as executables (
nmap,stat,xattr,ssh,sshd, etc.). - Configuration files (
sshd.conf,updatedb.conf,logrotate.conf, etc.). - Documentation files (
README,TODO,AUTHOR, etc.).
The name of every RPM package is comprised as follows:
An example:
[ You might also enjoy: Linux package management with YUM and RPM ]
How to create an RPM package
You'll need the following components to build an RPM package:
- A workstation or a virtual machine (I am using Fedora 32 on a virtual machine).
- Software to build the package.
- Source code to package.
- SPEC file to build the RPM.
Installing the required software
The following packages need to be installed to build the RPM package:
After installing rpmdevtools, we can run the following as a user called sai.local:
Note: Do not build RPM packages as the root user. This is highly discouraged.
The above command creates the following directory structure:
- The BUILD directory is used during the build process of the RPM package. This is where the temporary files are stored, moved around, etc.
- The RPMS directory holds RPM packages built for different architectures and noarch if specified in
.specfile or during the build. - The SOURCES directory, as the name implies, holds sources. This can be a simple script, a complex C project that needs to be compiled, a pre-compiled program, etc. Usually, the sources are compressed as
.tar.gzor.tgzfiles. - The SPEC directory contains the
.specfiles. The.specfile defines how a package is built. More on that later. - The SRPMS directory holds the
.src.rpmpackages. A Source RPM package doesn’t belong to an architecture or distribution. The actual.rpmpackage build is based on the.src.rpmpackage.
A .src.rpm package is very flexible since it can be built and re-built on every other RPM-based distribution and architecture.
Since you're now familiar with what each directory holds, here's how to create a simple but functional bash script that I'll show you how to package.
Create the bash script
You are probably familiar with the following error:
So the purpose of this bash script is to remove the offending key from ~/.known_hosts without having to manually edit the file and remove 42.
Note that ssh-keygen -R didn’t work in my case, so I created a script called rm-ssh-offendingkey to automate this process. Here it is:
Place the script in the designated directory
To build the script, you need to put it in the directory the RPM build process is expecting it to be in. Create the directory structure:
Put the rm-ssh-offendingkey script in the sshscript-1/rm-ssh-offendingkey directory.
Subsequently, I .tar.gz the source as follows:
Create the .spec file
To be able to package the script, you need to create a .spec file. To make a default .spec file for the package, I am going to use the following syntax:
Now let’s run tree ~/rpmbuild to see what the directory structure looks like:
The generated rm-ssh-offendingkey.spec file needs some modifications. The generated .spec file assumes that I am going to compile and build software. Since I'm packaging a simple bash script, I'll remove some unnecessary lines from the .spec file and add others. For example, I added Requires: bash so that the package requires bash to be installed as well. I also added BuildArch: noarch which means that the package should work on a 32-bit and a 64-bit CPU architecture.
It's important to specify which files are going to be installed under the %files section. Here I’ve explicitly put the following line:
This is sufficient since I only want this script to go to /usr/bin. Oh, by the way, %{_bindir} is called a macro and translates to /usr/bin. You can verify this by running:
Other useful macros to be aware of are:
Checking the .spec file on error (rpmlint)
At the beginning of the article, I installed the rpmlint package along with rpmdev-tools, which helps me to check the .spec file for errors.
Everthing looks good.
Building the package (rpmbuild)
To build the RPM package you can use the rpmbuild command. Earlier in this tutorial, I mentioned the difference between the .src.rpm (Source RPM package) and the .rpm package.
To create the .src rpm package, use:
The flags -bs have the following meanings:
- -b | build
- -s | source
To create the binary .rpm package, use:
The flags -bb have the following meanings:
- -b | build
- -b | binary
Redhat Commands List Pdf
If all goes well, you now have the following directory structure:
The following lines are indicating that the RPM package has successfully been built.
Installing the RPM package
After a successful build of the package, you now can install the RPM package as follows:
Verifying the package has been installed
To verify the package has correctly been installed, run the following command:
Querying some more info about the package, in the spec file, I did add a %changelog entry. This %changelog entry can be viewed as follows:
See what’s in the RPM package
It is very easy and quite convenient to see which files an RPM package contains. This information is retrieved as follows:
Removing the RPM package
Removing the package from the system is just as easy as installing it.
- - v | verbose
- - e | erase
Final thoughts
In this document, I covered the very basics of an RPM package, including how to build, install, and remove it from your system. The .spec file can get very complicated as you build more advanced software. If you plan to continue your journey on building RPM packages, don’t forget to check out mock and the mock GitHub page.
[ Free online course: Red Hat Enterprise Linux technical overview. ]