Hi all!
I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they're running on, and there was some mention of this not being the best of all possible ideas.
What I'm not sure of is what would be a better way for an app installer to find out which OS version it's being installed on. Can someone offer me some enlightenment
Thanks!
On 10 June 2014 16:19, Fred Smith fredex@fcshome.stoneham.ma.us wrote:
Hi all!
I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they're running on, and there was some mention of this not being the best of all possible ideas.
Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions. Regards, Dan
On Tue, Jun 10, 2014 at 10:28 AM, Daniel Ankers md1clv@md1clv.com wrote:
Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions.
# lsb_release -a -bash: lsb_release: command not found
Unmm????
On 06/10/2014 04:54 PM, Les Mikesell wrote:
On Tue, Jun 10, 2014 at 10:28 AM, Daniel Ankers md1clv@md1clv.com wrote:
Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions.
# lsb_release -a -bash: lsb_release: command not found
Unmm????
things usually work best once you install them :)
On Tue, Jun 10, 2014 at 10:54 AM, Karanbir Singh mail-lists@karan.org wrote:
On 06/10/2014 04:54 PM, Les Mikesell wrote:
On Tue, Jun 10, 2014 at 10:28 AM, Daniel Ankers md1clv@md1clv.com wrote:
Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions.
# lsb_release -a -bash: lsb_release: command not found
Unmm????
things usually work best once you install them :)
Yes, but executing things that aren't installed by default probably isn't good choice as a portable operation to determine your environment.
lsb-release is useless, it pipes out the text read from /etc/redhat-release
On 10 iunie 2014 18:54:42 EEST, Karanbir Singh mail-lists@karan.org wrote:
On 06/10/2014 04:54 PM, Les Mikesell wrote:
On Tue, Jun 10, 2014 at 10:28 AM, Daniel Ankers md1clv@md1clv.com
wrote:
Hi Fred, I would have thought that "lsb_release -a" would be far more
portable across
varying different distributions and versions.
# lsb_release -a -bash: lsb_release: command not found
Unmm????
things usually work best once you install them :)
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/10/2014 06:01 PM, Manuel Wolfshant wrote:
lsb-release is useless, it pipes out the text read from /etc/redhat-release
but lsb-release will give you relevant content even if you are on a distro that has no /etc/redhat-release
which is kind of the point of having a single tool that can be used across distros.
On Tue, Jun 10, 2014 at 12:24 PM, Karanbir Singh mail-lists@karan.org wrote:
On 06/10/2014 06:01 PM, Manuel Wolfshant wrote:
lsb-release is useless, it pipes out the text read from /etc/redhat-release
but lsb-release will give you relevant content even if you are on a distro that has no /etc/redhat-release
which is kind of the point of having a single tool that can be used across distros.
How is running a program that isn't there any more useful than reading a file that isn't there?
On 2014-06-10, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jun 10, 2014 at 12:24 PM, Karanbir Singh mail-lists@karan.org wrote:
On 06/10/2014 06:01 PM, Manuel Wolfshant wrote:
lsb-release is useless, it pipes out the text read from /etc/redhat-release
but lsb-release will give you relevant content even if you are on a distro that has no /etc/redhat-release
which is kind of the point of having a single tool that can be used across distros.
How is running a program that isn't there any more useful than reading a file that isn't there?
If lsb-release isn't there, then the distro isn't LSB compliant. Many third-party packages state LSB compliance as minimum requirements.
--keith
On 10 iunie 2014 21:39:15 EEST, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2014-06-10, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jun 10, 2014 at 12:24 PM, Karanbir Singh
mail-lists@karan.org wrote:
On 06/10/2014 06:01 PM, Manuel Wolfshant wrote:
lsb-release is useless, it pipes out the text read from
/etc/redhat-release
but lsb-release will give you relevant content even if you are on a distro that has no /etc/redhat-release
which is kind of the point of having a single tool that can be used across distros.
How is running a program that isn't there any more useful than
reading
a file that isn't there?
If lsb-release isn't there, then the distro isn't LSB compliant. Many third-party packages state LSB compliance as minimum requirements.
--keith
-- kkeller@wombat.san-francisco.ca.us
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
quite often i do not install the lsb-release package. And I use CentOS almost exclusively for many years. On many systems, for all the organizations I work for
On Tue, Jun 10, 2014 at 12:59:58PM -0500, Les Mikesell wrote:
On Tue, Jun 10, 2014 at 12:24 PM, Karanbir Singh mail-lists@karan.org wrote:
On 06/10/2014 06:01 PM, Manuel Wolfshant wrote:
lsb-release is useless, it pipes out the text read from /etc/redhat-release
but lsb-release will give you relevant content even if you are on a distro that has no /etc/redhat-release
which is kind of the point of having a single tool that can be used across distros.
How is running a program that isn't there any more useful than reading a file that isn't there?
Heh. Obviously, it isn't.
But I thank all of you who've responded, it's been educational!
the current installer I'm using (a large-ish shellscript) goes to some effort to parse fields out of /etc/redhat-release on either RHEL or Centos. Since RHEL and Centos don't necessarily have the same (or even highly similar) text in that file, there's a lot of nearly duplicate code in the script.
The output of lsb_release looks as if it can be parsed more easily, for my purposes (e.g.: lsb_release -i -r). since I have input on what packages get installed, as well as the installer program, I can request that the package containing lsb_release also be installed, thereby saving some nontrivial number of lines of code in the installer.
thanks again for all who responded.
On 06/10/2014 06:28 PM, Daniel Ankers wrote:
On 10 June 2014 16:19, Fred Smith <fredex@fcshome.stoneham.ma.us mailto:fredex@fcshome.stoneham.ma.us> wrote:
Hi all! I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they're running on, and there was some mention of this not being the best of all possible ideas.Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions. Regards, Dan
[root@wolfy ~]# echo "My personal distro release 1.0 ( wolfy's finest ) " > /etc/redhat-release [root@wolfy ~]# lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: Mypersonaldistro Description: My personal distro release 1.0 ( wolfy's finest ) Release: 1.0 Codename: wolfy'sfinest
On Tue, Jun 10, 2014 at 10:28:26PM +0300, Manuel Wolfshant wrote:
On 06/10/2014 06:28 PM, Daniel Ankers wrote:
On 10 June 2014 16:19, Fred Smith <[1]fredex@fcshome.stoneham.ma.us> wrote:
Hi all! I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they're running on, and there was some mention of this not being the best of all possible ideas.Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions. Regards, Dan
Dan, this app is installed only on RHEL or Centos systems, so cross- distribution issues don't come up (if yu try to run the installer on, say, SUSE, it'll just error out with "unknown/incorrect distribution" or something similar.)
So the pain comes simply in telling which RHEL or centos it is. While I'm sure someone smarter could parse /etc/redhat-release in fewer lines of code than I have, it's still a pain and prone to breakage with each new version. that's where lsb_release -i -r should make life simpler.
On 06/10/2014 10:37 PM, Fred Smith wrote:
On Tue, Jun 10, 2014 at 10:28:26PM +0300, Manuel Wolfshant wrote:
On 06/10/2014 06:28 PM, Daniel Ankers wrote: On 10 June 2014 16:19, Fred Smith <[1]fredex@fcshome.stoneham.ma.us> wrote: Hi all! I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they're running on, and there was some mention of this not being the best of all possible ideas. Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions. Regards, DanDan, this app is installed only on RHEL or Centos systems, so cross- distribution issues don't come up (if yu try to run the installer on, say, SUSE, it'll just error out with "unknown/incorrect distribution" or something similar.)
So the pain comes simply in telling which RHEL or centos it is. While I'm sure someone smarter could parse /etc/redhat-release in fewer lines of code than I have, it's still a pain and prone to breakage with each new version. that's where lsb_release -i -r should make life simpler.
rpm -q should make life much easier if you already know you are on centos/RHEL. just rpm -q --qf "%{vendor}\n" kernel or glibc or filesystem any other mandatory package to discriminate between the two families of distributions and then rpm -q --qf "apropriate fields here " centos-release / redhat-release to find out anything else you need.
On Jun 10, 2014, at 2:44 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 06/10/2014 10:37 PM, Fred Smith wrote:
On Tue, Jun 10, 2014 at 10:28:26PM +0300, Manuel Wolfshant wrote:
On 06/10/2014 06:28 PM, Daniel Ankers wrote:
On 10 June 2014 16:19, Fred Smith <[1]fredex@fcshome.stoneham.ma.us> wrote:
Hi all! I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they're running on, and there was some mention of this not being the best of all possible ideas.Hi Fred, I would have thought that "lsb_release -a" would be far more portable across varying different distributions and versions. Regards, Dan
Dan, this app is installed only on RHEL or Centos systems, so cross- distribution issues don't come up (if yu try to run the installer on, say, SUSE, it'll just error out with "unknown/incorrect distribution" or something similar.)
So the pain comes simply in telling which RHEL or centos it is. While I'm sure someone smarter could parse /etc/redhat-release in fewer lines of code than I have, it's still a pain and prone to breakage with each new version. that's where lsb_release -i -r should make life simpler.
rpm -q should make life much easier if you already know you are on centos/RHEL. just rpm -q --qf "%{vendor}\n" kernel or glibc or filesystem any other mandatory package to discriminate between the two families of distributions and then rpm -q --qf "apropriate fields here " centos-release / redhat-release to find out anything else you need.
We've been cursing this week that we didn't now about lsb_release. Just the same, our trick was similar to yours:
rpm -qf --queryformat '%{VERSION}\n' /etc/redhat-release
Which gets me the distro version, regardless of what RHEL derivative I'm querying. Yes, you're out of luck on SUSE but luckily that wasn't in my problem set.
Todd
Hi Fred,
You should checkout how Virtualmin does system version detection.
http://software.virtualmin.com/lib/oschooser.pl http://software.virtualmin.com/lib/os_list.txt
Dan
On 11 June 2014 23:51, Todd Rinaldo toddr@cpanel.net wrote:
On Jun 10, 2014, at 2:44 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 06/10/2014 10:37 PM, Fred Smith wrote:
On Tue, Jun 10, 2014 at 10:28:26PM +0300, Manuel Wolfshant wrote:
On 06/10/2014 06:28 PM, Daniel Ankers wrote:
On 10 June 2014 16:19, Fred Smith <[1]fredex@fcshome.stoneham.ma.us> wrote:
Hi all! I think it was on this list, in the last week or so I saw some comment about how some apps may grope the contents of /etc/redhat-release when installing themselves, so as to figure how which OS they'rerunning
on, and there was some mention of this not being the best of all possible ideas.Hi Fred, I would have thought that "lsb_release -a" would be far more
portable
across varying different distributions and versions. Regards, Dan
Dan, this app is installed only on RHEL or Centos systems, so cross- distribution issues don't come up (if yu try to run the installer on, say, SUSE, it'll just error out with "unknown/incorrect distribution" or something similar.)
So the pain comes simply in telling which RHEL or centos it is. While I'm sure someone smarter could parse /etc/redhat-release in fewer lines of code than I have, it's still a pain and prone to breakage with each new version. that's where lsb_release -i -r should make life simpler.
rpm -q should make life much easier if you already know you are on centos/RHEL. just rpm -q --qf "%{vendor}\n" kernel or glibc or filesystem any other mandatory package to discriminate between the two families of distributions and then rpm -q --qf "apropriate fields here " centos-release / redhat-release to find out anything else you need.
We've been cursing this week that we didn't now about lsb_release. Just the same, our trick was similar to yours:
rpm -qf --queryformat '%{VERSION}\n' /etc/redhat-release
Which gets me the distro version, regardless of what RHEL derivative I'm querying. Yes, you're out of luck on SUSE but luckily that wasn't in my problem set.
Todd
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, Jun 12, 2014 at 10:58:31AM +0100, Dan Porter wrote:
Hi Fred,
You should checkout how Virtualmin does system version detection.
http://software.virtualmin.com/lib/oschooser.pl http://software.virtualmin.com/lib/os_list.txt
Which does it the 100% wrong way.
Again, contents of /etc/*-release _can not be trusted_.
John
On 06/12/2014 12:04 PM, John R. Dennison wrote:
On Thu, Jun 12, 2014 at 10:58:31AM +0100, Dan Porter wrote:
Hi Fred,
You should checkout how Virtualmin does system version detection.
http://software.virtualmin.com/lib/oschooser.pl http://software.virtualmin.com/lib/os_list.txt
Which does it the 100% wrong way.
Again, contents of /etc/*-release _can not be trusted_.
the proper way for this is: rpm -q --nosignature --qf "%{VERSION}" --whatprovides redhat-release 2>/dev/null this is working on all rhel/centos/sl etc and even on fedora.
On 06/12/2014 11:29 AM, Farkas Levente wrote:
On 06/12/2014 12:04 PM, John R. Dennison wrote:
On Thu, Jun 12, 2014 at 10:58:31AM +0100, Dan Porter wrote:
Hi Fred,
You should checkout how Virtualmin does system version detection.
http://software.virtualmin.com/lib/oschooser.pl http://software.virtualmin.com/lib/os_list.txt
Which does it the 100% wrong way.
Again, contents of /etc/*-release _can not be trusted_.
the proper way for this is: rpm -q --nosignature --qf "%{VERSION}" --whatprovides redhat-release
shouldnt that be system-release ?
On Thu, Jun 12, 2014 at 11:35:37AM +0100, Karanbir Singh wrote:
On 06/12/2014 11:29 AM, Farkas Levente wrote:
On 06/12/2014 12:04 PM, John R. Dennison wrote:
On Thu, Jun 12, 2014 at 10:58:31AM +0100, Dan Porter wrote:
Hi Fred,
You should checkout how Virtualmin does system version detection.
http://software.virtualmin.com/lib/oschooser.pl http://software.virtualmin.com/lib/os_list.txt
Which does it the 100% wrong way.
Again, contents of /etc/*-release _can not be trusted_.
the proper way for this is: rpm -q --nosignature --qf "%{VERSION}" --whatprovides redhat-release
shouldnt that be system-release ?
Doesn't work on CentOS-4
best regards,
Florian La Roche
On 06/12/2014 11:38 AM, Florian La Roche wrote:>
Doesn't work on CentOS-4
if your app still cares about CentOS-4, you might have bigger problems at this point :)
- KB
On 06/12/2014 12:35 PM, Karanbir Singh wrote:
On 06/12/2014 11:29 AM, Farkas Levente wrote:
On 06/12/2014 12:04 PM, John R. Dennison wrote:
On Thu, Jun 12, 2014 at 10:58:31AM +0100, Dan Porter wrote:
Hi Fred,
You should checkout how Virtualmin does system version detection.
http://software.virtualmin.com/lib/oschooser.pl http://software.virtualmin.com/lib/os_list.txt
Which does it the 100% wrong way.
Again, contents of /etc/*-release _can not be trusted_.
the proper way for this is: rpm -q --nosignature --qf "%{VERSION}" --whatprovides redhat-release
shouldnt that be system-release ?
not. it's not working on os 5.x. but the above working everywhere.
On Tue, Jun 10, 2014 at 03:37:45PM -0400, Fred Smith wrote:
So the pain comes simply in telling which RHEL or centos it is. While I'm sure someone smarter could parse /etc/redhat-release in fewer lines of code than I have, it's still a pain and prone to breakage with each new version. that's where lsb_release -i -r should make life simpler.
For CentOS you can do:
rpm -q centos-release | cut -d. -f 1 | cut -d- -f3- | tr '-' '.'
(Yes, ugly. Works fine, however.)
I've not tried on a RHEL box but exchanging redhat-release for centos-release probably will work there as well.
Depending on contents of /etc/*-release is problematic as it's just a pure text file that can, and often is, modified by the user.
John
On 06/10/2014 05:19 PM, Fred Smith wrote:
What I'm not sure of is what would be a better way for an app installer to find out which OS version it's being installed on. Can someone offer me some enlightenment
/etc/os-release
http://www.freedesktop.org/software/systemd/man/os-release.html
On Jun 19, 2014 2:32 AM, "Miroslav Suchý" msuchy@redhat.com wrote:
On 06/10/2014 05:19 PM, Fred Smith wrote:
What I'm not sure of is what would be a better way for an app installer to find out which OS version it's being installed on. Can someone offer me some enlightenment
/etc/os-release
http://www.freedesktop.org/software/systemd/man/os-release.html
If you use Python, its standard library has a pretty good platform module for these kinds of things, which works even beyond Linux and even to somewhat old versions of distros.
Features that are introduced by systemd can't be assumed as present except on those (recent) Linux OS versions which are using systemd, and can almost be assumed absent outside the Linux world (such as Solaris, BSD, Win/Mac). A few non-systemd Linux distros do ship /etc/os-release, especially those distro preparing to adopt systemd like Debian and Ubuntu - but even there only in recent or unreleased versions.
By far the most portable platform detection system is know is GNU autoconf's config.guess, but that may be overkill. :)
- Jimmy
On 06/19/2014 12:38 PM, Jimmy Kaplowitz wrote:
Features that are introduced by systemd can't be assumed as present except on those (recent) Linux OS versions which are using systemd, and can almost be assumed absent outside the Linux world (such as Solaris, BSD, Win/Mac). A few
Well parsing /etc/redhat-release works only on RHEL/Fedora. /etc/os-release is little better, although I admit id did not work on Windows :)
non-systemd Linux distros do ship /etc/os-release, especially those distro preparing to adopt systemd like Debian and Ubuntu - but even there only in recent or unreleased versions
Not completely true. It is present in Debian for 2 years - long time before considering systemd. And it is present in Debian stable already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853
On Thu, Jun 19, 2014 at 6:15 AM, Miroslav Suchý msuchy@redhat.com wrote:
On 06/19/2014 12:38 PM, Jimmy Kaplowitz wrote:
Features that are introduced by systemd can't be assumed as present
except on those (recent) Linux OS versions which are
using systemd, and can almost be assumed absent outside the Linux world
(such as Solaris, BSD, Win/Mac). A few
Well parsing /etc/redhat-release works only on RHEL/Fedora. /etc/os-release is little better, although I admit id did not work on Windows :)
Right, I was replying to the /etc/os-release. That only works on RHEL/CentOS/Fedora 7, 6 and maybe 5. Python's platform module supports far older versions of those.
non-systemd Linux distros do ship /etc/os-release, especially those distro preparing to adopt systemd like Debian and
Ubuntu - but even there only in recent or unreleased versions
Not completely true. It is present in Debian for 2 years - long time before considering systemd. And it is present in Debian stable already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853
Debian stable already has pretty good working systemd as a non-default option, which explains that. The recent publicity was about Debian's decision to switch the default starting with Debian 8 "jessie".
For enterprise-lifecycle distros like Debian / RHEL / CentOS, being added two years ago and being present in only the most current stable release counts as "recent". Many people are still running Debian 7 "squeeze", to the point where a subset of squeeze ("squeeze-lts") is still receiving support and security fixes beyond Debian's normal policies.
- Jimmy
-
Dan Porter -
Daniel Ankers -
Farkas Levente -
Florian La Roche -
Fred Smith -
Jimmy Kaplowitz -
John R. Dennison -
Karanbir Singh -
Keith Keller -
Les Mikesell -
Manuel Wolfshant -
Miroslav Suchý -
Todd Rinaldo