Re: horse carcas flogging (was: traceroute in /usr/bin, not /usr/sbin)
On Sat, 16 Jun 2001, Rene Weber wrote:
>
> Hello,
>
> On Sun, Jun 17, 2001 at 12:23:49AM +1000, Craig Sanders wrote:
> > the "traceroute belongs in /usr/bin because FHS says so" is based on a
> > debatable interpretation of the FHS, and a highly debatable assessment
> > of traceroute's status as a "user" tool rather than an "admin" tool.
>
> All right, if you think it's debatable, then let's debate it! There has
> been no debate on the subject (of whether the FHS mandates that traceroute
> must move) on this thread yet that I've seen. What I've seen is people
> pointing out that traceroute is useful to regular users, and the respondents
> saying that many other things are as well. This does not refute the
> original argument that traceroute is a user tool, it merely shifts the
> debate to the question if it is too disruptive to move everything.
>
> I also happen to think the FHS is completely clear on the subject that
> user tools must be moved. If anyone disagrees, I'd appreciate hearing their
> interpretation of the FHS directive in question[1] and how they think that
> traceroute is "used exclusively by the system administrator."
>
> > some people are saying that because traceroute CAN be executed by a user,
> > that makes it a user tool.
> >
> > *exactly* the same can be said for ifconfig and dozens of other programs
> > in /sbin and /usr/sbin.
> >
> > if the argument is valid for traceroute then it is also valid for
> > ifconfig etc. if traceroute must be moved, then so must the others.
>
> Great, so is the argument valid? Set aside for the moment the
> disruption (and let there be no doubt, if the argument is valid, there will
> be messiness and probably some disruption) and consider if the argument
> alone is valid. First we have to decide if there is a problem *then* we
> should worry about fixing it. Allowing the fear (that fixing it will be too
> much work) to influence whether or not we think/admit there is a problem in
> the first place is deeply flawed, as I hope is obvious.
>
> You say that there is a question as to whether traceroute is a "user"
> tool or an "admin" tool. Since the only relevant application of this
> distinction to the current discussion is the meaning placed in the FHS
> section 4.6[1], then I think we have a very clear criteria. If traceroute
> is "used exclusively by the system administrator", then it is what you would
> presumably call an "admin" tool. If not (thus, if it is used even
> occasionally by regular users), then it is what you would seemingly call a
> "user" tool. It seems clear to me that regular users use traceroute, so it
> is a "user" tool. What's your argument?
The FHS isn't clear at all. It is totally ambiguos in this point becasue
it doesn't define neither user nor system administrator. When you look
at the related entry for /sbin it is even contratctory to itself if you
interpret it strictly. It lists programs that are required in /sbin but
for any of those programs may be used as an user and so are not allowed in
/sbin. E.g. could a system administrator allow his users to execute mkfs
on /dev/fdX so they can format floppy disks, so mkfs.XXX are user tools
according to fhs!
Back to traceroute. You will definitely need some system (or better
network) administrator capabilities to interpret the output of traceroute.
This does not hold for ping as with ping you do not necessarily have to
understand its output to get the wanted information. I.e if you want to
know if a host is available you simply have to look if ping gives you any
ordinary output at all.
--
Manfred Wassmann
PGP and GnuPG public keys available at http://germany.keyserver.net
PGP: 24B81049 Fingerprint: D7 10 EE 2B 74 16 C0 64 B4 5F BA B2 90 29 3D AF
GPG: 6B299971 Fingerprint: A598 A41F 57A3 5D69 83D2 8027 1274 F8CD 6B29 9971
+++ I18N ? For international language set LANG=POSIX +++
Reply to: