I want to install specific packages only in an environment where RHUI is not accessible
This page has been translated by machine translation. View original
Introduction
Hello everyone, this is Akaike.
Have you ever wanted to install packages on a RHEL EC2 instance that can't access RHUI?
I have.
Normally, you could simply use dnf install, but in an environment where you can't connect to RHUI due to network constraints, this obviously won't work.
On the other hand, setting up a repository server just to install a few packages during initial configuration seems excessive (and troublesome), doesn't it?
So in this article, I'll summarize how to install rpm packages directly without a repository server.
While this is a classic approach that has been used since ancient times, there seemed to be surprisingly few articles covering the complete procedure, so I decided to write one.
Overview
The approach is simple and follows this flow:
We'll use a server with RHUI access as a "rpm retrieval source" and manually install the retrieved rpm packages.
- Target server: Check the versions of required packages
- RPM retrieval server: Download the rpm packages
- Target server: Transfer the downloaded rpm packages and install them using
rpm -ivh
Environment for this blog
- Target server: RHEL 9 series EC2 instance (unable to access RHUI)
- RPM retrieval server: RHEL 9 series EC2 instance (able to access RHUI)
- AMI: AWS-provided RHEL AMI (License Included)
- Package to install:
glibc-langpack-ja(Japanese language pack) - SSH/SCP access to each server from local terminal is available
Procedure
1. Check the current status
First, let's check the available locales on the target server.
$ locale -a
C
C.utf8
en_AG
en_AU
en_AU.utf8
en_BW
en_BW.utf8
en_CA
en_CA.utf8
en_DK
en_DK.utf8
en_GB
en_GB.iso885915
en_GB.utf8
en_HK
en_HK.utf8
en_IE
en_IE@euro
en_IE.utf8
en_IL
en_IN
en_NG
en_NZ
en_NZ.utf8
en_PH
en_PH.utf8
en_SC.utf8
en_SG
en_SG.utf8
en_US
en_US.iso885915
en_US.utf8
en_ZA
en_ZA.utf8
en_ZM
en_ZW
en_ZW.utf8
POSIX
Japanese locales (like ja_JP.utf8) don't exist.
Our goal is to install glibc-langpack-ja to enable Japanese locales.
2. Check the required package version
Next, check the version of glibc installed on the target server.
Since glibc-langpack-ja must match the version of glibc itself, use the following command to identify the version to install:
$ rpm -q glibc --queryformat 'glibc-langpack-ja-%{VERSION}-%{RELEASE}\n'
glibc-langpack-ja-2.34-168.el9_6.24
We now know we need version glibc-langpack-ja-2.34-168.el9_6.24.
3. Download the rpm on a server with RHUI access
Next, on the server that can access RHUI, download the rpm of the version we identified:
$ sudo dnf download glibc-langpack-ja-2.34-168.el9_6.24
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.
Last metadata expiration check: 0:05:09 ago on Mon 23 Feb 2026 03:20:39 PM UTC.
glibc-langpack-ja-2.34-168.el9_6.24.x86_64.rpm 12 MB/s | 329 kB 00:00
Using dnf download allows you to get the rpm file without installing it.
Note that the warning "Unable to read consumer identity" appears because AWS-provided RHEL AMIs (License Included) use RHUI for license management rather than subscription-manager. Registration with subscription-manager is unnecessary, so this warning can be safely ignored.
4. Transfer the rpm to the target server
Transfer the downloaded rpm to the target server via your local terminal.
First, download it from the rpm retrieval server to your local machine:
% scp -i keys/ec2.pem ec2-user@XX.XX.XX.XX:~/ ~/Downloads/
glibc-langpack-ja-2.34-168.el9_6.24.x86_64.rpm 100% 329KB 1.8MB/s 00:00
After downloading to your local machine, upload it to the target server using SCP.
5. Install the rpm
Install the transferred rpm using rpm -ivh:
$ sudo rpm -ivh ./glibc-langpack-ja-2.34-168.el9_6.24.x86_64.rpm
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:glibc-langpack-ja-2.34-168.el9_6.################################# [100%]
The installation completed successfully.
6. Verify the installation
After installation, check the locale list again:
$ locale -a
C
C.utf8
en_AG
en_AU
en_AU.utf8
en_BW
en_BW.utf8
en_CA
en_CA.utf8
en_DK
en_DK.utf8
en_GB
en_GB.iso885915
en_GB.utf8
en_HK
en_HK.utf8
en_IE
en_IE@euro
en_IE.utf8
en_IL
en_IN
en_NG
en_NZ
en_NZ.utf8
en_PH
en_PH.utf8
en_SC.utf8
en_SG
en_SG.utf8
en_US
en_US.iso885915
en_US.utf8
en_ZA
en_ZA.utf8
en_ZM
en_ZW
en_ZW.utf8
ja_JP.eucjp
ja_JP.utf8
POSIX
We can confirm that ja_JP.eucjp and ja_JP.utf8 have been added.
Finally, apply the locale settings and confirm they're correctly configured:
$ source /etc/locale.conf && export LANG
$ cat /etc/locale.conf
LANG=ja_JP.UTF-8
$ locale
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=
If all items are set to ja_JP.UTF-8, the Japanese locale configuration is complete.
Bonus: Is this okay from a licensing perspective?
By the way, some of you might be concerned about whether this approach is acceptable from a licensing standpoint.
The conclusion is that it's likely fine for the following reasons:
- RHUI-based downloads
- RHEL instances on AWS include the RHEL subscription in the EC2 fee, and package retrieval via RHUI is the legitimate usage method
- Local installation with rpm -ivh
- This is a standard method described in Red Hat's official documentation as an "approach for network-isolated environments"
- Transferring RPMs to another instance
- Both instances are within the same AWS account and both have RHEL licenses
Specifically, this corresponds to "Approach 2: Download the updates on a connected system" in the following document, so it should be acceptable:
Conclusion
That's how to install specific packages in an environment without RHUI access.
While we used glibc-langpack-ja as an example, the same approach can be applied to other packages.
However, for packages with dependencies, you'll need to download those dependencies as well - in such cases, use the dnf download --resolve option.
Since environments that can't connect to RHUI for network reasons are surprisingly common, I hope this helps anyone facing similar situations.
