148

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.

151

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
  • 5
    command not found on my CentOS 5.4 box :( – gbjbaanb Dec 1 '09 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 '09 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 '11 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 '14 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... – Jens Timmerman Feb 21 '14 at 8:39
142

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.

  • 14
    This is the most appropriate answer to the question. – fsoppelsa Feb 19 '14 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 '15 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 '17 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. – Dennis Nolte Oct 4 '18 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).

  • 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. – Stefan Lasiewski Oct 29 '14 at 21:29
  • 5
    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. – David Tonhofer Jan 16 '15 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 '18 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.

  • 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 '13 at 15:47
  • 1
    Yeah thanks, one note: does not work with RHEL Worstation. – lzap Feb 6 '14 at 14:15
  • One note - this runs a lot slower than parsing /etc/foo-release. – Dan Pritts Mar 11 '15 at 15:10
  • 1
    or rpm -qa | grep release is even easier – warren Mar 16 '15 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).

  • 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 '14 at 13:31
  • 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 '14 at 14:53
2

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)
  • Interesting, useful. Unfortunately, not present on RHEL6 so of limited value at the moment. – Dan Pritts Jan 24 '18 at 2:19
2

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 ~]#

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

protected by Chris S Nov 13 '14 at 15:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.