Re: traceroute in /usr/bin, not /usr/sbin
On Mon, 18 Jun 2001, Keith G. Murphy wrote:
[FHS's definition for /sbin-programs]
> As a system administrator (IANADD), I find it a very good definition.
> Why? It's completely operational in nature: unless I change something,
> if an ordinary user wants to run, say, traceroute, he can't, because
> it's in /usr/sbin and not /usr/bin. So this:
> 'if a normal (not a system adminstrator) user will ever run it directly,
> then it must
> be placed in one of the "bin" directories'
> is literally true, barring symlinks, changing PATH, etc.
Saying that an ordinary user cannot run a program in [/usr]/sbin is simply
incorrect. He can. The question is what he'd be doing when he runs a
program from /sbin. When running ifconfig, he'd be doing system
administration tasks (why else would you need the IP address *when you're
already logged on to that machine*?)
When running traceroute, you'd be doing network administration
tasks. Which is simply not the same as system administration.
The difference here is: you're thinking as a user that wants to run the
program. I'm thinking as someone that has to decide where a program needs
> I would argue that the FHS definition reflects the practical effects of
> placement of the programs, rather than some attempt to define them in
> human language terms. I don't understand why folks are getting hung up
> on whether they're "primarily" "administration tools".
> WRT the example, defining chopsticks as "Chinese utensils" has no
> operational effect on whether I can use them, but putting them in a box
> that by default only Chinese people would be able to look in sure would.
Anyway. I'm sick of this discussion. Let's cut it ;-)
wouter dot verhelst at advalvas in belgium
Try does not exist. Believe that you will do it, else you will fail.
-- Luke Skywalker,
in the trilogy "The Jedi Academy", Kevin J. Anderson