153

From the shell and without root privileges, how can I determine what Red Hat Enterprise Linux version I'm running?

Ideally, I'd like to get both the major and minor release version, for example RHEL 4.0 or RHEL 5.1, etc.

9 Answers 9

155

You can use the lsb_release command on various Linux distributions:

lsb_release -i -r 

This will tell you the Distribution and Version and is a little bit more accurate than accessing files that may or may not have been modified by the admin or a software package. As well as working across multiple distros.

For RHEL, you should use:

cat /etc/redhat-release
6
  • 5
    command not found on my CentOS 5.4 box :(
    – gbjbaanb
    Dec 1, 2009 at 17:04
  • @gbjbaanb: That's strange I tested it on a fresh 5.4 minimal install and it worked just fine...
    – Zypher
    Dec 1, 2009 at 18:25
  • 26
    lsb_release -i -r -bash: lsb_release: command not found. However, cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.6 (Tikanga)
    – Tom
    May 10, 2011 at 12:12
  • 7
    Just for the record: Does not work on RHEL 6.5 minimal install. Command lsb_release is nowhere to be found.
    – sborsky
    Feb 6, 2014 at 9:18
  • 4
    lsb_release is not a lightweight package, It pulls in CUPS to provide ‘/usr/bin/lp’, which pulls in some pdf translation goop, which pulls in some rendering libraries... Feb 21, 2014 at 8:39
143

You can look at the contents of /etc/redhat-release, which will look something like this:

$ cat /etc/redhat-release 
CentOS release 5.4 (Final)

The contents are different for an actual RHEL system. This technique works on all RedHat derivatives, including CentOS, Fedora, and others.

4
  • 15
    This is the most appropriate answer to the question.
    – fsoppelsa
    Feb 19, 2014 at 17:01
  • lsb_release is the first thing to try, but since that might not be installed looking at files is a good Plan B.
    – chicks
    Jul 8, 2015 at 16:07
  • 1
    @chicks Given that the question asks for a test for Redhat systems, and lsb_release is not installed by default on redhat systems and /etc/redhat-release is, then lsb_release is obviously not the first thing to try!
    – bye
    Jun 8, 2017 at 16:27
  • @bye It is the first thing to try (at least in my opinion) , you always try the things which should be common on all distributions first, then only you switch to distribution-specific solutions. Oct 4, 2018 at 7:52
25

I prefer to use the /etc/issue file.

$ cat /etc/issue

I've seen many situations where /etc/redhat-release has been modified to meet software compatibility requirements (Dell or HP's management agents, for instance).

3
  • 1
    /etc/issue also works on other OSes as well, such as Debian & Ubuntu, and works with Linux OSes that don't conform to the Linux Standards Base, and lightweight OSes that don't have the lsb* utilities installed. Oct 29, 2014 at 21:29
  • 6
    This is not reliable. Apparently /etc/issue is meant to be parsed by agetty, which replaces the escape sequences with proper information. If you just cat it, the result may be underwhelming. On Fedora, one gets Fedora release 20 (Heisenbug) Kernel \r on an \m (\l), which tells you something but on RHEL7, one just gets \S Kernel \r on an \m. Jan 16, 2015 at 20:30
  • Note that /etc/issue may be replaced by the local admin and hence is not a reliable source of information.
    – larsks
    Oct 4, 2018 at 11:42
13

The most reliable way when lsb_release is not installed is:

# rpm -q --queryformat '%{VERSION}' redhat-release-server
6Server

# rpm -q --queryformat '%{RELEASE}' redhat-release-server
6.4.0.4.el6

On minimal installs, lsb_release is missing.

To get this working also with Red Hat clones (credit goes to comments):

# rpm -q --queryformat '%{VERSION}' $(rpm -qa '(redhat|sl|slf|centos|oraclelinux)-release(|-server|-workstation|-client|-computenode)')

Or, as a single command (rather than two "rpm"'s being executed):

# rpm -qa --queryformat '%{VERSION}\n' '(redhat|sl|slf|centos|oraclelinux)-release(|-server|-workstation|-client|-computenode)'

Use sed/cut and other text manipulating UNIX tools to get what you want.

4
  • 2
    This seems to work, more generically: rpm -qa '(oraclelinux|sl|redhat|centos)-release(|-server)' sl is for Scientific Linux; if you know the right name for other RHEL rebuilds maybe comment below. Warning - not extensively tested.
    – Dan Pritts
    Aug 8, 2013 at 15:47
  • 1
    Yeah thanks, one note: does not work with RHEL Worstation.
    – lzap
    Feb 6, 2014 at 14:15
  • One note - this runs a lot slower than parsing /etc/foo-release.
    – Dan Pritts
    Mar 11, 2015 at 15:10
  • 2
    or rpm -qa | grep release is even easier
    – warren
    Mar 16, 2015 at 18:40
6

Assuming it truly is a Red Hat release (not Centos):

rpm -q redhat-release

Or just run:

uname -r

And map the output. 2.6.9 kernels are RHEL4, 2.6.18 kernels are RHEL5. If necessary, you can map the full version to the specific update releases from Red Hat (i.e. 2.6.9-89 is RHEL5 U4).

2
  • 1
    rpm -q redhat-release just returns package redhat-release is not installed for me, and uname -r just tells me the kernel release.
    – Mark Booth
    Aug 20, 2014 at 13:31
  • 1
    Oh ! And now that time has passed, what would be RHEL6 ? RHEL7 ? Hum... Here are the answers: access.redhat.com/articles/3078#RHEL7
    – mika
    Nov 12, 2014 at 14:53
3

I quite like using the /etc/os-release file, which is in the release RPM:

# yum whatprovides /etc/os-release 
Loaded plugins: fastestmirror, langpacks
Determining fastest mirrors
 * base: dl.za.jsdaav.net
 * extras: dl.za.jsdaav.net
 * updates: dl.za.jsdaav.net
centos-release-7-4.1708.el7.centos.x86_64 : CentOS Linux release file
Repo        : base
Matched from:
Filename    : /etc/os-release

centos-release-7-4.1708.el7.centos.x86_64 : CentOS Linux release file
Repo        : @anaconda
Matched from:
Filename    : /etc/os-release

This file can be sourced in scripts, like:

$ source /etc/os-release
$ echo $NAME
CentOS Linux
$ echo $VERSION
7 (Core)
1
  • Interesting, useful. Unfortunately, not present on RHEL6 so of limited value at the moment.
    – Dan Pritts
    Jan 24, 2018 at 2:19
3

I prefer hostnamectl:

$ hostnamectl
   Static hostname: xxxxxx.xxx.xxx
         Icon name: computer-server
           Chassis: server
        Machine ID: 3e3038756eaf4c5c954ec3d24f35b13f
           Boot ID: 958452e0088b4191a4ea676ebc90403b
  Operating System: Red Hat Enterprise Linux Server 7.5 (Maipo)
       CPE OS Name: cpe:/o:redhat:enterprise_linux:7.5:GA:server
            Kernel: Linux 3.10.0-862.3.3.el7.x86_64
      Architecture: x86-64
1

If you want to just get the version numbers the following is about as short and simple as I can get it.

Tested on rhel 6.7, rhel 7.2, debian 8.3 and ubuntu 14.04:

lsb_release -s -r | cut -d '.' -f 1

For a practical example, say you want to test for the distribution major and minor version and do things based on that:

#!/bin/bash

major=$(lsb_release -s -r | cut -d '.' -f 1)
minor=$(lsb_release -s -r | cut -d '.' -f 2)

if (( "$major" >= 7 ))
then
  echo "Do stuff, OS major version is $major"
  echo "OS minor version is $minor"
else
  echo "Do other things"
  echo "Your version is $major.$minor"
fi
1

A late arrival to this, but I had fun trying to figure out the RHEL version on several remote nodes. So, if you have a batch of servers that use the same password (I know, I know...) here is a quick and dirty to check the RedHat version:

Create an expect script

vim server-version.sh

Expect script to check major RedHat version on multiple remote hosts

#!/usr/bin/expect
log_user 0
spawn ssh -l root [lindex $argv 0]
expect "assword:"
send "sUp3rS3cr3tP4ssW0rd^\r"
expect "# "
log_user 1
send "cat /etc/redhat-release\r"
expect "*#"
log_user 0
send "exit\n"

Run the script for all your nodes

[root@home ~]#
for server in server1 server2 server3 server4 server5; do echo -e "$server: \c"; /root/server-version.sh $server; echo; echo; done;

Output

server1: cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)
[root@server1 ~]#

server2: cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)
[root@server2 ~]#

...
2
  • 1
    If you're going to do remote stuff on a lot of machines, I strongly recommend using Ansible rather than hand-rolled bash scripts. Jan 31, 2018 at 16:53
  • I also recommend not enabling root login over ssh Jan 31, 2018 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .