11:11 a.m.
Hi,
Recently, the value of my PATH variable seems to be messed up:
[asinha@ankur-laptop ~]$ echo $PATH
/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin
/usr/bin is supposed to come before /usr/sbin etc. This makes mock throw
an error:
mock -r fedora-rawhide-x86_64 rebuild
./python-taskreport-1.2.1-1.fc20.src.rpm
ERROR: [Errno 1] Operation not permitted
ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an
unprivileged user.
ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or
manually run /usr/bin/mock to see if that fixes this problem.
Running /usr/bin/mock.. works, of course. I've checked the relevant
places, and everything seems to be in order. The EUID of my user is 1000
too, so there isn't a reason that /etc/profile should place the
directories incorrectly. Would anyone have an hints on correcting this?
There's nothing in my user's .bash_profile or .bashrc that modifies path
either.
I use byobu with a tmux backend, but I don't think that matters. I
opened a separate gnome-terminal without byobu and the EUID is correct
there too.
[asinha@ankur-laptop ~]$ id asinha
uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock)
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
11:15 a.m.
no, in general /usr/sbin is supposed to come before /usr/bin
and any software assuming the opposite has a bug
look what binaries are in /usr/sbin and then you know you really
don't want in general a bad package override them with place
a binary with the same name in /usr/bin
Am 04.05.2014 18:11, schrieb Ankur Sinha:
Recently, the value of my PATH variable seems to be messed up:
> [asinha@ankur-laptop ~]$ echo $PATH
>
/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin
/usr/bin is supposed to come before /usr/sbin etc. This makes mock throw
an error:
> mock -r fedora-rawhide-x86_64 rebuild ./python-taskreport-1.2.1-1.fc20.src.rpm
>
> ERROR: [Errno 1] Operation not permitted
>
> ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an
unprivileged user.
> ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or
manually run /usr/bin/mock to see if that fixes this problem.
Running /usr/bin/mock.. works, of course. I've checked the relevant
places, and everything seems to be in order. The EUID of my user is 1000
too, so there isn't a reason that /etc/profile should place the
directories incorrectly. Would anyone have an hints on correcting this?
There's nothing in my user's .bash_profile or .bashrc that modifies path
either.
I use byobu with a tmux backend, but I don't think that matters. I
opened a separate gnome-terminal without byobu and the EUID is correct
there too.
> [asinha@ankur-laptop ~]$ id asinha
> uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock)
11:54 a.m.
Reindl Harald wrote:
no, in general /usr/sbin is supposed to come before /usr/bin
and any software assuming the opposite has a bug
Am 04.05.2014 18:11, schrieb Ankur Sinha:
> /usr/bin is supposed to come before /usr/sbin etc.
I don't know of any kind of standard that specifies either. Does Posix
specify this for example? Does anyone have a link?
--
Björn Persson
11:59 a.m.
Am 04.05.2014 18:54, schrieb Björn Persson:
Reindl Harald wrote:
> no, in general /usr/sbin is supposed to come before /usr/bin
> and any software assuming the opposite has a bug
>
> Am 04.05.2014 18:11, schrieb Ankur Sinha:
>> /usr/bin is supposed to come before /usr/sbin etc.
I don't know of any kind of standard that specifies either. Does Posix
specify this for example? Does anyone have a link?
normally no software should break independent of that
order because it finds the binary anyways in the path
and it is unlikely in a clean setup that the same
binary exists in both
however, the semantics of /usr/sbin is to contain superuser
binaries which should not be overriden because a binary
with the same name exists in /usr/bin
4:51 p.m.
Reindl Harald wrote:
Am 04.05.2014 18:54, schrieb Björn Persson:
> Reindl Harald wrote:
>> no, in general /usr/sbin is supposed to come before /usr/bin
>> and any software assuming the opposite has a bug
>>
>> Am 04.05.2014 18:11, schrieb Ankur Sinha:
>>> /usr/bin is supposed to come before /usr/sbin etc.
>
> I don't know of any kind of standard that specifies either. Does
> Posix specify this for example? Does anyone have a link?
normally no software should break independent of that
order because it finds the binary anyways in the path
and it is unlikely in a clean setup that the same
binary exists in both
Right, and in the absence of a specified order in PATH it's a bug if
anything depends on *any* particular order.
however, the semantics of /usr/sbin is to contain superuser
binaries which should not be overriden because a binary
with the same name exists in /usr/bin
The Filesystem Hierarchy Standard says only that the sbin directories
are for programs that only system administrators use, and justifies them
with "a good partition between binaries that everyone uses and ones that
are primarily used for administration tasks". The part about not
overriding binaries is your own, personal opinion.
--
Björn Persson
4:58 p.m.
Am 04.05.2014 23:51, schrieb Björn Persson:
Reindl Harald wrote:
> Am 04.05.2014 18:54, schrieb Björn Persson:
>> Reindl Harald wrote:
>>> no, in general /usr/sbin is supposed to come before /usr/bin
>>> and any software assuming the opposite has a bug
>>>
>>> Am 04.05.2014 18:11, schrieb Ankur Sinha:
>>>> /usr/bin is supposed to come before /usr/sbin etc.
>>
>> I don't know of any kind of standard that specifies either. Does
>> Posix specify this for example? Does anyone have a link?
>
> normally no software should break independent of that
> order because it finds the binary anyways in the path
> and it is unlikely in a clean setup that the same
> binary exists in both
Right, and in the absence of a specified order in PATH it's a bug if
anything depends on *any* particular order.
> however, the semantics of /usr/sbin is to contain superuser
> binaries which should not be overriden because a binary
> with the same name exists in /usr/bin
The Filesystem Hierarchy Standard says only that the sbin directories
are for programs that only system administrators use, and justifies them
with "a good partition between binaries that everyone uses and ones that
are primarily used for administration tasks". The part about not
overriding binaries is your own, personal opinion.
no, given that /usr/sbin/iptables is clearly a administrative
command and so there is no valid reason to seek for iptables
in /usr/bin/ nor have it as override is a logical conclusion
if you want to override things /usr/local/bin and /usr/local/sbin
are your friends - however - back to topic:
"Incorrect order of /usr/bin and /usr/sbin in path" is plain wrong
and the PATH /usr/sbin:/usr/bin is in any case correct - period
5:15 p.m.
Once upon a time, Reindl Harald <h.reindl(a)thelounge.net> said:
no, given that /usr/sbin/iptables is clearly a administrative
command and so there is no valid reason to seek for iptables
in /usr/bin/ nor have it as override is a logical conclusion
And there's no reason to look in /usr/sbin for a clearly
non-administrative command like "ls". The non-admin commands will in
most cases vastly outnumber the admin commands, so putting /usr/bin
first just makes sense from a performance standpoint.
"Incorrect order of /usr/bin and /usr/sbin in path" is
plain wrong
and the PATH /usr/sbin:/usr/bin is in any case correct - period
No, /usr/bin is supposed to be before /usr/sbin, because otherwise you
get broken behavior just like the original poster said they had (mock
didn't work but /usr/bin/mock did).
The reason is that there are some programs (like mock) that have an
entry in both directories. The /usr/bin version is a symlink to
consolehelper, that grants additional privileges based on where the user
is connected (console vs. network). This is long-time Fedora (and Red
Hat Linux before that) behavior. I believe consolehelper is being
replaced, but that isn't done yet; after that, the PATH order shouldn't
matter.
To the OP: I'd suggest checking your .bash_profile to see if something
has changed the PATH there.
--
Chris Adams <linux(a)cmadams.net>
9:28 a.m.
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
however, the semantics of /usr/sbin is to contain superuser
binaries which should not be overriden because a binary
with the same name exists in /usr/bin
My memory is that the "s" was more for "static" not
"superuser".
There's some conceptual overlap, static binaries being there to recover
even if your shared libraries are hosed which is normally a "superuser"
kind of operation, but.
- ajax
9:35 a.m.
On 05/05/2014 10:28 AM, Adam Jackson wrote:
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> however, the semantics of /usr/sbin is to contain superuser
> binaries which should not be overriden because a binary
> with the same name exists in /usr/bin
My memory is that the "s" was more for "static" not
"superuser".
There's some conceptual overlap, static binaries being there to recover
even if your shared libraries are hosed which is normally a "superuser"
kind of operation, but.
My recollection is that the "s" in /sbin and /usr/sbin was more
"system"
level management. Things an admin would need but would not usually be
needed by an ordinary user.
Binaries in /bin and /sbin would have been statically linked to aid in
recovering a system in single-user mode when /usr might not be mounted,
in the days when disks were so small that /usr might often be a separate
disk.
--
Kaleb
9:43 a.m.
On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle(a)redhat.com) wrote:
On 05/05/2014 10:28 AM, Adam Jackson wrote:
>On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
>
>>however, the semantics of /usr/sbin is to contain superuser
>>binaries which should not be overriden because a binary
>>with the same name exists in /usr/bin
>
>My memory is that the "s" was more for "static" not
"superuser".
>There's some conceptual overlap, static binaries being there to recover
>even if your shared libraries are hosed which is normally a "superuser"
>kind of operation, but.
My recollection is that the "s" in /sbin and /usr/sbin was more
"system" level management. Things an admin would need but would not
usually be needed by an ordinary user.
Binaries in /bin and /sbin would have been statically linked to aid
in recovering a system in single-user mode when /usr might not be
mounted, in the days when disks were so small that /usr might often
be a separate disk.
/usr/sbin is an invention of Linux.
The traditional SysV meaning is /sbin for static binaries, and /bin for
and /usr/bin for normal dynamic binaries. Linux then redefine "sbin" as
meaning "system binaries", but that's a concept that really doesn't
make
much sense, as you can see for example by Fedora always placing both
/usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
in both places...
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...
Lennart
--
Lennart Poettering, Red Hat
9:52 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
/usr/sbin is an invention of Linux.
Hmm, I think Solaris had it, and I know DEC Unix had it.
IIRC /sbin came about for static bins, but then also to move config
binaries out of /etc. The bins not needed for early system startup
moved to /usr/sbin. I don't recall anything in /usr/sbin ever being
static. /usr/sbin also got other programs that had been in /usr/lib
(such as sendmail) when cleaning up.
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...
As I said before, there's still some consolehelper stuff that requires
entries in both /usr/bin and /usr/sbin to work.
--
Chris Adams <linux(a)cmadams.net>
10 a.m.
On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote:
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...
This -- and the current approach of having everything in $PATH -- leads toa
really cluttered namespace, making tab completion more frustrating than it
needs to be.
I'd like to see:
* commands which don't work at all as non-root left in usr/sbin and that
/removed from the default path; commands which are "system" commands but
work on some level as non-root could go to /usr/bin
* and commands which aren't meant to be executed by a human in normal
course of operation put somewhere other than /usr/bin -- usr/libexec is
kind of quirky but there it is, or else use /usr/sbin for that (and
possibly discard the previous notion)
This is a lot of shuffling for not necessarily very much gain, but if we're
going to have some sort of shuffling, it'd be nice to have one which makes
the in-$PATH namespace cleaner.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10:01 a.m.
On Mon, May 5, 2014 at 11:00 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote:
> We really should get rid of the destinction, and make all of /bin,
> /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> about $PATH orders and namespace collisions...
We can't do any cleanup of this form until consolehelper is gone though.
10:55 a.m.
On Mon, May 05, 2014 at 11:00:05AM -0400, Matthew Miller wrote:
On Mon, May 05, 2014 at 04:43:49PM +0200, Lennart Poettering wrote:
> We really should get rid of the destinction, and make all of /bin,
> /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> about $PATH orders and namespace collisions...
This -- and the current approach of having everything in $PATH -- leads toa
really cluttered namespace, making tab completion more frustrating than it
needs to be.
I'd like to see:
* commands which don't work at all as non-root left in usr/sbin and that
/removed from the default path; commands which are "system" commands but
work on some level as non-root could go to /usr/bin
* and commands which aren't meant to be executed by a human in normal
course of operation put somewhere other than /usr/bin -- usr/libexec is
kind of quirky but there it is, or else use /usr/sbin for that (and
possibly discard the previous notion)
This is a lot of shuffling for not necessarily very much gain, but if we're
going to have some sort of shuffling, it'd be nice to have one which makes
the in-$PATH namespace cleaner.
The full-scope cleanup looks very tempting:
https://docs.google.com/presentation/d/1ojgzJOfWB8XaC5kqyrv4IhR9snZKBI77a...
(Sorry for GDocs link, I don't know other source)
--
Tomasz Torcz To co nierealne -- tutaj jest normalne.
xmpp: zdzichubg(a)chrome.pl Ziomale na życie mają tu patenty specjalne.
11:15 a.m.
On Mon, May 05, 2014 at 05:55:17PM +0200, Tomasz Torcz wrote:
The full-scope cleanup looks very tempting:
https://docs.google.com/presentation/d/1ojgzJOfWB8XaC5kqyrv4IhR9snZKBI77a...
That seems to cover a lot of what I'd like to see, yeah, including moving
daemons out of the way (and it mentions the consolehelper problem).
It's got some other weirdness -- one is misunderstanding the meaning of
/usr/share ("do not use /usr/share for things which are not shared between
packages"), but the original intention is kind of absorbed into the multilib
proposal anyway. And calling /usr/libexec "Fedora-only" is of course kind of
funny.
But, overall, sure, looks cleaner and might be worth working towards, at
least where it actually addresses real problems rather than just shuffling
for the cleaner look alone.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
2:45 p.m.
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
And calling /usr/libexec "Fedora-only" is of course kind
of
funny.
"libexec" is Fedora-only, no other major distro used it, not even LSB
allowed it.
It makes no sense to ever have that, and the rest of the world
realized that long ago.
Kay
2:52 p.m.
Am 05.05.2014 21:45, schrieb Kay Sievers:
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> And calling /usr/libexec "Fedora-only" is of course kind of
> funny.
"libexec" is Fedora-only, no other major distro used it, not even LSB
allowed it.
you systemd-guys are really funny - /run was okay and FHS did
not matter because it don't get often enough updates and was in
your way, libexec is not OK because you don't like itand prefer
to fix things which ain't broken - wheter it's part of a proposed
FHS update and from where it comes
https://lists.fedoraproject.org/pipermail/devel/2012-December/175530.html
> It's worth knowing the history here. Libexec isn't
completely out of the
> blue -- it comes from GNU. For whatever reason, FHS was resistant to
> accepting libexec (but somewhat ironically!) the BSDs picked it up, and as I
> understand it, liked it so much that it's one of the reasons the FHS failed
> to become more than a Linux standard.
http://comments.gmane.org/gmane.linux.lfs.beyond.devel/21616
> I could have sworn I had seen something about this on list in the
past
> month, and didn't have time to answer, but I cannot for the life of me
> find it. Unfortunately, /usr/libexec is not a part of the current FHS,
> but, is a part of the 3.0 draft 1 (which hopefully will become official
> someday)
https://lists.debian.org/debian-hurd/2011/09/msg00039.html
>> On Wed, Sep 7, 2011 at 11:07 AM, Philipp Kern
<pkern(a)debian.org> wrote:
> On Mon, Nov 16, 2009 at 03:40:05PM +0100, Bastian Blank wrote:
>> Hurd violates the FHS by using /libexec. This name seems to be only used
>> by init and /etc/ttys.
3:03 p.m.
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 05.05.2014 21:45, schrieb Kay Sievers:
> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
>
>> And calling /usr/libexec "Fedora-only" is of course kind of
>> funny.
>
> "libexec" is Fedora-only, no other major distro used it, not even LSB
> allowed it.
you systemd-guys are really funny - /run was okay and FHS did
not matter because it don't get often enough updates and was in
your way, libexec is not OK because you don't like itand prefer
to fix things which ain't broken - wheter it's part of a proposed
FHS update and from where it comes
It is not about being funny, it is about making reasonable decisions.
/run solved a huge old problem, libexec is pointless and only creates
needless and nothing but annoying differences.
Kay
3:07 p.m.
Am 05.05.2014 22:03, schrieb Kay Sievers:
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> Am 05.05.2014 21:45, schrieb Kay Sievers:
>> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
>>
>>> And calling /usr/libexec "Fedora-only" is of course kind of
>>> funny.
>>
>> "libexec" is Fedora-only, no other major distro used it, not even LSB
>> allowed it.
> you systemd-guys are really funny - /run was okay and FHS did
> not matter because it don't get often enough updates and was in
> your way, libexec is not OK because you don't like itand prefer
> to fix things which ain't broken - wheter it's part of a proposed
> FHS update and from where it comes
It is not about being funny, it is about making reasonable decisions.
/run solved a huge old problem, libexec is pointless and only creates
needless and nothing but annoying differences
the follwing is *not* any sort of attack
your you it's pointless
for people maintaining existing machines with existing configurations,
systemd-units and so on it's pointless to fix and debug things which
are working because "reasonable decisions"
you need to distinct between
* reasonable with no impact
* reasonable with impact left and right around you
* change for the sake of change
3:09 p.m.
2014-05-05 22:03 GMT+02:00 Kay Sievers <kay(a)vrfy.org>:
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald
<h.reindl(a)thelounge.net>
wrote:
> Am 05.05.2014 21:45, schrieb Kay Sievers:
>> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller <
mattdm(a)fedoraproject.org> wrote:
>>
>>> And calling /usr/libexec "Fedora-only" is of course kind of
>>> funny.
>>
>> "libexec" is Fedora-only, no other major distro used it, not even LSB
>> allowed it.
> you systemd-guys are really funny - /run was okay and FHS did
> not matter because it don't get often enough updates and was in
> your way, libexec is not OK because you don't like itand prefer
> to fix things which ain't broken - wheter it's part of a proposed
> FHS update and from where it comes
It is not about being funny, it is about making reasonable decisions.
/run solved a huge old problem, libexec is pointless and only creates
needless and nothing but annoying differences.
Nah. /usr/libexec is a good place to store system-wide helper binaries
without having to worry about the patch changing due to multilib; remember
systemd has had to receive an explicit exception[1] for its scheme of
storing everything-in /usr/lib/systemd as if it were /opt/systemd, with
many of the files located there violating the intent of FHS.
Mirek
[1] https://fedorahosted.org/fesco/ticket/969
3:19 p.m.
On Mon, 2014-05-05 at 22:03 +0200, Kay Sievers wrote:
On Mon, May 5, 2014 at 9:52 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> Am 05.05.2014 21:45, schrieb Kay Sievers:
>> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
>>
>>> And calling /usr/libexec "Fedora-only" is of course kind of
>>> funny.
>>
>> "libexec" is Fedora-only, no other major distro used it, not even LSB
>> allowed it.
> you systemd-guys are really funny - /run was okay and FHS did
> not matter because it don't get often enough updates and was in
> your way, libexec is not OK because you don't like itand prefer
> to fix things which ain't broken - wheter it's part of a proposed
> FHS update and from where it comes
It is not about being funny, it is about making reasonable decisions.
/run solved a huge old problem, libexec is pointless and only creates
needless and nothing but annoying differences.
It's a practical way to keep helpers out of path and autocomplete
without polluting /usr/lib[64] and having to deal with multilib issues,
what's pointless about it ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:21 p.m.
Am 05.05.2014 22:19, schrieb Simo Sorce:
On Mon, 2014-05-05 at 22:03 +0200, Kay Sievers wrote:
> On Mon, May 5, 2014 at 9:52 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>> Am 05.05.2014 21:45, schrieb Kay Sievers:
>>> On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
>>>
>>>> And calling /usr/libexec "Fedora-only" is of course kind of
>>>> funny.
>>>
>>> "libexec" is Fedora-only, no other major distro used it, not even
LSB
>>> allowed it.
>
>> you systemd-guys are really funny - /run was okay and FHS did
>> not matter because it don't get often enough updates and was in
>> your way, libexec is not OK because you don't like itand prefer
>> to fix things which ain't broken - wheter it's part of a proposed
>> FHS update and from where it comes
>
> It is not about being funny, it is about making reasonable decisions.
> /run solved a huge old problem, libexec is pointless and only creates
> needless and nothing but annoying differences.
It's a practical way to keep helpers out of path and autocomplete
without polluting /usr/lib[64] and having to deal with multilib issues,
what's pointless about it?
that it was not proposed by systemd-upstream
(sorry could not resist)
3:24 p.m.
On Mon, 2014-05-05 at 16:19 -0400, Simo Sorce wrote:
It's a practical way to keep helpers out of path and autocomplete
without polluting /usr/lib[64] and having to deal with multilib issues,
what's pointless about it ?
It causes pointless configure and Makefile complications in every single
upstream project that wants to install something into that location and
has to differentiate between Fedora (/usr/libexec) and the rest of the
world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
e.g. having to patch the right prefix into desktop files, into service
files, etc etc.
The fact that multilib gets in the way is an argument against the way we
do multilib, not against /usr/lib/$pkg, from my pov.
Matthias
3:28 p.m.
On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
It causes pointless configure and Makefile complications in every
single
upstream project that wants to install something into that location and
has to differentiate between Fedora (/usr/libexec) and the rest of the
world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
e.g. having to patch the right prefix into desktop files, into service
files, etc etc.
Now that's a practical reason that I can get behind. But given that we're
already here and have done all that, is it valuable to undo? Again, I shrug
-- plenty of other stuff to fix, but I think a case could certainly be made.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
3:38 p.m.
On 05/05/2014 10:28 PM, Matthew Miller wrote:
On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
> It causes pointless configure and Makefile complications in every single
> upstream project that wants to install something into that location and
> has to differentiate between Fedora (/usr/libexec) and the rest of the
> world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
> e.g. having to patch the right prefix into desktop files, into service
> files, etc etc.
Now that's a practical reason that I can get behind. But given that we're
already here and have done all that, is it valuable to undo? Again, I shrug
-- plenty of other stuff to fix, but I think a case could certainly be made.
I don't think it's valuable to undo it at this point, but rather let
applications install into /usr/lib/$pkg/ if they want to. Right now, the
Fedora guidelines downright forbid that.
I'll emphasize that I really mean /usr/lib/$pkg/, as opposed to
/usr/$multilib_directory/$pkg/ -- this ensures that the same directory
is available in all distros the same way, and avoids multilib issues
with helper binaries.
Right now, various upstreams have to ship checks like:
if (fedora_based_distro)
helper_dir = /usr/libexec
else
helper_dir = /usr/lib
Relaxing the guidelines would allow those upstreams to write saner code,
and be more compatible across various distributions.
--
Hope this helps,
Kalev
5:25 p.m.
On Mon, May 05, 2014 at 10:38:10PM +0200, Kalev Lember wrote:
On 05/05/2014 10:28 PM, Matthew Miller wrote:
> On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
>> It causes pointless configure and Makefile complications in every single
>> upstream project that wants to install something into that location and
>> has to differentiate between Fedora (/usr/libexec) and the rest of the
>> world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
>> e.g. having to patch the right prefix into desktop files, into service
>> files, etc etc.
>
Note that when I first read this, I assumed you meant %{_libexecdir} and
%{_libdir}/$pkg which would be untrue. After reading kalev's message, I'm
guessing that you mean %{_libexecdir} and %{_prefix}/lib/$pkg. This could
also be stated as %{_libdir}/$pkg vs %{_prefix}/lib/$pkg... %{_libexecdir}
and %{_libdir}/$pkg are both valid in the packaging guidelines.
> Now that's a practical reason that I can get behind. But
given that we're
> already here and have done all that, is it valuable to undo? Again, I shrug
> -- plenty of other stuff to fix, but I think a case could certainly be made.
I don't think it's valuable to undo it at this point, but rather let
applications install into /usr/lib/$pkg/ if they want to. Right now, the
Fedora guidelines downright forbid that.
I'll emphasize that I really mean /usr/lib/$pkg/, as opposed to
/usr/$multilib_directory/$pkg/ -- this ensures that the same directory
is available in all distros the same way, and avoids multilib issues
with helper binaries.
Right now, various upstreams have to ship checks like:
if (fedora_based_distro)
helper_dir = /usr/libexec
else
helper_dir = /usr/lib
If upstream is using the autotools you should just use @pkglibexecdir@ or
@libexecdir@. Linux distributions, BSDs and etc all set --libexecdir to
the proper location for their tastes.
If upstream does not use autotools then they may end up having to do
a platform check for helper_dir. But they could also end up having to do
a platform check for shared libraries or arch-specific data files. The
difference between Fedora and other distros is really multilib, not libexec.
Relaxing the guidelines would allow those upstreams to write saner
code,
and be more compatible across various distributions.
If we get rid of multilib then that would be fine otherwise it'll be more
error prone to add %{_prefix}/lib into the mix with %{_libexecdir} and
%{_libdir}. Most upstreams do not know about or care about multilib. This
means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
that must go in %{_libdir}/$pkg. As long as we have multilib we need to
check the usage of these directories and patch in the separation between the
directories when needed. The usage of %{_libdir}/$pkg and %{_libexecdir}
just makes this more apparent.
We've already gotten rid of multilib distinctions for specific ecosystems
within Fedora so they don't have to make checks like this. We could either
expand that to encompass additional specific ecosystems or we could get rid
of multilib altogether.
-Toshio
10:02 a.m.
On 05/06/2014 12:25 AM, Toshio Kuratomi wrote:
<snip>
%{_libexecdir} and %{_libdir}/$pkg are both valid in the packaging
guidelines.
Yep, and both valid variants differ from what other distros use. Debian
uses /usr/lib/$pkg for @libexecdir@.
<snip>
If upstream is using the autotools you should just use
@pkglibexecdir@ or
@libexecdir@. Linux distributions, BSDs and etc all set --libexecdir to
the proper location for their tastes.
I agree with you here. As long as the helpers are only used internally,
it's indeed very simple. It doesn't matter what it exactly expands to:
the app can always find its own files since it can easily keep track how
it was configured.
But there is another class of packages that provide system wide
services. Those packages install system wide helpers and expect _other_
programs to run these.
At that point, the location of /usr/libexec/ vs /usr/lib/$pkg/ vs
/usr/$lib/$pkg becomes the interface that other programs are supposed to
use. And when those differ between different distros, it becomes
difficult for _consumers_ to know where they are installed.
This is why systemd insists on using /usr/lib/systemd on all distros so
that it would be consistent for consumers.
(I wrote a long text here how I ran into this issue having to detect
/usr/libexec/pk-trigger-offline-update (Fedora) vs
/usr/lib/packagekit/pk-trigger-offline-update (Debian), but decided to
delete it since it seemed too specialized.)
If upstream does not use autotools then they may end up having to do
a platform check for helper_dir. But they could also end up having to do
a platform check for shared libraries or arch-specific data files. The
difference between Fedora and other distros is really multilib, not libexec.
No, I disagree, those are separate issues.
Using /usr/lib/$pkg for helper binaries is no more or no less multilib
compatible than /usr/libexec. Neither one supports parallel installation
of executables.
> Relaxing the guidelines would allow those upstreams to write
saner code,
> and be more compatible across various distributions.
If we get rid of multilib then that would be fine otherwise it'll be more
error prone to add %{_prefix}/lib into the mix with %{_libexecdir} and
%{_libdir}. Most upstreams do not know about or care about multilib. This
means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
that must go in %{_libdir}/$pkg.
Yes, that's a fair point. More options makes it easier for packagers to
mess up in some way. I guess that's also why some people here are
advocating for complete removal of /usr/libexec to reduce the number of
options.
--
Kalev
3:24 p.m.
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote:
> And calling /usr/libexec "Fedora-only" is of course
kind of
> funny.
"libexec" is Fedora-only, no other major distro used it, not even LSB
allowed it.
Well, Red Hat Linux, before Fedora. And I believe we got it from BSD (it
seems to have made its way to Mac OS X as well); it's in the GNU coding
standards, of course... I don't know which was actually first.
But the part that's funny is that there's _several other major distros_
right around the corner that also use it. Now, since they're our downstream,
they probably would follow suit if we decided to do something different, but
that doesn't mean they don't exist.
It makes no sense to ever have that, and the rest of the world
realized that long ago.
It makes _some_ sense -- the rationale for it is in _your_ slides just
linked a few posts back -- daemons and other programs meant to be run by
other programs rather than by users. That's exactly the point. I think that
putting each program into its own subdirectory is probably a better way to
solve the same problem in theory, but in practice, libexec does the job
fine.
As I understand it, the /usr/libexec solution was preferred primarily
because it kept /usr/lib just for libraries -- the aesthetic argument,
ironically. We certainly don't follow _that_, so if we're going for
prettiness, going to /usr/lib/[application] makes sense. But it's also a lot
of churn, and it addresses the problem it's aimed at, so.... the case needs
to be stronger than "it doesn't make sense to me".
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
9:06 a.m.
On Mon, May 05, 2014 at 09:45:38PM +0200, Kay Sievers wrote:
On Mon, May 5, 2014 at 6:15 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> And calling /usr/libexec "Fedora-only" is of course kind of
> funny.
"libexec" is Fedora-only, no other major distro used it, not even LSB
allowed it.
It makes no sense to ever have that, and the rest of the world
realized that long ago.
libexec is from the GNU Coding Standards, which a lot of Linux-isms come
from:
http://www.gnu.org/prep/standards/standards.html
The rationale was always clear to me: libexec is for storing executable
programs to be run by other programs rather than directly by users.
*Even* GNU violates this "standard" with the installation of /usr/lib/gcc
(among other things).
The FSSTND, FHS, and LSB never made mention of libexec. They neither forbid
it nor explicitly required it, so it's like every other made up standard
that came along. No one really cared enough to stop it because it didn't
matter.
I think the annoying thing is if you're typing out a path that includes
/usr/lib, you can't easily hit TAB to get in to lib. And that's worth
fixing.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
9:11 a.m.
2014-05-06 16:06 GMT+02:00 David Cantrell <dcantrell(a)redhat.com>:
I think the annoying thing is if you're typing out a path that
includes
/usr/lib, you can't easily hit TAB to get in to lib. And that's worth
fixing.
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
2) Changing the file system hierarchy and repackaging dozens of hundreds of
packages to make tab completion, let alone tab completion for files that
users shouldn't ordinarily explicitly refer to, easier, is *not* worth
doing.
Mirek
9:37 a.m.
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
2014-05-06 16:06 GMT+02:00 David Cantrell
<[1]dcantrell(a)redhat.com>:
I think the annoying thing is if you're typing out a path that
includes
/usr/lib, you can't easily hit TAB to get in to lib. Â And that's
worth
fixing.
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
Yeah, that's true. The system in front of me is apparently still 32-bit.
2) Changing the file system hierarchy and repackaging dozens of
hundreds of packages to make tab completion, let alone tab completion
for files that users shouldn't ordinarily explicitly refer to, easier,
is not worth doing.
I agree with this. We're talking about janitorial work here and just
generating a lot of change. I'm not opposed to it if we were just something
we said, "hey, they next time you update your package, can you move these
files...." and then eventually libexec would just empty out. Or not, I
really have no strong opinions either way.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
11:49 a.m.
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
2014-05-06 16:06 GMT+02:00 David Cantrell
<dcantrell(a)redhat.com>:
> I think the annoying thing is if you're typing out a path that includes
> /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> fixing.
>
Oh my...
1) With the existence of /usr/lib{,64}, the additional existence of
/usr/libexec doesn't make any difference AFAICT.
Well getting rid of /usr/lib64 and multilib would be another
worthwhile long-term goal. Debian have used a more sensible scheme:
https://wiki.debian.org/Multiarch
For entertainment:
https://bugzilla.redhat.com/show_bug.cgi?id=235752
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
1:37 p.m.
On 6 May 2014 10:49, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Tue, May 06, 2014 at 04:11:50PM +0200, Miloslav Trmač wrote:
> 2014-05-06 16:06 GMT+02:00 David Cantrell <dcantrell(a)redhat.com>:
>
> > I think the annoying thing is if you're typing out a path that includes
> > /usr/lib, you can't easily hit TAB to get in to lib. And that's worth
> > fixing.
> >
>
> Oh my...
>
> 1) With the existence of /usr/lib{,64}, the additional existence of
> /usr/libexec doesn't make any difference AFAICT.
Well getting rid of /usr/lib64 and multilib would be another
worthwhile long-term goal. Debian have used a more sensible scheme:
https://wiki.debian.org/Multiarch
For entertainment:
https://bugzilla.redhat.com/show_bug.cgi?id=235752
I would go through the Debian bug system to find all the issues they have
with their multiarch scheme and certain software. Both 'solutions' cause
issues at time and headaches for packagers to sysadmins to users. Now
whether or not one set of headaches/problems is less painful I don't know..
[I only know this because the one thing my Debian friends ever tell me
that Red Hat got right was with multilib versus multiarch ... of course
they could just be throwing me a bone.]
--
Stephen J Smoogen.
10:12 a.m.
On 05/05/2014 10:43 AM, Lennart Poettering wrote:
On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle(a)redhat.com)
wrote:
> On 05/05/2014 10:28 AM, Adam Jackson wrote:
>> On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
>>
>>> however, the semantics of /usr/sbin is to contain superuser
>>> binaries which should not be overriden because a binary
>>> with the same name exists in /usr/bin
>> My memory is that the "s" was more for "static" not
"superuser".
>> There's some conceptual overlap, static binaries being there to recover
>> even if your shared libraries are hosed which is normally a
"superuser"
>> kind of operation, but.
> My recollection is that the "s" in /sbin and /usr/sbin was more
> "system" level management. Things an admin would need but would not
> usually be needed by an ordinary user.
>
> Binaries in /bin and /sbin would have been statically linked to aid
> in recovering a system in single-user mode when /usr might not be
> mounted, in the days when disks were so small that /usr might often
> be a separate disk.
/usr/sbin is an invention of Linux.
It existed in *BSD for as long as I used it.
The traditional SysV meaning is /sbin for static binaries, and /bin for
and /usr/bin for normal dynamic binaries. Linux then redefine "sbin" as
meaning "system binaries", but that's a concept that really doesn't
make
much sense, as you can see for example by Fedora always placing both
/usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
in both places...
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...
Lennart
--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
10:32 a.m.
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle(a)redhat.com)
wrote:
> On 05/05/2014 10:28 AM, Adam Jackson wrote:
> >On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> >
> >>however, the semantics of /usr/sbin is to contain superuser
> >>binaries which should not be overriden because a binary
> >>with the same name exists in /usr/bin
> >
> >My memory is that the "s" was more for "static" not
"superuser".
> >There's some conceptual overlap, static binaries being there to recover
> >even if your shared libraries are hosed which is normally a
"superuser"
> >kind of operation, but.
>
> My recollection is that the "s" in /sbin and /usr/sbin was more
> "system" level management. Things an admin would need but would not
> usually be needed by an ordinary user.
>
> Binaries in /bin and /sbin would have been statically linked to aid
> in recovering a system in single-user mode when /usr might not be
> mounted, in the days when disks were so small that /usr might often
> be a separate disk.
/usr/sbin is an invention of Linux.
The traditional SysV meaning is /sbin for static binaries, and /bin for
and /usr/bin for normal dynamic binaries. Linux then redefine "sbin" as
meaning "system binaries", but that's a concept that really doesn't
make
much sense, as you can see for example by Fedora always placing both
/usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
in both places...
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...
Is there a description somewhere of why /usr/bin instead of ditching it
and keeping just /bin ? Ie why the '/usr' prefix ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:49 a.m.
On Mon, 05.05.14 11:32, Simo Sorce (simo(a)redhat.com) wrote:
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
> On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle(a)redhat.com) wrote:
>
> > On 05/05/2014 10:28 AM, Adam Jackson wrote:
> > >On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> > >
> > >>however, the semantics of /usr/sbin is to contain superuser
> > >>binaries which should not be overriden because a binary
> > >>with the same name exists in /usr/bin
> > >
> > >My memory is that the "s" was more for "static" not
"superuser".
> > >There's some conceptual overlap, static binaries being there to
recover
> > >even if your shared libraries are hosed which is normally a
"superuser"
> > >kind of operation, but.
> >
> > My recollection is that the "s" in /sbin and /usr/sbin was more
> > "system" level management. Things an admin would need but would not
> > usually be needed by an ordinary user.
> >
> > Binaries in /bin and /sbin would have been statically linked to aid
> > in recovering a system in single-user mode when /usr might not be
> > mounted, in the days when disks were so small that /usr might often
> > be a separate disk.
>
> /usr/sbin is an invention of Linux.
>
> The traditional SysV meaning is /sbin for static binaries, and /bin for
> and /usr/bin for normal dynamic binaries. Linux then redefine "sbin" as
> meaning "system binaries", but that's a concept that really
doesn't make
> much sense, as you can see for example by Fedora always placing both
> /usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
> in both places...
>
> We really should get rid of the destinction, and make all of /bin,
> /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> about $PATH orders and namespace collisions...
Is there a description somewhere of why /usr/bin instead of ditching it
and keeping just /bin ? Ie why the '/usr' prefix ?
Since the /usr merge we have the nice property that the entire vendor
supplied OS is in /usr, so we can instantiate 100x for 100 containers,
with leaving a private /etc and /var for each.
Lennart
--
Lennart Poettering, Red Hat
10:41 a.m.
On 05/05/2014 10:43 AM, Lennart Poettering wrote:
/usr/sbin is an invention of Linux.
Strange that you would claim this.
Here's a list of what's in /usr/sbin on NetBSD 1.0 (and there's no
overlap between what's in /usr/sbin and any other subdir.)
drwxr-xr-x root/wheel 0 1994-10-19 15:16 ./usr/sbin
-r-xr-xr-x bin/bin 16384 1994-10-19 15:15 ./usr/sbin/ac
-r-xr-xr-x bin/bin 12288 1994-10-19 15:15 ./usr/sbin/accton
-r-xr-xr-x bin/bin 81920 1994-10-19 15:15 ./usr/sbin/amd
-r-xr-xr-x bin/bin 20480 1994-10-19 15:15 ./usr/sbin/amq
-r-xr-xr-x bin/bin 16384 1994-10-19 15:15 ./usr/sbin/arp
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/bad144
-r-xr-xr-x bin/bin 40960 1994-10-19 15:15 ./usr/sbin/bootpd
-r-xr-xr-x bin/bin 32768 1994-10-19 15:15 ./usr/sbin/bootpef
-r-xr-xr-x bin/bin 20480 1994-10-19 15:15 ./usr/sbin/bootpgw
-r-xr-xr-x bin/bin 20480 1994-10-19 15:15 ./usr/sbin/bootptest
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/chat
hr-xr-xr-x bin/bin 0 1994-10-19 15:15 ./usr/sbin/chown link
to ./usr/bin/chgrp
-r-xr-xr-x bin/bin 12288 1994-10-19 15:15 ./usr/sbin/chroot
-r-xr-xr-x bin/bin 32768 1994-10-19 15:15 ./usr/sbin/cron
-r-xr-xr-x bin/bin 12288 1994-10-19 15:15 ./usr/sbin/dev_mkdb
-r-xr-xr-x bin/bin 16384 1994-10-19 15:15 ./usr/sbin/diskpart
-r-xr-xr-x bin/bin 20480 1994-10-19 15:15 ./usr/sbin/edquota
-r-xr-xr-x bin/bin 40960 1994-10-19 15:15 ./usr/sbin/fsinfo
-r-xr-xr-x bin/bin 16384 1994-10-19 15:15 ./usr/sbin/gettable
-r-xr-xr-x bin/bin 24576 1994-10-19 15:15 ./usr/sbin/htable
-r-xr-xr-x bin/bin 24576 1994-10-19 15:15 ./usr/sbin/inetd
-r-xr-sr-x bin/kmem 16384 1994-10-19 15:15 ./usr/sbin/iostat
-r-xr-xr-x bin/bin 20480 1994-10-19 15:15 ./usr/sbin/kvm_mkdb
-r-xr-sr-x bin/daemon 28672 1994-10-19 15:15 ./usr/sbin/lpc
-r-xr-xr-x bin/bin 45056 1994-10-19 15:15 ./usr/sbin/lpd
-r-xr-xr-x bin/bin 12288 1994-10-19 15:15 ./usr/sbin/lptest
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/mailstats
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/makemap
-r-xr-xr-x bin/bin 28672 1994-10-19 15:16 ./usr/sbin/map-mbone
-r-xr-xr-x bin/bin 16384 1994-10-19 15:15 ./usr/sbin/mk-amd-map
-r-xr-xr-x bin/bin 24576 1994-10-19 15:16 ./usr/sbin/mrinfo
-r-xr-xr-x bin/bin 36864 1994-10-19 15:16 ./usr/sbin/mrouted
-r-xr-xr-x bin/bin 28672 1994-10-19 15:16 ./usr/sbin/mtree
-r-xr-xr-x bin/bin 81920 1994-10-19 15:16 ./usr/sbin/named
-r-xr-xr-x bin/bin 93 1994-10-19 15:16 ./usr/sbin/named.reload
-r-xr-xr-x bin/bin 136 1994-10-19 15:16 ./usr/sbin/named.restart
-r-xr-xr-x bin/bin 53248 1994-10-19 15:16 ./usr/sbin/nslookup
-r-xr-xr-x bin/bin 12288 1994-10-19 15:16 ./usr/sbin/nsquery
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/nstest
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/pac
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/portmap
-r-sr-xr-x root/bin 65536 1994-10-19 15:16 ./usr/sbin/pppd
-r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/pppstats
-r-xr-xr-x bin/bin 12288 1994-10-19 15:16 ./usr/sbin/praliases
-r-xr-sr-x bin/kmem 24576 1994-10-19 15:16 ./usr/sbin/pstat
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/pwd_mkdb
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/quot
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/quotaoff
hr-xr-xr-x bin/bin 0 1994-10-19 15:16 ./usr/sbin/quotaon link
to ./usr/sbin/quotaoff
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/rarpd
-r-xr-xr-x bin/bin 24576 1994-10-19 15:16 ./usr/sbin/rbootd
-r-xr-xr-x bin/bin 12288 1994-10-19 15:16 ./usr/sbin/rdate
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/repquota
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/rmt
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/rpc.bootparamd
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/rwhod
-r-xr-xr-x bin/bin 24576 1994-10-19 15:16 ./usr/sbin/sa
hr-sr-xr-x root/bin 0 1994-10-19 15:16 ./usr/sbin/sendmail
link to ./usr/bin/mailq
-r-sr-xr-x root/bin 16384 1994-10-19 15:16 ./usr/sbin/sliplogin
-r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/slstats
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/spray
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/sysctl
-r-xr-xr-x bin/bin 24576 1994-10-19 15:16 ./usr/sbin/syslogd
-r-xr-xr-x bin/bin 126976 1994-10-19 15:16 ./usr/sbin/tcpdump
-r-xr-xr-x bin/bin 45056 1994-10-19 15:16 ./usr/sbin/timed
-r-sr-xr-x root/bin 24576 1994-10-19 15:16 ./usr/sbin/timedc
-r-sr-xr-x root/bin 20480 1994-10-19 15:16 ./usr/sbin/traceroute
-r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/trpt
-r-xr-sr-x bin/kmem 16384 1994-10-19 15:16 ./usr/sbin/trsp
-r-xr-xr-x bin/bin 12288 1994-10-19 15:16 ./usr/sbin/update
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/vipw
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/vnconfig
-r-xr-xr-x bin/bin 20480 1994-10-19 15:16 ./usr/sbin/ypbind
-r-xr-xr-x bin/bin 16384 1994-10-19 15:16 ./usr/sbin/yppoll
-r-xr-xr-x bin/bin 12288 1994-10-19 15:16 ./usr/sbin/ypset
--
Kaleb
8:29 p.m.
On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions..
Arch made exactly this change this last year. [1] Their distro still
seems to work.
[1]
https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-i...
10:52 a.m.
On Mon, May 5, 2014 at 4:35 PM, Kaleb S. KEITHLEY <kkeithle(a)redhat.com> wrote:
On 05/05/2014 10:28 AM, Adam Jackson wrote:
>
> On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
>
>> however, the semantics of /usr/sbin is to contain superuser
>> binaries which should not be overriden because a binary
>> with the same name exists in /usr/bin
>
>
> My memory is that the "s" was more for "static" not
"superuser".
> There's some conceptual overlap, static binaries being there to recover
> even if your shared libraries are hosed which is normally a "superuser"
> kind of operation, but.
My recollection is that the "s" in /sbin and /usr/sbin was more
"system"
level management. Things an admin would need but would not usually be needed
by an ordinary user.
Binaries in /bin and /sbin would have been statically linked to aid in
recovering a system in single-user mode when /usr might not be mounted, in
the days when disks were so small that /usr might often be a separate disk.
Hi,
From the hier(7) man page:
/bin This directory contains executable programs which are needed in
single user mode and to bring the system up or repair it.
/sbin Like /bin, this directory holds commands needed to boot the
system, but which are usually not executed by normal users.
/usr This directory is usually mounted from a separate partition.
It should hold only sharable, read-only data, so that it can be
mounted by various machines running Linux.
You can take a look at the FHS too:
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Dridi
--
Kaleb
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
10:43 a.m.
Hi,
That's my recollection as well. Heard that confusion about sbin being for
superuser before.
Jon
On 5 May 2014 15:29, "Adam Jackson" <ajax(a)redhat.com> wrote:
On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> however, the semantics of /usr/sbin is to contain superuser
> binaries which should not be overriden because a binary
> with the same name exists in /usr/bin
My memory is that the "s" was more for "static" not
"superuser".
There's some conceptual overlap, static binaries being there to recover
even if your shared libraries are hosed which is normally a "superuser"
kind of operation, but.
- ajax
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5:16 p.m.
Reindl Harald wrote:
no, in general /usr/sbin is supposed to come before /usr/bin
and any software assuming the opposite has a bug
my /etc/profile contains:
# Path manipulation
if [ "$EUID" = "0" ]; then
pathmunge /usr/sbin
pathmunge /usr/local/sbin
else
pathmunge /usr/local/sbin after
pathmunge /usr/sbin after
fi
Which seems to be that sbin gets *appended* for non-root users, for better
or worse.
-- rex
2:41 p.m.
On Mon, 2014-05-05 at 02:11 +1000, Ankur Sinha wrote:
Hi,
Hi,
Recently, the value of my PATH variable seems to be messed up:
> [asinha@ankur-laptop ~]$ echo $PATH
>
/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin
The same.
/usr/bin is supposed to come before /usr/sbin etc. This makes mock
throw
an error:
> mock -r fedora-rawhide-x86_64 rebuild ./python-taskreport-1.2.1-1.fc20.src.rpm
>
> ERROR: [Errno 1] Operation not permitted
>
> ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an
unprivileged user.
> ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or
manually run /usr/bin/mock to see if that fixes this problem.
Running /usr/bin/mock.. works, of course. I've checked the relevant
places, and everything seems to be in order. The EUID of my user is 1000
too, so there isn't a reason that /etc/profile should place the
directories incorrectly. Would anyone have an hints on correcting this?
There's nothing in my user's .bash_profile or .bashrc that modifies path
either.
I use byobu with a tmux backend, but I don't think that matters. I
opened a separate gnome-terminal without byobu and the EUID is correct
there too.
> [asinha@ankur-laptop ~]$ id asinha
> uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock)
I've filled bug for this[0] some times ago.
[0]https://bugzilla.redhat.com/show_bug.cgi?id=1092612
--
-Igor Gnatenko
3650
days inactive
3652
days old
41 comments
25 participants
participants (25)
-
Adam Jackson -
Ankur Sinha -
Björn Persson -
Chris Adams -
Colin Walters -
David Cantrell -
Dridi Boukelmoune -
Igor Gnatenko -
Jon Kent -
Kaleb S. KEITHLEY -
Kalev Lember -
Kay Sievers -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Miloslav Trmač -
Reindl Harald -
Rex Dieter -
Richard W.M. Jones -
Simo Sorce -
Stephen John Smoogen -
Steve Clark -
Tomasz Torcz -
Toshio Kuratomi