4

The usual methods to determine the OS versions seem to be viewing

/etc/*-release file 

*here would be the family to which the particular version of the OS belongs to. But on the OEL system, the following files are present and all of them seem to be returning valid release versions, in such situations is there a definite method of determining the OS release version details :

 cat /etc/redhat-release
 Red Hat Enterprise Linux Server release 5.8 (Tikanga)

  cat /etc/enterprise-release
  Enterprise Linux Enterprise Linux Server release 5.8 (Carthage)

  cat /etc/oracle-release
  Oracle Linux Server release 5.8

cat /etc/*release*
Enterprise Linux Enterprise Linux Server release 5.8 (Carthage)
Oracle Linux Server release 5.8
Red Hat Enterprise Linux Server release 5.8 (Tikanga)

using alternatives as mentioned below are used only in case the above files don't return valid values :

lsb_release -a returns the same output as returned by enterprise-release 

Update 1 : context of execution

The /etc/*-release file is examined as a part of a programmatic solution, the value of * is provided by a dummy file which can have these values :

asianux,enterprise,mandrake,redhat,UnitedLinux,Suse,SuSE

depending on the order of appearance in the above scenario since enterprise appears first /etc/enterprise-release file is queried to find the OS version In case the ordering was otherwise with redhat appearing before enterprise /etc/redhat-release would be used.

This does not seem to be a viable solution hence seeking other more definite methods for determining the version of the OS.

5
  • 1
    Why do you need to know the version? Is this part of another process or script? Are you seeking a programmatic solution, or are you willing to check manually? More context would be helpful.
    – ewwhite
    Sep 2, 2014 at 7:01
  • 1
    I am not sure how other people do it for other distribution but the way I do it for RedHat and its corresponding distribution ,is to run uname -a and then map it to its source code,in that I am absolutely 100% sure that what distribution I am running access.redhat.com/labs/psb Sep 2, 2014 at 7:15
  • 1
    @ewwhite, the /etc/*-release scripts are being executed as a part of a programmatic solution. No manual check would not a practical solution. Also updating the questions with more information
    – bhavs
    Sep 2, 2014 at 7:16
  • @bhavs Do you need to differentiate between RHEL, CentOS and OEL?
    – ewwhite
    Sep 2, 2014 at 7:19
  • 2
    @PrashantLakhera That's not deterministic. Sometimes people use different kernels on RHEL/CentOS. Oracle Enterprise Linux definitely makes use of newer kernel revisions.
    – ewwhite
    Sep 2, 2014 at 7:21

4 Answers 4

7
lsb_release -a

See Linux Standard Base documentation

As per your question you mention this as an alternative in case the above do not work. You should use lsb_release first as it is the standard.

Also it should return more information than the enterprise-release command, specifically the LSB Version line (eg, lsb_release -v)

3
  • 2
    Just a side note, lsb_release is not installed by default on CentOS and comes from the redhat-lsb-core package. OP would have to try other options if that doesn't work at first.
    – gtirloni
    Sep 2, 2014 at 11:19
  • I agree with @gtirloni. It's not reasonable to expect lsb_release to be installed. I didn't even start installing it on RHEL/CentOS systems until the last year or two.
    – ewwhite
    Sep 3, 2014 at 9:11
  • I'm not a big Centos/Redhat user myself. Before answering I rechecked one of my older Centos dedicated servers at one of our ISP's and the server there from Feb 14 2011 does have it installed by default. It's running CentOS release 5.7 (Final) Sep 5, 2014 at 9:49
5

(Are Mandrake, AsianUX and UnitedLinux still around enough to certify compatibility on new software?)

Definitely check the suggestions at: What version of RHEL am I using?

But beyond that, look at facter if you have some control over the systems this software will be deployed on. If this is software that will be shipped and run on systems that you don't manage, then you'll likely have to have to handle OS-detection. If it is your company/environment, facter is the cleanest method.

When dealing with RHEL and its derivatives, it's important to know that the distribution lifecycle strives to maintain compatibility between minor releases. So software should be able to run on *EL5.4, 5.8 and 5.10, for example. I don't think that's your issue here, though, as you probably only care about the OS "family".

Look at the facter output from the following three systems.

# facter operatingsystem operatingsystemmajrelease operatingsystemrelease osfamily
operatingsystem => RedHat
operatingsystemmajrelease => 5
operatingsystemrelease => 5.8
osfamily => RedHat

and

# facter operatingsystem operatingsystemmajrelease operatingsystemrelease osfamily
operatingsystem => CentOS
operatingsystemmajrelease => 5
operatingsystemrelease => 5.9
osfamily => RedHat

and

# facter operatingsystem operatingsystemmajrelease operatingsystemrelease osfamily
operatingsystem => CentOS
operatingsystemmajrelease => 6
operatingsystemrelease => 6.5
osfamily => RedHat

They're CentOS and RHEL, versions 5.8, 5.9 and 6.5. But I think you probably only care that they're RedHat derivatives. I'd be using the osfamily and maybe the operatingsystemmajrelease fact.

Take a look at the OS-detection routine that facter uses... https://github.com/puppetlabs/facter/blob/master/lib/facter/operatingsystem/linux.rb

snip

      if FileTest.exists?("/etc/enterprise-release")
        if FileTest.exists?("/etc/ovs-release")
          operatingsystem = "OVS"
        else
          operatingsystem = "OEL"
        end
      elsif FileTest.exists?("/etc/redhat-release")
        operatingsystem = get_redhat_operatingsystem_name

snip

  def get_redhat_operatingsystem_name
    txt = File.read("/etc/redhat-release")
    matches = {
      "CentOS"     => "centos",
      "Scientific" => "Scientific",
      "CloudLinux" => "^cloudlinux",
      "PSBM"       => "^Parallels Server Bare Metal",
      "Ascendos"   => "Ascendos",
      "XenServer"  => "^XenServer",
      "XCP"        => "XCP"
    }

In short, Oracle Enterprise Linux detection totally hinges on the presence of /etc/enterprise-release.

[root@xt ~]# facter osfamily
RedHat
[root@xt ~]# facter operatingsystem
CentOS
[root@xt ~]# touch /etc/enterprise-release
[root@xt ~]# facter operatingsystem
OEL

So you're doing this the right way, or at least the same way facter does.

2
  • facter definitely looks very promising but I really don't have any control on the systems that the software will run on and cannot expect facter to be present there.
    – bhavs
    Sep 2, 2014 at 9:35
  • @bhavs Well, the logic to distinguish OEL from RHEL is included in my answer, as well as the relevant detection methods used by facter.
    – ewwhite
    Sep 3, 2014 at 9:12
3

There are no definitive/standard methods that will work across all major distributions. You'll have to use extra code to figure it out to the best of your knowledge (based on how you understand each distribution make this information available).

If this is for an installation script, give the user the option of specifying it by hand. If you want o be super nice, try to figure it out yourself and just ask for confirmation.

If this is for a program that will be checking things (and thus need to look at different locations to find them), provide the option of a configuration file or command-line option to specify which distro is being used.

The other solutions provided are great, but you'll depend on code/packages that might not be available everywhere (especially facter, which is by far the most complete tool for gathering information about the environment).

0
uname -a 

(Print all Information)

uname -r 

(Print the kernel name)

cat /etc/issue
cat /etc/redhat-release
lsb_release –a
tail /etc/redhat-releas

You must log in to answer this question.

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