Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #205561 > unrolled thread
| Started by | Pierre Couderc <pierre@couderc.eu> |
|---|---|
| First post | 2019-02-21 09:10 +0100 |
| Last post | 2019-02-24 20:20 +0100 |
| Articles | 20 on this page of 72 — 25 participants |
Back to article view | Back to linux.debian.user
Why /usr/sbin is not in my root $PATH ? Pierre Couderc <pierre@couderc.eu> - 2019-02-21 09:10 +0100
Re: Why /usr/sbin is not in my root $PATH ? Reco <recoverym4n@enotuniq.net> - 2019-02-21 09:20 +0100
Re: Why /usr/sbin is not in my root $PATH ? Pierre Couderc <pierre@couderc.eu> - 2019-02-21 09:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-21 14:30 +0100
Re: Why /usr/sbin is not in my root $PATH ? Reco <recoverym4n@enotuniq.net> - 2019-02-21 14:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Reco <recoverym4n@enotuniq.net> - 2019-02-21 19:20 +0100
Re: Why /usr/sbin is not in my root $PATH ? ghe <ghe@slsware.net> - 2019-02-21 19:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-21 20:00 +0100
Re: Why /usr/sbin is not in my root $PATH ? ghe <ghe@slsware.net> - 2019-02-21 21:10 +0100
Re: Why /usr/sbin is not in my root $PATH ? Ric Moore <wayward4now@gmail.com> - 2019-02-21 21:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Brad Rogers <brad@fineby.me.uk> - 2019-02-21 14:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-21 14:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Brad Rogers <brad@fineby.me.uk> - 2019-02-21 14:50 +0100
Re: Why /usr/sbin is not in my root $PATH ? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-21 17:30 +0100
Re: Why /usr/sbin is not in my root $PATH ? Reco <recoverym4n@enotuniq.net> - 2019-02-21 18:20 +0100
Re: Why /usr/sbin is not in my root $PATH ? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-21 18:50 +0100
Re: Why /usr/sbin is not in my root $PATH ? Andrei POPESCU <andreimpopescu@gmail.com> - 2019-05-26 10:50 +0200
Re: Why /usr/sbin is not in my root $PATH ? ghe <ghe@slsware.net> - 2019-02-21 19:20 +0100
Re: Why /usr/sbin is not in my root $PATH ? Reco <recoverym4n@enotuniq.net> - 2019-02-21 19:30 +0100
Re: Why /usr/sbin is not in my root $PATH ? ghe <ghe@slsware.net> - 2019-05-26 15:50 +0200
Re: Why /usr/sbin is not in my root $PATH ? Andy Smith <andy@strugglers.net> - 2019-05-27 04:20 +0200
Re: Why /usr/sbin is not in my root $PATH ? Andrei POPESCU <andreimpopescu@gmail.com> - 2019-05-27 07:20 +0200
Re: Why /usr/sbin is not in my root $PATH ? Andy Smith <andy@strugglers.net> - 2019-05-27 07:30 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Jason <electron@emypeople.net> - 2019-05-30 00:00 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andy Smith <andy@strugglers.net> - 2019-05-30 01:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Cindy Sue Causey <butterflybytes@gmail.com> - 2019-05-30 03:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andy Smith <andy@strugglers.net> - 2019-05-30 04:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Reco <recoverym4n@enotuniq.net> - 2019-05-30 08:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andy Smith <andy@strugglers.net> - 2019-05-30 23:30 +0200
Re: Ping as normal user Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-31 05:00 +0200
Re: Ping as normal user rhkramer@gmail.com - 2019-05-31 13:20 +0200
Re: Ping as normal user Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-05-31 13:30 +0200
Gmail problems (was Re: Ping as normal user) rhkramer@gmail.com - 2019-05-31 15:10 +0200
Re: Gmail problems (was Re: Ping as normal user) mick crane <mick.crane@gmail.com> - 2019-05-31 15:40 +0200
Re: Gmail problems (was Re: Ping as normal user) Brian <ad44@cityscape.co.uk> - 2019-05-31 21:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Gene Heskett <gheskett@shentel.net> - 2019-05-30 05:30 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andrei POPESCU <andreimpopescu@gmail.com> - 2019-05-31 08:40 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-05-31 11:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-31 15:00 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andrei POPESCU <andreimpopescu@gmail.com> - 2019-06-01 07:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Curt <curty@free.fr> - 2019-05-30 11:20 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-30 14:40 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Curt <curty@free.fr> - 2019-05-30 15:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-30 15:20 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Curt <curty@free.fr> - 2019-05-30 15:30 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-30 16:30 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Reco <recoverym4n@enotuniq.net> - 2019-05-30 16:40 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-30 17:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Reco <recoverym4n@enotuniq.net> - 2019-05-30 17:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andrei POPESCU <andreimpopescu@gmail.com> - 2019-05-31 09:00 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-31 09:20 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Reco <recoverym4n@enotuniq.net> - 2019-05-31 10:30 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-31 12:20 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Reco <recoverym4n@enotuniq.net> - 2019-05-31 13:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-31 14:30 +0200
Re: Ping as normal user Sven Hartge <sven@svenhartge.de> - 2019-05-30 17:50 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Reco <recoverym4n@enotuniq.net> - 2019-05-30 16:30 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-30 17:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Curt <curty@free.fr> - 2019-05-30 18:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-30 18:40 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Jason <electron@emypeople.net> - 2019-05-31 16:10 +0200
Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) Andy Smith <andy@strugglers.net> - 2019-05-31 16:40 +0200
Re: Why /usr/sbin is not in my root $PATH ? Andrei POPESCU <andreimpopescu@gmail.com> - 2019-05-26 10:50 +0200
Re: Why /usr/sbin is not in my root $PATH ? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2019-02-21 17:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? Mart van de Wege <mvdwege@gmail.com> - 2019-02-23 15:50 +0100
Re: Why /usr/sbin is not in my root $PATH ? Tixy <tixy@yxit.co.uk> - 2019-02-23 17:40 +0100
Re: Why /usr/sbin is not in my root $PATH ? John Hasler <jhasler@newsguy.com> - 2019-02-23 18:30 +0100
Re: Why /usr/sbin is not in my root $PATH ? Mart van de Wege <mvdwege@gmail.com> - 2019-02-24 09:50 +0100
Re: Why /usr/sbin is not in my root $PATH ? Curt <curty@free.fr> - 2019-02-24 10:00 +0100
[OT] Re: Why /usr/sbin is not in my root $PATH ? David Wright <deblis@lionunicorn.co.uk> - 2019-02-24 16:40 +0100
Re: [OT] Re: Why /usr/sbin is not in my root $PATH ? Martin Smith <tech@smithproductions.co.uk> - 2019-02-24 19:10 +0100
Re: [OT] Re: Why /usr/sbin is not in my root $PATH ? David Wright <deblis@lionunicorn.co.uk> - 2019-02-24 20:20 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2019-05-30 11:20 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3po6-44J-3@gated-at.bofh.it> |
| In reply to | #209398 |
On 2019-05-29, Andy Smith <andy@strugglers.net> wrote: > > How did you install this system? Because /bin/ping is supposed to > come with file capabilities such that the user can allow it to do > what it needs to do (this is part of what 'dpkg-reconfigure > iputils-ping' restores). So it would be interesting to know how the > system was installed in case there is a general theme for those who > never got those capabilities. There is a bug related to this imbroglio: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721 (libcap2-bin is recommended but is not a dependancy of iputils-ping, because "iputils-ping, as priority 'important', cannot declare a dependency on libcap2-bin, which is priority 'optional'"). > One other person in this thread said they used (a script which > ultimately uses) debootstrap. > > Cheers, > Andy > > -- “Decisions are never really made – at best they manage to emerge, from a chaos of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-05-30 14:40 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3svD-5WV-9@gated-at.bofh.it> |
| In reply to | #209412 |
On Thu, May 30, 2019 at 09:11:44AM -0000, Curt wrote: > There is a bug related to this imbroglio: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721 > (libcap2-bin is recommended but is not a dependancy of iputils-ping, > because "iputils-ping, as priority 'important', cannot declare a > dependency on libcap2-bin, which is priority 'optional'"). But libcap2-bin is priority important in both stretch and buster.
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2019-05-30 15:10 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3sYF-6na-1@gated-at.bofh.it> |
| In reply to | #209415 |
On 2019-05-30, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > On Thu, May 30, 2019 at 09:11:44AM -0000, Curt wrote: >> There is a bug related to this imbroglio: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721 >> (libcap2-bin is recommended but is not a dependancy of iputils-ping, >> because "iputils-ping, as priority 'important', cannot declare a >> dependency on libcap2-bin, which is priority 'optional'"). > > But libcap2-bin is priority important in both stretch and buster. > > Why is my Stretch apt-cache command telling me it's priority optional? Or am I once again missing some essential thing? curty@einstein:~$ apt-cache show libcap2-bin Package: libcap2-bin Source: libcap2 Version: 1:2.25-1 Installed-Size: 85 Maintainer: Christian Kastner <ckk@debian.org> Architecture: amd64 Replaces: libcap-bin Depends: libc6 (>= 2.14), libcap2 (>= 1:2.10) Recommends: libpam-cap Breaks: libcap-bin Description-en: POSIX 1003.1e capabilities (utilities) Libcap implements the user-space interfaces to the POSIX 1003.1e capabilities available in Linux kernels. These capabilities are a partitioning of the all powerful root privilege into a set of distinct privileges. . This package contains additional utilities. Description-md5: f223f06c6e812dc45d4b21cbd8163d36 Multi-Arch: foreign Homepage: http://sites.google.com/site/fullycapable/ Tag: admin::configuring, implemented-in::c, interface::commandline, role::program, scope::utility Section: utils Priority: optional Filename: pool/main/libc/libcap2/libcap2-bin_2.25-1_amd64.deb Size: 26490 MD5sum: cf46bb9dd77bd949226b90f735d52f33 SHA256: 8b6a70886d13a53e35bfacebab1bc869a09f405783f734835f313460e80be94e -- “Decisions are never really made – at best they manage to emerge, from a chaos of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-05-30 15:20 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3t8l-6qJ-1@gated-at.bofh.it> |
| In reply to | #209417 |
On Thu, May 30, 2019 at 01:00:19PM -0000, Curt wrote: > On 2019-05-30, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > > But libcap2-bin is priority important in both stretch and buster. > > Why is my Stretch apt-cache command telling me it's priority optional? > Or am I once again missing some essential thing? Uh... arc3:~$ dpkg -s libcap2-bin | grep -i priority Priority: important arc3:~$ apt-cache show libcap2-bin | grep -i priority Priority: optional OK, I have no freaking idea what this means.
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2019-05-30 15:30 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3ti1-6un-3@gated-at.bofh.it> |
| In reply to | #209418 |
On 2019-05-30, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > On Thu, May 30, 2019 at 01:00:19PM -0000, Curt wrote: >> On 2019-05-30, Greg Wooledge <wooledg@eeg.ccf.org> wrote: >> > But libcap2-bin is priority important in both stretch and buster. >> >> Why is my Stretch apt-cache command telling me it's priority optional? >> Or am I once again missing some essential thing? > > Uh... > > arc3:~$ dpkg -s libcap2-bin | grep -i priority > Priority: important > arc3:~$ apt-cache show libcap2-bin | grep -i priority > Priority: optional > > OK, I have no freaking idea what this means. > > curty@einstein:~$ dpkg -s libcap2-bin | grep -i priority Priority: optional At least I'm optionally consistent. ;-) -- “Decisions are never really made – at best they manage to emerge, from a chaos of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-05-30 16:30 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3ue5-75Y-1@gated-at.bofh.it> |
| In reply to | #209418 |
On Thu, May 30, 2019 at 05:19:49PM +0300, Reco wrote: > "dpkg -s" gets package state from /var/lib/dpkg/status. > "apt-cache" also uses /var/lib/apt/lists/*. > > Basically your result tells that libcap2-bin is "optional" from the > repository POV, but your local package database thinks it's "important". > > And in this case I trust the repository and have to assume that your > local package database is somehow corrupt. arc3:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status Package: libcap2-bin Status: install ok installed Priority: important wooledg:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status Package: libcap2-bin Status: install ok installed Priority: important wooledg:~$ ssh root@megview5 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status" root@megview5's password: Package: libcap2-bin Status: install ok installed Priority: important wooledg:~$ ssh svr4 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status" wooledg@svr4's password: Package: libcap2-bin Status: install ok installed Priority: important oledg:~$ ssh meglin2 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status" wooledg@meglin2's password: Package: libcap2-bin Status: install ok installed Priority: optional meglin2 is jessie. wooledg is buster. The others are stretch.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2019-05-30 16:40 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3unL-79A-3@gated-at.bofh.it> |
| In reply to | #209421 |
Hi. On Thu, May 30, 2019 at 10:26:29AM -0400, Greg Wooledge wrote: > On Thu, May 30, 2019 at 05:19:49PM +0300, Reco wrote: > > "dpkg -s" gets package state from /var/lib/dpkg/status. > > "apt-cache" also uses /var/lib/apt/lists/*. > > > > Basically your result tells that libcap2-bin is "optional" from the > > repository POV, but your local package database thinks it's "important". > > > > And in this case I trust the repository and have to assume that your > > local package database is somehow corrupt. > > arc3:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status > Package: libcap2-bin > Status: install ok installed > Priority: important > > wooledg:~$ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status > Package: libcap2-bin > Status: install ok installed > Priority: important > > wooledg:~$ ssh root@megview5 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status" > root@megview5's password: > Package: libcap2-bin > Status: install ok installed > Priority: important > > wooledg:~$ ssh svr4 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status" > wooledg@svr4's password: > Package: libcap2-bin > Status: install ok installed > Priority: important > > oledg:~$ ssh meglin2 "grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status" > wooledg@meglin2's password: > Package: libcap2-bin > Status: install ok installed > Priority: optional > > meglin2 is jessie. wooledg is buster. The others are stretch. Yep. But for me it's (stretch): $ grep -A2 'Package: libcap2-bin' /var/lib/dpkg/status Package: libcap2-bin Status: install ok installed Priority: optional Reco
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-05-30 17:10 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3uQO-7zC-7@gated-at.bofh.it> |
| In reply to | #209423 |
I asked on IRC, and got this answer: The archive (Packages) and individual .debs can disagree on Priority. It's mostly a field that has no meaning these days. I'm not 100% sure how to interpret that. Are different mirrors giving out different Packages files with different Priority settings? Someone who's affected by the missing capabilities on ping might want to investigate more closely, or add some info to bug #780721. Adrian talked about libcap2-bin being changed to "Priotity: important" at some point in the future (relative to 2016), so maybe that has already happened. I'm not sure how to *find out* whether that has happened, since we can't even figure out how to view the actual Priority. Or, if the Priority "mostly ... has no meaning", then whatever was stopping Adrian from acting in 2016 might no longer be a roadblock.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2019-05-30 17:50 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3vtv-7NY-1@gated-at.bofh.it> |
| In reply to | #209425 |
Hi. On Thu, May 30, 2019 at 11:08:22AM -0400, Greg Wooledge wrote: > I asked on IRC, and got this answer: > > The archive (Packages) and individual .debs can disagree on Priority. It's > mostly a field that has no meaning these days. > > I'm not 100% sure how to interpret that. Are different mirrors giving > out different Packages files with different Priority settings? Now that you mention it - [1]. A mirror can override a package priority, that's true. I don't know if http://ftp.debian.org/debian/indices/ is mirrored too, along with the usual Release files and *debs. It can explain this discrepancy if it's true. The question is - which Priority goes into the package database on package install? That one from the package itself, or the one from the mirror? > Someone who's affected by the missing capabilities on ping might want > to investigate more closely, or add some info to bug #780721. Adrian > talked about libcap2-bin being changed to "Priotity: important" at some > point in the future (relative to 2016), so maybe that has already happened. It sure did not happen here. > I'm not sure how to *find out* whether that has happened, since we can't > even figure out how to view the actual Priority. Or, if the Priority > "mostly ... has no meaning", then whatever was stopping Adrian from acting > in 2016 might no longer be a roadblock. In the context of the original deboostrap behaviour - it's simple. debootstrap installs barebones to produce a working apt, and uses it to install the rest of the packages. apt trusts the mirror (it would be counterproductive to download and analyze every package just to extract their Priority and Depends), hence mirror's priority wins here. Reco [1] https://wiki.debian.org/FtpMaster/Override
[toc] | [prev] | [next] | [standalone]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2019-05-31 09:00 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3JG9-8hd-5@gated-at.bofh.it> |
| In reply to | #209429 |
[Multipart message — attachments visible in raw view] — view raw
On Jo, 30 mai 19, 18:43:05, Reco wrote: > Hi. > > On Thu, May 30, 2019 at 11:08:22AM -0400, Greg Wooledge wrote: > > I asked on IRC, and got this answer: > > > > The archive (Packages) and individual .debs can disagree on Priority. It's > > mostly a field that has no meaning these days. > > > > I'm not 100% sure how to interpret that. Are different mirrors giving > > out different Packages files with different Priority settings? > > Now that you mention it - [1]. > A mirror can override a package priority, that's true. This would suggest you can get different results depending on mirror used, which is not the case. The priority is set in the central archive, which is then mirrored. > I don't know if http://ftp.debian.org/debian/indices/ is mirrored too, > along with the usual Release files and *debs. It can explain this > discrepancy if it's true. > > The question is - which Priority goes into the package database on > package install? That one from the package itself, or the one from the > mirror? APT and debootstrap will definitely use the archive view on priorities when deciding which packages to download and install. dpkg on the other hand is probably using the information inside the package (debian/control) for its database, but probably not much else. This is the most obvious way one could end up with different results. The other way would be if the archive priority was changed between different installs. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2019-05-31 09:20 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3JZw-bG-5@gated-at.bofh.it> |
| In reply to | #209441 |
Hi,
Andrei POPESCU wrote:
> The other way would be if the archive priority was changed between
> different installs.
This has happened in april 2016 (maybe related to bug 780721 ?)
"d/control: Increase Priority of libcap2{,-bin} to important"
https://salsa.debian.org/debian/libcap2/commit/a3f0fbccfa946b6895da1b3521849d04ccf8da0f
and again four months ago
"d/control: Drop Priority of libcap2"
https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d
(The latter is not yet in the released package's control file.)
So one maintainer already adapted to the new policy rules.
But
https://salsa.debian.org/debian/iputils/raw/master/debian/control
still has the hunchbacked gesture of recommending an actually necessary
dependency:
Package: iputils-ping
...
Recommends: libcap2-bin
...
Package: iputils-arping
...
Recommends: libcap2-bin
(I understand that this suffices if your local package management is set
to automatically install recommendations.
I also understand that there is a coarse workaround if libcap2 is missing.)
So bug 780721 is still valid and could now be fixed.
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2019-05-31 10:30 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3L5f-OI-5@gated-at.bofh.it> |
| In reply to | #209442 |
Hi.
On Fri, May 31, 2019 at 09:08:55AM +0200, Thomas Schmitt wrote:
> Andrei POPESCU wrote:
> > The other way would be if the archive priority was changed between
> > different installs.
>
> This has happened in april 2016 (maybe related to bug 780721 ?)
>
> "d/control: Increase Priority of libcap2{,-bin} to important"
> https://salsa.debian.org/debian/libcap2/commit/a3f0fbccfa946b6895da1b3521849d04ccf8da0f
>
> and again four months ago
>
> "d/control: Drop Priority of libcap2"
> https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d
>
> (The latter is not yet in the released package's control file.)
>
> So one maintainer already adapted to the new policy rules.
Ah, that's what is was. That change made into the stable, I've just checked.
> But
> https://salsa.debian.org/debian/iputils/raw/master/debian/control
> still has the hunchbacked gesture of recommending an actually necessary
> dependency:
No, maintainer is correct. Not every filesystem supported by Debian
implements extended attributes needed for capabilities. Off the top of
my head it's NFS and JFFS2. Upgrading this particular dependency leads
only to a dependency bloat, and Default Users™ (i.e. ones that are
installing Recommends by default) aren't affected anyway.
Reco
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2019-05-31 12:20 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3MNH-1TL-3@gated-at.bofh.it> |
| In reply to | #209443 |
Hi, i wrote: > > "d/control: Drop Priority of libcap2" > > https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d Reco wrote: > Ah, that's what is was. That change made into the stable, I've just checked. Not according to the package tracker: oldstable has 1:2.24-8 of march 2015, i.e. before bug 780721. https://tracker.debian.org/media/packages/libc/libcap2/control-1%3A2.24-8 No particular Priority set on lbibcap2-bin stable has 1:2.25-1 of october 2017, i.e. after bug 780721 went to sleep. https://tracker.debian.org/media/packages/libc/libcap2/control-1%3A2.25-1 libcap2-bin gets "Priority: important". testing has 1:2.25-2 of february 2019. https://tracker.debian.org/media/packages/libc/libcap2/control-12.25-2 libcap2-bin still gets "Priority: important". It was accepted in unstable at the very same day as the commit was made which removed the particular Priority in the salsa git repo. The package tracker's source browser says it is still in: https://sources.debian.org/src/libcap2/1:2.25-2/debian/control/#L17 But not to forget, the packages on the Debian mirrors get their priority from the uploading procedure, not necessarily from the debian/control file or the derived .dsc file. All this forth and back might be independent of the maintainer of libcap2. > Not every filesystem supported by Debian > implements extended attributes needed for capabilities. > Off the top of my head it's NFS and JFFS2. It is about the filesystem which holds the /bin directory. I would deem it extra-expert to use a partly incapable filesystem for that. Whatever, the maintainer's reasoning was a then valid quote from the policy manual "Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted." which is now replaced by a contrary statement "The priority of a package should not be increased merely because another higher-priority package depends on it; instead, the tools used to construct Debian installations will correctly handle package dependencies. In particular, this means that C-like libraries will almost never have a priority above optional [...]" The issue of incapable systems was addressed in bug 780721 by maintainer: "The iputils-ping postinst script takes care to handle the case where setcap is either not available or not functional (due e.g. to running on a filesystem that doesn't support capabilities." and bug reporter: "I'm aware we can't use capabilities on the non-Linux kernels yet, but since dpkg allows us to set dependencies per arch or per kernel, I don't see any particular problem adding libcap2-bin as to Depends for Linux." It became not a decisive argument against dependency. > Upgrading this particular dependency leads > only to a dependency bloat, and Default Users™ (i.e. ones that are > installing Recommends by default) aren't affected anyway. Currently the Default User depends on assumptions about local package management which are not obviously related to security. That's a future pitfall which just needs its unintentional cover removed. To skip a security improvement in order to save 111 kB of installed size seems daring. (Size for amd64 taken from end of https://packages.debian.org/unstable/libcap2-bin ) We can expect that the bug reporter, who is working on a colorful bunch of elderly CPU arches, has a different idea of a Default User than us. But shortage of memory and disk capacity surely belong to his considerations. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2019-05-31 13:10 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3NA5-2qG-5@gated-at.bofh.it> |
| In reply to | #209446 |
On Fri, May 31, 2019 at 12:09:19PM +0200, Thomas Schmitt wrote: > > Not every filesystem supported by Debian > > implements extended attributes needed for capabilities. > > Off the top of my head it's NFS and JFFS2. > > It is about the filesystem which holds the /bin directory. I would deem it > extra-expert to use a partly incapable filesystem for that. Please. NFS-for-root is decades old. JFFS2 is wildly popular for DIY solutions. Calling everyone who bought $20 ARM board on AliExpress an 'expert' seems overstretched. > Whatever, the maintainer's reasoning was a then valid quote from the > policy manual ... > It became not a decisive argument against dependency. It's really sad to see a maintainer who resorts to lawyering instead of considering real technical limitations of the "solution" proposed. > > Upgrading this particular dependency leads > > only to a dependency bloat, and Default Users™ (i.e. ones that are > > installing Recommends by default) aren't affected anyway. > > Currently the Default User depends on assumptions about local package > management which are not obviously related to security. So? The end result justifies a current situation. > That's a future pitfall which just needs its unintentional cover removed. The way I see it, the "problematic" package got that Important priority already. A potential pitfall is closed. > To skip a security improvement in order to save 111 kB of installed size > seems daring. (Size for amd64 taken from end of > https://packages.debian.org/unstable/libcap2-bin > ) Replacing a working fallback mechanism with one-size-fits-all "everyone are using ext4 on amd64 and Linux" is hardly an improvement. Reco
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2019-05-31 14:30 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3OPw-37U-9@gated-at.bofh.it> |
| In reply to | #209449 |
Hi,
i wrote:
> > Currently the Default User depends on assumptions about local package
> > management which are not obviously related to security.
> > That's a future pitfall which just needs its unintentional cover removed.
Reco wrote:
> The way I see it, the "problematic" package got that Important priority
> already. A potential pitfall is closed.
The priority in debian/control (and thus .dsc) is scheduled on salsa to be
lowered to "optional" by the next package release.
Whatever, the priority is not the problem with security. The lack of
dependency of iputils-ping on libcap2-bin is the problem.
This lack was justified by policy as of 2016. Soon later the priority of
libcap2-bin was raised to "important", but iputils-ping never made use of
this move.
> Replacing a working fallback mechanism with one-size-fits-all "everyone
> are using ext4 on amd64 and Linux" is hardly an improvement.
The proposal in the bug report would not disable the fallback mechanism
for situations where it is needed. It would only make sure that capable
kernels and filesystems would be able use upstream improvements of iptools.
The installation code in
https://sources.debian.org/src/iputils/3:20180629-2/debian/iputils-ping.postinst
adapts itself to effective success of an attempt to set capabilities:
if command -v setcap > /dev/null; then
if setcap cap_net_raw+ep /bin/ping; then
chmod u-s /bin/ping
else
echo "Setcap failed on /bin/ping, falling back to setuid" >&2
chmod u+s /bin/ping
fi
else
echo "Setcap is not installed, falling back to setuid" >&2
chmod u+s /bin/ping
fi
Safe for Default Users.
My best theory for the problem reported in bug 780721 that a normal user
cannot ping, is that setuid was disabled by mount -o nosuid or -o owner
and that setcap did not work because of his sparse installation.
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Sven Hartge <sven@svenhartge.de> |
|---|---|
| Date | 2019-05-30 17:50 +0200 |
| Subject | Re: Ping as normal user |
| Message-ID | <y3vtv-7NY-9@gated-at.bofh.it> |
| In reply to | #209425 |
Greg Wooledge <wooledg@eeg.ccf.org> wrote: > I asked on IRC, and got this answer: > The archive (Packages) and individual .debs can disagree on Priority. It's > mostly a field that has no meaning these days. > I'm not 100% sure how to interpret that. Are different mirrors giving > out different Packages files with different Priority settings? No, it means the Priority in the package itself is quite often overriden by the archive software and thus the Priority in the Packages-file is different. But all mirrors will have the same content, of course. Grüße, S! -- Sigmentation fault. Core dumped.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2019-05-30 16:30 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3ue5-75Y-3@gated-at.bofh.it> |
| In reply to | #209418 |
Hi. On Thu, May 30, 2019 at 09:10:55AM -0400, Greg Wooledge wrote: > On Thu, May 30, 2019 at 01:00:19PM -0000, Curt wrote: > > On 2019-05-30, Greg Wooledge <wooledg@eeg.ccf.org> wrote: > > > But libcap2-bin is priority important in both stretch and buster. > > > > Why is my Stretch apt-cache command telling me it's priority optional? > > Or am I once again missing some essential thing? > > Uh... > > arc3:~$ dpkg -s libcap2-bin | grep -i priority > Priority: important > arc3:~$ apt-cache show libcap2-bin | grep -i priority > Priority: optional Both show "optional" to me BTW. > OK, I have no freaking idea what this means. strace(1) to the rescue. "dpkg -s" gets package state from /var/lib/dpkg/status. "apt-cache" also uses /var/lib/apt/lists/*. Basically your result tells that libcap2-bin is "optional" from the repository POV, but your local package database thinks it's "important". And in this case I trust the repository and have to assume that your local package database is somehow corrupt. Reco
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2019-05-30 17:10 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3uQN-7zC-1@gated-at.bofh.it> |
| In reply to | #209417 |
Hi, Curt wrote: > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721 > >> (libcap2-bin is recommended but is not a dependancy of iputils-ping, > >> because "iputils-ping, as priority 'important', cannot declare a > >> dependency on libcap2-bin, which is priority 'optional'"). > Why is my Stretch apt-cache command telling me it's priority optional? > Or am I once again missing some essential thing? The statement in bug 780721 seems to be outdated. The priority rules have been changed since then. The package maintainer does not have the last say on this, anyways. -------------------------------------------------------------------- https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control Section and priority are used by front-ends like aptitude when they sort packages and select defaults. Once you upload the package to Debian, the value of these two fields can be overridden by the archive maintainers, in which case you will be notified by email. https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities The priority of a package is determined solely by the functionality it provides directly to the user. The priority of a package should not be increased merely because another higher-priority package depends on it; instead, the tools used to construct Debian installations will correctly handle package dependencies. In particular, this means that C-like libraries will almost never have a priority above optional, since they do not provide functionality directly to users. However, as an exception, the maintainers of Debian installers may request an increase of the priority of a package to resolve installation issues and ensure that the correct set of packages is included in a standard or minimal install. -------------------------------------------------------------------- So the explanation in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#10 iputils-ping, as priority "important", cannot declare a dependency on libcap2-bin, which is priority "optional". is wrong and in direct contradiction to The Policy. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#20 quotes exactly the above policy paragraph as Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. which i cannot see there any more. The change probably happened in august 2017: https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-0-1 2.5 [...] Packages may now depend on packages with a lower priority. [...] Last message in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721 is of february 2016. So this bug could need an update and iputils-ping could now depend on libcap2-bin. As we see in https://tracker.debian.org/media/packages/i/iputils/control-320180629-2 it is not done yet: Package: iputils-ping ... Recommends: libcap2-bin Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2019-05-30 18:10 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3vMS-8aG-19@gated-at.bofh.it> |
| In reply to | #209426 |
On 2019-05-30, Thomas Schmitt <scdbackup@gmx.net> wrote: > > So the explanation in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#10 > > iputils-ping, as priority "important", cannot declare a dependency on > libcap2-bin, which is priority "optional". > > is wrong and in direct contradiction to The Policy. I think it would be more accurate to call the explanation *caduc* (or *caduque*) perhaps. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721#20 > quotes exactly the above policy paragraph as > > Packages must not depend on packages with lower priority values > (excluding build-time dependencies). In order to ensure this, the > priorities of one or more packages may need to be adjusted. > > which i cannot see there any more. > The change probably happened in august 2017: > > https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-0-1 > 2.5 > [...] Packages may now depend on packages with a lower priority. [...] So it seems the reason invoked above is no longer valid due to a change in policy. > Last message in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780721 > is of february 2016. > > > So this bug could need an update and iputils-ping could now depend on > libcap2-bin. > > As we see in > https://tracker.debian.org/media/packages/i/iputils/control-320180629-2 > it is not done yet: > > Package: iputils-ping > ... > Recommends: libcap2-bin > > > Have a nice day :) Ditto. > Thomas > > -- “Decisions are never really made – at best they manage to emerge, from a chaos of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2019-05-30 18:40 +0200 |
| Subject | Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?) |
| Message-ID | <y3wfT-8l5-3@gated-at.bofh.it> |
| In reply to | #209431 |
Hi, i pointed to: > > https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4- 0-1 > > [...] Packages may now depend on packages with a lower priority. [...] Curt wrote: > So it seems the reason invoked above is no longer valid due to a change in > policy. It can be legally called a bug meanwhile, because https://tracker.debian.org/media/packages/i/iputils/control-320180629-2 has Standards-Version: 4.1.4 whereas the policy change was already in 4.0.1. If somebody here feels able to test the policy compliant change of "Depends:", then it would be worth to mail to 780721@bugs.debian.org and to point out that the change is overdue. Binary package iputils-arping has the same Recommends as iputils-ping. So one should check whether the reason is the same. The policy also demands to change libcap2-bin priority to "optional". Currently it is "important", which probably gets overridden by the repo deciders. https://tracker.debian.org/media/packages/libc/libcap2/control-12.25-2 has Standards-Version: 4.3.0 So that would be two maintainers to convince ... YMMV. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web