Install GPG 1.4.10 on CentOS 7.6.







- Goal
- Contents
- Brief Summary
- Summary
- Downloadable Assets
- Notes
- Installation Recipe for GPG 1.4.10
- Project Log







I have successfully installed GPG 1.4.10 on CentOS 7.6. There were some permission management problems during this project. I have written a new recipe that takes account of permissions management. It can be found in the Installation Recipe For GPG 1.4.10 section.







I have successfully installed GPG 1.4.10 on CentOS 7.6 on my computer New computer: Shovel.

I followed the recipe in the Installation Recipe For GPG 1.4.10 section of the article
Compiling GPG 1.4.10 from source
which has the associated asset:
gnupg-1.4.10.tar.gz

GCC and Make were already installed on the CentOS 7.6 system.

The original recipe was developed for use with the user. During this project, I worked as the user . I have written a new version of the recipe that shows how to manage permissions for a non- user. This new version can be found in the Installation Recipe For GPG 1.4.10 section of this article. It essentially summarises the work done during this project.

GPG 2.0.22 was already installed, and the command was linked to it. After installation of GPG 1.4.10, the command now called GPG 1. The command still called GPG 2.







Asset: A zipped tape archive of the GPG 1.4.10 source code. It is an asset of the article Compiling GPG 1.4.10 from source.
gnupg-1.4.10.tar.gz







System details:
- Name: Shovel
- Specifications: HP 6005 Pro SFF. 3 GHz x86_64 processor (AMD II x4 B95 Quad Core), 4 GB RAM, 1 TB hard drive. Running CentOS 7.6.1810 (Core).
- More information: New computer: Shovel
- Installed items: GCC 4.8.5, Make 3.82.


Terms and acronyms:
- GPG or GnuPG = GNU Privacy Guard
- GNU = GNU's not Unix


Some searching and reading indicates that:
- GPG 1 and GPG 2 can exist on the same system.
- Their data formats are compatible.
- They handle key storage somewhat differently. A key can be stored in only one of the two. To synchronise, you may have to export a key from one and import it into the other.













Parts


- Description
- Assets
- Notes
- Recipe




Description


This recipe describes a method for compiling and installing GPG 1.4.10.




Assets


Asset: A zipped tape archive of the GPG 1.4.10 source code. It is an asset of the article Compiling GPG 1.4.10 from source.
gnupg-1.4.10.tar.gz




Notes


This recipe was developed and tested on CentOS 7.6.

An earlier version of this recipe was published in the article Compiling GPG 1.4.10 from source, in the section Installation Recipe For GPG 1.4.10.

In step (9), I have tested only approach (9b).




Recipe


Requirements: Linux, Bash, GCC, Make, tar.


1) Create a work directory.


2) Browse to the Assets part of this recipe and download all the linked assets. List of assets:
- gnupg-1.4.10


3) Move the asset into the work directory.


4) Open a terminal program and change directory to the work directory.


5) Unzip the zipped tape archive file, e.g. by running the following command:

This will produce the directory containing the package's source code.


6) Run to run the script and configure the package for your system. The script will print messages to report the features for which it is checking.


7) Run to compile the package.


8) Optionally, run to run any self-tests that come with the package.


9) Choose an approach to deal with permissions. The command in the next step, , will need to install various items in the directory. This directory is usually owned by the user. It is likely that you will be working as a different user, referred to here as [current user].


9a) Change user to . Change user back to [current user] after performing the next step. This approach will grant the installation script complete access to any directory (or file) owned by the user.


9b) Change the ownership (recursively) of the directory to [current user]. Change the ownership back to after performing the next step. This approach temporarily allows the installation script to access directory but not any other directory owned by .


9c) Create an admin group (e.g. , ). This group may already exist, depending on the distribution. Add both and [current user] to this group. Change the group ownership (recursively) of the directory to the admin group. This approach permanently allows the installation script to access directory but not any other directory owned by .


10) Run to install the programs and any data files and documentation.


11) You can remove the program binaries and object files from the source code directory by running .


12) To remove the files that the script created (so you can compile the package for a different kind of computer), run .


13) Open a new terminal tab or window. Run the following command to see if GPG 1.4.10 has been installed successfully (and that the command has been linked to the location of the installed binary).



You should see something like this:



The important result is the first line in the output:
















I'll follow the recipe in the article
Compiling GPG 1.4.10 from source
which has the associated asset:
gnupg-1.4.10.tar.gz


System details:
- Name: Shovel
- Specifications: HP 6005 Pro SFF. 3 GHz x86_64 processor (AMD II x4 B95 Quad Core), 4 GB RAM, 1 TB hard drive. Running CentOS 7.6.1810 (Core).
- More information: New computer: Shovel








Hm.


I'd like to install GPG 1.4.10 without interfering with the existing instance of GPG 2.2.22.

Some searching and reading indicates that:
- GPG 1 and GPG 2 can exist on the same system.
- Their data formats are compatible.
- They handle key storage somewhat differently. A key can be stored in only one of the two. To synchronise, you may have to export a key from one and import it into the other.



Are GCC and Make installed?





GCC 4.8.5 is installed. Make 3.82 is installed.



Browse to:
Compiling GPG 1.4.10 from source
Scroll to the Downloadable Assets section.
Download gnupg-1.4.10.tar.gz


Create a work directory. Move gnupg-1.4.10.tar.gz into it.


In the article, scroll to the Installation Recipe For GPG 1.4.10 section. Follow the recipe.







Hm.

Key line:







User "root" owns the directory /usr/local/bin and is the only user allowed to write new data there.

I am currently user "spiano".

/usr/local is reserved for local installations.

Hm.

I could use "sudo make install", but I don't want to make a habit of allowing a make script access to everything. I'd like to know that root-owned directories are offlimits to the make script, unless I grant access to specific directories.

I could create a new unix group (or use an existing one), and set this to be the group that owns the directory /usr/local/bin. Then I would add "root" and my user "spiano" to this group. This is probably a decent permanent solution.

However, as a temporary approach, I can change the owner of /usr/local/bin to "spiano", run "make install", then change the owner back to "root".







Permissions changed. Now continue with the recipe. Later, change the permissions back to their original settings.


Also do this for any other directories that cause permission errors.






Should have run "make check" before "make install".

Note that "make clean" removed 20 MB of stuff and that "make distclean" removed 2 MB of stuff.


Let's test.





Hm. Why does the command "gpg" call gpg 2?

"which" reports that "gpg" calls "/usr/local/bin/gpg".

The PATH variable reports that "/usr/local/bin" comes before "/usr/bin".

Both of these pieces of information suggest that the command "gpg" should call gpg 1 in /usr/local/bin, not gpg 2 in /usr/bin.



Open new tab in Terminal application.










Now "gpg" calls gpg 1 as expected. Hypothesis: Some shell setting was not reloaded/updated properly in the original terminal environment after I ran "make install".

Anyway, looks like the gpg 1 program runs (or runs well enough at least to show the version message).








Good. Permissions back as they were originally.





Delete the work directory. I'm not going to preserve the intermediate results of the compilation.



That's the end of this project.













Changes from the original text:
- I have not always preserved the format of any computer output (e.g. from running bash commands). Examples: Setting input lines in bold text, adding/removing newlines in order to make a sequence of commands easier to read, using hyphens for lists and sublists instead of indentation, breaking wide tables into consecutive sections.
- In several places, the output included some unicode bytes (curled single quotes). I have replaced them with single quotes.