Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #211247 > unrolled thread

Where'd lsb-compat go?

Back to article view | Back to linux.debian.user

Contents

  Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-11 20:50 +0200
    Re: Where'd lsb-compat go? Dominic Knight <dominicknight@gmx.com> - 2019-07-12 05:10 +0200
      Re: Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-12 16:50 +0200
    Re: Where'd lsb-compat go? Tixy <tixy@yxit.co.uk> - 2019-07-12 10:10 +0200
    Re: Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-15 16:20 +0200
      Re: Where'd lsb-compat go? Michael Stone <mstone@debian.org> - 2019-07-15 16:30 +0200
        Re: Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-15 21:40 +0200
          Re: Where'd lsb-compat go? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-15 21:40 +0200
          Re: Where'd lsb-compat go? Stefan Monnier <monnier@iro.umontreal.ca> - 2019-07-15 21:50 +0200
            Re: Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-15 22:10 +0200
              Re: Where'd lsb-compat go? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-15 22:20 +0200
                Re: Where'd lsb-compat go? Nicolas George <george@nsup.org> - 2019-07-15 23:00 +0200
                  Re: Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-15 23:20 +0200
                Re: Where'd lsb-compat go? Kent West <westk@acu.edu> - 2019-07-15 23:00 +0200
                Re: Where'd lsb-compat go? Gene Heskett <gheskett@shentel.net> - 2019-07-15 23:20 +0200
              Re: Where'd lsb-compat go? Gene Heskett <gheskett@shentel.net> - 2019-07-15 23:00 +0200
            Re: Where'd lsb-compat go? Andy Smith <andy@strugglers.net> - 2019-07-16 14:30 +0200
      Re: Where'd lsb-compat go? Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-16 08:50 +0200
        Re: Where'd lsb-compat go? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-16 14:50 +0200

#211247 — Where'd lsb-compat go?

Two issues:


1) I have several Debian boxes running as kiosks, and reporting to a 
centralized Quest-branded "Systems Management Appliance" (SMA). With a 
recent update to the SMA, the Debian boxes stopped reporting in. After 
several weeks, I finally discovered that the installation of 
"lsb-compat" on several of them restored their functionality. Today, 
when I go to install "lsb-compat" on the other's, I find it's no longer 
available in Buster. Has it been deprecated? Why? Any ideas how I'm 
going to get my boxes reporting again to the SMA (what does "lsb-compat" 
do, that maybe I can duplicate manually, etc?)? I thought maybe 
"lsb-release" might do the same thing, as the basic problem is that the 
SMA's client piece on the Debian boxes had stopped finding the version 
of Debian installed on the box, which broke the reporting process. When 
I installed "lsb-compat", the SMA client piece could once again detect 
the Debian version.


2) When I compare two of my Debian boxes (set up at different times and 
probably in slightly different ways), I find that the 
/etc/apt/sources.list files are functionally identical (with no extras 
in the sources.list.d directory), but when I do an "aptitude search lsb" 
on each, they give different results. Huh? That doesn't make sense to 
me. For completeness:


root@lib-pac-04:~# cat /etc/apt/sources.list
#


deb http://ftp.us.debian.org/debian/ stable main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stable main contrib non-free

deb http://security.debian.org/debian-security stable/updates main 
contrib non-free
deb-src http://security.debian.org/debian-security stable/updates main 
contrib non-free

# stable-updates, previously known as 'volatile'
deb http://ftp.us.debian.org/debian/ stable-updates main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stable-updates main contrib 
non-free



----

root@lib-pac-04:~# aptitude search lsb
p liblist-utilsby-perl - higher-order list utility functions
p liblist-utilsby-xs-perl - XS implementation of List::UtilsBy
i lsb-base - Linux Standard Base init script functionality
i lsb-release - Linux Standard Base version reporting utility
r


====


root@mcg-pac-03:~# cat /etc/apt/sources.list
#

deb http://ftp.us.debian.org/debian/ stable main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free
#deb http://security.debian.org/debian-security stable/updates main 
contrib non-free
#deb-src http://security.debian.org/debian-security stable/updates main 
contrib non-free

# stretch-updates, previously known as 'volatile'
deb http://ftp.us.debian.org/debian/ stable-updates main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stable-updates main contrib 
non-free


----

root@mcg-pac-03:~# aptitude search lsb
p   liblist-utilsby-perl                             - higher-order list 
utility functions
p   liblist-utilsby-xs-perl                          - XS implementation 
of List::UtilsBy
v   lsb -
i   lsb-base                                         - Linux Standard 
Base init script functionality
i   lsb-compat                                       - Linux Standard 
Base Compatibility
v   lsb-core -
i A lsb-release                                      - Linux Standard 
Base version reporting utility


Thanks!


-- 

Kent

[toc] | [next] | [standalone]

#211263

On Thu, 2019-07-11 at 13:48 -0500, Kent West wrote:
> Two issues:
>
>
> 1) I have several Debian boxes running as kiosks, and reporting to a
> centralized Quest-branded "Systems Management Appliance" (SMA). With
> a
> recent update to the SMA, the Debian boxes stopped reporting in.
> After
> several weeks, I finally discovered that the installation of
> "lsb-compat" on several of them restored their functionality. Today,
> when I go to install "lsb-compat" on the other's, I find it's no
> longer
> available in Buster. Has it been deprecated? Why? Any ideas how I'm
> going to get my boxes reporting again to the SMA (what does "lsb-
> compat"

******
The Linux Standard Base (http://www.linuxbase.org/) was a standard
core system that third-party applications written for Linux could
depend upon.

This package provides the most minimal layer to be able to install and
run selected legacy LSB packages on Debian.
******

(untested) Maybe temporarily set your sources to old stable or stretch
and pick it up from there (then reset them of course).

I could only guess when you installed on the other boxes it was set to
stable (stretch) which was then stable but is now buster.

[toc] | [prev] | [next] | [standalone]

#211301

On 7/11/19 10:04 PM, Dominic Knight wrote:
> On Thu, 2019-07-11 at 13:48 -0500, Kent West wrote:
>> Two issues:
>>
>>
>> 1) I have several Debian boxes running as kiosks, and reporting to a
>> centralized Quest-branded "Systems Management Appliance" (SMA). With
>> a
>> recent update to the SMA, the Debian boxes stopped reporting in.
>> After
>> several weeks, I finally discovered that the installation of
>> "lsb-compat" on several of them restored their functionality. Today,
>> when I go to install "lsb-compat" on the other's, I find it's no
>> longer
>> available in Buster. Has it been deprecated? Why? Any ideas how I'm
>> going to get my boxes reporting again to the SMA (what does "lsb-
>> compat"
> ******
> The Linux Standard Base (http://www.linuxbase.org/) was a standard
> core system that third-party applications written for Linux could
> depend upon.
>
> This package provides the most minimal layer to be able to install and
> run selected legacy LSB packages on Debian.
> ******
>
> (untested) Maybe temporarily set your sources to old stable or stretch
> and pick it up from there (then reset them of course).
>
> I could only guess when you installed on the other boxes it was set to
> stable (stretch) which was then stable but is now buster.
>

Okay, I've learned something about aptitude.

I added "oldstable" and after an "aptitude update", the older lsb stuff 
became available with an "aptitude search lsb", and I installed 
"lsb-compat". And when I removed "oldstable" and did another "aptitude 
update", the old lsb stuff was still available. That surprised me; I 
thought "aptitude search" would show what was available for downloading, 
but I guess it needs to also remember what is currently installed. And 
if I purge "lsb-compat" and then do another "aptitude search lsb", sure 
enough, the old stuff is now not shown.

Interesting....

So that answers my issue #2.

Back to issue #1:

When I updated the working machine to my current "stable" sources.list, 
the version of Debian on that box went from 9.9 to 10, and even though 
"lsb-compat" remained installed, the communication with my Quest server 
has again gone silent. So apparently I don't need to know what 
lsb-compat does, or how to duplicate that functionality in some way now 
that lsb-compat is (apparently) deprecated, because the problem seems to 
be deeper than that. Although something changed between version 9.9 with 
lsb-compat and version 10 with lsb-compat, that's too general of an 
issue to ask about on this list; I'll have to narrow down more 
specifically what the Quest server is looking for (unless someone just 
knows what might have changed between the two versions that might have 
affected a third-party in this way - not likely).

And finally, yeah, I normally track release names ("potato", "buster", 
etc) in my sources.list files, but for some reason the working machine 
was tracking "stable", so I modified the non-working machine from 
"stretch" to "stable" to make the two machines more similar. I'm 
generally wary of the potential of upgrading to a new version by accident.

Thanks, all!

-- 

Kent

[toc] | [prev] | [next] | [standalone]

#211277

On Thu, 2019-07-11 at 13:48 -0500, Kent West wrote:
[..]
> Today, 
> when I go to install "lsb-compat" on the other's, I find it's no longer 
> available in Buster. Has it been deprecated?

Seems so, Googling for "debian lsb-compat buster" shows...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873090

[...]

>  For completeness:
> 
> root@lib-pac-04:~# cat /etc/apt/sources.list
> #
> 
> 
> deb http://ftp.us.debian.org/debian/ stable main contrib non-free
> deb-src http://ftp.us.debian.org/debian/ stable main contrib non-free
[...]

Well, the 'stable' release changed from 'stretch' to 'buster' a few
days ago, so your systems are possibly now going to be a mix of those
two releases, probably not what you wanted. Really, you want the
codenames of the release you want to run in sources.list, not 'stable'.
Then you can explicitely upgrade to a new release at a time of your
choosing, taking into consideration what the release notes say and
leasons leaned from upgrading one of your systems first.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#211407

NOT REQUIRED READING; this is just a follow-up for documentation 
purposes in case anyone else needs this info from the list archives. 
(TL;DR at bottom)

On 7/11/19 1:48 PM, Kent West wrote:
>
> 1) I have several Debian boxes running as kiosks, and reporting to a 
> centralized Quest-branded "Systems Management Appliance" (SMA). With a 
> recent update to the SMA, the Debian boxes stopped reporting in. After 
> several weeks, I finally discovered that the installation of 
> "lsb-compat" on several of them restored their functionality.

"lsb_compat" installs "/usr/bin/lsb_release", which I believe is 
probably what the SMA relies on for Debian versioning information. Prior 
to installing "lsb_compat" the SMA log files complained about about not 
finding a major and a minor number for Debian. After installing 
"lsb_compat", the complaint went away, and the machines were restored to 
their functionality.

However, now with the machines upgraded to Debian 10 (Buster), 
"/usr/bin/lsb_release -a" reports the Debian version as 10 rather than 
as 10.0, and apparently the SMA expects that minor number as well as the 
major number.

I would hit the vendor up for a fix, but they don't support Debian (they 
do support Ubuntu 18.04; once they support the next release of Ubuntu, 
that'll probably fix it for Buster, also). In the meantime, I'm trying 
to chase down a fix.

Looking at "/usr/bin/lsb_release", I see that the function call that 
returns the data I need comes from the Python 3 module 
"/usr/share/pyshared/lsb_release.py". That function call is 
"get_distro_information()", which in turn relies on "get_os_release()", 
or if that doesn't have the release info, then "guess_debian_release()" 
(both of which are in this same module file).

The "get_os_release()" function has a comment that says, "# Whatever is 
guessed above can be overridden in /usr/lib/os-release by derivatives", 
which leads me to believe that this file, "/usr/lib/os-release", is the 
canonical location for specifying the version of Debian installed.

So I changed this line in that file:

VERSION_ID="10"

to

VERSION_ID="10.0"

and now "lsb_release -a" reports Debian to be at version 10.0.

However, that didn't solve the issue; apparently the SMA release on the 
"Description:" line of output from "lsb_release -a" instead of the 
"Release:" line. And changing the second VERSION_ID line in 
"/usr/lib/os-release" doesn't change that "Description:" line.

However, I'm getting closer.

Looking again at "/usr/lib/os-release", I change this line:

PRETTY_NAME="Debian GNU/Linux 10 (buster)"

to

PRETTY_NAME="Debian GNU/Linux 10.0 (buster)"

and voila! My SMA once again can see my Debian box. I'm not sure what 
side effects will occur from changing this file (I changed the two 
VERSION_ID lines back to what they were originally), but I'm guessing 
that changing the "pretty name" is cosmetic only (unless other apps rely 
on it like the SMA relies on it, pfft).


TL;DR

Change the "PRETTY_NAME" line in "/usr/lib/os-release" from "10" to "10.0".


-- 

Kent

[toc] | [prev] | [next] | [standalone]

#211408

On Mon, Jul 15, 2019 at 09:15:19AM -0500, Kent West wrote:
>However, that didn't solve the issue; apparently the SMA release on 
>the "Description:" line of output from "lsb_release -a" instead of the 
>"Release:" line. 

And now we see one of the big reasons why the LSB initiative failed: the 
vendors didn't write to the spec, they just wrote to what worked on 
their preferred distro. Which is basically what they did without 
LSB--making the effort of implementing LSB a complete waste of time.

[toc] | [prev] | [next] | [standalone]

#211410

On 7/15/19 9:25 AM, Michael Stone wrote:
> On Mon, Jul 15, 2019 at 09:15:19AM -0500, Kent West wrote:
>> However, that didn't solve the issue; apparently the SMA release on 
>> the "Description:" line of output from "lsb_release -a" instead of 
>> the "Release:" line. 
>
> And now we see one of the big reasons why the LSB initiative failed: 
> the vendors didn't write to the spec, they just wrote to what worked 
> on their preferred distro. Which is basically what they did without 
> LSB--making the effort of implementing LSB a complete waste of time.


I'm glad you posted this, for three reasons:

1) it allowed me to realize I wrote "the SMA release" instead of "the 
SMA relies". I hate when I produce unintelligible output.

2) It answers my question of why Debian seems to have deprecated LSB. I 
don't know anything about programming to the LSB spec, but your comment 
makes it clear that Quest (<-- a little negative publicity there) failed 
to support the LSB properly, and vendors like that have made, as you 
say, "the effort of implementing LSB a complete waste of time."

3) It spurs me to ask: So, if not via LSB, what is the canonical way to 
programatically determine the version of an installed Debian setup?

Thanks!

-- 

Kent

[toc] | [prev] | [next] | [standalone]

#211411

On Mon, Jul 15, 2019 at 02:34:39PM -0500, Kent West wrote:
> 3) It spurs me to ask: So, if not via LSB, what is the canonical way to
> programatically determine the version of an installed Debian setup?

cat /etc/debian_version

[toc] | [prev] | [next] | [standalone]

#211412

> 3) It spurs me to ask: So, if not via LSB, what is the canonical way to
> programatically determine the version of an installed Debian setup?

Why would a program want to know?

That won't give it very much information, since the system may very
well have a mix of packages from different Debian releases plus other
packages from other repositories, plus hand-installed packages, without
talking about the fact that the Debian version number doesn't tell
you which packages are installed.


        Stefan

[toc] | [prev] | [next] | [standalone]

#211413

On 7/15/19 2:48 PM, Stefan Monnier wrote:
>> 3) It spurs me to ask: So, if not via LSB, what is the canonical way to
>> programatically determine the version of an installed Debian setup?
> Why would a program want to know?
>
> That won't give it very much information, since the system may very
> well have a mix of packages from different Debian releases plus other
> packages from other repositories, plus hand-installed packages, without
> talking about the fact that the Debian version number doesn't tell
> you which packages are installed.
>
>
>          Stefan


Well, in this particular case, the Quest SMA is a Systems Management 
Appliance, which provides management and data-collection capabilities of 
devices on a network. When a sysadmin wants to use the SMA to find out 
about PCs on the network, particularly Linux PCs, particularly Debian 
PCs, particularly Debian PCs of a certain version, that SMA itself must 
first know that information. That's part of what the SMA does; it goes 
and and collects information about the devices. In this case, it wanted 
to know the Debian version, both major and minor version. Granted, to 
you and me, perhaps that particular information is not very informative, 
but it seems to mean something to the Suits (and to the programmers of 
the Quest SMA). Go figure.


-- 

Kent

[toc] | [prev] | [next] | [standalone]

#211414

On Mon, Jul 15, 2019 at 03:09:28PM -0500, Kent West wrote:
> Well, in this particular case, the Quest SMA is a Systems Management
> Appliance, which provides management and data-collection capabilities of
> devices on a network. When a sysadmin wants to use the SMA to find out about
> PCs on the network, particularly Linux PCs, particularly Debian PCs,
> particularly Debian PCs of a certain version, that SMA itself must first
> know that information. That's part of what the SMA does; it goes and and
> collects information about the devices.

And yet it can't even figure out how to see the version number of a
Debian GNU/Linux system.  Are you sure you want to continue using this
product?  It doesn't sound very capable.

[toc] | [prev] | [next] | [standalone]

#211415

[Multipart message — attachments visible in raw view] — view raw

Kent West (12019-07-15):
> - They plainly state that they support Ubuntu 18.04, but not Debian.

So, did I get this right: this is a software, if you install it on
Ubuntu 18.04, it can tell you on what OS and version it runs, REMOTELY.
Is that it?

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#211419

On 7/15/19 3:54 PM, Nicolas George wrote:
> Kent West (12019-07-15):
>> - They plainly state that they support Ubuntu 18.04, but not Debian.
> So, did I get this right: this is a software, if you install it on
> Ubuntu 18.04, it can tell you on what OS and version it runs, REMOTELY.
> Is that it?
>

Yes.

And a host of other information: system name, location, model, ip, 
netmask, mac address, RAM, drives, OS, uptime, timezone, user name, 
Motherboard primary and secondary bus types, processors/cores, 
architecture, whether it's a virtual device or not, sound cards, video 
cards, NICs, BIOS version, BIOS serial number, printers installed, drive 
encryption, the names of all 1293 programs that are installed on this 
particular machine I'm currently looking at, and their versions, 
detailed information about those apps in many cases, track licenses, 
show what's been installed/uninstalled since the last inventory, and how 
many hours ago that inventory was, currently-running processes, patching 
status, etc etc.

And it can push software (or remove, update, tweak it).

It can run other maintenance type tasks (add a user to sudo; move files; 
run scripts).

And it does this for not just Ubuntu 18.04, but if you get all your 
details right, also Debian 10. And Linux is the step-child; it focuses 
mostly Windows and Macs.

It can do these things to one machine, or a dozen that fit a certain set 
of criteria, or all of the machines on the network.

It can also report on other devices, such as smart-phones hitting our 
wireless network, or printers on the LAN, or AP devices, or smart 
projectors, Chrome boxes, etc, although it can't actively manage those 
things.

It also has helpdesk software built in (which we don't use), and license 
compliance capability (which we'll probably use eventually), and a 
self-serve customer-facing portal for installing software, installing 
printers, trouble-shooting, etc.

It'll run reports for the Suits - how many copies of Software XYZ, 
version a.b, do we have?

It's got a lot of functionality. It's got a lot of "issues" to go with 
that functionality, but for such a big range of functions, issues should 
be expected.


-- 

Kent

[toc] | [prev] | [next] | [standalone]

#211417

On 7/15/19 3:15 PM, Greg Wooledge wrote:
> On Mon, Jul 15, 2019 at 03:09:28PM -0500, Kent West wrote:
>> Well, in this particular case, the Quest SMA is a Systems Management
>> Appliance, which provides management and data-collection capabilities of
>> devices on a network. When a sysadmin wants to use the SMA to find out about
>> PCs on the network, particularly Linux PCs, particularly Debian PCs,
>> particularly Debian PCs of a certain version, that SMA itself must first
>> know that information. That's part of what the SMA does; it goes and and
>> collects information about the devices.
> And yet it can't even figure out how to see the version number of a
> Debian GNU/Linux system.  Are you sure you want to continue using this
> product?  It doesn't sound very capable.
>

- Wasn't my choice.

- Every product has short-comings (and many support far fewer platforms; 
I'm thankful Quest works with Linux at all).

- They plainly state that they support Ubuntu 18.04, but not Debian. It 
worked fine on Debian until Debian changed with Buster. Had I stuck with 
Stretch, there would have been no problem. When they support the next 
version of Ubuntu, there will probably again be no problem. As it is, it 
still works; it just took some effort from me to get their product to 
work with an up-front-stated unsupported Debian.


-- 

Kent

[toc] | [prev] | [next] | [standalone]

#211418

On Monday 15 July 2019 16:15:23 Greg Wooledge wrote:

> On Mon, Jul 15, 2019 at 03:09:28PM -0500, Kent West wrote:
> > Well, in this particular case, the Quest SMA is a Systems Management
> > Appliance, which provides management and data-collection
> > capabilities of devices on a network. When a sysadmin wants to use
> > the SMA to find out about PCs on the network, particularly Linux
> > PCs, particularly Debian PCs, particularly Debian PCs of a certain
> > version, that SMA itself must first know that information. That's
> > part of what the SMA does; it goes and and collects information
> > about the devices.
>
> And yet it can't even figure out how to see the version number of a
> Debian GNU/Linux system.  Are you sure you want to continue using this
> product?  It doesn't sound very capable.

My between the lines interpretation is that it was born from an edict 
from someone on high, probably a freshly minted MBA, that demands you do 
your job with M$ software, so when it all goes south, he's got somebody 
to blame and/or sue. Those folks on the second floor doing the sales, 
are aghast to learn that the cash cow on the ground floor doing all the 
work, is running on linux, and has been for 20 years.  BSOD's cost 
money, and can bankrupt good services. Just ask TWC. When digital 
occurred in 2008, they built out a system that put then in every market 
in the USA. But they demanded total control to the extent we weren't 
allowed keys to the little building they put up in the back yard.  Then 
they filled the building up with windows boxes.  And if one BSOD'd, it 
took them at least a day to arrive and reboot it. So we had a BSOD on 
the air at least 10% of the time on our second channel.  Needless to 
say, when that contract ran out, it was not renewed.  Do they even have 
a web page today? Yes, but no radar images for the unwashed.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#211416

On Monday 15 July 2019 16:09:28 Kent West wrote:

> On 7/15/19 2:48 PM, Stefan Monnier wrote:
> >> 3) It spurs me to ask: So, if not via LSB, what is the canonical
> >> way to programatically determine the version of an installed Debian
> >> setup?
> >
> > Why would a program want to know?
> >
> > That won't give it very much information, since the system may very
> > well have a mix of packages from different Debian releases plus
> > other packages from other repositories, plus hand-installed
> > packages, without talking about the fact that the Debian version
> > number doesn't tell you which packages are installed.
> >
> >
> >          Stefan
>
> Well, in this particular case, the Quest SMA is a Systems Management
> Appliance, which provides management and data-collection capabilities
> of devices on a network. When a sysadmin wants to use the SMA to find
> out about PCs on the network, particularly Linux PCs, particularly
> Debian PCs, particularly Debian PCs of a certain version, that SMA
> itself must first know that information. That's part of what the SMA
> does; it goes and and collects information about the devices. In this
> case, it wanted to know the Debian version, both major and minor
> version. Granted, to you and me, perhaps that particular information
> is not very informative, but it seems to mean something to the Suits
> (and to the programmers of the Quest SMA). Go figure.

I'd assume their rational is to build for that minimal system, probably 
because they want a red line to draw support at.  Said another way, if 
you've got so-and-so's database because thats what needed to get the job 
done, they can take your money, then say "Oh, we don't support that".

We all are well aware that the chances of an linux install, done from an 
image or installer, has a vanishingly small chance of being a bit for 
bit copy 2 weeks later unless its been powered down for those 2 weeks.

Do we really need that?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#211423

Hello,

On Mon, Jul 15, 2019 at 03:48:50PM -0400, Stefan Monnier wrote:
> > 3) It spurs me to ask: So, if not via LSB, what is the canonical way to
> > programatically determine the version of an installed Debian setup?
> 
> Why would a program want to know?

Being able to programmatically query the status of a system is the
cornerstone of configuration management. Some products handle it
better than others.

I've never heard of OP's product but well known solutions in this
space include Puppet and Ansible, which have the advantage of being
open source.

Ansible does not suffer from this confusion over the version number
of "10":

$ ansible backup4*,limoncello* -m setup -a 'filter=ansible_distribution*'
backup4.bitfolk.com | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Debian", 
        "ansible_distribution_file_parsed": true, 
        "ansible_distribution_file_path": "/etc/os-release", 
        "ansible_distribution_file_variety": "Debian", 
        "ansible_distribution_major_version": "9", 
        "ansible_distribution_release": "stretch", 
        "ansible_distribution_version": "9.9"
    }, 
    "changed": false
}
limoncello.bitfolk.com | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Debian", 
        "ansible_distribution_file_parsed": true, 
        "ansible_distribution_file_path": "/etc/os-release", 
        "ansible_distribution_file_variety": "Debian", 
        "ansible_distribution_major_version": "10", 
        "ansible_distribution_release": "buster", 
        "ansible_distribution_version": "10.0"
    }, 
    "changed": false
}

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#211420

[Multipart message — attachments visible in raw view] — view raw

On Lu, 15 iul 19, 09:15:19, Kent West wrote:
> 
> However, now with the machines upgraded to Debian 10 (Buster),
> "/usr/bin/lsb_release -a" reports the Debian version as 10 rather than as
> 10.0, and apparently the SMA expects that minor number as well as the major
> number.

This issue will most likely disappear once Debian releases the first 
point-release for buster (i.e. 10.1).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#211424

On Tue, Jul 16, 2019 at 09:42:54AM +0300, Andrei POPESCU wrote:
> This issue will most likely disappear once Debian releases the first 
> point-release for buster (i.e. 10.1).

I had that thought, but I also had another thought:

The product may perform a version comparison using something like this
(bash syntax):

  if [[ "$version" > 8 ]]; then ...

Hilarity ensures.  (This syntax does a string comparison, not an integer
comparison, so "10" is less than "8".)

Even if this particular product doesn't have this bug, I bet something
out there will.  Similar bugs are easily achieved in most weakly-typed
scripting languages (awk, Tcl, perl, ...).  They show up all the time.
I've done it myself.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web